Qu'est-ce que l'exportation d'état-registre pour les ressources de numéros Internet?

L'exportation par l'état du registre est le concept de création d'une copie authentifiée, portable et vérifiable des renseignements essentiels du registre associés à une ressource de numéros Internet. Pour un bloc IPv4 , un préfixe IPv6 ou un numéro de système autonome, cette exportation pourrait inclure des informations telles que:

• la ressource du numéro Internet;
• les informations reconnues du détenteur;
• les objets de contact pertinents;
• le statut d'enregistrement;
• l'historique du transfert;
• les informations sur la délégation;
• les informations DNS inversées;
• RPKI - métadonnées connexes;
• le statut de différend ou de conflit;
• l'historique des changements matériels;
• les dossiers de vérification nécessaires pour comprendre l'état actuel vérifié.

Le but n'est pas simplement de créer un fichier de sauvegarde. Une exportation d'état-registre utile devrait permettre de répondre à une question plus importante:

Si le système qui tient actuellement un registre des ressources devient indisponible, contesté ou incapable de fournir des services essentiels, l'État du registre légitime peut-il encore être compris et reconstruit de façon indépendante?

Cela fait de l'exportation par l'État du registre une question de continuité, auditabilité et portabilité, pas simplement téléchargement de données. Il est également important de distinguer le concept des protocoles existants comme le RDAP . Le RDAP offre un accès structuré à l'information relative à l'enregistrement sur Internet, mais une exportation complète du registre et de l'État pourrait contenir des renseignements supplémentaires sur la continuité, le contexte historique, les relations d'autorisation et les données de vérification nécessaires pour reconstruire un état vérifié des ressources. Autrement dit : RDAP vous aide à consulter les données du registre. L'exportation des registres et des États contribuerait à préserver l'État nécessaire à la continuité.

Pourquoi est-ce que l'état du registre importe?

Les ressources de l'Internet peuvent rester opérationnelles pendant de nombreuses années. Pendant cette période:

• les entreprises peuvent changer de nom;
• les organisations peuvent fusionner;
• les ressources peuvent être transférées;
• les adresses peuvent être louées ou déléguées;
• les fournisseurs peuvent changer;
• le routage peut se déplacer entre les ASN ;
• les contacts techniques peuvent changer;
• L'information RPKI peut changer;
• DNS inverse peut se déplacer; et
• des différends peuvent survenir.

La ressource elle-même peut rester intégrée dans un réseau en cours d'exécution tout au long de ces changements. Cela signifie que l'état utile d'une ressource de numéro Internet est plus d'une ligne dans une base de données. Il peut résulter d'années de changements vérifiés. Si cette histoire devient inaccessible, les opérateurs de réseau peuvent encore savoir qu'un bloc IPv4 fonctionne, mais reconstruire pourquoi l'état de registre actuel est légitime peut devenir beaucoup plus difficile. Une exportation de l'état du registre vise à réduire cette dépendance. Le principe est simple: L'information essentielle du registre devrait demeurer durable même lorsque l'organisation, la plate-forme ou l'infrastructure qui la maintient actuellement change.

La fonction d'enregistrement est différente de l'institution d'enregistrement

Cette distinction est essentielle pour comprendre l'exportation des registres et des États. Internet nécessite certaines fonctions de ressources numériques. Les réseaux ont besoin :

• des identifiants uniques au niveau mondial;
• des informations exactes sur l'enregistrement;
• des coordonnées fiables;
• les registres de transfert;
• la continuité DNS inverse;
• l'information sur la sécurité du routage;
• les changements vérifiables;
• les mécanismes de règlement des revendications contradictoires.

Ces fonctions sont importantes. Mais les fonction et les institution exerçant actuellement la fonction ne sont pas nécessairement la même chose. Une plateforme de base de données peut changer. Une organisation peut se restructurer. Le logiciel peut être remplacé. Les responsabilités opérationnelles peuvent bouger. Un environnement de registre peut connaître des perturbations techniques, financières, juridiques ou organisationnelles. Aucun de ces événements ne devrait automatiquement rendre impossible la reconstruction de l'état historique des ressources de nombres Internet. C'est pourquoi L'échec de la continuité du registre distingue la continuité du registre de la permanence de l'organisation qui l'exploite. L'exportation par l'État du registre suit le même principe:

