Résumé

  • Le guide de la base ARIN permet de rattacher un Resource Tech POC à une ressource déterminée, tandis que le Routing POC porte la responsabilité RPKI et IRR au niveau de l’organisation.
  • Déposée le 20 août 2026, la suggestion ACSP 2026.10 demande que le premier puisse agir sur les ressources auxquelles il est lié.
  • La page ne porte que le statut Confirmed, sans commentaire d’ARIN ni échéance. Le processus ACSP distingue explicitement l’accusé de réception de l’évaluation ultérieure.
  • Une mise en œuvre prudente devrait accorder des capacités par préfixe et par opération, avec durée, révocation, éventuelle double validation et journal de l’autorité utilisée.

Le contact qui connaît le bloc n’a pas nécessairement le bouton

La documentation publique d’ARIN ne traite pas tous les POC comme des synonymes. L’Organizational Tech POC agit sur l’Org ID et sur les ressources qui en dépendent. Le Resource Tech POC, facultatif, peut recevoir une autorité directe sur une allocation, un bloc ou un ASN. Il peut modifier le nom et les commentaires publics d’une ressource, associer d’autres contacts et, selon le type de ressource, renseigner des serveurs de noms ou des enregistrements DS.

Le Routing POC occupe un autre emplacement dans ce modèle. ARIN le présente comme responsable des informations de certification IRR et RPKI « pour l’organisation ». La différence est modeste dans le vocabulaire, mais importante dans l’exploitation : l’un peut suivre un objet précis, l’autre suit le conteneur institutionnel.

Les interfaces de sécurité de routage reprennent cette logique. Pour créer un ROA dans ARIN Online, l’utilisateur choisit d’abord l’organisation à administrer. Dans l’API, l’adresse de la transaction est /rest/rpki/ORGHANDLE. Une même requête peut créer et supprimer plusieurs ROA et être couplée à des changements ASPA. Côté IRR, l’Org ID demeure celui du mainteneur et les liens de contact décrivent des POC de l’organisation.

Cette architecture peut être cohérente : elle évite qu’un contact limité à un bloc touche par inadvertance les autres actifs de routage du même Org ID. Mais elle crée aussi un passage obligé lorsque l’équipe qui exploite réellement un préfixe n’est pas celle qui détient le rôle de routage central.

Un signal entrant, pas une décision d’ARIN

La suggestion est signée Nathanael Jean-Francois. Son texte affirme que des équipes proches des ressources doivent passer par le Routing POC pour créer ou supprimer des ROA, et que ce relais peut allonger la remédiation d’incidents ainsi que le lancement de services. Ce sont les motifs avancés par l’auteur de la demande. Aucun tableau public ne mesure les délais, le nombre de préfixes concernés ou les incidents attribuables à ce chemin d’autorisation.

La fiche apporte une autre limite décisive. Elle indique : dépôt le 20 août, délai non précisé, statut Confirmed, mise à jour le même jour. La rubrique de suivi ne contient pas de réponse d’ARIN.

Le texte officiel de l’ACSP explique la séquence. ARIN confirme immédiatement la réception d’une suggestion valide, puis le personnel dispose de dix jours ouvrés pour l’évaluer. Ce n’est qu’ensuite que la demande peut être déclarée impossible, transmise à un organe compétent, jugée réalisable ou soumise à consultation. Employer « confirmé » comme synonyme de « accepté » ferait disparaître tout ce qui se trouve entre l’entrée dans la file et une décision.

À ce stade, aucune permission n’a changé. Aucun modèle n’a été choisi. Aucun calendrier n’a été promis.

La granularité est le vrai sujet

Une réponse rapide mais mal conçue consisterait à donner à tout Resource Tech POC les droits complets du Routing POC sur l’Org ID. Elle supprimerait un relais humain en agrandissant brutalement le rayon d’action du compte.

Or le rattachement à une ressource contient déjà une information utile : cette personne ou ce rôle intervient sur tel objet, pas nécessairement sur tous les préfixes, ASN et unités d’activité de l’organisation. Une délégation RPKI qui ignore cette information réintroduirait au niveau de la sécurité ce que le registre avait précisément séparé dans son modèle de contacts.

La capacité devrait donc être plus petite que l’organisation. Elle peut nommer les NET handles ou plages couverts, distinguer création, modification et suppression, séparer ROA, ASPA et objets IRR, préciser qui accorde le droit et jusqu’à quand, puis définir révocation et gel d’urgence. Certaines suppressions ou opérations en masse peuvent exiger un second accord sans imposer cette friction à chaque ajout courant.

L’échec atomique est essentiel. Si une transaction contient dix objets dont un seul dépasse le périmètre accordé, elle ne doit pas appliquer les neuf autres en laissant une opération partielle difficile à reconstruire. De même, le transfert d’une ressource vers un autre Org ID ou le retrait du Resource Tech POC doit invalider les droits dérivés, y compris ceux portés par une clé API.

ARIN publie déjà pour les ROA un journal indiquant l’heure, l’opération, la source, l’AS d’origine, le préfixe, la longueur maximale et l’utilisateur. Une délégation fine doit ajouter la provenance du pouvoir : quel lien actif a permis à cet acteur d’effectuer cette opération sur cet objet précis ?

Ce que les documents ne prouvent pas

La suggestion ne documente ni route rejetée, ni service interrompu, ni ROA erroné resté en place. Elle ne permet pas de compter les organisations touchées. Elle ne démontre pas que tous les contacts techniques de ressource doivent pouvoir supprimer un ROA sans contrôle.

L’étiquette publique d’un POC n’est pas non plus une autorisation complète. Le lien entre le compte ARIN Online et le POC, l’éligibilité RPKI, la couverture contractuelle, l’état du certificat et les validations internes restent déterminants.

Le fait nouveau est donc précis : ARIN a enregistré une demande qui met en regard deux niveaux de son propre modèle, ressource et organisation. Le prochain document utile ne sera pas une promesse vague d’accès plus rapide, mais une évaluation datée montrant comment une délégation plus proche de l’exploitation resterait plus étroite que le pouvoir central qu’elle remplace.

Sources