Résumé

  • APNIC et NIXI ont signé le 8 septembre 2026 un protocole d’accord portant notamment sur le déploiement de ROV en Inde, un miroir de dépôt RPKI et des capacités locales de formation. L’annonce ne prouve encore aucune modification de politique en production.
  • Le chiffre indien de 0,99 % présenté en juillet comme une part de réseaux filtrant les routes invalides provient d’une mesure qu’APNIC Labs décrit comme centrée sur les utilisateurs. Elle ne permet généralement pas de désigner le réseau d’accès ou de transit qui a filtré.
  • Le suivi doit conserver cinq registres distincts : couverture ROA, observations I-ROV assorties de leur fenêtre, périmètre de configuration des opérateurs, exposition des chemins et du trafic, puis moyens facilitateurs. Leur rapprochement est utile ; leur confusion ne l’est pas.

La fenêtre fait partie du chiffre

À la date du 8 septembre 2026, la série indienne d’APNIC Labs ne donne pas une seule réponse. La clé sur sept jours affiche un filter_rate de 1,138930 ; celle sur quatorze jours, 1,147895 ; la clé 28, 2,135396 ; et celle sur 112 jours, 6,031948. Une même source, une même économie, une même date, quatre résultats.

Il serait tentant d’en choisir un, de l’arrondir puis de l’appeler « taux d’adoption de ROV ». Ce serait précisément enlever au nombre l’information qui lui donne un sens. Une fenêtre longue transporte une autre histoire et une autre composition d’observations qu’une fenêtre courte. Le volume observé, la date de mise à jour et la méthode ne sont pas des notes techniques : ils sont le dénominateur du constat.

La source contient même une divergence documentaire à ne pas corriger au jugé. Sa description annonce des fenêtres de 7, 14, 38 et 112 jours ; les objets de données portent les clés 7, 14, 28 et 112. L’écart ne permet pas de décréter quelle mention est fautive. Il oblige simplement à citer la clé réellement utilisée et à conserver la description telle qu’elle a été publiée.

C’est dans ce paysage de mesure qu’APNIC et NIXI ont signé, le 8 septembre à APNIC 62 à Mumbai, un protocole d’accord sur la sécurité du routage et les compétences techniques. L’accord prévoit un travail avec les opérateurs et les entreprises pour déployer la validation de l’origine des routes, un projet pilote de miroir de dépôt RPKI en Inde, des laboratoires, un dispositif de formation de formateurs ainsi que des sessions en ligne et en présentiel.

Ces actions sont cohérentes. Elles ne sont pas équivalentes. Installer un miroir facilite éventuellement l’accès aux données signées. Former un ingénieur crée une capacité. Produire une ROA exprime une autorisation. Un validateur calcule un état. Seule une politique de routage explicitement configurée décide ensuite du sort d’une annonce invalide.

Une ROA ne rejette aucune route

La séparation est inscrite dans l’architecture elle-même. Une Route Origin Authorization relie cryptographiquement un préfixe à l’AS autorisé à l’annoncer. Le validateur transforme les objets RPKI en états utilisables par le routeur. Le RFC 6811 distingue Valid, Invalid et NotFound. Il précise aussi qu’une route ne doit pas être écartée du processus de décision du seul fait de son état, sauf configuration explicite. Rejeter les invalides ou modifier leur préférence relève d’une politique locale.

Cette distinction empêche de surinterpréter les très bons chiffres de signature publiés pour l’Inde. Un billet d’APNIC du 17 août indique qu’à la fin de juillet 2026, 88,04 % des objets de route IPv4 et 97,91 % des objets de route IPv6 étaient couverts par une ROA valide. Cela mesure la disponibilité d’une intention signée du côté des détenteurs de ressources. Cela ne mesure ni le nombre de réseaux récepteurs qui filtrent, ni la part de trafic soumise à ce filtrage, ni le nombre de chemins effectivement protégés.

Le même billet affirme que le déploiement de ROV restait limité à 0,99 % des réseaux filtrant les préfixes et annonces invalides au 29 juillet. La série sous-jacente contient bien une valeur sur sept jours de 0,990652 à cette date. Mais la méthode vers laquelle APNIC renvoie ne procède pas à un recensement des configurations de chaque AS.

APNIC Labs explique ne pas disposer d’une vue exhaustive de l’état BGP à l’intérieur de tous les systèmes autonomes. L’expérience est donc centrée sur l’utilisateur : des balises sont annoncées par des routes dont l’état ROA alterne entre valide et invalide, puis la mesure observe si l’internaute atteint la cible. Lorsqu’il ne l’atteint pas pendant la phase invalide, un filtrage quelque part sur le chemin est une explication compatible avec l’observation.

Le « quelque part » est décisif. Le document méthodologique dit qu’à mesure que le filtrage se déploie dans les réseaux de transit, il devient plus difficile de voir jusqu’au réseau d’accès et d’attribuer son comportement. Un abonné peut ne pas atteindre la balise parce que son opérateur filtre, parce qu’un transit en amont filtre, ou parce qu’une autre propriété du trajet observé intervient. Le résultat est précieux pour l’expérience de l’utilisateur ; il ne nomme pas automatiquement le détenteur du contrôle.

