Résumé

  • AS 0 n’est ni un numéro privé ni une valeur provisoire utilisable pour établir une identité BGP. Il est interdit dans OPEN, AS_PATH, AS4_PATH, AGGREGATOR et AS4_AGGREGATOR, alors que le code ORIGIN 0 signifie légitimement IGP.
  • Le refus est indexé sur le champ : couper une tentative de session qui revendique AS 0, traiter comme retirées les routes d’un UPDATE dont AS_PATH contient zéro, ou supprimer seulement l’attribut agrégateur ou de transition mal formé.

Une migration de configuration remplace temporairement une variable d’ASN absente par 0. Le contrôle de syntaxe en amont ne s’en aperçoit pas. Quelques secondes plus tard, trois équipes décrivent trois pannes différentes. La première voit une session qui ne monte plus. La deuxième voit des préfixes disparaître alors que TCP et BGP restent établis. La troisième conserve la route, mais l’attribut AGGREGATOR n’apparaît plus.

Elles ont toutes observé AS 0. Elles n’ont pas observé le même objet.

Cette divergence n’est pas une fantaisie de constructeurs. Le RFC 7607 codifie précisément le traitement de zéro selon l’endroit où il est transporté. La valeur reçue dans le champ d’AS du message OPEN invalide l’identité du pair. La même valeur, lue comme ASN dans AS_PATH, invalide les routes de l’UPDATE. Dans AGGREGATOR ou dans les attributs de transition à quatre octets, la procédure applicable supprime l’attribut et poursuit l’analyse du message.

Le pouvoir opérationnel n’est donc pas de « bloquer zéro » de la manière la plus brutale possible. Il est de préserver le champ, d’appliquer le refus minimal prescrit et de prouver qu’aucun état interdit n’a franchi la frontière suivante.

Un non-identifiant réservé

Le registre actuel des numéros de systèmes autonomes de l’IANA classe 0 comme Reserved et renvoie au RFC 7607. Le registre des ASN à usage spécial permet d’éviter une confusion fréquente. AS_TRANS 23456 sert à la transition vers les ASN à quatre octets. D’autres plages servent à la documentation ou à un usage privé. AS 0 ne constitue pas une solution de repli comparable.

Il ne peut pas signifier « inconnu », « à attribuer plus tard » ou « ne pas afficher ». Une application qui transforme une valeur absente en entier zéro a déjà pris une décision de protocole, même si son auteur pensait seulement satisfaire un type de données.

Le RFC 7607 nomme cinq emplacements. Un routeur ne doit pas initier une connexion en se présentant comme AS 0. Il ne doit ni créer ni propager une route contenant AS 0 dans AS_PATH, AS4_PATH, AGGREGATOR ou AS4_AGGREGATOR. Cette interdiction met à jour le cadre du RFC 4271, qui n’avait pas auparavant formulé clairement la réserve dans ces champs.

Un contrôle au commit est une première barrière. La documentation Junos sur les ASN à quatre octets indique, dans le périmètre décrit, que la configuration d’un numéro restreint comme zéro échoue. Cette protection ne dit rien d’un UPDATE reçu d’un autre logiciel, d’une ancienne version ou d’une chaîne de conversion défectueuse. L’implémentation doit encore reconnaître et traiter ce qui arrive sur le fil.

Le message OPEN refuse le voisin

OPEN est le premier message échangé après l’établissement de TCP. Son champ My Autonomous System indique l’AS de l’émetteur. Lorsque la valeur reçue est zéro, le RFC 7607 impose l’abandon de la connexion et l’envoi d’une NOTIFICATION OPEN Message Error avec le sous-code Bad Peer AS défini par le RFC 4271.

L’unité de panne est la tentative d’adjacence. Il n’existe pas encore de session BGP établie dont il faudrait préserver les autres routes. Une boucle de reconnexion peut néanmoins produire un coût : journaux, CPU, alarmes et instabilité opérationnelle. Les preuves minimales sont les deux extrémités, l’heure, le message OPEN reçu, la NOTIFICATION émise et la configuration qui a généré la revendication AS 0.

Autoriser temporairement le pair avec une option permissive ne corrige rien. Aucun opérateur ne détient AS 0 pour négocier une exception. Si la migration exige un ASN local transitoire, elle doit employer un numéro légitime pour le contexte et un plan explicite, pas le non-identifiant réservé.

AS_PATH refuse la route, pas toute la session

Quand zéro apparaît dans AS_PATH, le RFC 7607 qualifie l’UPDATE de mal formé et renvoie au RFC 7606. Pour AS_PATH, ce dernier choisit treat-as-withdraw. Toutes les destinations annoncées dans le message sont traitées comme si elles figuraient dans les retraits. Elles disparaissent de l’Adj-RIB-In selon les procédures BGP, tandis que la session et les autres routes valides peuvent rester en place.

Ce choix protège le service restant. L’ancien comportement général consistant à réinitialiser une session à la réception d’un attribut mal formé pouvait supprimer des centaines de milliers de routes sans rapport avec l’erreur. Maintenir la session n’est pas de la complaisance envers AS 0 ; c’est borner l’effet au reachability que l’on ne peut plus croire.

Une règle d’AS-path en bordure reste utile. La documentation de FRRouting fournit un exemple de filtrage d’ASN bogon qui recherche _0_. Elle ajoute une défense et une mesure de politique. Elle ne prouve pas à elle seule que l’analyseur a exécuté le traitement du RFC, ni qu’un autre champ contenant zéro a été examiné.

