Résumé

  • Selon Number Resource Society, un ROA associe un préfixe à un ASN d’origine autorisé, peut encadrer les annonces plus spécifiques par maxLength et doit être modifié dans le cadre d’un processus contrôlé.
  • L’état Valid, Invalid ou NotFound observé par un validateur décrit une situation de validation. Il ne prouve pas à lui seul qui a demandé ou approuvé la modification, quelles valeurs étaient prévues ni si le retrait a été achevé.
  • Un registre versionné de l’autorisation et du retrait peut relier la décision humaine à la publication RIR, aux observations des validateurs et aux actes de routage sans confondre observation et intention.

L’état « Valid » n’est pas l’historique de la décision

Le guide RPKI de Number Resource Society rappelle que l’infrastructure à clés publiques des ressources lie cryptographiquement des ressources Internet à leurs détenteurs légitimes. Une Route Origin Authorization indique quel système autonome est autorisé à annoncer un préfixe. Le champ facultatif maxLength définit jusqu’à quelle longueur des annonces plus spécifiques restent autorisées. La certification et la publication peuvent être hébergées par un RIR, ou gérées par le détenteur dans un modèle délégué.

Ce dispositif répond à une question essentielle : l’origine observée correspond-elle à une autorisation publiée ? Il ne reconstitue pas automatiquement la chaîne de décision. Un résultat présent ne dit pas qui a proposé un nouvel ASN d’origine, qui a accepté d’élargir maxLength, quelle fenêtre de changement avait été convenue, ni pourquoi un retour arrière a été déclenché.

Le guide d’audit de NRS rend l’enjeu concret. Il recommande de vérifier l’existence du ROA, l’ASN d’origine, le préfixe, la valeur de maxLength et l’état Valid, Invalid ou NotFound. Il demande aussi d’identifier les personnes capables de créer, modifier ou supprimer les ROA. Un maxLength trop large peut autoriser des routes plus spécifiques qui ne sont pas nécessaires ; un réglage trop strict peut rendre Invalid une annonce légitime.

Ces éléments sont des faits tirés des sources. Le registre proposé ici est une déduction éditoriale : il ne signifie pas que NRS l’a adopté ni qu’un ROA réel présente une anomalie.

Autoriser une version précise, pas un geste vague

Chaque modification devrait recevoir un identifiant stable. Le registre conserverait les valeurs avant et après : préfixe, ASN d’origine et maxLength. Il nommerait le détenteur responsable, le demandeur, l’approbateur, l’heure d’approbation, la fenêtre prévue et la justification. Une procédure d’urgence devrait citer la règle qui permet d’abréger le circuit normal ainsi que la personne qui en assume la responsabilité.

Les rôles doivent rester distincts. Celui qui demande une modification ne dispose pas nécessairement du pouvoir de l’approuver. Celui qui l’approuve n’utilise pas forcément le portail du RIR. L’opérateur qui active la route peut ne pas avoir le droit de modifier le ROA. Un statut final propre masque facilement ces différences.

Le périmètre négatif compte autant que le périmètre positif. Une autorisation concernant un préfixe ne doit pas s’étendre silencieusement à un autre. Le droit de changer l’ASN d’origine n’emporte pas celui d’élargir maxLength. Une permission donnée pour une migration ne doit pas devenir permanente après le retrait de l’ancien chemin.

L’empreinte cryptographique de l’objet approuvé peut relier la décision aux valeurs effectivement soumises. Elle ne prouve ni la pertinence ni la valeur juridique de la décision ; elle permet seulement de vérifier que l’objet observé est bien celui présenté à l’approbateur.

Publier, observer et activer sont trois étapes

Après l’approbation, le registre devrait consigner l’action de publication et une référence RIR faisant autorité, avec une heure d’observation. NRS recommande de conserver des enregistrements RIR datés comme preuves d’audit. Cette trace est plus solide qu’un souvenir du portail, mais elle reste une observation et non la preuve du motif de l’autorisation.

Les observations de validateurs indépendants doivent apparaître séparément, avec l’heure, le point d’observation et le logiciel ou service concerné. Des référentiels, caches et cycles de rafraîchissement différents peuvent produire un décalage temporaire. Ce décalage appelle une enquête ; il ne prouve pas automatiquement l’échec de la publication ou une faute de l’opérateur.

Un seul indicateur ne doit donc pas absorber toutes les étapes. Le registre peut distinguer : demandé, approuvé, soumis, publication observée, validation observée, route activée, retrait demandé, retrait observé, retour arrière effectué et version remplacée. Chaque transition possède son acteur ou son observateur et sa propre heure.

NotFound illustre cette prudence. L’état signifie que la vue du validateur n’a pas trouvé de ROA couvrant la route ; il ne révèle pas si cette absence est volontaire, retardée, erronée ou hors périmètre. De même, Valid confirme une correspondance dans une vue donnée, pas la persistance du mandat professionnel de la personne ayant initié le changement.

Une migration doit prévoir l’ordre du retrait

NRS indique qu’en migration, la nouvelle autorisation devrait normalement être établie et validée avant le retrait de l’ancienne route ou la suppression de l’ancien ROA. Un registre transforme ce principe de séquencement en preuve exploitable.

Avant l’exécution, il définit le préalable : quel nouveau ROA doit être vu, par quels validateurs, et quel contrôle de route doit réussir. Il désigne ensuite qui peut activer la nouvelle origine, retirer l’ancienne route, réduire ou supprimer l’ancien ROA et accuser réception de chaque étape.

Retirer ne signifie pas effacer l’historique. La version antérieure reste conservée ; un événement explique sa fin et renvoie vers le remplacement ou le retour arrière. En cas d’annulation, on peut ainsi établir que la publication initiale était autorisée à ce moment, identifier le déclencheur et montrer l’état restauré.

Le retour arrière doit être défini avant l’ouverture de la fenêtre. Des déclencheurs mesurables peuvent être un état Invalid inattendu, une propagation absente après le délai convenu, une perte de joignabilité, une différence entre valeurs approuvées et observées, ou l’impossibilité d’identifier l’opérateur responsable. « Annuler » ne suffit pas lorsque publication RPKI et retrait BGP progressent selon des horloges différentes.

Ne pas transformer les inconnues en certitudes

Les deux sources de NRS étayent la mécanique des ROA, de maxLength, des états de validation, du processus contrôlé et de l’ordre d’une migration. Elles ne désignent aucun opérateur défaillant, compte compromis, préfixe litigieux ou processus RIR fautif.

Les champs du registre constituent une recommandation de gouvernance. Il est raisonnable de penser qu’une chaîne commune facilite la reconstitution d’un changement. Il serait injustifié de conclure qu’une organisation ne possède pas de contrôle interne simplement parce que ses pages publiques ne le décrivent pas.

Pour un cas précis, des inconnues subsistent : détenteur réel de l’autorité, plateforme utilisée, durée de rafraîchissement des validateurs, portée de l’action de routage, effet juridique ou contractuel. Le registre doit les déclarer comme telles. La discipline recherchée n’ajoute pas une cérémonie à RPKI ; elle associe une autorisation cryptographique à une responsabilité humaine vérifiable et à une sortie sûre.

Sources