Résumé

  • L'IRR Auto-Manager peut créer ou relier un objet de route IRR pendant la création d'un ROA, tout en laissant ensuite les deux enregistrements suivre des cycles de vie distincts.
  • La suggestion ACSP 2026.9 demande un journal IRR comparable à l'historique ROA. C'est nécessaire, mais deux listes séparées ne prouvent pas quelles lignes relèvent d'une même intention.
  • Un reçu d'opération inter-registres peut réunir état initial, choix, correspondance, résultat et correction sans assimiler une autorisation ROA à une déclaration RPSL.

ARIN a retiré une friction bien connue du travail de sécurité du routage. Au lieu de saisir séparément une Route Origin Authorization et un objet de route dans l'Internet Routing Registry, un titulaire peut laisser l'IRR Auto-Manager produire l'objet correspondant et le relier au ROA. La fonction a été achevée avec les versions logicielles annoncées entre novembre 2024 et janvier 2025, puis présentée en détail en février 2025.

Il faut commencer par reconnaître ce que ce choix améliore. La double saisie est une source banale de divergence. Un outil qui part de la paire préfixe-AS d'origine déjà autorisée réduit le travail répétitif. Il n'impose pas pour autant le résultat. Le réglage peut être désactivé au niveau d'un Org ID et l'utilisateur peut refuser la création de l'objet IRR lors d'une opération particulière. Si un objet non géré correspondant existe déjà, il peut être remplacé par un objet géré automatiquement ou conservé tel quel. L'outil Sync Up permet aussi de traiter des ROA plus anciens.

Le dispositif respecte surtout une frontière que l'automatisation aurait facilement pu gommer. Un objet IRR peut être supprimé sans toucher au ROA. Lorsqu'un ROA est supprimé, l'utilisateur choisit de supprimer aussi les objets liés ou de les laisser subsister comme objets non gérés. Un ROA contenant plusieurs préfixes peut engendrer un objet IRR par préfixe. La liaison facilite une opération ; elle ne crée pas une dépendance juridique ou technique indissoluble entre deux données différentes.

Leur différence de contenu est tout aussi importante. Un ROA est une autorisation d'origine signée. Il peut contenir maxLength, qui borne la longueur des annonces plus spécifiques autorisées. Un objet de route IRR est une déclaration RPSL structurée autour d'un préfixe et d'un AS d'origine. L'Auto-Manager ne transforme pas maxLength en une série d'objets plus spécifiques : il utilise l'entrée de préfixe. Ce choix évite de présenter comme identiques deux instruments qui ne le sont pas.

ARIN a donc construit une automatisation étroite, utile et réversible. Le problème n'est pas que ce service accomplisse trop peu. Il est que la preuve visible ne suit pas encore toute l'opération qu'il rend possible.

Ce que le journal ROA permet déjà d'établir

La documentation d'ARIN décrit un Origin AS/Prefix Pair Change Log couvrant les ROA nouveaux et modifiés d'une organisation au cours des 365 derniers jours. Au-delà de cent éléments, les résultats sont paginés. Chaque ligne associe un horodatage, une opération Added ou Removed, une source — Web User, API User ou ARIN System —, l'AS d'origine, le préfixe, la longueur maximale et le champ Changed By. Une organisation peut demander un fichier CSV complet par ticket ; ARIN annonce un examen et une réponse sous deux jours ouvrables, puis une disponibilité du fichier pendant 90 jours.

Ce journal ne se contente pas d'afficher l'état courant. Il garde la trace d'une modification sous forme d'éléments retirés et ajoutés. Il distingue l'action d'un utilisateur web, celle d'un appel d'API et celle du système ARIN. Pour un incident de compréhension — pas nécessairement un incident de routage — ces distinctions évitent déjà de nombreux faux rapprochements.

La documentation publique actuelle ne décrit pas l'équivalent pour les objets IRR. Le 11 mai 2026, Randal Kohutek a formulé exactement cette demande dans ACSP 2026.9. Son texte reste prudent : le système IRR « ne semble pas » présenter une telle journalisation. Cette formulation ne prétend pas connaître les journaux de sécurité, l'historique de base de données ou les outils internes d'ARIN.

