Résumé

  • La feuille de route d’APNIC vise, pour le troisième trimestre 2026, l’affichage dans REx des informations VRP actuelles et historiques concernant une ressource Internet individuelle. La fiche publique ne précise pas encore le schéma, la cadence ni la limite des archives.
  • Un ROA signé, le VRP qu’un logiciel de relying party en dérive, l’état Valid, Invalid ou NotFound d’une route BGP et l’action décidée par un réseau constituent quatre preuves différentes.
  • Chaque période historique devrait porter un bandeau de provenance : ressource interrogée, relation exacte ou couvrante, tuple préfixe–maxLength–ASN d’origine, instant d’observation, version du jeu de données, méthode, complétude et exclusion explicite de la politique locale des opérateurs.

Le risque apparaît dès que l’interface devient convaincante. Une frise nette, une période verte, une rupture rouge : le lecteur croit voir un événement. Il attribue la transition à un détenteur, à un registre ou à un routeur, alors que l’écran ne montre peut-être que deux observations faites à des moments différents.

APNIC peut éviter ce piège avant même le lancement. Sa feuille de route 2026 contient une fiche intitulée « Display RPKI VRP information for individual INR in REx ». L’équipe responsable est Information, les produits associés sont REx et RPKI, et la cible est le troisième trimestre. Les objectifs annoncés sont d’élargir l’accès communautaire aux informations d’état RPKI et d’apporter un contexte historique pour chaque ressource numérique. La solution proposée tient en une phrase : montrer les informations d’état VRP présentes et passées.

Cette concision est normale pour une feuille de route. Ce n’est pas une spécification d’écran. Lors de la capture, le champ de changelog du jeu de données public était vide. La fiche ne nommait ni les colonnes futures, ni la fréquence d’observation, ni le validateur, ni les ancres de confiance, ni les identifiants des objets sources, ni la durée de conservation. On ne peut pas en conclure qu’APNIC ne les a pas définis en interne. On peut seulement constater que le lecteur public ne dispose pas encore du contrat de sens qui accompagnera la chronologie.

Ce contrat sera décisif. Une page REx sera rapidement utilisée au-delà de son intention initiale. Un ingénieur joindra une capture à un ticket. Un chercheur comptera les bascules. Une équipe de réponse à incident alignera la frise avec des annonces BGP. Un acquéreur d’adresses ajoutera le graphique à sa diligence. À ce moment-là, une commodité d’interface devient une pièce de preuve.

Le mot « valide » change de sujet

L’architecture RPKI juxtapose plusieurs objets qui reprennent un préfixe et un ASN. Leur ressemblance n’abolit pas leurs fonctions.

Le ROA vient d’abord. APNIC le présente comme un objet signé numériquement qui autorise un système autonome à annoncer un préfixe, avec l’ASN autorisé, le préfixe et la longueur maximale. La RFC 9582 impose ensuite au relying party de valider l’objet signé et d’effectuer les vérifications propres au ROA avant de l’utiliser contre une annonce de routage. L’échec d’une de ces vérifications rend le ROA entier invalide.

Le VRP vient après. Ce n’est pas le fichier signé rebaptisé. L’explication technique publiée par APNIC décrit un logiciel de relying party qui récupère les objets RPKI, vérifie leur cryptographie et en extrait des tuples : ASN, préfixe, longueur de préfixe et maxLength. Le VRP est donc un produit dérivé d’un point de validation. Il garde l’autorisation utile à la validation d’origine, mais il n’est plus le contenant signé.

L’état d’origine concerne ensuite une route BGP. La RFC 6811 demande si le préfixe de cette route est couvert par un VRP, si sa longueur respecte maxLength et si son ASN d’origine correspond. Au moins une correspondance donne Valid. Une couverture sans correspondance donne Invalid. L’absence de tout VRP couvrant donne NotFound. Ces mots qualifient la route soumise au calcul, pas la ressource toute seule.

