Un bug de traitement BGP provoque une instabilité du routage Internet

 (blog.benjojo.co.uk)
1 points par GN⁺ 2025-05-29 | 1 commentaires | Partager sur WhatsApp
  • Le 20 mai 2025 à 07:00 UTC, un message BGP corrompu propagé sur Internet a déclenché un comportement inattendu dans deux implémentations majeures, provoquant la réinitialisation de nombreuses sessions BGP interconnectées et, sur certains réseaux, une instabilité du routage ou de brèves pertes de connectivité
  • La mise à jour en cause contenait un attribut BGP Prefix-SID inhabituel pour une mise à jour BGP Internet, dans un état corrompu avec des données internes entièrement à 0x00
  • IOS-XR et Nokia SR-OS, avec la tolérance aux erreurs de type RFC7606, l’ont filtré, mais JunOS l’a relayé et Arista EOS a réinitialisé la session, ce qui a pu affecter les utilisateurs Arista connectés à des transit carriers basés sur JunOS
  • Dans les observations de bgp.tools, AS9304, AS135338, AS151326 et AS138077 reviennent de façon répétée, et l’acteur ayant probablement ajouté l’attribut défectueux serait Starcloud AS135338 ou Hutchison AS9304
  • Pendant l’incident, le débit moyen de messages sur 10 secondes du route collector de bgp.tools est passé de 20 000–30 000 messages/s en temps normal à plus de 150 000/s, montrant que les différences de traitement des erreurs BGP peuvent réellement déstabiliser l’Internet mondial

Incident sur les mises à jour BGP du 20 mai 2025

  • Le mardi 20 mai 2025 à 07:00 UTC, un message BGP propagé sur Internet a provoqué un comportement inattendu dans deux implémentations BGP majeures, couramment utilisées pour acheminer le trafic Internet
  • L’impact s’est étendu à mesure que de nombreuses sessions BGP interconnectées se terminaient automatiquement
    • Une instabilité du routage a été observée sur certains réseaux
    • Dans le pire des cas, de brèves pertes de connectivité ont pu se produire

Le message BGP en cause

  • La mise à jour observée sur les sessions alimentant bgp.tools était une BGP Update assez banale pour un /16, mais elle contenait l’attribut BGP Prefix-SID problématique
  • Cet attribut était dangereux pour deux raisons
    • C’est un attribut qu’on ne s’attend pas à voir dans des mises à jour BGP de la table Internet
    • C’était un attribut corrompu dont les données internes étaient entièrement à 0x00
  • La plupart des implémentations comme IOS-XR ou Nokia SR-OS le filtrent correctement, sans provoquer de problème, lorsque la « BGP error tolerance » basée sur RFC7606 est activée
  • La combinaison JunOS + Arista EOS a produit un résultat différent
    • JunOS a relayé le message corrompu
    • Les équipements Arista EOS réinitialisaient la session en recevant ce message, qui semblait provenir d’un équipement JunOS
  • Comme de nombreux transit carriers Internet utilisent du matériel Juniper exécutant JunOS, les réseaux exploitant Arista EOS et connectés à des routeurs de transit amont basés sur JunOS ont pu perdre l’accès à Internet pendant un certain temps
    • La durée est estimée à environ 10 minutes au maximum

AS candidats ayant ajouté l’attribut défectueux

  • Le filtrage des archives bgp.tools sur cette période montre que plusieurs AS d’origine semblent impliqués dans l’incident
  • Cela suggère que l’attribut a pu être ajouté non par le réseau à l’origine du préfixe, mais par un carrier intermédiaire sur le trajet vers l’Internet plus large
  • Les quatre candidats revenant de façon répétée dans l’ensemble des messages problématiques sont les suivants
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools a observé le préfixe impacté sur le chemin […] 151326 138077 […] sans l’attribut BGP défectueux
    • L’acteur ayant ajouté l’attribut défectueux serait donc probablement Starcloud AS135338 ou Hutchison AS9304
  • Voici quelques préfixes observés dans des mises à jour contenant cet attribut
    • 156.230.0.0/16
    • 138.113.116.0/24
    • 163.171.102.0/24
    • 163.171.103.0/24
    • 163.171.104.0/24