La réponse est arrivée le 19 mai. ARIN a reconnu l'intérêt de la fonction pour les clients qui doivent suivre les actions touchant les objets IRR. L'organisation a ajouté la suggestion à sa feuille de route de sécurité du routage, l'a transmise au processus interne de priorisation et de planification de la mise en œuvre, puis a clos la suggestion. Huit jours pour reconnaître le besoin et l'orienter constituent une réponse sérieuse. Ce n'est ni une date de livraison, ni un schéma promis, ni la preuve que la fonction est déjà disponible.

Deux journaux comparables ne forment pas encore une opération

Imaginons que la feuille de route aboutisse à un tableau IRR doté des mêmes colonnes essentielles. Le titulaire disposerait alors de deux chronologies. Il lui manquerait encore le lien causal le plus utile : quelles lignes appartiennent au même choix ?

À la création d'un ROA, un objet IRR correspondant peut déjà exister sans être géré par l'Auto-Manager. L'utilisateur peut le remplacer ou le laisser intact. Plusieurs préfixes créent plusieurs objets. Plus tard, la suppression indépendante d'un objet IRR laisse le ROA en place. À l'inverse, la suppression du ROA offre le choix entre effacer les objets associés ou les conserver en les faisant passer à l'état non géré. Sync Up peut créer un objet absent ou relier un objet présent.

La proximité des horaires ne suffit pas à réunir ces faits. Deux lignes à la même seconde peuvent provenir d'un traitement partiel ou de deux actions. Deux lignes éloignées peuvent appartenir à une décision parfaitement volontaire. Un état final divergent n'est pas, à lui seul, une erreur.

Or les deux systèmes alimentent des pratiques distinctes. Les ROA sont des entrées signées pour la validation de l'origine. Les objets IRR peuvent servir à construire ou vérifier des filtres de politique de routage. Ni l'un ni l'autre ne prouve ce qu'un routeur a effectivement annoncé, reçu ou retenu. Pourtant, lorsqu'ils divergent, l'ingénieur doit savoir s'il regarde un refus explicite, un objet antérieur conservé, une suppression indépendante, une correspondance un-à-plusieurs, un échec partiel ou une correction.

Le bon objet de preuve n'est donc pas un journal public exhaustif de l'activité de tous les membres. C'est un reçu borné, consultable par l'organisation autorisée et défini par un schéma public.

Un reçu attaché au geste

Le reçu commencerait par un identifiant d'opération opaque et un horodatage. Il indiquerait la surface d'origine — ARIN Online, API RPKI, API IRR, Sync Up ou ARIN System — ainsi qu'une classe d'acteur, sans publier inutilement un nom personnel. Il nommerait l'organisation autorisée et l'intention : créer ou modifier le ROA, le supprimer, créer ou relier un objet IRR, remplacer un objet non géré, supprimer l'objet IRR, le conserver comme non géré ou resynchroniser l'ensemble.

Puis viendraient les états avant et après. Pour le ROA : identifiant, AS d'origine, préfixe et maxLength. Pour l'IRR : clé route ou route6, préfixe, origine, statut géré ou non géré et état de la liaison. Si un ROA comporte plusieurs préfixes, le reçu montrerait la cardinalité de la correspondance. Si un objet existait, il préciserait s'il a été réutilisé, remplacé ou laissé intact.

La décision de suppression mérite un champ propre. « Supprimer le ROA et les objets liés » n'est pas la même opération que « supprimer le ROA et conserver les objets comme non gérés ». L'absence d'un objet ne devrait pas être la seule preuve du choix. Un échec ou un résultat partiel recevrait une classe de résultat. Une correction pointerait vers le reçu remplacé, au lieu de réécrire silencieusement l'explication antérieure.

Ce schéma n'exige pas de rendre le monde entier témoin de tout. Les clés d'API, les identités personnelles et l'historique d'une autre organisation ne sont pas des données de transparence. ARIN peut conserver davantage de détails dans ses journaux de sécurité, remettre un reçu structuré au titulaire autorisé et publier seulement le schéma, les règles de conservation et les possibilités d'export.

La bonne intuition institutionnelle existe déjà dans l'Auto-Manager : coordonner sans confondre, aider sans commander et laisser une sortie. ACSP 2026.9 identifie la lacune suivante. La meilleure mise en œuvre n'ajouterait pas seulement des colonnes égales. Elle donnerait une preuve commune du passage entre les deux états, afin que l'opérateur sache quand deux changements forment une seule opération — et quand ce n'est pas le cas.

Sources