Résumé

  • RFC 8955 transporte par BGP des critères de trafic et des actions, mais sa validation par défaut exige que l’origine du filtre corresponde à celle de la meilleure route unicast applicable ; tout changement de cette route impose une nouvelle validation.
  • Susan Hares a coécrit RFC 8955 et participé comme éditrice à son extension IPv6, RFC 8956. RFC 9117, rédigé ensuite par d’autres auteurs, aménage le cas d’un contrôleur central dans un même domaine local sans ouvrir un droit général au filtrage interdomaines.

Quand l’annonce devient une consigne de traitement

FlowSpec répond à une contrainte de temps. Face à une attaque par déni de service, distribuer une règle précise par BGP peut être plus rapide que configurer chaque équipement de bord. La règle peut combiner préfixes source et destination, protocole, ports, champs ICMP, drapeaux TCP, longueur de paquet, DSCP ou fragmentation. Des communautés étendues expriment ensuite une action : limiter le débit en octets ou en paquets, échantillonner, rendre la règle terminale, rediriger par route target ou modifier le marquage. Un débit nul signifie le rejet.

Cette efficacité rend l’erreur plus grave. Une annonce de reachability infléchit le chemin ; une annonce FlowSpec peut modifier directement le sort du trafic. Une syntaxe BGP valide ne démontre ni l’intention, ni la compétence opérationnelle, ni le droit de demander l’action.

Le profil officiel de Susan Hares dans l’IETF Datatracker permet de situer une contribution documentée. RFC 8955, publié en décembre 2020 sur le Standards Track, est signé par Christoph Loibl, Susan Hares, Robert Raszuk, Danny McPherson et Martin Bacher ; il remplace RFC 5575 et RFC 7674. RFC 8956, consacré à IPv6, a pour éditeurs Loibl, Raszuk et Hares.

Il s’agit d’un produit collectif de l’IETF, non de l’invention solitaire d’une personne. L’attribution raisonnable porte sur la participation de Hares à cette révision normative. Elle ne prouve ni propriété de FlowSpec, ni contrôle de ses implémentations, ni déploiement universel.

Emprunter une frontière au routage unicast

RFC 8955 définit un ordre déterministe lorsque plusieurs règles se chevauchent. Sans action associée, le comportement par défaut d’une correspondance est l’acceptation. Cet ordre évite que deux équipements appliquent arbitrairement des priorités contraires. Mais une règle bien ordonnée peut encore être illégitime.

La validation par défaut cherche donc la meilleure route unicast correspondant à la destination. L’émetteur du FlowSpec doit correspondre à l’émetteur de cette route. La présence d’une route plus spécifique provenant d’un autre AS voisin peut retirer cette qualité. En EBGP, le premier AS du chemin FlowSpec est aussi confronté à celui du chemin unicast.

Ce test n’est pas une preuve cryptographique de bonne foi. Il définit un périmètre. Le voisin qui constitue déjà l’étape immédiate vers la destination pourrait jeter les paquets une fois reçus. Lui permettre de demander à l’amont de limiter ou d’écarter ce même trafic plus tôt peut préserver la liaison saturée. Son droit découle de sa place actuelle dans le chemin vers la destination, pas de sa seule capacité à parler BGP.

Cette qualité n’est jamais acquise. RFC 8955 demande de revalider le FlowSpec chaque fois que la route unicast associée change. Une nouvelle origine ou un préfixe plus spécifique venu d’un autre pair peut enlever le fondement de la règle déjà installée. Un système qui ne contrôle qu’à la réception transforme à tort une autorisation contextuelle en privilège permanent.

Une exception qui reste à l’intérieur

Un contrôleur central légitime pose un problème différent. Dans son propre domaine, l’opérateur peut lui confier la diffusion des règles sans le placer sur le chemin de transfert de chaque préfixe. Le test strict le rejetterait précisément parce que ce contrôleur n’est pas un routeur de transit.

RFC 9117, paru en août 2021, adapte la validation à cette architecture. Ses auteurs sont Jeffrey Uttaro, Jorge Alcaide, Clarence Filsfils, David Smith et Pradosh Mohapatra ; Susan Hares n’en est pas l’autrice. Ce texte ultérieur importe ici parce qu’il révèle comment la limite du standard qu’elle a coécrit a été affinée.

L’assouplissement vise un même domaine administratif local. L’opérateur peut désigner un contrôleur de routes interne comme source de confiance sans exiger qu’il apparaisse dans la meilleure route unicast. RFC 9117 précise aussi le cas des route servers, dont l’AS_PATH n’exprime pas un transit classique. Il ne confère aucun mandat universel à un contrôleur distant. À la frontière entre domaines, la relation au routage et la politique du récepteur restent essentielles.

Autoriser « notre contrôleur à programmer notre réseau » est une décision de gouvernance locale. Accepter « qu’un autre réseau demande une action sur notre trafic » est une coordination interdomaines. La commodité technique ne doit pas effacer cette différence institutionnelle.

Le routeur doit confirmer la conséquence

La section sécurité de RFC 8955 énumère des risques concrets : filtrage, marquage ou redirection non désirés, changement de contexte VPN ou de file, rafale de mises à jour par un contrôleur défaillant, épuisement de la capacité de règles. Une correspondance trop large peut être syntaxiquement parfaite et opérationnellement destructrice.

Le réseau récepteur peut borner les actions acceptées par voisin, les préfixes, ports, débits, cibles de redirection et nombres de règles. Il doit aussi distinguer l’acceptation dans le control plane de l’installation dans l’ACL, la FIB ou l’ASIC. Même l’installation ne prouve pas que seuls les services prévus sont touchés.

Un RFC publié ne démontre donc ni support homogène des fournisseurs, ni activation chez un opérateur, ni réussite d’une mitigation. Il fixe des significations communes et une logique de sécurité par défaut. L’exécution réclame ses propres preuves.

Une grammaire commune, une responsabilité locale

L’essai de Lu Heng sur Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption éclaire cette répartition. La couche partagée peut rester mince : critères, encodage des actions, ordre déterministe et validation adossée au routage. Le réseau récepteur conserve la décision future : pairs autorisés, sous-ensemble d’actions, confiance accordée au contrôleur, capacité, journalisation et retrait.

Confondre une syntaxe commune avec un pouvoir commun rendrait le protocole coercitif. Laisser chaque implémentation réinterpréter la syntaxe le rendrait inutile. Le compromis consiste à stabiliser un petit langage et à rendre ses effets localement responsables.

Running-Code Primacy impose ensuite de regarder au-delà de la table BGP : état de validation, ordre sélectionné, installation matérielle, compteurs de paquets, effet réel, retrait et récupération. Il faut surtout tester la revalidation lors d’un changement de route unicast. Ces deux essais ultérieurs constituent le cadre d’analyse de Sofia Ren ; ils ne sont pas attribués à Hares ni aux auteurs des RFC.

Une règle FlowSpec mérite confiance si le réseau peut répondre à trois questions : qui l’a émise, quel fait de routage actuel lui donne qualité, et quelle politique locale autorise son action. La contribution documentée de Hares est importante parce que le standard ne sépare jamais la puissance du filtre de cette obligation de justification.

Sources