Enfin vient la politique. La RFC 7115 rappelle que l’usage du résultat dans le routage relève de la politique locale de l’opérateur. Un réseau peut rejeter les annonces Invalid ; un autre peut commencer par les journaliser ; un troisième peut intégrer l’état à un ensemble plus large de préférences et d’exceptions. Le résultat de validation ne contient pas cette décision. Il ne prouve pas non plus le chemin réellement emprunté par les paquets.

Une interface honnête doit conserver ces quatre sujets : validité de l’objet signé, présence du tuple dérivé, résultat appliqué à une route déterminée, choix local du réseau. Les fusionner sous un badge unique reviendrait à transférer une autorité qui n’existe pas.

« Aucun VRP » ne dit pas pourquoi

La difficulté est moins visible lorsque le tuple est présent. Le préfixe, maxLength et l’ASN peuvent être affichés. Elle devient aiguë quand la frise montre un vide.

L’absence d’un VRP dans une observation peut suivre le retrait volontaire d’une autorisation. Elle peut aussi venir de l’expiration ou de l’invalidation d’un objet, d’un problème de manifeste ou de certificat, d’un retard de récupération, d’une remise à zéro du cache, d’une lacune d’archive ou d’un changement de méthode. Elle peut enfin provenir de la relation entre la ressource saisie et le préfixe affiché : le lecteur attendait une correspondance exacte, alors que l’autorité pertinente était couvrante.

La chronologie ne doit pas choisir une cause sans preuve. La formulation sûre est sobre : « aucun VRP dérivé dans cette observation REx ». Elle est moins spectaculaire que « le détenteur n’avait pas de ROA ». Elle est aussi vérifiable. La seconde phrase attribue une action à une partie ; la première décrit le contenu d’un jeu de données.

Cette discipline protège également APNIC. Un membre qui conteste une période ne devrait pas avoir à réfuter une accusation implicite. Il devrait pouvoir retrouver le tuple, l’instant et la méthode, reproduire le désaccord et fournir un autre point d’observation.

Une date n’identifie pas le regard

La distribution du RPKI rend les horloges concrètes. La RFC 8210 décrit un cache comme une copie agrégée des données RPKI publiées, récupérée périodiquement par un logiciel de relying party. Le numéro de série représente une version logique du cache. Des intervalles de rafraîchissement, de nouvelle tentative et d’expiration règlent le passage des données du cache vers le routeur. Si la mise à jour incrémentale n’est plus disponible, une remise à zéro et un chargement complet peuvent être nécessaires. Les caches distribués ne sont pas rigoureusement synchrones.

L’étude hébergée par le blog APNIC sur la synchronisation distingue trois étages : publication, cache intermédiaire et application dans la politique BGP. Elle avertit qu’une vue incomplète ou ancienne peut entraîner des résultats de validation erronés. Surtout, les auteurs définissent leur propre seuil de fraîcheur pour leur mesure. Ils ne traitent pas la fraîcheur comme une essence universelle.

Une période duau ne suffit donc pas. Il faut connaître le moment où REx a observé le jeu, la version du jeu de données, la méthode qui l’a produit et la qualité de la collecte. Lorsqu’un validateur, une ancre, une logique d’archive ou une règle de comparaison change, la frise devrait porter un marqueur de méthode. Sinon, une rupture de l’instrument ressemble exactement à une rupture du monde observé.

Nommer le point d’observation ne signifie pas publier la topologie interne ou les secrets d’exploitation d’APNIC. Cela signifie borner la phrase : « selon ce jeu REx, produit par cette méthode documentée, complet ou qualifié à cet instant ». La provenance sert la reproductibilité, pas la cartographie de l’infrastructure.

Le rapport entre la requête et le préfixe doit rester visible

Une recherche portant sur une ressource individuelle peut cacher trois requêtes distinctes. Le lecteur veut-il un VRP exactement égal au préfixe saisi ? Veut-il aussi un VRP couvrant, par exemple un /16 dont maxLength autorise le /24 recherché ? Veut-il les autorisations plus spécifiques situées à l’intérieur de la ressource ?

Ces vues ont toutes une utilité. Elles ne sont pas interchangeables. Les règles de couverture de la RFC 6811 utilisent la longueur et les bits communs du préfixe ; maxLength décide ensuite si l’annonce plus spécifique peut correspondre. Un badge sans cette relation peut masquer la raison même du résultat.

