Le jour où le signal de confiance devient silencieux

Summary

Les exercices menés par le groupe RPKI temporaire de JANOG en 2013 ont exposé des défauts logiciels et des questions de continuité, mais ils ne constituaient ni un déploiement national ni un test de panne en production.
La sûreté de la validation d’origine dépend d’une chaîne entière — dépôt, validateur, cache, protocole RTR, routeur et politique locale — dont chaque état doit être distingué; les incidents de 2021 et 2022 montrent pourquoi cette précision est opérationnelle, pas seulement lexicale.
La maturité croissante de RPKI et ses bénéfices de sécurité plaident pour un déploiement progressif et observable, non pour l’abandon de la validation; les sources consultées ne font toutefois apparaître aucun pourcentage d’arrêt adopté par JANOG.

À l’instant du redémarrage

Imaginons un routeur qui vient de redémarrer. Ses sessions BGP se reforment, des centaines de milliers de routes reviennent, et une autre conversation s’ouvre en parallèle avec un ou plusieurs caches RPKI. Le routeur ne demande pas au système de certification si Internet est « sûr » au sens large. Il reçoit un jeu de données validées qui associe des préfixes à des systèmes autonomes autorisés à les annoncer, avec une longueur maximale éventuelle. Il compare ensuite les annonces BGP à ce jeu. Ce mécanisme peut rendre une usurpation d’origine plus difficile.

Mais que doit croire le routeur si le cache tarde, si le dépôt en amont publie un manifeste périmé, si deux validateurs ne voient pas la même chose ou si le jeu reçu se vide brutalement ?

La scène paraît contemporaine. Elle était pourtant déjà au cœur d’une discussion publique à JANOG32, le 4 juillet 2013. Des entités avaient alors derrière eux plusieurs mois de manipulations RPKI. Ils avaient rencontré des logiciels imparfaits, recommencé une partie du travail, fait circuler des données validées jusqu’à un équipement de routage et observé ce que le routeur affichait. Dans la salle, les questions ont ensuite quitté le chemin heureux. Que se passe-t-il avec plusieurs caches ? Après un rechargement du routeur ? Si le cache transporte des données corrompues ? Si tout semble devenir Invalid ? Un entité a même suggéré de suspendre les mises à jour lorsqu’une proportion anormale serait atteinte.

Il serait séduisant de transformer cet échange en moment fondateur: une communauté aurait découvert le problème, conçu la redondance et fixé une règle de sécurité. Les sources ne permettent rien de tel. La RFC 6810, publiée en janvier 2013, prévoyait déjà qu’un routeur puisse se connecter à un ou plusieurs caches, conserver temporairement des données et essayer un cache de remplacement. Le pourcentage évoqué à JANOG32 n’a pas laissé de chiffre adopté, de règle JANOG, de fonction de fournisseur ni de seuil japonais de production. Et le groupe lui-même n’a existé que du 22 janvier au 31 juillet 2013.

La valeur de cet épisode est plus modeste, donc plus utile. Il montre le moment où un signal cryptographique descend vers le monde des opérateurs et cesse d’être seulement une hiérarchie de certificats. Dans ce monde, la confiance doit survivre à des composants qui tombent, à des données qui vieillissent, à des implémentations qui divergent et à des décisions locales qui ne peuvent être déléguées à une étiquette. Le vrai problème n’est pas de choisir entre la sécurité et la disponibilité. Il est de savoir exactement où une anomalie se produit, ce que l’on sait encore, et quelle action reste réversible.

Six mois, pas une nouvelle autorité

Le groupe de travail RPKI Routing de JANOG avait une limite nette. Son activité officielle a commencé le 22 janvier 2013 et s’est achevée le 31 juillet. Son programme comprenait deux hackathons, des séances pratiques, un tutoriel et une restitution à JANOG32. Il réunissait une communauté d’opérateurs autour d’outils et de questions concrètes. Il ne formait pas une autorité permanente, et le dossier public n’établit pour lui ni personnalité juridique distincte, ni pouvoir contractuel, ni contrôle financier.

Cette frontière institutionnelle compte parce que RPKI distribue les responsabilités. JANOG convoquait et archivait l’échange. JPNIC était le registre Internet japonais; il a fourni ou exploité certains environnements expérimentaux, puis des services, un dépôt et des recommandations. APNIC et les autres registres Internet régionaux exerçaient, dans leurs régions de service, des fonctions de certification et de dépôt. Les opérateurs, eux, restaient maîtres de la topologie de leurs caches, de la configuration de leurs routeurs, des exceptions et de l’action appliquée aux états de validation.

Aucun lien entre ces acteurs ne faisait de JANOG un registre, un organisme de certification, un régulateur ou l’exploitant des réseaux présents dans la salle.

