Résumé

  • La classe optionnelle transitive permet à une extension BGP de traverser des équipements qui n’en connaissent pas la sémantique. Si un locuteur accepte puis retransmet le chemin, il conserve l’attribut et active Partial ; un AS ultérieur ne peut plus effacer cette trace.
  • Partial est une cicatrice épistémique, pas un mécanisme d’intégrité. Il ne désigne pas le saut ignorant, n’authentifie pas l’origine, ne valide pas la valeur et ne prouve ni support universel ni consentement politique.
  • Avec RFC 7606, un défaut peut conduire à jeter l’attribut ou à traiter les routes comme retirées tout en gardant la session. L’exploitation doit donc corréler octets reçus et émis, action d’erreur, RIB et paquets, au lieu de s’arrêter à l’état du voisin.

À 2 h 10, un opérateur teste un nouvel attribut de politique entre deux sites contrôlés. Le routeur d’origine exécute la nouvelle version. Le transit intermédiaire ne reconnaît pas le code. Le bord destinataire vient d’être mis à jour et sait l’interpréter.

Le premier UPDATE est correctement encadré : drapeaux, type, longueur, valeur et préfixe IPv4. Le transit sait où commence et finit l’objet, mais ne possède aucun décodeur pour sa valeur. Optional et Transitive étant activés, il accepte le chemin, préserve les octets, met Partial à 1 et annonce la route au destinataire.

Celui-ci reconnaît le type. Son décodeur constate une violation de la grammaire propre à l’attribut. L’action prévue est treat-as-withdraw : la route sort de l’Adj-RIB-In, mais TCP reste établi et les KEEPALIVE continuent. Le transit conserve encore le préfixe. Seul le chemin client en aval disparaît.

La scène est construite, pas la frontière d’autorité. BGP a volontairement prévu qu’une information future traverse des locuteurs plus anciens. Sans cela, chaque extension exigerait une mise à niveau coordonnée de la chaîne. En contrepartie, un routeur peut transporter loyalement une sémantique qu’il est incapable de contrôler, et une simple mise à jour logicielle peut transformer un objet longtemps opaque en motif de retrait.

Quatre bits, quatre promesses distinctes

Les quatre bits supérieurs de l’octet Attribute Flags n’expriment pas la même chose. Optional sépare une extension d’un attribut well-known que toutes les implémentations doivent reconnaître. Transitive indique si un attribut optionnel inconnu peut franchir une frontière BGP. Partial qualifie l’information d’un attribut optionnel transitif comme incomplète. Extended Length choisit un champ de longueur sur un ou deux octets. Les quatre bits inférieurs sont réservés : zéro à l’émission, ignorés à la réception.

Un attribut well-known doit être compris. Son bit Transitive est actif, mais Partial doit rester nul. Un attribut optionnel non transitif peut être utile entre locuteurs équipés ; un récepteur ignorant le supprime silencieusement et ne le transmet pas. Là encore, Partial vaut zéro.

L’exception qui rend l’évolution graduelle possible est l’attribut optionnel transitif. RFC 4271 n’attend pas de chaque implémentation qu’elle connaisse toutes les extensions. Un chemin portant un tel attribut inconnu devrait être accepté. S’il est ensuite annoncé, l’attribut doit l’accompagner et Partial doit passer à 1.

La promesse reste limitée : garde des octets, pas compréhension. Le routeur lit le type, les drapeaux et la longueur ; il peut conserver la valeur opaque. Il ne sait pas si celle-ci est autorisée par un contrat, authentique, cohérente avec sa spécification interne ou sans danger pour un futur parseur.

Extended Length ne certifie rien de plus. Il change seulement la taille du champ qui annonce la longueur. Une valeur peut être parfaitement délimitée et pourtant malformée selon sa grammaire interne. Le locuteur ancien la propage précisément parce qu’il ne possède pas le code qui révélerait le défaut.

Partial n’est pas une note de confiance

Le mot incite à lire « endommagé », « non vérifié » ou « peu fiable ». La définition est à la fois plus étroite et plus utile. Quand un locuteur ignorant retransmet l’attribut, il active Partial. Si un locuteur ultérieur le reconnaît et reçoit déjà ce bit à 1, il ne doit pas le remettre à zéro. Un locuteur qui n’est pas l’origine et ajoute un nouvel attribut optionnel transitif l’active également.

