Résumé

  • La version du 28 juillet 2026 a ajouté l’authentification Reg-RWS par en-tête Authorization. Le lendemain, ARIN a clos la suggestion ACSP 2022.5 tout en précisant que les jetons transmis dans les paramètres d’URL resteraient acceptés.
  • Les sources publiques examinées confirment la nouvelle option et la recommandation de basculer, mais ne donnent ni date de retrait, ni jalon de migration, ni nombre d’appels utilisant encore l’URL. La clôture atteste donc la livraison d’une fonctionnalité, pas la disparition de l’ancien transport ni la migration des clients.

Une requête, deux calendriers

Un appel à un registre doit identifier la ressource demandée et établir que le client a le droit d’y accéder. Reg-RWS permet d’automatiser des opérations liées notamment à RPKI et à IRR, aux réassignations et réallocations, ainsi qu’aux mises à jour de blocs réseau. Pendant des années, la requête documentée pouvait transporter un jeton API dans la chaîne de requête de l’URL. En juillet 2026, ARIN a ajouté une autre voie : l’URL désigne la ressource, tandis que la clé est transmise séparément dans un en-tête Authorization.

Le résultat fonctionnel peut être le même ; la surface d’exposition ne l’est pas. Une URL est souvent conservée dans l’historique du navigateur, les journaux de requêtes, les traces d’un proxy ou les diagnostics. Dans son explication d’août, ARIN cite précisément l’historique du navigateur et les journaux de serveurs et de proxys comme endroits où peut subsister une clé portée par l’URL. Le déplacement vers un en-tête réduit le risque de diffusion accidentelle.

Il ne rend pas le secret invisible : une application, un proxy, un outil de traçage ou un dossier de support peut encore enregistrer la valeur de l’en-tête si les règles de journalisation sont mal conçues. Le gain pratique est une exposition par défaut plus étroite, pas la fin de la gestion des identifiants.

La chronologie rend la différence nette. La suggestion ACSP 2022.5 a été déposée le 11 février 2022. Elle demandait une autre méthode que le jeton dans l’URL des appels REST et signalait que les systèmes qui journalisent les URL complètes peuvent révéler un jeton valide à toute personne ayant accès à ces journaux, avec un risque d’accès non autorisé. Le délai souhaité était « non spécifié ». Le 23 février, ARIN a estimé qu’un en-tête HTTP était la meilleure solution, a inscrit le travail parmi les éléments à prioriser pour la feuille de route d’ingénierie 2023 et a indiqué que la suggestion resterait ouverte jusqu’à sa mise en œuvre.

Le 28 juillet 2026, ARIN a annoncé que les appels REST pouvaient employer un en-tête Authorization avec le schéma ApiKey. Le 29 juillet, sa réponse de clôture a indiqué que l’alternative privilégiée avait été déployée et que les jetons resteraient acceptés comme paramètres d’URL. La demande était considérée comme achevée parce que l’alternative demandée existait ; la clôture ne disait pas que l’ancien accès avait pris fin. L’explication technique du 11 août et l’édition de septembre d’ARIN Bits ont confirmé que l’URL restait acceptable pour l’instant, qu’elle serait retirée à terme et qu’il était recommandé de changer dès maintenant.

Deux calendriers se superposent. Le premier est celui de la livraison : une suggestion est enregistrée, évaluée, mise en œuvre puis close. Le second est celui de la migration : les clients découvrent le changement, adaptent leurs outils, testent la nouvelle forme de requête, retirent le secret de l’URL et cessent finalement d’utiliser l’ancien chemin. Le premier a une borne clairement datée dans les documents publics. Le second n’a ni échéance publique ni mesure publiée.

Il ne s’agit pas de reprocher à ARIN d’avoir fermé la suggestion. Une demande d’alternative peut être satisfaite dès que cette alternative fonctionne, même si les clients ont besoin de temps pour l’adopter. La question de gouvernance commence après la clôture. Tant que l’ancienne méthode reste prise en charge, il ne s’agit plus seulement d’une modification logicielle : c’est un contrat d’exploitation entre ARIN et les organisations dont les scripts, plateformes d’automatisation et prestataires appellent le registre.

Pourquoi l’emplacement du jeton compte

Une clé API n’est pas une donnée ordinaire de la requête. ARIN la décrit comme un secret servant à identifier l’appelant et précise que certaines opérations REST nécessitent un compte associé à un Point of Contact ayant l’autorité pertinente. Si le jeton figure dans la chaîne de requête, il voyage avec l’adresse de la ressource. Les systèmes qui stockent ou recopient les URL peuvent donc le conserver au-delà du processus qui a lancé l’appel. Les historiques du navigateur et les journaux de serveurs ou de proxys mentionnés par ARIN illustrent ce mécanisme de rétention accidentelle.

