Résumé

  • FlowSpec distribue des critères de correspondance et des actions ; voir la route établit un état du plan de contrôle, pas un résultat de transfert.
  • Une règle externe dépend normalement d’une validation contre les routes unicast et doit être revalidée lorsque la meilleure route change.
  • Des règles et actions peuvent se chevaucher ou se contredire ; les limites de traitement IPv6 et du matériel peuvent empêcher leur application.
  • La clôture exige de relier le NLRI exact aux équipements programmés, aux compteurs, aux paquets observés et à l’effet sur le trafic légitime.

Imaginons qu’un contrôleur anti-DDoS émette une règle visant une destination et un port. Elle apparaît sur le réflecteur et sur trois plans de contrôle de bordure ; le tableau d’incident passe au vert. Pourtant, une interface à fort débit continue de transporter le flux, car sa carte n’a pas pu compiler le critère de couche supérieure. L’annonce BGP était bien présente. Le filtre, lui, ne l’était pas.

Ce scénario est hypothétique. Il ne décrit ni panne réelle ni fournisseur précis. Il montre seulement qu’une instruction distribuée et une action exécutée ne constituent pas la même preuve.

Ce que transporte réellement la route

La RFC 8955 décrit une Flow Specification comme un n-uplet encodé dans un NLRI BGP. Les composants peuvent viser les préfixes source et destination, le protocole, les ports, les drapeaux TCP, la longueur, le DSCP ou les fragments. Un paquet ne correspond que s’il satisfait l’intersection de tous les composants. Il faut donc conserver l’expression décodée, pas seulement le nom donné par un outil.

Les communautés étendues portent les actions : limitation en octets ou en paquets, échantillonnage, redirection vers une cible de route et marquage. Par défaut, un paquet correspondant suit le traitement normal et reste accepté. Un débit nul exprime l’abandon. Une règle reçue sans l’action attendue peut donc ne rien bloquer.

Plusieurs règles peuvent viser le même trafic. L’ordre de comparaison est déterministe et indépendant de l’ordre d’arrivée BGP, mais les actions peuvent encore être incompatibles. Dans ce cas, le choix appliqué au transfert relève de l’implémentation. Une diffusion uniforme peut produire des comportements locaux différents.

Une validation dépendante du routage

Sans configuration contraire, une règle externe doit contenir un préfixe de destination, provenir du même initiateur que la meilleure route unicast correspondante et ne pas englober une route plus spécifique reçue d’un autre AS voisin. La configuration peut assouplir la première condition ; la politique de validation fait donc partie de la preuve.

La route unicast peut changer sans nouvelle règle FlowSpec. La RFC impose alors une revalidation. Une annonce jugée possible à un instant peut devenir impossible après un changement de chemin, même si elle reste visible dans une collecte. Il faut enregistrer le point de validation et l’état unicast qui l’a justifiée.

La RFC 8956 étend le mécanisme à IPv6. Elle reprend la validation, impose un décalage nul au composant de préfixe de destination et décrit des critères propres à IPv6. Elle prévient aussi que certaines chaînes d’en-têtes et certaines limites matérielles empêchent l’application de critères de couche supérieure. Une route valide ne garantit pas que chaque carte saura la traduire.

Mesurer l’action sur les paquets

La RFC 8955 recommande la journalisation des en-têtes et des compteurs de correspondance par règle. Un dossier utile indique, pour chaque équipement et interface, si la règle a été compilée, refusée ou approximée, quelle action et quelle priorité ont été retenues, puis relie les compteurs à des échantillons du trafic attaquant.

Il faut ensuite mesurer ce qui atteint la victime, la perte de trafic légitime, la capacité de redirection et l’effet du retrait. Un compteur d’abandon qui monte peut viser le mauvais agrégat. Une baisse du trafic hostile peut masquer un dommage collatéral excessif. La présence de la route ne tranche aucun de ces cas.

Sources