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
  • Un bug de traitement des messages BGP a provoqué le 20 mai 2025 une forte instabilité du routage ainsi que, sur certains réseaux, des coupures de connectivité Internet
  • La cause du problème était un attribut BGP Prefix-SID invalide, qui a déclenché des réactions anormales dans plusieurs implémentations BGP majeures, en particulier JunOS et Arista EOS
  • Certains opérateurs de transit, dont Hutchison et Starcloud, ont relayé le message à l’origine du problème, aggravant sa propagation
  • L’incident a entraîné des réinitialisations massives de sessions BGP et de l’instabilité sur plus d’une centaine de réseaux
  • Cette situation a mis en évidence les failles de tolérance aux erreurs BGP selon les fournisseurs ainsi que la nécessité d’améliorations

27 mai 2025

Instabilité mondiale du routage Internet causée par un bug de traitement BGP

Le mardi 20 mai 2025 à 7 h (UTC), la propagation d’un message BGP a entraîné un comportement inattendu dans deux grandes implémentations BGP couramment utilisées pour acheminer le trafic Internet.

Cela a provoqué la fermeture automatique de nombreuses « sessions BGP de connectivité Internet », entraînant temporairement au minimum une instabilité du routage et, dans les cas les plus graves, une perte de connectivité sur certains réseaux.

Le message BGP en cause

  • L’analyse des sessions collectées par bgp.tools montre que le message BGP Update à l’origine du phénomène semblait ordinaire, mais contenait un attribut BGP Prefix-SID corrompu dont les données internes étaient remplies de 0x00
  • La plupart des implémentations BGP (IOS-XR, Nokia SR-OS) le filtrent correctement conformément à la RFC7606 (tolérance aux erreurs BGP), mais un problème est apparu dans l’interaction entre JunOS et Arista EOS
    • JunOS conserve et relaie le message corrompu, tandis qu’Arista EOS réinitialise la session BGP à sa réception
  • Dans les environnements où le matériel Juniper (JunOS) est largement déployé et relié à Arista EOS, cela peut entraîner jusqu’à 10 minutes de coupure d’accès à Internet

L’émetteur du message problématique

  • L’analyse des archives bgp.tools sur cette période montre que plusieurs AS d’origine sont impliqués

  • Cela suggère que l’attribut invalide n’a pas été ajouté par le réseau ayant émis le préfixe, mais par un opérateur de transit situé sur le trajet

  • Les principaux AS liés à l’incident sont les suivants

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • D’après les données de bgp.tools, il est probable que l’attribut ait été effectivement ajouté par Starcloud (AS135338) ou Hutchison (AS9304)

  • Parmi les préfixes représentatifs ayant propagé cet attribut figurent 156.230.0.0/16, 138.113.116.0/24, etc.

  • Hutchison/AS9304 étant connecté à de nombreux points d’échange Internet (IX), le message s’est également propagé jusqu’aux route servers utilisant bird

  • Bird ne prend pas en charge les BGP SID et a donc relayé le message vers de nombreux IX sans filtrage, amplifiant le désordre à l’échelle du réseau

Qu’est-ce que le BGP Prefix-SID ?

  • L’attribut BGP Prefix-SID ne devrait généralement être utilisé que dans des sessions BGP internes, afin de définir le chemin vers une destination au sein d’un même réseau (RFC8669)
  • La fuite de cet attribut dans la table de routage globale pourrait venir d’une session BGP externe configurée comme une session interne

Réseaux touchés

  • Il est difficile d’identifier précisément les victimes, mais le problème a été observé sur environ une centaine de réseaux ayant montré un churn massif après le message BGP initial
  • En temps normal, le route collector de bgp.tools collecte 20 000 à 30 000 messages par seconde, mais au moment de l’incident il a enregistré plus de 150 000 messages en moyenne sur 10 secondes
  • Ce niveau indique qu’une perturbation grave a affecté une large partie des routes Internet

Responsabilité des fournisseurs et enseignements

  • Même si la cause profonde n’est pas établie avec certitude, la propagation d’un message erroné à l’échelle d’Internet montre que les problèmes existants de gestion des erreurs BGP constituent un risque bien réel
  • D’autres fournisseurs ont filtré l’attribut problématique, mais Juniper l’a indirectement laissé passer jusqu’à des équipements Arista, où l’insuffisance du code de tolérance aux erreurs BGP a provoqué des réinitialisations de session
  • La documentation officielle de JunOS indique également qu’« il n’inspecte pas l’intégralité du message »
  • Avec cette conception, JunOS évite peut-être le risque de réinitialisation de session à distance pour lui-même, mais il peut transmettre des messages problématiques à d’autres peers ou clients

