Résumé

  • La disponibilité du RPKI est une propriété de bout en bout. Un contrôle de santé du serveur peut être vert tandis que les validateurs externes reçoivent des données obsolètes, incomplètes, incohérentes ou cryptographiquement inutilisables.
  • Une courte interruption ne modifie pas nécessairement la validation de routage, car les parties utilisatrices mettent en cache les objets précédemment validés. La même interruption devient critique lorsqu’un manifeste ou une liste de révocation de certificat dépasse son champ nextUpdate, qu’un certificat expire ou qu’un changement nécessaire ne devient jamais visible de l’extérieur.
  • Les incidents publics montrent des classes de défaillances distinctes: l’APNIC a signalé une incohérence rsync alors que le RRDP restait valide en 2019; le RIPE NCC a signalé une CRL expirée après une panne de publication silencieuse en 2020 et une publication incohérente de certificat parent-enfant en 2021; le JPNIC a signalé que les ROA devenaient NotFound après l’arrêt de la publication suffisamment longtemps pour que les champs de fraîcheur expirent en 2022.
  • Un engagement de service crédible doit mesurer les récupérations réussies depuis des réseaux indépendants, l’exhaustivité par protocole, la validité cryptographique, la marge de fraîcheur, les changements de charge utile validée, la convergence de récupération et tout changement associé dans la validation de routage observée.
  • L’attribution nécessite un enregistrement chronologique depuis le changement autorisé jusqu’à la production du certificat, la publication, la récupération externe, la validation, la livraison au routeur et la politique de routage. Sans cette chaîne, un registre, un référentiel, un fournisseur de logiciels et un opérateur réseau peuvent chacun pointer vers une autre couche.
  • L’impact sur le routage ne peut pas être déduit uniquement de la défaillance du référentiel. Les opérateurs choisissent leur politique locale, utilisent différents logiciels et intervalles de rafraîchissement, et voient différents chemins BGP. Les rapports doivent indiquer la population observée et conserver les inconnues plutôt que de revendiquer un taux de panne universel.
  • NRS peut renforcer la légitimité des registres en parrainant des sondes neutres, des champs d’incidents communs et une norme d’assurance reproductible de l’extérieur. Sa contribution positive serait de rendre testables les affirmations institutionnelles limitées, non de déclarer que chaque interruption de référentiel a causé une perte de clientèle.

Une panne commence chez la partie utilisatrice, pas dans la salle des serveurs

L’événement RPKI déterminant n’est pas un voyant rouge sur la console de l’opérateur du référentiel. C’est l’incapacité d’une partie utilisatrice extérieure à récupérer et valider les données sur lesquelles un réseau compte pour fonder ses décisions d’origine de route. Les deux événements peuvent coïncider, mais ils ne sont pas identiques.

Un opérateur de référentiel peut observer des processus sains, des sockets ouverts et des requêtes locales réussies tandis que des utilisateurs ailleurs rencontrent une défaillance DNS, un nœud de distribution de contenu cassé, une discordance TLS, une arborescence rsync incomplète, une incohérence de session RRDP ou un ensemble d’objets dont les signatures ne forment plus un chemin valide. À l’inverse, un référentiel peut être inaccessible pendant plusieurs heures sans modifier la vue validée déjà détenue par les opérateurs, à condition que le matériel en cache reste utilisable et qu’aucune mise à jour urgente ne soit manquée.

Cette distinction est plus qu’une ponctuation technique. Les documents de politique utilisent souvent la disponibilité comme s’il s’agissait d’une propriété d’une machine: minutes de fonctionnement divisées par minutes dans un mois. Le RPKI est un service de publication intégré dans une décision de sécurité distribuée. Sa production utile est un ensemble validé d’assertions, pas une page web qui répond. Une mesure qui s’arrête au bord du référentiel mesure donc la capacité de l’opérateur à se servir lui-même, pas la capacité de la partie utilisatrice à se reposer sur lui.

La bonne question est observable de l’extérieur: à un moment donné, depuis un réseau donné, en utilisant un protocole et une version de validateur donnés, une partie utilisatrice pouvait-elle récupérer le matériel complet requis pour un chemin de certification donné, le valider conformément aux normes applicables et produire les charges utiles validées attendues avant que les marges de fraîcheur ne soient épuisées?

Cette question est plus longue que « le serveur était-il en ligne? » parce que le service est plus long. Elle répartit aussi les responsabilités plus équitablement. Elle peut montrer une défaillance côté référentiel, un problème d’accessibilité spécifique au chemin, un défaut de validateur, un cache local obsolète ou un délai de livraison au routeur sans prétendre que tous les cinq ne font qu’un seul événement.

La publication RPKI est une chaîne de dépendances temporelles

Le RPKI donne aux opérateurs un moyen d’évaluer si un système autonome est autorisé à annoncer un préfixe. Un détenteur de ressources crée une autorisation d’origine de route. Les certificats lient les ressources numériques pertinentes en un chemin de certification. Les référentiels publient des certificats, des ROA, des manifestes et des listes de révocation de certificats. Le logiciel de la partie utilisatrice récupère et valide ces objets, produit des charges utiles validées et les fournit aux systèmes de routage, généralement via le protocole RPKI-to-Router.

Le routeur applique une politique locale aux annonces BGP classées comme Valid, Invalid ou NotFound.

Chaque verbe de cette séquence a sa propre frontière de défaillance. Un détenteur peut soumettre une origine ou une longueur maximale erronée. Un service de certification peut émettre un certificat incohérent. Un service de publication peut ne pas exposer un changement terminé. Un protocole d’accès peut fonctionner pendant qu’un autre échoue. Une partie utilisatrice peut rejeter trop, retenir trop peu ou se rafraîchir trop lentement. Une session RTR peut cesser de transporter un ensemble à jour. Un routeur peut recevoir l’ensemble et appliquer une politique inattendue. Une route peut être filtrée par un réseau et acceptée par un autre.

Le référentiel est central parce que toutes les parties utilisatrices ont besoin d’une vue de publication récupérable, mais ce n’est pas un routeur et il ne commande pas une réponse universelle. La RFC 7115 rend la politique de routage locale. Cela limite ce qu’un rapport de référentiel peut honnêtement affirmer. Il peut établir que des objets étaient indisponibles ou invalides, que certaines charges utiles validées ont disparu sous un logiciel défini et que des routes observées ont changé d’état à des points d’observation sélectionnés.

Il ne peut pas déduire de ces seuls faits la politique de chaque opérateur ou la joignabilité de chaque client.

Le temps relie les couches. Une interruption de dix minutes avec une large marge de fraîcheur diffère d’une interruption de dix minutes qui franchit le nextUpdate d’un manifeste. Un nouveau ROA retardé diffère de la disparition d’un ROA précédemment valide. Un cache qui protège la continuité pour un validateur peut être absent ou déjà proche de l’expiration pour un autre. La qualité de service doit donc s’exprimer comme une séquence de preuves temporelles, pas comme une durée unique.

