Export de l’état du registre : rendre récupérables les enregistrements des ressources de numérotation Internet

Un export utile permet à un autre opérateur de vérifier l’état consigné et son historique. Conserver une copie n’est qu’un début : la passation doit aussi être compréhensible et pouvoir être testée.

Lorsqu’un registre est disponible, une ressource de numérotation Internet peut sembler se résumer à une simple consultation. On interroge un préfixe IP ou un numéro de système autonome et l’on reçoit un enregistrement. Cet enregistrement est utile, mais il ne donne qu’une vue d’un état plus vaste : qui le registre reconnaissait, ce qui a changé, quels services ont été délégués, quelles autorisations de routage existaient et quels éléments de preuve étayent la réponse actuelle.

La question se complique lorsque le registre est indisponible, contesté, compromis ou en cours de remplacement. L’état légitime de la ressource peut-il encore être compris et vérifié par quelqu’un qui ne dispose ni de la base de données d’origine ni des procédures internes ?

La question de la continuité : si le système actuel du registre cesse de répondre demain, de quelles informations un titulaire légitime ou un successeur aurait-il besoin pour reconstituer le dernier état vérifié sans en inventer un nouveau ?

Commencer par distinguer trois états

De nombreuses discussions sur les registres deviennent confuses parce que trois questions différentes sont traitées comme une seule :

• L’état du registre : ce qu’une autorité consigne actuellement concernant la ressource, le titulaire reconnu, les contacts, les événements, la délégation et le statut.
• L’état opérationnel : la manière dont la ressource est utilisée en pratique, notamment le DNS inverse, les relations avec les fournisseurs et la continuité du service.
• L’état du routage : le système autonome à l’origine de l’annonce d’une route et la validité de l’autorisation de routage correspondante.

Ces états peuvent concorder, sans pour autant devoir changer au même moment. Un préfixe peut passer d’un fournisseur à un autre alors que son titulaire reconnu reste le même. Un enregistrement dans un registre peut être correct alors qu’une route est mal configurée. Une autorisation de routage peut être valide alors qu’un objet de contact est obsolète. Un export utile doit préserver les relations entre ces états et montrer quelle affirmation est étayée par chaque élément de preuve.

Ce que RDAP apporte, et ce qu’il n’apporte pas

RDAP est la couche standard de consultation des données d’enregistrement. Son modèle JSON décrit des objets tels que les réseaux IP, les numéros de système autonome, les entités, les événements et les liens. Il facilite ainsi la consultation et l’interprétation d’un enregistrement en ligne d’un registre à l’autre. Sa structure est définie par le RFC 9083.

RDAP répond à une question de consultation au présent : que renvoie maintenant le registre qui répond à la requête pour cet objet ? La réponse peut inclure l’enregistrement actuel et des informations sur les événements, mais une réponse en ligne ne constitue pas automatiquement un dossier de continuité indépendant. Elle ne garantit pas, à elle seule, qu’un titulaire dispose d’une séquence portable et authentifiée d’états antérieurs, d’un historique complet des transitions ou des éléments nécessaires à une reprise ordonnée par un successeur.

Cette différence compte. Un annuaire en ligne est une fenêtre sur un système. L’export de l’état du registre permet de préserver suffisamment d’informations vérifiées pour raisonner sur la continuité lorsque la fenêtre, le système ou la relation institutionnelle change.

Ce que RPKI prouve, et ce qu’il ne prouve pas

RPKI répond à une question de routage. Une autorisation d’origine de route, ou ROA, identifie un système autonome que le titulaire de l’espace d’adressage a autorisé à être à l’origine des annonces de routes pour un ou plusieurs préfixes. Le profil et les règles de validation sont décrits dans le RFC 9582.

Il s’agit d’un élément de preuve précieux, mais pas d’une réponse complète à toutes les questions relatives au registre. Un ROA valide ne prouve pas à lui seul l’intégralité de l’historique juridique ou administratif d’une ressource, n’identifie pas tous les contacts opérationnels, n’établit pas la continuité du DNS inverse et ne résout pas un différend sur l’état du registre à reconnaître. L’autorisation RPKI est une couche du dossier de continuité, pas un substitut à ce dossier.

Une définition pratique de l’export de l’état du registre