Le rapport d’activité révisé en mars 2014 reconstitue les travaux. Lors des premiers hackathons, les entités ont essayé des outils de certification, créé ou manipulé des certificats et des ROA, construit la fonction de cache et préparé un chemin vers un routeur BGP expérimental. Des défauts de l’environnement et des logiciels ont empêché que tout se déroule comme prévu. Des corrections ont été apportées. Une seconde série a permis de mener plus loin la mise en place du cache et d’observer plus complètement le résultat côté routeur. Des séances ultérieures ont simplifié l’environnement, notamment au moyen de machines virtuelles préconfigurées, afin de rendre l’émission et la validation observables sans que chaque entité reconstruise toute l’infrastructure.

Ce récit est consistant à travers la page du groupe, les présentations et la rétrospective publiée par JPNIC en novembre 2013. Mais les documents appartiennent pour l’essentiel à la même famille institutionnelle. Ils ne sont accompagnés ni des configurations brutes, ni des journaux de cache, ni des versions complètes des validateurs et des routeurs, ni d’un protocole de test permettant de recalculer un taux de réussite. Nous ignorons combien de entités ont achevé chaque parcours de bout en bout. Dire que la deuxième tentative a mieux fonctionné après correction est justifié; lui attribuer un pourcentage de réussite ou une robustesse de production ne le serait pas.

Le mot « essai » doit donc rester attaché au laboratoire. Des personnes ont réellement manipulé la chaîne. Elles n’ont pas, selon le dossier accessible, activé un filtrage national, ni forcé un réseau japonais de production dans un état où toutes ses routes auraient été invalidées. Un atelier réussi prouve qu’un geste peut être exécuté dans un environnement borné. Il ne prouve ni la capacité à l’exécuter à l’échelle, ni la résistance à toutes les pannes, ni l’adoption par ceux qui étaient présents. C’est précisément cette distance entre démonstration et exploitation qui donne à la discussion de juillet sa portée.

Ce qui a été fait, ce qui a seulement été redouté

Une enquête sur la sûreté perd toute valeur si elle mélange l’expérience et le scénario. En 2013, les opérations attestées comprennent l’usage d’outils RPKI, la création de certificats et de ROA, la mise en place d’une fonction de validation/cache, le transfert de données validées et l’observation de l’état obtenu sur un routeur expérimental. Les premiers essais ont rencontré des défauts; les outils ont été corrigés; une nouvelle tentative a amélioré l’achèvement. Les séances pratiques ont ensuite présenté un environnement plus accessible. Voilà le noyau exécuté.

Le compte rendu de la session JANOG32, lui, enregistre aussi les questions de la salle. Il mentionne la configuration de plusieurs caches, le comportement après rechargement, le risque de données corrompues et la possibilité que « tout » apparaisse Invalid. Ce dernier mot décrit ici une inquiétude formulée dans l’échange, pas un incident de production documenté. Le compte rendu est édité, non une transcription mot à mot, et ne fournit ni injection de panne, ni métrique d’impact, ni preuve qu’un tel état ait été provoqué durant le groupe de travail.

La présentation technique de Tomoya Yoshida aide à comprendre pourquoi ces questions s’enchaînaient. Une architecture qui dépend d’un cache externe crée une relation de disponibilité. La perte de la session RPKI-to-Router, ou RTR, soulève la question de la durée pendant laquelle un routeur conserve les informations déjà reçues. Le rechargement d’un routeur peut faire converger BGP et la validation à des rythmes différents. Un cache corrompu peut transmettre un jeu erroné. Enfin, même une route techniquement Valid ne devient pas pour autant acceptable au regard de toutes les règles de routage: la validation d’origine ne contrôle ni tout le chemin AS ni les politiques habituelles d’importation.

Cette présentation cartographie des risques; elle ne démontre pas qu’ils se sont tous produits. La nuance est particulièrement importante pour la proposition de suspension. Un entité a suggéré d’arrêter les mises à jour lorsqu’un pourcentage de résultats anormaux serait franchi. Les archives consultées n’indiquent ni la valeur de ce pourcentage, ni une adoption collective, ni une implémentation. Inventer 10 %, 20 % ou n’importe quel autre nombre donnerait une fausse précision à une idée demeurée ouverte. La qualifier de « règle JANOG » convertirait une remarque en autorité.

L’idée elle-même mérite cependant examen. Un arrêt automatique pourrait empêcher qu’un jeu de VRP manifestement incomplet contamine rapidement tous les routeurs. Mais il pourrait aussi figer des données obsolètes. Un attaquant ou une modification légitime de grande ampleur pourrait déclencher le seuil. Un pourcentage global pourrait rester faible tout en masquant une catastrophe pour une région ou un client précis. À l’inverse, une vague parfaitement légitime de créations ou de retraits de ROA pourrait paraître suspecte.