Le test post-correction doit montrer plus qu’une baisse du compteur. Il faut recevoir un nouvel AS_PATH sans zéro, vérifier que le préfixe réintègre l’Adj-RIB-In uniquement avec ce chemin défendable, puis constater sa sélection et sa diffusion selon la politique habituelle. Remplacer localement zéro par un ASN supposé fabriquerait une provenance qui n’a jamais été annoncée.

L’agrégateur perd l’attribut

AGGREGATOR raconte quel AS et quel routeur ont formé une route agrégée. AS 0 y est interdit, mais le RFC 7606 attribue aux erreurs d’AGGREGATOR le traitement attribute discard. L’attribut est supprimé ; le reste de l’UPDATE poursuit son parcours d’analyse.

Cette différence est essentielle. Une phrase comme « toute route qui contient AS 0 doit être retirée » est trop large. La route peut rester acceptable après suppression d’un AGGREGATOR mal formé, sous réserve des autres contrôles. Il faut cependant enregistrer la perte : l’information d’agrégation a disparu, et la source reste défectueuse.

Les attributs AS4_PATH et AS4_AGGREGATOR obéissent au RFC 6793, qui organise le passage entre speakers anciens et nouveaux pour les ASN à quatre octets. RFC 7607 rend zéro mal formé dans ces attributs et renvoie à leurs procédures. Dans les contextes prévus, l’attribut est écarté, l’erreur journalisée et l’UPDATE continue.

Il faut conserver les messages OPEN et les capacités négociées. AS4_PATH et AS4_AGGREGATOR ne devraient pas circuler entre deux speakers capables de quatre octets ; leur présence y déclenche déjà une suppression d’attribut. Sans savoir qui est OLD, qui est NEW et quelles capacités ont été échangées, un collecteur ne peut pas expliquer correctement la décision.

Le zéro valide qui démasque une mauvaise télémétrie

Le champ ORIGIN du RFC 4271 utilise aussi le nombre zéro. Ici, 0 signifie IGP, 1 EGP et 2 INCOMPLETE. ORIGIN 0 est une valeur normale ; ce n’est pas l’Autonomous System 0.

Cette collision fournit un test simple à toute plateforme d’observation. Si une recherche zero mélange ORIGIN, ASN, métrique, compteur et préfixe par défaut, elle n’est pas assez précise pour piloter un incident. Si l’équipe ajoute ensuite une exclusion générale afin de réduire le bruit, elle peut masquer l’AS_PATH réellement interdit.

Le journal utile conserve le type de message, le code d’attribut, la valeur brute ou une représentation sans perte, la direction, le pair, l’AFI/SAFI, les capacités et l’horodatage. Le libellé destiné à l’humain vient après. La normalisation ne doit jamais détruire la possibilité de revenir au champ.

Un ROA AS 0 n’est pas une route AS 0

Le RFC 6482 définit le ROA comme un objet signé associant un asID à des préfixes. Le RFC 6483 décrit le cas AS 0 : le détenteur d’un préfixe déclare que ce préfixe et ses plus-spécifiques ne devraient pas être employés dans le routage.

Ce mécanisme n’accorde pas à AS 0 le droit d’originer une route. Le RFC 6907 l’exprime directement : aucune route valide ne peut avoir ASN 0 comme origine, donc aucune route ne peut correspondre à un ROA AS 0. Une annonce issue d’un AS réel peut devenir Invalid face à ce ROA si aucun autre ROA candidat ne valide son origine et sa longueur.

Le résultat n’est pourtant pas une interdiction absolue portée par l’objet zéro. Un ROA AS 0 peut coexister avec un ROA pour un AS routable. Si ce dernier correspond au préfixe, à la longueur et à l’origine, la route est Valid. La présence du ROA AS 0 ne renverse pas cette autorisation positive.

Les chronologies restent distinctes. L’UPDATE arrive sur une session et reçoit immédiatement un traitement local. Le ROA traverse une publication RPKI, une chaîne de certificats, des collecteurs et des caches de relying parties. Corriger l’un ne garantit pas que l’autre a convergé. L’enquête doit tenir deux registres : paquets et RIB d’un côté, objets RPKI et état des caches de l’autre.

Une preuve de bout en bout de la décision

BMP, défini par le RFC 7854, peut fournir les UPDATE reçus et l’Adj-RIB-In avant et après politique. L’état pré-policy prouve qu’un voisin a envoyé le champ. L’état post-policy montre ce que le routeur a conservé après traitement. Leur comparaison distingue l’émission fautive de son admission locale.

Le RFC 9069 ajoute la visibilité Loc-RIB. Elle montre les routes retenues par le Decision Process, pas encore la livraison des paquets. Pour attribuer une panne de service, il faut encore examiner FIB, next hop et tests de trafic.

Le RFC 8671 étend BMP à l’Adj-RIB-Out avant et après politique. Il devient alors possible de tester l’interdiction de propagation sur chaque frontière matérielle. L’absence chez un collecteur ne prouve pas l’absence mondiale, mais l’ensemble nommé des sorties critiques peut être vérifié.

L’ordre de preuve est stable : message exact ; contexte de pair et de capacité ; action prescrite ; différence pré/post-policy ; Loc-RIB ; FIB si nécessaire ; Adj-RIB-Out ; correction à la source ; nouvelle observation propre. Le RFC 7454 fournit le cadre général de filtrage aux frontières. RFC 7607 fournit ici la décision spécifique au champ.

Sources