Résumé

  • Le billet mis en ligne par LACNIC le 28 juillet part d'un attribut BGP Prefix-SID mal formé, code 40, observé le 20 mai 2025 et d'un pic supérieur à 150 000 mises à jour en dix secondes.
  • Selon ce récit, IOS-XR et SR OS ont supprimé l'attribut, Junos l'a transmis, EOS a réinitialisé des sessions et des serveurs de routes d'IXP l'ont relayé.
  • La RFC 8669 exige la suppression et la journalisation d'un Prefix-SID mal formé, sans pour autant prouver la version, le réglage de tolérance aux erreurs ou la politique héritée d'un équipement en production.
  • Une matrice probante doit lier un vecteur binaire commun à la version exacte, la configuration effective, la relation BGP, l'action, l'empreinte des octets retransmis et l'effet sur les routes.

Trois réactions pour un seul message

Le 28 juillet, LACNIC a publié une synthèse consacrée aux angles morts de la sécurité du routage. Elle ne réduit pas le sujet aux détournements de préfixe et aux fuites de routes. Son premier exemple est un objet de protocole précis : le 20 mai 2025, un BGP UPDATE contenait un attribut Prefix-SID corrompu. Cet attribut est optionnel et transitif ; son code est 40.

Le trajet rapporté est hétérogène. Cisco IOS-XR et Nokia SR OS auraient supprimé l'attribut mal formé. Junos aurait transmis le message sans le filtrer. Des routeurs Arista auraient réagi en réinitialisant leurs sessions BGP. Des serveurs de routes exploités dans plusieurs points d'échange l'auraient également relayé. L'article fait état de plus de 150 000 mises à jour en dix secondes et de fluctuations de routes associées à plusieurs grands réseaux. Il précise qu'Arista a modifié le comportement à partir d'EOS 4.28.11.

Cette chronologie est utile parce qu'elle refuse une mauvaise catégorie. Le message n'était pas, par ce seul fait, un détournement de préfixe ni une fuite de routes. Une ROA valide n'aurait pas rendu les octets internes de l'attribut conformes. RPKI et le parseur du récepteur ne répondent pas à la même question.

Le récit devient toutefois trop facile à généraliser si le nom du constructeur tient lieu d'état opérationnel. Une famille de produits ne dit ni quel parseur était installé, ni quel correctif était actif, ni quelle option de traitement des UPDATE provenait d'un groupe de voisins. Elle ne dit pas davantage si la frontière était un client, un transit, un pair, une session interne ou un serveur de routes.

Une règle normative n'est pas un inventaire de parc

La RFC 8669 décrit le Prefix-SID comme un ensemble de TLV et impose une action claire pour plusieurs erreurs de syntaxe. Un attribut trop court, une longueur impossible ou un TLV dépassant la limite annoncée doit être supprimé, et l'erreur doit être journalisée. Le texte renvoie à l'action Attribute discard de la RFC 7606.

Cette prescription permet de tester la conformité. Elle ne révèle pas spontanément le comportement de tous les logiciels déployés.

Le compte rendu publié au lendemain de l'incident par Ben Cox conserve une réserve déterminante. IOS-XR et SR OS auraient filtré l'objet à condition d'être configurés pour la tolérance aux erreurs définie par la RFC 7606. La formulation de LACNIC est plus directe : les deux plates-formes ont fait ce que la RFC exigeait. Ces phrases ne sont pas forcément contradictoires, mais la première conserve une variable que l'exploitant doit connaître.

Il ne s'agit pas d'accuser une synthèse d'être inexacte. Un article doit raccourcir, une enquête académique doit normaliser les termes, et un incident mondial ne fournit presque jamais un banc d'essai complet. Il suffit de transformer la réserve en colonne plutôt que de diluer toute conclusion.

