Resource Public Key Infrastructure
Resource Public Key Infrastructure ( RPKI ), également connue sous le nom de Resource Certification, est un usage spécialisé d'infrastructure à clé publiques (PKI) destiné à améliorer la sécurité du routage BGP d'Internet. RPKI fournit un moyen de relier les informations sur les ressources d'Internet (telles que les numéros de système autonome et les adresses IP ) à une autorité de certification. La structure du certificat reflète la manière dont les ressources des ressources d'Internet sont distribuées. Les ressources sont initialement distribuées par l'IANA aux registres Internet régionaux (RIR), qui les distribuent à leur tour aux registres Internet locaux (LIR), qui distribuent ensuite les ressources à leurs clients. RPKI est utilisé par les détenteurs légitimes des ressources pour contrôler le fonctionnement des protocoles de routage Internet afin d'empêcher une interception du trafic ou des erreurs de fuites de routes. RPKI est utilisé pour sécuriser principalement le Border Gateway Protocol (BGP) via la validation des l'origine des routes (ROV). Il peut-être également utilisé dans le Neighbor Discovery Protocol (ND) d'IPv6 via le protocole Secure Neighbor Discovery (SEND).
La mise en forme de cet article est à améliorer (juillet 2024).
La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».
Les points d'amélioration suivants sont les cas les plus fréquents. Le détail des points à revoir est peut-être précisé sur la page de discussion.
- Les titres sont pré-formatés par le logiciel. Ils ne sont ni en capitales, ni en gras.
- Le texte ne doit pas être écrit en capitales (les noms de famille non plus), ni en gras, ni en italique, ni en « petit »…
- Le gras n'est utilisé que pour surligner le titre de l'article dans l'introduction, une seule fois.
- L'italique est rarement utilisé : mots en langue étrangère, titres d'œuvres, noms de bateaux, etc.
- Les citations ne sont pas en italique mais en corps de texte normal. Elles sont entourées par des guillemets français : « et ».
- Les listes à puces sont à éviter, des paragraphes rédigés étant largement préférés. Les tableaux sont à réserver à la présentation de données structurées (résultats, etc.).
- Les appels de note de bas de page (petits chiffres en exposant, introduits par l'outil «
Source - Les liens internes (vers d'autres articles de Wikipédia) sont à choisir avec parcimonie. Créez des liens vers des articles approfondissant le sujet. Les termes génériques sans rapport avec le sujet sont à éviter, ainsi que les répétitions de liens vers un même terme.
- Les liens externes sont à placer uniquement dans une section « Liens externes », à la fin de l'article. Ces liens sont à choisir avec parcimonie suivant les règles définies. Si un lien sert de source à l'article, son insertion dans le texte est à faire par les notes de bas de page.
- La présentation des références doit suivre les conventions bibliographiques. Il est recommandé d'utiliser les modèles {{Ouvrage}}, {{Chapitre}}, {{Article}}, {{Lien web}} et/ou {{Bibliographie}}. Le mode d'édition visuel peut mettre en forme automatiquement les références.
- Insérer une infobox (cadre d'informations à droite) n'est pas obligatoire pour parachever la mise en page.
Pour une aide détaillée, merci de consulter Aide:Wikification.
Si vous pensez que ces points ont été résolus, vous pouvez retirer ce bandeau et améliorer la mise en forme d'un autre article.
Resource Public Key Infrastructure ( RPKI ), également connue sous le nom de Resource Certification, est un usage spécialisé d'infrastructure à clé publiques (PKI) destiné à améliorer la sécurité du routage BGP d'Internet.
RPKI fournit un moyen de relier les informations sur les ressources d'Internet (telles que les numéros de système autonome et les adresses IP ) à une autorité de certification. La structure du certificat reflète la manière dont les ressources des ressources d'Internet sont distribuées. Les ressources sont initialement distribuées par l'IANA aux registres Internet régionaux (RIR), qui les distribuent à leur tour aux registres Internet locaux (LIR), qui distribuent ensuite les ressources à leurs clients. RPKI est utilisé par les détenteurs légitimes des ressources pour contrôler le fonctionnement des protocoles de routage Internet afin d'empêcher une interception du trafic ou des erreurs de fuites de routes. RPKI est utilisé pour sécuriser principalement le Border Gateway Protocol (BGP) via la validation des l'origine des routes (ROV). Il peut-être également utilisé dans le Neighbor Discovery Protocol (ND) d'IPv6 via le protocole Secure Neighbor Discovery (SEND).
Certificats de ressources
[modifier | modifier le code]RPKI utilise des certificats PKI de type X.509 (RFC 5280[1]) avec des extensions pour les adresses IP et les identifiants AS (RFC 3779[2]). Ces certificats sont émis par les membres des registres Internet régionaux, appelés registres Internet locaux (LIR). Ils leur offrent une preuve de possession pouvant être validée, bien que le certificat ne contienne aucune information d'identité. À l'aide du certificat de ressource, les LIR peuvent créer des attestations cryptographiques sur les annonces d'itinéraire qu'ils autorisent à être faites avec les préfixes et les ASN qu'ils détiennent. Ces attestations sont décrites ci-dessous.
Origine des routes
[modifier | modifier le code]Une autorisation d'origine de route (ROA)[3] indique quel système autonome (AS) est autorisé à annoncer certains préfixes IP. Il détermine également la longueur maximale du préfixe que l'AS est autorisé à annoncer.
Longueur maximale du préfixe
[modifier | modifier le code]Lorsqu'il est présent, il spécifie la longueur du préfixe IP le plus spécifique que l'AS est autorisé à annoncer. Par exemple, si le préfixe de l'adresse IP est 10.0.0.0/16 et que la longueur maximale est 22, l'AS est autorisé à annoncer tout préfixe inférieur à 10.0.0.0/16, à condition qu'il ne soit pas plus spécifique que /22 . Ainsi, dans cet exemple, l'AS serait autorisé à annoncer 10.0.0.0/16, 10.0.128.0/20 ou 10.0.252.0/22, mais pas 10.0.255.0/24 .
La longueur maximale du préfixe est un champ facultatif. Lorsqu'il n'est pas défini, l'AS est uniquement autorisé à annoncer exactement le préfixe spécifié. Toute annonce plus spécifique du préfixe sera considérée comme invalide. Il s'agit d'un moyen d'imposer l'agrégation et d'empêcher le détournement par l'annonce d'un préfixe plus spécifique.
Autorisations au transit du système autonome
[modifier | modifier le code]Une autorisation de fournisseur de transit de système autonome (Autonomous System Provider Authorization - ASPA) est une attestation particulière indiquant quels réseaux sont autorisés à apparaître comme un fournisseur de transit en amont d'un système autonome dans les AS_PATH BGP[4].
Gestion et distribution des certificats
[modifier | modifier le code]Il existe des outils open source[5] disponibles pour administrer l'autorité de certification et gérer les certificats de ressources et les objets enfants tels que les ROA. De plus, les RIR disposent d'une plateforme RPKI qu'ils hébergent disponible sur leurs portails membres. Ils permettent aux LIR de choisir de s'appuyer sur ce système hébergé ou d'exécuter leur propre logiciel.
RPKI ne possède pas d'unique référentiel pour les objets RPKI. Le système de référentiel RPKI se compose de multiples services de publication distribués et délégués. Chaque service de publication du référentiel est associé à un ou plusieurs points de publication de certificats RPKI. En pratique, cela signifie que lorsqu'un LIR gère une autorité de certification, il peut soit publier lui-même tout le matériel cryptographique, soit s’appuyer sur un tiers pour la publication. Lorsqu'un LIR choisit d'utiliser le système hébergé fourni par le RIR, la publication se fait en principe dans le référentiel du RIR.
Validation d'une annonce de route
[modifier | modifier le code]Pour la validation, un logiciel utilisateur intermédiaire récupère, met en cache et valide les données du référentiel à l'aide de rsync ou du protocole RPKI Repository Delta (RFC 8182[6])[7]. Il doit se synchroniser régulièrement avec tous les points de publication afin de conserver une vue complète et à jour des données du référentiel. Des données incomplètes ou périmées peuvent conduire à des décisions de routage erronées[8],[9]. Le temps de propagation RPKI peut également poser des problèmes de routages[10]. Le logiciel intermédiaire de cache va creer une vue globale des annonces ROA valide.
Pour transmettre les données RPKI aux routeurs depuis ces serveurs de cache, il est possible d'employer le protocole "RPKI vers routeur" ou RTR (Resource Public Key Infrastructure to Router Protocol) décrit dans la RFC 6810[11],[12]. De nombreux constructeurs proposent également l'utilisation de SSH pour sécuriser le transfert des autorisations RPKI[13],[14].
Lorsqu'une ROA a été créé pour une certaine combinaison d'AS d'origine et de préfixe, cela aura un effet sur la validité RPKI[15] d'une ou plusieurs annonces de routes. Les routes sont alors séparées en 3 états:
- Valide (VALID) : L'annonce d'itinéraire est couverte par au moins un ROA
- Invalide (INVALID) : Le préfixe est annoncé par un AS incorrect. Cela peut signifier:
- Qu'il existe une ROA pour ce préfixe pour un autre AS.
- Que le préfixe est potentiellement annoncé de manière malveillante ou désagrégée par un autre AS.
- L'annonce est plus spécifique que ne le permet la longueur maximale définie dans un ROA qui correspond au préfixe et à l'AS. Cela peut être le cas lors de l'usage de RTBH qui peut entrer en conflit avec RPKI[16].
- Inconnue (UNKOWN) : Le préfixe de cette annonce n'est pas couvert (ou seulement partiellement couvert) par un ROA existant.
Une fois cette validation de route on peut appliquer des décisions de routages.
Décisions de routage
[modifier | modifier le code]Après validation des ROA, les routes certifiées peuvent être comparées aux routes apprises et aider les opérateurs de réseaux sur leur décisions de routes. L'impact de l'état de validité de la route sur les décisions de routage peuvent être multiples. Ces décisions de routes sont prise par le routeur et les politiques qu'on lui applique. Ainsi, il peut par exemple considérer les routes "INVALID" comme ne devant pas être prises en compte et les supprimer totalement, ou alors peut appliquer une préférence à l'égard de routes validées par RPKI. On peut également appliquer une communauté BGP particulière. Un ensemble de trois communauté étendue BGP well-known (0x4300 0x0000) sont réservées pour décrire l'état de validation et la propager aux pairs iBGP. 0x4300:0:0 pour les routes valides, 0x4300:0:1 pour les inconnues, et 0x4300:0:2 pour les routes invalides RPKI. Elles deviennent standard par la RFC 8097[17].
Implémentations
[modifier | modifier le code]Cisco Systems offrent une prise en charge native sur de nombreuses plates-formes[18] pour utiliser RPKI sur la configuration du routeur et ses décisions de routes[19]. Juniper offrent une prise en charge sur toutes les plates-formes[20] qui exécutent la version 12.2 ou une version ultérieure de leur OS. Quagga possède cette fonctionnalité via BGP Secure Routing Extensions (BGP-SRx)[21] ou par une implémentation RPKI[22] entièrement conforme à la RFC basée sur RTRlib. Le logiciel de routage Bird permet également la validation RPKI[23].
La librairie RTRlib[24] est une implémentation open source écrite en C du protocole RTR et la vérification de l'origine du préfixe. La bibliothèque est utile aux développeurs de logiciels de routage mais également aux opérateurs de réseaux[25]. Les développeurs peuvent intégrer RTRlib dans leur serveur BGP pour implémenter RPKI. Les opérateurs de réseaux peuvent utiliser RTRlib pour développer des outils de surveillance (par exemple, pour vérifier le bon fonctionnement des caches ou pour évaluer leurs performances).
Limites de RPKI
[modifier | modifier le code]RPKI est une avancée dans le domaine de la sécurité des protocoles de routages par l’authentification mais possède également des limitations. En effet, les validations RPKI ne s'intéressent qu'aux sources d'annonces et ne protègent pas la totalité du chemin emprunté. On parle ainsi ici de validation d'origine. Des validations différentes doivent être effectuées pour valider que l'intégralité d'un chemin est valide. Il ne protège par exemple pas d'une annonce possédant un AS privé dans son chemin, qui se doivent d'être filtrés autrement[26]. Des mécanismes comme l'ASPA (Autonomous System Provider Authorization)[27] visent à combler ce domaine.
Bien qu'il soit possible de se servir de validateurs externes, la vocation sécurisante de RPKI nécessite de pouvoir maintenir et surveiller ses propres serveurs de validation. Il est possible notamment que ces derniers divergent dans leurs validations. Ce peut notamment être du à l’actualisation des ressources signées par un opérateur. Au sein des routeurs, ces divergences s'additionnent dans les bases de ressources autorisées.
La création des certificats n'est pas uniformisée entre les Registres Internet Régionaux ce qui entraîne des difficultés d'exploitation et une accessibilité différente à la signature des ressources[28]. Ils n'utilisent pas non plus la même hiérarchie dans les objets de chiffrement entraînant des différences de performances significatives entre les ressources à valider[29].
RFC correspondantes
[modifier | modifier le code]L'architecture RPKI est documentée initialement dans la RFC 6480[30]. Les spécifications techniques de RPKI sont documentées dans une série étendue de RFC : RFC 6481[31], RFC 6482[32], RFC 6483[33], RFC 6484[34], RFC 6485[35], RFC 6486[36], RFC 6487[37], RFC 6488[38], RFC 6489[39], RFC 6490[40], RFC 6491[41], RFC 6492[42], et RFC 6493[43]. SEND lui est documenté dans les RFC 6494[44] et RFC 6495[45]. Ces RFC sont un produit du groupe de travail SIDR (« Secure Inter-Domain Routing ») de l'IETF[46] et sont basées sur une analyse des menaces documentée dans la RFC 4593[47]. Ces RFC couvrent la validation de l'origine BGP, tandis que la validation du chemin est fournie par BGPsec, qui a été normalisée séparément dans la RFC 8205[48]. Il existe plusieurs implémentations pour la validation de l'origine des préfixes à l'heure actuelle[49].
La RFC 6494 met à jour par le Secure Neighbor Discovery (SEND) le protocole Neighbor Discovery (ND) afin d'utiliser RPKI sur l'annonce de présence d'un routeur IPv6. Elle définit un type de certificat particulier SEND: certificat RPKI RFC 6487 modifié qui doit inclure une unique extension de délégation d'adresse IP RFC 3779[50].
Références
[modifier | modifier le code]- ↑ (en) Request for comments no 5280
- ↑ (en) Request for comments no 3779
- ↑ A Profile for Route Origin Authorizations (ROAs), M. Lepinski, S. Kent, D. Kong, May 9, 2011
- ↑ Azimov, Bogomazov, Bush, Patel, Snijders et Sriram, « BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects », Internet Engineering Task Force, 29 août 2023
- ↑ « GitHub - dragonresearch/rpki.net: Dragon Research Labs rpki.net RPKI toolkit », 23 novembre 2019
- ↑ (en) Request for comments no 8182
- ↑ Bruijnzeels, Muravskiy, Weber et Austein, « RFC 8182 - The RPKI Repository Delta Protocol », sur datatracker.ietf.org, juillet 2017
- ↑ John Kristoff, Randy Bush, Chris Kanich, George Michaelson, Phokeer, Schmidt et Wählisch, Proceedings of the ACM Internet Measurement Conference, New York, NY, USA, Association for Computing Machinery, coll. « IMC '20 », 27 octobre 2020, 484–491 p. (ISBN 978-1-4503-8138-3, DOI 10.1145/3419394.3423622, S2CID 225042016), « On Measuring RPKI Relying Parties »
- ↑ (en) John Kristoff, Randy Bush, Chris Kanich, George Michaelson, Phokeer, Schmidt et Wählisch, Proceedings of the ACM Internet Measurement Conference, ACM, 27 octobre 2020, 484–491 p. (ISBN 978-1-4503-8138-3, DOI 10.1145/3419394.3423622, S2CID 225042016), « On Measuring RPKI Relying Parties »
- ↑ (en) Romain Fontugne, Amreesh Phokeer, Cristel Pelsser et Kevin Vermeulen, « RPKI Time-of-Flight: Tracking Delays in the Management, Control, and Data Planes », dans Passive and Active Measurement, vol. 13882, Springer Nature Switzerland, 2023, 429–457 p. (ISBN 978-3-031-28485-4, DOI 10.1007/978-3-031-28486-1_18, lire en ligne)
- ↑ (en) Request for comments no 6810
- ↑ Bush et Austein, « RFC 6810 - The Resource Public Key Infrastructure (RPKI) to Router Protocol », sur datatracker.ietf.org, janvier 2013
- ↑ (en) « BGP Configuration Guide for Cisco NCS 5500 Series Routers, IOS XR Release 7.2.x - Implementing BGP [Cisco IOS XR Software Release 7.2] », sur Cisco (consulté le 7 juillet 2024)
- ↑ (en-US) Inc Extreme Networks, « Extreme SLX-OS Command Reference, 20.4.3 », sur documentation.extremenetworks.com (consulté le 20 décembre 2025)
- ↑ (en) Geoff Huston et George G. Michaelson Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) (rapport), Internet Engineering Task Force, février 2012 (lire en ligne)
- ↑ (en) Ioana Livadariu, Romain Fontugne, Amreesh Phokeer et Massimo Candela, « A Tale of Two Synergies: Uncovering RPKI Practices for RTBH at IXPs », Passive and Active Measurement, Springer Nature Switzerland, 2024, p. 88–103 (ISBN 978-3-031-56252-5, DOI 10.1007/978-3-031-56252-5_5, lire en ligne, consulté le 7 juillet 2024)
- ↑ (en) Request for comments no 8097
- ↑ « RPKI Configuration with Cisco IOS », RIPE
- ↑ « Cisco IOS IP Routing: BGP Command Reference - BGP Commands: M through N [Support] », Cisco
- ↑ « Example: Configuring Origin Validation for BGP - Technical Documentation - Support - Juniper Networks », www.juniper.net
- ↑ « BGP Secure Routing Extension (BGP‑SRx) Prototype », NIST, 15 août 2016
- ↑ « Quagga with RPKI-RTR prefix origin validation support: rtrlib/quagga-rtrlib », 10 mai 2019
- ↑ « Validating BGP Routes with RPKI in BIRD · ./brooks.sh », sur brooks.sh (consulté le 7 juillet 2024)
- ↑ « RTRlib - The RPKI RTR Client C Library », rpki.realmv6.org
- ↑ M. Wählisch, F. Holler, T.C. Schmidt, J.H. Schiller: "RTRlib: An Open-Source Library in C for RPKI-based Prefix Origin Validation, Proc. of USENIX Security Workshop CSET'13, Berkeley, CA, USA:USENIX Assoc., 2013.
- ↑ BGP Filter Guide, « Filtering Bogon ASNs », sur bgpfilterguide.nlnog.net (consulté le 20 décembre 2025)
- ↑ Alexander Azimov, Eugene Uskov, Randy Bush et Job Snijders, « A Profile for Autonomous System Provider Authorization », IETF, Internet Engineering Task Force, no draft-ietf-sidrops-aspa-profile-20, 18 août 2025 (lire en ligne, consulté le 20 décembre 2025)
- ↑ « The process of creating ROAs through each RIR portal | The Number Resource Organization », sur www.nro.net (consulté le 20 décembre 2025)
- ↑ (en) « Poster: Diverging Branches - How different are RPKI Trees across RIRs? », sur dl.acm.org (DOI 10.1145/3646547.3689681, consulté le 20 décembre 2025)
- ↑ (en) Request for comments no 6480
- ↑ (en) Request for comments no 6481
- ↑ (en) Request for comments no 6482
- ↑ (en) Request for comments no 6483
- ↑ (en) Request for comments no 6484
- ↑ (en) Request for comments no 6485
- ↑ (en) Request for comments no 6486
- ↑ (en) Request for comments no 6487
- ↑ (en) Request for comments no 6488
- ↑ (en) Request for comments no 6489
- ↑ (en) Request for comments no 6490
- ↑ (en) Request for comments no 6491
- ↑ (en) Request for comments no 6492
- ↑ (en) Request for comments no 6493
- ↑ (en) Request for comments no 6494
- ↑ (en) Request for comments no 6495
- ↑ « Secure Inter-Domain Routing (SIDR) », datatracker.ietf.org
- ↑ (en) Request for comments no 4593
- ↑ (en) Request for comments no 8205
- ↑ Resource Public Key Infrastructure (RPKI) Router Implementation Report (RFC 7128)], R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch, February, 2014
- ↑ « Blog Stéphane Bortzmeyer: RFC 6493: The RPKI Ghostbusters Record », sur www.bortzmeyer.org (consulté le 7 juillet 2024)
Liens externes
[modifier | modifier le code]- Outil de Cloudflare pour explorer RPKI
- Documentation RPKI open source
- Journal de l'IETF - Sécuriser BGP et SIDR
- RPKI-Monitor - Surveillance et analyse mondiales et régionales du déploiement et de l'utilisation du RPKI.
- Statistiques de déploiement RPKI pour tous les RIR
- Carte thermique de déploiement du ROA mondial
- Informations sur la certification des ressources RIPE NCC (RPKI)
- Déclaration du NRO sur le RPKI
- Déclaration de l'Internet Architecture Board sur RPKI
- RFC de rapport sur la mise en œuvre de RPKI