REx devrait donc afficher la relation avant le verdict : exacte, couvrante, plus spécifique ou agrégée selon une définition publiée. Plusieurs VRP applicables doivent rester plusieurs lignes. Lors d’une transition, le lecteur doit voir quel tuple est apparu, a disparu ou a changé. Un compteur ne permet pas de distinguer un nouvel ASN d’origine, un maxLength resserré et la suppression d’une autorisation redondante.

Un bandeau de provenance, pas un deuxième tableau de bord

L’instrument nécessaire est petit. Chaque état courant et chaque période historique peuvent recevoir un bandeau composé des éléments suivants :

  1. La ressource saisie et sa relation avec le préfixe affiché.
  2. La classe d’objet : ROA signé, VRP dérivé ou résultat de validation d’une route.
  3. Le tuple VRP complet : préfixe, maxLength, ASN d’origine.
  4. Le début, la fin et l’instant effectif d’observation, avec fuseau horaire.
  5. Un identifiant stable de version ou de snapshot REx.
  6. La méthode de dérivation et sa version lorsque celle-ci affecte la comparaison.
  7. Les ancres de confiance et une indication de complétude de récupération suffisamment précise pour qualifier le résultat.
  8. Un drapeau pour les changements de méthode et les lacunes d’archive.
  9. Un lien vers la définition active et l’observation suivante.
  10. Une limite lisible : cette page ne montre ni le cache d’un opérateur donné, ni sa politique, ni sa route sélectionnée, ni le trajet des paquets.

Rien dans cette liste n’exige la publication d’une clé privée, d’un identifiant de membre, d’un détail d’incident non public ou de la topologie des collecteurs. Il s’agit de décrire la preuve publiée, non d’ouvrir les systèmes qui la produisent.

Ce que l’historique pourra affirmer

Avec ce bandeau, REx pourra formuler des constats forts et étroits. À tel instant, sa méthode documentée a dérivé tel tuple. Ce tuple était encore présent dans les observations suivantes. Un tuple a disparu tandis qu’un autre est apparu. Une période n’est pas comparable parce qu’une lacune de collecte ou un changement de méthode intervient. Un tiers peut reprendre l’identifiant du snapshot et vérifier le compte.

En revanche, le même écran ne pourra pas prouver qu’un détenteur a volontairement retiré l’autorisation au premier point manquant. Il ne pourra pas affirmer que tous les relying parties ont reçu la transition au même moment. Il ne pourra pas classer une route sans nommer son préfixe et son origine. Il ne pourra pas déduire qu’un opérateur a rejeté l’annonce, ni qu’un incident, un détournement ou une perte de trafic a suivi.

L’article d’APNIC sur la mesure des ROA et du ROV offre une analogie utile. Une observation faite depuis un seul accès peut attribuer à tous les réseaux situés derrière lui le filtrage réalisé par l’amont. Le paquet n’arrive pas, mais l’auteur de la décision n’est pas celui que la mesure naïve désigne. La leçon vaut pour REx : une observation exacte peut soutenir une attribution fausse si son point de vue disparaît de la présentation.

Une mémoire publique qui sait rester partielle

Le bon usage de la future frise n’est pas de remplacer un rapport d’incident. C’est de fournir un témoin stable. L’équipe d’enquête pourra joindre ce témoin aux observations BGP, aux exports locaux du validateur, aux journaux des routeurs, aux communications du détenteur et aux mesures de trafic. REx dira ce qu’il a vu ; les autres preuves diront ce qui s’est produit ailleurs.

Cette modestie augmente la valeur du produit. Les membres disposent d’un objet contestable et reproductible plutôt que d’un verdict. Les chercheurs peuvent séparer l’évolution du RPKI de l’évolution des archives. Les opérateurs peuvent comparer leur vue locale avec une référence publique sans supposer que l’une commande l’autre. APNIC gagne en autorité comme source précisément parce qu’il refuse de parler au nom de chaque routeur.

Sources