Résumé

  • Le dispositif RPKI/BGP Intelligence accepté par ARIN en 2024 prévoit, dans ARIN Online, les annonces observées, leur état de validité et des avertissements avant confirmation d’un ROA. Le même texte indique que les utilisateurs de l’API devront obtenir ces informations auprès d’outils tiers.
  • L’API RPKI actuelle peut créer, modifier et supprimer des ROA dans une transaction unifiée, elle-même combinable de façon atomique avec des opérations ASPA. Ce canal est donc une voie d’écriture à fort effet, pas un simple accès de consultation.
  • La réponse proportionnée serait un précontrôle facultatif et lisible par machine, fondé sur le même modèle consultatif que l’écran. Il doit documenter ses entrées et sa fraîcheur sans devenir une autorisation, une vue universelle de BGP ou une règle de routage.

Le dernier instant réversible

Une erreur de ROA est plus facile à corriger avant qu’après la signature. Le préfixe, l’AS d’origine et la longueur maximale sont déjà saisis ; la transaction n’est pas encore confirmée. Si une annonce visible deviendrait Invalid, ou si une annonce NotFound resterait sans couverture, c’est le bon moment pour le dire. L’avertissement n’a pas à connaître toute l’intention de l’opérateur. Il doit seulement rendre l’écart visible pendant que l’action peut encore être abandonnée.

ARIN a bien identifié ce moment. Sa consultation de janvier 2024 constatait que l’utilisateur d’ARIN Online ne voyait alors que le contenu du ROA et devait passer par des services tiers pour estimer son effet sur la table de routage. Le nouveau tableau de bord proposé devait rassembler des annonces presque en temps réel, leur état RPKI, les divergences entre BGP et les ROA existants, puis suggérer une correction avant validation.

La séparation des interfaces se trouve dans ce même texte. Le service serait disponible aux clients d’ARIN Online ; les utilisateurs de l’API devraient recueillir les mêmes données ailleurs. Le résultat officiel du 11 mars a conservé ce choix. Il a confirmé l’affichage détaillé de BGP, les états de validité, l’aide sur les incohérences, la création rapide de ROA pour des annonces NotFound ou Invalid, ainsi que la publication des sources et de leur fréquence de rafraîchissement.

Il n’y a pas deux autorités. Dans les deux cas, l’organisation authentifiée doit contrôler les ressources couvertes par son certificat. Mais il y a deux enveloppes de prudence. Devant l’écran, une personne reçoit le dernier avis intégré d’ARIN. Dans un pipeline, le logiciel doit choisir ses collecteurs, évaluer l’âge des données, reproduire le calcul et conserver une preuve qui ne sera pas nécessairement comparable à celle du tableau de bord.

Cette asymétrie compte parce que l’API est puissante. Le guide REST actuel d’ARIN décrit une opération unique pour créer, modifier et supprimer plusieurs ROA. Elle peut être associée à une modification ASPA, le tout réussissant ou échouant ensemble. À ARIN 57, Reg-RWS a été présenté comme l’interface de provisionnement destinée aux transactions à grand volume. Plus un canal peut répéter fidèlement une action, plus un résultat de contrôle structuré lui est utile.

Rien dans ces sources ne prouve qu’un ROA créé par API a provoqué un incident. Rien ne permet non plus d’affirmer que l’API serait dépourvue de toute validation. Le constat est plus étroit : dans la conception publique acceptée, l’analyse de l’effet sur les routes est intégrée au Web et externalisée pour l’automatisation.

La meilleure défense d’un lancement Web

Le choix d’ARIN n’est pas absurde. La majorité des organisations utilisant le RPKI hébergé travaille probablement dans ARIN Online. Un tableau est un moyen direct d’expliquer une relation difficile : annonces actuelles, VRP, état attendu et action possible. Une nouvelle réponse d’API impose en revanche un schéma stable, des versions, un engagement de disponibilité et de l’assistance pendant des années.

Il est aussi raisonnable de penser qu’un opérateur capable d’automatiser ses ROA dispose déjà de RIPEstat, d’un validateur local, de RouteViews, d’un service commercial ou de flux BGP internes. ARIN n’a pas besoin de remplacer ces instruments. À ARIN 57, l’organisation a d’ailleurs précisé que Routing Intelligence devait rester limité aux ressources de l’organisation et ne visait pas à fournir toute la perspective que peuvent offrir les services tiers.

Enfin, l’observation n’est jamais complète. À ARIN 56, ARIN a nommé RIPE RIS et Route Views et parlé d’un instantané relativement récent. Ces infrastructures voient les annonces de collecteurs et de pairs identifiés. Elles ne voient pas chaque route privée, n’anticipent pas une migration à venir et ne connaissent ni la synchronisation de chaque cache RPKI ni la politique de chaque réseau.

Un contrôle bloquant fondé sur cet instantané donnerait donc trop de pouvoir à l’observation. ARIN sait si l’organisation est habilitée à publier pour les ressources de son certificat. Un collecteur sait seulement ce que certains pairs lui ont annoncé à un moment donné. Lors d’une urgence ou d’une migration en plusieurs étapes, le projet légitime peut volontairement différer de la photographie.

La solution n’est pas de transformer le conseil en veto. Elle consiste à donner au programme accès au même conseil limité que la personne.

Ne pas confondre prévision et publication

