Résumé

  • RFC 8092 offre trois champs de 32 bits, souvent lus comme ASN:Fonction:Paramètre. Le premier désigne un espace de noms ; il ne signe pas le triplet et ne prouve pas que le voisin est habilité à demander l’action.
  • La preuve complète relie les octets reçus, l’identité et la classe du voisin, la version du dictionnaire, la règle appliquée, les RIB d’entrée et de sortie, la FIB et le résultat observé sur les paquets.
  • Une exploitation sûre sépare information et commande, filtre l’usage non autorisé de son propre espace, conserve le contexte étranger utile, teste les migrations mixtes et prévoit une réévaluation explicite lors du retour arrière.

Le catalogue public n’est pas une liste de mandats

Prenons un opérateur fictif qui publie deux Large Communities. La première indique le point d’entrée d’une route. La seconde demande de réduire la préférence locale dans une région. Un client multihomé attache la seconde à son préfixe afin de détourner le trafic d’un lien saturé.

Sur un premier réseau, la chaîne est cohérente. Le routeur reçoit le triplet du client contractuellement autorisé, vérifie que cette classe de session peut appeler cette fonction et que le paramètre régional est admis. La trace de politique montre la baisse de LOCAL_PREF. Le Loc-RIB sélectionne l’alternative, l’Adj-RIB-Out confirme l’export prévu et les mesures de paquets constatent le déplacement.

Sur un deuxième réseau, le même triplet disparaît dans un ancien modèle d’import avant d’atteindre la politique commune. La session reste Established, le compteur de préfixes ne bouge presque pas et la route demeure joignable ; la commande n’a simplement jamais existé pour le moteur de décision.

Sur un troisième, la valeur est reconnue mais la permission n’est pas contrôlée. Toute session qui présente l’espace de noms du fournisseur peut déclencher la baisse de préférence. Un pair, ou le client d’un client, n’a pas besoin de falsifier le format : il lui suffit d’émettre douze octets valides que la politique traite comme une capacité.

Les trois situations utilisent la même syntaxe. Leur différence appartient à la relation entre représentation, principal, permission, interprétation et effet. Dire « nous supportons les Large Communities » ne décrit aucune de ces frontières.

Pourquoi il fallait douze octets

La Community de RFC 1997 tient sur quatre octets. Les opérateurs ont souvent utilisé les seize bits de poids fort comme numéro d’AS et les seize autres comme valeur locale. Ce partage a produit un vocabulaire pratique, mais il ne peut loger un ASN sur quatre octets dans sa moitié supérieure.

Les Extended Communities ont ajouté un type et huit octets. RFC 5668 définit bien une forme propre aux ASN sur quatre octets, mais elle réserve quatre octets au Global Administrator et seulement deux au Local Administrator. Elle répond à des usages typés sans permettre deux valeurs locales de pleine largeur.

RFC 8092 choisit une structure plus simple : quatre octets de Global Administrator, puis deux blocs de quatre octets de données locales. IANA lui attribue le type d’attribut 32. RFC 8195 propose la lecture opérationnelle ASN:Fonction:Paramètre, sans imposer un dictionnaire mondial des fonctions.

Cette liberté est précisément l’intérêt du mécanisme. Un réseau peut coder un site d’entrée, une classe de relation, un choix d’export ou un nombre de prepend. Mais le protocole ne sait pas si la fonction 9 signifie « information » ou « modifie immédiatement LOCAL_PREF ». Le sens exécutable naît dans la configuration du destinataire.

Propriétaire du nom, auteur de la valeur et principal autorisé

RFC 8092 recommande qu’un ASN occupe le Global Administrator. Lorsque c’est le cas, le détenteur de l’ASN définit l’interprétation des deux champs suivants. Il possède un espace de définition ; il n’est pas pour autant l’auteur authentifié de chaque occurrence de cette valeur sur Internet.

Voir 64497:9:3 ne prouve donc pas que l’AS 64497 l’a ajouté. Cela ne prouve pas non plus que le voisin immédiat pouvait invoquer la fonction 9, qu’aucun intermédiaire n’a modifié le triplet ou que le paramètre 3 conserve le sens publié hier. Le document prévoit qu’un AS intermédiaire puisse ajouter, supprimer ou changer des Large Communities et précise l’absence de protection d’intégrité.