Conclusion

  • Cet incident a été de courte durée, mais il montre qu’il pourrait devenir bien plus grave à plus grande échelle

  • À mesure que les services reposent de plus en plus sur l’IP, l’impact des pannes Internet pourrait dépasser la simple impossibilité d’accéder au mail grand public, avec des risques comme l’échec de diffusion TV ou l’impossibilité de joindre les services d’urgence

  • Cela souligne la nécessité, selon les fournisseurs, d’une implémentation réellement robuste de la tolérance aux erreurs BGP, avec la possibilité réaliste que de telles pannes puissent aller jusqu’à provoquer des pertes humaines réelles

  • Un appel est lancé aux opérateurs réseau souhaitant contribuer à l’analyse des données bgp.tools (lien fourni)

À lire aussi

1 commentaires

 
GN⁺ 2025-05-29
Avis Hacker News

  • En général, le principe « soyez tolérant à la réception, précis à l’émission » est considéré comme l’approche standard

    • Il existe plusieurs options : filtrer les messages corrompus (drop, filtrage), ignorer uniquement l’attribut et transmettre quand même (break), ou couper complètement la connexion (comme Arista)

    • Je considère que la quatrième option (la méthode Arista) est vraiment difficile à accepter

    • La troisième (Juniper) n’est pas non plus souhaitable, mais je ne la vois pas comme un problème fatal

    • Édit : en relisant, je me suis rendu compte qu’Arista n’était pas le quatrième cas mais le deuxième (fermeture de la connexion)

    • Ils ont simplement considéré la connexion comme invalide et l’ont fermée ; ce n’est pas une très bonne décision du point de vue de l’expérience utilisateur, mais cela reste acceptable à mon avis

    • Le RFC 7606 (Improved Error Handling for BGP UPDATE Messages) existe déjà et précise concrètement comment traiter les messages corrompus

      • La méthode la plus courante est treat-as-withdraw (traiter comme si la route avait été retirée)
      • Si l’on ignore simplement le message corrompu, on risque de conserver l’état précédent alors qu’il n’est en réalité plus valide

    • Le principe « soyez tolérant à la réception et précis à l’émission » correspond justement à ce qu’on appelle le « robustness principle » ou la « loi de Postel »

      • C’est une idée héritée des débuts d’Internet dans les années 1980-1990
      • Mais aujourd’hui, le secteur reconnaît largement que c’était une mauvaise manière de penser
      • Ce principe a entraîné la rigidification des protocoles et d’innombrables problèmes de sécurité

    • En exploitant les caractéristiques de fonctionnement de BGP, tout un ensemble de problèmes est apparu à l’échelle du réseau, en profitant du fait qu’un équipement local peut relayer tel quel des attributs qu’il ne connaît pas

      • Nous voyons maintenant dans la pratique les inconvénients de cette « fonctionnalité »

    • L’auteur le souligne également dans son billet

      • Cette « fonctionnalité » semble être une très mauvaise idée, car elle pousse le système à relayer sans esprit critique des données qu’il ne comprend pas
      • Mais elle a aussi permis la diffusion rapide de nouvelles fonctionnalités comme Large Communities et facilité l’adoption de nouvelles extensions BGP

    • Je ne suis pas d’accord avec cette approche

      • Je pense qu’il est bien préférable d’être strict et explicite à la fois sur ce qu’on accepte et sur ce qu’on émet

  • Je me souviens encore de la frénésie pour déployer des correctifs du bug CVE-2023-4481 à l’échelle du réseau

    • Ce type de bug restera un cauchemar à gérer
    • Vu la conception de BGP et la façon dont il est implémenté, je crains qu’il faille encore très longtemps pour corriger réellement ce genre de comportement

  • J’ai travaillé autrefois sur des fonctionnalités BGP chez un équipementier télécom (il y a assez longtemps)

    • Je trouve toujours BGP beaucoup trop complexe

    • On continue d’y ajouter de nouvelles fonctions, et les fournisseurs réimplémentent sans cesse selon les standards ou les drafts

    • Comme BGP semble ne jamais devoir disparaître, j’ai l’impression que ce type de bug reviendra sans cesse

      • À une époque, des opérateurs comme AT&T et des fournisseurs comme Juniper ou Cisco poussaient BGP dans les fonctionnalités MPLS et VPN, ce qui plongeait les systèmes dans une grande complexité
        • C’était excessivement complexe, mais certains en ont très bien profité financièrement

  • HGC Global Communications Limited (anciennement Hutchison Global Communications Limited, abrégé HGC) est un fournisseur d’accès Internet de Hong Kong

  • J’ai l’impression que BGP serait bien plus stable sur ce type de sujets si les différents fabricants de matériel s’alignaient sur les standards

    • Je me demande si le vrai problème ne vient pas du fait que chaque fournisseur hésite à standardiser afin de garder ses clients captifs
    • Je précise au passage que ma compréhension de BGP reste assez superficielle

  • Je ne sais pas si je suis le seul, mais je n’avais jamais entendu parler de BGP avant d’apprendre qu’il avait causé un problème

    • C’est pourtant un protocole essentiel à Internet, comme TCP/IP, sauf que TCP/IP est enseigné à l’école, dans les parcours professionnels et dans les livres, alors que je n’ai jamais croisé BGP
    • On peut pratiquer et apprendre TCP/IP chez soi, mais je n’ai aucune idée de la manière de « jouer avec » BGP à la maison

      • S’il existe un moyen de pratiquer BGP chez soi, cela m’intéresse

      • On peut le faire avec un vrai routeur intégrant une implémentation BGP (parmi les modèles abordables, il y a par exemple Mikrotik), ou avec une implémentation open source

        • Il y a bird mentionné dans l’article, ainsi que le très populaire FRR (Free Range Routing)
        • Il est possible de lancer deux conteneurs Docker, d’établir une session BGP entre eux et d’y propager des routes statiques, par exemple
        • Si vous cherchez un tutoriel, le guide de ce lien est bien fait et permet de suivre cela avec des logiciels gratuits

      • DN42 est un terrain de jeu pour pratiquer les technologies de routage

        • Mais cela demande un investissement en temps, ce n’est pas quelque chose qu’on teste à la légère
        • Moi aussi je fais pas mal de réseau, mais le routage WAN me semble encore confus
        • GNS3 est probablement le moyen le plus simple pour manipuler directement n’importe quelle technologie réseau
        • Wiki DN42

      • Mon cursus de licence n’abordait pas BGP, mais je l’ai étudié en master

        • On utilisait un package Python capable de simuler plusieurs AS, mais je ne me souviens plus du nom exact

      • Dans le cours de réseau que j’ai suivi en licence, BGP n’a été évoqué que très brièvement au tableau

        • Pour pratiquer BGP, on peut utiliser un simulateur réseau comme l’auteur l’a fait
        • Dans notre cours, on utilisait un simulateur appelé gini, un programme développé par un doctorant du professeur
        • Le gns3 utilisé par l’auteur donne un peu l’impression d’un ns3 orienté Cisco
        • ns3 m’a semblé difficile, car il y avait beaucoup à apprendre
        • gini a une interface plus simple, mais des performances plus modestes
        • Présentation du projet gini
        • Documentation officielle de gns3

      • J’ai l’impression qu’on ne peut vraiment « pratiquer » BGP qu’en administrant un grand réseau relié au trafic réel d’Internet

        • À la maison, ce qu’on peut faire au mieux, c’est utiliser un simulateur réseau

  • Par le passé, plusieurs fournisseurs ont eux aussi eu des bugs similaires à celui décrit dans l’article

  • Nous avons aussi reçu des paquets similaires sur nos châssis IOS XR

    • Cela coïncidait avec une forte quantité d’annonces de routes BGP

    • Je ne sais pas exactement quel était l’équipement en amont

    • Cela m’a amené à me demander si le protocole BGP est correctement testé par fuzzing

    • Peut-être que, comme c’est un protocole trop critique, personne n’ose provoquer volontairement une panne

    • Écrire un fuzzer pour BGP serait sans doute facile, mais diagnostiquer les crashs pourrait être très difficile

      • (Auteur du billet)
        • Oui, c’est précisément ce que j’ai fait dans mon article
        • Billet associé

  • Je me demande s’il existe un autre système aussi vaste que le backbone Internet et qui ait accumulé autant de complexité accidentelle

  • Vu l’impact potentiel de ce genre de bug, je suis surpris qu’il n’existe pas un consortium exploitant une suite de tests d’interopérabilité

    • Ou alors il en existe réellement un, mais ce problème particulier est passé hors du périmètre de test
    • Il semblerait naturel d’utiliser un fuzzer ou un générateur automatique pour couvrir toutes les erreurs de paquets possibles et multiplier les cas de test afin d’augmenter la couverture
    • Même si l’exécution prend plusieurs jours
    • L’auteur de l’article a d’ailleurs réellement créé un fuzzer et l’a utilisé, et il a rencontré plusieurs fois des problèmes similaires
    • Je trouve étonnant que les fournisseurs ne s’intéressent pas davantage à ce type de recherche pourtant critique