Démystifier les préfixes invalides du RPKI : causes cachées et risques réels
En résumé :
- Malgré l'adoption généralisée de l'infrastructure à clé publique des ressources (RPKI), des milliers de routes restent signalées comme non conformes à la RPKI, sans que leur nombre ne diminue de manière significative.
- Les deux principales causes d'invalidité du RPKI sont les services de transit IP opaques et la location d'adresses IP.
- Deux préfixes sur cinq parmi ceux concernés subissent une augmentation de la latence supérieure à 100 millisecondes.
L'infrastructure à clé publique des ressources (RPKI) est devenue un pilier de la sécurité sur Internet. Elle permet aux réseaux de vérifier si une annonce de route — c'est-à-dire, en substance, une déclaration indiquant qui détient et exploite un bloc d'adresses IP — est légitime. Ce faisant, elle joue un rôle essentiel dans la prévention du détournement de routes, une menace de longue date susceptible de rediriger le trafic, de perturber les services ou de faciliter la surveillance.
Dans notre article intitulé «Démystifier les préfixes non valides selon le RPKI : causes cachées et risques de sécurité», nous avons, à Virginia Tech, en collaboration avec CableLabs, mené la première étude exhaustive visant à comprendre pourquoi des routes non conformes au RPKI persistent, à identifier leurs causes profondes et à mesurer leur impact concret sur le routage Internet.
Que sont les préfixes non valides RPKI ?
Au cours des dernières années, l'adoption du RPKI s'est développée rapidement. Aujourd'hui, plus de la moitié de toutes les routes Internet sont protégées par des autorisations cryptographiques (appelées ROA). Cette évolution est largement considérée comme une avancée majeure pour la sécurisation du routage mondial.
Mais il y a un problème. Malgré un déploiement généralisé, des milliers de routes sont toujours signalées comme non valides selon la RPKI. Notre étude récente révèle que plus de 6 000 routes invalides apparaissent chaque jour dans le système de routage mondial, avec des dizaines de milliers observées au fil du temps, et que ce nombre n’a pas diminué de manière significative, comme le montre la figure 1. Cela soulève une question importante : si le RPKI fonctionne, pourquoi ces routes invalides persistent-elles ?
Quelles sont les causes des routes non valides selon le RPKI ?
Outre les erreurs de configuration bien connues et facilement détectables, telles que celles existant entre des AS appartenant à la même organisation, nous avons identifié deux causes profondes majeures, mais moins visibles, de l'invalidité du RPKI :
Location de propriété intellectuelle
Les adresses IPv4 se faisant de plus en plus rares, les organisations louent souvent des préfixes IP au lieu d'en être directement propriétaires. Dans la plupart des cas, le propriétaire d'origine conserve le contrôle des enregistrements RPKI, tandis que le locataire annonce les préfixes dans le BGP.
Des problèmes surviennent lorsque l'autorisation RPKI n'est pas mise à jour pour inclure le réseau du locataire. En conséquence, des annonces de routage parfaitement légitimes peuvent être considérées comme non valides, non pas en raison d'une attaque, mais à cause d'un manque de coordination entre les parties.
Transit IP opaque
Les services réseau modernes, tels que la protection contre les attaques DDoS ou le tunneling de trafic, peuvent masquer la véritable origine d'un préfixe. Dans ce type de configuration, un fournisseur peut annoncer le préfixe d'un client sur son propre réseau, tout en acheminant le trafic en interne vers ce client.
Du point de vue du RPKI, l'origine observée ne correspond plus à celle qui a été autorisée ; l'itinéraire est donc classé comme non valide. Ces pratiques sont souvent intentionnelles et nécessaires d'un point de vue opérationnel, mais elles ne sont pas toujours compatibles avec les modèles de validation actuels.
Ensemble, nous avons constaté que plus de 96 % des préfixes non valides selon le RPKI figurant dans les tables de routage IPv4 actuelles, collectées auprès de Routeviews, sont dus à des erreurs de configuration que nous pouvons expliquer et classer dans la figure 2.
Quelles en sont les répercussions concrètes ?
Ces routes non valides selon le RPKI ont des conséquences concrètes sur le fonctionnement d'Internet. Afin de mesurer leur impact concret, nous avons lancé des mesures ping et traceroute via le protocole ICMP (Internet Control Message Protocol) à partir de plus de 5 000 sondes RIPE Atlas réparties sur plus de 1 600 AS à travers le monde, en ciblant des hôtes actifs au sein de plus de 4 000 préfixes non valides selon le RPKI. Nous avons constaté que
- 3,1 % des préfixes non valides selon le RPKI subissent une perte de connectivité depuis au moins un point d'observation du réseau. Ce constat remet en cause l'hypothèse selon laquelle les routes non valides sont inoffensives tant qu'un chemin de secours est disponible, une hypothèse couramment admise aujourd'hui.
- 18,5 % des préfixes non valides selon le RPKI subissent des modifications de routage involontaires. Ces réacheminements contournent fréquemment les réseaux en amont destinés à fournir des services de sécurité tels que l'atténuation des attaques DDoS ou l'inspection du trafic. L'impact sur les performances est considérable : la quasi-totalité des préfixes concernés subissent une augmentation de la latence, et 39,2 % d'entre eux enregistrent des hausses de latence supérieures à 100 millisecondes. De nombreux préfixes traversent également un nombre nettement plus élevé de sauts AS, ce qui accroît leur exposition à la congestion et élargit leur surface d'attaque.
Aller au-delà d'une hygiène passive
La persistance d'itinéraires non valides dans le RPKI met en évidence un écart critique entre l'autorisation cryptographique et les réalités opérationnelles du transit IP et de la location de bandes passantes modernes. Pour combler cet écart, la communauté doit aller au-delà de la création passive d'autorisations ROA et adopter une hygiène de routage proactive.
Tout d'abord, les opérateurs de réseau doivent aligner leurs pratiques sur des initiatives telles que le MANRS (Mutually Agreed Norms for Routing Security). Le respect des directives du MANRS garantit que les organisations filtrent non seulement les routes invalides, mais assurent également une coordination rigoureuse entre leur stratégie de routage et leurs enregistrements RPKI.
Pour les organisations impliquées dans la location d’adresses IP ou dans des montages de transit complexes — tels que les centres de filtrage destinés à atténuer les attaques DDoS —, la gestion manuelle des ROA n’est plus viable. Les opérateurs doivent intégrer la création et la suppression des ROA directement dans leurs processus automatisés de mise en service du réseau afin d’éviter les défaillances de coordination qui sont à l’origine de la grande majorité de ces adresses invalides.
De plus, la communauté doit passer d’une mentalité consistant à « configurer puis oublier » à une validation continue de l’état du RPKI. Il est essentiel de tirer parti d’outils de surveillance proactive pour signaler les divergences d’origine BGP avant qu’elles ne se propagent à l’échelle mondiale. Les discussions au sein du groupe de travail SIDROPS (SIDR Operations) de l’IETF soulignent le besoin urgent de telles directives opérationnelles et d’outils améliorés.
En définitive, le RPKI reste le pilier de la sécurité du routage à l'échelle mondiale, mais son efficacité dépend de l'adaptation de nos modèles opérationnels à la complexité structurelle de l'Internet actuel. Nous invitons instamment les opérateurs de réseau à procéder à un audit de leurs configurations actuelles en matière de location d'adresses IP et de transit, et nous invitons les chercheurs et les décideurs politiques à collaborer à l'élaboration de modèles d'autorisation plus souples, capables de prendre en compte les pratiques légitimes de routage opaque sans compromettre la sécurité.
Lisez notre article et suivez notre présentation lors du NDSS 2026 pour en savoir plus.
Weitong Li est chercheur postdoctoral à Virginia Tech, où ses travaux portent sur la mesure et la sécurisation de l'infrastructure de routage Internet.
Les opinions exprimées par les auteurs de cet article de blog n'engagent qu'eux-mêmes et ne reflètent pas nécessairement celles de l'Internet Society.