Sans modèle de référence, distribution historique, règle de reprise et contrôle humain, le « disjoncteur » risque de déplacer le problème plutôt que de le résoudre.

Ainsi, l’apport du débat de 2013 n’est pas un algorithme prêt à l’emploi. C’est la formulation publique d’un invariant: lorsqu’un système de sécurité produit soudain un résultat massif et improbable, l’opérateur doit pouvoir distinguer une attaque du réseau, une erreur de données, une défaillance de publication, un problème de logiciel et un changement légitime avant de rendre l’action irréversible.

La chaîne ne tombe pas d’un seul bloc

Le vocabulaire RPKI est parfois présenté comme un feu tricolore: Valid, Invalid, NotFound. Cette simplification convient à une introduction, mais devient dangereuse pendant un incident. Avant que ces états n’apparaissent sur un routeur, plusieurs couches ont déjà agi.

La première est la certification des ressources et le dépôt. Des certificats, des listes de révocation, des manifestes et des ROA sont publiés dans une hiérarchie. Un défaut de disque, une incohérence entre parent et enfant ou une publication non atomique peut rendre ces objets périmés, incohérents ou rejetés. Cela ne dit pas encore ce qu’un routeur affichera. La deuxième couche est le logiciel de validation côté utilisateur — la « relying party », qui peut aussi alimenter un cache — qui récupère ces objets, applique les règles cryptographiques et produit un ensemble de VRP.

Si des objets sont rejetés, cet ensemble peut être incomplet; deux implémentations peuvent aussi réagir différemment à une incohérence.

La troisième couche est RTR, le protocole par lequel les données validées atteignent le routeur. Une session peut tomber, se réinitialiser ou basculer vers un autre cache. Le routeur peut conserver temporairement ce qu’il savait, puis expirer ces données selon les règles et l’implémentation. La quatrième couche est la comparaison avec BGP. Une annonce est Valid si son préfixe, son AS d’origine et sa longueur respectent au moins un VRP pertinent. Elle est Invalid lorsqu’un VRP couvrant existe mais que l’origine ou la longueur ne concorde pas. Elle est NotFound lorsqu’aucun VRP couvrant disponible ne permet cette validation.

Puis vient la cinquième couche, souvent oubliée: la politique locale. L’opérateur peut observer, marquer, modifier une préférence, traiter différemment des catégories de pairs, maintenir une exception ou rejeter. Enfin seulement apparaît une conséquence éventuelle pour la table de transfert et pour les utilisateurs. Une route Invalid n’est pas automatiquement rejetée; une route NotFound n’est pas automatiquement perdue; une route Valid n’est pas automatiquement bonne. Elle pourrait porter un chemin AS indésirable, violer un filtre de client ou présenter un autre problème que la validation d’origine ne cherche pas à résoudre.

La RFC 7115, publiée en janvier 2014, formalise cette souveraineté opérationnelle: l’usage de l’état de validation relève de la politique locale. Elle recommande de prévoir et mesurer les effets, de surveiller, puis de renforcer progressivement le traitement. Elle envisage que NotFound continue d’être accepté et que le traitement d’Invalid soit déployé avec prudence. Cette recommandation n’est pas la preuve qu’un opérateur japonais particulier l’a appliquée, mais elle interdit de raconter RPKI comme une décision prise une fois pour toutes par une communauté extérieure au réseau.

Ce découpage permet aussi de préciser ce qu’est un comportement sûr en cas de panne. Il ne s’agit pas de tout accepter dès qu’un composant hésite, car un assaillant bénéficierait alors de la moindre perturbation. Il ne s’agit pas non plus de tout rejeter au premier signal, car le système de validation deviendrait un point de panne. La sûreté consiste à préserver suffisamment d’état et d’observabilité pour choisir une réaction proportionnée: données retenues mais datées, comparaison de caches, alerte avant action, déploiement par étapes, possibilité de retour arrière, exception locale documentée et critères de reprise.

Les garde-fous existaient avant la réunion

L’antériorité de la RFC 6810 change le récit. Publiée le même mois que le début du groupe temporaire, elle décrivait déjà le protocole entre caches et routeurs. Elle autorisait une connexion à un ou plusieurs caches, prévoyait la conservation temporaire des données et le recours à un cache de remplacement, ainsi que des mécanismes de réinitialisation et de mise à jour. JANOG32 s’est tenu environ six mois plus tard. On ne peut donc pas créditer le groupe de l’invention de la redondance ou de la rétention.

