Quatre classes d’attaques BGP n’ont aucune défense cryptographique, et l’incident Prefix-SID de mai 2025 l’a montré

20 mai 2025. Un UPDATE BGP porteur d’un attribut Prefix-SID corrompu — attribut optionnel transitif, code 40 — est émis par un AS de la région Asie-Pacifique. Dix secondes. Le temps qu’il faut au système de routage mondial pour absorber plus de 150 000 mises à jour et voir flapper les sessions de Starlink, Disney, Zscaler et ByteDance. Juillet 2026. Une enquête publiée dans IEEE Communications Surveys & Tutorials cartographie enfin le problème dans son ensemble. Le verdict tient en une phrase : RPKI et ASPA ne couvrent que deux des huit sous-catégories d’attaques BGP recensées.

Pour un opérateur réseau, c’est la différence entre une défense vérifiable — « je consulte la ROA et je rejette la route invalide » — et une défense locale — « j’ai une limite de préfixes et j’espère ».

Ce que l’incident de mai 2025 n’était pas

L’événement du 20 mai 2025 n’était ni un détournement, ni une fuite. Cisco IOS-XR et Nokia SR-OS ont fait ce que la RFC 7606 prescrit : ils ont écarté l’attribut malformé et sont passés à autre chose. Juniper JunOS l’a propagé intact. Les routeurs Arista qui l’ont reçu ont répondu en réinitialisant leurs sessions BGP. Les serveurs de route de plusieurs IXP ont relayé l’attribut sans le filtrer.

Rien de ce que RPKI valide n’a été violé à aucun moment de la chaîne. Demandez à un opérateur de classer l’événement et vous obtenez un haussement d’épaules : « pas un détournement, pas une fuite, un truc avec un attribut ». Arista a corrigé le comportement dans EOS 4.28.11 et les versions suivantes — mais l’angle mort, lui, est resté.

C’est précisément ce type d’incident qu’une enquête publiée cet été dans IEEE Communications Surveys & Tutorials (DOI 10.1109/COMST.2026.3714569, fruit d’une collaboration entre l’université Sapienza de Rome, Namex et l’Agence nationale italienne de cybersécurité, ACN) a entrepris de classer. Elle revisite les questions ouvertes posées en 2011 par Huston, Rossi et Armitage et demande ce qui a réellement changé en quinze ans.

Quatre familles, huit sous-catégories

La contribution de l’enquête n’est pas de nouvelles attaques — la plupart des distinctions existent déjà dans les RFC et la pratique opérationnelle — mais une structure unique à la nomenclature cohérente. Quatre macro-catégories, huit micro-catégories :

• Manipulation de route : le détournement de préfixe (PRH, prefix hijack) dans ses variantes complète, incomplète, par interception et abusive, et la manipulation d’AS_PATH (ASM) — empoisonnement, injection d’origine forgée, raccourcissement ou allongement de chemin.
• Cohérence du routage : la volatilité d’état (VOL) — flapping perturbateur, inondation par oscillation, injection de churn amplifié, convergence retardée — et la désagrégation de préfixe (DEG).
• Violation de politique : les fuites de routes (RLK) dans les quatre directions définies par la RFC 7908, et la manipulation de politique (POL) via Local Preference, MED, longueur d’AS_PATH et propagation sélective.
• Attaque de session : la réinitialisation de session par attribut (ATR) — injection d’attribut optionnel transitif malformé, exploitation spécifique à un constructeur, abus de la politique de traitement d’erreur. C’est la case où vit l’événement de mai 2025.

La valeur de cette taxonomie est de rendre chaque classe cartographiable : on peut désormais poser la question « quelle défense couvre quelle classe » et obtenir une réponse nette, au lieu d’évaluer chaque mécanisme isolément.

Là où la couverture existe réellement

La superposition des défenses sur cette grille produit un tableau déséquilibré, facile à manquer quand on juge chaque mécanisme seul.

PRH est la réussite, avec des réserves. IRR et RPKI fournissent la validation d’origine, et la couverture ROA grimpe. Mais la couverture n’est pas l’application : une étude longitudinale sur plus de 28 000 AS montre que 36,2 % n’implémentent pas ROV du tout et que 12,3 % seulement atteignent une protection complète. Le maxLength permissif élargit la surface d’attaque au lieu de la réduire — d’où la RFC 9319.

ASM est partiellement traité en théorie et à peine en pratique. BGPsec existe, est implémenté, et reste essentiellement non déployé : un seul AS non adoptant dans le chemin retire l’information de sécurité, ce qui rend le déploiement partiel proche de l’inutile.

