ARIN finance un tableau RPKI autour d’un chiffre de 99 %. La méthode doit suivre

Résumé

• ARIN a accordé 17 350 dollars à Virginia Tech pour un tableau de santé opérationnelle de la RPKI, à partir d’un entrepôt annoncé de 3,9 milliards d’observations sur quatorze ans.
• Le résumé fourni par le bénéficiaire situe la « conformité de révocation » entre 9 % chez AFRINIC et plus de 99 % chez ARIN depuis 2023. Il présente aussi un passage de 14 à 80 jours pour la cadence de re-signature d’ARIN.
• La page publique ne donne ni le numérateur, ni le dénominateur, ni la fenêtre d’observation de cette conformité. L’API bêta définit certaines mesures voisines, mais pas la recette de ces deux valeurs emblématiques.
• Chaque comparaison devrait donc porter un reçu de mesure versionné : population, unité, règles d’inclusion, état de validation, couverture des données, code, correction et résultat exact.

Le volume n’est pas encore une preuve comparative

L’annonce d’ARIN du 22 septembre est brève : un projet de Virginia Tech, 17 350 dollars, un tableau de santé opérationnelle de la RPKI. La page détaillée des bénéficiaires ajoute l’ambition technique. Elle précise aussi que les résumés sont fournis par les bénéficiaires, une provenance qu’il faut conserver lorsque les résultats sont cités.

Virginia Tech décrit quatorze années de données couvrant les cinq RIR : environ 3,9 milliards d’observations d’objets, stockées dans 139 Go de fichiers Parquet. Cette échelle rend possibles des questions historiques difficiles à poser avec une seule photographie. Elle ne décide pourtant pas, à elle seule, de ce qu’est une observation indépendante. Le même objet vu chaque jour produit de nombreuses lignes ; une autorité de certification peut produire beaucoup plus d’objets qu’une autre.

Le résumé passe ensuite de la taille à l’évaluation. Les fenêtres de validité des CRL varieraient d’un facteur sept, les cadences de re-signature d’un facteur seize, et la conformité de révocation irait de 9 % chez AFRINIC à plus de 99 % chez ARIN depuis 2023. Pour ARIN, le texte relie l’année 2023 à trois évolutions : cadence de 14 à 80 jours, durée des certificats de dix ans à 825 jours, conformité inférieure à 5 % devenue supérieure à 99 %.

Ces affirmations peuvent être solides. Le texte indique que l’analyse est en cours d’évaluation pour IMC 2026. Il ne dit pas qu’elle a été acceptée. Le financement ne remplace pas cette évaluation et ARIN ne présente pas la méthode comme une mesure qu’elle aurait reproduite elle-même.

Un même nom peut cacher deux horloges

Le RPKI Warehouse actuellement lié se présente comme un observatoire longitudinal en bêta. Il annonce des clichés quotidiens, des recherches de ROA et des vues sur les cycles de vie et la couverture. Il avertit que les données et les fonctions peuvent changer. Ce site existant n’est donc pas nécessairement la livraison finale promise par la subvention.

Son schéma OpenAPI est néanmoins instructif. Il définit la cadence de signature comme l’intervalle entre deux champs this_update consécutifs de CRL pour une CA identifiée par son AKI. Lors d’une consultation le 25 septembre, la réponse globale pour ARIN donnait une médiane de 24 heures.

Vingt-quatre heures ne réfutent pas quatre-vingts jours. Les deux chiffres peuvent viser des objets, des périodes et des agrégations différents. L’un peut suivre l’émission courante de CRL ; l’autre, le renouvellement d’un autre produit ou une série historique de CA choisies. C’est précisément le problème : l’étiquette « cadence de re-signature » ne suffit pas à identifier le calcul.

La définition publique de la stagnation des CRL est plus étroite : seulement les CRL actuellement vivantes, avec un retard égal à l’heure courante moins next_update. Cette mesure est compréhensible et exploitable. Elle ne définit pas la « conformité de révocation ». Dans la surface inspectée, aucun point d’API ne permettait de reconstruire directement les 9 % et 99 %.

Les RFC définissent des objets, pas ce classement

RFC 6487 décrit les certificats de ressources et les CRL de la RPKI. Une CA publie une CRL couvrant les certificats qu’elle a émis ; la validation vérifie notamment si un certificat révoqué figure dans la CRL courante. Le texte impose des structures et des contrôles. Il ne crée pas une statistique comparative unique entre registres.