Le temps de fonctionnement interne est nécessaire et radicalement insuffisant

La surveillance de disponibilité conventionnelle demande si un hôte ou une application répond. Cela reste utile. Un opérateur doit savoir si les serveurs d’origine, le stockage, les services de signature, les travailleurs de publication, le DNS, la terminaison TLS et les nœuds de distribution sont sains. Mais un contrôle interne a trois angles morts structurels.

Premièrement, il commence généralement à l’intérieur ou à proximité du réseau du fournisseur. Il peut contourner le résolveur DNS, le chemin d’appairage, la famille d’adresses, le nœud de distribution de contenu ou le contrôle d’accès rencontrés par un validateur externe. Une requête réussie depuis la même installation prouve peu de choses sur la joignabilité depuis l’Afrique, l’Asie, l’Europe ou les Amériques.

Deuxièmement, il tend à tester le transport plutôt que le sens. Un code HTTP 200 peut délivrer un ancien fichier de notification RRDP. Un démon rsync peut répondre tout en exposant une arborescence partiellement mise à jour. Un fichier peut être présent mais absent du manifeste actuel, listé avec un hachage erroné, signé sous une chaîne invalide ou associé à une CRL périmée. Le serveur est vivant; l’assertion est inutilisable.

Troisièmement, la surveillance interne sait souvent qu’une action de publication a été tentée, mais pas si des utilisateurs indépendants l’ont reçue. Une file d’attente peut marquer une tâche comme terminée lorsque les données ont atteint un répertoire d’origine, même si une couche de distribution a conservé la vue précédente. La différence entre une publication tentée et une publication visible de l’extérieur est précisément là où un service d’assurance doit regarder.

Une norme reproductible de l’extérieur ne rejette pas la télémétrie du fournisseur. Elle la place au bon endroit. Les preuves internes expliquent la cause et accélèrent la réparation. Les preuves externes établissent l’état visible par l’utilisateur. L’engagement de service devrait exiger les deux et spécifier comment les désaccords sont résolus. Si les contrôles internes disent « sain » alors que divers validateurs extérieurs échouent sémantiquement, le service est dégradé jusqu’à ce que l’écart soit expliqué.

Les caches transforment une simple panne en une course contre la montre cryptographique

Le RPKI a été conçu avec une mise en cache locale parce que les référentiels et les chemins réseau ne peuvent pas être supposés joignables en permanence. La RFC 8182 conseille aux parties utilisatrices de conserver les anciens objets, et la RFC 9286 recommande de continuer à utiliser les objets en cache associés à une récupération échouée jusqu’à ce qu’ils deviennent obsolètes ou puissent être remplacés avec succès. C’est une fonctionnalité de continuité importante. C’est aussi pourquoi le temps d’arrêt brut est une mauvaise description du risque.

Au début d’une interruption, deux parties utilisatrices peuvent détenir des états de cache différents mais valides. L’une s’est rafraîchie quelques instants plus tôt; l’autre approche de sa prochaine récupération planifiée. Leurs marges de fraîcheur restantes diffèrent. Si le référentiel récupère rapidement, les deux peuvent continuer à produire les mêmes charges utiles validées. Si la récupération arrive après les limites temporelles pertinentes, l’une peut perdre des objets plus tôt que l’autre. Une troisième implémentation peut suivre une politique locale différente pour le matériel obsolète.

L’incident a donc au moins trois horloges. La première mesure l’échec de récupération externe. La deuxième mesure la marge de fraîcheur pour chaque branche de certification affectée. La troisième mesure quand la sortie validée change réellement. Les rapports de politique ne publient généralement que la première, s’ils en publient une. Pourtant, la deuxième identifie l’urgence et la troisième la conséquence sur le service de sécurité.

La mise en cache peut aussi masquer une mise à jour échouée. Les objets existants restent valides, donc la validation générale semble stable, mais une correction nouvellement créée par un détenteur est absente. Si le changement manquant devait autoriser une migration ou réparer un état Invalid accidentel, la continuité pour l’ancien matériel ne signifie pas que le service était disponible pour le détenteur affecté. La disponibilité en lecture et la disponibilité de publication des changements ont besoin de mesures séparées.

Un rapport sensé trace ces horloges ensemble. Il indique quand les récupérations indépendantes ont d’abord échoué, le temps minimum observé jusqu’à l’expiration ou l’obsolescence pertinente, quand les changements attendus ont cessé d’apparaître, quand les validateurs ont changé de sortie et quand une part définie de sondes a convergé vers la récupération. Ce récit montre si la résilience du cache a fonctionné et à quel point le système est passé près d’une conséquence plus grave.

Les manifestes et les listes de révocation rendent la disponibilité sémantique testable

Un référentiel RPKI n’est pas simplement un répertoire de fichiers signés. Les manifestes énumèrent les objets signés associés à une autorité de certification et incluent des hachages. Ils aident les parties utilisatrices à détecter la suppression, la substitution et les vues incomplètes. Les listes de révocation de certificats identifient les certificats révoqués. Leurs champs temporels créent des attentes visibles de l’extérieur quant à la fraîcheur.

La RFC 9286 fournit une base inhabituellement utile pour la mesure de service. Une partie utilisatrice doit récupérer le manifeste identifié par le certificat, vérifier que le temps actuel tombe dans l’intervalle du manifeste, acquérir chaque fichier listé et vérifier chaque hachage. Un manifeste invalide ou obsolète, un fichier listé manquant ou une discordance de hachage est une récupération échouée. La partie utilisatrice doit continuer à utiliser les versions en cache appropriées jusqu’à ce qu’elles deviennent obsolètes ou qu’une récupération réussie les remplace.

Cela signifie qu’un observateur extérieur n’a pas besoin de faire confiance à la déclaration de l’opérateur selon laquelle la publication était complète. L’observateur peut tester l’inventaire signé par rapport aux fichiers récupérés. Il peut enregistrer l’autorité de certification exacte à laquelle la validation s’est arrêtée, la raison, le protocole et la marge de cache restante. Répéter ce test depuis des réseaux indépendants crée un historique de disponibilité vérifiable.

La même méthode évite l’exagération. Une branche échouée n’invalide pas automatiquement les branches non liées. Un point de publication délégué indisponible ne devrait pas être rapporté comme preuve que chaque objet sous une ancre de confiance régionale a disparu. Les résultats doivent être limités à l’autorité, aux objets et aux validateurs affectés. Des étiquettes trop larges obscurcissent à la fois l’ingénierie et la responsabilité.

La mesure sémantique empêche également l’erreur inverse: traiter un point d’accès joignable comme un référentiel sain alors que les champs temporels ou la cohérence des objets ont déjà échoué. Dans le RPKI, les contrôles d’intégrité font partie de la disponibilité parce qu’un fichier sur lequel on ne peut pas se reposer en toute sécurité n’est pas le service promis.