Le chemin de propagation via les points d’échange Internet

  • L’incident a pris de l’ampleur parce que Hutchison/AS9304 était connecté à de nombreux points d’échange Internet
  • Les messages problématiques ont été envoyés à des route servers d’IX, qui exécutent généralement bird
  • Bird ne prend pas en charge BGP SID et n’a donc pas pu filtrer ces messages, les redistribuant tels quels à plusieurs points d’échange Internet multi-térabits
  • En conséquence, la perturbation s’est étendue bien au-delà des seules sessions de transit Internet

La nature de BGP Prefix-SID

  • L’attribut BGP Prefix-SID ne devrait normalement apparaître que dans des sessions BGP internes
  • Comme le définit RFC8669, il sert à aider à déterminer, au sein d’un seul réseau, le chemin que doit emprunter le trafic vers une destination
  • Si cet attribut a fuité dans la table de routage globale, c’est peut-être parce qu’une session BGP externe a été configurée comme une session interne

Réseaux affectés et indicateurs d’observation

  • Il est difficile d’affirmer avec certitude qui a été touché, mais en se basant sur les réseaux dont le churn a été très élevé par rapport à leur taille juste après le premier message BGP problématique, environ 100 réseaux auraient subi des problèmes
  • Exemples cités avec un haut niveau de confiance
  • En temps normal, le route collector de bgp.tools collecte environ 20 000 à 30 000 messages par seconde
  • Pendant cet incident, le débit moyen de messages sur 10 secondes a largement dépassé 150 000/s
    • Ce qui indique une perturbation importante sur un grand nombre de routes Internet

Différences de traitement des erreurs selon les fournisseurs

  • Même si la cause racine et l’acteur réellement à l’origine ne sont pas totalement établis, le fait qu’un message défectueux ait pu se propager à l’échelle d’Internet montre le risque lié au traitement des erreurs BGP
  • D’autres fournisseurs ont détecté l’attribut défectueux et supprimé l’annonce de route, mais Juniper l’a propagé à ses peers
  • Une fois le message arrivé sur des équipements Arista, l’absence de code de tolérance aux erreurs BGP, ou un défaut dans celui-ci, a conduit à des réinitialisations de session
  • La documentation JunOS sur la tolérance aux erreurs BGP indique que JunOS n’examine pas toutes les parties d’un message
  • Ce comportement permet à JunOS d’éviter lui-même une réinitialisation de session déclenchée à distance, tout en transmettant le même message à d’autres peers ou clients

Implications opérationnelles

  • Cette panne a été brève, mais elle aurait pu avoir un impact bien plus large
  • À mesure que davantage de services migrent vers l’IP, la portée d’une panne Internet peut dépasser le simple échec d’accès aux e-mails
    • Panne de diffusion TV
    • Défaillance des appels vers les services d’urgence
  • Ce type de bug augmente le risque de provoquer ou d’aggraver des pertes humaines dans le monde réel
  • Les opérateurs de réseau disposant de la table de routage complète peuvent fournir un flux de données à bgp.tools pour aider à déboguer de futurs incidents

À lire aussi