Mais un standard et un comportement réel ne sont pas identiques. Le mot « MAY » permet plusieurs caches; il ne garantit pas que chaque routeur en utilise deux, que les deux soient réellement indépendants, que les données retenues aient la bonne durée ou que le basculement ait été testé. Deux caches installés dans le même site, nourris par la même vue, exécutant le même logiciel et dépendant du même chemin réseau peuvent tomber ensemble. Deux implémentations différentes peuvent réduire le risque d’un défaut logiciel commun tout en partageant un dépôt défaillant.

Une rétention trop courte peut vider l’état avant le rétablissement; une rétention trop longue peut prolonger des autorisations qui ne devraient plus l’être.

C’est ici que la discussion opérateur ajoute quelque chose sans devenir une source normative. Elle oblige à poser des questions que le texte de protocole ne résout pas seul: où placer les caches ? Comment observer leurs écarts ? Que fait le routeur au démarrage avant la synchronisation complète ? À partir de quel écart la variation cesse-t-elle d’être plausible ? Qui peut autoriser une exception ? Comment revenir à l’état précédent ? Comment éviter qu’une dépendance externe centralisée ne devienne une fragilité partagée ?

Il faut également distinguer ce qui relève du registre et ce qui relève de l’exploitant. Le 3 mars 2015, JPNIC a lancé un environnement d’essai lié aux ressources inscrites dans son registre. Cette étape rapprochait la certification des allocations réelles. Elle ne configurait pas pour autant les routeurs des titulaires. La documentation précisait qu’une configuration BGP et ROV séparée demeurait nécessaire. JPNIC pouvait offrir le service de certification, le dépôt ou un cache; l’opérateur devait décider comment consommer les données et agir sur le trafic.

Cette passation est le cœur politique discret de la chaîne. Le détenteur de ressources publie une autorisation d’origine dans une hiérarchie de certificats. Le logiciel de validation décide quels objets passent ses contrôles et en dérive les VRP. Le routeur compare l’annonce BGP aux VRP disponibles et calcule un état. L’opérateur décide de la conséquence. Si l’on attribue tous ces gestes à JANOG, on fabrique un pouvoir qui n’existait pas. Si l’on les attribue tous au registre, on nie l’autonomie du réseau.

Une architecture crédible rend au contraire ces responsabilités explicites, précisément parce qu’elles doivent être coordonnées lors d’un incident.

Quand les dépôts ont réellement failli

Deux incidents ultérieurs donnent un poids concret aux scénarios de données incomplètes, sans prouver qu’ils descendent du travail de 2013. Le premier s’est produit hors du Japon. Le 7 janvier 2021, une incohérence de publication dans le dépôt RPKI du RIPE NCC a créé un désaccord entre certificats parent et enfant. Des implémentations strictes, notamment des versions plus anciennes, ont rejeté l’ensemble des certificats de ressources RIPE. Le compte rendu publié le 8 janvier a dénombré 327 instances de logiciels de validation affectées et annoncé notamment un travail vers une publication atomique.

Le dénominateur est essentiel: il s’agit de 327 instances de logiciels de validation, et non de 327 opérateurs, routes ou pannes de clients. Le RIPE NCC a écrit que l’incident avait pu provoquer des interruptions, mais le document ne mesure pas une population d’utilisateurs touchés. Le cas montre qu’une incohérence du dépôt et des choix d’implémentation peuvent supprimer un vaste sous-arbre de la vue validée. Il ne permet pas de compter des pertes de connectivité ni d’en attribuer la cause à JANOG.

Le second incident touche directement JPNIC. Du 26 janvier au 2 février 2022, un disque plein a empêché la publication fraîche de la liste de révocation et du manifeste. Dans son avis d’incident, JPNIC a expliqué que presque tous les ROA qu’il avait émis étaient devenus invalides au niveau des objets du dépôt. Des routes BGP concernées ont été observées avec l’état NotFound. Le problème a été détecté par un utilisateur, puis corrigé manuellement.

Cette séquence doit être énoncée sans raccourci. Les objets ROA sont devenus invalides parce que les publications nécessaires à leur validation n’étaient plus à jour. Les validateurs ne disposaient donc plus des VRP correspondants. Face aux annonces BGP, l’absence de VRP couvrant a produit NotFound pour les routes observées. Cela ne signifie pas que toutes les routes BGP sont devenues Invalid. Cela ne signifie pas davantage qu’elles ont été rejetées. Le communiqué ne fournit ni nombre de routes concernées, ni nombre de parties utilisatrices, ni volume de trafic, ni compte d’usagers affectés, ni mesure d’interruption de bout en bout.

