Résumé

  • ARIN prévoit un ASPA propre à chaque Customer ASN et permet d’en modifier l’ensemble des Provider ASes. Même l’ajout d’un seul fournisseur remplace donc une déclaration complète.
  • La documentation sépare l’effet immédiat dans la base RPKI, l’apparition dans le dépôt public sous 24 heures, les mises à jour effectuées toutes les quelques minutes et le contrôle par un validateur. Ce sont quatre états observables, pas un unique succès.
  • Les Internet-Drafts actifs demandent l’union de tous les fournisseurs, y compris les serveurs de routes non transparents, et distinguent No Attestation de Not Provider+. Une omission peut peser sur la validation sans rendre automatiquement toute route invalide.
  • Un reçu proportionné doit lier l’ensemble autorisé avant la modification, l’ensemble complet soumis, le résultat atomique, l’objet publié et la vue d’un validateur, sans dévoiler contrats ni topologie interne.

Une opération de routage peut tenir dans une phrase : « ajoutez notre nouveau transit ». C’est ainsi qu’elle arrive dans un ticket, qu’elle est discutée avec les achats et qu’elle trouve sa place dans une fenêtre de maintenance. Mais un ASPA ne signe pas cette phrase. Il exprime l’ensemble des systèmes autonomes autorisés à apparaître comme fournisseurs d’un Customer ASN.

La différence paraît minime jusqu’au jour où deux changements se croisent. Un responsable part d’un ensemble composé de A et B pour ajouter C. Entre-temps, une automatisation ajoute le serveur de routes R. Si le premier responsable soumet finalement A, B et C, la transaction peut être parfaitement valide tout en effaçant R. Personne n’a nécessairement mal saisi un ASN ; chacun a seulement travaillé à partir d’un état devenu ancien.

Le service d’ARIN rend cette nature collective assez claire. Pour une organisation qui détient plusieurs ASN, sa documentation demande un objet ASPA unique pour chacun des Customer ASN. Dans ARIN Online, l’utilisateur modifie le « Set of Provider ASes ». L’API RPKI exprime pour sa part des éléments aspaDelete et aspaAdd comprenant le Customer ASN et les providerAsIds. Elle autorise aussi l’association d’opérations ASPA et ROA dans une transaction dont tous les éléments réussissent ou échouent ensemble.

Cette atomicité est une bonne propriété. Elle empêche qu’une moitié du lot devienne officielle tandis que l’autre moitié est rejetée. Elle ne répond toutefois qu’à la question de l’acceptation par ARIN. Elle ne prouve ni que le demandeur avait vu le dernier état autorisé, ni que l’objet correspondant était déjà présent dans le dépôt public, ni qu’un relying party l’avait récupéré et interprété.

Le singulier du ticket masque le pluriel de la déclaration

Les écrans de gestion favorisent naturellement le geste élémentaire. Une ligne reçoit un ASN, une autre disparaît, puis un bouton ferme l’opération. Or la déclaration consommée n’est pas une suite autonome d’autorisations. C’est un état complet.

Le profil ASPA actuellement en cours de travail à l’IETF demande de recenser tous les Provider ASes, dont les ASN des serveurs de routes non transparents. Si plusieurs objets ASPA valides existent pour le même client, le relying party construit leur union. Le texte recommande néanmoins d’éviter cette multiplicité, car le chevauchement de périodes de validité peut créer des courses. Le projet sur la vérification recommande lui aussi un objet unique représentant l’union des fournisseurs.

Il faut nommer précisément le statut de ces textes. Ce sont des Internet-Drafts actifs, et non des RFC définitives. Leur formulation peut encore évoluer. Cela n’enlève rien au fait qu’ils décrivent la sémantique actuelle contre laquelle les outils sont conçus : le fournisseur oublié n’est pas une ligne restée vide, mais un membre absent d’un ensemble présenté comme complet.

Cette absence peut avoir plusieurs origines. Le contrat de transit a pu se terminer. Un serveur de routes peut être transparent et ne pas devoir figurer, ou non transparent et devoir être recensé. Une liaison de secours peut exister sans porter de trafic habituel. Une ancienne session d’administration peut enfin écraser un ajout récent. Le registre ne peut pas deviner laquelle de ces histoires est vraie à partir du seul BGP observé.

Il peut en revanche empêcher qu’elles se confondent. Pour cela, la demande doit dire : « je remplace l’état dont voici l’empreinte par cet ensemble complet ». Si l’empreinte ne correspond plus, le service refuse le remplacement comme conflit d’état. Ce refus n’arbitre pas la relation commerciale ; il rend simplement visible le besoin de réconciliation.

Une absence n’a pas toujours le même sens

Le projet de vérification distingue trois résultats utiles au raisonnement. Sans entrée ASPA utilisable pour le client, on obtient No Attestation. Si le fournisseur appartient à l’ensemble utilisable, on obtient Provider+. S’il n’y appartient pas alors qu’un ensemble utilisable existe, le résultat est Not Provider+.

La différence est plus importante que la typographie. Supprimer l’objet et publier un objet non vide qui omet un fournisseur ne formulent pas la même assertion. Dans le premier cas, aucun ensemble exploitable ne porte l’attestation. Dans le second, un ensemble existe et ne reconnaît pas cette paire client-fournisseur.

Il serait néanmoins excessif d’en conclure qu’une omission rend automatiquement chaque route invalide. La vérification complète du chemin tient compte de sa direction, de ses segments et des autorisations disponibles. Le projet avertit qu’un fournisseur manquant peut conduire plus tard à déclarer à tort une route ASPA Invalid. C’est un mécanisme de risque, pas la description d’un incident observé chez ARIN.

