Exportação do estado do registo: como tornar recuperáveis os registos de recursos numéricos da Internet

Uma exportação útil permite a outro operador verificar o estado registado e o respetivo histórico. Guardar uma cópia é apenas o início; a passagem de responsabilidades também tem de ser compreensível e testável.

Quando uma entidade de registo está disponível, um recurso numérico da Internet pode parecer uma simples consulta. Pesquisa-se um prefixo IP ou um número de sistema autónomo e recebe-se um registo. Esse registo é útil, mas representa apenas uma perspetiva de um estado mais amplo: quem a entidade de registo reconhecia, o que mudou, que serviços foram delegados, que autorizações de encaminhamento existiam e que elementos de prova sustentam a resposta atual.

A pergunta mais difícil surge quando a entidade de registo está indisponível, é contestada, foi comprometida ou está a ser substituída. O estado legítimo do recurso continua a poder ser compreendido e verificado por alguém que não dispõe da base de dados original e dos procedimentos internos?

A questão da continuidade: se o atual sistema de registo deixar de responder amanhã, de que informação precisará um titular legítimo ou um sucessor para reconstruir o último estado verificado sem inventar um novo?

Começar por separar três estados diferentes

Muitas discussões sobre entidades de registo tornam-se confusas porque três perguntas diferentes são tratadas como uma só:

• Estado do registo: o que uma autoridade regista atualmente sobre o recurso, o titular reconhecido, os contactos, os eventos, a delegação e a situação.
• Estado operacional: como o recurso está a ser utilizado na prática, incluindo o DNS inverso, as relações com fornecedores e a continuidade do serviço.
• Estado do encaminhamento: que sistema autónomo está a originar uma rota e se a autorização de encaminhamento pertinente é válida.

Estes estados podem estar de acordo, mas não têm de mudar ao mesmo tempo. Um prefixo pode passar de um fornecedor para outro enquanto o seu titular reconhecido permanece o mesmo. Um registo pode estar correto enquanto uma rota está mal configurada. Uma autorização de encaminhamento pode ser válida enquanto um objeto de contacto está obsoleto. Uma exportação útil tem de preservar as relações entre estes estados e mostrar que afirmação é sustentada por cada elemento de prova.

O que o RDAP fornece e o que não fornece

O RDAP é a camada normalizada de consulta de dados de registo. O seu modelo JSON descreve objetos como redes IP, números de sistema autónomo, entidades, eventos e ligações. Isto facilita a consulta e a interpretação de um registo em serviço entre diferentes entidades de registo. A estrutura é definida pela RFC 9083.

O RDAP responde a uma pergunta sobre o presente: o que devolve agora a entidade de registo que responde à consulta deste objeto? Pode incluir o registo atual e informação sobre eventos, mas uma resposta em tempo real não constitui automaticamente um pacote independente de continuidade. Não garante, por si só, que um titular disponha de uma sequência portátil e autenticada de estados anteriores, de um registo completo das transições ou dos elementos necessários a um processo de sucessão ordenado.

Essa diferença é importante. Um diretório em serviço é uma janela para um sistema. Uma exportação do estado do registo é uma forma de preservar estado verificado suficiente para avaliar a continuidade quando a janela, o sistema ou a relação institucional muda.

O que a RPKI prova e o que não prova

A RPKI responde a uma questão de encaminhamento. Uma Autorização de Origem de Rota identifica um sistema autónomo que o titular do espaço de endereçamento autorizou a originar rotas para um ou mais prefixos. O perfil e as regras de validação são descritos na RFC 9582.

É um elemento de prova valioso, mas não é uma resposta completa a todas as questões de registo. Uma ROA válida não prova, por si só, todo o histórico jurídico ou administrativo de um recurso, não identifica todos os contactos operacionais, não estabelece a continuidade do DNS inverso nem resolve um litígio sobre que estado do registo deve ser reconhecido. A autorização RPKI é uma camada de um registo de continuidade, não um substituto desse registo.

Uma definição de trabalho de exportação do estado do registo