La nuance ne minimise pas l’incident; elle le rend actionnable. Si l’opérateur croit à tort que les routes sont Invalid, il peut rechercher une autorisation contradictoire ou une usurpation d’origine. Si le véritable état est NotFound à cause d’un ensemble VRP incomplet, l’enquête doit remonter vers la fraîcheur du dépôt, les manifestes, les journaux du validateur et les différences entre caches. La réparation n’est pas la même. L’action de routage ne doit pas être la même non plus.

Ces deux incidents établissent une classe de défaillance: une publication erronée peut réduire massivement la base validée, et les implémentations peuvent réagir différemment. Ils n’établissent pas une fatalité. La publication atomique, la surveillance de fraîcheur, la comparaison de plusieurs validateurs et des politiques qui ne transforment pas automatiquement l’absence d’information en rejet offrent des réponses. Mais ils montrent que la redondance des caches n’est utile que si l’on comprend ce qu’ils partagent. Multiplier les copies d’un dépôt incohérent ne restaure pas les objets absents.

Le Japon de la production: diversité, étapes et limites des chiffres

Une présentation d’IIJ à JANOG47 offre un contrepoint nécessaire au laboratoire de 2013. L’opérateur a décrit une progression, de mars à décembre 2020, depuis des tests vers un traitement par étapes sur son réseau AS2497. Dans son retour de déploiement, IIJ indiquait connecter chaque routeur à deux caches situés dans des sites nationaux différents et utilisant des implémentations différentes. Il signalait environ 3 000 routes initialement Invalid, soit près de 0,3 % de la table, puis un déploiement couvrant dix nœuds et moins de 2 000 pairs BGP.

Ces chiffres ont une fonction précise. Ils montrent qu’un opérateur pouvait définir une topologie, observer un volume d’anomalies, segmenter ses catégories de voisins et étendre la politique progressivement. Ils ne sont pas les résultats d’un audit externe. Les configurations brutes, le collecteur exact, l’instantané complet et tous les domaines de panne ne sont pas publics dans le dossier. Deux sites et deux logiciels réduisent certaines dépendances communes; ils ne démontrent pas l’indépendance des sources de données, de l’alimentation, des réseaux de transport ou des procédures humaines.

La mention de travaux JANOG antérieurs manifeste une mémoire institutionnelle, pas une preuve que JANOG32 a causé la décision d’IIJ.

À JANOG50, en juillet 2022, une expérience en environnement simulé a abordé une peur particulière: la reprise d’un routeur face à une table proche de la taille réelle. Le compte rendu de JPNIC publié le 17 août parle de près de 800 000 routes et rapporte un comportement de redémarrage qui ne différait pas sensiblement d’un redémarrage BGP ordinaire. Cette observation contredit utilement l’hypothèse selon laquelle le chargement de la validation provoquerait nécessairement une attente exceptionnelle.

Elle reste bornée. « Près de 800 000 » est un ordre de grandeur, pas un décompte exact. Le document est un résumé, sans données brutes de temps, matrice complète de versions ou preuve applicable à tous les routeurs, caches et politiques. Le test ne permet pas d’écrire que le redémarrage est désormais sûr partout. Il permet d’écrire qu’un risque formulé longtemps auparavant a reçu, dans un environnement donné, un contre-test plutôt rassurant.

Un an plus tard, le programme de JANOG52 comparait encore plusieurs implémentations de caches et plusieurs fournisseurs de routeurs, tout en laissant ouvert le traitement des routes Invalid. Cette continuité de la question est révélatrice. La maturité ne signifie pas disparition du choix local; elle permet de mieux mesurer ce choix. Là où le débat de 2013 demandait ce qui arriverait, les essais ultérieurs apportent des tailles de table, des topologies, des procédures de reprise et des observations. Mais ils ne transforment pas une communauté de réunion en autorité de production.

Une recommandation n’est pas une preuve de conformité

La recommandation JPNIC entrée en vigueur le 13 novembre 2024, puis mise à jour le 27 mars 2026, rassemble nombre de pratiques devenues familières. Le document JPNIC-01324 recommande de surveiller les processus et les ressources des caches, de suivre le rétablissement des collectes, de comparer régulièrement les données de plusieurs caches — le texte évoque une comparaison quotidienne — et de tester les redémarrages et reconnexions. Il préconise aussi une mise en œuvre progressive, des procédures de retour arrière et des réponses locales, y compris des exceptions de type SLURM, lorsque les données et la réalité opérationnelle divergent.

Le document traite aussi du cas où une déconnexion dépasse la durée de conservation. À ce point, l’opérateur doit avoir anticipé la perte de l’état validé et la politique qui s’appliquera. C’est la version procédurale de la question de 2013: pas un pourcentage magique, mais un ensemble de signaux, de tests et d’actions réversibles. Pourtant, une recommandation reste une recommandation. Elle ne prouve ni adoption universelle au Japon, ni conformité de chaque cache, ni filiation directe avec le groupe temporaire.

