ASPA reste déployé sur 3 % des ASN et 99 % des fuites BGP passent encore au travers

Juin 2019. Une fuite de routes détourne le trafic européen via China Telecom pendant 2 h 15. Août 2026. La validation d’origine RPKI (ROV) dépasse 60 % de déploiement chez les grands transitaires — et les fuites de routes continuent. La raison tient en une phrase : le RPKI ne valide jamais le chemin, seulement l’origine.

Pour un opérateur réseau, c’est la différence entre un détournement — qu’un filtre ROV bloque — et une fuite, invisible pour RPKI. La correction existe, elle s’appelle ASPA, mais elle n’est déployée que sur 3 % des ASN.

RPKI valide l’origine, pas le chemin

Le mécanisme est précis. RPKI (Resource Public Key Infrastructure) s’appuie sur des ROA (Route Origin Authorizations) : un enregistrement signé qui dit « le préfixe 192.0.2.0/24 ne peut être annoncé QUE par AS 65000 ». La Route Origin Validation compare chaque annonce BGP reçue à cette base et classe le préfixe Valid, Invalid ou NotFound.

Ce que RPKI ne dit jamais, c’est si le chemin emprunté par l’annonce est légitime. Une route peut avoir une origine valide et un chemin fui. Si AS 65000 annonce 192.0.2.0/24 à un client, et que ce client le ré-annonce à un autre fournisseur, l’origine reste AS 65000, la ROA reste valide, et RPKI ne voit aucune violation. Le trafic transite pourtant par un AS de travers.

C’est exactement ce qui distingue une fuite d’un détournement. Le détournement usurpe l’origine ; la fuite conserve l’origine mais viole la topologie. RPKI a résolu le premier problème. Il est structurellement aveugle au second.

Deux incidents, deux défenses

La distinction entre fuite et détournement n’est pas un détail de classification : elle change la défense à déployer. Un détournement — l’annonce d’un préfixe par un AS non autorisé — se combat avec ROV. Une fuite — la ré-annonce d’une route au-delà de sa portée légitime — se combat avec ASPA.

Les deux protections sont complémentaires et s’empilent sans se gêner. ROV répond à « qui a le droit d’annoncer ce préfixe » ; ASPA répond à « cette route emprunte-t-elle un chemin plausible ». Un réseau qui déploie les deux filtre à la fois les usurpations d’origine et les violations de topologie.

C’est le point que les retardataires comprennent trop tard : RPKI a créé un faux sentiment de sécurité. À 53 % de couverture ROA, beaucoup d’opérateurs pensent avoir « fait leur part ». Leurs préfixes peuvent pourtant fuir par un client ou un pair négligent, sans que ROV lève le petit doigt.

ASPA, le complément de chemin qui manque

ASPA (Autonomous System Provider Authorization, RFC 9234) est le pendant de RPKI pour le chemin. Un enregistrement ASPA dit « AS 65000 autorise AS 65100 comme fournisseur ». Avec des enregistrements ASPA pour chaque AS d’un chemin, un routeur peut vérifier que le chemin a un sens topologique : le trafic doit circuler client → fournisseur → fournisseur → client, jamais latéralement entre deux fournisseurs.

Une route qui traverse une vallée — le motif fournisseur → client → fournisseur — est la signature d’une fuite. Un routeur conscient d’ASPA détecte ce motif et rejette la route. C’est précisément ce que RPKI pur ne peut pas faire.

La distinction n’est pas académique. Elle détermine quels incidents votre réseau peut bloquer automatiquement, et lesquels il subira passivement jusqu’à ce qu’un humain les remarque dans un graphe de monitoring.

Les chiffres de PeerCortex : 99 % des fuites sur des chemins sans ASPA

La plateforme PeerCortex a mesuré l’état du déploiement sur 70 847 ASN. Le constat est net :

Le chiffre qui résume tout : sur 1 247 événements de fuite en 90 jours, 99 % sont passés par des chemins sans couverture ASPA. Les 12 qui ont traversé des chemins protégés relèvent de cas de déploiement partiel — un AS du chemin possède des enregistrements, un intermédiaire non. La protection d’un chemin exige la couverture de tout le chemin.

Le contraste avec RPKI est éloquent : 53,6 % de couverture ROA contre 3 % d’ASPA. La première moitié du problème — l’origine — est en voie de résolution. La seconde — le chemin — n’a pas commencé.

Pourquoi seulement 3 %

La charge opérationnelle d’ASPA est faible. Documenter ses relations de transit : quatre fournisseurs amont signifient quatre enregistrements ASPA, une configuration unique, puis une maintenance occasionnelle quand un fournisseur change. Pour un réseau stable, c’est trente minutes.

La barrière est ailleurs : la notoriété et l’outillage. La plupart des ingénieurs réseau qui connaissent RPKI ignorent qu’ASPA existe. Les grandes plateformes de gestion RPKI — Krill, le portail Cloudflare RPKI — ont ajouté le support ASPA en 2024–2025, mais la documentation opérationnelle reste mince. Le standard est jeune : la RFC 9234 date de mai 2022, et les implémentations sur routeurs prennent du temps à se propager.

C’est un problème d’action collective classique. ASPA est le plus efficace quand il est largement déployé : à 3 %, il bloque les fuites entre réseaux déjà couverts ; à 30 %, il couvrirait la majorité des grands chemins de transit. Les premiers déployeurs rendent service à tout l’Internet.

Ce qu’il faut faire : publier vos ASPA

L’action est concrète et mesurable. Si vous opérez un AS, publiez vos enregistrements ASPA pour vos relations amont auprès de votre RIR, en complément de vos ROA existantes. Le coût est de trente minutes pour un réseau au transit stable — moins que la rédaction du post-mortem d’une fuite.

Pour vérifier où vous en êtes, PeerCortex expose votre statut ASPA aux côtés de la santé RPKI, de l’historique des fuites et d’autres indicateurs, sans inscription. C’est le premier réflexe à avoir avant de toucher à la configuration.

Si vous ne contrôlez pas votre routage — hébergement cloud, transit IP acheté — la question à poser à votre fournisseur est simple : « publiez-vous des ASPA et validez-vous les chemins reçus ? ». Un fournisseur qui bloque les détournements mais laisse passer les fuites ne vous protège qu’à moitié.

Verdict

Si vous opérez un AS, publier vos enregistrements ASPA est le geste au meilleur rapport effort/protection de l’année : trente minutes pour combler l’angle mort que RPKI ne couvrira jamais. Commencez par vos relations de transit stables, vérifiez votre statut sur PeerCortex, et étendez à mesure que vos fournisseurs changent.

Si vous achetez du transit, ajoutez ASPA à vos critères d’évaluation de fournisseur. Un opérateur qui valide l’origine sans valider le chemin laisse ses clients exposés à la moitié des incidents de routage — et ne le sait probablement pas lui-même.

Le signal de fond : RPKI a pris dix ans pour atteindre 53 %. ASPA part de plus bas, mais le problème qu’il résout — la fuite, pas le détournement — est celui qui cause encore le plus d’incidents silencieux. La moitié du travail de sécurisation de BGP reste à faire, et elle ne se fera pas toute seule.

Références

• Fichtmueller.org — Route Leaks in 2026: Still Happening, Still Causing Outages, consulté le 17 août 2026
• RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, IETF, mai 2022
• PeerCortex — Network Intelligence Platform, données consultées le 17 août 2026