Résumé

  • Depuis octobre 2023, ARIN notifie les POC Admin, Tech et Routing à chaque suppression de ROA. En juin 2024, le plafond de suppressions autorisées pour une organisation est passé de 20 000 à 40 000.
  • La suggestion ACSP 2025.6 demande de pouvoir supprimer tous les courriels d’un appel de retrait en masse. La suggestion 2026.6 constate que la création et la modification ne donnent pas lieu à la même notification générale.
  • Le besoin de réduire le bruit est légitime. Mais la matérialité d’une opération ne dépend ni du nombre de messages ni du verbe supprimer : toute modification de l’ensemble d’autorisations peut changer les éléments utilisés pour valider une route.
  • Une solution minimale consisterait à produire un relevé durable par transaction, exposant l’autorité exercée, l’état avant et après, le résultat atomique, l’observation de la publication et les destinataires effectivement informés.

Quarante mille suppressions possibles, sans incident à inventer

Le 3 juin 2024, ARIN a consigné une hausse de limite : une organisation pouvait désormais effectuer jusqu’à 40 000 suppressions de Route Origin Authorizations, contre 20 000 auparavant. Ce nombre n’est pas le bilan d’une panne. Il ne démontre pas qu’un membre ait lancé une telle opération, encore moins que 40 000 routes aient disparu. Il décrit néanmoins l’échelle prévue par le produit.

Cette échelle donne son sens à une demande apparemment banale sur le courriel. Si chaque objet supprimé déclenche un message vers chaque personne d’une longue liste de POC, le système multiplie le nombre d’objets par le nombre de destinataires. Or ni l’un ni l’autre ne mesure directement le risque. Une transaction cohérente peut contenir des milliers d’objets ; une seule suppression peut être critique.

La règle initiale a pourtant une justification solide. Le 9 octobre 2023, ARIN a annoncé que les POC Admin, Tech et Routing recevraient une notification dans ARIN Online dès qu’un ROA serait supprimé. Retirer un ROA n’est pas une simple opération de nettoyage. Le ROA exprime qu’un détenteur de préfixes autorise un système autonome à les annoncer. Selon le RFC 8211, la suppression fait disparaître cette liaison vérifiable. Une annonce jusque-là couverte peut ensuite être classée NotFound s’il ne reste aucun ROA applicable, ou Invalid si un autre ROA couvrant le préfixe autorise un AS différent.

Ce mécanisme ne permet pas de conclure à une coupure. Selon les ROA restants, une annonce peut demeurer Valid, devenir Invalid ou passer à NotFound. Les caches n’évoluent pas tous en même temps et chaque réseau conserve sa propre politique pour les routes Invalid. Il suffit toutefois à expliquer pourquoi ARIN a choisi d’avertir plusieurs fonctions au sein de l’organisation. L’utilisateur de l’API, le responsable administratif et l’équipe de routage peuvent être trois personnes différentes. Un observateur indépendant du compte ayant effectué l’action peut déceler une erreur ou un identifiant compromis.

La défense la plus sérieuse de la notification n’est donc pas le volume. C’est la séparation entre celui qui agit et celui qui voit.

Une demande raisonnable contre la saturation

La suggestion ACSP 2025.6 part de l’expérience des grands gestionnaires d’adresses. Déposée le 11 juillet 2025, elle décrit des listes de POC longues et la nécessité de prévenir à l’avance les collègues d’une arrivée massive de messages. Elle demande un indicateur facultatif dans l’API de suppression en masse. Par défaut, rien ne changerait ; lorsqu’il serait activé, tous les courriels produits par l’appel seraient supprimés.

ARIN a répondu le 23 juillet que cette fonction serait utile et qu’elle serait priorisée dans le calendrier de développement. La page était toujours Open, en attente de mise en œuvre, lors du gel des sources. Le terme compte : il n’autorise pas à écrire que l’option existe déjà ni à deviner sa forme finale.

Sur le fond, l’objection au flot de courriels est convaincante. Des milliers de messages presque identiques encombrent les serveurs et les boîtes, mais surtout ils dégradent l’attention. Le destinataire prépare une règle de filtrage, cesse de lire ou considère la rafale comme la preuve attendue d’une maintenance. L’alerte censée rendre visible l’exception devient un bruit annoncé.

Réduire ce coût ne devrait pas obliger à choisir le silence. Le défaut réside dans l’unité de notification : un objet, plutôt qu’une opération.

Le changement d’autorité ne se résume pas au retrait

Une autre proposition publique a élargi la question. ACSP 2026.6, déposée le 23 avril 2026, affirme que tous les POC reçoivent une notification ARIN et un courriel lorsqu’un ROA est retiré, mais pas lorsqu’il est créé ou modifié. Elle demande des réglages facultatifs pour les trois types de changement et envisage un choix global au niveau du compte.

Le 27 avril, ARIN a regroupé cette amélioration avec d’autres travaux en attente sur les notifications ROA, l’a transmise à son processus interne de priorisation et a fermé la suggestion. Closed désigne ici la fin du traitement ACSP public. Ce n’est pas une attestation de déploiement.