1 commentaires

 
GN⁺ 2025-05-29
Avis sur Hacker News

  • L’approche standard consiste à être tolérant à la réception et strict à l’émission.
    Les options sont de filtrer les messages cassés, de les rejeter, d’ignorer les attributs cassés tout en les transmettant, ou de tomber en panne à cause d’un attribut cassé ; à mon avis, la seule option vraiment difficile à accepter est la 4e, le comportement à la Arista. Le comportement de Juniper, la 3e option, n’est pas souhaitable, mais il n’est pas fatal.
    En relisant, Arista était plutôt proche de la 2e option que de la 4e : il semble que l’équipement n’ait pas complètement crashé, mais ait considéré la connexion comme erronée et l’ait fermée. Du point de vue de l’utilisateur, ce n’est pas idéal, mais dans le débat, cela reste plutôt acceptable.

    • Il existe déjà la RFC 7606 (Revised Error Handling for BGP UPDATE Messages), qui précise en détail comment traiter les messages BGP cassés.
      La méthode la plus courante est treat-as-withdraw, qui consiste à traiter une mise à jour d’annonce de route comme le retrait d’une route précédemment annoncée. Il ne faut pas simplement jeter les messages cassés, car cela maintiendrait indéfiniment un ancien état qui n’est plus valide.
    • Ce qui est reformulé ici, c’est le fameux principe de robustesse, c’est-à-dire la loi de Postel.
      C’est une idée issue de la préhistoire d’Internet, dans les années 1980 et 1990, mais elle est aujourd’hui largement comprise comme une mauvaise idée ayant conduit à l’ossification des protocoles et à de nombreux problèmes de sécurité.
    • Le problème vient du fait que BGP transmet aussi des attributs inconnus que l’équipement local ne comprend pas, et que les gens ont exploité ce comportement à toutes sortes de fins à l’échelle du réseau.
      Désormais, beaucoup de systèmes dépendent de ce comportement, et on subit les inconvénients de cette « fonctionnalité ».
    • Dans l’article lié, l’auteur pointe le même problème.
      À première vue, cette « fonctionnalité » ressemble à une très mauvaise idée, car elle permet à des informations inconnues de se propager aveuglément via des systèmes qui ne comprennent pas les effets des informations qu’ils transmettent. Mais on peut aussi considérer que c’est grâce à elle que des choses comme les Large Communities ont pu être déployées plus rapidement et plus largement, et que le déploiement de nouvelles fonctionnalités BGP a tout simplement été possible.
    • Je ne suis pas d’accord avec cette approche. Je pense qu’il vaut mieux être très strict à la réception comme à l’émission.

  • Je me souviens encore d’avoir couru partout comme un fou pour corriger CVE-2023-4481 sur tout le réseau.
    Ce genre de bug doit être un véritable cauchemar à gérer, et vu la façon dont BGP a été conçu et implémenté, corriger ce comportement prendra très longtemps.

  • Il y a plusieurs décennies, j’ai développé des fonctionnalités BGP chez un fournisseur d’équipements télécoms.
    Je continue de penser que BGP est beaucoup trop complexe ; les gens n’arrêtent pas d’y ajouter de nouvelles fonctionnalités, et les fournisseurs continuent de les implémenter à partir des RFC ou des brouillons de standards.
    Comme BGP ne semble pas près d’être abandonné, ce genre de bug va probablement continuer à être découvert encore et encore.

    • Il y a clairement eu une période où AT&T, avec Juniper et Cisco, a poussé BGP dans un domaine totalement complexe via des fonctionnalités liées à MPLS et aux VPN.
      Personnellement, je trouvais cela effroyablement complexe, mais pour certains, c’était très rentable.

  • HGC Global Communications Limited est une entreprise autrefois connue sous le nom de Hutchison Global Communications Limited ; c’est un fournisseur d’accès Internet de Hong Kong.
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • Nos châssis IOS XR ont aussi reçu une partie de ces paquets, et cela coïncidait avec un volume élevé d’annonces de routes BGP. Honnêtement, je ne sais pas quel équipement utilise notre upstream.
    Je me demande si le protocole BGP est correctement fuzzé. C’est peut-être un domaine tellement critique que tout le monde a peur d’essayer de le casser.
    Écrire un fuzzer BGP pourrait être facile, mais diagnostiquer la cause des crashs me semble très difficile.

  • J’ai l’impression de n’avoir jamais appris BGP avant d’entendre dire qu’il causait des problèmes. C’est pourtant essentiel à Internet, comme TCP/IP, mais TCP/IP, je l’ai appris à l’université, je l’ai rencontré au cours de ma carrière et j’ai lu beaucoup de livres dessus, alors que BGP, je ne l’ai presque jamais croisé ni à l’université, ni au travail, ni dans les livres.
    Avec TCP/IP, on peut apprendre en « jouant » à la maison sur des projets jouets, mais avec BGP, je ne vois pas trop comment faire. Comment apprendre BGP chez soi ?

    • Il suffit d’acheter un routeur qui intègre une implémentation de BGP. Il existe du matériel bon marché comme Mikrotik, ainsi que des implémentations open source.
      L’article mentionne bird, et il y a aussi FRR (Free Range Routing), une implémentation très populaire. Lancer deux conteneurs Docker, établir une session BGP entre eux et, par exemple, annoncer une route statique configurée en interne, c’est très simple.
      Si vous aimez les tutoriels guidés, https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ est plutôt bien et va jusqu’à des sujets un peu plus avancés. Tout ce qu’il faut pour le suivre est du logiciel libre.
    • DN42[1] fournit un terrain de jeu pour expérimenter les technologies de routage. Si vous ne comptez pas y consacrer beaucoup de temps, je ne recommande pas de creuser trop profondément. Même en étant assez à l’aise avec le réseau, le routage WAN reste déroutant.
      Le moyen le plus simple d’acquérir une expérience pratique de n’importe quelle technologie réseau est probablement GNS3.
      [1]: https://wiki.dn42.us/home
    • BGP, c’est comme le transport maritime international. C’est indispensable au fonctionnement du monde, mais la plupart des gens n’ont pas besoin d’interagir directement avec.
      Une façon d’expérimenter est celle-ci : https://www.eve-ng.net/
      Une autre consiste à créer deux ou trois machines virtuelles avec plusieurs interfaces réseau, à configurer un réseau entre elles, puis à utiliser un démon de routage BGP.
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      Il existe des outils de ce genre.
    • Mon cours de réseau en licence ne couvrait pas BGP ; mon cours de réseau en master, oui.
      On utilisait un package Python pour simuler plusieurs AS, mais je ne me souviens plus lequel.
    • Dans mon cours de réseau en licence, on a un peu abordé BGP, mais seulement au tableau.
      Pour expérimenter avec BGP, on peut utiliser un simulateur de réseau, comme l’auteur de cet article. En cours, on utilisait gini[1], qui semblait avoir été créé par un doctorant du professeur, et l’auteur semble utiliser gns3, qui ressemble à une version de ns3 spécialisée Cisco. J’ai essayé ns3 une fois, et la courbe d’apprentissage était raide. Le simulateur gini a une interface plus rudimentaire, mais il est sans doute moins puissant.
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • On dirait que BGP serait beaucoup plus stable si les différents fabricants de matériel s’étaient mis d’accord sur une méthode standard pour gérer ce genre de choses.
    Le vrai problème est-il que chaque fournisseur veut créer un effet de verrouillage et évite donc la standardisation ?
    Cela dit, ma compréhension de BGP est superficielle et limitée, et je ne suis pas expert.

  • Vu l’impact de ce genre de bug, je suis surpris qu’il n’existe pas de consortium doté d’une suite de tests d’interopérabilité.
    Peut-être qu’il en existe une, mais que ce problème précis ne figure pas dans la suite de tests. Dans ce cas, je trouve surprenant qu’on n’utilise pas du fuzzing ou de la génération automatique pour explorer toutes les erreurs de paquets possibles et en faire des cas de test. Ce ne serait pas grave si l’exécution de la suite prenait des heures ou des jours.
    L’auteur de cet article a créé un fuzzer avec un certain niveau de couverture, et semble déjà avoir rencontré un problème similaire auparavant. Je suis surpris que les fournisseurs ne s’emparent pas plus activement de ce travail.

  • Plusieurs fournisseurs ont déjà rencontré ce bug par le passé : https://www.kb.cert.org/vuls/id/347067
    Il y a eu CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd) et CVE-2023-40457 (EXOS).
    À l’époque, Arista n’était pas affecté.

  • Je me demande s’il existe quelque chose d’aussi vaste que la plomberie d’Internet et dont la complexité accidentelle soit aussi byzantine.