Le rôle de RPKI dans le renforcement de la sécurité du routage mondial
Le trafic sur les réseaux Internet est acheminé selon le protocole BGP (Border Gateway Protocol). BGP part du principe que chaque système autonome (AS) est honnête quant aux préfixes IP qu’il contrôle lors de la publication de ses annonces. Ce modèle de confiance présente toutefois des faiblesses. Des annonces malveillantes, des erreurs de configuration ou des attaques délibérées peuvent entraîner la publication de préfixes non contrôlés, conduisant à des détournements de préfixes ou à des fuites de routes.
Pour renforcer la sécurité, l’infrastructure à clés publiques de ressources (RPKI) a été développée. Ce système cryptographique permet aux détenteurs de préfixes IP d’affirmer quel AS est autorisé à publier des annonces de routes pour leurs préfixes. Les autres réseaux peuvent ensuite valider les mises à jour BGP par rapport à ces affirmations.
L’élément central de RPKI est l’autorisation d’origine de route (ROA). Une ROA atteste qu’un AS est autorisé à publier un certain préfixe et peut inclure une longueur maximale pour ce préfixe. Lors de la réception d’une mise à jour BGP, les réseaux exécutant la validation d’origine de route (ROV) comparent les annonces entrantes aux ROA existantes et les classent comme valides, invalides ou inconnues.
Aujourd’hui, seule la validation de l’origine est prise en charge ; la validation du chemin AS (c’est-à-dire le trajet précis suivi par le paquet) repose sur un mécanisme différent, plus complexe (BGPsec) et beaucoup moins répandu.
En bref : RPKI permet d’établir une vérité de référence plus fiable concernant les personnes autorisées à annoncer quels blocs d’adresses IP. Cela renforce la sécurité du routage global.
Histoire, normes et gouvernance
L’infrastructure à clés publiques (RPKI) et ses normes associées ont été développées au sein du groupe de travail SIDR (Secure Inter-Domain Routing) de l’IETF.
Parmi les documents de référence clés figurent les RFC 6480 (architecture RPKI), 6482/6483 (profils et validation des ROA) et 6810 (protocole RPKI-routeur).
Chacun de ces documents peut être considéré comme une autorité de confiance. Les RIR délivrent des certificats de ressources aux registres Internet locaux (LIR) ou à d’autres détenteurs de ressources, reflétant leur attribution de préfixes IP et de numéros de systèmes autonomes (AS). Ces certificats de ressources forment une hiérarchie qui sous-tend l’émission des ROA.
Les opérateurs peuvent choisir de gérer leurs propres autorités de certification ou de déléguer cette tâche à un service RPKI hébergé proposé par le RIR.
Côté client, les routeurs récupèrent les données validées auprès des validateurs tiers. Ces validateurs collectent les données ROA auprès des référentiels RPKI distribués (via des protocoles tels que rsync ou RRDP – le protocole delta du référentiel RPKI).
Cependant, aucune organisation n’impose l’adoption de ces données. L’efficacité de RPKI repose fortement sur les effets de réseau : plus les réseaux adoptent la signature et la validation d’origine, plus la valeur ajoutée pour chaque participant augmente.
Avantages de RPKI pour la sécurité du routage
Prévention des détournements et erreurs de configuration flagrants
Un avantage majeur réside dans la détection des annonces d’origine non autorisées. Si un réseau tente d’annoncer un préfixe sur lequel il ne dispose pas des droits, les pairs exécutant ROV peuvent invalider cette annonce et la supprimer ou la déprioriser. Cela réduit le risque de détournement de préfixe.
De nombreuses erreurs de routage proviennent de simples erreurs de configuration ou d’erreurs de saisie. RPKI contribue à les atténuer.
Limitation de l’impact
Le routage étant interdépendant, un réseau défaillant peut engendrer des perturbations bien au-delà de son périmètre. En rejetant rapidement les origines invalides, RPKI contribue à limiter les dégâts.
Signaler la confiance et la responsabilité
L’enregistrement public des ROA garantit la transparence. Les autres opérateurs de réseau peuvent ainsi voir quels préfixes sont signés, ce qui témoigne de la rigueur opérationnelle et de la qualité du réseau.
Préparer les futures améliorations (et la validation des chemins)
Si l’infrastructure à clés publiques (RPKI) est aujourd’hui principalement axée sur la validation de l’origine, elle constitue la base d’une sécurité de routage plus avancée, notamment BGPsec (validation des chemins) ou des extensions comme ASPA (autorisation des chemins AS).
À plus long terme, une infrastructure RPKI mondiale pourrait renchérir le coût des détournements de routes pour les attaquants et améliorer la confiance globale dans le routage interdomaines.
État actuel de l'adoption et défis rencontrés Statistiques et lacunes en matière de déploiement
La couverture des ROA s’est étendue, mais reste partielle. Selon des mesures récentes, environ 40 à 50 % des préfixes IPv4 disposent de ROA valides, et une proportion similaire, voire légèrement supérieure, pour IPv6.
Cependant, peu de réseaux appliquent activement la validation d’origine (ROV) au niveau de leurs routeurs. Cloudflare, par exemple, collecte des données sur l’adoption de la « signature d’origine » par rapport à la « validation d’origine ».
L’écart entre signature et validation constitue une lacune critique : la protection n’est efficace que si les deux parties s’engagent.
Crainte opérationnelle : faux positifs et perte de connectivité
L’une des raisons qui inquiètent certains opérateurs est la crainte des faux positifs : des ROA mal configurés pourraient qualifier à tort des annonces légitimes d’invalides, entraînant des interruptions de route involontaires.
Les opérateurs peuvent également craindre que l’application du rejet des routes invalides ne les déconnecte de leurs destinations. Ces risques exigent une planification rigoureuse, une préparation minutieuse et des politiques de repli adaptées.
vulnérabilités des tiers de confiance et des référentiels
Des recherches récentes ont mis en évidence des vulnérabilités dans les logiciels de validation RPKI (« parties de confiance »). Par exemple, CUREanalysis a découvert des failles permettant l’empoisonnement de routes ou la désactivation de la logique de validation.
Une autre classe d’attaques (Stalloris) a démontré comment un attaquant pouvait bloquer la récupération des données du dépôt, contraignant ainsi les routeurs à adopter un fonctionnement non sécurisé.
Une étude systémique de 2024 a révélé que 56 % des validateurs RPKI mondiaux présentent au moins une vulnérabilité documentée.
Pour atténuer ces vulnérabilités, on trouve la conception de parties de confiance à sécurité byzantine (BRP), qui vise à décentraliser la validation et à améliorer la résilience.
Politiques fragmentées et application incohérente
Les RFC contiennent des cas ambigus ou insuffisamment spécifiés concernant le ROA et la logique de validation. Cela a engendré des comportements divergents selon les implémentations.
Certains réseaux appliquent un filtrage strict, d’autres se contentent d’une surveillance, et d’autres encore l’appliquent partiellement en fonction des catégories de préfixes.
Le routage étant global, des politiques incohérentes réduisent les gains de sécurité. Si seuls certains routeurs bloquent les paquets invalides, des annonces malveillantes peuvent néanmoins se propager via des chemins moins restrictifs.
Évolutivité, automatisation et outillage
Certains opérateurs citent la facilité d’utilisation, la complexité et le manque d’outils comme des obstacles. L’automatisation de la gestion des ROA, la synchronisation des caches de validation et l’intégration aux plateformes de routage demeurent des défis.
De plus, le recours à rsync pour la synchronisation des dépôts est jugé peu sûr ou inefficace par certains experts, ce qui a conduit à des propositions en faveur de RRDP.
Certains réseaux retardent l’émission des ROA jusqu’à ce que la validation soit largement adoptée, ce qui contribue à la lenteur de son adoption.
Bonnes pratiques pour les opérateurs déployant RPKI
Commencez par le mode de surveillance.
Déployez les ROV passivement (marquez les routes invalides sans les supprimer). Surveillez les routes invalides non intentionnelles avant d’appliquer les restrictions.
Conception soignée des ROA :
Utilisez des paramètres maxLength conservateurs. Évitez les préfixes trop larges ou trop stricts qui pourraient invalider accidentellement des annonces légitimes.
Application progressive et repli :
Ne rejetez les routes invalides qu’après une observation suffisante et en prévoyant des chemins de repli. Renforcez progressivement l’application des restrictions.Infrastructure de validation robuste :
Utilisez plusieurs instances de validation, choisissez un logiciel fiable, surveillez les interruptions et envisagez un repli vers des systèmes résilients comme BRP.Maintenez les données ROA et de validation à jour :
Synchronisez fréquemment, surveillez les défaillances du dépôt et assurez des mesures d’atténuation lorsque les données sont obsolètes.Coordonnez-vous avec vos pairs et les fournisseurs en amont :
Encouragez les autres acteurs du réseau à valider. La participation de nombreux réseaux renforce les avantages.Suivez les initiatives communautaires comme MANRS :
Les normes telles que les directives d’hygiène de routage complètent l’adoption de RPKI.
Audit et mise à jour réguliers :
Les ROA doivent être revus périodiquement. Les changements de propriétaire d’AS, les fusions ou les réaffectations de propriété intellectuelle nécessitent des mises à jour.
Le dilemme de « l’effet de réseau » et les incitations
Un obstacle majeur réside dans le fait que l’avantage n’est acquis que lorsque de nombreux réseaux valident le système. Un opérateur signataire, mais dont les pairs ne le sont pas, est moins bien protégé. Inversement, imposer la validation risque d’interrompre la connectivité avec les réseaux non conformes. Cette tension ralentit le déploiement.
Certains estiment que la réglementation ou des incitations sectorielles pourraient être utiles. D’autres évoquent des raisons économiques : les opérateurs de réseau proposant un « transit sécurisé » pourraient facturer un supplément s’ils imposent la validation à distance. De même, les fournisseurs de contenu pourraient exiger la conformité à la validation à distance des hébergeurs pour des raisons de sécurité.
Des préoccupations juridiques se posent également. Une étude sur les obstacles juridiques a souligné que les tribunaux jugeraient rarement les certificats RPKI défectueux si les RIR respectent les normes de l’IETF.
Principales limitations 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 AS ; les attaquants peuvent donc toujours falsifier les chemins AS. Ce problème est résolu par le protocole BGPsec, qui reste largement inexploité.
- Attaques de rétrogradation et interférences avec les dépôts : si les attaquants bloquent les dépôts RPKI ou empêchent l’accès des validateurs, les réseaux peuvent revenir à un routage non sécurisé.
- Logiciels de validation vulnérables : comme l’ont montré des audits récents (CURE), des bogues peuvent entraîner des erreurs de validation ou un empoisonnement des routes.
- Politiques partielles ou incohérentes : si certaines parties d’Internet n’appliquent pas ou ne signent pas les ROA, des routes invalides peuvent passer entre les mailles du filet.
- Erreurs opérationnelles : des ROA mal configurées ou des mises à jour négligées peuvent causer des dommages collatéraux.
Ainsi, RPKI constitue une amélioration importante, mais pas une solution miracle. Son plein potentiel se révèle lorsqu’il est combiné à d’autres mesures telles que le filtrage des routes, l’hygiène au niveau des pairs et, à terme, les systèmes de validation des chemins.
La voie à suivre : ce qui doit se passer
- Résilience et décentralisation des validateurs : Utilisation généralisée d’architectures robustes (par exemple, BRP) pour atténuer la dépendance à des points de défaillance uniques.
- Outils et automatisation améliorés : Interfaces optimisées, intégration aux systèmes de routage, alertes et outils de gestion du cycle de vie des ROA.
- Coordination et incitations communautaires : Signature d’accords mutuels, voire exigence de conformité ROV pour les interconnexions, entre pairs, IXP et opérateurs.
- Sensibilisation et formation accrues : De nombreux FAI et équipes réseau connaissent encore mal RPKI.
- Déploiement de normes complémentaires : ASPA, BGPsec et les normes associées doivent gagner en maturité et être largement adoptées.
Si ces conditions sont réunies, l’infrastructure de routage d’Internet deviendra beaucoup plus robuste face aux détournements et aux fuites de données.
FAQs: RPKI et sécurité du routage
1. Que signifie l’invalidation d’une route ?
Si une annonce BGP est invalide selon un ROV (c’est-à-dire non couverte par un ROA ou si l’AS d’origine ne correspond pas), les routeurs peuvent la supprimer, la déprioriser ou la placer dans une priorité inférieure.
2. Un préfixe peut-il avoir plusieurs ROA ?
Oui. Plusieurs ROA peuvent exister pour un même préfixe (avec potentiellement différents AS d’origine valides). La logique de validation doit gérer les unions et les conflits avec précaution.
3. RPKI garantit-il une sécurité de routage complète ?
Non. RPKI couvre uniquement l’assurance d’origine, et non la vérification complète du chemin. Des attaquants peuvent toujours usurper les chemins AS ou provoquer d’autres anomalies.
4. Que se passe-t-il si les données du validateur sont obsolètes ou inaccessibles ?
Les routeurs peuvent par défaut traiter les annonces comme inconnues (c’est-à-dire les autoriser). Mais en cas de défaillance de la connectivité, ce comportement de repli pourrait être exploité (vecteur de rétrogradation).
5. Comment les petits réseaux ou les hébergeurs de contenu peuvent-ils adopter RPKI ?
Ils peuvent utiliser les services RPKI hébergés par leur FAI ou RIR. Même sans validateur interne, ils peuvent émettre des ROA et signaler l’autorisation d’origine.