Cette seconde demande révèle la faiblesse de la frontière existante. Un ajout peut être aussi important qu’un retrait. Lorsqu’un nouveau ROA couvre un préfixe, une annonce provenant d’un autre AS, ou plus spécifique que le maxLength autorisé, peut passer de NotFound à Invalid. Une modification peut réduire une portée, changer l’AS d’origine autorisé ou déplacer la longueur maximale. Le caractère additif de l’écriture en base ne dit rien, à lui seul, de son effet sur l’ensemble des preuves d’autorisation.

Le bon objet est donc la différence entre deux états : quelles liaisons préfixe-AS-maxLength étaient acceptées avant, lesquelles le sont après.

L’API actuelle d’ARIN confirme que ce niveau existe. Son guide RPKI décrit un appel unifié pour créer, modifier et supprimer des ROA au niveau de l’organisation. Le même ensemble peut intégrer des changements ASPA, et l’ensemble réussit ou échoue de manière atomique. Le payload contient une liste de ROA à supprimer et une liste à ajouter.

L’atomicité protège l’opérateur contre une substitution interrompue à mi-chemin. Elle fournit aussi une identité sémantique : il s’agit d’une intention de changement, pas d’une collection fortuite d’événements isolés. L’alerte devrait conserver cette identité.

Le journal existant mérite d’être pris au sérieux

ARIN ne part pas de zéro. Depuis septembre 2025, ARIN Online propose un ROA Change Log. La documentation courante indique une fenêtre de 365 jours et des champs utiles : horodatage, opération Added ou Removed, source Web User, API User ou ARIN System, AS d’origine, préfixe, maxLength et nom de l’utilisateur ayant effectué le changement. Au-delà de 100 entrées, l’affichage est paginé. Un CSV complet peut être demandé ; il est livré après traitement d’un ticket.

Ce journal constitue une réponse forte au besoin d’audit rétrospectif. Rien dans les sources consultées ne prouve qu’il soit inexact, modifiable par l’utilisateur ou indisponible. Il faut partir de cette capacité réelle, pas la minimiser.

Mais consulter un journal et recevoir un signal indépendant ne couvrent pas la même panne. Le journal attend qu’un utilisateur autorisé se connecte et enquête. La notification pousse l’information vers une personne ou un système séparé. Si le compte automatisé à l’origine du changement est précisément la source du problème, cette séparation a de la valeur. Inversement, si le canal indépendant reçoit dix mille messages sans synthèse, la séparation subsiste mais la compréhension disparaît.

Un relevé d’autorité par transaction

Une conception plus fine peut agréger sans effacer. Après chaque transaction validée, ARIN pourrait produire un seul relevé durable décrivant le changement net.

Élément du relevé Fonction probante
Identifiant de transaction et heure de fin Relier l’intention à l’opération acceptée
Organisation et catégorie d’acteur protégée Montrer sous quelle autorité l’action a été exécutée
Combinaison d’opérations Distinguer création, remplacement, suppression et actions ROA/ASPA liées
État d’autorisation avant et après Exposer la différence de préfixe, AS d’origine et maxLength
Résultat atomique Savoir si tout a réussi, échoué ou n’a pas été validé
État de publication observé Séparer la validation par le service de l’apparition dans le dépôt
Destinataires indépendants et livraison Prouver qu’un canal distinct de l’acteur a reçu la synthèse
Référence de correction Relier un retour arrière ou un remplacement ultérieur

Le détail personnel de l’acteur n’a pas à devenir public. Les ROA sont destinés à la consultation publique ; l’identité du compte et la liste interne des contacts appartiennent à un dossier protégé. Une organisation peut recevoir un résumé limité sur un canal de sécurité distinct sans exposer son organisation du travail.

Les préférences restent utiles autour de ce noyau. Un POC peut vouloir un courriel par transaction, une alerte dans ARIN Online, un webhook, un condensé périodique ou le détail par objet. Une correction urgente ne doit pas attendre l’approbation de tous. Informer n’est ni autoriser ni donner un droit de veto.

La règle minimale est plus étroite : une option de confort ne doit pas pouvoir supprimer simultanément l’enregistrement durable et tout signal indépendant d’un changement matériel.

Ce que les pièces ne permettent pas d’affirmer

Aucune source citée ne décrit un incident de suppression en masse, un compte compromis, une notification perdue ou une route rejetée. Le plafond de 40 000 n’est pas un compteur d’événements. La suggestion 2025.6 n’est pas mise en œuvre dans le dossier public ; la clôture de 2026.6 ne prouve pas une livraison. Le journal n’est pas démontré défaillant. Enfin, ARIN ne décide pas comment chaque réseau traite une route Invalid.

Les faits établissent une chose plus limitée : le produit dispose d’une transaction atomique et d’un journal riche, alors que le signal poussé suit encore principalement la suppression et que les propositions publiques oscillent entre multiplication et extinction des messages. C’est assez pour redessiner la frontière avant qu’un sinistre ne serve de cahier des charges.

Sources