Même les valeurs réservées n’offrent pas un raccourci. Les ASN 0, 65535 et 4294967295 sont déconseillés comme Global Administrator, mais leur présence ne rend pas à elle seule l’attribut mal formé. Le parseur décide si la longueur et l’encodage sont recevables. La politique d’autorisation décide si cette relation peut causer cet effet. Mélanger ces décisions détruit la piste de preuve.

Une protection de session peut identifier le pair du saut courant. Elle ne certifie pas l’auteur initial d’un attribut transitif. De même, la validation d’origine RPKI lie un préfixe à un AS d’origine autorisé selon les ROA disponibles ; elle ne confère aucun droit d’écrire une instruction dans la politique interne d’un autre opérateur.

Le même conteneur transporte des faits et des commandes

RFC 8195 distingue les usages informatifs des usages d’action. Un marquage informatif peut décrire le point d’entrée, le type de relation ou l’audience souhaitée. Une valeur d’action réclame une modification : préférence, next-hop, propagation ou prépends AS_PATH.

Le fil ne porte pas cette classification. Un triplet devient informatif ou exécutable à travers le dictionnaire et la règle qui le consomme. Si deux plateformes chargent des versions différentes, une donnée de diagnostic peut devenir une commande sur l’une, tandis qu’une commande publiée reste inerte sur l’autre.

Le dictionnaire doit donc réserver des plages distinctes et, pour chaque action, nommer un propriétaire, les classes d’émetteurs admises, le domaine du paramètre, les conflits, les familles d’adresses, la durée de validité et le retour arrière. « Réduire la préférence en Europe » ne doit pas devenir « réduire partout » parce qu’une ancienne plateforme ignore le paramètre. Une fonction contractuelle réservée aux clients directs ne doit pas être héritée par tous les peer-groups qui partagent un fragment de configuration.

Publier le dictionnaire, comme le recommande RFC 8195, rend la coordination possible. Ce n’est que la couche de spécification. La version réellement chargée, la route reçue, la clause qui a matché et l’effet de forwarding forment la couche d’exécution.

Nettoyer ses commandes sans effacer le contexte d’autrui

RFC 7454 pose une limite utile : à l’entrée, un opérateur devrait retirer les communities utilisant son propre numéro, sauf celles que ce voisin est autorisé à envoyer. Il ne devrait pas supprimer indistinctement les valeurs étrangères, dont un client peut avoir besoin pour communiquer avec un réseau plus lointain.

Pour les Large Communities, une politique sérieuse sépare au moins quatre ensembles : les actions de l’espace local autorisées pour ce voisin ; les informations locales acceptées ou ajoutées selon un contrat ; les valeurs étrangères opaques à préserver ; et les valeurs interdites parce qu’elles sont obsolètes, impossibles dans cette relation ou dangereuses en combinaison.

Tout préserver permet à un tiers de fabriquer une commande appartenant au fournisseur si la règle ne vérifie que le triplet. Tout effacer casse les signaux destinés à l’aval. Remplacer la totalité du set pour ajouter une marque locale peut également détruire la provenance antérieure. L’ajout conservateur protège cette histoire, mais il faut ensuite retirer les valeurs périmées et résoudre les contradictions.

Le route server constitue un cas particulier assumé. RFC 7948 décrit un service où les clients contrôlent parfois l’export par destinataire. RFC 8195 donne des exemples d’annonce à tous, à personne ou avec exceptions. L’influence du client est ici le produit vendu, pas une intrusion. Le route server doit néanmoins lier la fonction à la session cliente, résoudre les conflits et prouver l’Adj-RIB-Out de chaque destinataire. Cette exception ne doit pas migrer silencieusement vers un modèle de transit ordinaire.

Un ensemble n’a pas de première instruction

Une Large Community est un élément d’un ensemble non ordonné. RFC 8092 retire toute signification à l’ordre d’encodage. Une politique « la première gagne » fabrique donc une priorité à partir d’un accident d’implémentation.

