Résumé

  • Le 13 novembre 2025, ARIN a bloqué administrativement l’accès à ses dépôts RPKI Hosted et RPS de 13 h 30 à 14 h 30 EST. L’accès a été rétabli à 14 h 30, la redondance confirmée à 14 h 35 et le niveau antérieur retrouvé à 14 h 50.
  • Ce test documente la reprise après une coupure d’accès au dépôt. Il ne publie ni les classes de dépendance externe, ni les risques communs, ni le périmètre d’observation réclamés par la suggestion ACSP 2025.7.
  • Une fiche versionnée par service et domaine de panne permettrait de relier l’invariant protégé, le scénario exercé, les jalons observés, les hypothèses restantes et le seuil de notification, sans exposer l’architecture sensible.

Le calendrier commence par un incident qui n’était pas un incident de bascule. Le 23 octobre 2025, ARIN reçoit le signalement d’un client concernant Hosted RPKI après le déploiement d’une fonction prenant en charge les ROA lors des transferts. Le compte rendu publié le 27 octobre parle d’une configuration précise, d’un seul client touché et d’un défaut logiciel. Les transferts en cours sont suspendus, le correctif est mis en production, puis des validations supplémentaires sont ajoutées.

Le lendemain du signalement public, le 28 octobre, Ramakant Pandrangi dépose la suggestion 2025.7. Sa demande porte sur un autre étage : les dépendances de chaque service ARIN, les changements d’architecture qui doivent être annoncés et les objectifs de continuité, notamment RTO et RPO. Le texte cite le DNS, les CDN, les adresses IP, les routes BGP, les fournisseurs et les dépendances circulaires.

Le 12 novembre, ARIN répond qu’un plan est en préparation et qu’il sera soumis à la communauté. Le 13 novembre, l’organisation mène son exercice RPKI en production. Cette proximité donne envie de raconter une seule histoire. Les preuves imposent au contraire d’en conserver trois : un défaut de code, une question de gouvernance opérationnelle et un test de reprise.

Ce que la chronologie démontre

Selon le message archivé sur la liste technique d’ARIN, la restriction d’accès aux sites desservant les dépôts Hosted et RPS commence à 13 heures EST. À 13 h 30, tout accès est bloqué afin de simuler une panne complète. L’accès revient à 14 h 30. Cinq minutes plus tard, ARIN confirme la pleine redondance. À 14 h 50, le système est revenu à son niveau d’avant le test.

Ces heures donnent une forme vérifiable à l’expression « haute disponibilité ». Elles distinguent le début de la restriction, la coupure totale, le rétablissement, la confirmation et le retour à la normale. ARIN explique aussi pourquoi le test a eu lieu en production : un environnement séparé ne rendait pas fidèlement la préparation à une défaillance réelle du dépôt.

Il serait injuste de traiter cette publication comme si elle ne disait rien. Elle dit beaucoup sur le scénario choisi. Mais un scénario n’est pas l’inventaire de toutes les conditions qui pourraient l’empêcher de réussir.

Le blocage a été administratif. Le message ne précise pas si les chemins de secours utilisaient des fournisseurs DNS, CDN, transit, énergie ou identité distincts. Il ne nomme pas la limite logique ou physique injectée derrière le blocage. Il ne fournit pas non plus un échantillon de validateurs indépendants, une mesure des caches ou un effet observé sur le routage. Ces éléments ne sont pas nécessairement requis pour réussir l’exercice ; ils sont requis pour élargir la conclusion.

Deux chemins visibles peuvent partager une condition invisible

La suggestion 2025.7 vise les dépendances systémiques et circulaires. Une redondance applicative peut reposer sur le même service de nommage. Deux sites peuvent sortir par un même opérateur. À l’inverse, une dépendance externe n’est pas automatiquement fragile : elle peut être diversifiée, remplaçable, mise en cache ou isolée par contrat et par conception.

La bonne question n’est donc pas « quel fournisseur ? », mais « quel invariant survit à la perte de quelle classe de dépendance ? ».

Pour un dépôt RPKI, plusieurs invariants sont possibles. Les lecteurs peuvent continuer à récupérer le dernier état accepté. Les nouvelles publications peuvent être différées sans perdre leur ordre. L’intégrité des objets déjà servis peut être maintenue. Les écritures mises en attente peuvent être rapprochées après reprise. Chacune de ces promesses correspond à un plan différent : lecture, écriture, signature, publication ou réconciliation.

L’avis de maintenance de juillet 2026 montre qu’ARIN sait publier cette granularité. ARIN Online, le provisionnement REST, RPKI Up/Down et RPS étaient annoncés indisponibles, tandis que le dépôt RPKI restait accessible sans nouvelles mises à jour. Un article antérieur de Theo March a étudié l’écart entre disponibilité et fraîcheur. Ici, l’objet est ailleurs : les domaines de panne couverts par chaque plan et la portée exacte de l’exercice.