L’export de l’état du registre est une proposition de dossier de continuité qui rend les éléments essentiels de l’état vérifié d’une ressource IPv4, IPv6 ou ASN portables, compréhensibles et testables. Il doit permettre à un lecteur indépendant de répondre à quatre questions :

1. De quelle ressource et de quel titulaire reconnu parle-t-on ?
2. Quel était le dernier état vérifié et quand a-t-il pris effet ?
3. Quels changements importants sont intervenus après cet état ?
4. Quels éléments de preuve et quelle autorité justifient une transition ou une reprise légitime par un successeur ?

C’est plus précis qu’une copie brute de base de données et plus utile qu’une capture d’écran. L’export doit contenir l’état dont un successeur a besoin, tout en excluant les données clients sans rapport, la stratégie commerciale confidentielle et les détails de mise en œuvre internes qui ne contribuent pas à établir la situation de la ressource.

L’export minimal utile

Un export pratique peut s’organiser autour d’un petit ensemble d’enregistrements liés. Chacun doit comporter un identifiant stable, une date et heure de prise d’effet, sa source et suffisamment d’informations pour détecter un changement inexpliqué.

• Identité de la ressource : le préfixe IPv4, le préfixe IPv6 ou l’ASN, sa relation avec une ressource parente ou son allocation lorsque cela s’applique, et ses identifiants dans le registre.
• Titulaire reconnu : l’organisation ou l’entité reconnue dans l’état vérifié, l’identifiant du registre, la date de prise d’effet et le statut de cette reconnaissance.
• Contacts : les contacts administratifs, techniques, chargés des abus et de la sécurité dont un successeur ou une partie qui se fie aux données a réellement besoin.
• Historique des événements importants : les transferts, changements de nom ou d’organisation, délégations, changements de statut, différends et éléments de preuve ou autorisations associés à chaque événement.
• Relations opérationnelles : les relations pertinentes avec les fournisseurs, les utilisateurs délégués, le DNS inverse et les services, avec leurs périodes d’effet et leur état à la cessation.
• Références de routage et de sécurité : les références pertinentes de l’ASN d’origine, des ROA ou des objets RPKI, l’état de publication et le moment où cet état a été observé.
• État des conflits : l’existence éventuelle d’un différend, d’un blocage ou d’une revendication concurrente, la ressource concernée et le dernier état non contesté.
• Piste d’audit : qui a changé quoi, quand, sous quelle autorité, de quelle valeur vers quelle valeur et avec quel résultat de vérification.
• Informations d’intégrité : les numéros de version, horodatages, empreintes de hachage des objets, signatures et un manifeste d’export permettant au destinataire de vérifier la source et de détecter toute modification.

L’export n’a pas besoin de reproduire toutes les tables de la base de données interne. Il doit préserver les relations qui donnent son sens à la réponse publique et rendent la transition auditable.

Pourquoi une sauvegarde ne suffit pas

Une sauvegarde est généralement conçue pour restaurer un système au bénéfice du même opérateur. L’export de l’état du registre vise à permettre à une autre partie autorisée de comprendre et de vérifier l’état lorsque le système, l’organisation ou le dispositif d’exploitation d’origine ne peut pas simplement être rétabli.

• Une sauvegarde peut nécessiter un logiciel propriétaire, des relations non documentées et les identifiants d’accès d’origine.
• Un export doit être lisible par un successeur indépendant et identifier les éléments de preuve qui sous-tendent chaque affirmation importante.
• Une sauvegarde peut contenir bien plus de données que ce qu’un titulaire de ressource est en droit ou désireux de recevoir.
• Un export doit être limité à la ressource, authentifié, lisible par machine et portable.

La distinction ne relève pas d’une préférence technique. Elle sépare la préservation d’une machine de la préservation de la capacité à reconnaître un état légitime.

Que se passe-t-il lorsqu’il faut assurer la continuité ?

Un processus de continuité ne doit pas commencer par permettre à deux systèmes de revendiquer la même ressource. Il doit commencer par figer le dernier état vérifié et rendre la transition explicite.