Les échanges NANOG du jour même montrent pourquoi. Ils relient le comportement d'EOS au bug 899981 et citent des corrections dans les branches 4.28.11, 4.29.8, 4.30.6 et 4.31.2. Les participants se demandent aussi si ces versions auraient produit, pour le message exact, une réponse entièrement maîtrisée. Une présentation Arista à JANOG 57 reprend ensuite l'interaction entre IOS XR, SR OS, Junos et EOS. C'est un dossier cohérent ; ce n'est toujours pas un replay unique exécuté sur quatre plates-formes avec des paramètres publiés.

Le pic de messages ne mesure pas le nombre de pannes

La valeur de 150 000 décrit une amplification du plan de contrôle. Pour rester exacte, elle doit garder son unité : le graphe source montre un taux de messages observé par un collecteur et moyenné sur dix secondes. Il ne compte pas 150 000 préfixes uniques, sessions, routeurs, réseaux ou interruptions.

Les noms cités ne constituent pas non plus un inventaire technique. Des routes liées à Starlink, Disney, Zscaler ou ByteDance ont pu fluctuer sans que l'on puisse en déduire la version installée dans chaque organisation, le voisin qui a transmis les octets ou l'impact subi par tous les utilisateurs.

L'intention de l'AS émetteur reste inconnue. Les auteurs reconnaissent eux-mêmes que cette catégorie peut naître d'une redistribution mal réglée, d'un script lancé deux fois ou d'un défaut logiciel. Donner un nom à la classe de risque ne transforme pas l'événement en attaque volontaire.

Construire une fiche de conformité

LACNIC n'a pas besoin de devenir auditeur des routeurs pour améliorer cette preuve. Il peut joindre à son article une matrice datée fondée sur un vecteur de test assaini et identique pour tous les essais.

Chaque ligne commencerait par l'empreinte immuable de l'UPDATE, le code 40, les flags, la longueur annoncée et la faute TLV. Elle préciserait ensuite la plate-forme, la version exacte, l'identifiant du correctif et la configuration réellement appliquée après héritage des modèles, groupes et paramètres du voisin.

La frontière doit être nommée. Une politique acceptable en iBGP peut être refusée à un client, un fournisseur de transit, un pair ou un serveur de routes. La mention route server ne prouve ni un logiciel commun ni un filtrage commun.

Le résultat doit distinguer réinitialisation, désactivation d'une famille, treat-as-withdraw, suppression de l'attribut, acceptation ou autre action. Si le message ressort, une empreinte de la copie assainie permet de savoir si les octets ont changé. S'il ne ressort pas, la non-propagation doit être explicite. Enfin, la fiche relie cette décision à l'état de session et aux variations d'Adj-RIB-In, de Loc-RIB et de FIB dans le test.

Une publication publique n'a besoin ni des adresses de pairs, ni des noms de clients, ni des secrets, ni d'une configuration complète. Les captures brutes peuvent rester protégées. Le vecteur, la méthode, les pertes de collecte, les résultats agrégés, les corrections et la date du nouveau test peuvent être ouverts.

Cette discipline rétablit le partage des rôles. Les RFC définissent l'action. Les constructeurs écrivent et corrigent le code. Les opérateurs choisissent versions et politiques. Les exploitants de serveurs de routes décident de ce qu'ils transportent. LACNIC documente et diffuse une méthode ; il n'acquiert aucun pouvoir sur ces décisions locales.

Ce que le dossier ne permet pas d'affirmer

Les sources ne montrent pas que LACNIC ait émis le message, exploité un équipement touché ou été en mesure d'arrêter l'incident. Elles ne mesurent pas une population d'utilisateurs, une durée identique ou une panne mondiale unique. Elles ne démontrent pas non plus un défaut permanent d'une marque.

L'épisode ne réfute pas RPKI. La validation d'origine porte sur l'autorisation d'un couple préfixe–AS. La validité syntaxique d'un attribut optionnel transitif appartient à un autre dispositif de contrôle. Les fusionner masquerait précisément la responsabilité que le cas rend visible.

La conclusion la plus solide est donc modeste : LACNIC a fourni un excellent exemple de divergence entre implémentations. Pour qu'il reste vrai après la prochaine mise à jour logicielle, le tableau doit désormais dire dans quelles conditions chacun des trois verbes a été observé.

Sources