EN
en direct

RPKI et ROV bloquent les détournements BGP avant qu’ils n’atteignent votre AS — 48 % des préfixes restent non protégés

Le 31 juillet 2026, un préfixe appartenant à un opérateur cloud européen a été détourné pendant 4 heures via une annonce BGP frauduleuse en Asie du Sud-Est. RPKI et ROV auraient bloqué l’incident en 87 secondes — et pourtant, près de la moitié des préfixes IPv4 mondiaux ne sont toujours pas couverts.

Un panneau de brassage fibre optique avec un seul câble débranché et une LED jaune allumée

31 juillet 2026, 4 heures, un seul préfixe : un opérateur cloud européen perd le contrôle de son bloc IPv4 après qu’un AS non autorisé en Asie du Sud-Est a annoncé la route comme sienne. Le trafic destiné aux serveurs de Francfort atterrit à Jakarta. L’incident est détecté par les outils de monitoring — mais pas bloqué. Il n’y avait pas de ROV sur le chemin.

Le Resource Public Key Infrastructure (RPKI) et la Route Origin Validation (ROV) existent depuis 2012. En 2026, ils restent la seule défense automatisée contre les détournements BGP accidentels ou malveillants. Et pourtant, selon les statistiques NIST RPKI Monitor d’août 2026, 48 % des préfixes IPv4 ne sont toujours pas couverts par une ROA valide. Ce n’est pas un problème de technologie — c’est un problème de volonté.

BGP n’a pas changé depuis 1989

Border Gateway Protocol version 4 (RFC 4271) est le protocole qui fait fonctionner Internet. Il repose sur un principe simple : chaque Autonomous System (AS) annonce les préfixes qu’il sait router, et les routeurs choisissent le meilleur chemin. La faille est connue depuis le début : n’importe quel AS peut annoncer n’importe quel préfixe.

Le 24 décembre 2004, AS 9121 (TTNet, Turquie) annonce accidentellement l’intégralité de la table BGP mondiale. Le résultat : une panne Internet massive. En avril 2018, un FAI russe détourne le trafic de Google, Apple, Facebook et Microsoft en annonçant leurs préfixes. En février 2022, AS 55410 (Vodafone Idea, Inde) détourne le préfixe 103.21.244.0/22 de Cloudflare — le trafic de milliers de sites transite par Mumbai pendant 17 minutes.

À chaque incident, la réponse est la même : « activez RPKI ». En 2026, 18 ans après la première spécification RPKI (RFC 3779), le message n’a toujours pas été entendu par la moitié des opérateurs.

Comment RPKI + ROV bloquent un détournement en moins de deux minutes

Le mécanisme est cryptographique et décentralisé :

  • Chaque titulaire d’un bloc IP crée une Route Origin Authorization (ROA) signée numériquement. Une ROA dit : « le préfixe 192.0.2.0/24 ne peut être annoncé QUE par AS 64500 ».
  • Les ROA sont publiées dans les cinq Regional Internet Registries (RIR) — RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC — qui maintiennent des points de publication RPKI accessibles publiquement.
  • Un opérateur qui active la Route Origin Validation (ROV) sur ses routeurs télécharge ces ROA via un validator (routinator, rpki-client, Fort, OctoRPKI) et les compare aux annonces BGP reçues.
  • Résultat : une annonce non couverte par une ROA valide est classée INVALID et rejetée — avant d’entrer dans la table de routage.

Le temps de propagation d’une nouvelle ROA à l’ensemble des validateurs mondiaux est inférieur à 90 secondes. Un détournement BGP classique est stoppé avant que vos utilisateurs ne le remarquent.

Ce que RPKI ne fait pas : il ne protège pas contre un AS malveillant qui crée une ROA légitime pour un préfixe qu’il possède réellement et détourne le trafic en aval (on-path attack). Pour cela, il faut BGPsec ou ASPA (Autonomous System Provider Authorization) — deux standards encore au stade de déploiement expérimental en 2026. RPKI/ROV est la couche 1 de la sécurité BGP, pas la solution complète.

48 % de préfixes non protégés : qui sont les retardataires ?

Les données publiques du NIST RPKI Monitor (août 2026) donnent une photographie précise :

MétriqueValeur
Préfixes IPv4 avec ROA valide52 %
Préfixes IPv6 avec ROA valide44 %
AS déployant ROV (estimation)38 %
Filtrage ROV chez les Tier 1~90 %
Filtrage ROV chez les petits FAI< 20 %

Le problème est concentré dans la longue traîne des petits fournisseurs d’accès et des entreprises qui opèrent leur propre AS sans équipe réseau dédiée. Pour un FAI régional gérant 5 000 clients, configurer un validator RPKI prend moins de deux heures avec Routinator 3000 de NLnet Labs — l’installation tient en trois commandes :

bash
apt install routinator
routinator-init --accept-licenses
systemctl enable --now routinator

La barrière n’est pas technique. Elle est organisationnelle : personne n’a inscrit « déployer RPKI » dans un ticket Jira.

MANRS : le cadre qui transforme la bonne volonté en conformité mesurable

Depuis 2014, l’initiative MANRS (Mutually Agreed Norms for Routing Security), portée par l’Internet Society, définit quatre actions minimales pour un opérateur réseau responsable :

  1. Filtrage : ne pas propager d’annonces incorrectes.
  2. Anti-spoofing : empêcher le trafic avec des adresses source falsifiées.
  3. Coordination : maintenir des contacts joignables (NOC, PeeringDB à jour).
  4. Validation globale : publier des ROA et activer ROV.

En août 2026, plus de 1 000 AS ont rejoint MANRS, dont tous les Tier 1 européens et nord-américains. Les opérateurs conformes MANRS représentent environ 70 % des routes Internet mondiales. Mais MANRS n’a pas de pouvoir coercitif : c’est un engagement volontaire.

La Federal Communications Commission (FCC) américaine a ouvert une consultation en juin 2026 sur l’obligation de déploiement RPKI pour les FAI recevant des subventions fédérales. L’Union européenne envisage une mesure similaire dans le cadre de la directive NIS3, dont l’adoption est prévue pour fin 2026.

Verdict : vous pouvez protéger votre AS en une matinée

Le calcul est simple :

  • Si vous opérez un AS : publiez vos ROA auprès de votre RIR (30 minutes), déployez un validator RPKI sur un serveur ou un routeur compatible (2 heures), activez ROV sur vos sessions BGP (15 minutes). Coût matériel : un conteneur de 256 Mo de RAM.
  • Si vous ne contrôlez pas votre routage (hébergement cloud, transit IP) : exigez de votre fournisseur qu’il publie ses ROA et active ROV. Les trois hyperscalers (AWS, GCP, Azure) publient des ROA pour leurs préfixes depuis 2022-2023 ; vérifiez que votre fournisseur de transit fait de même.
  • Si vous gérez un réseau d’entreprise connecté à Internet : le risque n’est pas théorique. Le détournement BGP est une attaque MITM sans malware — aucun antivirus ne la détecte. Seul ROV la bloque.

En août 2026, ne pas avoir déployé RPKI n’est plus une question de complexité technique. C’est une question de priorité.


Références

  • NIST RPKI Monitor, statistiques de couverture des ROA, consulté le 3 août 2026 — https://rpki-monitor.antd.nist.gov/
  • MANRS Initiative, « MANRS Network Operators Actions », Internet Society, 2024 — https://www.manrs.org/netops/
  • RFC 8210, « The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 », IETF, septembre 2017
  • « BGP Hijacking : A 2026 Retrospective », Kentik Blog, juillet 2026
  • FCC, « Notice of Inquiry on Border Gateway Protocol Security », GN Docket No. 26-142, juin 2026

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

La confiance implicite entre fonctions réseau livre 84 failles dans les cœurs 4G et 5G

Des chercheurs de l’Université NTU de Singapour ont découvert 84 vulnérabilités dans sept implémentations open source de cœurs LTE et 5G — 81 CVE déjà attribuées, deux opérateurs commerciaux touchés. La cause racine est partout la même : les fonctions réseau se font confiance sans vérifier les messages qu’elles reçoivent, et la transition vers le cloud-native a rendu ces interfaces accessibles depuis Internet.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer