- 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
Aucun commentaire pour le moment.