Protéger la fonction de registre en rendant l'état récupérable.

C'est différent de supposer qu'une institution doit rester inchangée pour toujours.

Que devrait contenir un registre-État d'exportation?

Une exportation utile devrait contenir suffisamment d'informations pour reconstruire l'état vérifié pertinent de la ressource. Le format technique exact nécessiterait des spécifications, mais l'information peut être divisée en plusieurs catégories.

1. Numéro Internet Renseignements sur les ressources

L'exportation devrait clairement identifier la ressource. Par exemple:

• Préfixe IPv4 ;
• Préfixe IPv6 ;
• Numéro de système autonome;
• la relation de parenté ou de répartition pertinente;
• état des ressources;
• les identifiants d'enregistrement applicables.

Sans identité de ressource précise, le reste de l'exportation a peu de valeur. Par exemple:

IPv4 : 192.0.2.0 / 24

ou:

ASN : AS64500

La ressource doit être lisible par machine et sans ambiguïté.

2. Renseignements reconnus par le détenteur

L'exportation doit enregistrer l'organisation associée à l'état du registre reconnu. Les informations pertinentes peuvent comprendre:

• nom de l'organisation;
• identification du registre;
• organisation ID ;
• référence juridique ou organisationnelle pertinente;
• la date d'entrée en vigueur;
• le statut de l'enregistrement.

Cela ne signifie pas qu'un enregistrement doit être traité comme un titre juridique universel. Cela signifie qu'un système de continuité doit savoir:

Qui a reconnu le registre au dernier état vérifié?

Cela fournit une base à partir de laquelle des changements ultérieurs peuvent être examinés.

3. Objets de contact

Les dossiers de ressources numériques d'Internet contiennent souvent plusieurs types de contacts. Il peut s'agir notamment :

• contacts administratifs;
• contacts techniques;
• les contacts abusifs;
• les contacts de sécurité;
• autres contacts opérationnels.

Les systèmes actuels d'enregistrement et de données peuvent exposer nombre de ces relations par l'intermédiaire de WHOIS ou de RDAP . Toutefois, une exportation de l'État du registre devrait préserver non seulement le contact actuellement visible, mais suffisamment d'informations pour comprendre la relation pertinente vérifiée au moment de l'exportation. Cela devient important lorsque le personnel quitte ou que les organisations se restructurent.

4. Historique du transfert et du changement

L'état actuel est important. L'histoire peut être tout aussi importante. Supposons qu'un bloc IPv4 change de l'Organisation A à l'Organisation B. Une requête courante du registre pourrait montrer :

Organisation B

Mais un système de continuité devrait idéalement être également en mesure d'établir:

• lorsque le changement s'est produit;
• ce qu'était l'état précédent;
• le type de changement qui s'est produit;
• si la transition a été vérifiée;
• qui l'a appuyé; et
• quand le nouvel État est entré en vigueur.

L'exportation d'un registre-État n'a pas nécessairement besoin de divulguer publiquement des renseignements confidentiels sur les transactions. Mais l'architecture de continuité devrait préserver suffisamment l'histoire authentifiée pour établir que la transition d'état a eu lieu légitimement. Cela transforme le registre d'un instantané en un grand livre vérifiable.

5. Information sur la délégation opérationnelle

Le détenteur inscrit et l'utilisateur opérationnel des ressources de numéros Internet peuvent être différents. Par exemple: Titulaire des ressources → bailleur → locataire → hébergeur → réseau en amont Il se peut donc qu'un registre capable d'assurer la continuité doive consigner les informations appropriées concernant la délégation opérationnelle reconnue. Cela pourrait comprendre :

• préfixe délégué;
• utilisateur opérationnel;
• la période effective;
• des contacts délégués;
• la relation de routage;
• le statut d'autorisation;
• le statut d'expiration ou de résiliation.