L’interruption du JPNIC en 2020 montre pourquoi le temps d’arrêt écoulé n’est pas l’impact

Le JPNIC a rapporté que son ROAWeb et son référentiel RPKI étaient indisponibles du 15 mai à 23h29 au 16 mai 2020 à 10h01, heure du Japon, après une panne de courant liée au matériel. Les utilisateurs ne pouvaient pas créer ou supprimer de ROA, et les parties extérieures ne pouvaient pas télécharger les certificats, ROA et autres fichiers. C’était manifestement une interruption de service.

Pourtant, le JPNIC a également rapporté que les résultats de validation basés sur les ROA précédemment téléchargés n’avaient pas changé parce que l’expiration des certificats et les valeurs nextUpdate de la CRL et du manifeste n’avaient pas été dépassées. C’est la distinction qu’un engagement de service externe devrait préserver. Le point de publication a échoué pendant environ dix heures et demie, mais la fonction de validation en cache décrite dans l’avis a continué pour les objets et les utilisateurs dans les conditions indiquées.

L’événement avait quand même de l’importance. Les détenteurs ont temporairement perdu la capacité d’effectuer des changements. Une nouvelle autorisation ou révocation nécessaire ne pouvait pas être effectuée. Les validateurs sans le cache antérieur pertinent, ou avec une condition locale différente, pourraient ne pas avoir bénéficié de la même continuité. L’avis public n’a pas établi l’état de chaque partie utilisatrice ni la joignabilité de chaque route. Il a établi une affirmation limitée, techniquement significative, sur le contenu publié inchangé et les durées de fraîcheur non épuisées.

C’est mieux que de qualifier l’événement d’inoffensif ou de catastrophique. Une métrique bien conçue rapporterait une indisponibilité séparée pour les actions de gestion et les récupérations de publication, puis un changement nul observé de la sortie validée parmi les états de cache testés. Elle divulguerait les sondes, les branches d’objets et les validateurs utilisés pour parvenir à cette conclusion.

La leçon est positive. Le temps cryptographique et la mise en cache peuvent absorber une défaillance de référentiel comme prévu. La politique devrait récompenser cette résilience tout en enregistrant le service de changement refusé. Un fournisseur ne devrait pas perdre de crédit de disponibilité pour la continuité de routage, ni recevoir un crédit complet alors que les détenteurs ne pouvaient pas émettre une mise à jour nécessaire.

L’événement de 2019 d’APNIC montre pourquoi chaque protocole d’accès a besoin de son propre résultat

L’annonce de service d’APNIC pour le 13 décembre 2019 décrit une panne partielle de vingt minutes du RPKI. L’état du référentiel rsync était incomplet et un manifeste obsolète et révoqué a été publié, ce qui a rendu un certain nombre de certificats et de ROA invalides. Les validateurs utilisant le RRDP n’ont pas été affectés et ont continué à voir une validité complète.

Un incident a donc produit deux réalités externes matériellement différentes. Un moniteur qui ne testait que le RRDP aurait déclaré un succès. Un moniteur qui ne testait que rsync aurait constaté un échec sémantique. Un agrégat au niveau du serveur aurait pu moyenner les deux en un pourcentage rassurant tout en cachant que les utilisateurs d’une méthode standardisée recevaient une vue inutilisable.

La diversité des protocoles ne peut fournir de résilience que si les mesures conservent la distinction. Les indicateurs pertinents incluent la récupération de notification RRDP, l’intégrité des snapshots et des deltas, la progression de session et de série, la joignabilité rsync, l’exhaustivité de l’arborescence et le fait que le basculement ait eu lieu lorsque la méthode préférée a échoué. Un fournisseur devrait également divulguer si les deux méthodes partagent une origine, un système de stockage, un chemin réseau ou un processus de mise à jour, car des méthodes d’accès nominalement séparées peuvent avoir un mode de défaillance commun.

Le comportement de la partie utilisatrice appartient au compte rendu. La RFC 8182 autorise des mécanismes d’accès alternatifs lorsque le RRDP a des problèmes, mais un basculement configuré ou implémenté n’est pas garanti de fonctionner dans chaque déploiement. L’étude de 2020 sur les parties utilisatrices a trouvé un comportement de récupération incohérent dans ses conditions expérimentales. Ces résultats provenaient d’un ensemble limité d’autorités de certification et de tests observés; ils ne constituent pas un dénominateur pour tous les validateurs actuels.

Ils montrent pourquoi les opérateurs de publication devraient tester le comportement réel des clients plutôt que de le déduire de la conception du protocole.

Un engagement externe ne devrait jamais publier un seul chiffre de disponibilité RPKI sans une ventilation par protocole. Si une méthode fournit une vue valide complète et qu’une autre non, le service est résilient pour certains utilisateurs et dégradé pour d’autres. Les deux faits appartiennent au titre.

La défaillance de 2020 du RIPE NCC montre le danger d’un silence de publication

En février 2020, le RIPE NCC a rapporté qu’un problème de disque avait empêché les ROA nouvellement créés, modifiés ou supprimés d’atteindre son serveur de publication. L’avis a identifié 176 changements de ce type. Les informations affectées étaient conservées ailleurs, mais la publication n’a pas eu lieu et le disque n’a pas signalé de problème qui aurait alerté les ingénieurs.

C’était déjà une panne avant l’expiration de tout objet cryptographique. L’action côté détenteur et l’état visible de l’extérieur avaient divergé. Un utilisateur pouvait raisonnablement croire qu’un changement avait été accepté alors que les parties utilisatrices continuaient à récupérer l’ancien état. Le service a échoué au niveau de la confirmation de publication même si les fichiers étaient toujours servis.

L’événement a ensuite franchi une deuxième frontière. Le RIPE NCC a rapporté que la CRL avait expiré, après quoi les objets sous-jacents ont également expiré. La condition anormale est apparue différemment selon le logiciel de la partie utilisatrice. La réparation a nécessité plus que la résolution du problème de disque; l’organisation a finalement effectué un roulement complet de la clé de l’autorité de certification avant la résolution.

Le temps de fonctionnement traditionnel manque à la fois la phase silencieuse et la falaise sémantique. Un test reproductible de l’extérieur aurait comparé une référence de changement accepté signée ou autrement vérifiable avec la publication observée, suivi la marge de fraîcheur de la CRL et déclenché une alarme lorsque la vue du référentiel n’avançait plus. Des validateurs indépendants montreraient alors comment la branche expirée affecte la sortie sous des versions nommées.

L’incident démontre également pourquoi la découverte d’état fait partie de la qualité de service. La défaillance a commencé un samedi, la CRL est devenue obsolète le dimanche et l’organisation a dit avoir été notifiée le lundi. Un référentiel peut être surveillé en continu et être pourtant opérationnellement aveugle si ses contrôles ne vérifient pas que le nouvel état autoritaire est présent à l’extérieur.