Le mot « validation » recouvre ici plusieurs décisions distinctes. L’autorité du registre détermine qui peut demander la signature. Le précontrôle compare une transaction proposée à des routes observées et à un ensemble de VRP. L’écriture modifie la configuration hébergée. La publication rend les objets signés disponibles dans le dépôt. Enfin, chaque relying party synchronise son cache et applique sa propre politique.

RFC 6811 définit Valid, Invalid et NotFound à partir de la relation entre une route et les VRP disponibles localement. RFC 7115 souligne que la synchronisation des caches dépend des opérateurs. Une prévision d’ARIN peut être exacte pour les entrées déclarées sans être l’état simultané de tout l’Internet.

La documentation d’ARIN montre elle aussi une chaîne, non un bouton magique. L’interface Web comporte une étape Review ROA. Le dépôt est mis à jour toutes les quelques minutes et ARIN recommande un validateur pour vérifier l’activation. Une suppression est appliquée immédiatement dans la base RPKI d’ARIN, puis apparaît dans le dépôt public dans la fenêtre annoncée. La revue, la signature, la publication et l’usage en aval ont chacune leur propre temps.

Un précontrôle d’API doit donc rester sans effet de bord : une transaction proposée entre, un diagnostic borné sort. Il ne crée pas de ROA, ne réserve pas de configuration et n’accorde aucun droit.

Le contrat minimal

Le premier champ devrait être l’empreinte de la transaction proposée. Une opération atomique peut retirer un ROA, en ajouter deux et modifier un ASPA. Sans lien avec ces octets précis, l’avertissement ne prouve pas ce qui a réellement été examiné.

Le deuxième champ est un repère sur l’état du certificat de ressources utilisé par le calcul : version ou empreinte, sans donnée privée. Il fixe l’étendue sur laquelle ARIN pouvait agir à cet instant.

Viennent ensuite les observations : noms des sources, heure de chaque instantané et mesure de fraîcheur. Pour chaque annonce repérée, la réponse peut fournir préfixe, origine, état actuel, état prévu et code d’avertissement stable. Le texte explicatif reste nécessaire à l’écran ; le code stable évite qu’un changement de formulation casse l’automatisation.

Le résultat doit aussi expirer. Une photographie vieille de dix minutes n’est pas une approbation permanente. Si une source manque, la réponse doit dire stale ou unavailable. Le silence ne vaut ni permission ni interdiction.

Enfin, un identifiant facultatif peut relier le diagnostic à l’écriture ultérieure. Il atteste seulement qu’une prévision précise accompagnait une transaction précise. Il ne doit jamais devenir une preuve de sûreté ni une condition de publication.

Un précédent après l’action

ARIN sait déjà conserver l’origine du canal. Son ROA Change Log distingue Web User, API User et ARIN System, avec l’heure, l’opération Added ou Removed, l’AS d’origine, le préfixe, maxLength et l’auteur. C’est une bonne trace après la modification : qui a changé quoi, quand et par où.

Elle ne dit pas ce que l’opérateur savait avant de cliquer ou d’envoyer. Ce n’est pas un défaut à corriger dans le journal. Le journal établit la filiation de l’écriture ; le précontrôle conserve les éléments disponibles quand le choix était encore réversible. Relier leurs empreintes permettrait de reconstituer la séquence sans présenter une prévision comme un verdict.

La parité a aussi un précédent explicite. En 2023, ARIN a annoncé un nouvel endpoint REST destiné à offrir la parité avec les améliorations de l’interface de création des ROA, notamment l’auto-renouvellement. Ce texte ne promet rien pour Routing Intelligence. Il montre cependant que l’équivalence entre Web et API peut être formulée comme une propriété du produit.

Une chronologie à lire sans extrapoler

En octobre 2025, ARIN disait avoir commencé le développement le 30 septembre. En avril 2026, Routing Intelligence était encore présenté comme proche, mais à venir ; le compte rendu officiel le classait parmi les travaux en cours. Le registre des fonctionnalités livrées jusqu’au 28 juillet 2026 ne l’annonce pas.

Cette absence ne prouve pas qu’aucune version limitée, étape interne ou décision plus récente n’existe. Elle permet seulement de qualifier la fonction de planifiée dans le corpus public disponible. ARIN 57 a aussi évoqué de futures capacités d’API en général, sans les rattacher explicitement à Routing Intelligence. Il serait donc aussi imprudent d’annoncer la parité que d’affirmer son abandon définitif.

Une suggestion communautaire encore ouverte demande par ailleurs une analyse Web et un export CSV des préfixes et ASN candidats avant engagement. ARIN a répondu qu’une fonction similaire figurait dans son pipeline et que le rapport téléchargeable serait étudié. L’export rendrait l’information plus transportable pour une personne. Il ne remplace pas un précontrôle reproductible portant sur la transaction exacte d’un client logiciel.

Une alerte qui reste à sa place

Le bon résultat n’est ni vert ni rouge sans contexte. Il nomme ses points d’observation, indique leur âge et distingue « non vu ici » de « absent d’Internet ». Il sépare l’état prévu de la publication effective, puis la publication de la décision prise par les réseaux en aval.

La personne peut lire un tableau. Le programme peut interpréter les mêmes faits, les comparer à l’intention locale et aux flux internes, puis demander une revue en cas d’écart. ARIN reste l’émetteur. Le détenteur des ressources garde la décision. Les collecteurs restent des témoins. Les réseaux gardent leur politique.

Une API qui peut écrire n’a pas besoin d’un nouveau gardien. Elle a besoin de pouvoir lire, sous une forme vérifiable, l’avertissement qu’ARIN prévoit déjà de montrer avant la même écriture.

Sources