Résumé

  • Dans son projet de procès-verbal de janvier 2026, le conseil d’administration d’ARIN rapporte qu’un contrôle périodique du service Registration Services n’a relevé aucun ticket audité non conforme au NRPM et juge le fonctionnement du service efficace.
  • Le projet d’avril rend compte d’un autre audit, confié à Baker Tilly après l’incident d’attribution 4.10 de décembre 2025. Des incohérences auraient été trouvées dans chacun des domaines étudiés, mais au regard de dix critères créés récemment et qui n’étaient pas auparavant au centre de l’attention.
  • Ces formules ne sont comparables ni par leur objet ni par leur référentiel. Le document public de janvier parle de conformité de tickets à une politique ; celui d’avril de contrôles structurels appliqués après un incident. Aucun ne publie le dénominateur, l’échantillonnage ni la nomenclature complète des écarts.
  • Une grille d’audit versionnée pourrait relier chaque conclusion à la mission, au déclencheur, à la période, à la population, au critère en vigueur, à la gravité, au responsable du correctif, à l’échéance, au nouveau test et aux transactions que couvrirait un éventuel Registry Control Plane.

Le mot « audit » ne désigne pas une mesure unique

Le contraste est spectaculaire si l’on ne conserve que deux phrases.

Le 13 janvier, le conseil d’ARIN entend que les tickets audités ne présentent aucune non-conformité au Number Resource Policy Manual. Le 19 avril, il entend que des incohérences existent dans tous les domaines examinés. Une lecture rapide transformerait volontiers cette succession en contradiction, voire en aveu tardif.

Or le premier geste d’une analyse d’audit consiste précisément à remettre le résultat dans son cadre.

Le projet de procès-verbal du 13 janvier intitule le point « 2025 ARIN RSD Audit Report ». La direction explique qu’une entreprise extérieure examine tous les deux ans la documentation, les étapes des procédures et l’organisation de Registration Services. La phrase publique sur les tickets porte sur leur conformité au NRPM. Elle n’indique pas le nombre total de tickets, la taille du lot contrôlé, la méthode de sélection ni la période représentée.

Le projet du 19 avril décrit une mission déclenchée par un événement précis. Après l’erreur de décembre, ARIN sollicite un contrôle externe et engage Baker Tilly. Mike Cullen présente un projet de rapport. Le procès-verbal mentionne des incohérences dans tous les domaines étudiés, puis apporte une restriction essentielle : les dix critères venaient d’être établis et n’avaient pas jusque-là constitué un axe de travail.

Ce ne sont donc pas deux thermomètres placés au même endroit. L’un vérifie, dans les termes rendus publics, si des décisions consignées dans des tickets respectent la politique communautaire. L’autre cherche des fragilités de contrôle à partir d’un incident et d’un référentiel nouveau. Le second peut découvrir un risque réel sans invalider le premier ; le premier peut être exact sans certifier toute l’architecture qui exécute la décision.

Une adresse réattribuée révèle le plan de contrôle manquant

Le rapport d’incident publié le 12 décembre rend cette différence concrète.

Le préfixe 23.150.164.0/24, correctement attribué à un client, a été retiré puis attribué à un autre le 2 décembre 2025 pendant une opération relevant de la section 4.10. ARIN décrit un inventaire en partie manuel et hors ligne : un « e-black-book » et un tableur vivaient à côté du système principal. Le retrait a aussi supprimé les services de registre associés, dont la ROA et le DNS inverse. Un prestataire tiers a ensuite annoncé le préfixe sous l’enregistrement erroné.

Le système ne détecte pas automatiquement l’anomalie. Le premier client la signale le 9 décembre, soit environ sept jours plus tard. ARIN rétablit le préfixe, remet un /24 de remplacement à l’autre client, coordonne le retrait de route et achève les mesures correctives le même jour. Le rapport public ne formule aucune conclusion sur l’impact technique subi par les clients. Il ne permet donc pas d’affirmer qu’une panne ou une perte de trafic mesurable a eu lieu.

Surtout, le mécanisme dépasse l’idée commode d’une simple erreur humaine. Plusieurs surfaces se rejoignent : état d’inventaire séparé, règles métier insuffisamment intégrées, possibilité d’exécuter seul une action sensible et suppression en chaîne de données de registre. ARIN dit avoir achevé des protections immédiates. Les tickets comportant la suppression d’une ressource réseau sont désormais réservés à un groupe limité d’analystes expérimentés, soumis à une double vérification et revus à des heures définies.

Un ticket peut donc respecter la règle d’attribution tout en traversant un dispositif de contrôle fragile. Inversement, l’application irrégulière de nouveaux critères de séparation ou de validation ne signifie pas automatiquement que le ticket enfreint le NRPM. La conformité de la décision et la maîtrise de son exécution sont deux preuves nécessaires, pas deux formulations interchangeables.