RFC 9286 place la CRL dans un autre mécanisme : le manifeste du point de publication. Celui-ci énumère les objets, contient thisUpdate et nextUpdate, et permet de détecter des suppressions ou des versions périmées. Un relying party peut garder un cache après un échec de collecte. Deux observateurs, à des instants différents, ne voient donc pas forcément le même ensemble validable.

Une ligne de l’entrepôt peut ainsi correspondre à un objet présent mais non retenu par un relying party, à une CRL encore dans sa fenêtre ou déjà périmée, à une collecte réussie ou à un cache prolongé. Si le tableau compte les présences dans le dépôt, il répond à une question. S’il compte les objets valides selon un logiciel et une heure donnés, il en répond à une autre.

L’unité change aussi le poids des acteurs. Une moyenne par observation avantage les CA qui produisent le plus de lignes. Une moyenne par CA donne le même poids à une petite autorité déléguée et à une infrastructure hébergée très active. Une moyenne par événement de révocation demande encore une population différente. Le RIR auquel attribuer une CA hébergée ou déléguée doit lui aussi être explicite.

Le dénominateur distribue la responsabilité

La conformité pourrait signifier qu’un certificat remplacé apparaît rapidement sur la CRL suivante. Elle pourrait mesurer la présence de tous les certificats révoqués et non expirés sur la CRL courante. Elle pourrait encore vérifier qu’une nouvelle CRL est émise dans un délai après un événement. Ces trois tests ont chacun une logique ; un seul nom ne permet pas de choisir.

Le sort des données manquantes peut transformer le résultat. Une absence de cliché est-elle un échec, une observation non disponible ou une raison de reprendre le dernier état validé ? Une panne du collecteur est-elle attribuée au RIR ? Les certificats expirés sortent-ils du dénominateur le jour de leur expiration ? Une correction historique recalcule-t-elle toute la série ?

Ces décisions influencent plus que la forme d’un graphique. Un écart de 9 % à 99 % suggère une différence institutionnelle immense. Il peut orienter l’attention des opérateurs, la réputation d’un registre, un programme d’audit ou un prochain financement. Le tableau doit donc montrer ce qui relève du comportement observé et ce qui relève du dispositif de mesure.

La subvention offre justement l’occasion de produire ce bien public. Un tableau hebdomadaire peut révéler une amélioration avant qu’un rapport annuel ne paraisse. Mais la continuité visuelle ne doit pas masquer un changement de code, de source ou de population. Une série dont la méthode change silencieusement n’est pas vraiment longitudinale.

Un reçu attaché au score

Chaque indicateur pourrait recevoir un identifiant stable et une version sémantique. Le reçu préciserait la question en langage courant, l’objet ou l’événement, la version de profil RFC, le collecteur, le cliché et la période. Il publierait ensuite le numérateur, le dénominateur, l’unité, les exclusions, la déduplication et la règle d’attribution au RIR.

Il distinguerait CA hébergées et déléguées, objet présent et objet validé, mesure courante et recalcul historique. Il expliquerait le traitement des échecs de collecte, caches, données absentes, certificats expirés et doublons. Une version du code et des données, une requête reproductible, un journal de correction et l’empreinte du résultat achèveraient la chaîne.

L’interface peut rester simple : « plus de 99 %, métrique RC-2.1, population N, période du … au … ». Le détail serait accessible en un clic. En cas de trou de collecte, un taux de couverture vaut mieux qu’une réussite ou un échec inventé.

Le but n’est pas de ralentir un produit en bêta. Il est de préserver la valeur particulière de quatorze années de données : pouvoir dire si une rupture vient d’une opération, d’un logiciel, d’un corpus ou d’une définition. Le chiffre peut alors devenir une preuve publique, pas seulement une couleur sur un tableau.

Sources

1. ARIN — annonce des bénéficiaires 2026
2. ARIN — page détaillée des bénéficiaires
3. RPKI Warehouse bêta
4. Schéma OpenAPI de RPKI Warehouse
5. Cadence de signature ARIN
6. Stagnation des CRL ARIN
7. État des données de RPKI Warehouse
8. RFC 6487 — profil des certificats de ressources
9. RFC 9286 — manifestes RPKI