Resumen

  • FlowSpec distribuye criterios de coincidencia y acciones; ver la ruta acredita un estado de control, no un resultado de reenvío.
  • Las reglas externas suelen validarse contra rutas unicast y deben revisarse cuando cambia la mejor ruta correspondiente.
  • Varias reglas o acciones pueden solaparse, y los límites del análisis IPv6 o del hardware pueden impedir su aplicación.
  • El cierre exige unir el NLRI exacto con programación, contadores, muestras de paquetes y el efecto sobre tráfico atacado y legítimo.

Imaginemos que un controlador contra DDoS origina una regla para un destino y un puerto. Aparece en el reflector y en los planos de control de tres routers de borde, y el panel del incidente se vuelve verde. Sin embargo, un enlace de entrada sigue pasando el flujo porque su tarjeta no pudo compilar la coincidencia de capa superior. La evidencia BGP era correcta; la conclusión sobre el filtrado no.

Es un ejemplo hipotético, no un incidente atribuido. La diferencia importante es entre distribuir una instrucción y ejecutarla sobre paquetes.

Lo que realmente transporta la ruta

RFC 8955 codifica una Flow Specification como una n-tupla dentro de NLRI de BGP. Sus componentes pueden describir prefijos de origen y destino, protocolo, puertos, banderas TCP, longitud, DSCP o fragmentos. Un paquete coincide solo si cumple la intersección de todos los componentes. Por eso debe conservarse la expresión decodificada y no solo el nombre del panel.

Las comunidades extendidas llevan acciones de tasa en bytes o paquetes, muestreo, redirección por route target y marcado. La acción predeterminada es aceptar el paquete según el reenvío normal. Una tasa cero expresa descarte. Recibir una regla sin la acción esperada no equivale a bloquear.

Varias reglas pueden coincidir con un flujo. El estándar fija un orden que no depende de la llegada por BGP, pero las acciones todavía pueden contradecirse. Si el conflicto llega a la selección de reenvío, la implementación decide qué aplicar. La propagación puede ser idéntica y el resultado local diferente.

La validación cambia con el unicast

Sin una configuración explícita que lo altere, una regla externa debe incluir prefijo de destino, compartir originador con la mejor ruta unicast que cubra ese prefijo y no afectar a una ruta más específica recibida de otro AS vecino. La primera condición puede relajarse, de modo que la configuración de validación también forma parte de la prueba.

La mejor ruta unicast puede cambiar sin que cambie la regla. RFC 8955 exige revalidarla. Una regla viable antes de un cambio puede dejar de serlo aunque siga en un colector. El registro debe indicar dónde se validó y qué estado unicast la respaldaba.

RFC 8956 lleva FlowSpec a IPv6 con AFI 2 y SAFI 133 o 134. Reutiliza la validación con desplazamiento cero en el prefijo de destino y añade componentes propios. También advierte que cadenas de cabeceras anómalas o límites de hardware pueden impedir aplicar criterios de capa superior. La aceptación del control no elimina esa frontera física.

El resultado necesita evidencia de paquetes

RFC 8955 recomienda registrar cabeceras y contar coincidencias por regla. Para cada dispositivo e interfaz conviene guardar si la regla se compiló, fue rechazada o se aproximó; qué prioridad y acción quedaron; y cómo se relacionan sus contadores con muestras del ataque.

Después hay que medir el tráfico que llega a la víctima, la pérdida legítima, la capacidad de redirección y el efecto de retirar la regla. Un contador de descartes puede crecer sobre el agregado equivocado. Una caída del ataque puede ocultar daño colateral. La ruta FlowSpec por sí sola no distingue esos casos.

Fuentes