La marque indique donc qu’on ne peut pas supposer une garde sémantique complète de bout en bout. Elle ne dit pas quel AS ignorait le type, ne fournit aucune chronologie de reconnaissance, ne révèle pas si une modification permise a eu lieu et ne prouve pas que l’émetteur avait le droit d’ajouter l’objet.

Surtout, Partial n’est pas authentifié. Il reste un bit dans un UPDATE, soumis à la confiance de la session et de la chaîne opérationnelle. Il ne remplace ni validation d’origine, ni politique de relation, ni protection du transport, ni provenance de configuration, ni observation des paquets.

Sa vertu est de ne pas prétendre davantage. Il conserve l’aveu qu’une frontière sans maîtrise sémantique complète a été franchie. Cet aveu justifie une enquête et une politique ciblée, pas une acceptation automatique ni un rejet universel.

Une mise à niveau déplace la frontière de reconnaissance

« Inconnu » n’est pas une propriété durable du code ; elle dépend de l’implémentation, de la version, de l’AFI/SAFI et des fonctions actives. Les mêmes octets peuvent être opaques le mardi et analysés le mercredi.

Tant que le type est inconnu, le routeur peut le conserver sans vérifier l’intérieur. Une fois reconnu, il applique la spécification particulière : drapeaux permis, longueur, sous-structures, sémantique et action d’erreur. Une valeur propagée depuis des mois peut alors déclencher un discard ou un treat-as-withdraw au premier décodeur, ou sur un équipement qui vient d’acquérir ce décodeur.

Ce changement n’est pas forcément une régression. La nouvelle version est peut-être la première à détecter une véritable malformation. Le transit ignorant n’a pas nécessairement fauté non plus. L’incident naît de l’interaction entre déploiement asynchrone, transport opaque et activation tardive d’une frontière sémantique.

Une recette de mise à niveau doit donc inventorier les routes qui portent des attributs inconnus. Avant le changement : code, drapeaux, longueur, empreinte de la valeur, voisin, famille, NLRI concernés et état de Partial. Après : quels codes sont devenus connus, quelles validations s’exécutent, quelle action en découle et quelles routes ont changé.

Sans ce relevé, une perte de route sera classée « bug logiciel ». Avec lui, on distingue un défaut du parseur, un rejet légitime, une politique de confinement trop large ou un émetteur qui viole le contrat de l’attribut.

Réduire le rayon d’impact ne supprime pas l’incident

Le modèle initial de BGP-4 pouvait fermer une session entière pour un seul attribut malformé, supprimant aussi les routes valides sans rapport. Le cas optionnel transitif était particulièrement dangereux : plusieurs routeurs ignorants pouvaient amplifier une valeur jamais contrôlée jusqu’aux implémentations qui la comprenaient.

RFC 7606 distingue notamment trois actions. Le reset de session reste la plus forte. Treat-as-withdraw retire de l’Adj-RIB-In les routes de l’UPDATE fautif tout en conservant la session. Attribute discard enlève l’attribut malformé et poursuit le traitement.

Ce n’est pas une simple échelle de gravité. Jeter l’attribut peut être plus trompeur qu’un retrait : la route demeure, mais la sémantique censée influencer sélection ou installation disparaît. Le discard ne convient donc qu’à un attribut sans effet sur ces décisions, sauf analyse spécifique convaincante.

Treat-as-withdraw rend le défaut visible sous forme de perte de route, mais le masque aux outils centrés sur la session. Le voisin est Established, les temporisateurs sont sains, les KEEPALIVE circulent. Rien de cela ne prouve que le NLRI subsiste. Une salle d’exploitation entièrement verte peut accompagner une panne client.

Lorsque Optional ou Transitive contredit la définition d’un attribut reconnu, RFC 7606 prescrit en général treat-as-withdraw, sauf règle propre à l’attribut. Un doublon de MP_REACH_NLRI ou MP_UNREACH_NLRI déclenche treat-as-withdraw pour toutes les routes de l’UPDATE tout en préservant la session ; pour la plupart des autres doublons, seule la première occurrence est gardée. Si plusieurs erreurs coexistent, l’action la plus forte s’impose.

Dire qu’un produit « prend en charge RFC 7606 » ne suffit donc pas. Il faut connaître la classification réellement appliquée, la règle de l’attribut et le nouvel ensemble de routes. Une implémentation peut préserver correctement la session tout en provoquant une panne importante.

Le réseau local conserve son pouvoir de confinement

La règle de propagation protège l’extensibilité ; elle n’oblige pas un opérateur à laisser tout code inconnu traverser chaque frontière de production. Il peut exiger des preuves sur la provenance, le coût et l’effet en aval avant d’autoriser un passage.

