Résumé

  • RFC 1997 impose à un locuteur conscient des communautés de ne pas annoncer une route NO_EXPORT au-delà de la frontière de confédération ; la valeur n'authentifie ni l'émetteur ni le préfixe.
  • La communauté réside dans un attribut optionnel transitif que la politique locale peut modifier. RFC 8642 a documenté des commandes apparemment similaires qui effaçaient ou conservaient différemment les valeurs bien connues.
  • La preuve doit suivre la route : attribut envoyé, reçu, transformé puis annoncé à chaque frontière, complété par les filtres de préfixes et de relations.

Prenons un préfixe plus spécifique annoncé sur une interconnexion privée. Son propriétaire veut que le voisin l'utilise à l'intérieur de son réseau, sans qu'il atteigne la table mondiale. Il ajoute NO_EXPORT. Cette action prouve seulement ce qui a quitté son propre routeur. La limite promise dépend encore de toute la chaîne du voisin.

RFC 1997 a créé COMMUNITIES pour regrouper des destinations partageant une propriété et simplifier la politique. L'attribut est optionnel, transitif et composé de valeurs de quatre octets. « Transitif » décrit le transport de l'attribut ; il ne transforme pas NO_EXPORT en permission d'exporter.

La règle est précise. Une route portant NO_EXPORT ne doit pas être annoncée hors d'une frontière de confédération. Un AS autonome constitue sa propre confédération pour cette règle. NO_ADVERTISE va plus loin : la route ne doit être annoncée à aucun autre pair BGP. NO_EXPORT_SUBCONFED bloque aussi les autres AS membres de la même confédération. Le registre IANA fixe les identifiants ; le RFC fixe le comportement.

Cette norme réduit le coût de coordination. L'émetteur n'a pas besoin de connaître la syntaxe Junos, IOS XR ou OpenBGPD du destinataire. Mais il n'obtient pas pour autant une commande distante. RFC 1997 permet au locuteur d'ajouter une communauté à une route reçue sans elle et de modifier les communautés selon sa politique locale.

L'ambiguïté est devenue opérationnelle. RFC 8642 a constaté que « set community » ne signifiait pas la même transformation partout. Certains logiciels remplaçaient toutes les communautés, y compris les valeurs bien connues. D'autres en préservaient certaines. OpenBGPD, dans le comportement documenté, ne supprimait pas les valeurs existantes. Deux configurations visuellement proches pouvaient donc produire des frontières opposées.

Un dépôt de configuration ne suffit pas. Une route-map peut ajouter une étiquette commerciale et effacer NO_EXPORT sans intention. Une famille IPv6 peut emprunter une autre chaîne de politique. Un changement sauvegardé peut ne pas être chargé par le processus actif. Le seul arbitre est l'annonce résultante.

RFC 8642 interdit aux nouvelles implémentations d'ajouter de nouvelles divergences. Il aide les opérateurs à survivre aux anciennes. Il ne normalise pas rétroactivement chaque version en production. Toute migration doit comparer les attributs avant et après, sur un préfixe contrôlé.

RFC 7454 formule une règle équilibrée. Un réseau devrait nettoyer les communautés de son propre espace que le voisin n'est pas autorisé à utiliser. Il devrait généralement préserver les autres communautés reçues et ne pas supprimer NO_EXPORT sans raison. Préserver aveuglément donnerait accès à des actions privées ; effacer aveuglément détruirait des limites légitimes.

La communauté ne signe pas son histoire. Elle ne prouve pas qui l'a ajoutée, que l'origine est autorisée ou que la relation commerciale exige son respect. RPKI peut apporter une preuve sur l'origine maximale autorisée ; il ne dit pas à quels pairs une route apprise peut ensuite être revendue. Ce sont deux objets de contrôle.

RFC 7908 définit une fuite comme une propagation au-delà de la portée voulue, souvent inscrite dans plusieurs politiques locales et relations bilatérales. Une fuite client-vers-fournisseur peut se produire sans aucun NO_EXPORT. Les filtres de préfixes, de cônes clients et de classes de voisins restent nécessaires.

RFC 9234 renforce autrement la frontière. Les deux pairs peuvent confirmer leurs rôles dans OPEN ; l'attribut Only to Customer porte ensuite un état de relation permettant de prévenir ou détecter certaines fuites. Le mécanisme corrige une faiblesse des étiquettes posées unilatéralement, sans contrôle de cohérence avec le voisin.

Même là, l'autorité reste distribuée. Le mode strict peut refuser une session si le rôle n'est pas confirmé, mais ce choix peut aussi couper une interconnexion après une mise à jour. Un AS en chemin peut retirer OTC volontairement. Le protocole rend l'accord plus explicite ; il ne crée ni police centrale ni preuve cryptographique universelle.

La vérification commence dans l'Adj-RIB-Out de l'émetteur : NLRI exact, famille d'adresses, pair, attributs avant et après politique. Elle continue dans la vue reçue brute du voisin puis dans son état post-politique. Elle se termine dans chaque annonce sortante susceptible de franchir la limite.

L'absence chez un collecteur public ne prouve rien à elle seule. Le collecteur ne voit que ses propres sessions. Il faut un préfixe canari, des pairs connus, plusieurs points d'observation ou des données bilatérales. Annoncer avec puis sans NO_EXPORT permet de vérifier la différence, le retrait et le nettoyage.

L'automatisation doit comparer les routes, pas seulement les fichiers. Elle peut refuser une version qui perd une communauté protégée, détecter un écart entre matrice de relations et Adj-RIB-Out, et expirer toute exception. En incident, le réseau qui émet l'annonce fautive doit garder un levier local : filtre explicite, retrait ciblé ou arrêt de l'export.

Le principe de spécification minimale de Heng Lu éclaire ce partage. Le standard commun fournit un vocabulaire court et une limite intelligible. Les décisions futures — exceptions, hiérarchie interne, preuve et tolérance à la panne — restent chez ceux qui en supportent le coût.

La primauté du code exécuté ferme le raisonnement. RFC et configuration décrivent l'intention ; la route reçue et l'UPDATE effectivement émis constituent le système. NO_EXPORT réussit lorsqu'une demande étroite devient un comportement observable sans transférer le contrôle du routeur. Son nom ne verrouille rien ; la responsabilité locale, elle, doit le faire.

Sources