Le reçu doit donc conserver plus qu’un verbe. « C ajouté » ne dit pas si B est resté présent. « A retiré » ne dit pas si l’état final est vide ou contient B et C. Même une capture d’écran ne relie pas forcément l’affichage aux octets de la requête, au certificat utilisé, à l’objet émis et à la vue du validateur.

Quatre horloges au lieu d’un horodatage

La première horloge est celle de la décision. Elle part de l’ensemble vu par la personne ou l’automate autorisé et se termine avec l’ensemble complet approuvé. Un reçu public n’a pas besoin de donner le nom du salarié ; une classe de rôle et une empreinte de l’état suffisent pour établir qu’il existait une autorité définie.

La deuxième est celle de la transaction. ARIN reçoit la demande, authentifie son auteur, applique les contrôles et accepte ou rejette l’ensemble. Lorsqu’ASPA et ROA partagent une transaction, l’identifiant commun doit préserver le caractère tout ou rien sans imposer la publication publique de tous les préfixes concernés.

La troisième horloge est celle de la publication. ARIN indique que la modification agit immédiatement dans sa base RPKI et doit apparaître dans le dépôt public sous 24 heures. La même page précise que le dépôt est mis à jour toutes les quelques minutes. Il ne faut donc pas transformer la borne de 24 heures en durée habituelle ; il faut mesurer l’heure réelle de première observation, l’empreinte de l’objet et la référence de manifeste ou de dépôt.

La quatrième horloge appartient au validateur. Celui-ci récupère le matériel, vérifie la chaîne et construit l’ensemble utilisable. Son résultat dépend d’un point d’observation, d’un logiciel, d’une version et d’un instant. Une observation reproductible est une preuve utile. Elle ne signifie pas que tous les relying parties de la planète ont convergé.

Lorsque ces quatre horloges sont réduites à « mis à jour à 14 h 03 », le diagnostic devient devinette. Une intention incomplète, un conflit de transaction, une publication non encore observée et un validateur en retard produisent des remèdes différents. Le reçu doit garder les frontières, parce que c’est à ces frontières que l’on attribue le travail.

Le contenu minimal du reçu

La première section identifie le Customer ASN et le contexte du certificat émetteur. Elle conserve l’ensemble antérieur dans un ordre canonique, ou son empreinte accompagnée d’une référence durable à l’objet antérieur. Elle conserve ensuite l’ensemble complet soumis. Ajouts, retraits et éléments inchangés sont calculés à partir de ces deux états.

La deuxième section explique les rôles utiles. Les serveurs de routes non transparents doivent pouvoir être distingués. L’opérateur peut aussi annoter en privé un fournisseur de secours ou d’urgence. Ces annotations n’ont pas à modifier la charge utile ASPA ; elles évitent seulement qu’une relation silencieuse parce qu’elle est en veille soit supprimée par inadvertance.

La troisième section décrit la transaction : identifiant de requête, classe de l’acteur authentifié, empreinte de l’ensemble soumis, condition de comparaison avec l’état antérieur, date d’acceptation et résultat. Elle précise si l’opération appartenait à un lot atomique avec des ROA, sans publier ce qui n’est pas nécessaire au lecteur.

La quatrième section suit l’objet : empreinte de l’ASPA émis, référence au dépôt, première observation publique et, si possible, référence au manifeste. La cinquième consigne la vue du validateur : point d’observation, logiciel et version, heure de récupération, ensemble utilisable observé et résultats testés pour les paires concernées.

Enfin, le reçu a besoin de ses propres liens temporels : corrigé par, remplacé par, expiré à, retour à l’état. Un retour arrière ne doit pas supprimer la trace de l’état fautif. Il constitue une nouvelle décision complète, liée à celle qu’il corrige.

Une preuve publique peut rester sobre

Les ASN de fournisseurs contenus dans un ASPA sont destinés au système public RPKI. Ce fait ne rend pas publics les tarifs, le volume de trafic, les clauses contractuelles, l’identité des agents, les fenêtres de maintenance, les identifiants ou la topologie interne. Le niveau public peut conserver ensembles signés, empreintes, horodatages et classes de rôle. Le détail d’approbation peut rester dans un espace réservé au membre.

La même retenue doit s’appliquer à l’observation. Nommer un moniteur et sa version permet de répéter le test. Affirmer que « l’Internet a vu le changement » confère à une mesure locale une portée qu’elle n’a pas. Plusieurs points d’observation renforcent le dossier ; aucun ne devient une vue universelle.

ARIN a annoncé en mars 2026 qu’ASPA était pleinement disponible dans ARIN Online. Il s’agit d’une information sur la disponibilité du service, pas d’une mesure d’adoption ni d’un certificat de fonctionnement sans erreur. Lors de l’ARIN 57, John Curran a d’ailleurs séparé la mission d’implémenter et d’expliquer ASPA de la décision des opérateurs de le déployer.

Le reçu proposé respecte cette frontière. Il ne dit pas à un réseau quels fournisseurs déclarer. Il montre quelle décision autorisée ARIN a reçue, quel état elle remplaçait, quel objet a été publié et où cet objet a été observé.

Aucun élément examiné ne prouve qu’ARIN ait perdu, retardé, réordonné ou mal publié un ensemble réel. Aucun chemin n’est présenté comme devenu ASPA Invalid. Le contrôle est proposé précisément parce que préserver l’état antérieur au moment de l’opération coûte peu, alors que le reconstruire après une alerte coûte cher et reste incertain.

Dans le ticket, un fournisseur change. Dans le système signé, un ensemble entier change. Le bon reçu est celui qui sait tenir ces deux vérités ensemble.

Sources