La géographie des services a également évolué. En janvier 2025, JPIX a présenté des points de cache publics dans les régions AWS de Tokyo et d’Osaka, accessibles en IPv4 et IPv6 sur le port TCP 323. Cette description est suffisamment précise pour identifier des points de service. Elle ne fournit pas de taux de disponibilité, de nombre de clients ni d’audit de la diversité des chemins. Deux régions ne garantissent pas à elles seules deux chaînes de dépendance indépendantes.

En décembre 2025, JPNIC a annoncé la fin du cache public expérimental qu’il exploitait depuis 2015. Le registre a invoqué le risque d’un point de concentration, l’existence d’alternatives offertes par des opérateurs ou des points d’échange, la publication de recommandations et une utilisation devenue moindre. Il serait excessif d’en conclure que les caches publics sont intrinsèquement dangereux ou que les solutions alternatives sont à l’abri des pannes.

La décision montre plutôt une réallocation des rôles: un service central d’amorçage peut perdre sa justification quand les opérateurs disposent d’options locales ou régionales et de meilleures procédures.

Le tableau n’est donc ni celui d’une centralisation inévitable, ni celui d’une autonomie totale. Les registres doivent publier correctement et expliquer leurs incidents. Les fournisseurs de caches et les points d’échange doivent rendre leurs dépendances observables. Les opérateurs doivent éviter une diversité de façade, tester la perte prolongée et savoir qui peut intervenir. JANOG peut mettre ces expériences en commun. Chacun de ces pouvoirs a une portée distincte, et la sûreté vient en partie du refus de les confondre.

Le meilleur argument contre l’immobilisme

À force de décrire les pannes, on pourrait laisser croire que la solution la plus prudente consiste à ne jamais agir sur la validation d’origine. Ce serait ignorer la raison pour laquelle RPKI existe. Une annonce BGP peut prétendre qu’un AS est à l’origine d’un préfixe qu’il n’est pas autorisé à annoncer. Lorsque des ROA corrects existent et que les données sont distribuées de manière fiable, la validation permet de détecter cette contradiction. Elle ne sécurise pas tout le chemin, mais elle réduit une classe réelle d’erreurs et d’attaques.

L’étude indépendante « RPKI Is Coming of Age », publiée en 2019, fournit le contre-argument le plus fort à une lecture pessimiste des premiers hackathons. Sur un horizon longitudinal mondial, ses auteurs observent que les erreurs de configuration, très fréquentes au début, étaient devenues beaucoup plus rares et soutiennent un usage plus ferme de RPKI. L’étude n’est pas une mesure du Japon et ne prouve aucune influence de JANOG. Sa méthodologie ne rend pas RPKI infaillible. Mais elle montre que les défauts de jeunesse ne doivent pas être projetés indéfiniment sur un écosystème qui apprend.

Le cas NTT publié par APNIC en décembre 2022 va dans le même sens depuis une perspective d’opérateur. Le retour d’expérience décrit une surveillance continue des annonces invalides dans les familles d’adresses et une réduction de 86,84 % de ces annonces au moyen de logiciels et de procédures. C’est un chiffre de cas d’étude, non un audit indépendant du jeu de données, et APNIC participe lui-même à l’écosystème RPKI. Il ne mesure pas un effet JANOG. Il illustre cependant un mécanisme précieux: la surveillance ne sert pas seulement à éviter un faux rejet; elle aide les détenteurs de ressources et les opérateurs à corriger les causes de l’invalidité.

Le conflit apparent entre sécurité et résilience se dissipe alors. Une politique progressive permet d’observer les résultats avant de rejeter. Le contact avec les réseaux concernés réduit les erreurs. Les exceptions locales peuvent protéger une route légitime pendant la correction, à condition d’être limitées et révisées. La diversité des validateurs et le contrôle de fraîcheur réduisent la probabilité qu’un défaut unique dicte une action massive. Une fois ces pratiques éprouvées, le traitement d’Invalid peut devenir plus strict et fournir le bénéfice attendu contre les origines non autorisées.

Le véritable immobilisme serait double: refuser ROV parce que le système a connu des incidents, ou l’activer brutalement en supposant que la cryptographie élimine la nécessité d’exploiter. La première position abandonne un bénéfice de sécurité démontrable. La seconde fabrique une nouvelle dépendance sans capacité de diagnostic. La maturité se mesure moins à l’absence de panne qu’à la faculté de voir la panne, d’en limiter la portée, de revenir en arrière et de rétablir ensuite une politique protectrice.

Le retour du disjoncteur