La méthode par en-tête change l’endroit où le client place l’identifiant, pas la ressource visée. La forme documentée par ARIN utilise le champ Authorization et le schéma ApiKey. Le client, l’outil d’automatisation ou le service de provisionnement doit envoyer ce champ correctement tout en conservant le point de terminaison et le sens de la requête. L’URL n’a alors plus besoin d’inclure le secret comme paramètre supplémentaire.

Il existe un parallèle utile avec une limite à rappeler. Le RFC 6750 de l’IETF porte sur les jetons OAuth de type bearer, et non sur le schéma ApiKey d’ARIN. Il recommande l’en-tête Authorization et déconseille de placer ces jetons dans les paramètres URI, notamment parce que les URL ont de fortes chances d’être journalisées. Ce RFC ne signifie pas que Reg-RWS utilise OAuth ou qu’il relève de cette spécification. Il montre que la différence d’exposition est une propriété connue des opérations HTTP : une valeur sensible dans un URI rejoint plus facilement des journaux généralistes qu’un identifiant placé dans un champ dédié de la requête.

Un en-tête n’est pas une politique de sécurité complète. Un administrateur peut journaliser tous les en-têtes ; un outil de traçage peut les capturer ; un vidage de débogage peut les conserver ; un client peut réintroduire le secret dans l’URL avant de suivre une redirection. L’adoption des en-têtes doit donc aller de pair avec l’exclusion des valeurs Authorization des journaux, le stockage protégé des clés, la validation des certificats et une procédure de remplacement en cas d’exposition. Ce sont des contrôles côté opérateur, pas de nouvelles fonctionnalités d’ARIN affirmées ici.

La charge de migration n’est pas la même pour tous. Une équipe disposant d’un seul client maintenu peut modifier un champ de configuration et tester quelques appels. Un opérateur réseau utilisant de vieux scripts, des logiciels fournisseurs, des tâches planifiées, des services externalisés et des outils RPKI ou IRR distincts doit retrouver chaque endroit où la chaîne de requête est construite. Ce travail échappe au registre, sauf si ARIN le mesure. Il explique aussi pourquoi une compatibilité maintenue ne prouve pas qu’un client a choisi l’option moins sûre après en avoir été informé.

Ce que les sources publiques établissent

Les éléments disponibles étayent quatre constats distincts :

  1. L’authentification par en-tête est disponible pour Reg-RWS. La version de juillet et la documentation actuelle des méthodes REST la décrivent.
  2. ARIN préfère cette méthode et recommande de migrer. L’explication technique d’août et la synthèse de septembre le disent.
  3. Les appels avec jeton dans l’URL restent acceptés selon les documents publics consultés. La réponse de clôture du 29 juillet l’indique explicitement ; la page actuelle des méthodes REST le répète.
  4. Les sources examinées ne publient ni date de retrait, ni jalons successifs, ni volume d’appels encore fondés sur l’URL, ni taux d’adoption des en-têtes.

Le quatrième point est volontairement circonscrit. Il signifie que ces mesures ne figurent pas dans les sources publiques citées ; il ne démontre pas qu’ARIN ne dispose d’aucune donnée interne, d’aucun projet privé ou d’aucun échange avec ses clients. Les sources ne décrivent pas non plus de compromission. La suggestion de 2022 expose un mécanisme plausible ; les documents de 2026 expliquent pourquoi ARIN préfère l’alternative. Aucun ne rapporte la divulgation effective d’un jeton ou une action non autorisée dans le registre.

Cette distinction évite deux erreurs opposées. La première consisterait à interpréter les quatre années comme une preuve d’échec. La suggestion ne fixait aucun délai et les sources montrent qu’une alternative a été déployée. La seconde serait de prendre la clôture pour la preuve que le risque a disparu. La réponse maintient explicitement la compatibilité avec l’URL ; la recommandation de septembre évoque un retrait futur, sans date. Une option plus sûre peut exister alors qu’un ancien chemin d’exposition reste actif.

La compatibilité est un engagement de service

Maintenir l’ancienne méthode pendant une période transitoire est souvent le choix responsable. Une coupure immédiate pourrait interrompre un processus automatisé essentiel à l’administration des ressources. L’échec d’une tâche pourrait retarder la gestion de données de registre, les opérations RPKI ou IRR, des réassignations ou d’autres opérations construites autour de Reg-RWS. Les sources publiques établissent ces usages généraux mais ne chiffrent pas les conséquences d’une interruption particulière. L’API du registre fait partie de l’infrastructure opérationnelle des clients ; ce n’est pas un simple point d’accès de démonstration.