La politique devrait demander non seulement la rapidité avec laquelle les ingénieurs ont réparé un événement connu, mais combien de temps le service a été erroné avant que quiconque le sache. Le temps moyen de détection externe est un indicateur RPKI de premier ordre.

L’incident de 2021 du RIPE NCC montre que l’exhaustivité peut échouer pour seulement certains validateurs

Le 7 janvier 2021, un transfert de ressources sortant a conduit le système du RIPE NCC à publier un certificat parent mis à jour avant le certificat enfant associé. Pendant l’intervalle incohérent, l’enfant revendiquait des ressources qui n’étaient plus présentes sur le parent. L’organisation a rapporté que les implémentations plus anciennes de la partie utilisatrice utilisant une interprétation stricte du manifeste rejetaient tous les certificats listés sur le manifeste lorsqu’une entrée était invalide.

Le même état publié a donc produit des résultats différents selon la version du logiciel. Le RIPE NCC a estimé à partir des journaux d’accès que 327 instances de partie utilisatrice étaient affectées et a averti que l’incident aurait pu entraîner des pannes. Il n’a pas prétendu que 327 réseaux avaient perdu la joignabilité, encore moins que chaque route sous l’ancre de confiance avait échoué. Cette retenue est importante: un nombre d’instances n’est pas un nombre de réseaux, et les certificats rejetés ne sont pas un dénominateur universel d’impact client.

L’événement expose une faiblesse dans les rapports de politique qui utilisent un seul validateur de référence. La conformité évolue. Les implémentations interprètent différemment les cas difficiles, les bogues sont corrigés et les opérateurs mettent à jour à des vitesses différentes. Un référentiel peut réussir avec la plus récente implémentation tout en créant des conséquences graves pour une population plus ancienne déployée.

L’assurance externe devrait maintenir un panel de compatibilité divulgué des validateurs pris en charge et matériellement déployés. Elle devrait enregistrer les différences de sortie au niveau de la branche de certification et de la charge utile validée. Le panel n’est pas un vote sur la conformité aux normes; une implémentation non conforme devrait être identifiée comme telle. C’est une mesure de l’exposition opérationnelle prévisible pendant que les mises à jour se propagent.

Les remèdes proposés par le RIPE NCC pointent également vers la bonne métrique. Il a recherché une publication atomique et des fenêtres d’incohérence plus courtes. L’objectif de service devrait mesurer l’atomicité observée de l’extérieur: aucune sonde ne devrait récupérer un état parent et un état enfant qui ne peuvent pas être validés ensemble. C’est plus significatif que de mesurer la rapidité avec laquelle deux tâches de mise à jour internes se sont terminées.

L’événement de 2022 du JPNIC montre la conversion retardée de Valid à NotFound

L’avis de février 2022 du JPNIC a rapporté qu’un journal d’accès croissant a rempli le disque du serveur de référentiel entre le 26 janvier et le 2 février. Le processus de publication ne pouvait pas mettre à jour les champs nextUpdate dans les CRL ou les manifestes. Une fois ces champs dépassés, les ROA associés ne pouvaient plus être validés par les clients, et les routes qu’ils couvraient étaient détectées comme NotFound.

Cette séquence est importante. Le service n’a pas nécessairement déplacé les routes directement de Valid à Invalid. Il a supprimé les preuves d’autorisation utilisables, produisant NotFound pour la vue de validation affectée. De nombreuses politiques opérationnelles acceptent NotFound, souvent avec une préférence différente de Valid. La conséquence de sécurité peut être une perte de protection plutôt qu’une perte immédiate de joignabilité. Un rapport qui qualifie chaque ROA disparu de panne de routage confond ces résultats.

L’événement a duré assez longtemps pour que la continuité du cache s’épuise. Une mesure de disponibilité basée uniquement sur une connexion TCP réussie aurait été particulièrement trompeuse si le serveur répondait encore alors que la fraîcheur de publication s’était arrêtée. L’alarme utile était le temps décroissant jusqu’au nextUpdate combiné à l’absence d’observation d’un nouveau manifeste et d’une nouvelle CRL.

Le JPNIC a également dit qu’un utilisateur compétent avait signalé le problème. Ce fait soutient une réforme institutionnelle: des moniteurs indépendants devraient avoir un canal défini, authentifié et doté de personnel en continu vers les opérations de référentiel. La découverte externe ne devrait pas dépendre du fait qu’un spécialiste remarque une anomalie et trouve le bon contact.

Un rapport pour cette classe d’événement devrait quantifier, dans l’ensemble mesuré, quand chaque ROA affecté a cessé de produire une charge utile validée, quelles routes sont passées de Valid à NotFound à des points d’observation BGP sélectionnés, et si des opérateurs ont signalé des conséquences de politique ou pour les clients. Si les données client ne sont pas disponibles, elles doivent rester indisponibles plutôt que d’être inférées du nombre de ROA.

La dégradation de 2022 d’ARIN montre la valeur et les limites de la redondance de transport

ARIN a rapporté une dégradation de service RRDP de quatre-vingt-dix minutes le 11 août 2022 après qu’un changement de configuration a installé des certificats discordants sur certains nœuds de service. L’organisation a retiré les nœuds affectés de la rotation DNS, restauré les certificats correspondants et redémarré la génération du référentiel. Son service rsync est resté fonctionnel tout au long, tandis que la publication de six ROA a été retardée.

C’est un cas utile de résilience partielle. La méthode de publication alternative est restée disponible, et le fournisseur a donné un nombre limité de changements retardés. Mais il ne s’ensuit pas que chaque partie utilisatrice a obtenu ces changements par basculement. Les opérateurs peuvent préférer le RRDP, appliquer des calendriers de nouvelles tentatives, ne pas avoir de basculement fonctionnel ou avoir des chemins réseau qui atteignent un service différemment d’un autre.

Le bon tableau de bord montrerait la récupération réussie par protocole et point d’observation, les tentatives et résultats de basculement, le délai de publication pour les six ROA affectés et la convergence de sortie validée après réparation. Il distinguerait également l’état existant du référentiel public de la pause temporaire dans la génération de nouvel état. La disponibilité pour un opérateur avec un cache actuel n’était pas identique à la disponibilité pour un détenteur attendant l’un des ROA retardés.

La redondance ne mérite de crédit que lorsqu’elle est exercée indépendamment. Deux URL servies par le même pool de nœuds mal configurés ne sont pas deux contrôles. Le RRDP et rsync avec des modes de défaillance séparés peuvent améliorer la continuité, mais le fournisseur devrait prouver que les validateurs peuvent utiliser le chemin survivant avant l’expiration de la fraîcheur. Des exercices planifiés, comme un retrait contrôlé d’une méthode, peuvent révéler si le basculement fonctionne sans attendre une urgence.

C’est là que les tests externes surpassent les diagrammes architecturaux. Ils montrent le chemin que les clients ont effectivement emprunté, la vue qu’ils ont effectivement validée et le moment où les assertions retardées sont devenues utiles.

