Résumé

  • L’interface Routinator hébergée par AFRINIC sait déduire l’ASN d’origine d’une observation BGP avant de confronter le préfixe et cet ASN aux autorisations RPKI.
  • Dans l’échantillon figé, la recherche de 196.216.2.0/23 a retenu AS33764 depuis riswhois par correspondance exacte, sans livrer l’heure de l’instantané BGP. La réponse RPKI a indiqué valid et une heure de génération, sans reprendre la source BGP ni sa date.
  • Les âges globaux ne sont pas cachés : une table séparée publie la fraîcheur des données RPKI, BGP et des registres. Ce qui manque est le lien durable entre ces états et un résultat particulier.
  • Un reçu de validation composé devrait fixer l’entrée, le mode de recherche, la sélection BGP et son instantané, la version et le numéro de série de Routinator, les VRP examinés, l’heure de réponse et une empreinte vérifiable.

Le logiciel ne répond plus tout à fait à la même question

Saisir un préfixe et un ASN revient à poser une question déterminée : cet ASN est-il autorisé, dans l’état RPKI du validateur, à annoncer ce préfixe avec cette longueur ? Activer la recherche automatique de l’ASN pose d’abord une autre question : quel ASN la vue BGP choisie associe-t-elle au préfixe ? Le résultat final rassemble les deux réponses, même si l’écran les fait tenir dans un même geste.

Ce raccourci est bien conçu pour le diagnostic. Il évite une erreur de copie. Il aide l’ingénieur qui part d’une adresse ou d’un bloc et qui veut comprendre l’origine observée. Il rend aussi explicite un choix souvent enfoui dans les outils : prendre uniquement la correspondance exacte ou accepter le préfixe le plus long qui contient la cible. L’interface publique d’AFRINIC donne donc davantage de contrôle qu’un simple champ de recherche opaque.

La difficulté commence lorsque le résultat quitte la page. Un opérateur l’insère dans un ticket ; un collègue le relit après un changement de route ; un auditeur demande ce que signifiait le vert d’une capture d’écran. La réponse RPKI peut être parfaitement correcte pour le couple qu’elle a reçu, alors que le débat porte sur la façon dont ce couple a été choisi. Sans l’instantané BGP, le numéro de série de la source et la règle de correspondance, la moitié amont de la preuve a disparu.

Trois sources sont affichées, deux opérations produisent le verdict

Le service public mérite d’abord une lecture favorable. Sa rubrique de fraîcheur distingue RPKI, BGP et les données d’allocation des RIR. L’état de Routinator expose la version du logiciel, le numéro de série de validation, les repères du cycle de mise à jour et des compteurs détaillés par ancre de confiance. L’état du service de recherche nomme riswhois comme source BGP et fournit son propre numéro de série et son champ lastUpdated. Les fichiers d’allocation d’AFRINIC et des quatre autres RIR ont leurs dates propres.

Cette séparation est importante. Elle reconnaît déjà que la page n’observe pas un seul monde à une seule heure. La cryptographie RPKI, les annonces visibles depuis un collecteur et la classification d’un bloc par un registre répondent à des autorités différentes. Leur juxtaposition peut éclairer un diagnostic, mais ne les rend pas interchangeables.

Le 12 septembre 2026, l’échantillon public retenu pour cet article a demandé 196.216.2.0/23. La réponse de recherche a conservé le même préfixe. Une entrée de métadonnées a identifié la source d’allocation AFRINIC. Une autre a désigné riswhois, donné AS33764 comme origine et qualifié la relation d’exact-match.

La requête suivante à Routinator a testé AS33764 avec 196.216.2.0/23. Le service a rendu l’état valid et montré un VRP correspondant : même ASN, préfixe 196.216.2.0/23, longueur maximale 24. Il a également livré generatedTime. Le lecteur dispose donc du couple, de l’issue et de l’autorisation correspondante ; le résultat ne se réduit pas à une couleur.

Pourtant, la réponse de recherche ne comportait pas la date de mise à jour de riswhois. La réponse de validité ne comportait ni riswhois, ni l’heure de l’observation BGP, ni le mode de sélection, ni l’état du fichier d’allocation. Ces renseignements existaient ailleurs au moment de la capture, mais ils n’étaient pas attachés à ce constat.

Il faut résister à une conclusion excessive. Cela ne prouve pas l’absence de journaux internes. Cela ne rend pas le résultat faux. Cela ne montre ni panne, ni annonce périmée, ni erreur d’un membre. Cela montre seulement que l’objet rendu par le service ne suffit pas, à lui seul, à refaire la chaîne qui l’a produit.

