RPKI and BGP Route Origin Validation
Validation de l'origine des routes RPKI et BGP
Comment l’infrastructure à clé publique de ressources empêche les détournements de routes – couvrant la chaîne de confiance ROA, les états de validation, le protocole RTR et la situation actuelle du déploiement.
1. Pourquoi BGP n'a pas de validation d'origine native
BGP a été conçu pour un Internet coopératif où tous les participants étaient dignes de confiance. Un routeur accepte un message UPDATE et le propage sans vérification cryptographique indiquant que l'AS d'origine est effectivement autorisé à annoncer ces préfixes IP. Cela signifie que n'importe quel AS – en raison d'une mauvaise configuration ou d'une malveillance – peut annoncer les préfixes de quelqu'un d'autre, et cette annonce peut se propager à l'échelle mondiale en quelques minutes.
Incidents notables qui ont accéléré l’adoption de RPKI :
- 2008 — Pakistan Télécom :PTCL a accidentellement annoncé un préfixe plus spécifique pour l'espace d'adressage de YouTube (208.65.153.0/24), mettant YouTube en noir dans le monde entier pendant environ 2 heures avant que les fournisseurs en amont ne retirent la route.
- 2010 – Chine Télécom :China Telecom a créé environ 50 000 préfixes appartenant à des réseaux militaires, gouvernementaux et commerciaux américains pendant environ 18 minutes. Qu'il soit accidentel ou délibéré n'a jamais été confirmé.
- 2018 — Détournement DNS d'Amazon Route 53 :Un attaquant a utilisé BGP pour pirater 205.251.196.0/24 (Amazon DNS), redirigeant ainsi le trafic du portefeuille de crypto-monnaie pour voler des fonds. L'attaque a utilisé une MISE À JOUR BGP d'eNet (AS10297).
- 2019 — Trafic européen réacheminé via China Telecom :Le trafic mobile européen (y compris Vodafone et Swisscom en Suisse) a été redirigé via China Telecom pendant environ 2 heures en raison d'une fuite de route BGP.
2. La hiérarchie de confiance RPKI
RPKI (RFC6480) construit une hiérarchie de certificats X.509 reflétant la manière dont l'espace d'adressage IP est délégué :
- IANAdétient l’ancre de confiance racine. Il délivre des certificats de ressources aux cinq RIR (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), chacun couvrant son espace d'adressage.
- RIRdélivrer des certificats à leurs membres (FAI, entreprises) pour l'espace d'adressage que ces membres détiennent.
- Membresémettre des certificats d'entité finale (EE) et signerAutorisations d'origine de l'itinéraire(ROA) — attestations signées autorisant un ASN spécifique à générer des préfixes spécifiques.
Les vérificateurs téléchargent cette hiérarchie d'objets signés à partir de cinq référentiels RIR (plus tous les référentiels délégués), valident la chaîne de certificats et créent une table de charge utile ROA (VRP) validée. Les routeurs interrogent ensuite un cache RPKI local via leProtocole RTR (RFC8210) pour obtenir cette table et effectuer la validation de l'origine sur les MISES À JOUR BGP entrantes.
3. Autorisations d'origine de route (ROA)
Un ROA (RFC6482) est un objet signé contenant trois champs :
- ASN: Le système autonome autorisé à générer le préfixe.
- Préfixe: Le préfixe IP (IPv4 ou IPv6) étant autorisé.
- longueurmax: La longueur maximale du préfixe que l'ASN est autorisée à annoncer. S’il n’est pas précisé, seul le préfixe exact est autorisé. S'il est défini, par exemple, sur 24 pour un préfixe /20, l'ASN peut également annoncer tout élément plus spécifique entre /20 et /24.
Une seule ROA peut autoriser plusieurs préfixes pour le même ASN, mais une seule ROA ne peut pas autoriser plusieurs ASN pour un seul préfixe. Pour permettre à un ASN secondaire (par exemple, un fournisseur de transit ou un CDN) de générer votre préfixe, créez un ROA distinct pour cet ASN.
4. États de validation
Lorsqu'un routeur reçoit une MISE À JOUR BGP, il effectue une validation d'origine (RFC6811) par rapport à sa table VRP locale :
| État | Condition | Traitement typique de préférence locale |
|---|---|---|
| Valide | Au moins un ROA couvre le préfixe (préfixe ⊆ préfixe ROA ET longueur du préfixe ≤ maxLength) ET l'ASN du ROA correspond à l'ASN d'origine de la MISE À JOUR BGP. | +20 ou préféré (commun) |
| Invalide | Au moins une ROA couvre le préfixe, mais aucune ROA de couverture n'a un ASN correspondant et une maxLength ≥ la longueur du préfixe annoncée. | Définir la préférence locale 0 ou supprimer (choix de l'opérateur ; la RFC 6811 recommande d'autoriser mais de marquer) |
| Introuvable | Il n'existe aucun ROA couvrant le préfixe annoncé | Inchangé (traité comme avant l'existence du RPKI) |
L’idée clé :Invalideest une preuve plus forte d'un problème queIntrouvable. NotFound signifie simplement que le propriétaire du préfixe n'a pas encore créé de ROA. Invalide signifie qu'il existe une ROA indiquant que cet ASN estpasautorisé – un signal fort d’une mauvaise configuration ou d’un détournement.
5. Le protocole RTR
Les routeurs ne valident pas eux-mêmes les chaînes de certificats X.509, ce qui serait coûteux en termes de calcul et nécessiterait de conserver un cache RPKI complet. Au lieu de cela, un dédiévalidateur RPKI(Routinator, OctoRPKI, Fort, rpki-client) télécharge et valide le référentiel RPKI complet et exporte uniquement les charges utiles ROA validées (VRP) résultantes vers les routeurs via le protocole RTR (RFC8210).
RTR utilise TCP (port 323 attribué par l'IANA ; les validateurs tels que Routinator utilisent par défaut le port 3323 pour éviter de nécessiter les privilèges root) avec un mécanisme de synchronisation incrémentielle : le validateur envoie des numéros de série et les routeurs ne demandent que le delta depuis leur dernière synchronisation. Cela maintient une bande passante faible, même pour les grandes tables VRP (actuellement ~ 400 000+ entrées IPv4 dans le monde).
6. Déploiement et statistiques
Début 2026, le déploiement du RPKI a atteint une échelle significative :
- Plus de 50 % des préfixes IPv4 routés dans le monde ont au moins un ROA de couverture (contre environ 10 % en 2019).
- La majorité des FAI de niveau 1 et 2 effectuent désormais la validation de l'origine de la route et suppriment ou dépriorisent les routes non valides.
- MANRS (Mutually Agreed Norms for Routing Security) exige la création de RPKI ROA comme condition préalable à l'adhésion et publie un tableau de bord de conformité par AS.
Statistiques en direct :Moniteur NIST RPKI, ROV++, Statistiques APNIC RPKI.
7. Au-delà du ROV : ASPA et BGPsec
La validation de l'origine de la route RPKI vérifie uniquement que leorigine ASNest autorisé à annoncer le préfixe. Il ne valide pas l'AS_PATH — un attaquant peut toujours construire un faux AS_PATH avec un AS d'origine légitime à la fin. Deux normes de l'IETF abordent ce problème :
- BGPsec (RFC8205) : Chaque AS du chemin signe cryptographiquement la MISE À JOUR, créant ainsi une chaîne de contrôle incassable. Nécessite que tous les AS de transit prennent en charge BGPsec – un obstacle de déploiement important. Rarement déployé à partir de 2026.
- ZSPA(Autorisation du fournisseur de système autonome,projet-ietf-sidrops-aspa-profile) : Un AS signe un objet listant ses fournisseurs amont autorisés. Les vérificateurs peuvent détecter les chemins sans vallée invalides (par exemple, un client annonçant des itinéraires comme s'il s'agissait d'un fournisseur). Plus simple à déployer que BGPsec et gagnera du terrain à partir de 2025-2026.
Références
- RFC6480— Une infrastructure pour prendre en charge le routage Internet sécurisé (aperçu RPKI)
- RFC6482— Un profil pour les autorisations d'origine de route (ROA)
- RFC6811— Validation de l'origine du préfixe BGP
- RFC8210— Le protocole RPKI vers routeur, version 1 (RTR)
- RFC8416— Gestion simplifiée des ressources de numéros Internet locaux avec le RPKI (SLURM — remplacements locaux)
- RFC9286— Manifestes pour l'infrastructure à clé publique de ressources (RPKI)
- RFC8205— Spécification du protocole BGPsec
- MANRS— Normes mutuellement convenues pour la sécurité du routage
- Portail Cloudflare RPKI— recherche de ROA en direct