Résumé

  • L’IESG a approuvé le 22 juin 2026 un texte de Best Current Practice interdisant de signaler des états de validation dérivés de la RPKI dans des attributs BGP transportés par EBGP au-delà d’une frontière administrative. La révision 12 est en file chez le RFC Editor.
  • Un état est le produit d’une vue locale, non une attestation portable. L’inscrire dans un attribut non signé n’en transmet pas la chaîne de preuve, mais transforme les variations de ROA, de cache ou de session RTR en mises à jour BGP potentiellement massives.

La preuve absente de l’attribut

RFC 6811 demande au routeur de comparer le préfixe et l’AS d’origine d’une route avec les VRP présents dans son stockage local. Le résultat prend l’une des valeurs NotFound, Valid ou Invalid. Le texte qualifie expressément cet état de propriété locale de la route.

Ce résultat dépend d’un inventaire précis : objets signés récupérés, validation réussie, instant du dernier rafraîchissement, fonctionnement de la session RPKI-to-Router et politique appliquée ensuite. Deux domaines peuvent donc avoir, pendant un intervalle, deux vues différentes sans que l’un d’eux mente.

Une communauté qui dit Valid ne contient aucun de ces éléments. Elle ne révèle ni les VRP utilisés, ni leur fraîcheur, ni l’ancre de confiance, ni l’état du cache. Le voisin ne peut pas reproduire la décision à partir de ce qu’il reçoit.

Le nouveau document ajoute une limite d’authenticité. Les attributs BGP ordinaires qui circulent par EBGP ne sont pas signés ; un tiers peut ajouter ou modifier l’état prétendu. La présence du mot dans une annonce ne prouve donc ni son auteur, ni sa date, ni sa conformité à la vue du destinataire.

Une règle intérieure devenue fuite extérieure

RFC 8097 avait défini une Extended Community non transitive pour partager l’état de validation à l’intérieur d’un AS. L’objectif était opérationnel : des locuteurs IBGP pouvaient utiliser un calcul effectué ailleurs dans le même domaine de confiance.

Par défaut, une implémentation doit supprimer cette communauté lorsqu’elle la reçoit d’un pair EBGP et ne devrait pas l’envoyer à un pair EBGP. Le RFC prévoit une configuration exceptionnelle lorsque deux AS adjacents relèvent de la même administration. La frontière utile est donc la responsabilité commune, pas la seule différence entre IBGP et EBGP.

La recommandation approuvée généralise cette discipline. Elle vise les communautés standard, étendues ou larges, les valeurs propres aux opérateurs et tout attribut actuel ou futur dont la modification provoque l’envoi d’UPDATE vers un domaine externe. La même logique vaut si un opérateur tente d’exporter des résultats locaux issus d’ASPA ou de BGPsec.

Un équipement peut encore imposer un attribut entre locuteurs internes. Dans ce cas, l’opérateur doit prouver qu’il est retiré avant l’annonce du NLRI à l’extérieur. Une contrainte d’implémentation n’est pas une délégation de confiance aux voisins.

Un incident de cache facturé au plan de contrôle

Le scénario le plus parlant du document met AS65536 derrière AS65537. Les deux réseaux interrogent le même service RTR selon un cycle de 300 secondes et annotent leurs routes selon l’état obtenu. Il s’agit d’un exemple analytique, non d’une panne observée.

AS65536 rafraîchit ses données une seconde avant l’arrêt du service. AS65537 devait les rafraîchir une seconde après. Le fournisseur perd donc sa vue le premier, modifie ses communautés et envoie un flot d’UPDATE à ses clients. AS65536 reçoit et propage ce flot.

Environ 300 secondes plus tard, la vue d’AS65536 expire à son tour. Ses propres communautés changent et une deuxième vague part. Une durée de cache plus longue déplace les vagues ; si l’interruption dépasse cette durée, elle ne supprime pas leur séparation.

Le préfixe n’a pas changé d’origine. La connectivité n’a pas nécessairement changé. C’est la dépendance de validation qui a échoué. Pourtant, parce que le résultat local était devenu une composante de la route externe, le coût apparaît sur les processeurs, la mémoire et les files BGP de nombreux voisins.

L’échelle rend le couplage visible

Le document cite une observation de février 2024 : entre 8 % et 10 % des messages BGP UPDATE vus par le Routing Information Service portaient des communautés publiques indiquant NotFound ou Valid. La création ou la suppression d’un objet ROA a également produit une chaîne de mises à jour durant environ une heure. Cette mesure est datée et ne constitue pas une proportion permanente.

Pour le milieu de 2026, le texte utilise une table IPv4 et IPv6 d’environ 1,3 million de préfixes, dont près de 65 % couverts par des ROA. La perte d’un cache peut ainsi obliger à renvoyer plus de 850 000 routes si les états sont intégrés aux attributs externes.

Le chiffre décrit un mécanisme de multiplication. Une modification de ROA devrait conduire chaque réseau concerné à recalculer sa politique locale. Une interruption RTR devrait être traitée comme un incident de service de validation. Le transport de l’état oblige en plus les voisins à traiter des remplacements de route alors que le fait de joignabilité peut être identique.

Le mécanisme peut être sollicité volontairement. Un acteur capable d’émettre et de retirer des objets signés pour ses préfixes peut provoquer des bascules répétées. Celui qui réannonce un NLRI peut aussi altérer un attribut non signé. Lier l’identité externe d’un chemin à ces états offre donc un levier de churn.

La décision doit rester là où se trouve la vue

Un réseau qui valide et rejette réellement les routes Invalid ne devrait jamais les annoncer à ses clients. L’ensemble exporté porte déjà l’effet de sa politique. Ajouter une étiquette ne fournit pas au client une assurance supplémentaire vérifiable.

Le destinataire qui a besoin d’une décision RPKI doit utiliser sa propre vue actuelle. C’est la seule manière de connaître les objets, la fraîcheur et la politique sur lesquels il engage sa responsabilité. L’étiquette du voisin peut décrire un état interne ; elle ne peut pas devenir une permission externe.

La séparation recommandée est donc nette : acquérir et valider les données localement, décider localement, conserver tout attribut de partage dans le domaine administratif, puis l’effacer à chaque bord externe. La route qui a survécu à la politique peut sortir. Le commentaire non authentifié sur les raisons de cette politique reste dedans.

Sources