Résumé

  • Le guide actuel d’ARIN prévoit un nom facultatif pour chaque ROA, alors que la recherche dans ARIN Online n’est documentée que par préfixe ou par ASN.
  • La suggestion ACSP 2024.14 a demandé une recherche par nom. ARIN l’a jugée utile en août 2024 et l’élément demeure affiché comme « Open ».
  • L’API RPKI transporte déjà le nom à la création et dans la liste d’une organisation ; un opérateur autorisé peut donc télécharger cette liste et la filtrer localement.
  • Le nom doit rester un index privé et mutable. Toute action devrait être confirmée sur un identifiant stable du ROA et sur ses coordonnées réseau.

Un champ conçu pour la mémoire, sans chemin de retour documenté

Un préfixe et un numéro de système autonome disent ce qu’une autorisation porte. Un nom explique souvent pourquoi l’équipe l’a créée. Il peut désigner un client, une migration, un projet de modernisation ou un ensemble de ressources que l’adressage ne regroupe pas naturellement.

Le guide d’ARIN consacré aux Route Origin Authorizations énumère précisément ces éléments : l’Origin AS, le préfixe accompagné de sa longueur maximale, puis un nom facultatif. Mais la rubrique consacrée à la recherche dans ARIN Online ne propose publiquement que deux clés, le préfixe et l’ASN. Le champ s’inscrit donc dans la fiche sans achever son parcours dans l’outil de découverte.

La suggestion ACSP 2024.14 a donné à ce décalage une formulation nette. Déposée le 23 août 2024, elle demande que les ROA rattachés à une organisation puissent être recherchés par leur nom, et pas seulement par leurs coordonnées réseau. Son auteur présente un usage concret : retrouver ensemble les autorisations associées à un client ou à un projet.

La réponse d’ARIN, datée du 28 août, reconnaît l’intérêt de cette extension. L’organisation l’a placée parmi les améliorations RPKI en attente de priorisation et a indiqué que la suggestion resterait ouverte jusqu’au développement et au déploiement de la fonction. La page particulière et l’index ACSP capturés pour cet article affichent toujours le statut « Open ».

Il faut s’arrêter à ce que ces pages démontrent. Elles ne permettent pas d’affirmer qu’aucun compte authentifié ne bénéficie d’une fonction récente ou non documentée. Aucun compte ARIN Online n’a été utilisé pour cette enquête. Le statut ouvert n’est pas davantage une échéance manquée : ARIN n’a annoncé aucun calendrier. Le constat vérifiable est plus étroit : la documentation accepte le nom comme donnée, sans l’inscrire parmi les clés de recherche en ligne décrites au public.

L’API offre un détour crédible

La meilleure défense d’ARIN se trouve dans sa propre documentation RPKI REST. L’exemple de création contient un élément name. La charge utile décrivant un ROA renvoie elle aussi ce nom. Enfin, l’opération de liste porte sur les ROA d’un identifiant d’organisation. Une équipe autorisée peut donc récupérer l’ensemble, puis filtrer les noms dans son outil interne.

Cette solution peut suffire. Le préfixe et l’ASN sont les coordonnées de l’autorisation, et non une convention de classement. Ils forcent l’opérateur à revenir au contenu qui compte réellement. Une équipe déjà outillée autour de l’API n’a probablement pas besoin d’un nouveau bouton. Elle peut aussi définir elle-même les règles de casse, de caractères accentués et de recherche partielle.

La prudence a une autre justification : le nom peut être sensible. Un libellé contenant un client, un programme interne ou une zone commerciale n’a pas vocation à devenir un index public. Les homonymes, les renommages et les variantes Unicode rendent en outre une recherche approximative risquée. Le fait que la recherche par préfixe ou ASN évite ce niveau sémantique ne constitue pas, en soi, un défaut.

Reste que le détour n’est pas un contrat commun. L’opération documentée fournit la liste de l’organisation ; elle ne décrit pas de paramètre serveur filtrant le nom. Chaque opérateur qui souhaite cette fonction doit donc la recréer dans un script, un tableur ou une mémoire de procédure. Le service sait enregistrer le libellé, mais l’usage de ce libellé comme index dépend d’un environnement extérieur.

L’impact doit être décrit sans dramatisation. Aucune source examinée ne rapporte une suppression erronée, une route invalide, un détournement ou une panne. Le risque se situe avant l’action, au moment de sélectionner l’objet. Si un même projet recouvre plusieurs préfixes ou ASN, le nom sert justement à exprimer ce regroupement local. Sans recherche correspondante, l’équipe doit se souvenir des coordonnées, parcourir l’inventaire ou maintenir une deuxième table. Elle peut oublier un objet apparenté ou en choisir un autre. C’est une friction de gestion, pas une faille dans la cryptographie de RPKI.

Le nom de gestion ne signe aucune autorité de routage

La chaîne comporte au moins six états qu’un bon écran ne devrait jamais confondre : la fiche gérée chez ARIN, l’objet signé, sa publication dans un dépôt, la vue qu’en a un validateur, l’annonce BGP observée et la décision finale d’un réseau d’accepter ou non la route.

Le profil défini par le RFC 6482 contient une version, un identifiant d’AS et des blocs d’adresses IP. Il ne prévoit pas de nom descriptif. ARIN rappelle par ailleurs que la vérification de l’état actif passe par un validateur RPKI et par son dépôt. Retrouver une fiche intitulée « migration-client-rouge » ne prouve donc ni sa publication, ni sa visibilité par les validateurs, ni l’existence d’une annonce correspondante, ni son traitement par un réseau.

Cette séparation autorise précisément une amélioration de l’ergonomie sans modifier l’autorité. Le nom peut rester privé, local à l’organisation et modifiable. L’identifiant technique de la fiche peut rester durable. Le préfixe et l’ASN demeurent les informations qui doivent être relues avant toute opération.

Chercher par nom exige un identifiant stable

Une fonction bien bornée commencerait dans le périmètre de l’organisation authentifiée. Elle préciserait le mode de correspondance — exacte, par début de chaîne ou par sous-chaîne — ainsi que la casse, la normalisation Unicode, les noms vides et les doublons. Elle dirait aussi si un ancien nom reste consultable dans l’historique après renommage.

Chaque résultat devrait afficher un identifiant stable du ROA avec le nom, l’Origin AS, le préfixe, la longueur maximale et l’état. Toute modification ou suppression devrait être confirmée sur cet identifiant et sur les coordonnées réseau. Le nom aide à repérer ; il ne doit jamais être la seule preuve que l’objet choisi est le bon.

La pagination mérite la même rigueur. Si la deuxième page est calculée après un changement d’inventaire, un objet peut apparaître deux fois ou disparaître. Une photographie cohérente et un curseur explicite évitent ce glissement. Un reçu minimal pourrait conserver le périmètre d’organisation, l’empreinte de la requête normalisée plutôt que son texte sensible, le mode de correspondance, l’heure de la photographie, le nombre de résultats, les identifiants stables renvoyés et le curseur suivant.

Ce reçu resterait privé. Il ne publierait aucun nom de client. Il permettrait simplement à ARIN et à l’opérateur de reproduire ce qui a été présenté avant une modification importante. La suggestion 2024.14 ne demande donc pas de redéfinir la sécurité du routage. Elle demande si un champ de gestion dispose d’un cycle de vie complet, depuis sa saisie jusqu’à sa récupération sûre.

Sources