Résumé

  • Au numéro de série 23421, le Routinator 0.14.2 public d'AFRINIC affichait 39 059 VRP valides en entrée, 8 212 doublons et 30 847 VRP finales.
  • Au numéro 23422, les deux premiers nombres sont passés à 39 058 et 8 211, tandis que les 30 847 VRP finales sont restées inchangées.
  • Selon la documentation de Routinator, un doublon résulte de ROA portant la même autorisation ; son attribution peut varier avec l'ordre de traitement entre deux validations.
  • Rien dans ces captures n'identifie l'objet, son détenteur ou un effet BGP. Il faut une quittance de lignée pour relier objets sources, tuple unique, jeu final et observation du routeur.

Le nombre qui n'a pas bougé est le plus instructif

La première photographie a été prise alors que le service public d'AFRINIC exposait le numéro de série 23421. La validation correspondante s'était achevée le 29 août à 06 h 37 min 53 s UTC. Pour l'ancre AFRINIC, le calcul était net : 39 059 VRP présentes et valides, moins 8 212 classées comme doublons, donnaient 30 847 VRP contribuant au jeu final. Aucune VRP n'était comptée comme dangereuse ou filtrée localement.

À 06 h 57 min 08 s, une nouvelle validation s'est terminée et le numéro de série est passé à 23422. Le total d'entrée a reculé à 39 058 ; le nombre de doublons, à 8 211. Le résultat de la soustraction est resté 30 847.

La ventilation permet de situer le mouvement sans le surinterpréter. En IPv4, les entrées sont passées de 37 804 à 37 803 et les doublons de 8 136 à 8 135 ; le total final est resté 29 668. En IPv6, les trois valeurs n'ont pas changé : 1 255, 76 et 1 179. Les points de publication valides sont demeurés au nombre de 1 408, sans point rejeté.

Le second état comptait aussi 12 170 ROA valides et une invalide, contre 12 171 et zéro dans le premier. La coïncidence numérique attire l'œil, mais le service ne fournit pas l'identifiant qui permettrait d'affirmer que cette ROA est la source de la variation du doublon. Une colonne qui perd une unité n'est pas une relation entre objets.

On peut donc dire qu'une occurrence valide et une occurrence classée en doublon ne figuraient plus dans l'agrégat ultérieur, alors que le nombre final n'avait pas changé. On ne peut pas dire quelle autorisation est concernée, qu'elle a été retirée, corrigée ou remplacée, ni qui aurait agi. On ne peut même pas déduire de la seule égalité des comptes que chaque tuple du jeu final était identique : une sortie et une entrée pourraient se compenser. Il faudrait comparer les jeux eux-mêmes.

Ce degré de retenue n'affaiblit pas l'information. Il la place au bon niveau. Le compteur décrit le résultat local d'une validation ; il n'est ni un journal causal, ni un bulletin de santé de toutes les routes africaines.

Quatre objets se cachent derrière le même raccourci

Une ROA est un objet signé de la RPKI. Elle désigne un système autonome d'origine et contient une ou plusieurs autorisations de préfixe, avec éventuellement une longueur maximale. Elle possède un certificat, une localisation de publication et une histoire propre.

Une VRP est le résultat compact que le validateur en tire pour la validation d'origine : adresse IP, longueur du préfixe, longueur maximale et numéro d'AS d'origine. Une ROA peut produire plusieurs VRP. Plusieurs occurrences issues d'objets ou de chemins de publication distincts peuvent représenter exactement le même tuple.

Le jeu final est encore autre chose. Routinator élimine de sa contribution les occurrences qu'il attribue comme doublons, ainsi que les éléments filtrés localement et, suivant la configuration, certaines VRP dangereuses. Le routeur n'a pas besoin de recevoir deux fois la même autorisation pour comparer un préfixe BGP à ce qu'autorise la RPKI.

Enfin, une route est une observation BGP avec un préfixe et une origine déduite de l'AS_PATH. Son état de validation dépend de la comparaison avec les VRP disponibles : valide si au moins une correspond, invalide si une VRP couvre le préfixe sans qu'aucune ne corresponde, ou introuvable si aucune ne le couvre. Le nombre de doublons d'une ancre ne donne aucun de ces trois états pour une route déterminée.

Mélanger ces objets produit des phrases trompeuses. « Une ROA a disparu » confond occurrence validée et objet signé. « Une route a été retirée » confond autorisation et annonce BGP. « AFRINIC a supprimé un doublon » attribue une action à l'opérateur de l'ancre et du service, alors que l'objet peut dépendre d'un détenteur et que l'attribution peut venir du traitement du validateur. « La sécurité s'est améliorée » invente un effet que le jeu final inchangé ne mesure pas.

La bonne chaîne distingue aussi les responsabilités. Le détenteur signe l'autorisation. Un ou plusieurs dépôts la publient. Le validateur la récupère, vérifie et attribue les occurrences selon sa configuration. Le cache propose un jeu final. L'opérateur du routeur choisit ses caches et sa politique. AFRINIC est au centre de plusieurs de ces fonctions dans le cas observé, mais le mot « AFRINIC » ne remplace pas chaque acteur de la chaîne.

Un doublon n'est pas un verdict sur la qualité

Dans le langage courant, le doublon ressemble à une faute : une ligne superflue à effacer. Dans un graphe de publication cryptographique, la multiplicité a des causes très différentes. Elle peut être involontaire, accompagner une migration, provenir d'autorisations qui se chevauchent, d'un renouvellement ou de plusieurs chemins conduisant au même tuple. Le compteur ne distingue pas ces histoires.