A exportação do estado do registo é uma proposta de pacote de continuidade que torna o estado verificado essencial de um recurso IPv4, IPv6 ou ASN portátil, compreensível e testável. Deve permitir a um leitor independente responder a quatro perguntas:

1. De que recurso e de que titular reconhecido estamos a falar?
2. Qual foi o último estado verificado e quando entrou em vigor?
3. Que alterações relevantes ocorreram depois desse estado?
4. Que elementos de prova e que autoridade sustentam uma transição legítima ou um processo de sucessão?

Isto é mais específico do que uma extração integral da base de dados e mais útil do que uma captura de ecrã. A exportação deve conter o estado de que um sucessor precisa, deixando de fora dados de clientes sem relação com o recurso, estratégias empresariais privadas e pormenores internos de implementação que não contribuem para estabelecer o estado do recurso.

A exportação mínima útil

Uma exportação prática pode ser organizada num pequeno conjunto de registos interligados. Cada registo deve incluir um identificador estável, o momento de entrada em vigor, a sua origem e informação suficiente para detetar uma alteração sem explicação.

• Identidade do recurso: o prefixo IPv4, o prefixo IPv6 ou o ASN, a sua relação com um recurso superior ou com uma atribuição, quando pertinente, e os seus identificadores de registo.
• Titular reconhecido: a organização ou entidade reconhecida no estado verificado, o identificador de registo, a data de entrada em vigor e a situação desse reconhecimento.
• Contactos: os contactos administrativos, técnicos, de abuso e de segurança de que um sucessor ou uma parte que se baseie no registo efetivamente precisa.
• Histórico relevante: transferências, alterações de nome ou de organização, delegações, alterações de situação, litígios e os elementos de prova ou autorizações associados a cada evento.
• Relações operacionais: as relações pertinentes com fornecedores, utilizadores por delegação, DNS inverso e serviços, com os respetivos períodos de vigência e o estado no momento da cessação.
• Referências de encaminhamento e segurança: o ASN de origem pertinente, as referências a ROA ou objetos RPKI, o estado de publicação e o momento em que esse estado foi observado.
• Estado dos conflitos: se existe um litígio, um bloqueio ou uma reivindicação contraditória, que recurso afeta e qual foi o último estado não contestado.
• Rasto de auditoria: quem alterou o quê, quando, ao abrigo de que autoridade, de que valor para que valor e com que resultado de verificação.
• Informação de integridade: números de versão, marcas temporais, hashes de objetos, assinaturas e um manifesto da exportação que permitam ao destinatário verificar a origem e detetar modificações.

A exportação não precisa de reproduzir todas as tabelas internas da base de dados. Precisa de preservar as relações que dão significado à resposta pública e tornam a transição auditável.

Porque não basta uma cópia de segurança

Uma cópia de segurança é normalmente concebida para restaurar um sistema para o mesmo operador. A exportação do estado do registo é concebida para permitir que outra parte autorizada compreenda e verifique o estado quando o sistema original, a organização ou o modelo operacional não podem ser simplesmente restaurados.

• Uma cópia de segurança pode exigir software proprietário, relações não documentadas e as credenciais originais.
• Uma exportação deve poder ser lida por um sucessor independente e deve identificar os elementos de prova subjacentes a cada afirmação relevante.
• Uma cópia de segurança pode conter muito mais dados do que aqueles que o titular de um recurso tem o direito de receber ou está disposto a receber.
• Uma exportação deve limitar-se ao recurso, ser autenticada, legível por máquina e portátil.

A distinção não é uma preferência técnica. É a diferença entre preservar uma máquina e preservar a capacidade de reconhecer um estado legítimo.

O que acontece quando a continuidade é necessária

Um processo de continuidade não deve começar por permitir que dois sistemas reivindiquem o mesmo recurso. Deve começar por fixar o último estado verificado e tornar explícita a transição.