Tous les détails commerciaux ne doivent pas devenir des données de registre. L'objectif est de préserver l'information pertinente à la coordination Internet. Cette distinction est étudiée de manière plus générale dans Le miroir politique, où la délégation opérationnelle est traitée comme une réalité registrable lorsqu'elle affecte matériellement la façon dont la ressource est utilisée ou coordonnée. Le principe important est: Le dossier devrait pouvoir décrire la réalité opérationnelle légitime sans avoir à contrôler la relation commerciale sous-jacente.

6. Information DNS inversée

Le DNS inverse peut devenir important sur le plan opérationnel pour une ressource IP en cours d'exécution. Une exportation par l'État du registre pourrait donc comporter des informations pertinentes sur:

• délégation de zone inversée;
• les serveurs de noms faisant autorité;
• le statut de délégation;
• l'organisation responsable;
• l'historique des changements pertinents.

Pour IPv4 , le DNS inverse implique généralement in-addr.arpa hiérarchie. Pour IPv6 , il utilise ip6.arpa. Le DNS inversé peut affecter :

• systèmes de messagerie;
• l'analyse de sécurité;
• l'exploitation forestière;
• dépannage;
• les systèmes de réputation;
• les opérations de réseau.

Si la continuité du registre est requise, le DNS inversé ne doit pas être oublié. Un dossier de ressources qui survit alors que sa délégation de DNS d'appui devient impossible à reconstruire n'apporterait qu'une continuité partielle.

7 . RPKI -Métadonnées connexes

RPKI est une autre couche sensible à la continuité. Le système RPKI contient des certificats de ressources et des objets signés utilisés pour appuyer l'information sur la sécurité du routage, comme les autorisations d'origine des routes. Une exportation d'état-registre ne doit pas être confondue avec la simple copie de clés cryptographiques privées. La manipulation des clés privées nécessite des contrôles de sécurité séparés. Au lieu de cela, l'exportation pourrait préserver l'état pertinent tel que:

• si le service RPKI est activé;
• les relations pertinentes entre les ressources et les certificats;
• actuel ROA informations;
• origine autorisée ASN ;
• les informations de durée maximale, le cas échéant;
• métadonnées de publication;
• les informations pertinentes sur la situation;
• suffisamment de références pour comprendre l'état actuel de l'affirmation de sécurité.

L'objectif n'est pas de reproduire toute l'architecture RPKI . L'objectif est de faire en sorte que la planification de la continuité sache :

Quelles assertions de sécurité ont été associées à la ressource à l'état vérifié?

Cela est important parce qu'une transition de registre ne devrait pas créer accidentellement des problèmes inutiles de sécurité de routage pour un réseau légitime.

8. Litiges et situation de conflit

Une exportation de registre-état devient particulièrement précieuse lorsque la ressource est contestée. Imaginez que deux parties revendiquent l'autorité sur la même ressource. Exporter simplement :

Titulaire = Organisation A

peut ne pas suffire si l'État actuel lui-même est contesté. L'exportation devrait pouvoir représenter un État en conflit. Par exemple:

• un différend existe;
• date à laquelle le différend a été enregistré;
• ressources affectées;
• le dernier état non contesté ou vérifié;
• le statut administratif actuel;
• le statut de restriction ou de détention pertinent;
• le statut d'arbitrage, le cas échéant;
• références à la piste de preuve.

Le but n'est pas de trancher automatiquement le différend. Il s'agit d'empêcher le différend de disparaître des données. Un bon registre devrait pouvoir dire :

Cette ressource est actuellement sujette à un conflit enregistré.

plutôt que de présenter silencieusement un côté comme une réalité incontestée.

9. Le dernier État vérifié

Un des concepts les plus utiles pour la continuité des registres est dernier état vérifié. Supposons que les données de registre actuelles deviennent contestées ou corrompues. Le système devrait idéalement pouvoir reconstruire :

1. le dernier État considéré comme valide;
2. lorsque cet état est entré en vigueur;
3. les preuves à l'appui;
4. les changements survenus après; et
5. qui a introduit l'incertitude.

Cela rend l'enquête sur les différends beaucoup plus précise. Au lieu de demander :

Qui contrôle la ressource?

l'enquête peut demander:

Quel était le dernier état vérifié, et quelles preuves étayent la transition ?

C'est une question beaucoup plus vérifiable. L'exportation de l'état du registre rend ce modèle pratique parce que l'état historique pertinent est préservé plutôt que d'être écrasé sans contexte.

