Résumé

  • L’essai a évalué trois choses distinctes : le fonctionnement normal, la protection contre des routes Invalid et la capacité de réagir si le contrôle provoquait un résultat indésirable.
  • Les documents publics retracent le passage d’une expérimentation à un guide. Ils ne prouvent ni un filtrage en production par les 18 participants, ni l’absence d’incident, ni un pouvoir de JANOG ou de JPNIC sur la politique de chaque AS.

Un contrôle de sécurité n’est pas gouverné sérieusement si son activation est la seule décision visible. Il faut aussi savoir qui peut observer ses effets, qui peut modifier la politique et qui doit ramener le réseau dans un état connu. C’est précisément ce qui rend l’expérimentation japonaise de validation de l’origine des routes plus intéressante que son inventaire de matériels.

Le projet n’a pas affirmé que ROV ne pouvait pas échouer. Il a intégré l’échec à l’épreuve. Ses « trois confirmations » demandaient si le réseau continuait normalement après l’introduction du contrôle, s’il protégeait contre des routes Invalid et si l’opérateur pouvait répondre à une anomalie. Le rétablissement devenait ainsi un critère d’adoption, pas une note de bas de page.

La discussion est devenue publique lors de JANOG52, le 5 juillet 2023. JANOG a réuni les intervenants et publié le programme et les supports de Taiji Kimura, de JPNIC, Katsushi Yamaguchi, de BIGLOBE, et Osamu Nakamura, de l’université Keio et de WIDE. Ce rôle de forum ne faisait toutefois pas de JANOG le propriétaire du projet, un régulateur ou l’administrateur des réseaux participants.

La chaîne d’autorité était distribuée. Le ministère japonais des Affaires intérieures et des Communications finançait le projet. NTT Communications en était le maître d’œuvre. Mitsubishi Research Institute et JPNIC intervenaient en sous-traitance. JPNIC a conçu certaines parties des essais RPKI et DNSSEC, préparé et exploité des environnements, rassemblé les résultats, puis publié le guide. L’université Keio, l’université d’Osaka avec le Cyber Kansai Project et l’université de Nagasaki hébergeaient des installations. Les organisations participantes testaient. La décision de politique BGP restait, elle, dans chaque système autonome.

Le rapport d’activité 2023 de JPNIC compte 18 entreprises dans le volet RPKI, huit dans DNSSEC et dix dans DMARC. Ce sont des effectifs de participation. Ils ne signifient pas 18 déploiements en production, 18 rejets de routes activés ou 18 validations réussies par un tiers indépendant.

Trois parcours étaient proposés : une prise en main, une expérimentation dans l’environnement du projet et une vérification dans l’environnement du participant. Cette distinction empêche de confondre laboratoire et exploitation. Le dossier public ne dit pas quelles entreprises ont suivi quel parcours, ni si une session BGP transportant du trafic réel a été modifiée.

Dans les installations d’essai, les ingénieurs pouvaient injecter volontairement des routes BGP Invalid et observer ROV avec des données ROA. Des routeurs virtuels ou physiques Arista, Cisco, Juniper et Nokia figuraient dans le dispositif. La diversité des fournisseurs élargit la portée technique du test ; elle ne démontre ni une équivalence parfaite des fonctions, ni une sûreté générale en production.

Le guide actuel de JPNIC conserve la logique en plusieurs étapes. Il recommande d’abord d’appliquer la validation tout en continuant d’accepter les routes Invalid, afin d’observer la charge et les routes concernées. Il demande ensuite de vérifier des exemples Invalid créés à dessein, puis de s’assurer qu’une exception locale ou un changement de politique peut rétablir une route classée Invalid par erreur.

Le rétablissement est donc inscrit dans le contrôle. Le guide décrit la suppression d’une politique ROV, le comportement après redémarrage d’un routeur, la reconnexion aux caches et la réponse aux classifications Invalid involontaires. Si une coupure de cache risque de dépasser le délai de conservation, il envisage l’arrêt de ROV pour un voisin ou un routeur, ou l’usage de SLURM pour éviter l’abandon de routes Invalid ou NotFound.

Cette réversibilité n’est pas une correction universelle. SLURM produit une vue locale personnalisée des informations RPKI. L’exception peut préserver la connectivité, mais elle crée aussi une décision de confiance locale. Les sources examinées ne publient ni l’autorité d’approbation, ni la durée, ni la procédure de rapprochement ultérieur de telles exceptions.

La norme RFC 6811 éclaire la limite. L’état de validation est une propriété locale de la route. Il ne doit pas provoquer à lui seul l’exclusion de celle-ci ; le filtrage ou la préférence relèvent d’une politique locale explicite. La norme avertit aussi qu’une manipulation des données de validation peut servir un déni de service. ROV vérifie l’origine annoncée d’un préfixe, pas la totalité du chemin AS.

Une présentation a mesuré un instantané de la table AS2500 à 9 heures le 8 mars 2023 : 905 690 routes IPv4, dont 77 Invalid, et 170 405 routes IPv6, dont 231 Invalid. Ces chiffres décrivent une RIB, un AS et un instant. Ils ne mesurent ni paquets, ni clients, ni perte d’accessibilité, et ne peuvent représenter le risque pour l’ensemble de l’Internet japonais.

L’apprentissage a ensuite été institutionnalisé. Le rapport de JPNIC mentionne une session JANOG52.5 consacrée à l’expérimentation et au guide. JPNIC a plus tard publié formellement celui-ci ; la version 1.1 était en vigueur le 27 mars 2026 et maintenue par une équipe d’experts. Cette continuité prouve la conservation d’un savoir, pas son adoption universelle.

Le résultat le plus solide est donc limité : le dispositif public rendait visible la capacité de détecter un effet non désiré et de revenir en arrière. Il ne permet pas encore de savoir combien de participants ont dû le faire, dans quel délai ni avec quel impact.