Un engagement de service de référentiel nécessite quatre objectifs de service distincts

Le premier objectif est la disponibilité de la récupération. Depuis des points d’observation indépendants, une partie utilisatrice peut-elle résoudre le nom du référentiel, se connecter via la famille d’adresses prise en charge, négocier le transport requis et récupérer le matériel RRDP ou rsync? Les résultats doivent être divisés par protocole, version IP, région et fournisseur de réseau. Une moyenne mensuelle ne devrait pas cacher une défaillance complète pour une combinaison.

Le deuxième est la disponibilité sémantique. La vue récupérée contient-elle un manifeste valide actuel, les objets listés avec des hachages correspondants, une CRL utilisable et un chemin de certification valide? Le validateur peut-il produire l’ensemble de charges utiles attendu sans rejeter une branche non liée? Cet objectif convertit la correction cryptographique en indicateur de service.

Le troisième est la ponctualité de la publication. Après qu’une action autorisée est acceptée, combien de temps faut-il pour que des sondes indépendantes observent le nouvel objet et produisent le changement de charge utile correspondant? Cet objectif couvre la création, la modification, la révocation, le transfert et la correction d’urgence. Il nécessite une référence préservant la confidentialité qui permet à un auditeur de faire correspondre l’action à la publication sans exposer les secrets de compte.

Le quatrième est la convergence de récupération. Après une réparation, combien de temps faut-il pour qu’un panel défini de validateurs indépendants atteigne la même vue actuelle et que les systèmes de routage la reçoivent? Un référentiel qui est réparé à l’origine mais reste obsolète aux nœuds de distribution n’a pas entièrement récupéré. Pas plus qu’un référentiel dont les fichiers sont actuels alors que les sessions RTR fournissent encore un ancien ensemble de charges utiles.

Chaque objectif a besoin d’un dénominateur explicite. La récupération peut utiliser des tentatives de sondes planifiées. La disponibilité sémantique peut utiliser les branches de certification censées être actuelles. La ponctualité de la publication peut utiliser les actions acceptées éligibles à une publication immédiate. La récupération peut utiliser des sondes actives avec un état pré-incident connu. Mélanger ces populations produit un pourcentage attrayant mais dénué de sens.

Le modèle à quatre objectifs soutient également une attribution équitable. Un référentiel peut satisfaire à la récupération tout en échouant à l’intégrité sémantique, ou satisfaire aux deux alors qu’un changement demandé par un détenteur reste erroné. Les opérateurs et les organismes de surveillance peuvent voir exactement quelle promesse a échoué.

Les sondes indépendantes doivent être assez diverses pour défier les hypothèses du fournisseur

Un réseau de mesure neutre devrait inclure des sondes dans plusieurs régions et systèmes autonomes, en utilisant à la fois IPv4 et IPv6 là où c’est offert. Il devrait éviter de concentrer toutes les sondes dans un seul cloud dont le chemin ou le résolveur peut échouer comme une unité. Le nombre et l’emplacement ne doivent pas prétendre représenter chaque internaute; ils doivent être divulgués pour que les lecteurs comprennent la population observée.

Chaque sonde devrait utiliser une horloge contrôlée, enregistrer les réponses DNS, l’adresse de destination, le chronométrage du transport, la réponse du protocole, les hachages d’objets, le nom et la version du validateur, le matériel d’ancre de confiance, l’état du cache et le condensé final de la charge utile validée. Les détails opérationnels sensibles peuvent être protégés, mais suffisamment de preuves devraient être publiées pour qu’une autre partie qualifiée puisse répéter le test.

Les modes cache frais et cache chaud sont tous deux nécessaires. Un validateur frais montre si une nouvelle partie utilisatrice peut construire la vue. Un validateur chaud montre si un opérateur établi peut continuer à travers une panne. Tester uniquement des instances fraîches exagère la perte immédiate; tester uniquement des instances chaudes cache le risque d’intégration et d’épuisement du cache.

Les sondes devraient récupérer à des intervalles réalistes tout en respectant la capacité du référentiel. Un système de mesure qui submerge le service crée la condition qu’il prétend observer. Les fournisseurs et les chercheurs peuvent convenir de limites de taux et d’une identification dédiée sans donner au fournisseur un chemin qui contourne la distribution ordinaire.

Les fausses alarmes nécessitent une gestion disciplinée. Une défaillance de sonde unique peut provenir de son résolveur, de son horloge locale, du disque, du validateur ou du chemin amont. La déclaration d’incident devrait utiliser une règle pré-annoncée, comme un échec sémantique sur un nombre minimum de réseaux indépendants ou une confirmation du fournisseur. Les défaillances localisées appartiennent toujours aux données, mais toutes ne deviennent pas un avis global.

La norme devrait publier le code de sonde, les vecteurs de test et les définitions de résultats. La reproductibilité vient d’une méthode partagée et d’observations signées, pas du prestige institutionnel.

La marge de fraîcheur est l’indicateur de risque qu’un tableau de bord vert ne peut pas fournir

À tout moment, une branche de référentiel a un intervalle restant avant qu’un manifeste ou une CRL pertinente ne devienne obsolète ou qu’un certificat n’expire. Cet intervalle est sa marge de fraîcheur. Il convertit un problème de récupération ordinaire en une mesure de risque opérationnel.

Supposons que des sondes extérieures échouent à récupérer une branche alors que son manifeste actuel a encore dix-huit heures. L’événement mérite l’attention, mais les validateurs en cache ont de la marge pour continuer. Si la marge tombe à une heure sans récupération, la même condition de transport devient urgente. Si une nouvelle révocation requise est également en attente, le risque de sécurité peut déjà être élevé malgré des objets anciens non expirés.

Le fournisseur devrait rapporter la marge minimale, médiane et la distribution de la marge sur les branches affectées, pas seulement le minimum à l’échelle du référentiel. Une autorité déléguée avec un intervalle inhabituellement court ne devrait pas être utilisée pour laisser entendre que chaque branche est proche de la défaillance. De même, un certificat parent de longue durée ne devrait pas masquer un manifeste enfant proche de l’obsolescence.

La marge soutient une alerte de taux de consommation. Si un événement consomme la marge de fraîcheur plus vite que la confiance de réparation n’augmente, l’escalade devrait avoir lieu avant l’expiration. Cela est analogue à la gestion d’une réserve: le service n’a pas encore échoué sémantiquement, mais sa capacité à absorber le retard diminue.

Le timing des objets n’est pas le risque entier. Un détenteur attendant une nouvelle autorisation peut avoir une marge pratique nulle parce qu’une migration de réseau est en cours. Le dossier d’incident devrait permettre aux détenteurs affectés de marquer un changement attendu urgent, avec preuves et examen, sans exposer publiquement des plans commerciaux confidentiels.

