Résumé

  • L’agrégation remplace plusieurs routes spécifiques par une annonce moins spécifique. Avec RFC 9774, AS_SET n’est plus le mécanisme normal : ATOMIC_AGGREGATE reconnaît la perte d’information et AGGREGATOR désigne le dernier speaker ayant construit le résumé.
  • La présence du résumé, une validation RPKI positive et une session Established ne prouvent pas la reachability de chaque sous-préfixe. Un contributeur absent peut conduire correctement les paquets vers une route de rejet sans modifier l’annonce mondiale.
  • Le droit de compresser doit dépendre d’une origine choisie, de filtres propres à chaque contributeur, d’un registre antérieur à l’agrégation, de preuves RIB/FIB et paquets, et d’un rollback qui restaure tout le contrat.

À 02 h 13, un opérateur produit 203.0.112.0/22 à partir de quatre routes /24. Le but n’a rien d’exceptionnel : limiter les UPDATE, éviter d’exposer chaque changement local et offrir aux fournisseurs un point de stabilité. AS 64505 origine le résumé, un ROA l’autorise pour le /22, et les attributs ATOMIC_AGGREGATE et AGGREGATOR accompagnent la route.

À 03 h 07, 203.0.114.0/24 disparaît pendant une maintenance client. Les trois autres contributeurs sont encore actifs ; l’implémentation conserve donc le /22. Aucun collecteur public ne voit de retrait. Le contrôle d’origine reste Valid, le peer amont reste Established et le tableau de bord ne change pas de couleur.

Un paquet destiné au /24 absent atteint néanmoins AS 64505, ne trouve aucune route plus spécifique et tombe sur la route discard du résumé. Ce rejet est correct : il empêche le paquet d’emprunter un autre chemin moins spécifique, de revenir et de former une boucle. Mais « correct » ne signifie pas « livré ». Le système a contenu une absence que le résumé ne rend plus visible.

L’incident est fictif ; les règles ne le sont pas. ATOMIC_AGGREGATE n’annonce pas que tout va bien. Il annonce que l’AS_PATH ne raconte pas toute l’histoire.

Agréger, c’est créer une nouvelle affirmation

Un résumé n’est pas une ligne raccourcie dans une interface. BGP prend plusieurs NLRI plus spécifiques et forme une nouvelle NLRI moins spécifique avec ses propres attributs, sa condition d’activation, ses policies d’export et son effet de forwarding.

RFC 4271 prévoyait de conserver la plus longue séquence initiale commune aux AS_PATH contributeurs, puis de placer les numéros restants dans un AS_SET non ordonné. Le set réduisait la taille et gardait une trace des AS impliqués, mais perdait l’ordre. Il rendait aussi l’origin AS ambigu, ce qui est particulièrement mal adapté aux mécanismes de sécurité qui doivent raisonner sur un acteur précis.

RFC 6472 avait recommandé l’abandon d’AS_SET et d’AS_CONFED_SET. En mai 2025, RFC 9774 a transformé cette recommandation en exigence de standards : hors exception explicitement configurée, par exemple durant une transition, un speaker ne doit plus annoncer ces segments et doit traiter comme retirée une route reçue qui les contient.

L’agrégation demeure. C’est la manière d’assumer la perte qui change. La route garde une séquence déterminée, l’opérateur stabilise l’origine, et un attribut sans contenu matériel avertit que d’autres AS ont pu disparaître de la représentation.

Un attribut vide qui dit une chose essentielle

ATOMIC_AGGREGATE porte le code 6. C’est un attribut well-known discretionary de longueur zéro. Il ne transporte ni la liste supprimée, ni un digest, ni l’heure, ni la signature du décideur. Sa seule force vient d’une convention commune.

Lorsqu’un agrégat omet des AS parce que l’AS_SET a été écarté, il devrait porter cet attribut. Un receiver ne devrait pas le retirer en propageant la route. Il ne doit pas transformer la NLRI en annonces plus spécifiques. Surtout, il doit savoir que le chemin réel vers une destination couverte peut traverser des AS absents de l’AS_PATH.

ATOMIC_AGGREGATE est ainsi une limite de connaissance. Il confirme l’omission, pas le contenu omis. Il n’authentifie personne, n’autorise aucun préfixe et ne prouve aucune livraison. Lorsqu’un contributeur le portait déjà, le nouvel agrégat doit le conserver : une seconde compression ne peut pas effacer la première perte.

Ce détail remet l’autorité à sa place. L’annonce publique est utile parce qu’elle est minimale. Elle ne devient pas supérieure aux réalités qu’elle exclut. Un chemin court peut être moins précis, pas plus vrai.

AGGREGATOR ne tient pas un registre de garde

AGGREGATOR, code 7, est optionnel et transitif. Le speaker qui forme l’agrégat peut y inscrire son propre AS et son adresse IP, en principe son BGP Identifier. Dans l’agrégation « consistent brief » de RFC 9774, il accompagne ATOMIC_AGGREGATE.

Les deux champs répondent à des questions distinctes. Le premier reconnaît que des informations de chemin manquent. Le second désigne le dernier acte de construction du résumé. Il ne liste ni les contributeurs ni les décisions antérieures. RFC 4271 précise d’ailleurs que les AGGREGATOR présents sur les routes sources ne sont pas copiés tels quels dans le nouvel agrégat.