10. Registres de vérification

La vérification est l'un des éléments les plus importants d'une exportation significative. Un journal de vérification pourrait conserver des renseignements tels que :

• horodatage;
• action;
• objet affecté;
• valeur précédente;
• nouvelle valeur;
• l'acteur authentifié;
• référence d'autorisation;
• le statut de vérification; et
• identificateur de transaction ou de changement.

Tous les détails opérationnels ne doivent pas être publics. Mais les transitions d'état critique doivent être expliquées. Une piste de vérification permet de répondre :

Qui a changé ça ?

Quand ?

De quoi ?

À quoi ?

Sous l'autorité de qui ?

D'après quelles preuves ?

Ces questions revêtent une importance particulière lorsque les ressources de l'Internet soutiennent l'infrastructure de production ou ont une valeur opérationnelle importante.

Registre-État Export vs RDAP

Il ne faut pas confondre l'exportation de l'état du registre et celle du RDAP . Le RDAP offre déjà un important mécanisme normalisé d'accès aux données d'enregistrement. Mais les objectifs sont différents.

Fonctionnalité	RDAP	Registre-État des exportations
Interroger les données d'enregistrement actuelles	Oui	Oui, potentiellement
Protocole normalisé	Oui	Pas actuellement comme norme générale d'exportation INR
Lisible à la machine	Oui	devrait être
Renseignements sur les détenteurs de ressources	Oui, le cas échéant	Oui
Personnes-ressources	Oui, sous réserve des règles d'accès	État de continuité pertinent
Historique complet du transfert	Ce n'est pas son but principal	Potentiel
État historique	Limité / dépendant de la mise en œuvre	Doit le soutenir
Registres d'audit	Ce n'est pas l'objectif principal du RDAP	Important
Métadonnées des litiges	Dépend de la mise en œuvre	Doit le soutenir
Métadonnées de continuité RPKI	Système séparé	Pourrait renvoyer l'état pertinent
État de continuité DNS inverse	Système séparé	Peut inclure l'état pertinent
Failover / fonction de portabilité	Numéro	Oui
Restaurer l'état du registre vérifié	Ce n'est pas son but principal	Objectif de base

La distinction est importante. RDAP est un protocole d'accès aux données d'enregistrement. L'exportation Registry-State est un concept d'architecture de continuité. Les deux pourraient se compléter. Un futur format d'exportation registre-état pourrait réutiliser des objets RDAP normalisés plutôt que d'inventer de nouveaux formats inutiles pour l'information que RDAP représente déjà bien.

L'exportation de l'état du registre est plus qu'une sauvegarde

Une sauvegarde de base de données répond :

Peut-on restaurer cette base de données ?

Une exportation d'État-registre demande:

Cette ressource peut-elle être reconstruite indépendamment ?

Ce sont là des objectifs différents. Une sauvegarde traditionnelle peut :

• dépendent de logiciels de base de données propriétaires;
• contiennent des données pour chaque client;
• exiger l'infrastructure originale du registre;
• utiliser des relations internes sans papiers;
• contenir des informations confidentielles inutiles; ou
• il est difficile pour un détenteur de ressources de vérifier de façon indépendante.

Au lieu de cela, l'exportation au niveau du registre et de l'état des ressources devrait être :

• Étendue;
• authentifié;
• compréhensible;
• lisible par machine;
• vérifiable;
• portatifs; et
• suffisamment pour assurer la continuité.

Cela le rapproche de de continuité pour la ressource que la sauvegarde d'un serveur conventionnel.

Pourquoi les détenteurs de ressources peuvent avoir besoin d'un registre-exportation de l'État

Un opérateur de réseau pense rarement à la faillite du registre lorsque tout fonctionne normalement. Mais les infrastructures essentielles devraient aussi être conçues pour des situations anormales. Les événements potentiels de continuité peuvent comprendre :

• la corruption des bases de données;
• panne technique prolongée;
• incident de cybersécurité;
• la restructuration organisationnelle;
• insolvabilité;
• perte de personnel clé;
• les registres contestés;
• la migration des services; ou
• transition vers une plate-forme successeur.