Un rapport de politique qui publie la marge explique pourquoi une panne de dix heures n’a eu aucun changement de validation tandis qu’une autre défaillance de publication de plusieurs jours en a eu un. Il donne aux conseils d’administration et aux opérateurs un langage commun pour l’urgence que le temps de fonctionnement brut ne peut pas fournir.

L’attribution nécessite une séquence partagée de l’action autorisée à l’effet sur la route

Lorsqu’un incident RPKI devient contentieux, chaque entité ne voit qu’une partie de la séquence. Le détenteur sait ce qu’il a demandé. Le service de certification sait ce qu’il a accepté et signé. Le référentiel sait ce qu’il a servi. La partie utilisatrice sait ce qu’elle a récupéré et rejeté. Le routeur sait quel ensemble de charges utiles et quelle politique il a utilisés. Le client sait qu’un service est devenu injoignable. Sans temps corrélés, la responsabilité devient une affirmation.

Un dossier d’incident commun devrait attribuer une référence stable à chaque action matérielle et enregistrer six jalons: autorisation acceptée, objet produit, objet publié à l’extérieur, objet récupéré et validé, charge utile livrée à un routeur, et décision de routage pertinente observée. Chaque jalon devrait identifier l’institution responsable et la source de l’horloge. Les rapports publics peuvent hacher ou agréger les références sensibles tout en préservant la séquence pour un examen indépendant.

Cette méthode distingue un objet erroné d’un objet indisponible. Si le détenteur a demandé une longueur maximale erronée et que le service l’a fidèlement publiée, la responsabilité diffère d’un défaut de code qui a produit un certificat incohérent avec l’état d’enregistrement. Si le référentiel a publié un objet correct mais qu’un validateur obsolète a rejeté une branche plus large, le fournisseur a encore des devoirs de compatibilité et de communication, mais la cause technique directe est différente.

L’attribution a également besoin de tests contrefactuels. Les enquêteurs peuvent rejouer l’ensemble d’objets observé à travers des validateurs nommés et comparer les charges utiles résultantes, puis appliquer la politique de route déclarée de l’opérateur aux annonces BGP capturées. Cela ne reconstruit pas chaque paquet ou transaction perdue. Cela teste si la chaîne alléguée est techniquement possible et où l’état a d’abord divergé.

Aucune institution ne devrait contrôler la seule copie de ces preuves. Les fournisseurs peuvent signer les enregistrements de jalons; les moniteurs neutres peuvent signer les observations externes; les opérateurs peuvent conserver l’historique RTR et de politique de routage. Des preuves partagées rendent possible une responsabilité étroite, ce qui est plus juste que le blâme généralisé et l’immunité générale.

L’impact sur le routage doit être mesuré, pas présumé d’après le nombre d’objets

Un incident de référentiel peut changer la sécurité du routage sans changer la joignabilité. Lorsqu’un ROA valide disparaît de la vue utilisable, une annonce peut devenir NotFound et rester acceptée. La protection contre une origine non autorisée peut s’affaiblir, mais la route légitime peut encore fonctionner. Lorsqu’un certificat incohérent fait disparaître une autorisation valide alors qu’un autre ROA couvrant reste, l’état de la route peut ne pas changer du tout.

Lorsqu’un ROA erroné rend une annonce légitime Invalid, les opérateurs qui rejettent les routes Invalid peuvent retirer la joignabilité tandis que d’autres continuent de l’accepter.

L’étude d’impact commence donc par les différences de charge utile validée. Quels tuples de préfixe, longueur maximale et origine ont été ajoutés ou supprimés sous chaque validateur? L’étape suivante joint ces différences aux annonces BGP observées aux collecteurs nommés ou aux flux des opérateurs. L’étape technique finale applique les hypothèses de politique divulguées ou, lorsqu’elles sont disponibles, la politique réelle de l’opérateur.

L’impact client nécessite des preuves séparées: alarmes, perte de trafic, sessions échouées, rapports de support ou violations de niveau de service. Les collecteurs de routes ne voient pas chaque chemin d’appairage privé, et un changement d’état de validation ne révèle pas combien de trafic l’utilisait. Les rapports devraient éviter de traduire les préfixes en utilisateurs ou en revenus sans données fournies par les réseaux affectés.

La même discipline protège les fournisseurs contre des affirmations gonflées. Un incident qui a rendu une branche temporairement NotFound ne devrait pas être décrit comme la preuve que l’Internet régional est hors ligne. Elle protège aussi les opérateurs contre la minimisation. Si plusieurs réseaux indépendants ont enregistré le rejet d’une route Invalid et que le trafic a chuté en même temps, une déclaration selon laquelle l’hôte du référentiel restait joignable est hors de propos.

Le produit approprié est un tableau d’impact stratifié: objets de publication affectés, charges utiles validées affectées, annonces observées affectées, réseaux avec une réponse politique attestée, et clients ou services avec une conséquence documentée. Les cellules inconnues restent inconnues.

Les dénominateurs doivent être locaux, divulgués et résistants à la réutilisation promotionnelle

La mesure RPKI attire des chiffres impressionnants parce que le système est d’envergure mondiale. Mais aucun observateur public n’a un recensement complet des instances de partie utilisatrice, des versions logicielles, des historiques de cache, des politiques de routage, des chemins BGP privés ou des effets sur les clients finaux. Un engagement de service crédible ne fabrique pas ce dénominateur.

Chaque taux devrait porter sa population observée. La disponibilité des sondes est le nombre de contrôles réussis divisé par les contrôles planifiés de l’ensemble de sondes nommé. La compatibilité du validateur est le nombre de sorties réussies divisé par les versions et les cas de test du panel. La ponctualité de la publication est le nombre d’actions observées dans les délais divisé par les actions acceptées éligibles dans la période de rapport. L’effet sur les routes est le nombre d’annonces changées divisé par les annonces visibles aux collecteurs nommés. Aucun n’est « le pourcentage de l’Internet affecté. »

L’étude de 2020 sur les parties utilisatrices de l’IMC est précieuse précisément quand elle est bornée. Elle a observé des clients atteignant trois autorités de certification et a utilisé des conditions contrôlées pour exposer des récupérations incohérentes. Les proportions rapportées décrivent cette expérience, pas chaque opérateur actuel ou chaque version future. Les rapports de politique devraient préserver ces limites lorsqu’ils citent des recherches.

Les décomptes spécifiques à un incident nécessitent une retenue similaire. L’estimation du RIPE NCC de 327 instances de partie utilisatrice affectées en janvier 2021 provenait de journaux d’accès et d’un comportement logiciel défini. Les instances peuvent partager un réseau, desservir plusieurs réseaux ou être des systèmes de test. Le nombre est une preuve d’exposition opérationnelle, pas un décompte d’organisations déconnectées.

Une bonne mesure peut quand même être percutante. Elle peut dire que chaque sonde dans cinq réseaux indépendants a rejeté la même branche, que les trois validateurs actuels testés ont perdu les mêmes charges utiles, ou qu’une route nommée a disparu à deux collecteurs. La précision renforce la responsabilité parce que l’affirmation peut être reproduite et contestée.

