Résumé
- Daté du 2 novembre,
draft-ietf-idr-fsv2-content-filter-00propose un critère fondé sur des octets du paquet pour FlowSpec v1 et v2. C'est un projet de groupe de travail IETF. - Le critère indique un point de départ, un décalage, une séquence et un masque. Dans FSv2, il est obligatoire : si l'équipement ne peut l'appliquer, la règle entière ne peut pas être installée localement.
- Ignorer les octets tout en gardant le reste élargirait le filtre. La sélection des pairs BGP, l'autorisation de la règle, les ressources et la possibilité de retour arrière restent du ressort de l'opérateur.
Le détail qui empêche un filet de devenir un chalut
Une règle FlowSpec voyage par BGP et peut influer sur le traitement du trafic. Les familles IP de base s'appuient surtout sur les en-têtes. Le nouveau texte de l'IDR ajoute un critère sur le contenu : une séquence fixe, cherchée à une position précise. Pour une attaque dont les paquets portent un motif connu, ce détail peut réduire la cible. S'il disparaît en route, le filet cesse d'être précis.
Le format choisit d'abord un repère : début de l'en-tête IP, de la charge IP, de la charge UDP ou de la charge TCP. Un décalage conduit aux octets visés; un masque détermine les bits significatifs. Le document donne même l'exemple de deux octets au début d'une charge TCP, associés à un préfixe de destination. Il s'agit de comparaison de bits, pas d'une compréhension générale du contenu applicatif.
La limite matérielle est au cœur de l'affaire. Le format peut coder une longueur de un à 255 octets, alors qu'un équipement peut prendre en charge beaucoup moins. Dans FSv2, le composant est marqué obligatoire. Si un appareil ne sait pas réaliser la comparaison, la route FlowSpec devient inéligible à l'installation locale. Il ne peut pas effacer ce critère et conserver les autres conditions avec une action de blocage ou de limitation. Un tel raccourci frapperait des paquets que la règle originale aurait épargnés.
Même lorsqu'un appareil sait lire les octets, il faut savoir lesquels. En IPv6, le repère « charge IP » commence après l'en-tête fixe et peut englober des en-têtes d'extension dont la disposition change en chemin. Avec un tunnel, compter depuis l'enveloppe extérieure peut viser le mauvais paquet. Le projet recommande de travailler sur le paquet interne après décapsulation lorsque c'est approprié, ou de fixer un repère sans ambiguïté.
Les auteurs conseillent des points de filtrage contrôlés, des conditions d'en-tête complémentaires, des pairs BGP de confiance et une diffusion limitée. Les entrées ACL, UDF et TCAM ne sont pas infinies. Le texte fait état d'essais avec OpenBGPD, FRRouting et des commutateurs programmables, sans chiffre de déploiement en production. Il met une règle simple devant les opérateurs : la machine qui ne peut pas tenir la promesse d'un filtrage précis doit refuser l'action entière.
Sources originales
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé au Cercle stratégique
Cercle stratégique
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre le Cercle stratégiqueRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance





