ROA et ROV en 2026 : des autorisations publiées au filtrage réel

Publier une autorisation ne suffit pas à faire filtrer les routes

Un ROA indique quel ASN peut annoncer un préfixe. La ROV confronte les annonces à ces autorisations ; la politique du réseau détermine ensuite leur traitement. Dans les mesures APNIC de février 2026, 60,3 % des routes IPv4 et 60,9 % des routes IPv6 étaient Valid, contre environ 26,6 % des points d’observation bénéficiant de ROV. Les dénominateurs diffèrent : leur soustraction ne donne pas un déficit de sécurité exact. L’enjeu est de faire entrer les autorisations dans les décisions de routage.

Que mesure la couverture ROA ?

Un ROA est un objet RPKI signé qui autorise un système autonome à annoncer des préfixes déterminés. La RFC 9582 en définit le format. La couverture se rapporte aux routes visibles et aux données d’autorisation disponibles. Valid, Invalid et Not Found décrivent leur correspondance, pas la politique réellement appliquée par chaque réseau. Les adresses et ASN des exemples sont illustratifs.

Prefix:     203.0.113.0/24
Origin ASN: AS64500

Comment fonctionne la validation d’origine ?

Le réseau compare l’origine BGP et la longueur du préfixe aux données RPKI validées. Dans l’exemple, AS64500 correspond à l’autorisation ; AS64501 ne correspond pas si aucune autre autorisation ne le permet. Le réseau peut rejeter une route Invalid, la déprioriser ou commencer par l’observer. Il faut examiner toutes les autorisations couvrantes, et non choisir arbitrairement un seul ROA.

203.0.113.0/24 → AS64500

203.0.113.0/24 → AS64500

203.0.113.0/24 → AS64501

Une photographie mondiale de février 2026

Les tableaux suivants reprennent les observations APNIC de février 2026, et non des valeurs en temps réel. La part Valid avait progressé d’environ six points pour IPv4 et sept pour IPv6 depuis février 2025. Cette avancée de la publication ne prouve pas une généralisation du filtrage.

IPv4 : 60,3 % de routes Valid

Dans cet échantillon, 37,7 % des routes IPv4 étaient Not Found et 2,0 % Invalid. Une part importante restait donc sans autorisation couvrante.

IPv6 : 60,9 % de routes Valid

La part Not Found atteignait 36,1 %, et Invalid 3,0 %. IPv6 n’élimine pas les erreurs d’origine : les autorisations et les politiques doivent aussi y être entretenues.

Lire les chiffres ROV avec leur méthode

L’estimation mondiale APNIC était de 26,6 % en février, puis de 26,92 % fin juillet dans l’analyse consacrée à l’Inde. Il ne s’agit pas d’un recensement des ASN ayant eux-mêmes configuré ROV. Un filtrage en amont peut protéger un point d’observation en aval. Les valeurs régionales du tableau concernent février ; elles ne doivent pas être fusionnées avec celles de juillet.

Deux décisions opérationnelles différentes

Créer un ROA demande de préciser préfixe, ASN d’origine et longueur autorisée. Déployer ROV affecte les annonces reçues des clients, pairs, transitaires et serveurs de routes. Rejet, dépriorisation, observation ou exception temporaire engagent le fonctionnement du réseau et nécessitent des responsabilités claires.

Pourquoi les équipes hésitent-elles ?

Le risque de bloquer du trafic légitime, les systèmes anciens, les ROA périmés, l’automatisation inégale et la gestion des exceptions expliquent une partie des difficultés. Ce sont des raisons de préparer le déploiement, pas de renoncer à ROV. Si l’origine passe d’AS64500 à AS64501 sans mise à jour du ROA, une route légitime peut devenir Invalid.

Original routing:
203.0.113.0/24 → AS64500

ROA:
203.0.113.0/24 → AS64500

203.0.113.0/24 → AS64501

Relier registre, autorisation et réseau réel

Qui administre la ressource ? Quel ASN est autorisé ? Que montre BGP ? Le fournisseur, l’ASN ou la longueur du préfixe ont-ils changé ? Ces questions sont liées mais distinctes. Un ROA n’est pas une annonce BGP, et une inscription au registre ne prouve pas l’autorisation actuelle. La gestion des changements doit maintenir leur cohérence.

L’Asie du Sud-Est montre qu’une progression rapide est possible

En février, APNIC relevait 92,4 % de routes IPv4 Valid en Asie du Sud-Est, contre 31,0 % en Asie de l’Est. Formation, communautés d’opérateurs, incitations et participation des grands réseaux comptent autant que la disponibilité technique. Les arrondis du tableau peuvent empêcher un total exact de 100 %.

IPv6 présente aussi de forts écarts régionaux

L’Océanie et l’Asie du Sud approchaient une couverture IPv6 complète, tandis que l’Asie de l’Est restait loin derrière. Le déploiement d’un protocole plus récent n’installe pas automatiquement les pratiques de sécurité correspondantes.

Indonésie : l’effet d’un effort collectif

Selon APNIC, la couverture ROA IPv4 indonésienne est passée d’un peu plus de 60 % à environ 90,6 % fin 2025 ; la mesure ROV était proche de 22 % début 2026. La politique de rejet des Invalid dans l’environnement de réflecteurs de routes d’IIX a encouragé des ROA corrects. Publication et application ont néanmoins avancé à des rythmes différents.

Inde : une couverture élevée sans validation généralisée

L’analyse APNIC publiée en août cite, pour fin juillet, 88,04 % de couverture IPv4 et 97,91 % pour IPv6, mais une mesure ROV de 0,99 %. La même méthode donnait 3,14 % pour l’Asie du Sud et 26,92 % au niveau mondial. Cela ne permet pas de juger chaque réseau indien ; cela montre que la publication ne garantit pas l’application.

Du signal d’autorisation à la décision

Le détenteur publie un ROA ; les données sont récupérées et validées ; le réseau vérifie les routes puis applique sa politique. Sans cette chaîne, une autorisation correcte peut ne rien changer au traitement d’une annonce. Le schéma décrit un principe, pas une architecture imposée.

Détenteur de la ressource
  ↓ Publication du ROA
Récupération et validation des données RPKI
  ↓ Autorisation validée
Vérification de l’origine par le réseau
  ↓
Application de la politique

Ce que Valid établit réellement

Une route est Valid si au moins une autorisation validée couvrante permet à la fois son origine et sa longueur. Ce résultat ne prouve ni le meilleur chemin, ni la fiabilité de tout l’AS_PATH, ni l’absence de fuite, ni la réputation des adresses, ni la sécurité générale du réseau.

ROA:
203.0.113.0/24 → AS64500

BGP:
203.0.113.0/24 → AS64500

Invalid n’est pas un verdict d’attaque

Il existe des autorisations couvrantes, mais aucune ne permet la combinaison observée d’origine et de longueur. Une annonce non autorisée, une migration mal répercutée, un maxLength trop restrictif ou une erreur de configuration peuvent produire ce résultat. Il faut enquêter avant d’attribuer une intention malveillante.

Not Found : aucune autorisation couvrante

L’absence de données validées empêche cette vérification d’origine, sans rendre la route malveillante par définition. En février, 37,7 % des routes IPv4 et 36,1 % des routes IPv6 observées restaient dans cette catégorie. Couverture et validation doivent progresser ensemble.

Un ROA périmé peut perturber un service légitime

Changement de fournisseur, migration d’ASN, transfert d’adresses, fusion, désagrégation ou reprise après incident peuvent désynchroniser routage et autorisation. Finaliser un transfert au registre ne suffit pas : il faut aussi organiser la nouvelle origine, les autorisations existantes et leur calendrier de retrait.

Définir maxLength selon les besoins réels

maxLength fixe la longueur maximale autorisée ; s’il est absent, seul le préfixe exact est permis. L’exemple autorise un /24 : annoncer un /25 peut devenir Invalid malgré un ASN correct. Élargir excessivement maxLength autorise aussi des annonces plus spécifiques non prévues. Mieux vaut expliciter le besoin et suivre les changements.

Prefix:    203.0.113.0/24
Origin:    AS64500
maxLength: /24

203.0.113.0/25

L’origine n’est pas le chemin entier

ROV vérifie si un ASN peut être à l’origine d’un préfixe. Elle n’authentifie pas chaque relation de l’AS_PATH. Fuites de routes, manipulations de chemin, attributs anormaux et erreurs de politique demandent d’autres contrôles. Une origine Valid n’écarte pas toutes les formes de détournement.

AS64510 → AS64520 → AS64530 → AS64500

RPKI et IRR restent complémentaires

RPKI fournit une autorisation d’origine vérifiable cryptographiquement. L’IRR consigne des politiques et relations de routage plus larges. Les deux peuvent alimenter le filtrage et l’audit, mais aucun ne décrit seul le réseau en fonctionnement. Il faut les comparer aux observations BGP et aux dossiers internes.

ROV engage l’exploitation

Où valider ? Comment transmettre les données aux routeurs ? Que faire des Invalid, des exceptions et des défaillances du validateur ? Qui répond aux alertes ? Les équipes routage, sécurité et ressources doivent organiser ces responsabilités ; publier des ROA ne clôt pas le travail.

La place du réseau compte autant que son nombre

Un grand transitaire, un FAI majeur ou un point d’échange peut modifier les routes visibles pour beaucoup d’utilisateurs. Compter les ASN ne suffit donc pas : leur position dans la topologie détermine aussi l’effet du filtrage, y compris en aval.

Le rôle des points d’échange

Les serveurs de routes des IXP peuvent mutualiser la validation et l’application de politiques, réduisant le coût d’adoption pour leurs participants. L’expérience indonésienne illustre cet effet. Chaque membre doit néanmoins comprendre ses annonces, ses autorisations et ses exceptions.

Auditer d’abord ses propres ressources

Les statistiques mondiales donnent un contexte. Pour la continuité de service, il faut des preuves sur ses préfixes, ses origines, ses autorisations et ses accès. Les huit questions suivantes doivent avoir un responsable et une réponse vérifiable.

1. Quels préfixes annonçons-nous ?

Recenser les préfixes IPv4 et IPv6 importants, y compris ceux utilisés en secours, sans se limiter aux annonces les plus visibles.

2. Quel ASN doit être à l’origine ?

Documenter la correspondance entre chaque préfixe et l’ASN attendu. Cette intention opérationnelle sert de référence pour interpréter les observations.

Prefix → Intended Origin ASN

3. Les autorisations correspondent-elles ?

Vérifier préfixe, ASN, maxLength et validité des données. Examiner toutes les autorisations pertinentes pour ne pas manquer celle qui permet effectivement l’annonce.

4. Que voit-on dans BGP ?

Comparer l’intention aux annonces réellement visibles sur Internet, et pas seulement aux configurations ou tickets de changement.

5. L’IRR est-il cohérent ?

Rechercher les objets route et route6 périmés, contradictoires ou encore liés à une ancienne origine.

6. Qui maîtrise l’administration RPKI ?

Vérifier les droits, les suppléants et la récupération d’accès. Le contrôle des autorisations ne doit pas dépendre d’une seule personne.

7. Les changements déclenchent-ils une révision ?

Lier chaque modification de fournisseur, d’ASN, de longueur ou d’architecture à une vérification des ROA avant et après intervention.

8. Les Invalid sont-ils détectés ?

Surveiller les Invalid et les origines inattendues, avec destinataire d’alerte, méthode d’investigation et échéance des exceptions.

Une liste de contrôle par couche

Le tableau réunit registre, inventaire, ASN, autorisations, politiques, accès et continuité. Des preuves pour chaque ligne sont plus utiles qu’une simple déclaration « RPKI activé ».

Sept enseignements des données de 2026

Les observations montrent à la fois une avancée et du travail restant. Elles orientent des améliorations par couche, sans certifier la sécurité d’un réseau particulier.

1. Un seuil de couverture a été franchi

Plus de 60 % des routes IPv4 et IPv6 observées en février étaient Valid : davantage de détenteurs publient une autorisation vérifiable.

2. Beaucoup de routes restent sans couverture

Plus d’un tiers de l’échantillon était Not Found. Sans données d’autorisation, la validation d’origine manque de référence.

3. L’application doit encore progresser

Disposer de ROA ne signifie pas les utiliser. Configuration, supervision et traitement des exceptions doivent accompagner les politiques de production.

4. Les situations régionales divergent

L’écart IPv4 entre Asie du Sud-Est et Asie de l’Est rappelle qu’une moyenne mondiale masque des conditions locales très différentes.

5. La couverture ne garantit pas le filtrage

L’exemple indien l’illustre nettement. Les bilans doivent distinguer autorisations publiées et comportement de filtrage mesuré.

6. L’exactitude compte autant que le volume

Un ROA ancien peut rendre Invalid une route légitime. L’ajout d’objets ne dispense pas de leur entretien.

7. La rigueur opérationnelle reste essentielle

Inventaires exacts, configuration BGP, ROA à jour, politique adaptée, surveillance et gestion des changements se complètent.

L’autorisation doit suivre le réseau qu’elle protège

Une signature forte ne corrige pas une relation d’autorisation erronée. Préfixe, origine, longueur et gestion de la ressource doivent refléter les opérations. Cela rejoint la question de gouvernance portée par NRS : qui peut modifier ces données et comment les opérateurs participent-ils aux décisions ? État technique, contrôle administratif et mandat de représentation restent distincts.

Faire agir des autorisations fiables

Créer des ROA précis, les synchroniser avec BGP, déployer la validation avec méthode et surveiller les Invalid : tel est le travail à poursuivre lors des transferts et migrations. Shield peut apporter un soutien face au risque lié aux ressources. Un mandat POA est une démarche séparée, à examiner selon son périmètre, sa durée, les décisions déléguées et sa révocation.

Questions fréquentes

Quelle différence entre couverture ROA et adoption de ROV ?

La première décrit les autorisations associées aux routes. La seconde cherche à mesurer leur usage dans la validation et le traitement des annonces. Les dénominateurs diffèrent : les soustraire ne donne pas un écart de protection exact.

Quelle part des routes IPv4 était Valid en 2026 ?

Dans l’observation mondiale APNIC de février : environ 60,3 %, contre 37,7 % Not Found et 2,0 % Invalid. Il s’agit de cet échantillon daté.

Et pour IPv6 ?

La même analyse indiquait 60,9 % Valid, 36,1 % Not Found et 3,0 % Invalid.

Quelle était l’adoption mesurée de ROV ?

Environ 26,6 % au niveau mondial en février ; l’analyse ultérieure cite 26,92 % pour le 29 juillet. Le filtrage en amont influence la mesure, qui ne compte donc pas les ASN configurant eux-mêmes ROV.

Peut-on comparer directement les deux taux ?

Ils éclairent ensemble le déploiement, mais ne mesurent pas le même objet : autorisation des routes d’un côté, comportement de filtrage inféré de l’autre. Dates, échantillons et méthode doivent rester explicites.

Lire les mesures dans leur contexte

Note éditoriale du 13 octobre 2026. Les chiffres viennent des observations APNIC de février et de fin juillet 2026 ; ils ne sont pas actualisés en direct. Couverture des routes et comportement ROV mesuré ont des dénominateurs différents. Un filtrage en amont peut protéger des points situés en aval : la mesure ne recense pas les ASN configurant eux-mêmes ROV. Les arrondis régionaux et les dates originales de publication et de mise à jour sont conservés.

Sources et lectures complémentaires

• APNIC : état des lieux de février 2026
• APNIC : Inde et mesures de fin juillet 2026
• APNIC : méthode de mesure des ROA et de ROV
• RFC 6811 : validation d’origine
• RFC 9582 : profil ROA
• RPKI et IRR
• Utiliser RPKI en exploitation
• Auditer ses ressources numériques

Choisir un soutien en connaissance de cause

NRS Shield propose un soutien aux membres face aux risques liés aux ressources. Un mandat POA relève d’une décision distincte : examiner son périmètre, sa durée, les décisions confiées et sa révocation. Lire cet article ou demander de l’aide ne vaut pas mandat de représentation.

Découvrir NRS Shield · Mandat POA et représentation · Actions en cours