Résumé

  • À APNIC 62, le 9 septembre, Maria Matejka a signalé un traitement trop brutal des routes OTC invalides dans BIRD. Les versions 2.20.0 et 3.4.0 étaient annoncées comme destinations attendues du correctif, non comme versions déjà livrées.
  • Dans le code examiné de BIRD 2.19.2, certaines violations OTC liées au rôle de la session deviennent des retraits avant la création de l’objet de route habituel. Le message de journalisation et la route consultable ne sont pas le même produit.
  • L’interdiction de sélection doit rester entière. Une trace diagnostique séparée ne doit ni installer la route dans la Loc-RIB active, ni lui permettre de repartir vers un voisin.

Une route refusée peut laisser un message sans laisser le dossier dont l’exploitant a besoin. La nuance paraît administrative jusqu’au moment où un participant demande pourquoi son annonce n’est visible nulle part dans l’outil qu’il consulte. Répondre « elle a été bloquée » décrit le résultat. Cela ne reconstitue pas nécessairement la décision.

Cette question affleure dans la présentation de Maria Matejka à APNIC 62, datée du 9 septembre. Elle y avertit que BIRD rejette trop durement les routes OTC invalides et évoque une correction attendue dans 2.20.0 et 3.4.0. Le propos s’inscrit dans une discussion des observations externes limitées : rien ne garantit qu’un autre réseau prévienne l’exploitant.

Il ne faut donc pas transformer cette diapositive en preuve d’une livraison, encore moins en règle imposée par APNIC. Son intérêt est ailleurs. Elle rapproche la prévention des fuites d’une difficulté très concrète de diagnostic.

Deux obligations qui ne se remplacent pas

OTC accompagne une limite de propagation liée à la relation entre voisins BGP. Le RFC 9234, publié en mai 2022, prescrit des vérifications selon le rôle de la session. Il définit aussi l’inéligibilité par l’exclusion de l’installation dans la Loc-RIB et de l’étape suivante de sélection.

Cette définition ne confond pas une route inutilisable avec toute information conservée à son sujet. Une copie mise à l’écart pour diagnostic peut être utile sans devenir une candidate à l’acheminement. Mais la possibilité de conserver une preuve ne vaut pas autorisation d’installer une route invalide dans une table active en comptant sur une promesse de non-utilisation.

La représentation doit garantir l’exclusion, pas seulement l’afficher. Et l’on ne peut traiter de la même manière un attribut correctement formé révélant une fuite et un attribut dont la longueur est incorrecte. Dans le second cas, il s’agit d’abord de validité du message.

Le besoin de visibilité n’est pas nouveau

En juin 2025, un échange lancé par André Grüneberg exposait déjà le problème côté BCIX. Le correspondant voulait montrer les routes OTC refusées dans un outil de consultation de routes, en les identifiant comme telles. Le rangement qu’il proposait était une demande adressée aux développeurs, pas la démonstration d’un dispositif déployé ni d’une conformité acquise.

Sa réponse du même mois relevait que le chemin utilisant le retrait ne semblait pas interagir avec le mécanisme de conservation des routes filtrées. La discussion évoquait également le coût d’un traitement OTC uniquement assuré par des filtres : perdre la vérification des rôles au niveau de la session.

Il serait dangereux d’en tirer une recette de dépannage. Déplacer la décision pour rendre la route consultable peut modifier une protection que l’on voulait préserver. Une trace plus riche n’est pas un bénéfice net si elle oblige à abandonner une vérification de relation entre voisins.

Cette correspondance reste historique. Elle ne mesure ni la configuration actuelle de BCIX ni la diffusion de ces pratiques dans les points d’échange.

Où le code coupe la chaîne

La page officielle de téléchargement capturée le 14 septembre présente notamment 2.19.2 et 3.3.2, datées du 30 juillet. Les deux versions évoquées dans la présentation n’y figurent pas dans cette capture. C’est une borne sur la preuve publique examinée, non une enquête exhaustive sur les branches, distributions ou correctifs privés.

Dans le fichier de traitement des attributs du tag 2.19.2, les contrôles OTC ne s’appliquent que lorsque les rôles sont applicables au canal. Si le rôle local est fournisseur ou serveur de routes, recevoir une route portant OTC déclenche le retrait. Pour le rôle de pair, le retrait intervient aussi lorsque l’ASN porté par OTC diffère de l’ASN distant.

Le mécanisme écrit un message, positionne un indicateur de retrait puis revient à l’appelant. Le même fichier possède un contrôle distinct de longueur : OTC doit contenir quatre octets ; une autre longueur conduit elle aussi au retrait, pour une autre raison.

Le traitement des paquets du même tag permet de suivre la suite. Après la finalisation des attributs, l’indicateur de retrait rend nul le pointeur d’attributs. La branche correspondante transmet un retrait à la routine de mise à jour. La branche non nulle construit, elle, un objet de route temporaire.

Le problème n’est donc pas seulement de choisir un filtre plus explicite. Le filtre peut recevoir une autre sorte d’opération : un retrait au lieu de l’objet qu’un rangement diagnostique aurait voulu conserver. C’est une déduction tirée de ce chemin de code précis. Aucun routeur en service n’a été testé.

La journalisation subsiste. Rien ici ne démontre l’invisibilité de la route dans tous les journaux, captures de paquets, tables d’importation ou flux BMP possibles. En revanche, un message survivant ne fournit pas automatiquement l’annonce reçue, son attribut OTC, le contexte de session et l’explication du rejet sous une forme interrogeable.