La date globale ne remplace pas la provenance locale

Une table de fraîcheur générale répond à la question « de quand datent les sources visibles maintenant ? ». Un reçu répond à « quelles versions ont servi à cette réponse-là ? ». La nuance semble administrative jusqu’au moment où une source se rafraîchit entre la capture d’écran et l’enquête.

Rejouer la requête ne récupère pas le passé. BGP a pu changer d’origine, Routinator achever un nouveau cycle ou un fichier d’allocation avancer. La nouvelle réponse est précieuse, mais elle constitue une nouvelle observation. Elle ne corrige ni n’annule la précédente. Sans identifiants de versions, les deux couleurs peuvent être comparées tandis que les objets réellement comparés restent inconnus.

Il en va de même pour le mot valid. Dans ce contexte, il signifie qu’au moins un VRP couvrant correspond au préfixe, à sa longueur et à l’ASN d’origine. Il ne garantit ni la qualité du chemin BGP, ni la portée mondiale de l’annonce, ni son acceptation par un routeur, ni son bien-fondé commercial ou contractuel. La politique locale de l’opérateur reste souveraine.

Le fichier d’allocation doit également garder sa place. Il permet d’indiquer la région, de rapprocher des préfixes ou d’ajouter du contexte de registre. Il ne signe pas l’origine BGP et ne produit pas le verdict RPKI. Un bon reçu conserve sa version précisément pour montrer son rôle limité, pas pour l’élever au rang d’autorisation.

Un reçu court, avec des verbes précis

Le service pourrait proposer un téléchargement structuré qui fixe :

  • le préfixe demandé et l’ASN saisi, s’il y en a un ;
  • l’activation ou non de la recherche BGP ;
  • la règle « correspondance exacte » ou « préfixe correspondant le plus long » ;
  • le préfixe et l’ASN retenus, avec l’identifiant de la source BGP ;
  • le numéro de série et l’heure lastUpdated de cette source ;
  • la source d’allocation affichée à titre de contexte et sa version ;
  • la version de Routinator, le numéro de série de validation et l’achèvement du cycle ;
  • l’état RPKI et les empreintes des VRP correspondants ou non correspondants ;
  • l’heure de génération, l’empreinte du reçu et, si nécessaire, le lien vers un reçu qui le remplace.

Les verbes doivent empêcher le glissement d’autorité. BGP « a observé » une origine depuis une vue donnée. Le fichier du registre « a classé » une ressource. Routinator « a comparé » le couple avec son ensemble validé. L’opérateur, lui, « a décidé » d’accepter, de préférer, d’alerter ou de filtrer. Aucun champ ne devrait laisser entendre que l’un de ces acteurs a exercé le pouvoir d’un autre.

Le reçu peut rester respectueux de la confidentialité. Une vérification publique porte déjà sur un préfixe et un ASN publics. Pour un dossier sensible, l’organisation peut garder la pièce complète et ne partager qu’une empreinte, les identifiants de sources et la classe de résultat. Il n’est pas nécessaire de publier les notes du NOC ni l’historique du client.

Ne pas transformer l’outil en autorité accidentelle

Les outils commodes acquièrent une réputation plus large que leur contrat. Une capture accompagnée du nom AFRINIC peut être résumée, quelques semaines plus tard, par « AFRINIC a déclaré cette route valide ». Cette phrase efface la source BGP, le cycle RPKI et la politique de l’opérateur. Elle transforme un diagnostic hébergé en décision institutionnelle.

Un reçu composé protège aussi AFRINIC. Il borne exactement ce que le service a fait et ce qu’il n’a pas fait. Il permet de dire : le logiciel a sélectionné ce couple à partir de cet état de riswhois, puis il l’a comparé à ce cycle Routinator. La conclusion reste vérifiable sans promettre une vue totale de BGP ni un comportement uniforme des routeurs.

L’interface sait déjà montrer que ses sources vivent à des rythmes différents. La discipline suivante consiste à faire survivre cette honnêteté à l’instant où le résultat est copié.

Sources

Le contexte institutionnel figure sur la page de certification des ressources d’AFRINIC et l’outil sur l’interface Routinator hébergée. L’observation repose sur l’état de Routinator, l’état des sources BGP et RIR, la recherche du préfixe de l’échantillon et sa réponse de validité RPKI. La fonction de l’interface est décrite dans la documentation Routinator de NLnet Labs ; la logique publique observée de recherche BGP et de fraîcheur se trouve dans le bundle d’interface versionné.