RLK est le chantier le plus encourageant. Les objets ASPA sont publiables dans les registres RIR depuis décembre 2025 — 1 314 étaient enregistrés au moment de la rédaction — et un déploiement par des AS stratégiquement placés pourrait réduire jusqu’à 96 % le nombre d’AS touchés par les fuites. L’attribut OTC et la communauté Down Only, tous deux construits sur les rôles de la RFC 9234, pourraient supprimer plus de 98 % des fuites multi-sauts s’ils étaient adoptés sélectivement sur les réseaux Tier-1 et Tier-2 bien connectés.

Les quatre classes sans réponse cryptographique

VOL, DEG, POL et ATR n’ont aucune réponse cryptographique. Pas une réponse partiellement déployée : aucune. Elles sont traitées par le durcissement opérationnel — control-plane policing, limites de préfixes, filtres de longueur de préfixe, hygiène de politique, traitement d’erreur robuste et filtrage d’attributs sur les serveurs de route. Tout cela est local, réactif et invérifiable par la partie qui subit les conséquences.

Il n’existe aucun équivalent de « vérifier la ROA et rejeter l’invalide », aucun état global interrogeable. Quand un opérateur demande s’il est protégé contre une inondation de désagrégation venue d’un pair, la réponse honnête est : vous avez une limite de préfixes et un espoir.

Deux choses ont déplacé le risque. La première est l’arithmétique IPv6. La désagrégation abusive en IPv4 est bornée par ce que l’attaquant détient réellement. En IPv6, non : dans un seul /29, jusqu’à 524 288 /48 distincts peuvent être générés et annoncés, alors que la table BGP IPv6 mondiale compte environ 219 000 entrées. Une allocation, un routeur, et la table fait plus que doubler — et la défense, une limite de préfixes statique, casse aussi la croissance légitime si elle est réglée trop serrée, ce qui est précisément pourquoi les opérateurs la règlent lâche.

La seconde est l’économie de l’attention des attaquants. À mesure que l’application de ROV progresse, le rendement marginal du détournement de préfixe baisse, et celui des classes que personne ne valide monte. C’est l’effet ordinaire d’un contrôle qui couvre bien une seule chose : il redirige l’effort ailleurs.

Ce qu’il faut faire

L’action se joue à deux niveaux, selon que vous opérez un AS ou non.

Si vous opérez un AS, commencez par mesurer votre exposition réelle. Votre couverture ROV et vos éventuels enregistrements ASPA ne protègent que deux sous-catégories sur huit. Pour les quatre autres, la protection est une liste de contrôles locaux qu’il faut durcir, pas supposer : une limite de préfixes par pair avec un seuil qui n’étrangle pas la croissance légitime, des filtres de longueur de préfixe cohérents avec vos annonces réelles, le control-plane policing sur les sessions eBGP, et la conformité RFC 7606 sur le traitement d’erreur pour ne pas transformer un attribut malformé en réinitialisation de session.

Si vous achetez du transit ou du cloud, la question à poser à votre fournisseur n’est plus « faites-vous du RPKI » — presque tout le monde répond oui désormais — mais « que se passe-t-il quand un pair vous envoie un attribut malformé ou une inondation de désagrégation ? ». Un fournisseur qui ne peut pas répondre précisément ne vous protège que sur la moitié du spectre des incidents de routage.

Verdict

RPKI et ASPA ont résolu — partiellement — le détournement et la fuite. Les quatre autres classes d’attaques BGP restent défendues par des pratiques locales que personne ne peut vérifier à distance, et l’incident Prefix-SID du 20 mai 2025 a montré que leur coût se compte en dix secondes et en 150 000 mises à jour, pas en jours.

Le signal de fond de l’enquête est sans appel : en quinze ans, les solutions « optimales » (S-BGP, soBGP, psBGP) n’ont mené nulle part, et « assez bon et déployable » a gagné à chaque fois. La prochaine amélioration réelle ne viendra pas d’une nouvelle cryptographie, mais d’un durcissement opérationnel systématique sur les classes que la cryptographie ne touchera jamais — et d’une exigence de transparence vis-à-vis de vos fournisseurs de transit.

Références

• RIPE Labs — Beyond Origin Validation: Four Classes of Routing Attack Nobody Is Validating, Antonio Prado, 21 juillet 2026
• IEEE Communications Surveys & Tutorials — Survey on Internet Routing Security, DOI 10.1109/COMST.2026.3714569, 2026
• RFC 7606 — Revised Error Handling for BGP UPDATE Messages, IETF
• RFC 9234 — Route Leak Prevention and Detection Using Roles, IETF, mai 2022
• RFC 9319 — The Use of maxLength in the RPKI, IETF