Qu’est-ce que RPKI et pourquoi est-ce important ?
Le trafic qui traverse les réseaux Internet est acheminé selon BGP (Border Gateway Protocol). BGP suppose que chaque système autonome (AS) est honnête lorsqu’il annonce les préfixes IP qu’il contrôle. Ce modèle de confiance est fragile. Des annonces malveillantes, des erreurs de configuration ou des attaques délibérées peuvent revendiquer des préfixes qu’ils ne contrôlent pas, provoquant des détournements de préfixes ou des fuites de routes.
Pour renforcer cette sécurité, Resource Public Key Infrastructure (RPKI)a été développé. Ce système cryptographique permet aux détenteurs de préfixes IP de déclarer quel AS peut être à l’origine des annonces de routes pour leurs préfixes. Les autres réseaux peuvent valider les mises à jour BGP à partir de ces déclarations.
Le composant central de RPKI est l’autorisation d’origine de route (ROA). Une ROA indique qu’un AS est autorisé à annoncer un préfixe donné et peut inclure une longueur maximale de préfixe. Lorsqu’une mise à jour BGP arrive, les réseaux qui exécutent Route Origin Validation (ROV) comparent les annonces entrantes aux ROA existantes et les classent comme valides, invalides ou inconnues.
Actuellement, seule la validation d’origineest prise en charge ; la validation du chemin AS complet, c’est-à-dire le trajet précis suivi par un paquet, nécessite BGPsec, un mécanisme plus complexe et encore peu déployé.
En résumé, RPKI fournit une méthode permettant d’établir plus solidement qui est autorisé à annoncer quels blocs IP, ajoutant ainsi une barrière de protection au routage mondial.
Histoire, normes et gouvernance
RPKI et les normes qui l’accompagnent ont été élaborés par le groupe de travail SIDR (Secure Inter-Domain Routing) de l’IETF.
Les principaux documents de référence sont :
RFC 6480: architecture de RPKI
RFC 6482/6483: profils et validation des ROA
RFC 6810: protocole RPKI-to-Router
Chaque RIR (registre Internet régional) peut être considéré comme une ancre de confiance. Il délivre des certificats de ressources aux Local Internet Registries (LIRs) ou à d’autres détenteurs de ressources, reflétant l’attribution des préfixes IP et des numéros AS. Ces certificats forment une hiérarchie qui soutient l’émission des ROA.
Les opérateurs peuvent choisir d’exploiter leurs propres autorités de certification ou de déléguer cette fonction à un service RPKI hébergé proposé par le RIR.
Côté consommateur, les routeurs obtiennent des données validées auprès de validateurs relying-party, qui recueillent les informations des ROA dans les dépôts RPKI distribués au moyen de protocoles tels que rsync ou RRDP (RPKI Repository Delta Protocol).
Toutefois, aucune organisation unique n’impose l’adoption. L’efficacité de RPKI dépend fortement des effets de réseau: plus les réseaux adoptent à la fois la signature de l’origine et la validation, plus chaque participant en tire de valeur.
Avantages de RPKI pour la sécurité du routage
Prévenir les détournements manifestes et les erreurs de configuration
L’un des principaux avantages consiste à détecter les annonces d’origine non autorisées. Si un réseau tente d’annoncer un préfixe sur lequel il n’a aucun droit, les pairs qui exécutent ROV peuvent déclarer cette annonce invalide puis la rejeter ou lui accorder une priorité moindre, ce qui réduit le risque de détournement de préfixe.
De nombreux incidents de routage proviennent aussi de simples erreurs de configuration ou « fautes de frappe ». RPKI contribue à atténuer ces problèmes.
Limiter l’étendue des dommages
Le routage étant interdépendant, un réseau défaillant peut provoquer des perturbations bien au-delà de son propre périmètre. En rejetant tôt les origines invalides, RPKI aide à contenir les dommages.
Signaler la confiance et la responsabilité
Le fait de disposer de ROA enregistrées publiquement apporte de la transparence. Les autres opérateurs peuvent voir quels préfixes sont signés, ce qui témoigne d’une discipline opérationnelle et d’une bonne hygiène du réseau.
Permettre de futures améliorations et la validation des chemins
Bien que RPKI se concentre aujourd’hui principalement sur la validation d’origine, il pose les bases d’une sécurité du routage plus avancée, notamment BGPsec pour la validation des chemins et des extensions telles que ASPA (AS Path Authorization).
À long terme, une infrastructure RPKI mondiale pourrait augmenter le coût des détournements de routes pour les attaquants et améliorer la confiance générale dans le routage interdomaines.
État actuel de l’adoption et difficultés : statistiques de déploiement et lacunes
La couverture par les ROA a progressé, mais reste partielle. Selon des mesures récentes, environ 40–50 % des préfixes IPv4 disposent de ROA valides, et une proportion similaire ou légèrement supérieure est observée pour IPv6.
Cependant, moins de réseaux appliquent activement ROV sur leurs routeurs. Cloudflare, par exemple, publie des données comparant l’adoption de la « signature de l’origine » et de la « validation de l’origine ».
L’écart entre signature et validation constitue une lacune critique: la protection ne fonctionne que lorsque les deux parties participent activement.
Crainte opérationnelle : faux positifs et perte de connectivité
L’une des raisons pour lesquelles certains opérateurs hésitent est la crainte de faux positifs: des ROA mal configurées pourraient déclarer invalides des annonces légitimes et entraîner le rejet involontaire de routes.
Les opérateurs peuvent également craindre que l’application du rejet des routes invalides les déconnecte de certaines destinations. Ces risques exigent une planification rigoureuse, un déploiement progressif et des politiques de repli.
Vulnérabilités des relying-party et des dépôts
Des recherches récentes ont révélé des vulnérabilités dans le logiciel de validation RPKI des « relying parties ». Par exemple, CUREanalysis a identifié des failles susceptibles de permettre l’empoisonnement des routes ou de désactiver la logique de validation.
Une autre catégorie d’attaque,Stalloris, a montré comment un attaquant pourrait bloquer la récupération des données des dépôts, obligeant les routeurs à fonctionner de manière non sécurisée.
Une étude systémique de 2024 a indiqué que 56 % des validateurs RPKI mondiaux présentaient au moins une vulnérabilité documentée.
L’une des initiatives visant à atténuer ces problèmes est la conception Byzantine-secure relying party (BRP), qui cherche à décentraliser la validation et améliorer la résilience.
Politiques fragmentées et mise en œuvre incohérente
La logique des ROA et de la validation comprend des cas ambigus ou insuffisamment définis dans les RFC, ce qui entraîne des comportements divergents entre les différentes implémentations.
Certains réseaux appliquent un filtrage strict, d’autres se limitent à la surveillance et d’autres encore l’appliquent partiellement selon les catégories de préfixes.
Le routage étant mondial, les politiques incohérentes réduisent les bénéfices de sécurité. Si seuls certains routeurs rejettent les routes invalides, les annonces malveillantes peuvent encore se propager par des chemins plus permissifs.
Évolutivité, automatisation et outils
Certains opérateurs citent la facilité d’utilisation, la complexité et le manque d’outils comme obstacles. Automatiser la gestion des ROA, synchroniser les caches des validateurs et les intégrer aux plateformes de routage reste difficile.
En outre, la dépendance à rsync pour synchroniser les dépôts est jugée peu sûre ou inefficace par certains experts, ce qui a conduit à proposer de privilégier RRDP.
Certains réseaux retardent l’émission des ROA jusqu’à ce que la validation soit largement adoptée ; toutefois, cela perpétue la lenteur de l’adoption.
Bonnes pratiques pour les opérateurs qui déploient RPKI
Commencer en mode surveillance
Déployez ROV de manière passive en signalant les routes invalides sans les rejeter. Surveillez les invalides involontaires avant d’appliquer la politique.
Concevoir les ROA avec soin
Utilisez des paramètres maxLength prudents. Évitez des préfixes trop larges ou trop stricts qui pourraient invalider accidentellement des annonces légitimes.
Application progressive et routes de secours
Ne commencez à rejeter les routes invalides qu’après une période d’observation suffisante et en présence de routes de secours. Appliquez la validation progressivement.
Une infrastructure de validateurs robuste
Utilisez plusieurs instances de validateurs, choisissez un logiciel fiable, surveillez les lacunes et envisagez des systèmes résilients tels que BRP.
Maintenir les données des ROA et des validateurs à jour
Synchronisez fréquemment, surveillez les défaillances des dépôts et prévoyez des mesures d’atténuation lorsque les données sont obsolètes.
Coordonner les actions avec les pairs et les upstreams
Encouragez les autres acteurs du chemin à valider. La participation de nombreux réseaux renforce les bénéfices.
Suivre des initiatives communautaires comme MANRS
Des normes telles que les directives d’hygiène du routage complètent l’adoption de RPKI.
Auditer et mettre à jour régulièrement
Examinez régulièrement les ROA. Les changements de propriété d’un AS, les fusions ou les réattributions d’IP nécessitent des mises à jour.
Le dilemme de « l’effet de réseau » et les incitations
Un obstacle majeur tient au fait que le bénéfice n’apparaît que lorsque de nombreux réseaux valident. Un opérateur qui signe, mais dont les pairs ne valident pas, est moins protégé. À l’inverse, l’application de la validation peut rompre la connectivité avec les réseaux non conformes, ce qui ralentit le déploiement.
Certains estiment que la réglementation ou les incitations du secteur pourraient aider. D’autres invoquent des raisons économiques : les opérateurs réseau qui proposent un « transit sécurisé » pourraient facturer un supplément s’ils appliquent ROV. Les fournisseurs de contenu pourraient également exiger la conformité à ROV des hébergeurs pour des raisons de sécurité.
Des préoccupations juridiquesapparaissent également. Une étude sur les obstacles juridiques a indiqué que les tribunaux considéreraient rarement les certificats RPKI comme défectueux si les RIR respectent les normes de l’IETF.
Principales limites et risques résiduels
Même avec une validation d’origine parfaite, RPKI n’empêche pas toutes les attaques BGP :
Manipulation des chemins: RPKI ne vérifie pas chaque saut d’AS ; les attaquants peuvent encore falsifier les chemins AS. Ce problème est traité par BGPsec, qui reste largement non déployé.
Attaques par dégradation et interférence avec les dépôts: si des attaquants bloquent les dépôts RPKI ou empêchent les validateurs d’y accéder, les réseaux peuvent revenir à un routage non sécurisé.
Logiciel de validation vulnérable: comme l’ont montré de récents audits CURE, des erreurs peuvent entraîner des validations incorrectes ou l’empoisonnement des routes.
Politiques partielles ou incohérentes: si certaines parties d’Internet n’appliquent ni ne signent les ROA, des routes invalides peuvent encore emprunter des chemins permissifs.
Erreurs opérationnelles: des ROA mal configurées ou l’absence de mises à jour peuvent provoquer des dommages collatéraux.
RPKI constitue donc une amélioration importante, mais pas une solution complète. Il révèle toute sa valeur lorsqu’il est associé à d’autres mesures, telles que le filtrage des routes, l’hygiène au niveau des pairs et, à terme, des systèmes de validation du chemin complet.
La voie à suivre : ce qui doit évoluer
Résilience et décentralisation des validateurs: utilisation à grande échelle d’architectures robustes, par exemple BRP, afin de réduire la dépendance aux points uniques de défaillance.
Amélioration des outils et de l’automatisation: interfaces plus efficaces, intégration aux systèmes de routage, alertes et outils de gestion du cycle de vie des ROA.
Coordination communautaire et incitations: pairs, IXPs et opérateurs signant des accords mutuels, voire exigeant la conformité à ROV pour les interconnexions.
Amélioration de la sensibilisation et de la formation: de nombreux ISP et équipes réseau connaissent encore mal RPKI.
Déploiement de normes complémentaires: ASPA, BGPsec et les normes associées doivent mûrir et être réellement adoptés.
Si ces éléments convergent, l’infrastructure de routage d’Internet deviendra au fil du temps beaucoup plus résistante aux détournements et aux fuites.
Questions fréquentes : RPKI et sécurité du routage
Que signifie la déclaration d’une route comme « invalide » ?
Si une annonce BGP est invalide selon ROV, c’est-à-dire qu’elle n’est couverte par aucune ROA ou que l’AS d’origine ne correspond pas, les routeurs peuvent la rejeter, lui accorder une priorité moindre ou lui attribuer une préférence inférieure.Un préfixe peut-il avoir plusieurs ROA ?
Oui. Il peut exister plusieurs ROA pour le même préfixe avec différents AS d’origine valides. La logique de validation doit gérer soigneusement les unions ou les conflits.RPKI garantit-il une sécurité complète du routage ?
Non. RPKI ne couvre que la garantie de l’origine, et non la vérification complète du chemin. Les attaquants peuvent encore usurper des chemins AS ou provoquer d’autres anomalies.Que se passe-t-il si les données du validateur sont obsolètes ou inaccessibles ?
Les routeurs peuvent considérer les annonces comme inconnues et donc les autoriser. Toutefois, en cas de perte de connectivité, ce mécanisme pourrait être exploité commevecteur de dégradation.Comment les petits réseaux ou fournisseurs de contenu peuvent-ils adopter RPKI ?
Ils peuvent utiliser des services RPKI hébergés par leur ISP ou leur RIR. Même sans exploiter leur propre validateur, ils peuvent émettre des ROA et signaler l’autorisation de l’origine.