La compatibilité a aussi un coût. Chaque format de requête pris en charge devient un état que la documentation, l’assistance, les mainteneurs de clients et les équipes utilisatrices doivent comprendre. Si une méthode est recommandée tandis qu’une autre reste fonctionnelle sans échéance, « préférée » peut finir par désigner une consigne sans date de décision. De nouvelles intégrations peuvent reprendre d’anciens exemples ; des scripts dormants peuvent ne jamais être revus ; un audit interne peut conclure que le problème est réglé parce qu’une option avec en-tête existe.

La réponse n’est pas de supposer qu’ARIN doit publier des données d’utilisation nominatives qui pourraient elles-mêmes être sensibles. Une transition peut être observable sans exposer d’identités ni de secrets. ARIN pourrait au minimum décrire les phases envisagées, l’événement qui déclenchera le compte à rebours, le préavis prévu, la manière dont les changements de compatibilité seront annoncés et les éléments qui justifieraient une prolongation. Si aucune date n’a été choisie, le dire explicitement est plus utile que de laisser les clients déduire une échéance de « à terme ».

Les éléments examinés ne montrent pas qu’ARIN s’est engagé sur ces jalons. Ce sont des recommandations pour rendre un futur retrait prévisible, pas la description d’un plan actuel. Cette limite est importante : annoncer une date crée une obligation. Si ARIN n’a pas pris cette décision, l’analyse ne doit pas prétendre le contraire.

Un dossier de retrait ne se limite pas à une note de version

Une migration techniquement réussie ne se résume pas à un exemple d’en-tête fonctionnel. Les opérateurs ont besoin de savoir quels points de terminaison et outils l’acceptent, si des bibliothèques clientes ont une incompatibilité connue, quelle erreur apparaît si l’en-tête manque ou est mal formé, et si une requête peut envoyer par inadvertance l’en-tête et un jeton URL simultanément. Les guides publics d’ARIN répondent à la question de syntaxe principale. Les documents examinés ne fournissent pas d’inventaire public par client ni de tableau d’adoption.

Un tel tableau n’a pas à révéler l’identité d’un client. Des volumes agrégés peuvent montrer si les appels par en-tête remplacent ceux par paramètre d’URL, si une longue traîne subsiste et si la migration est concentrée sur quelques intégrations. Un avis de retrait pourrait associer ces mesures à des dates : annonce, arrêt des nouveaux exemples URL, période d’avertissement, revue finale de compatibilité et fenêtre de retrait envisagée. Si aucune mesure ne peut être publiée sans révéler des données opérationnelles, ARIN pourrait exposer les critères de décision et indiquer si chaque étape est franchie.

Pour les clients, attendre une date universelle n’est pas une stratégie de sécurité. La recommandation actuelle est déjà claire : retirer la clé API des URL dès que le client prend en charge l’authentification par en-tête. Les équipes peuvent rechercher l’assemblage de chaînes de requête dans le code et la configuration, mettre à jour les bibliothèques partagées d’abord, vérifier que journaux et traces expurgent Authorization, tester les opérations représentatives sous leur procédure de changement et remplacer les clés exposées. Ces mesures restent utiles quelle que soit la date de retrait.

Il faut toutefois tester la migration au lieu de remplacer une chaîne et de supposer que tous les clients se comportent de la même façon.

Le registre ne devrait pas transformer l’échéance finale en surprise. Un processus par étapes laisse aux opérateurs le temps de découvrir des clients qu’ils ne maintiennent pas, de contacter les fournisseurs, de mettre à jour les procédures et de vérifier la supervision. Des avertissements peuvent précéder le rejet ; le rejet peut être réservé à une étape ultérieure ; une procédure d’exception documentée peut traiter une dépendance réelle sans rendre silencieusement la méthode provisoire permanente. Les sources ne disent pas qu’ARIN a choisi ces contrôles.

Ce sont les composantes habituelles d’un changement dont les conséquences de compatibilité dépassent l’organisation qui le met en œuvre.

Ce que veut dire « close »

La suggestion de 2022 demandait un moyen plus sûr d’authentifier les appels REST. ARIN en a fourni un, puis a clos le dossier. Au sens étroit, le statut est exact. Mais un statut de suivi n’est pas une mesure de migration. Il confirme que l’alternative a été mise en œuvre ; il ne dit pas combien d’appels utilisent encore l’ancien format, quel préavis s’appliquera ni quand cette compatibilité prendra fin.

Pour les clients d’ARIN, la conclusion pratique est simple : utiliser l’en-tête dans les nouveaux clients et les clients maintenus, et traiter la prise en charge de l’URL comme une compatibilité, non comme une option de sécurité équivalente. Pour ARIN, la tâche de gouvernance restante consiste à rendre le retrait futur suffisamment lisible pour transformer une recommandation en migration coordonnée. Les sources ne justifient ni d’alléguer une fuite ni d’attribuer une faute. Elles justifient de demander quel signal public marquera le démarrage du second calendrier.

Sources