La documentation de Routinator ajoute une réserve décisive. Lorsqu'une VRP apparaît dans plusieurs ancres de confiance ou dépôts, l'occurrence considérée comme doublon dépend de l'ordre de traitement. Cet ordre peut changer d'une validation à l'autre ; le nombre peut donc varier de manière inattendue. Il s'agit d'une propriété comptable du validateur, pas nécessairement d'un changement de droit de routage.

Cette réserve interdit aussi de transformer les colonnes des cinq ancres en classement. Les captures exposent des nombres très différents selon les RIR. Ils dépendent du moment, de la version 0.14.2, de la configuration, de la topologie des dépôts et des règles d'attribution. Un nombre élevé n'est pas la preuve d'une mauvaise discipline ; zéro n'est pas un certificat d'excellence. La comparaison devient utile seulement si l'on garde les objets et les règles constants.

Le jeu final stable fournit ici une limite concrète. La multiplicité observée a diminué d'une unité, sans réduire le nombre final. C'est compatible avec la disparition d'une occurrence redondante. « Compatible » n'est toutefois pas « démontré ». Le service n'offre pas le diff de tuples nécessaire, et il avertit lui-même que l'attribution peut bouger.

La formule honnête doit donc être plus longue que le titre : entre deux validations du même service, les comptes d'entrées et de doublons attribués à l'ancre AFRINIC ont baissé ensemble, tandis que le compte final est resté identique. Aucune cause et aucun effet de routage ne sont établis.

L'API sait décrire un état, pas raconter son histoire

Le point d'accès public est précieux. La documentation le présente comme une source JSON exhaustive sur les ancres, les dépôts, les connexions RRDP et rsync, ainsi que les sessions RTR et HTTP. L'interface web en tire ses statistiques de la dernière validation. Version, série et horodatage rendent la mesure réfutable.

Mais l'exhaustivité porte sur la représentation de l'état du service, pas sur la généalogie de chaque variation. La réponse ne donne pas, pour la paire de séries observée, une table disant : tel hash d'objet a cessé d'être valide ; tel tuple existait deux fois et n'existe plus qu'une fois ; telle attribution a changé parce que l'ordre de traitement a changé. Sans cette table, le lecteur doit s'arrêter au constat agrégé.

La présence de statistiques RTR ne ferme pas non plus la chaîne. Un cache peut proposer un jeu final ; il ne prouve pas qu'un routeur donné l'a reçu, qu'il l'a conservé ou qu'une politique locale a rejeté une route. Pour parler d'effet opérationnel, il faut un reçu du client, le numéro de série consommé, la route BGP observée et l'action de politique correspondante.

Cette séparation protège autant l'institution que ses critiques. Elle empêche d'imputer à AFRINIC l'intention d'un détenteur ou la décision d'un routeur. Elle empêche aussi de balayer une variation comme « simple doublon » lorsque, dans un autre cas, le tuple unique pourrait réellement quitter le jeu final. La lignée rend les deux conclusions possibles, chacune avec ses preuves.

Une quittance de lignée suffirait

La première partie de la quittance identifierait la validation : version et empreinte de configuration, numéro de série, heures de début et de fin, empreinte de l'ensemble des ancres et des dépôts. Une mesure ne serait plus détachée de l'instrument qui l'a produite.

La deuxième partie porterait sur le tuple unique : AS d'origine, préfixe et longueur maximale. Elle lierait les hashes des ROA sources, leurs URI de publication et les références de chaîne de certificats. Elle indiquerait le nombre d'occurrences avant et après, et laquelle a reçu l'étiquette de doublon dans chaque exécution.

La troisième partie qualifierait le changement avec prudence. Retrait observé, nouvelle émission, échec de validation, indisponibilité de dépôt ou réattribution due au traitement ne seraient inscrits que lorsqu'une preuve les établit. Dans le cas contraire, cause non résolue serait une valeur légitime et révisable.

La quatrième partie donnerait le diff du jeu final, lié au numéro de série du cache. Une égalité de taille serait complétée par l'identité ou la non-identité des tuples. Toute affirmation sur le réseau commencerait ensuite dans une section séparée : client RTR, série reçue, route et politique observées.

Le reçu public n'a pas besoin d'exposer la topologie interne ni l'identité d'un client. Les tuples d'autorisation, les hashes, la multiplicité et les changements de statut sont des éléments bornés. Une correction ultérieure peut s'ajouter sans effacer le premier état. C'est le comportement attendu d'un registre : conserver une trace vérifiable, non s'arroger une explication qu'il ne possède pas.

Les chiffres ne sont utiles que s'ils gardent leurs frontières

Les deux captures ne montrent aucune route lésée, aucun réseau qui aurait changé de politique et aucun détenteur identifié. Elles ne prouvent pas une réparation par AFRINIC. Elles montrent deux états précis d'un validateur et une différence qui s'annule avant le jeu final.

Ce résultat n'est ni rassurant par principe ni alarmant. Il dit où chercher la prochaine preuve. Si le tuple unique n'a pas changé, la question porte sur la multiplicité et la provenance. S'il a changé, il faut examiner l'autorisation. Si un routeur a reçu un autre jeu, il faut documenter sa décision. Chaque étape possède son propre reçu.

Une institution de registre gagne en autorité lorsqu'elle limite ce qu'elle prétend savoir. Dans ce cas, la fonction la plus solide d'AFRINIC n'est pas de transformer 8 211 doublons en note de sécurité. C'est de rendre le chemin entre objet signé, validation, jeu final et observation du routeur assez durable pour qu'un tiers puisse vérifier la conclusion.

Sources