Le 16 juillet 2026, treize ans après JANOG32, le programme de JANOG58 présentait une proposition de « VRP breaker ». L’idée annoncée était de détecter une anomalie ou un ensemble de VRP incomplet et de suspendre temporairement la distribution. La proximité avec la question du pourcentage de 2013 est frappante. Elle ne permet pourtant pas d’écrire une filiation technique. À la date de consultation du 20 juillet, la page du programme ne donnait ni présentation publique complète, ni méthode détaillée, ni résultat de déploiement, ni validation indépendante. Le mécanisme était une proposition, annoncée comme faisant l’objet d’une demande de brevet.

Cette absence de résultat est substantielle. Un disjoncteur de VRP doit définir son état de référence: comparaison avec le dernier ensemble connu, avec d’autres validateurs ou avec une distribution historique. Il doit distinguer une chute due à un dépôt inaccessible d’une révocation massive légitime. Il doit prévoir la durée de la suspension, le traitement des nouvelles autorisations urgentes et la reprise après correction. Il doit éviter qu’un assaillant puisse maintenir un ancien état favorable en déclenchant sans cesse l’arrêt. Enfin, son périmètre devrait peut-être être local à un registre ou à une portion de l’espace plutôt que global.

Ce sont des questions de conception, pas des critiques d’un produit dont les résultats ne sont pas publics. Elles expliquent pourquoi aucun seuil universel ne peut être déduit de l’archive. Un pourcentage qui convient à un cache, une région et un profil de variation peut être aveugle ailleurs. L’anomalie pertinente n’est pas forcément la quantité totale; elle peut être la disparition d’un trust anchor, un écart entre implémentations, la fraîcheur d’un manifeste, une concentration inhabituelle d’Invalid chez un client ou la perte d’un ensemble critique de préfixes.

L’histoire ne boucle donc pas sur une invention attribuable à JANOG. Elle revient à une question qui résiste parce qu’elle est difficile: comment suspendre la propagation d’une erreur de sécurité sans suspendre la sécurité elle-même ? Le groupe temporaire a laissé une trace publique de cette question. Les standards, les incidents et les opérateurs ont depuis ajouté des mécanismes et des mesures. Le disjoncteur de 2026 rappelle qu’une réponse complète reste un objet d’ingénierie et de preuve.

Ce qu’exigerait une preuve plus forte

Pour affirmer que le groupe de 2013 a directement façonné les déploiements ultérieurs, il faudrait davantage qu’une citation dans une présentation. Il faudrait des décisions datées, des documents d’architecture ou des témoignages techniques reliant explicitement une question de JANOG32 à un choix précis: deux implémentations plutôt qu’une, une durée de rétention, une procédure de retour arrière, un système d’alerte. Il faudrait aussi écarter les explications concurrentes: les RFC, les recommandations des registres, les progrès des logiciels, les incidents internationaux et l’expérience propre des opérateurs.

Pour affirmer qu’un mécanisme de sûreté fonctionne, il faudrait un protocole de test reproductible. Quelle version de validateur ? Quelle vue des dépôts ? Combien de VRP avant et après ? Quelle table BGP ? Quel routeur ? Quelle durée de conservation ? Quel temps de bascule ? Quelle action de politique ? Quels effets sur le plan de transfert ? Les exercices de 2013 ne livrent pas ce niveau de détail. Le test de JANOG50 apporte une taille de table approximative et une observation de reprise, sans matrice universelle. Les retours d’IIJ et de NTT offrent des mesures utiles, mais demeurent des déclarations d’opérateurs ou des études de cas.

Pour établir une panne de connectivité, enfin, il faudrait suivre la chaîne jusqu’au bout. Un objet rejeté réduit-il le jeu de VRP ? Quel état apparaît sur quels routeurs ? La politique change-t-elle la sélection ou le FIB ? Quels flux cessent d’aboutir ? Pendant combien de temps et pour combien d’utilisateurs ? Ni l’incident RIPE de 2021 ni celui de JPNIC en 2022 ne fournit ce dénominateur complet. Les présenter comme des pannes d’Internet mesurées dépasserait les sources.

Cette discipline probatoire n’est pas un luxe académique. Elle empêche une organisation de tirer la mauvaise leçon d’un incident. Si l’on confond une absence de VRP avec une route Invalid, on peut durcir la mauvaise politique. Si l’on confond une instance de validateur avec un opérateur ou un utilisateur, on gonfle l’impact. Si l’on confond une recommandation avec une conformité, on cesse de tester. Et si l’on confond une discussion de communauté avec une autorité, personne ne sait plus qui doit réparer quoi.

Conclusion — La confiance a besoin d’une marche arrière