Les doublons ne doivent pas être émis et sont éliminés silencieusement à la réception. Deux occurrences identiques ne prouvent ni deux votes ni deux auteurs. Après normalisation, une seule demeure. Il faut aussi distinguer « contient ce triplet » de « l’ensemble entier est exactement celui-ci », ainsi que match-any de match-every. Les fonctions documentées par Cisco IOS XR et la lecture exacte ou JSON disponible dans FRRouting permettent de vérifier ces choix ; elles ne décident pas lesquels sont sûrs.

L’agrégation ajoute une ambiguïté. RFC 8092 demande que l’agrégat porte l’union des valeurs de ses contributeurs. L’information est conservée, mais l’union ne signifie pas unanimité. Si un more-specific demandait un backup régional et un autre un export sélectif, l’agrégat peut hériter des deux. Une politique doit préciser quelles actions survivent à l’agrégation et conserver la preuve des contributeurs.

Mal formé n’est pas synonyme de non autorisé

La validité d’encodage possède une règle nette : la longueur de la valeur doit être un multiple non nul de douze octets. Dans le cas contraire, RFC 8092 renvoie au treat-as-withdraw de RFC 7606.

Cette réponse évite de réinitialiser toute la session, mais peut se cacher derrière une télémétrie rassurante. Les KEEPALIVE continuent, le pair reste Established et les autres routes survivent, tandis que les NLRI concernées disparaissent. Il faut corréler l’erreur brute, la variation de l’Adj-RIB-In et l’impact de service.

Un triplet correctement encodé mais envoyé sans droit doit, lui, atteindre la décision d’autorisation et produire un résultat explicable. Le contrat peut imposer de retirer l’action et garder la route, de rejeter la route ou de la mettre en quarantaine. Le qualifier de « malformed » masque si l’échec vient du parseur, du dictionnaire ou du principal.

Migrer, c’est changer un programme distribué

Passer d’une Community classique à une Large Community ne consiste pas à agrandir un champ. Les producteurs, imports de bordure, route reflectors, route servers, collecteurs, documentation client et outils d’incident doivent partager la même époque de politique.

Le double marquage aide pendant la coexistence. Il peut aussi exécuter deux fois une action ou exécuter deux sens différents si les catalogues ont divergé. Un routeur ancien qui préserve la Community et efface la Large Community paraîtra compatible jusqu’au retrait du signal historique. Un collecteur qui archive le nouveau triplet prouve le transport, pas l’adoption par le moteur de décision.

Le canari doit utiliser un préfixe dont le résultat est sûr et mesurable. Il faut enregistrer les deux ensembles reçus, l’ensemble normalisé après nettoyage, la version exacte de règle, le changement d’attribut, chaque Adj-RIB-Out concerné, le meilleur chemin, le next-hop installé et le comportement des paquets. Un émetteur non autorisé doit être testé autant qu’un client autorisé. La longueur mal formée se teste en laboratoire. L’agrégation se teste si le service en produit.

Le rollback doit traiter l’état. Supprimer la nouvelle règle peut laisser un chemin choisi sous l’ancien LOCAL_PREF tant qu’une réévaluation n’a pas eu lieu. Un route refresh reconstruit la vue mais a une portée et un coût ; un hard reset impose une convergence plus large. Dans un BGP wedgie au sens de RFC 4264, une configuration apparemment réparée peut conserver un équilibre stable mais indésirable, et exiger une action coordonnée.

Le registre de preuve

Pour chaque route, le journal devrait conserver le pair, sa classe, le préfixe, AFI/SAFI, l’époque de session, l’ensemble brut, l’ensemble normalisé, les valeurs retirées et ajoutées, la version de dictionnaire, le résultat d’autorisation, la clause exécutée et les attributs produits. À cela s’ajoutent la raison du choix Loc-RIB, les Adj-RIB-Out par classe, le next-hop FIB et des sondes de paquets.

Ce registre répond séparément : le triplet a-t-il été transporté ? était-il bien formé ? l’émetteur était-il autorisé ? quel sens avait-il sous cette version ? la règle a-t-elle agi ? le service a-t-il changé ? le sens a-t-il survécu vers l’aval ?

Un collecteur public n’offre qu’un point de vue sur la dernière question. Il ne reconstitue pas toutes les transformations, ne signe pas le premier auteur et ne voit pas une action confinée à un autre AS. Une absence peut venir d’un nettoyage, d’une sélection, d’une agrégation ou d’une exportation différente.

Sources