1. Identificar o evento desencadeador: interrupção de serviço, insolvência, comprometimento, migração, litígio ou outro evento de continuidade definido.
2. Preservar o último estado verificado: registar o recurso, o titular reconhecido, os contactos, o histórico relevante e os elementos de prova que sustentam esse retrato do estado.
3. Verificar a exportação: verificar assinaturas, hashes, marcas temporais, referências de autorização e a integridade do manifesto.
4. Separar as camadas de prova: comparar o estado do registo com a utilização operacional, o DNS inverso, as observações de encaminhamento e o estado RPKI, em vez de tratar uma camada como prova de todas as outras.
5. Registar o sucessor: definir como o estado anterior é substituído, como se tratam os conflitos e como os sistemas que dependem do registo descobrem o sucessor reconhecido.
6. Publicar a transição: tornar consultáveis o novo estado e o momento da sua entrada em vigor, conservando o estado anterior como registo histórico auditável.

O processo foi concebido para preservar a continuidade sem transformar uma interrupção numa oportunidade para um requerente não verificado reescrever a história.

O que a exportação do estado do registo não deve fazer

Uma exportação de continuidade não é um segundo registo que dá a todos os destinatários o poder de reivindicar a propriedade. Não deve criar reivindicações paralelas, contornar a política de recursos aplicável, expor tráfego de clientes ou estratégias confidenciais, nem converter silenciosamente a utilização operacional em controlo administrativo reconhecido.

A exportação deve também declarar os seus limites. Se um campo estiver indisponível, tiver sido ocultado ou estiver em disputa, o registo deve dizê-lo. Um desconhecimento assumido com honestidade é mais seguro do que um valor aparentemente completo sem elementos de prova.

Como testar uma exportação antes de uma crise

Um titular ou operador de recursos pode testar o conceito com uma análise simples:

• Um leitor independente consegue identificar o recurso IPv4, IPv6 ou ASN exato?
• Consegue identificar o último titular reconhecido cujo estado foi verificado e a data de entrada em vigor?
• Consegue reconstruir as transferências, delegações e alterações de organização relevantes?
• Consegue distinguir o estado do registo do encaminhamento atual e da utilização operacional?
• Consegue localizar os elementos de prova pertinentes de RPKI e DNS inverso?
• Consegue perceber se existe um litígio ou uma reivindicação contraditória?
• Consegue verificar quem produziu a exportação e se esta foi alterada posteriormente?
• Um sucessor legítimo consegue utilizar o registo sem importar a base de dados privada original?

Se a resposta a estas perguntas for negativa, a organização pode dispor de uma consulta em serviço ou de uma cópia de segurança, mas ainda não dispõe de um registo de continuidade testado.

Como se enquadra no ciclo de vida do IPv4

Um recurso IPv4 tem um ciclo de vida que inclui registos, transferências, delegação operacional, encaminhamento e uma eventual mudança de utilização. A exportação é o elo de ligação entre esses momentos. Comece por ler o que os dados de registo podem mostrar sobre o ciclo de vida de um recurso IPv4 e depois distinga a movimentação regional nas transferências entre RIR de uma alteração de encaminhamento na mudança de rede de origem em BGP.

O mesmo raciocínio aplica-se à questão mais ampla da governação: quando um sistema coordena recursos únicos, a capacidade de verificar e transportar o estado não deve depender inteiramente de um ponto administrativo indisponível. É por isso que a exportação do estado do registo deve ser considerada a par das questões práticas de o que acontece se uma entidade de registo da Internet falhar e o que a prova de controlo pode efetivamente demonstrar.

Conclusão

A exportação do estado do registo é uma forma de tornar a continuidade concreta. Não substitui o RDAP, a RPKI, os dados de encaminhamento, o DNS inverso ou a política da entidade de registo. Liga os elementos de prova pertinentes num registo autenticado, com controlo de versões e portátil, que um leitor legítimo pode compreender quando já não é possível simplesmente confiar no sistema original ou restaurá-lo.

Se a entidade de registo desaparecer, o objetivo não é permitir que qualquer pessoa reivindique o recurso. O objetivo é preservar estado verificado suficiente para que a resposta legítima continue a poder ser reconhecida, testada e levada para o futuro.