À l’inverse, une organisation peut déclarer ROV en production tout en le limitant à certaines sessions, à certains routeurs ou à un traitement progressif. Elle peut conserver des exceptions et un mécanisme de retour arrière. Compter cette organisation comme une unité entière serait tout aussi trompeur que d’attribuer chaque échec de balise au réseau d’accès.

La concentration doit être démontrée sur les chemins

Le directeur général de NIXI avance une logique plus fine qu’un simple décompte d’AS. Selon les propos rapportés par APNIC, un petit nombre de grands opérateurs transporte la majorité du trafic Internet indien ; leur adoption de ROV pourrait donc sécuriser une part significative du paysage national.

Cette hypothèse donne au programme une stratégie plausible. Si l’objectif est de protéger l’exposition réelle, travailler d’abord avec quelques réseaux très présents peut avoir plus d’effet que d’accumuler les participants sans passage en production. Une mesure centrée sur les utilisateurs apporte elle aussi une perspective que le nombre brut d’opérateurs ne fournit pas.

Mais le communiqué ne nomme pas ces opérateurs, ne quantifie pas leurs parts de trafic, ne définit pas les flux inclus et ne précise pas si le filtrage vise les clients, les pairs, les transits ou plusieurs classes de sessions. La concentration n’est donc encore qu’une théorie de changement. Pour devenir un résultat, elle doit être reliée à des politiques datées et à une exposition mesurée.

Un opérateur important n’est pas un chemin unique. Son trafic peut emprunter plusieurs transits, points d’échange, interconnexions privées et frontières de politique. Le fait qu’une configuration existe à un endroit ne suffit pas à conclure que tous les utilisateurs ou toutes les annonces invalides la rencontrent. Le dénominateur pertinent n’est ni nécessairement le nombre d’AS, ni nécessairement le nombre d’abonnés : il dépend de la question posée.

Cinq registres et une clé de rapprochement

Le plan d’activité 2026 approuvé par le conseil d’APNIC fournit un point d’appui utile. Il prévoit de rendre compte de l’aide apportée aux Membres pour créer et maintenir des ROA valides et de son impact mesurable ; il prévoit séparément l’aide au déploiement de ROV auprès d’opérateurs identifiés et son impact mesurable. Il prévoit aussi un état semestriel de l’usage de RPKI en Asie-Pacifique. Autrement dit, l’activité et l’effet ne devraient pas partager une seule case.

Le premier registre est celui des ROA. Il doit séparer IPv4 et IPv6, dire si l’unité est l’objet de route ou l’étendue d’adresses, conserver les états Valid, Invalid et NotFound, puis fixer la date et la version des données. Il répond à la question de l’autorisation publiée.

Le deuxième est le registre I-ROV. Il porte la méthode de balise, l’affectation à l’économie, les volumes, la fenêtre, la date de mise à jour et la limite d’attribution entre accès et transit. Il répond à une question d’observation sur des utilisateurs et des chemins.

Le troisième est le registre de politique opérateur. Il décrit une cohorte stable, les AS concernés ou leur nombre borné, la date de déploiement, la génération de la politique, les classes de sessions couvertes, les exceptions et l’état du retour arrière. Une publication agrégée peut protéger la topologie et les données commerciales tout en rendant le mot « déployé » vérifiable.

Le quatrième est celui de l’exposition : méthode de calcul des parts de trafic, couverture des chemins ou des pairs, résultat des annonces de test, incidents, exceptions et durée d’observation. C’est là que l’hypothèse de concentration de NIXI doit être testée.

Le cinquième conserve les moyens facilitateurs. Le miroir est évalué par rapport à une référence d’accès et de résilience. La formation progresse par étapes : présence, réussite du laboratoire, changement prévu, mise en production, puis maintien de la configuration. Aucun de ces jalons ne se transforme silencieusement en filtrage.

La clé de rapprochement est une cohorte et une date. Elle permet d’indiquer qu’un ensemble défini a reçu une assistance, modifié une politique délimitée, couvert une certaine exposition et produit une observation bornée. Sans cette clé, cinq indicateurs se côtoient sans prouver qu’ils racontent la même opération.

Ce que les sources ne permettent pas de conclure

Le protocole d’accord n’avait qu’un jour à la date de recherche. Aucune source ne permet de dire qu’un opérateur indien nommé a déjà modifié sa politique. On ne peut pas soustraire 0,99 % de 88,04 % pour fabriquer un « retard » : les unités sont différentes. Les écarts entre fenêtres en septembre ne démontrent pas un déploiement soudain. Un miroir n’est pas un filtre, et un validateur n’impose pas la décision locale du routeur.

Enfin, ROV porte sur l’autorisation de l’origine. Il ne certifie pas à lui seul tout le chemin AS et ne supprime pas toutes les fuites de route. Un programme peut apporter un gain considérable tout en publiant exactement la portée de ce gain.

Sources