Au redémarrage de notre routeur imaginaire, la bonne question n’est pas: « RPKI fonctionne-t-il ? » Elle est plus précise. Les objets du dépôt sont-ils frais et cohérents ? Les validateurs indépendants produisent-ils des ensembles comparables ? Le routeur a-t-il conservé une base connue et rejoint un cache de remplacement ? Les états de validation ont-ils changé de façon plausible ? La politique locale est-elle réversible ? Et dispose-t-on d’une observation du trafic capable de distinguer une alerte d’une perte réelle de connectivité ?

Le groupe RPKI temporaire de JANOG n’a pas répondu à toutes ces questions. Entre le 22 janvier et le 31 juillet 2013, il a fait passer des entités de l’explication à la manipulation, rencontré des défauts, recommencé et exposé en public les scénarios qui menaçaient la continuité. Les mécanismes importants de cache et de rétention figuraient déjà dans la RFC 6810. La décision de routage demeurait locale, comme l’a ensuite souligné la RFC 7115. JPNIC assurait des fonctions de registre et de service; les opérateurs gardaient leurs routeurs. Aucun seuil numérique adopté ne ressort de l’archive.

Les années suivantes ont donné au problème des contours plus nets. IIJ a décrit deux caches, deux sites, deux implémentations et un déploiement par étapes. Un essai proche de 800 000 routes a relativisé, dans son environnement, la peur du redémarrage. Le RIPE NCC et JPNIC ont montré que des erreurs de publication pouvaient retirer de vastes ensembles de la vue validée, sans fournir pour autant un compte complet des utilisateurs affectés. JPNIC a rassemblé surveillance, comparaison, retour arrière et exceptions dans une recommandation.

JPIX a offert d’autres points de cache; JPNIC a retiré un cache central; un nouveau disjoncteur a été proposé sans résultat public.

Dans le même temps, les recherches longitudinales et le cas NTT rappellent que RPKI apprend et qu’il protège. La bonne conclusion n’est donc pas de maintenir indéfiniment toutes les routes à l’abri de toute action. Elle est de rendre l’action graduelle, visible et récupérable, puis de la renforcer à mesure que les données et les procédures deviennent fiables. Une validation d’origine qui ne peut jamais conduire à une décision ne remplit pas sa mission. Une validation qui ne sait pas survivre à sa propre chaîne de dépendances n’est pas encore crédible.

La sûreté ne réside pas dans un chiffre secret au-delà duquel tout s’arrête. Elle réside dans la capacité à nommer la couche en panne, à conserver un état borné, à comparer des sources, à suspendre une propagation suspecte sans figer aveuglément le passé, et à laisser l’opérateur reprendre la main. En 2013, JANOG a offert une pièce où cette difficulté pouvait être vue. Le travail décisif, lui, se déroule toujours dans les dépôts, les caches, les routeurs et les procédures qui doivent continuer à fonctionner lorsque le signal de confiance devient silencieux.

Métadonnées éditoriales

Champ	Valeur
Titre SEO	RPKI et continuité: la leçon du groupe temporaire de JANOG
Description SEO	En 2013, un groupe temporaire réuni par JANOG a expérimenté la chaîne RPKI et exposé ses modes de panne. Comment valider sans couper ?
Titre Open Graph	Quand la validation RPKI doit survivre à ses propres pannes
Description Open Graph	Des exercices JANOG de 2013 aux incidents de dépôt et aux déploiements japonais: enquête sur une validation d’origine sûre, progressive et réversible.
Titre Twitter	RPKI: sécuriser l’origine sans créer un point de panne
Description Twitter	Ce que les essais de JANOG, les RFC, IIJ, JPNIC, RIPE NCC et NTT enseignent sur les caches, `NotFound`, `Invalid` et le retour arrière.
Mot-clé principal	sûreté de la validation d’origine RPKI
Slug	janog-rpki-validation-origine-surete-pannes
Catégorie	jpnog
Sujet contrôlé	rpki-and-route-security
Texte alternatif de l’image	Dans une salle réseau sombre, une ingénieure observe deux caches RPKI redondants alimentant un routeur, tandis qu’un flux interrompu est isolé avant d’atteindre le trafic.
Légende de l’image	La validation d’origine devient crédible quand une anomalie du dépôt, du cache ou du transfert peut être isolée sans se transformer automatiquement en perte de route.
Description d’accessibilité	Illustration horizontale à fort contraste: à gauche, deux serveurs de cache distincts; au centre, un indicateur de contrôle suspend une mise à jour anormale; à droite, le routeur continue d’acheminer les flux connus. Aucun texte essentiel n’est intégré dans l’image.
Provenance de l’image	Illustration éditoriale originale BTW, conçue pour cet article à partir du schéma fonctionnel public dépôt–validateur–RTR–routeur; aucun logo, visage réel, tableau de bord propriétaire ou capture d’incident n’est reproduit.