1. Identifier le déclencheur : panne, insolvabilité, compromission, migration, différend ou autre événement de continuité défini.
2. Préserver le dernier état vérifié : consigner la ressource, le titulaire reconnu, les contacts, l’historique des événements importants et les éléments de preuve qui étayent cet instantané.
3. Vérifier l’export : contrôler les signatures, les empreintes de hachage, les horodatages, les références d’autorisation et l’intégrité du manifeste.
4. Séparer les couches de preuve : comparer l’état du registre avec l’usage opérationnel, le DNS inverse, les observations de routage et l’état RPKI au lieu de traiter une couche comme la preuve de toutes les autres.
5. Consigner le successeur : définir comment l’état précédent est remplacé, comment les conflits sont traités et comment les systèmes qui se fient à ces données découvrent le successeur reconnu.
6. Publier la transition : rendre le nouvel état et son moment de prise d’effet accessibles, tout en conservant l’état antérieur comme trace historique auditable.

Le processus vise à préserver la continuité sans faire d’une panne l’occasion, pour un revendiquant non vérifié, de réécrire l’histoire.

Ce que l’export de l’état du registre ne doit pas faire

Un export de continuité n’est pas un second registre donnant à chaque destinataire le pouvoir d’affirmer sa propriété. Il ne doit pas créer de revendications parallèles, contourner la politique applicable aux ressources, exposer le trafic des clients ou une stratégie confidentielle, ni transformer silencieusement l’usage opérationnel en contrôle administratif reconnu.

L’export doit aussi préciser ses limites. Si un champ est indisponible, masqué ou contesté, l’enregistrement doit l’indiquer. Une inconnue reconnue honnêtement est plus sûre qu’une valeur apparemment complète mais dépourvue de preuve.

Comment tester un export avant une crise

Un titulaire de ressource ou un opérateur peut mettre le concept à l’épreuve à l’aide d’un examen simple :

• Un lecteur indépendant peut-il identifier exactement la ressource IPv4, IPv6 ou ASN ?
• Peut-il identifier le titulaire reconnu dans le dernier état vérifié et la date de prise d’effet correspondante ?
• Peut-il reconstituer les transferts, délégations et changements d’organisation importants ?
• Peut-il distinguer l’état du registre du routage actuel et de l’usage opérationnel ?
• Peut-il retrouver les éléments pertinents concernant RPKI et le DNS inverse ?
• Peut-il voir s’il existe un différend ou une revendication concurrente ?
• Peut-il vérifier qui a produit l’export et si celui-ci a été modifié ensuite ?
• Un successeur légitime peut-il utiliser l’enregistrement sans importer la base de données privée d’origine ?

Si la réponse à ces questions est non, l’organisation dispose peut-être d’un service de consultation en ligne ou d’une sauvegarde, mais pas encore d’un dossier de continuité éprouvé.

Comment cela s’inscrit dans le cycle de vie d’IPv4

Une ressource IPv4 possède un cycle de vie qui comprend les enregistrements du registre, les transferts, la délégation opérationnelle, le routage et un éventuel changement d’usage. L’export fait le lien entre ces moments. Commencez par ce que les données des registres peuvent montrer du cycle de vie d’IPv4, puis distinguez le passage d’une région à une autre dans les transferts inter-RIR d’un changement de routage dans le changement de réseau d’origine BGP.

Le même raisonnement s’applique à la question plus générale de la gouvernance : lorsqu’un système coordonne des ressources uniques, la capacité à vérifier et à emporter l’état ne doit pas dépendre entièrement d’un point administratif devenu indisponible. C’est pourquoi l’export de l’état du registre a sa place aux côtés des questions pratiques de ce qui se passe lorsqu’un registre Internet fait défaut et de ce que la preuve de contrôle peut réellement démontrer.

Conclusion

L’export de l’état du registre est un moyen de rendre la continuité concrète. Il ne remplace ni RDAP, ni RPKI, ni les données de routage, ni le DNS inverse, ni les politiques du registre. Il relie les éléments de preuve pertinents dans un dossier authentifié, versionné et portable qu’un lecteur légitime peut comprendre lorsque le système d’origine ne peut pas simplement être considéré comme fiable ou être restauré.

Si le registre disparaît, l’objectif n’est pas de permettre à n’importe qui de revendiquer la ressource. Il est de préserver suffisamment d’informations vérifiées pour que la réponse légitime puisse encore être reconnue, mise à l’épreuve et reprise dans la suite du processus.