Résumé

  • Cloudflare a examiné une anomalie BGP au Venezuela et a identifié AS8048, CANTV, comme système autonome ayant semblé divulguer des routes apprises via AS6762 vers AS52320, avec des préfixes originés par AS21980, Dayco Telecom [1].
  • Low Orbit Security a publié des exemples de chemins BGP où AS8048 apparaissait plusieurs fois dans des routes liées à l'espace 200.74.224.0/20. Ces chemins servent de preuve de routage, pas de preuve complète d'impact utilisateur [2].
  • APNIC a ensuite rappelé que certaines fuites détectées dans les collecteurs publics peuvent être éphémères, liées à la convergence, et doivent être évaluées selon leur durée et leur propagation [3].
  • La validation d'origine RPKI aide quand l'origine est fausse. Ici, l'origine pouvait rester correcte alors que la relation au milieu du chemin était contestable. Les contrôles pertinents sont donc la politique explicite, les rôles BGP, Only-to-Customer, ASPA et la télémétrie conservée [1][5][6][7][8].
  • L'article ne conclut pas que CANTV a provoqué une panne nationale. Il demande quelles preuves CANTV et ses voisins devraient produire pour montrer que la route, la relation, l'alerte, le retrait et la réparation sont maîtrisés.

Ce qui s'est passé

Les sources publiques décrivent une anomalie observée dans Cloudflare Radar et dans des collecteurs BGP. Low Orbit Security a signalé que des préfixes vénézuéliens apparaissaient avec CANTV, AS8048, dans des chemins où cette présence devait être expliquée. Cloudflare a ensuite précisé que le schéma impliquait des routes apprises via AS6762, Sparkle, et redistribuées vers AS52320, V.tal GlobeNet, avec AS21980 comme origine de certains préfixes [1][2].

Un chemin AS est une liste de réseaux autonomes que l'annonce de route prétend traverser. Une relation normale distingue client, pair et fournisseur. Un client peut généralement envoyer ses propres routes et celles de ses clients vers un fournisseur. Un fournisseur ne devrait pas utiliser une route de client ou de pair pour créer un transit imprévu vers une relation qui n'a pas cette portée. Lorsque cette frontière est franchie, le résultat est une fuite de route [5].

Le détail important est la frontière de preuve. Cloudflare a parlé d'une fuite de route, mais a aussi indiqué que l'événement ne devait pas être transformé en récit simple d'interception, de sabotage ou de panne générale. APNIC a renforcé cette prudence en expliquant que certains événements visibles dans des détecteurs publics peuvent être courts et limités. Cette prudence ne rend pas l'anomalie insignifiante. Elle indique seulement que le jugement doit partir du chemin observé, de sa durée, de sa propagation et de la sélection réelle du trafic.

Pourquoi cela compte

CANTV n'est pas un service web ordinaire. Un opérateur national porte des routes pour des clients, des fournisseurs, des organismes publics, des entreprises et des utilisateurs finaux. Une erreur de politique d'export peut donc devenir visible au-delà du réseau local. Même si l'impact final est limité, l'opérateur doit pouvoir expliquer pourquoi la route a été acceptée, pourquoi elle a été exportée, qui a reçu l'alerte et quelle règle empêche la répétition.

L'analyse plus générale de FastNetMon rappelle que BGP ne comprend pas nativement l'intention, la qualité ni la topologie attendue. Une route syntaxiquement valide peut donc se propager malgré une relation opérationnellement anormale [4].

Le critère de responsabilité n'est pas seulement "aucun dommage n'a été prouvé". Le critère est: l'opérateur peut-il reconstruire la chronologie, séparer les faits observés des hypothèses, et prouver que la configuration exécutée correspond aux relations commerciales et techniques prévues?

La couche technique

RPKI Route Origin Validation vérifie si un système autonome est autorisé à annoncer un préfixe [8]. Dans cette classe d'événements, l'origine peut rester légitime. Le problème se situe dans le chemin. C'est pourquoi des contrôles comme RFC 8212, RFC 9234, Only-to-Customer et ASPA sont plus proches de la faute décrite [6][7].

Une clôture technique crédible devrait inclure les préfixes, les sessions BGP, les politiques d'import et d'export, les rôles de relation, le premier et le dernier instant d'observation, la propagation dans RouteViews ou RIPE RIS, les compteurs de trafic, les retraits et les tests de non-récurrence. Sans ces éléments, le public ne peut pas savoir si l'anomalie était une convergence brève, une politique trop permissive ou un défaut opérationnel plus sérieux.

Qui est affecté

Les sources nomment des préfixes et des systèmes autonomes, pas une liste complète d'utilisateurs touchés. Une annonce BGP peut être visible dans un collecteur sans devenir le chemin choisi par beaucoup de réseaux. Elle peut aussi affecter certains utilisateurs si des réseaux qui comptent pour eux sélectionnent ce chemin. La bonne analyse doit donc relier les routes aux flux, aux pertes, à la latence et aux tickets clients.

Ce qu'il faut surveiller

Il faut surveiller les récidives autour d'AS8048, la durée des événements, les relations avec AS6762, AS52320 et AS21980, et toute preuve publique de politique plus stricte. Un progrès réel mentionnerait des filtres d'export, des rôles BGP, OTC, ASPA, des alarmes de comptage de routes et une vérification indépendante.

Le dossier devient plus sévère si les fuites AS8048 se répètent avec les mêmes formes de chemin, si les alertes sont ignorées, ou si l'opérateur refuse de concilier les collecteurs publics avec ses journaux internes. Il devient moins sévère si une clôture technique montre une durée courte, un trafic peu sélectionné, un retrait propre, une correction testée et une période sans récidive.

Sources

  1. https://blog.cloudflare.com/bgp-route-leak-venezuela/
  2. https://loworbitsecurity.com/radar/radar16/
  3. https://blog.apnic.net/2026/05/25/ephemeral-leaks-and-automated-bgp-route-leak-detection/
  4. https://fastnetmon.com/2026/01/09/venezuelas-routing-anomaly-and-the-bigger-problem-with-bgp-security/
  5. https://www.rfc-editor.org/rfc/rfc7908
  6. https://www.rfc-editor.org/rfc/rfc9234
  7. https://www.rfc-editor.org/rfc/rfc8212
  8. https://www.rfc-editor.org/rfc/rfc6811