Hosted, Delegated et RPS ne placent pas le contrôle au même endroit

La documentation actuelle d’ARIN indique que plus de 95 % de ses déploiements RPKI utilisent Hosted RPKI. ARIN y exploite l’autorité de certification et le dépôt. Un participant Delegated peut conserver sa propre autorité et son propre serveur de publication. Avec RPS, il garde l’autorité de certification et la clé privée, tandis qu’ARIN exploite le dépôt à haute disponibilité.

Cette séparation est volontaire. La page RPS rappelle qu’un dépôt consolidé peut se trouver hors du périmètre administratif de l’émetteur. Une organisation peut vouloir maîtriser l’acte cryptographique sans assurer elle-même un service de publication vingt-quatre heures sur vingt-quatre.

La résilience doit alors être lue en deux colonnes au minimum. L’émetteur peut-il produire un contenu publiable et valide ? Le dépôt peut-il accepter puis distribuer ce contenu ? La réussite d’une reprise du dépôt répond à la seconde question. Elle ne certifie pas mécaniquement l’autorité de certification, le protocole de publication, l’accès au compte ou la chaîne de notification.

Cette prudence protège la valeur de RPS. Si l’on confond la disponibilité du dépositaire et le contrôle cryptographique de l’émetteur, on efface le partage de responsabilités que le service est justement conçu pour offrir.

Un taux annuel ne représente pas un domaine de panne

Dans son rapport annuel 2025, ARIN attribue 99,9 % de disponibilité aux dépôts RRDP et Rsync. Le chiffre est utile : il rend une performance annuelle comparable et évite de réduire la fiabilité à une impression.

Il ne donne pas la carte de dépendances. Il ne dit pas si deux chemins partagent une condition, quel RTO s’applique, quelle perte de données serait tolérée ni quelle partie de la disponibilité provient d’une reprise testée. Un excellent taux et une documentation incomplète des dépendances peuvent coexister. Une architecture bien séparée peut, elle aussi, connaître une interruption mesurée.

Le rapport d’incident d’octobre apporte une autre preuve, sur un autre mécanisme. ARIN y attribue le problème à un défaut de code après déploiement, limité à une condition et à un client. Ce texte renseigne la maîtrise du changement et la correction. Il ne permet pas de conclure qu’un fournisseur externe a défailli. La discipline consiste à ne pas demander à une preuve de porter une conclusion qu’elle n’a pas mesurée.

Informer sans offrir un plan de reconnaissance

La transparence a un coût de sécurité. Publier les emplacements, fournisseurs, points de contrôle, routes exactes ou conditions de bascule peut faciliter une attaque. Certaines relations contractuelles sont confidentielles. Une cartographie interne détaillée vieillit aussi rapidement.

ARIN n’a pas besoin de rendre ce plan public. Une fiche par service et par plan suffirait. Elle indiquerait la fonction publique, les classes de dépendance, l’invariant protégé, la limite du scénario testé, les jalons constatés, les modes non testés, l’objectif de disponibilité ou de reprise applicable, le seuil de changement nécessitant une notification, ainsi qu’une date de révision.

Les classes remplaceraient les noms sensibles : « service de nommage », « livraison de contenu », « connectivité », « contrôle d’identité », « lieu d’exploitation ». Les résultats resteraient précis : heures du test, condition injectée, état protégé et hypothèses non couvertes. La communauté pourrait juger si l’invariant est utile sans apprendre comment viser le système.

La date d’expiration est essentielle. Une déclaration exacte aujourd’hui devient trompeuse si une migration change le domaine commun et si le document ne suit pas. La suggestion 2025.7 associe justement dépendances et gestion du changement. La fiche doit donc être corrigée ou remplacée lorsque l’architecture matérielle change.

« Ouvert » ne signifie pas « inactif »

À la date de l’enquête, la suggestion apparaît toujours comme Open. La réponse d’ARIN promet une présentation à la communauté une fois le plan finalisé. On peut décrire cet état public. On ne peut pas en déduire qu’aucun travail interne n’existe, qu’un retard est établi ou qu’une faiblesse est cachée.

Le prochain jalon utile serait un premier relevé limité, pas une garantie universelle. Un service, ses plans, ses classes de dépendance, le dernier test, ses limites et sa date de révision : cette petite unité peut être vérifiée, comparée et améliorée.

ARIN a déjà fourni la partie la plus rare, une intervention en production accompagnée d’une chronologie. La question des dépendances demeure parce que la reprise d’un scénario et l’indépendance d’une architecture sont deux propositions différentes. Les relier sans les confondre renforcerait les deux.

Sources