Résumé

  • Dans l’ACSP 2026.4, l’auteur de la suggestion a indiqué qu’après une Detailed Reassignment vers une autre Org, la clé API du titulaire amont ne pouvait pas obtenir le NET enfant par handle. La clé de l’Org destinataire le pouvait, tandis que l’amont pouvait, selon le même récit, supprimer le NET et le retrouver par plage exacte avec mostSpecificNet.
  • ARIN a clos la suggestion le 30 mars 2026 après avoir examiné d’autres moyens de retrouver l’information et des projets futurs. Sa réponse ne valide pas séparément chaque étape rapportée et le statut Closed ne signifie ni correctif déployé ni comportement universel établi.
  • La séparation peut être légitime : le destinataire d’une réaffectation détaillée dispose d’une autorité de gestion, alors que le titulaire direct conserve un droit de reprise. Un résultat Whois public n’est pas la même chose qu’un NET Payload d’approvisionnement authentifié.
  • Il manque surtout un contrat exploitable : une matrice versionnée des acteurs, relations, classes de NET, chemins, verbes, champs et préconditions, complétée par un aperçu de suppression expurgé et lié à un jeton de version.

Un droit d’accès n’habite pas un verbe. Il habite une relation.

C’est pourquoi le point de départ n’est pas GET, PUT ou DELETE, mais ce qui se passe lorsqu’un titulaire direct confie un bloc à une autre organisation. La documentation de gestion d’ARIN distingue la réaffectation simple, la Detailed Reassignment et la reallocation. Dans le premier cas, le client ne reçoit pas de capacité de gestion directe. Dans le deuxième, une Org destinataire obtient cette capacité ; le titulaire direct conserve toutefois le pouvoir de reprendre l’espace. Certaines fonctions de DNS inverse et d’IRR peuvent être partagées. La reallocation ouvre encore une autre faculté, celle de déléguer plus loin.

La frontière est fonctionnelle. Le destinataire doit pouvoir maintenir ce qui relève de sa présence dans le registre. Le titulaire amont doit pouvoir mettre fin à la relation dont il demeure responsable. Si le second héritait automatiquement de tous les champs et de toutes les modifications du premier, la Detailed Reassignment ne créerait aucune autonomie réelle.

La confidentialité renforce cette défense. Le NET Payload décrit par ARIN peut contenir version, commentaire, date d’enregistrement, handle de l’Org ou du client, bloc d’adresses, parent, nom, origin AS et liens vers les POC. Les champs de hiérarchie ne sont pas tous modifiables. Un annuaire public peut exposer une partie de cette identité sans ouvrir la charge d’approvisionnement complète à chaque acteur qui connaît le handle.

Il est donc parfaitement possible qu’un droit de reprise soit plus étroit qu’un droit de gestion. La difficulté commence seulement si le droit le plus lourd peut être exercé sans que son détenteur dispose d’une vue minimale de l’objet qu’il va détruire.

Le récit officiel reste un récit attribué

La suggestion ACSP 2026.4 a été déposée le 3 mars 2026. Son auteur dit avoir effectué une Detailed Reassignment depuis l’un de ses NET vers une autre Org. La requête GET par handle, signée avec la clé API de l’amont, aurait été refusée faute d’autorisation ; seule la clé de l’Org destinataire aurait réussi.

Le même auteur affirme cependant pouvoir DELETE le NET, l’obtenir par la plage exacte grâce à mostSpecificNet, et consulter les informations publiques par handle ou adresse IP dans Whois. Il en tire deux propositions : le parent devrait pouvoir lire, puis modifier par PUT, puisqu’il pourrait supprimer et recréer.

ARIN n’a pas adopté cette hiérarchie. Dans sa réponse du 30 mars, l’organisation indique avoir discuté d’autres méthodes de récupération de l’information à l’aide d’outils existants ainsi que de plans de développement futurs. Elle conclut qu’une modification des contrôles d’autorisation n’est pas nécessaire à ce moment-là. La suggestion est close avec l’accord de son auteur.

Ce dossier officiel ne doit pas être gonflé au-delà de ce qu’il prouve. Il conserve un comportement rapporté et la réponse institutionnelle. Ce n’est ni un avis de vulnérabilité, ni un incident, ni une reproduction indépendante. Les pages actuelles documentent des routes et des types de payload ; elles ne démontrent pas que chaque compte et chaque objet rencontrent aujourd’hui les mêmes décisions.

Cette prudence ne diminue pas l’intérêt du cas. Elle en précise la question : que promet exactement le contrat d’exploitation lorsqu’un même objet est résolu par plusieurs chemins ?

Trois résolutions, trois ensembles de sens

Le catalogue Reg-RWS documente un GET par NETHANDLE, un GET mostSpecificNet par adresses de début et de fin, un DELETE par handle et un PUT par handle. Les deux GET retournent un NET Payload. DELETE produit une Ticketed Request Payload. PUT exige un NET Payload et renvoie l’état après modification.

Une lecture rapide y voit des variantes d’accès au même NET. Une lecture d’opérateur y voit des préconditions différentes :

