Si ce bandeau n'est plus pertinent, retirez-le. Cliquez ici pour en savoir plus.
La mise en forme de cet article est à améliorer ().
La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».
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 routageBGP 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
RPKI utilise des certificats PKI de type X.509 ( RFC 5280 ) avec des extensions pour les adresses IP et les identifiants AS ( RFC 3779 ). 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
Une autorisation d'origine de route (ROA)[1] 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
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
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[2].
Gestion et distribution des certificats
Il existe des outils open source[3] 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 permetttent 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
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 )[4]. 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[5],[6]. Le temps de propagation RPKI peut également poser des problèmes de routages[7]. 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[8]. Cisco proposent également pour leur plateforme IOS-XR l'utilisation de SSH pour sécuriser le transfert des autorisations RPKI[9].
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[10] 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[11].
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
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 la décision de routage peuvent être multiples. Cette décision de route est 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.
Implémentations
Cisco Systems offrent une prise en charge native sur de nombreuses plates-formes[12] pour utiliser RPKI sur la configuration du routeur et ses décisions de routes[13]. Juniper offrent une prise en charge sur toutes les plates-formes[14] 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)[15] ou par une implémentation RPKI[16] entièrement conforme à la RFC basée sur RTRlib. Le logiciel de routage Bird permet également la validation RPKI[17].
La librairie RTRlib[18] 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[19]. 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).
RFC correspondantes
L'architecture RPKI est documentée initialement dans la RFC 6480. Les spécifications techniques de RPKI sont documentées dans une série étendue de RFC : RFC 6481, RFC 6482, RFC 6483, RFC 6484, RFC 6485, RFC 6486, RFC 6487, RFC 6488, RFC 6489, RFC 6490, RFC 6491, RFC 6492, et RFC 6493. SEND lui est documenté dans les RFC 6494 et RFC 6495 . Ces RFC sont un produit du groupe de travail SIDR (« Secure Inter-Domain Routing ») de l'IETF[20] et sont basées sur une analyse des menaces documentée dans la RFC 4593. 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 . Il existe plusieurs implémentations pour la validation de l'origine des préfixes à l'heure actuelle[21].
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[22].
↑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 », , 484–491 p. (ISBN978-1-4503-8138-3, DOI10.1145/3419394.3423622, S2CID225042016), « 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, , 484–491 p. (ISBN978-1-4503-8138-3, DOI10.1145/3419394.3423622, S2CID225042016), « 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, , 429–457 p. (ISBN978-3-031-28485-4, DOI10.1007/978-3-031-28486-1_18, lire en ligne)
↑(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, (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, , p. 88–103 (ISBN978-3-031-56252-5, DOI10.1007/978-3-031-56252-5_5, lire en ligne, consulté le )
↑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.
↑[rfc:7128 Resource Public Key Infrastructure (RPKI) Router Implementation Report (RFC 7128)], R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch, February, 2014