Les rapports d’incident devraient séparer la cause, la condition, la conséquence et la confiance

La cause est la défaillance initiale: disque plein, publication mal ordonnée, certificats discordants, perte de courant ou défaut logiciel. La condition est ce que les utilisateurs extérieurs ont rencontré: échec de récupération, manifeste obsolète, arborescence rsync incomplète, chemin de certification incohérent ou changement retardé. La conséquence est la sortie observée: suppression de charge utile, changement d’état, route rejetée ou interruption client. La confiance indique avec quelle force les preuves les relient.

Beaucoup d’avis effondrent ces couches en une seule phrase. Cela crée de la confusion lorsque des preuves ultérieures changent. Un fournisseur peut connaître la condition avant de connaître la cause. Un opérateur peut prouver une conséquence sur une route avant que le fournisseur ne reproduise le chemin externe. Rapporter les couches séparément permet au compte rendu public de s’améliorer sans effacer l’observation originale.

L’avis devrait inclure des définitions exactes de début et de fin. Le début peut être le premier échec de vérification sémantique externe, pas le moment où un ingénieur a ouvert un incident. La fin peut exiger une validation réussie par un quorum de sondes et la publication des changements retardés, pas simplement le redémarrage d’un processus. Les temps de détection, d’accusé de réception, d’atténuation et de convergence complète devraient tous être visibles.

La confiance peut être graduée selon les preuves: confirmée par rejeu d’objet signé, observée par plusieurs validateurs indépendants, rapportée par un opérateur affecté, ou inférée du timing. Ce n’est pas un substitut aux faits. Cela indique aux lecteurs où une enquête supplémentaire est nécessaire.

Le fournisseur devrait également publier ce qui n’a pas été mesuré. Si aucune donnée de perte client n’a été collectée, dites-le. Si rsync a été testé mais que les journaux RRDP étaient indisponibles, indiquez la lacune. Si un collecteur BGP n’a pas vu la route affectée, ne traitez pas l’absence comme une preuve d’absence d’effet.

Un rapport honnête peut être concis et contenir ces champs. Le but n’est pas la longueur bureaucratique. C’est d’empêcher une affirmation étroite de temps de fonctionnement d’évincer les preuves dont les opérateurs ont besoin.

Les crédits de service seuls sont un mauvais remède pour l’interruption de la sécurité de routage

La publication RPKI est souvent incluse dans l’adhésion ou le service d’enregistrement plutôt que vendue comme un service public à prix séparé. Un crédit conventionnel sur les frais peut donc être trivial, difficile à calculer ou indisponible pour les parties utilisatrices et les clients en aval. Les remèdes les plus précieux sont opérationnels.

D’abord vient la correction rapide. Les fournisseurs ont besoin d’un canal doté de personnel en continu pour signaler un objet erroné, manquant ou obsolète, avec une authentification qui ne dépend pas entièrement du portail potentiellement affecté. La cible de réponse devrait varier selon la marge de fraîcheur et le risque de routage démontré.

Deuxièmement vient la préservation des preuves. Les versions d’objets, les temps de publication, l’état des méthodes d’accès, les résultats de validation et les autorisations de changement devraient être conservés assez longtemps pour l’enquête et les réclamations légitimes. Une réparation qui écrase les preuves laisse les institutions se disputer de mémoire.

Troisièmement vient la communication portable. Un avis d’incident signé devrait identifier les branches de certification affectées et les condensés d’objets afin que les validateurs et opérateurs puissent déterminer l’exposition sans faire confiance à des captures d’écran ou des rumeurs. Les mises à jour devraient indiquer si les caches existants restent utilisables et si un changement demandé est retardé.

Quatrièmement vient un examen indépendant pour les événements graves ou répétés. L’examinateur devrait tester les objectifs externes, examiner les contrôles du fournisseur et publier les conclusions dans les limites de sécurité. Un compte rendu rédigé par le fournisseur est nécessaire mais ne peut pas être la seule assurance lorsque la propre surveillance du fournisseur a manqué la défaillance.

Les remèdes financiers peuvent encore compter lorsqu’une perte réelle et une responsabilité légale sont établies. Leur conception relève de la responsabilité, de la causalité et du droit applicable. L’engagement de service ne devrait pas promettre une compensation impossible, mais des frais bas ou nuls ne devraient pas non plus être utilisés pour nier le devoir de publier avec exactitude et de réparer rapidement.

Les opérateurs ont aussi des devoirs de continuité mesurables

La responsabilité externe n’est pas un dispositif pour transférer tous les risques RPKI vers un référentiel. Les opérateurs de réseau choisissent des validateurs, des intervalles de rafraîchissement, la redondance, la surveillance et la politique de routage. Les détenteurs de ressources choisissent le contenu et le moment des ROA. Ces décisions affectent matériellement les conséquences.

Un opérateur devrait exécuter un logiciel de partie utilisatrice pris en charge, surveiller la synchronisation réussie du référentiel, conserver au moins le comportement de cache recommandé par les normes applicables et tester la redondance RTR. Il devrait savoir comment ses routeurs se comportent lorsque les charges utiles disparaissent ou que les validateurs deviennent indisponibles. Un deuxième validateur qui partage le même résolveur, la même alimentation électrique et le même défaut logiciel n’est pas une redondance robuste.

Les détenteurs de ressources devraient comparer les ROA avec les annonces prévues avant les changements de réseau, éviter des longueurs maximales inutilement permissives et vérifier la publication externe après la création ou le transfert. Ils devraient maintenir des contacts d’urgence et comprendre quelle partie contrôle les clés dans les arrangements hébergés et délégués.

Ces devoirs devraient apparaître dans l’analyse d’incident sans devenir une excuse générale pour la défaillance du référentiel. Si un opérateur a exécuté un logiciel obsolète qui a rejeté plus que ce que les normes exigent, c’est pertinent. Si un référentiel a publié un état incohérent, c’est aussi pertinent. Plusieurs causes peuvent contribuer à une seule perte.

Des exercices partagés peuvent améliorer les deux côtés. Un fournisseur peut annoncer une fenêtre de test dans laquelle une méthode d’accès est retirée tandis que les opérateurs vérifient le basculement. Des branches de certification synthétiques peuvent tester les alarmes d’expiration et les mises à jour atomiques sans mettre en danger les routes de production. Les opérateurs peuvent rapporter des résultats de convergence anonymisés.

Le but est une preuve réciproque. Les fournisseurs démontrent la qualité de la publication externe; les opérateurs démontrent une dépendance prudente. Lorsque les deux sont mesurés, l’incertitude résiduelle devient visible au lieu d’être attribuée par contrat ou rhétorique seulement.

NRS peut faire de l’assurance externe un service de légitimité