Chemin Ce que l’appelant doit déjà posséder Ce que le chemin permet d’établir
Handle l’identité stable du NET l’objet désigné comme tel par le registre
Plage exacte les deux bornes correctes le NET le plus spécifique correspondant à ces bornes
Whois/RDAP un handle ou une adresse recherchable une représentation publique de l’enregistrement

L’alternative par plage est moins autonome qu’elle n’en a l’air. L’ACSP 2023.13 relève que mostSpecificNet avec début et fin exacts ne permet pas de partir simplement d’une adresse quelconque contenue dans le réseau. Il faut déjà connaître les limites. Une base locale exacte rend ce chemin utile ; une base locale périmée peut en faire une vérification circulaire.

Pour une personne, le portail ARIN Online peut fournir une recherche et un écran de confirmation. Pour une automatisation, le fait qu’une solution humaine existe ne définit pas la cohérence entre l’état local et l’objet autoritatif. Le programme doit savoir si le handle, la plage et la relation parent-enfant sont encore ceux qu’il croit connaître au moment de l’exécution.

La reprise mérite une précondition, pas une clé maîtresse

La suppression n’est pas un simple changement de champ. ARIN précise qu’elle ne s’applique qu’aux réaffectations et reallocations. Sans NET enfant, le traitement peut être automatique et la réponse contient les détails du réseau supprimé. Avec des réseaux imbriqués, une demande ticketée est créée ; l’espace ne doit pas être réattribué avant la réussite du ticket.

Les instructions de réaffectation demandent également à l’utilisateur de retrouver le réseau, de choisir son Net Handle et de confirmer une opération annoncée comme irréversible. Le handle, la structure descendante et le résultat du ticket sont donc déjà des éléments de sécurité. La faiblesse conceptuelle est leur temporalité : si les détails les plus fiables n’arrivent qu’après DELETE, ils servent à constater, pas à prévenir.

Le bon compromis consiste en une vue de reprise expurgée. Elle pourrait contenir l’identité stable et la plage normalisée, la classe du NET, la relation de parent direct, l’existence de descendants, le mode automatique ou ticketé, un résumé des dépendances DNS/IRR/routage, la portée des notifications et un jeton de version de courte durée. Elle exclurait commentaires privés, coordonnées protégées et champs de gestion propres au destinataire.

DELETE présenterait ensuite le jeton. Toute modification de la plage, de la hiérarchie ou d’une dépendance matérielle invaliderait l’appel. Le titulaire amont gagnerait la capacité de vérifier une action qu’il est déjà autorisé à entreprendre ; il ne gagnerait pas le droit d’administrer l’Org destinataire.

Huit coordonnées au lieu d’une échelle de verbes

Le contrat public devrait exprimer chaque cellule sous la forme :

rôle de l’acteur × relation × classe d’objet × chemin d’identification × verbe × jeu de champs × précondition × résultat

Cette formule évite deux erreurs symétriques. La première consiste à croire que toute différence entre deux chemins est un défaut. La seconde consiste à croire qu’une différence voulue n’a pas besoin d’être expliquée.

La matrice indiquerait séparément les simples réaffectations, les réaffectations détaillées et les reallocations ; les enfants directs et descendants ; le titulaire, l’Org destinataire et les rôles POC ; les sorties publiques, complètes ou expurgées ; les champs immuables ; l’exécution automatique et le ticket. Chaque asymétrie volontaire aurait une justification et une date d’effet.

La procédure de modification NET contient déjà une intuition comparable : obtenir le NET actuel avant de le modifier afin d’en garantir l’exactitude. Lorsqu’un acteur autorisé à reprendre ne doit pas recevoir le GET complet, il lui faut une primitive plus petite qui porte la même garantie de fraîcheur.

Une matrice testable permettrait enfin de transformer les différences en assertions. Le destinataire détaillé obtient son payload de gestion. Le titulaire direct obtient une vue de reprise. Le client simple n’obtient pas d’autorité de gestion. La reallocation suit ses propres règles. Le système n’a pas besoin d’être uniforme ; il doit être explicite.

Une clôture n’est pas une spécification

ARIN pouvait raisonnablement décider qu’un changement de permission n’était pas prioritaire. Les outils existants peuvent répondre à des besoins concrets et les plans futurs modifier l’équilibre. Le consentement de l’auteur à la clôture compte aussi.

Mais Closed demeure l’état d’un processus de suggestion. Il ne certifie pas une livraison, ne valide pas chaque test rapporté et n’interdit pas de réexaminer l’automatisation. La formulation « à ce moment-là » conserve justement cette latitude.

Si le modèle voulu est qu’un titulaire puisse reprendre sans obtenir le NET Payload complet par handle, il faut le dire. Si le portail ou la plage exacte constituent le pré-contrôle recommandé, leurs hypothèses de découverte doivent être publiées. Si une interface future doit résoudre l’objet avec moins de données, elle doit recevoir une version et un chemin de migration.

Le moindre privilège ne consiste pas à donner le moins d’informations possible en toute circonstance. Il consiste à fournir le minimum exact pour accomplir une responsabilité sans empiéter sur celle d’un autre. Pour une suppression irréversible, ce minimum inclut l’identité actuelle de ce qui va disparaître.