En esta página
El problema operativo
FlowSpec solo ve componentes de cabecera: destino, protocolo, puertos, longitud de paquete, flags TCP y campos similares según el proveedor. No sabe si una sesión pertenece a un jugador legítimo, a una API crítica o a un botnet.
Además, cada upstream impone límites: número de reglas, acciones aceptadas, granularidad de destinos y campos soportados. Diseñar como si FlowSpec fuera ilimitado puede fallar en el peor momento.
Por qué importa antes del ataque
Una regla demasiado amplia se aplica antes de que el cliente pueda recuperar tráfico legítimo con su propia lógica. El enlace parece limpio, pero usuarios reales pueden quedar fuera.
Comprender las limitaciones evita vender FlowSpec como protección completa. Su mejor papel es retirar tráfico pesado y evidente para que la mitigación downstream trabaje con menos presión.
Enfoques técnicos posibles
La práctica más segura es usar FlowSpec para desgrosar: reglas cortas, destino concreto, protocolo claro y expiración. Si el patrón no es estable, es mejor no intentar describir todo el ataque con una sola regla.
Las decisiones que requieren estado, baseline o conocimiento de aplicación deben quedarse en DPDK/VPP, XDP, proxy, reglas post-filtrado o lógica gaming específica.
Checklist operativo antes de ponerlo en producción
- Revisar la regla de Limitaciones de BGP FlowSpec cuando el ataque cambia de forma.
Caso de uso concreto
Un UDP flood de 180 Gbps repite puerto y tamaño hacia una IP concreta. Una regla FlowSpec estrecha puede bajar la presión antes del handoff. Una regla global sobre todo UDP del prefijo puede romper DNS, juegos o supervisión.
El enfoque correcto es progresivo: filtrar la firma evidente, observar el tráfico permitido y dejar el tráfico mixto a una capa downstream con más contexto.