Ce n’est pas non plus une preuve cryptographique. Voir un AS et un BGP Identifier dans un collecteur n’établit ni le contrôle du bloc, ni la policy appliquée, ni la conservation des éléments sources. Avec des ASN sur quatre octets, AGGREGATOR change d’encodage ; en présence d’un ancien speaker, AS_TRANS et AS4_AGGREGATOR assurent la compatibilité. Ils préservent un nombre, pas une légitimité.

RFC 7606 limite le dommage d’un attribut mal formé. ATOMIC_AGGREGATE ou AGGREGATOR incorrect est écarté sans réinitialiser nécessairement la session. Ce choix protège la disponibilité, mais permet aussi à une route de survivre sans son avertissement ou son attribution. Le journal d’erreur doit donc rester indépendant du chemin accepté.

Fixer l’origine avant que les routes ne décident à notre place

L’agrégation brief garde la plus longue séquence initiale commune et abandonne le reste. Or cette séquence dépend des contributeurs disponibles. Deux chemins disjoints peuvent donner une séquence vide ; si l’un disparaît, le chemin restant peut soudain imposer son AS comme origine apparente.

Une responsabilité visible ne devrait pas varier au rythme des sessions clients. RFC 9774 exige donc, pour une agrégation consistent brief, de tronquer le chemin après l’occurrence la plus à droite d’un origin AS choisi. Celui-ci peut être l’AS agrégateur. Le préfixe résumé doit disposer d’un ROA correspondant si l’on veut une validation RPKI cohérente.

Le choix rend la décision explicite. AS 64505 ne devient pas origine parce qu’il était le dernier survivant d’un calcul ; il devient origine parce que l’opérateur accepte d’endosser le résumé. Cette responsabilité doit être reliée à la policy qui a généré la route et à la preuve locale des contributeurs.

Un ROA reste étroit : le détenteur du bloc autorise un AS à originer un ou plusieurs préfixes. Il ne valide pas les chemins retirés, l’adresse AGGREGATOR, le NEXT_HOP, la présence dans la FIB ou les paquets. Il faut aussi distinguer cet origin AS de l’attribut BGP ORIGIN, qui décrit comment l’information est entrée dans BGP et dont la valeur agrégée retient le cas le moins favorable.

Après AS_SET, la prévention des boucles devient une policy

AS_SET conservait des numéros capables de déclencher la détection ordinaire de boucle. Un AS contributeur retrouvant son propre numéro pouvait refuser le résumé. Une fois le set supprimé, cette protection ne se trouve plus dans le chemin.

RFC 9774 indique alors que l’agrégat ne devrait pas être annoncé aux AS contributeurs. Chacun reçoit plutôt les autres routes spécifiques pertinentes, à l’exclusion de celle apprise de lui. Cette règle exige une carte par peer et par direction. Si l’inventaire est faux, l’UPDATE comprimée ne possède plus assez de contexte pour corriger la policy.

Le plan de données impose un autre verrou. RFC 4632 exige que l’émetteur d’un agrégat rejette les paquets couverts par le résumé mais par aucune route spécifique atteignable. Une route null matérialise généralement cette règle. Elle évite qu’un paquet reparte par une default ou une route moins spécifique et revienne en boucle.

Cette route de rejet n’est pas un indicateur de disponibilité. Elle prouve une terminaison sûre. Dans notre incident, le paquet perdu montre à la fois que le garde-fou fonctionne et que 203.0.114.0/24 n’est plus servi. Réunir ces deux réalités sous une métrique « aggregate up » détruit l’information dont l’exploitation a besoin.

Conserver la preuve avant de la retirer du protocole

Le collecteur public sait montrer le /22, l’origin AS et les attributs arrivés jusqu’à lui. Il ne peut pas ressusciter un contributeur rejeté avant calcul ni les AS que l’avertissement déclare absents. L’observation doit donc commencer en amont de la compression.

Pour chaque résumé, le registre minimal contient les préfixes contributeurs, leurs peers, les chemins reçus avant policy, les chemins acceptés, la séquence commune calculée, l’origine choisie, le ROA, la version de policy et le speaker auteur. Il faut ensuite conserver Loc-RIB, Adj-RIB-Out avant et après policy, ATOMIC_AGGREGATE, AGGREGATOR ou AS4_AGGREGATOR, NEXT_HOP, ORIGIN, communities et état de suppression des spécifiques.

La chaîne se termine dans le forwarding. Vérifiez la route discard dans la RIB et dans le matériel. Sondez une adresse par contributeur actif et une adresse dans une zone volontairement non couverte. Un succès et un rejet attendu sont deux résultats sains mais différents ; l’outil ne doit jamais les additionner.

Quatre états méritent des alertes distinctes : contributeur présent ; contributeur absent avec résumé légitime ; résumé absent ; résumé présent sans discard. Le dernier associe une apparence de continuité à la perte du garde-fou de boucle.

Modifier tout le contrat, pas une commande

Une migration d’agrégation touche simultanément la NLRI, l’origine, la condition d’activation, l’avertissement de perte, l’attribution, les exports, la suppression des spécifiques, le ROA et le rejet de données. Elle doit être conçue et annulée comme un ensemble.

Le canary doit comporter un test positif et un test négatif. Une adresse d’un /24 actif doit être livrée. Après retrait contrôlé d’un contributeur de test, une adresse de ce composant doit finir localement dans le discard, jamais repartir chez un voisin. En parallèle, relevez exactement AS_PATH, ATOMIC_AGGREGATE, AGGREGATOR, état RPKI et annonces spécifiques.

Le rollback restaure import, suppression, génération du résumé, origine, ROA, filtres de sortie et discard. Remettre une ligne de configuration sans restaurer les routes dont dépend la livraison n’est pas un retour arrière.