La conclusion doit voyager avec son référentiel

ARIN peut rendre cette distinction vérifiable sans exposer d’informations client ni de détail exploitable par un attaquant. Il suffit que chaque résumé public conserve les coordonnées de la mission.

Une grille commune devrait comporter au minimum :

Élément Ce que le dossier public peut préciser
Mission Identifiant stable, commanditaire, prestataire et statut provisoire ou définitif
Périmètre Déclencheur, objectif, période, population, échantillon et méthode de sélection
Unité testée Ticket, transaction, application, rôle, état d’inventaire ou chaîne d’approbation
Référentiel Version du NRPM, section, règle de contrôle ou version des critères
Écart Domaine, définition, nombre, dénominateur et gravité bornée
Suite Recommandation, responsable, date cible, dépendance et état de mise en œuvre
Assurance Méthode et date du nouveau test, résultat et risque résiduel
Architecture Transaction et application effectivement placées sous le Registry Control Plane

La publication actuelle laisse plusieurs de ces cases vides. En janvier, les pièces W et X ainsi que des recommandations sont mentionnées, mais non détaillées sur la page. En avril, le projet de rapport et ses dix critères apparaissent, sans la liste des critères, les domaines, le nombre d’écarts ni leur gravité. Cela ne signifie pas que les administrateurs ont délibéré à l’aveugle. Cela signifie que le lecteur public ne peut pas reconstruire le dénominateur des deux conclusions.

Une telle grille éviterait également les raccourcis. Rien n’établit que l’audit périodique ait examiné tous les tickets ou démontré l’efficacité de tous les contrôles. Rien n’établit que l’audit d’incident ait relevé exactement dix défaillances, une par critère, ni que chaque incohérence soit grave. Un critère nouvellement formulé ne peut être transformé rétrospectivement en obligation ancienne. Les pages publiques ne démontrent pas non plus l’existence d’un unique rapport Baker Tilly réunissant les deux exercices.

Le Registry Control Plane déplace la question vers l’architecture

La réunion d’avril ne s’arrête pas au diagnostic. L’équipe propose une couche de contrôle située entre les applications du registre : le Registry Control Plane. Des règles arrêtées par le conseil et la direction y seraient appliquées de manière centralisée, avec l’objectif de réduire le risque d’exécution par une seule personne et d’améliorer la traçabilité.

La promesse est compréhensible. Une règle distribuée dans plusieurs applications peut être interprétée différemment, contournée lors d’une procédure manuelle ou devenir invisible quand un inventaire parallèle subsiste. Une couche commune peut donner un point d’application et une piste d’audit cohérents.

Mais le même procès-verbal conserve le caractère préliminaire du projet. Les administrateurs demandent sa fonction exacte, la première application visée, l’ordre des intégrations, l’incidence sur les autres priorités et le mode d’interfaçage. Le coût et le calendrier restent à définir. Il serait donc prématuré de le présenter comme approuvé, financé, acheté, déployé, testé ou efficace.

Son utilité d’audit dépendra de la précision du périmètre transactionnel. Pour l’incident 4.10, il faudrait pouvoir suivre séparément le retrait de l’inventaire, la désactivation de la ROA et du DNS inverse, la réattribution, le remplacement et toute dérogation exceptionnelle. Chaque étape devrait être liée à une version de règle, une identité demandeuse, une approbation indépendante et une preuve de l’état final.

Centraliser un journal sans réconcilier l’autorité de l’inventaire produirait seulement un meilleur récit d’une mauvaise opération. Bloquer la suppression tout en laissant un contournement non gouverné déplacerait le risque. Le nom de la plateforme ne constitue pas la preuve du contrôle ; la transaction couverte, son comportement en échec et son nouveau test, oui.

Des procès-verbaux provisoires imposent des verbes prudents

Les deux pages portent la mention « Draft ». Elles rendent compte de présentations et de discussions, mais ne remplacent pas les rapports ni les pièces citées. Il faut donc écrire qu’ARIN « rapporte » ou que le procès-verbal « indique », et non traiter chaque formule comme une conclusion définitive publiée avec ses travaux justificatifs.

L’index des réunions du conseil consulté le 31 août affiche pour 2026 les entrées de janvier et d’avril. Le projet d’avril prévoyait une présentation des prochaines étapes à la réunion suivante, en août. L’état de l’index ne prouve ni qu’aucune réunion n’a eu lieu ni qu’aucun travail n’a avancé. Les procédures des réunions fournissent le cadre de gouvernance, sans ajouter le compte rendu manquant.

Enfin, le NRPM est un référentiel évolutif. Inscrire sa version et la section testée dans la grille permettrait de distinguer une modification de la pratique d’une modification de la politique. « Conforme au NRPM » ne reste vérifiable dans le temps que si l’on sait quel texte et quelle décision ont été contrôlés.

Sources