La documentation Juniper actuelle expose deux choix très différents : retirer l’attribut inconnu tout en gardant la route, ou retirer les routes qui le portent. Des exceptions par code sont possibles, avec une portée globale, par groupe ou par voisin. Les vues de voisin indiquent ensuite les attributs supprimés et ceux qui ont causé un retrait.

Ce sont des commandes locales, pas une loi universelle. Supprimer l’attribut peut préserver les paquets en effaçant une sémantique nécessaire au service. Retirer toutes les routes portant un code nouveau peut transformer une adoption progressive en panne. Une exception trop large peut, elle, restaurer le risque initial.

La bonne question n’est pas « autoriser les attributs inconnus ? », mais « quel code traverse quelle relation et quelle famille, après quelle preuve, avec quelle action en cas de doute ? ». Client, route server, réflecteur interne, pair et laboratoire n’appellent pas la même réponse.

La documentation Cisco NX-OS montre la granularité d’observation nécessaire : liste des préfixes portant un attribut inconnu ou supprimé, puis drapeaux, type, longueur et valeur pour une route. Un compteur global ne sépare pas une extension bénigne d’un objet anormal attaché à des centaines de milliers de préfixes.

Transporter, ce n’est pas consentir

Le routeur ignorant qui conserve l’attribut n’adhère pas à son sens ; il exécute une obligation de transport d’information. Confondre ces deux actes produit de mauvaises conclusions commerciales.

Si l’attribut prétend exprimer une classe de service, un AS de transit qui ne le connaît pas n’est pas réputé fournir le service, valider l’éligibilité du client ou accepter la responsabilité associée. Partial ne transforme pas le portage en consentement. Chaque réseau aval garde sa politique et son contrat.

Même prudence en sécurité : inconnu ne signifie pas hostile, attribué par l’IANA ne signifie pas sûr. Le registre stabilise une identité de code. Il ne prouve ni la conformité de l’émetteur ni l’absence de défaut de ressources, de parsing ou de logique chez le récepteur.

La souveraineté pratique des données se joue aussi ici. Un réseau qui ignore la signification privée des octets décide néanmoins s’ils entrent dans les journaux, franchissent un tenant, quittent le domaine, déclenchent une action ou restent disponibles pour l’enquête. Opaque ne veut pas dire sans gardien.

La preuve doit garder une empreinte des octets reçus et émis, pas uniquement l’affichage CLI. Une interface peut normaliser les drapeaux, tronquer les valeurs ou omettre l’attribut dans une vue sommaire. L’UPDATE brut et les Adj-RIB pré- et post-politique montrent ensemble si le système a préservé, modifié ou supprimé l’objet.

Le canari doit rendre l’ignorance observable

Il ne faut pas inventer un code au hasard dans la table publique. L’essai appartient au laboratoire, à une relation bilatérale contrôlée ou au cadre d’allocation de l’extension réelle : peu de préfixes, code connu, politique réversible et sondes de trafic indépendantes.

Quatre étapes doivent être enregistrées : l’UPDATE d’origine avec ses octets exacts ; le saut ignorant avec Partial avant et après et l’annonce sortante ; le saut connaissant avec version du décodeur, validation, action et Adj-RIB-In ; enfin le plan de données avec route choisie, FIB et sondes.

Tester une valeur valide, une valeur bien encadrée mais sémantiquement invalide, puis un témoin inconnu non transitif. La première doit produire l’effet documenté, la deuxième l’action d’erreur prévue, la troisième s’arrêter au locuteur ignorant. On vérifie ainsi la classification, pas seulement la présence.

Puis il faut déplacer le temps : mettre à niveau le saut auparavant ignorant et rejouer le même UPDATE. Un résultat différent peut être correct. Cette répétition révèle le vrai risque de production : la reconnaissance déplace la frontière de validation.

Le retour arrière exige deux leviers autonomes : corriger ou enlever l’attribut à la source ; contenir le type à la frontière sans réinitialiser les sessions sans rapport. Si l’un d’eux nécessite un correctif logiciel d’urgence, le canari n’est pas prêt.

La primauté du code en fonctionnement prend ici une forme littérale. La norme offre le mécanisme ; la chaîne déployée décide si les octets survivent et si la route reste utilisable. La preuve est l’UPDATE capturé, la transition de Partial, l’action locale, le RIB et le paquet livré.