BGP : un vieux champ suffit encore à déplacer le trafic Internet

Le 24 juillet, Cloudflare a publié une étude assez dérangeante sur l’attribut ORIGIN de BGP. Ce petit champ historique, censé décrire comment une route est entrée dans BGP, est régulièrement modifié par des opérateurs réseau. Pas à la marge : dans l’expérience menée par Cloudflare, environ 70 % des chemins IPv4 observés et 67 % des chemins IPv6 avaient vu leur valeur ORIGIN remplacée par IGP.

Ce n’est pas une nouvelle faille permettant de détourner Internet avec trois commandes. C’est plus banal, donc presque plus intéressant : une règle ancienne est contournée parce qu’elle donne un avantage économique à ceux qui la contournent.

## ORIGIN n’est pas « l’origine » d’une route

BGP permet aux systèmes autonomes, ou AS, d’échanger les routes disponibles pour atteindre les différents préfixes IP. Pour choisir entre plusieurs chemins, les routeurs examinent une série d’attributs : préférence locale, longueur de l’AS_PATH, type d’origine et plusieurs critères de départage définis par leurs implémentations.

Malgré son nom, ORIGIN ne désigne pas l’AS qui annonce le préfixe. Il indique la manière dont la route a été injectée dans BGP. La RFC 4271 prévoit trois valeurs :

IGP, la valeur la plus favorable ;
EGP, héritée d’un protocole aujourd’hui obsolète ;
INCOMPLETE, utilisée lorsque l’origine exacte n’est pas connue ou vient d’un mécanisme externe.

Lorsque deux routes restent à égalité après les premiers critères de sélection, IGP est préférée à EGP, elle-même préférée à INCOMPLETE. La même RFC précise que cet attribut est créé par le routeur à l’origine de l’annonce et ne devrait pas être modifié ensuite.

Le problème tient dans ce « devrait ».

## Réécrire un champ pour attirer le trafic

Un opérateur recevant une route marquée INCOMPLETE peut la republier en IGP. Si un réseau situé plus loin reçoit deux chemins autrement équivalents, il risque alors de sélectionner celui qui contient la valeur réécrite. Le trafic passe par l’opérateur qui a modifié l’attribut, plutôt que par son concurrent.

L’étude s’appuie sur six préfixes de test, trois en IPv4 et trois en IPv6, annoncés avec les différentes valeurs ORIGIN depuis le réseau anycast de Cloudflare. Les chercheurs ont ensuite analysé les mises à jour collectées par RIPE RIS et RouteViews, notamment avec l’outil open source BGPKIT.

Sur les routes publiques observables, 89,8 % utilisent déjà IGP, contre 3,5 % pour EGP et 6,7 % pour INCOMPLETE. Mais parmi les 606 AS auxquels Cloudflare a pu attribuer un comportement, 64, soit 10,6 %, remplaçaient les valeurs moins favorables par IGP. Le phénomène est surtout concentré chez les gros acteurs : l’étude estime que 26 % des 50 premiers AS et 20 % des 100 premiers pratiquent cette réécriture.

Cette concentration explique pourquoi une minorité d’opérateurs peut toucher une majorité des chemins visibles.

## Ce n’est pas un hijack, mais le résultat se voit

Il faut distinguer cette pratique d’un détournement BGP classique. Le préfixe n’est pas annoncé par un faux propriétaire et l’AS_PATH continue d’exister. La manipulation agit plus subtilement sur le classement entre plusieurs routes valides.

Dans l’expérience, les opérateurs réécrivant ORIGIN ont obtenu 18 % de chemins supplémentaires en IPv4 et 40 % en IPv6 par rapport aux routes qui conservaient la valeur initiale. Autrement dit, ce vieux champ influence encore assez la sélection pour déplacer une part mesurable du trafic vers certains fournisseurs de transit.

Pour un développeur qui héberge une application sur un VPS, cela rappelle une limite simple : un serveur peut être sain, le DNS correct et le reverse proxy disponible, tandis que le chemin pris pour atteindre cette machine dépend de politiques appliquées bien au-delà de notre infrastructure. Une latence différente selon les régions ou certains fournisseurs d’accès ne vient pas forcément du code, de Nginx ou de la base de données.

## Supprimer le signal devenu mensonger

Cloudflare propose de réduire progressivement l’influence d’ORIGIN, voire de normaliser toutes les routes sur IGP. Une ancienne proposition de l’IETF suggérait déjà de « nettoyer » cet attribut, mais le brouillon a expiré sans devenir une norme.

L’idée est pragmatique : si un champ obligatoire peut être modifié, qu’il est difficile à vérifier et que les principaux opérateurs ont intérêt à le manipuler, il ne constitue plus un signal fiable. Continuer à l’utiliser récompense surtout les réseaux qui ont cessé de respecter son intention initiale.

Ce n’est donc pas seulement une histoire de plomberie Internet. C’est un bon exemple de dette technique à l’échelle d’un protocole : une information autrefois utile devient un levier stratégique, puis finit par nuire au système qu’elle devait aider.

## Pour aller plus loin

Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.