NRS soutient que les registres de numéros devraient maintenir des enregistrements précis, respecter le rôle opérationnel des réseaux et rester bornés par une fonction de tenue de livres. Le RPKI complique cette philosophie parce que les actions de certificat et de référentiel peuvent influencer les annonces de routage que les opérateurs acceptent. La réponse appropriée n’est pas de rejeter le RPKI. C’est de rendre le pouvoir ajouté observable et responsable.

NRS pourrait réunir détenteurs, opérateurs, ingénieurs de registre, mainteneurs de partie utilisatrice et chercheurs autour d’un profil d’assurance de référentiel commun. Le profil définirait les quatre objectifs de service, les champs minimaux d’incident, les tests spécifiques au protocole, le rapport de fraîcheur et les jalons d’attribution décrits ici. La participation pourrait commencer volontairement, les résultats étant publiés par service et région.

Il pourrait également opérer ou commissionner des sondes neutres. L’indépendance exigerait un financement divulgué, un code de mesure ouvert, des règles de conflit et plusieurs réseaux d’hébergement. NRS ne devrait pas certifier son propre plaidoyer par assertion. Il devrait publier des preuves que tout opérateur, registre ou chercheur peut reproduire.

Un examen annuel utile comparerait chaque référentiel entité avec ses propres objectifs publiés, sans classer les régions par un score universel grossier. Il pourrait identifier des défaillances partielles répétées, des basculements non testés, une détection externe lente ou des preuves de récupération faibles. Les fournisseurs auraient le droit de corriger les erreurs factuelles et de joindre des explications, tandis que les observations sous-jacentes resteraient disponibles.

C’est un rôle institutionnel positif parce qu’il récompense la bonne performance. L’événement JPNIC de 2020, par exemple, pourrait recevoir un crédit pour la continuité de validation en cache tout en enregistrant l’indisponibilité de gestion et de récupération. L’événement APNIC de 2019 pourrait montrer la résilience RRDP et l’échec rsync séparément. La nuance remplacerait à la fois l’alarmisme et l’autosatisfaction.

NRS traduirait ainsi une demande générale de responsabilité des registres en un bien public pratique: des preuves comparables quant à savoir si les assertions critiques de sécurité de routage sont utilisables à l’extérieur.

Les achats et les politiques publiques devraient demander des preuves qui survivent au désaccord

Les gouvernements, les opérateurs d’infrastructures critiques et les grands réseaux dépendent de plus en plus du RPKI sans nécessairement opérer les couches de certification et de publication auxquelles ils font confiance. Leurs questions d’achat devraient aller au-delà du fait qu’un fournisseur revendique une haute disponibilité.

Ils devraient demander où sont hébergés le RRDP et rsync, si leurs domaines de défaillance diffèrent, à quelle fréquence une validation externe complète est exécutée, quelle marge de fraîcheur déclenche l’escalade, comment les changements acceptés sont appariés à la publication, quelles versions de validateur sont testées, comment les incidents sont annoncés et comment les preuves sont préservées. Ils devraient demander des résultats récents d’exercices et des exemples de convergence de récupération.

Les politiques publiques devraient résister à l’imposition d’une réponse de route universelle à un événement de référentiel. Les opérateurs ont des positions de risque différentes, et le comportement de défaillance ouverte a des avantages de continuité aussi bien que des coûts de sécurité. L’exigence la plus constructive est la transparence: divulguer la vue de validation, la politique locale et le plan de basculement pour les systèmes dont l’interruption affecterait les services publics.

La surveillance devrait également distinguer le référentiel d’un registre régional des points de publication délégués en dessous. Une ancre de confiance peut être joignable alors qu’une autorité déléguée échoue. Une politique qui attribue chaque panne déléguée au parent découragera la délégation sans améliorer la mesure. Le chemin de certification identifie où la défaillance s’est produite; la gouvernance devrait suivre cette preuve.

Les assurances et les examens des risques par les conseils peuvent utiliser le même modèle. Ils peuvent examiner si une organisation connaît sa marge de cache, dispose de validateurs indépendants, conserve l’historique de politique de route et peut joindre le contact de référentiel approprié. Cela transforme le RPKI d’un contrôle abstrait de cybersécurité en une dépendance de continuité auditable.

La norme ne doit pas garantir un routage ininterrompu. Elle devrait garantir une réponse disciplinée à une question plus étroite: qu’est-ce qui était disponible à l’extérieur, quand a-t-il cessé d’être utilisable, qui contrôlait l’étape défaillante, et quelle conséquence de routage a été effectivement observée?

La panne de référentiel que les rapports de politique manquent est celle cachée entre la publication et la dépendance

Les référentiels RPKI ont déjà démontré que les défaillances ne rentrent pas dans un seul compteur de temps de fonctionnement. Le matériel peut arrêter l’accès sans épuiser la validité en cache. Un manifeste obsolète peut endommager rsync tandis que le RRDP reste cohérent. Un disque peut bloquer silencieusement les changements jusqu’à ce qu’une CRL expire. Les certificats parent et enfant peuvent être individuellement authentiques mais temporairement incohérents. Un nœud de distribution peut servir des identifiants de transport discordants tandis qu’une méthode alternative reste disponible.

Ce ne sont pas des arguments contre la validation d’origine de route. Ce sont des preuves que la sécurité de routage a mûri en une infrastructure qui mérite une assurance de service mature. La cryptographie rend la falsification détectable; elle ne rend pas la publication infaillible. La mise en cache fournit la continuité; elle ne prouve pas que le nouvel état est arrivé. La politique de routage locale préserve l’autonomie de l’opérateur; elle n’élimine pas la responsabilité du référentiel.

La meilleure affirmation de disponibilité est par conséquent modeste et exacte. Un fournisseur peut dire que des sondes indépendantes nommées ont récupéré le matériel complet actuel par des méthodes indiquées, que toutes les branches de certification testées ont validé, que les actions acceptées sont devenues visibles dans les délais, que les validateurs pris en charge ont convergé après réparation et que les effets de routage observés ont été ou n’ont pas été trouvés dans une population définie. Une autre partie peut répéter les tests.

Toute affirmation plus large a besoin de plus de preuves. Un tableau de bord interne ne peut pas prouver la récupérabilité externe. Un ROA manquant ne peut pas prouver une perte client. Un collecteur BGP stable ne peut pas prouver qu’aucun réseau privé n’a été affecté. Un pourcentage global ne peut pas être construit à partir d’un échantillon non divulgué.

La légitimité du registre grandit lorsque l’institution ne demande pas au public d’accepter son temps de fonctionnement sur la foi. NRS et la communauté plus large des opérateurs peuvent aider à établir cette norme. Le référentiel devrait être jugé au point où ses assertions deviennent utilisables, avant que leurs horloges n’expirent et après que leurs conséquences soient visibles.

C’est la panne que les rapports de politique manquent habituellement: non pas le moment où une machine s’est arrêtée, mais l’intervalle pendant lequel les parties utilisatrices de l’Internet ne pouvaient plus obtenir la même déclaration opportune, cohérente et responsable d’autorité de routage.

Sources