Cela ne signifie pas qu'un registre particulier devrait échouer. Le même principe de résilience s'applique tout au long de l'ingénierie des infrastructures: Si une fonction est importante, son chemin de récupération doit être conçu avant que l'échec ne se produise. Les réseaux maintiennent des sauvegardes. Les bases de données utilisent la réplication. DNS utilise plusieurs serveurs faisant autorité. Le routage utilise des chemins redondants. Les systèmes Cloud utilisent plusieurs zones de disponibilité. L'information critique du registre mérite la même question architecturale :

Quel est le chemin de récupération?

Comment le registre-État exporte soutient la transférabilité

La transférabilité devient difficile lorsque toutes les preuves d'un état actuel de ressource n'existent qu'à l'intérieur d'un seul système interne de fournisseur. Un système successeur devrait reconstituer la ressource à partir de preuves incomplètes. Cela peut introduire des incertitudes sur:

• l'identité du titulaire;
• contacts;
• les transferts historiques;
• autorisation;
• délégation opérationnelle;
• État RPKI ;
• le DNS inverse;
• les différends; et
• les changements vérifiés antérieurs.

Une exportation normalisée et authentifiée de l'état du registre pourrait réduire ce problème. Théoriquement, la portabilité pourrait fonctionner comme suit: Registre actuel ↓ Exportation authentifiée d'état de registre ↓ Vérification indépendante ↓ Registre ou système de continuité du successeur qualifié ↓ Identité des ressources conservées et continuité des services L'objectif n'est pas une duplication incontrôlée. Il devrait encore y avoir un État actif reconnu à des fins uniques. La transférabilité devrait préserver l'unicité, et non la saper.

L'exportation ne signifie pas que deux registres peuvent revendiquer la même ressource

C'est une limite importante. La portabilité de l'état du registre ne devrait pas créer d'enregistrements actifs en double. Internet a encore besoin d'unicité. Un modèle d'échec nécessite des règles pour:

• l'état du registre faisant autorité;
• lorsqu'un déclencheur de continuité se produit;
• la manière dont le registre précédent est remplacé;
• la manière dont les États en conflit sont détectés;
• la façon dont la transition est enregistrée;
• comment les systèmes de confiance découvrent le successeur reconnu.

Un fichier copié à lui seul ne résout pas ces questions. L'architecture a besoin mécanisme de transition d'état. L'exportation a pour but de fournir les preuves et les données nécessaires à ce mécanisme. Il ne devrait pas créer de registres concurrents pour la même ressource.

À quoi ressemblerait une exportation authentifiée?

Une exportation de registre-état utile ne devrait pas être un tableur modifiable sans aucun moyen de vérifier son origine. Une conception technique future pourrait utiliser:

• JSON structuré;
• objets compatibles RDAP normalisés;
• les signatures cryptographiques;
• les horodatages;
• les hachages d'objets;
• les numéros de version;
• les identificateurs de changement immuables;
• des manifestes d'exportation vérifiables.

Par exemple, une exportation pourrait contenir :

Champ	Exemple Objet
Ressources	Identifier IPv4 , IPv6 ou ASN
Greffe	Identifier le registre source
Exporter version	Identifier la version du format
Horodatage d'exportation	Établir le temps
Objet du titulaire	Titulaire reconnu
Personnes-ressources	Préserver les contacts pertinents
Statut d ' enregistrement	Préserver l'état des ressources
Historique du transfert	Expliquer les transitions antérieures
Délégations	Enregistrer les relations opérationnelles
DNS inversé	Préserver l'état de délégation pertinent
Métadonnées RPKI	Décrire l'état de sécurité
Statut du différend	Préserver l'information sur les conflits
Audits	Expliquer les changements importants
État hash	Détecter la modification
Signature numérique	Authentifier l'exportateur

La spécification précise exigerait une conception technique et un examen communautaire. Mais l'objectif de conception devrait être clair:

Un destinataire devrait être en mesure de vérifier d'où provient l'exportation et de déterminer si elle a été modifiée.

À quelle fréquence l'État d'enregistrement devrait-il être exporté?

Il n'y a pas d'intervalle universel aujourd'hui parce que l'exportation d'un état de registre n'est pas un système opérationnel normalisé. Une mise en œuvre future pourrait prendre en compte les exportations:

• périodiquement;
• après les principaux changements de ressources;
• après transferts;
• après les changements d'organisation;
• après d'importants changements de délégation;
• après RPKI les changements;
• lorsqu'un différend commence;
• avant une migration d'enregistrement; et
• lorsque des événements à risque de continuité sont définis.

La bonne fréquence dépend de la rapidité avec laquelle l'état change. Une ressource qui est restée statique depuis dix ans a des besoins différents d'un portefeuille avec des transferts et des délégations fréquents. L'objectif devrait être de maintenir l'exportation assez récente pour qu'elle puisse servir de preuve significative de continuité.

Qui devrait être capable de recevoir une exportation?

Tous les champs de registre ne devraient pas nécessairement être publics. La vie privée, la sécurité et la confidentialité sont toujours importantes. Une architecture d'état de registre pourrait distinguer :

Données des registres publics

Information déjà destinée à la coordination publique.

Données sur la continuité des détenteurs de ressources

Renseignements supplémentaires dont dispose un détenteur de ressources authentifiées.

Données relatives à l'escroquerie ou au registre successeur

Informations stockées dans des conditions contrôlées à des fins de continuité.

Preuves limitées

Les documents sensibles ne sont disponibles que dans le cadre d'une autorisation, d'un différend ou de procédures juridiques définies. Cette approche en couches peut soutenir la continuité sans transformer chaque enregistrement interne en données publiques. L'objectif est portabilité de l'état nécessaire, pas une publication sans discrimination.

Registre-État d'exportation et Escrow indépendant

L'exportation devient plus forte lorsqu'elle est combinée à un séquestre indépendant. Si la seule copie d'une exportation de continuité est stockée sur la même infrastructure que la base de données du registre, les deux peuvent échouer ensemble. Une architecture de continuité pourrait donc préserver des versions authentifiées avec un service séquestre indépendant ou un mécanisme équivalent. Ce système pourrait maintenir :

• les versions périodiques;
• intégrité cryptographique;
• les horodatages;
• les antécédents de rétention;
• les contrôles d'accès;
• conditions de libération définies.

Cela crée une séparation entre: fonctionnement du registre et: préserver les preuves nécessaires pour restaurer la fonction de registre. La séparation est précieuse car la continuité ne devrait pas dépendre entièrement du même domaine d'échec.

Registre-État RPKI Continuité

RPKI nécessite des soins spéciaux. Le système RPKI a sa propre hiérarchie de certificats, les clés, les dépôts de publications et les objets signés. Une exportation de l'État du registre devrait donc être effectuée pas être traité comme un substitut informel RPKI L'architecture cryptographique. Au contraire, la planification de la continuité doit être explicite. RPKI procédures de succession. Ces procédures mai besoin de répondre:

• Qu'advient-il des certificats existants?
• Ce qui arrive à la publication ROA s ?
• Comment un successeur conserve-t-il ou rétablit-il une autorisation valide?
• Comment les objets révoqués ou remplacés sont-ils traités?
• Comment la transition est-elle communiquée aux parties dépendantes?

Une architecture de continuité des registres devrait fonctionner avec les mécanismes RPKI existants plutôt que de tenter de les remplacer. Le principe reste le suivant : La continuité du Greffe devrait inclure la continuité de la sécurité.

Registre-État d'exportation et continuité DNS inversée

Le même principe s'applique au DNS inversé. Une ressource peut rester dûment enregistrée pendant que son DNS inverse devient indisponible parce que l'information de délégation n'a pas été conservée pendant une transition. Un plan de continuité complet doit donc être envisagé:

• délégation de zone inversée;
• l'information du serveur de noms;
• l'autorisation pertinente;
• le calendrier de transition;
• opération de remplacement.

Cela démontre pourquoi la continuité des registres est plus large que la restauration d'un serveur WHOIS ou RDAP . La ressource a plusieurs dépendances. Un système de continuité devrait les comprendre.

Ce que l'exportation par l'État du registre ne devrait pas faire

Une exportation ciblée d'un registre-État ne devrait pas tenter de devenir une base de données universelle de tout ce qui implique une ressource de numéro Internet. Elle n'a pas besoin de contenir:

• les plans d'affaires des clients;
• prix;
• une stratégie commerciale confidentielle;
• chaque configuration du réseau;
• le trafic des clients;
• les données d'application;
• données de conformité non liées; ou
• chaque contrat impliquant l'organisation.

Cela rendrait la couche de coordination inutilement épaisse. L'exportation devrait plutôt se concentrer sur les informations réellement nécessaires pour préserver: Unicité contrôle vérifié exactitude du registre assertions de sécurité État de délégation vérifiable visibilité des différends et: continuité Ceci est conforme au modèle de coordination mince décrit dans Primacy du code de fonctionnement. Une exportation de continuité devrait être suffisamment forte pour protéger la fonction de registre sans devenir un dépôt pour le contrôle organisationnel indépendant.

Liste de contrôle pratique pour l'exportation de l'état du registre

Une exportation prête pour la continuité devrait permettre à un examinateur autorisé de répondre :

Ressources

• Quelles ressources IPv4 , IPv6 ou ASN sont impliquées ?
• La ressource est-elle identifiée de façon unique?

Titulaire

• Qui est le dernier détenteur reconnu vérifié?
• Quand cet État a-t-il été établi ?

Personnes-ressources

• Quels sont les contacts pertinents?
• Sont-ils actuels ?

Historique

• Quels changements importants d'état sont survenus?
• Les états précédents peuvent-ils être reconstruits?

Transfert

• La ressource a-t-elle été transférée?
• L'historique de la transition est-il disponible?

Délégation

• Existe-t-il une délégation opérationnelle pertinente?
• Quel est son statut actuel?

Routage et sécurité

• Quelles sont les informations sur les autorisations liées au routage?
• Quel est l'état RPKI pertinent?

DNS inversé

• Quelle délégation du DNS inverse est associée à la ressource?

Litiges

• La ressource est-elle actuellement contestée?
• Quel était le dernier état vérifié ?

Vérification

• Qui a apporté des changements importants?
• Quand ?
• Sous quelle autorité vérifiée?

Authenticité

• L'exportation est-elle authentifiée numériquement?
• Une modification peut-elle être détectée?

Récupération

• L'information pourrait-elle appuyer une continuité légitime ou un processus successeur?

Si la réponse à la dernière question est non, le fichier peut être une exportation de données, mais il n'est pas encore significatif. continuité du registre exportation.

Conclusion

Les registres des numéros Internet remplissent une fonction importante. Ils aident à préserver des identifiants uniques à l'échelle mondiale. Ils tiennent des registres des ressources. Ils publient des contacts. Ils soutiennent l'histoire du transfert. Ils interagissent avec le DNS inversé et les systèmes de sécurité de routage. Ils aident les réseaux indépendants à comprendre l'environnement de ressources numériques qu'ils partagent. Ces fonctions étant importantes, elles devraient être conçues pour assurer la continuité. L'exportation par l'État du registre est un moyen de penser à cette exigence. Elle pose une simple question sur les infrastructures:

Si le système actuel de registre devient indisponible, avons-nous encore suffisamment d'information authentifiée pour comprendre l'état légitime de la ressource?

Une réponse sérieuse nécessite plus qu'un dossier WHOIS actuel. Elle exige:

• l'identité des ressources;
• État détenteur reconnu;
• contacts;
• histoire matérielle;
• les registres de transfert;
• les informations sur la délégation;
• État lié à la sécurité;
• les informations relatives au DNS inverse;
• métadonnées de conflit;
• la vérification;
• des preuves authentifiées.

Cela ne signifie pas qu'un registre particulier devrait échouer. Cela signifie que les systèmes importants devraient avoir des voies de récupération. Internet applique déjà ce principe au routage, au DNS , au stockage, aux bases de données et à l'infrastructure cloud. La couche nombre-ressources peut bénéficier de la même pensée de résilience. La fonction de registre devrait rester récupérable à mesure que les technologies, les plates-formes et les organisations évoluent. Le grand livre doit rester compréhensible. La ressource devrait demeurer unique. Et le fonctionnement des réseaux devrait être en mesure de préserver la continuité à mesure que les systèmes qui les entourent changent.