Résumé

  • En 2025, la table consultable de SEACOM montrait la route légitime de SingNet vers 203.127.0.0/16, mais pas le sous-préfixe 203.127.225.0/24 annoncé par Innove. Un traceroute depuis SEACOM atteignait pourtant des sauts du réseau Innove.
  • ROV qualifie l’origine d’une annonce ; la politique locale décide de son rejet. Elle ne commande ni la table du voisin ni l’acheminement ultérieur des paquets.
  • BMP donne une vue structurée des annonces reçues par les routeurs effectivement surveillés. Il ne transforme pas une collecte locale en mesure du réseau voisin ou du plan de données.

Le /24 absent, le trajet présent

La commande la plus importante n’a renvoyé aucune route. Dans les relevés reproduits par Li et ses collègues, le looking glass de SEACOM (AS37100) ne trouvait pas 203.127.225.0/24. Il affichait en revanche le /16 de SingNet (AS3758), d’origine valide. Cette absence pouvait rassurer l’opérateur : le sous-préfixe non autorisé d’Innove Communications (AS17894) ne figurait pas dans sa table.

Le traceroute exécuté depuis le même réseau change la portée de cette assurance. En direction de 203.127.225.1, les sauts passent par TISparkle (AS6762), FLAG Telecom (AS15412), Globe Telecom (AS4775), puis des adresses du réseau AS17894. Selon les chercheurs, AS37100 filtrait la route invalide et AS6762 ne la filtrait pas. Le premier pouvait donc envoyer vers le /16 légitime par son voisin ; le second connaissait le /24 plus précis et réorientait le trafic. Les deux observations ne s’annulent pas. Elles décrivent des décisions prises en des lieux différents.

Le document de recherche est un Internet-Draft individuel, encore en cours de discussion, non une norme approuvée par l’IETF. Ses auteurs disent avoir signalé le cas à Globe le 10 février 2025 et l’avoir encore observé le 24 avril. Ils jugent plausible une erreur de configuration plutôt qu’une intention hostile. Le traceroute atteste un chemin observé vers des sauts AS17894 ; il ne mesure ni tous les paquets ni la qualité du service à destination.

Lors de la session technique d’APNIC 62, Ritesh Mukherjee, chez Nokia, a repris ce dossier pour poser le problème du « bon voisin ». Ses diapositives plaident pour la validation des origines, l’examen des chemins et la télémétrie. Leur portée est celle d’une proposition opérationnelle, pas d’un essai démontrant qu’un produit aurait arrêté ce cas.

Une validation n’est pas un ordre transmis

La RFC 6811 classe l’origine d’une annonce selon les autorisations ROA validées : Valid, Invalid ou NotFound. Rejeter Invalid relève d’une politique configurée dans chaque réseau. Une autorisation d’origine ne valide pas toute la chaîne AS_PATH et ne force aucun voisin à appliquer la même politique. Dans le cas SingNet, le /16 et le /24 ne deviennent pas deux versions concurrentes d’une vérité universelle. AS37100 pouvait n’avoir que le /16 ; une fois le paquet remis à AS6762, ce dernier pouvait préférer le /24, plus spécifique.

Le cas Telegram évoqué dans la même session montre un autre échec. Le 16 juin 2026, des annonces pour des préfixes Telegram ont porté l’origine AS18101, alors que 91.108.4.0/22 devait provenir d’AS62041. BGPHorizon situe une détection à 07 h 17 min 27 s UTC, observée par quatre réseaux pairs auprès de cinq collecteurs, et documente une seconde vague de sous-préfixes plus précis. Les ROA permettaient de déclarer l’origine invalide ; les collecteurs ne disent pas pour autant combien d’utilisateurs ont perdu l’accès ni pourquoi l’annonce a été lancée. Une fuite massive comme celle de Vodafone Idea en 2021 soulève encore une question différente : la limite de préfixes sur une session peut arrêter une avalanche, non trancher la légitimité d’un unique /24.

Ce qu’un observateur peut réellement promettre

Mukherjee suggère d’exporter l’Adj-RIB-In au moyen de BMP. La RFC 7854 décrit les vues avant et après politique, les instantanés initiaux et les mises à jour, mais seulement pour les pairs et les étapes effectivement configurés. Des changements intermédiaires peuvent être condensés, un horodatage peut manquer et une session du collecteur peut perdre sa continuité. Une vue avant politique permet de conserver la trace d’une annonce rejetée si le routeur l’a reçue et si cette vue est exportée. Elle ne révèle pas une annonce reçue uniquement chez AS6762.

BMP n’inspecte pas non plus le chemin des paquets. Pour rapprocher route locale et transfert réel, il faut des points de vue indépendants, un test actif bien délimité et, si possible, les relevés du voisin. Le dépôt RAVEN de Nokia expose des fonctions de corrélation BMP, ROV et ASPA ; sa documentation ne démontre ni leur déploiement dans ces réseaux ni une protection obtenue. La sortie affichée dans la présentation est indiquée comme illustrative.

Les contrôles ne sont donc pas interchangeables. ROV traite l’origine au point d’importation. La RFC 7454 recommande des plafonds de préfixes adaptés à chaque pair, utiles contre un afflux anormal mais non contre un seul sous-préfixe. La vérification ASPA reste un travail de normalisation sur les relations de fournisseur ; elle ne constitue pas la preuve rétrospective d’un incident résolu. Le dossier de 2025 démontre surtout combien une table honnêtement propre peut être une pièce insuffisante.

Sources et incertitudes

Le brouillon de Li et al., section 4 et annexe A contient les relevés essentiels. Le compte rendu APNIC situe les propos du conférencier ; BGPHorizon fournit une autre reconstruction de l’annonce Telegram. Les limites techniques sont établies par les RFC 6811, 7854 et 7454. Aucun de ces documents ne fournit un bilan exhaustif des pertes de trafic, une preuve d’intention ou une mesure de l’efficacité de RAVEN en production.