Analyse d’une anomalie BGP survenue au Venezuela
(blog.cloudflare.com)- Plusieurs fuites de routes BGP (route leaks) se sont produites sur le réseau CANTV (AS8048) au Venezuela, provoquant une propagation anormale de certains chemins réseau
- Selon les données de Cloudflare Radar, 11 événements de fuite ont été confirmés depuis décembre, ce qui suggère fortement une erreur technique due à des politiques de routage insuffisantes
- Dans cet incident, AS8048 a retransmis à un autre fournisseur, AS52320 (V.tal GlobeNet), des routes reçues de son fournisseur amont AS6762 (Sparkle), ce qui correspond à une fuite en épingle de type 1 typique
- La validation de l’origine des routes (ROV) basée sur RPKI n’est d’aucune utilité dans ce cas, et de nouvelles normes comme ASPA (Autonomous System Provider Authorization) et RFC9234 sont nécessaires pour empêcher ce type de fuite
- En raison de l’architecture fondée sur la confiance de BGP, ce genre d’incident est fréquent, et l’adoption de technologies comme ASPA, Peerlock et RFC9234 est essentielle à l’exploitation d’un Internet sûr
Notion de fuite de routes BGP
- BGP (Route Gateway Protocol) est le protocole qui échange des routes entre systèmes autonomes (AS) sur Internet
- Les relations entre réseaux sont de type client-fournisseur (customer-provider) ou pair-à-pair (peer-peer)
- Une fuite de route (route leak) est définie par la RFC7908 comme une « propagation d’informations de routage au-delà de leur portée prévue »
- Exemple : lorsqu’un client réannonce à un autre fournisseur des routes reçues d’un fournisseur
- Ces fuites constituent une violation de la règle du valley-free routing, ce qui fait circuler le trafic sur des chemins anormaux
- Cela peut entraîner congestion réseau, latence et perte de trafic
Cas de fuite de routes chez AS8048 (CANTV)
- Cloudflare Radar a confirmé que AS8048 (CANTV) a retransmis à AS52320 (V.tal GlobeNet) des routes reçues de AS6762 (Sparkle)
- Il s’agit clairement d’une fuite de route
- L’origine des routes divulguées est AS21980 (Dayco Telecom), un réseau client d’AS8048
- La relation entre les deux AS est identifiée comme une relation fournisseur-client dans les données de Cloudflare Radar et de bgp.tools
- Le chemin comportait plusieurs prepend d’AS8048
- Le prepend est une technique qui rend un chemin moins attractif afin de diriger le trafic vers d’autres routes
- La probabilité d’une attaque MITM (attaque de l’homme du milieu) intentionnelle est donc faible
- Les fuites se sont produites à plusieurs reprises entre le 2 janvier 2026 à 15:30 et 17:45 UTC, ce qui laisse penser à une erreur de politique réseau ou à un problème de convergence
- D’après l’historique de Cloudflare Radar, 11 fuites similaires se sont répétées depuis décembre, ce qui indique une défaillance persistante des politiques
Causes techniques et problèmes de politique
- Il est possible qu’AS8048 ait configuré de manière trop permissive sa politique d’export de routage à destination de son fournisseur AS52320
- Si seuls des prefix-lists basées sur l’IRR ont été utilisés au lieu de tags de communauté BGP côté client, une mauvaise réannonce des routes a pu se produire
- Ce type d’erreur de politique peut être évité grâce à l’attribut Only-to-Customer (OTC) de la RFC9234
- OTC définit explicitement les rôles BGP (client, fournisseur, pair) afin de bloquer les mauvaises propagations de routes
Rôle de RPKI et d’ASPA
- Sparkle (AS6762) n’a pas entièrement déployé RPKI Route Origin Validation (ROV),
- mais comme cet incident relève d’une anomalie de chemin (path), il ne peut pas être empêché par la ROV
- ASPA (Autonomous System Provider Authorization) fournit une validation fondée sur le chemin
- Chaque AS y déclare la liste de ses fournisseurs amont autorisés, ce qui permet de bloquer automatiquement les chemins anormaux
- Exemple : si AS6762 déclare n’avoir aucun fournisseur amont, les autres réseaux peuvent rejeter les chemins erronés incluant AS6762
- ASPA fonctionne sur la base de RPKI et a un effet direct sur la prévention des fuites de routes
Propositions pour un BGP plus sûr
- BGP est par nature un protocole fondé sur la confiance, ce qui rend fréquentes les fuites dues à des erreurs de politique ou de manipulation
- L’application conjointe de technologies comme ASPA, RFC9234 et Peerlock/Peerlock-lite permet de :
- renforcer la validation des chemins
- bloquer la propagation de routes erronées
- améliorer la stabilité du réseau
- RIPE prend déjà en charge la création d’objets ASPA,
- et les opérateurs doivent demander aux fournisseurs d’équipements réseau la mise en œuvre de la RFC9234
- L’adoption coopérative de ces standards est le principal moyen de prévenir des incidents BGP comme celui observé au Venezuela
1 commentaires
Commentaires Hacker News
J’ai trouvé le fil de commentaires ici assez inattendu. Tout le monde parle de la peur des entreprises américaines, mais ça ne semble pas vraiment lié au contenu de l’article
Le billet de Cloudflare explique simplement le fonctionnement de BGP et souligne que des fuites de routes se sont fréquemment produites chez un FAI vénézuélien
Bien sûr, Cloudflare peut se tromper ou cacher quelque chose, mais le texte ne dit nulle part qu’ils sont intervenus directement. Je me demande sur quoi les gens se fondent pour en être si sûrs
Cela dit, quand on voit des affaires comme Stuxnet ou Dual EC DRBG, il ne faut pas sous-estimer la capacité des gouvernements à exploiter des 0-day
Un ami à moi travaillait dans une entreprise du FANG et a vu l’État recevoir un accès direct aux flux de données. Les backdoors chez les FAI existent aussi bel et bien (Room 641A)
Si Cloudflare avait coopéré en vertu d’un mandat, aurait-il eu légalement le droit d’écrire un billet niant cela ?
C’est de là, à mon avis, que vient le scepticisme de fond des gens. La conclusion de Cloudflare, du type « c’est un vieux problème, rien d’extraordinaire », me paraît un peu faible
Je me demande aussi s’il existe, dans l’architecture même de BGP, une raison pour laquelle les États-Unis pourraient faire ce genre de chose plus facilement que d’autres pays
L’opinion sur le gouvernement américain est tellement cynique en ce moment que le moindre incident suscite la suspicion
Ou alors c’est peut-être juste des comptes sociaux russes ou chinois, mais qui sait
Et un article de CNN mentionnait aussi que Trump évoquait une possible action militaire même contre des alliés
Avec l’administration actuelle, j’ai même l’impression qu’ils se seraient vantés publiquement d’une telle attaque. Donc, pour l’instant, je penche plutôt pour la thèse de la « simple erreur de configuration »
Cela dit, comme dès que les États-Unis apparaissent dans l’actualité on parle de menaces, de retraits ou de sanctions, il est naturel que la méfiance grandisse
J’étais à moitié endormi, mais j’ai trouvé l’article intéressant. L’analyse de l’AS path prepending étaye bien l’hypothèse de l’« accident »
Si un État avait voulu intercepter le trafic, il n’aurait eu aucune raison d’allonger volontairement le chemin
C’était probablement juste une erreur de configuration du routage. BGP reste un système fondé sur la confiance, donc une simple faute de frappe peut avoir des effets à l’échelle mondiale
Une absence de filtre d’export paraît plus plausible qu’une intention malveillante
En pratique, il existe aussi des acteurs non étatiques qui cherchent à manipuler le trafic publicitaire
Malgré tout, du point de vue d’un opérateur réseau, ce genre d’erreur est courant, et des scripts automatisés d’ajustement de trafic peuvent aggraver le problème
Au fond, c’est la fragilité structurelle de BGP qui pose problème. Sécurité et BGP restent deux mots qui vont mal ensemble
L’un des documents Snowden, NSA Network Shaping 101, mérite d’être consulté
C’est un document rédigé en 2007 qui explique l’ASIN et le contrôle du trafic en couche 3
Il se contente surtout d’expliquer une architecture où le trafic envoyé vers certaines IP emprunte tel ou tel lien
Après avoir lu l’article, j’ai de nouveau eu des frissons en voyant à quel point l’imbrication entre entreprises américaines et gouvernement est profonde
Je le savais déjà, mais cette fois j’ai l’impression que la confiance est complètement brisée. On dirait un tournant d’époque
Ce type d’infrastructure de surveillance existe depuis très longtemps, et le Japon faisait déjà de la surveillance du trafic en temps réel en 2003
Aujourd’hui, la technologie DPI est devenue beaucoup trop facile à mettre en œuvre
Les nouveaux venus dans l’industrie commencent naïvement, puis finissent par comprendre la proximité structurelle entre gouvernements et entreprises, et perdent confiance
Avec le temps, une nouvelle génération arrive et recommence le même parcours
L’idée centrale du billet, c’est le rasoir de Hanlon : soupçonner d’abord l’erreur plutôt que la malveillance
Bien sûr, si Cloudflare avait déformé les faits, il faudrait le critiquer, mais pour l’instant il n’y a aucune preuve en ce sens
Quand on pense à l’infrastructure vieillissante du Venezuela, on peut se demander s’il y avait vraiment besoin d’une cyberattaque sophistiquée
En réalité, ce sont surtout des sous-traitants corrompus qui ont livré des systèmes bancals
Bien plus que les cyberattaques, c’est la structure de corruption qui pose le vrai problème
Au final, on a résolu ça en donnant de l’argent à un technicien qui travaillait dans la rue, et ce numéro était celui d’une compagnie de taxis
Dans un tel environnement, débattre d’une attaque BGP a quelque chose d’un peu absurde
Cet article était une bonne piqûre de rappel sur BGP
Quand je travaillais comme ingénieur réseau, j’utilisais souvent la magie des communautés BGP, et
si BGP s’était contenté d’exprimer trois types — provider, customer et peer — tout aurait peut-être été bien plus simple
C’est comme enlever les données de circulation ou les feux tricolores de Google Maps : le calcul devient plus facile, mais le résultat est catastrophique
Une fois, Google Maps m’a fait quitter l’autoroute pour traverser le parking d’un Walmart avant de reprendre une autre autoroute
À l’époque, j’avais pris ça pour une simple erreur d’algorithme, mais s’il m’avait envoyé par un drive McDonald’s, j’aurais soupçonné un complot
Pour cet incident aussi, l’explication par une simple erreur me paraît plus convaincante
Le fait que l’infrastructure centrale d’Internet soit largement opérée par des entreprises américaines a quelque chose d’inquiétant
D’autres pays devraient désormais bâtir des structures plus indépendantes
La vraie question, c’est : qui devrait s’en charger à la place ?
J’observe les incidents BGP depuis longtemps, et j’ai toujours trouvé difficile de distinguer un changement intentionnel, une erreur et une panne structurelle
Du coup, je commence toujours par trois questions : l’ampleur de l’impact a-t-elle augmenté progressivement, les routes ont-elles changé de manière symétrique, et la reprise a-t-elle été propre ?
Ensuite, je regarde d’abord les variations d’AS-path prepending et je compare la visibilité selon les régions
Enfin, je cherche à savoir « à qui cela a profité ». Je serais curieux de savoir quels indicateurs les autres utilisent pour détecter ce type de problème
La couverture mondiale de Cloudflare est vraiment impressionnante
En revanche, c’est une organisation très orientée ingénierie, donc elle communique bien ce genre d’analyses publiquement