Resumo

  • RPKI não é simplesmente um recurso de segurança em cinco portais membros. É um sistema de confiança no qual a autoridade de certificação, a publicação do repositório, o gerenciamento de ROAs, a configuração de validadores, a distribuição de TALs, a dependência de serviços hospedados, a disponibilidade de serviços delegados e a governança de registros podem todos se tornar fatores de dependência para o roteamento.
  • O programa RPKI do NRO visa abertamente um serviço RPKI mais consistente, uniformemente seguro e confiável nos cinco RIRs, enquanto seus objetivos para 2025 incluem transparência, robustez, segurança e uma preocupação com a configuração atual das âncoras de confiança. A coordenação é útil, mas também significa que a resiliência deve ser medida pelos domínios de falha compartilhados, em vez do número de marcas de RIR.
  • Um padrão sério de resiliência RPKI deve perguntar quais falhas são independentes, quais são comuns, quais podem ser delegadas fora de um registro, quais exigem suporte de operador de emergência e quais exigem revisão pública antes que as mudanças no estado do certificado afetem a aceitação do roteamento.

O número de logotipos não é uma medida de resiliência

O mapa público de RPKI parece reconfortante à primeira vista. Existem cinco registros regionais da Internet. Cada um tem sua própria região, site público, portal de membros, páginas de certificação de recursos e material de âncora de confiança. O repositório de conteúdo RPKI do NRO direciona para portais RPKI distintos, páginas de certificação de recursos, informações sobre Trust Anchor Locator e declarações de práticas de certificação para AFRINIC, APNIC, ARIN, LACNIC e RIPE NCC. A superfície parece distribuída porque é visivelmente plural.

A aparência plural não é o mesmo que resiliência independente. Cinco marcas públicas podem compartilhar uma mesma suposição de governança. Cinco âncoras de confiança podem convergir através de uma direção de programa comum. Cinco portais ainda podem depender de práticas de controle de contas semelhantes, incentivos de serviços hospedados semelhantes, interpretações legais semelhantes da autoridade do titular e expectativas de continuidade de emergência semelhantes. Cinco repositórios ainda podem ser consumidos pelo mesmo ecossistema de validadores e encaminhados para as mesmas decisões de filtragem downstream.

Uma falha que parece regional no ponto de assinatura pode se tornar global no ponto da parte confiante se os operadores ingerirem o resultado por meio de ferramentas comuns e políticas de roteamento comuns.

Este é o problema central sob a confiança RPKI comum. RPKI foi projetado para tornar a autorização de origem de rota mais verificável. Ele vincula recursos digitais a um certificado criptográfico e permite que um titular legítimo autorize um sistema autônomo a originar um prefixo. Esta é uma grande melhoria em relação à confiança cega em anúncios de rota e objetos de rota obsoletos. Mas uma vez que a aceitação do roteamento começa a depender do estado do certificado, a governança desse estado do certificado se torna parte da superfície de controle da Internet. A questão não é mais simplesmente se cada RIR tem um logotipo e um portal.

A questão é quais falhas podem remover, desatualizar, declarar incorretamente ou atrasar as evidências que os roteadores e filtros de rota consomem.

Oprograma RPKI do NROtorna explícita a camada de coordenação. Ele afirma que o NRO concordou em trabalhar para um serviço RPKI robusto, coordenado e seguro, com o objetivo de fornecer um serviço mais consistente, uniformemente seguro, resiliente e confiável, e remover barreiras enfrentadas por operadores que criam objetos RPKI através de múltiplos RIRs. Este é um objetivo sensato. Operadores com recursos em múltiplas regiões não deveriam ter que aprender cinco culturas de segurança incompatíveis. Uma camada global de segurança de roteamento se beneficia da consistência.

A consistência, no entanto, altera a questão da resiliência. Quando um serviço é intencionalmente tornado mais uniforme, um observador deve se perguntar se a uniformidade reduz o erro ou o concentra. Uma base comum pode eliminar práticas locais fracas. Ela também pode propagar uma suposição errada por todas as regiões. Um conjunto comum de documentação pode facilitar a adoção. Também pode mascarar diferenças regionais que importam para o serviço delegado, acesso de emergência, recuperação de conta, revogação de ROA e autoridade legal. Um programa comum pode fortalecer a segurança.

Também pode fazer com que escolhas de política pareçam técnicas porque chegam em uma linguagem operacional.

A métrica correta, portanto, é o domínio de falha, não o número de logotipos. Um domínio de falha é o conjunto de componentes, autoridades, suposições, pessoas, regras legais, dependências de software, pontos de publicação e caminhos de revisão que podem falhar juntos. Se cinco instituições compartilham o mesmo domínio para um risco específico, contá-las como cinco unidades de resiliência é enganoso. Se uma instituição tem dois domínios verdadeiramente separados para um risco, contá-la como uma também é enganoso. A auditoria deve seguir a decisão e a dependência, não o emblema na página.

RPKI transforma autoridade de registro em evidência de roteamento

RPKI começa como uma arquitetura técnica, mas não permanece fora da governança.RFC 6480descreve uma infraestrutura para suportar segurança de roteamento aprimorada. Sua base é uma infraestrutura de chave pública de recursos representando a hierarquia de alocação de endereços IP e números AS, com repositórios distribuídos para objetos assinados usados na segurança de roteamento. Ele descreve como um titular legítimo pode autorizar um ou mais AS a originar rotas para um espaço de endereçamento e como essas autorizações verificáveis podem suportar filtros de rota.

Esta arquitetura segue a alocação de recursos. A IANA está na raiz da hierarquia de alocação. Os RIRs gerenciam a alocação de endereços e números AS em regiões definidas. Certificados de recursos atestam as participações; ROAs fornecem autorização de origem. O certificado não é um artefato decorativo. É uma declaração que pode afetar se uma rota é considerada válida, inválida ou não encontrada por operadores que usam validação de origem RPKI. Um registro de registro torna-se assim uma evidência de roteamento.

A consequência de governança é direta. Quando um registro controla o serviço RPKI hospedado para um titular, ele não está apenas mantendo um recurso de site. Ele está operando uma parte da evidência de origem de rota do titular. Quando um registro altera o estado do certificado após uma transferência, comprometimento de conta, ordem judicial, não pagamento, revisão de sanções, falecimento do titular, fusão de empresas, litígio ou fraude suspeita, essa mudança pode passar do escritório do registro para o cache do validador e, em seguida, para o filtro de rota. A distância entre governança e roteamento diminui.

Isso não significa que os RIRs devam evitar a autoridade RPKI. A estrutura de alocação existente tornou natural o envolvimento dos RIRs. A RFC 6480 afirma que a estrutura do PKI corresponde à alocação de recursos existente, tornando a gestão uma extensão natural das organizações já responsáveis pela alocação de recursos. Ela também afirma que os certificados de recursos não verificam identidade pessoal ou organizacional no sentido usual de PKI pública; eles atestam as participações de recursos. Esse limite reduz alguma responsabilidade enquanto levanta outra questão: que fato de registro o certificado é competente para expressar?

A resposta deve ser restrita. Um certificado de recursos deve expressar a autoridade de titularidade de recursos e o estado de delegação associado, não o ponto de vista de um registro sobre todos os problemas comerciais, políticos ou morais em torno do titular. Um ROA deve expressar a autorização de origem de rota em um estado de recursos reconhecido, não resolver todas as disputas subjacentes. Um repositório RPKI deve publicar evidências criptográficas atuais, não se tornar uma ferramenta disciplinar opaca. Quanto mais os operadores confiam no resultado, mais importante se torna manter a autoridade de entrada precisa.

A análise dos domínios de falha começa aqui. Uma falha de governança de registro pode se tornar uma falha RPKI se o registro puder revogar incorretamente, não publicar, recusar-se a atualizar, atrasar a transferência, gerenciar mal a publicação delegada, perder o controle da conta, interpretar mal a autoridade do titular ou aplicar uma suposição de política comum de forma muito ampla. Uma falha de validador pode se tornar uma falha de roteamento mesmo que o registro esteja correto. Uma falha de repositório pode se tornar uma falha de dados desatualizados. Uma renovação de âncora de confiança pode se tornar uma falha de configuração global.

Uma disputa legal pode se tornar um atraso no estado do certificado.

Nenhum desses riscos é resolvido dizendo que existem cinco RIRs. O mesmo operador pode depender dos cinco. O mesmo validador pode buscar os cinco. O mesmo grande rede pode aplicar filtros de rota com base nos cinco. O mesmo programa do NRO pode empurrar os cinco para documentação e funcionalidades comuns. O sistema é distribuído de algumas maneiras e concentrado em outras. O mapa de resiliência deve mostrar ambos.

O TAL é um pequeno arquivo com grande significado institucional

O Trust Anchor Locator é um dos exemplos mais claros de concentração oculta.RFC 6490explica que uma âncora de confiança em RPKI é representada por um certificado de autoridade de certificação X.509 autoassinado, e que o TAL especifica os dados usados para recuperar e verificar a autenticidade de uma âncora de confiança. O TAL contém uma URI e o material de chave pública usado pelo software da parte confiante. O objetivo é evitar redistribuir a âncora de confiança sempre que o conjunto de recursos de números da Internet associados à âncora de confiança muda, desde que a chave pública e o local permaneçam estáveis.

Esta descrição parece técnica, mas o TAL também é um objeto de dependência institucional. Uma parte confiante que configura um TAL decide em qual autoridade confiar para certificados de recursos de uma região. Se o local do TAL muda, se a chave muda, se o repositório está indisponível, se o certificado da AC é mal gerenciado, se uma renovação é mal comunicada, ou se uma crise levanta questões sobre quem pode autorizar mudanças, o problema não é apenas criptográfico. É uma questão de governança da confiança.

O repositório de conteúdo RPKI do NRO torna essa dependência visível listando as informações de TAL para cada RIR. Ele também direciona para materiais de CPS e recursos de suporte. Isso é transparência útil. Permite que os operadores encontrem o que precisam. Mas não responde às questões mais profundas de resiliência. Quem decide quando um TAL deve mudar? Qual aviso prévio é necessário? O que acontece se um operador de emergência precisa manter o serviço? Uma ordem de um tribunal local pode afetar o material da âncora de confiança? Como as reivindicações conflitantes são tratadas?

O que acontece se um registro está operacional, mas enfraquecido em sua governança? Como os validadores lidam com o material antigo e novo durante a transição?

Certificados de âncora de confiança de curta duração, métodos de publicação de repositório, suporte a serviços delegados e design de serviços hospedados afetam todos este quadro. Oroteiro do NRO para serviços principais de RPKIlista o serviço hospedado como disponível em todos os cinco RIRs, o serviço delegado da APNIC, ARIN, LACNIC e RIPE NCC com todos os RIRs visados para o final do primeiro trimestre de 2026, metas de gerenciamento de API, objetos ROA via interface e API, e certificados TA de curta duração oferecidos por APNIC, ARIN e LACNIC com meta para todos até o final de 2025. Essas lacunas e metas de funcionalidades são fatos de governança, não apenas notas de produto.

Se cada RIR eventualmente oferece o mesmo conjunto básico de funcionalidades, algumas barreiras de adoção caem. Um titular multirregional pode projetar melhores controles internos. As expectativas das partes confiantes se tornam mais previsíveis. A documentação pode melhorar. Mas datas-alvo comuns não criam automaticamente domínios de falha independentes. Se a mesma suposição sobre renovação de âncoras de confiança está embutida em todos os lugares, um erro pode se propagar. Se todas as regiões adotam um serviço hospedado padrão semelhante, a autonomia delegada pode permanecer subutilizada.

Se todas as regiões alinham a terminologia, mas não os direitos de recurso, os operadores podem entender melhor uma recusa sem poder contestá-la.

O TAL é, portanto, um bom teste de resiliência. Conte o número de TALs configurados, depois pergunte quantos caminhos de governança independentes os protegem. Conte o número de repositórios, depois pergunte se as partes confiantes tratam as falhas de maneira diferente. Conte o número de marcas de RIR, depois pergunte se um programa comum do NRO ou uma decisão de implementação comum pode mudar todas as expectativas dos operadores de uma só vez. Conte o número de certificados, depois pergunte qual ator legal pode autorizar a continuidade de emergência.

A resposta variará de acordo com o risco. A disponibilidade do repositório pode ser mais distribuída do que a interpretação legal. Os controles multifatoriais do portal podem ser específicos da região. O comportamento de implementação do validador pode ser global. A comunicação sobre âncoras de confiança pode ser parcialmente coordenada. A continuidade de emergência pode ser subdefinida. O importante é mapear esses domínios explicitamente, e não presumir que logotipos plurais equivalem a resiliência plural.

A conveniência do serviço hospedado não é o mesmo que controle do operador

A página de referência do NRO sobre serviços RPKI indica que o serviço hospedado está disponível nos cinco RIRs. O serviço hospedado é valioso porque muitos detentores de recursos carecem de pessoal, tempo ou engenharia de segurança para executar RPKI delegado. Uma pequena rede pode criar ROAs por meio de um portal de registro familiar. Um operador maior pode gerenciar a evidência de origem de rota sem operar sua própria AC. O serviço hospedado acelera a adoção, e a adoção é importante porque RPKI só melhora a segurança de roteamento quando detentores suficientes publicam objetos corretos e redes suficientes os validam.

O custo de governança é a dependência. No modo hospedado, o portal do registro, a autenticação da conta, o modelo de autorização, o registro de alterações, o suporte, o processo de pessoal, o gerenciamento de falhas e a interpretação legal estão entre o titular e sua evidência de origem de rota. Se a conta do titular é comprometida, o processo do registro importa. Se uma transferência é concluída, o processo de transferência importa. Se uma correção urgente de maxLength é necessária, o serviço de suporte importa. Se a triagem de sanções ou uma revisão legal bloqueia uma conta, o estado do certificado pode se tornar dano colateral.

Se uma crise de registro interrompe o acesso do pessoal ou os sistemas de pagamento, o serviço RPKI hospedado faz parte do problema de continuidade do serviço.

O RPKI delegado altera o equilíbrio. Ele permite que o titular execute sua própria AC ou arranjo de publicação sob um certificado emitido pelo registro. Pode reduzir a dependência do portal e dar aos operadores experientes um controle mais direto. Mas o serviço delegado não é uma fuga do registro. O certificado pai, a âncora de confiança, o reconhecimento de recursos, as atualizações de transferência e os limites de política ainda importam. A delegação move alguns domínios de falha operacionais para longe do registro, enquanto deixa outros com ele.

A visão geral dos serviços RPKI do NRO mostra que a disponibilidade do serviço delegado e as funcionalidades de publicação híbrida não são uniformes. O serviço hospedado é universal. O serviço delegado está listado para quatro RIRs na visão geral de dezembro de 2025, com AFRINIC indicado como não oferecendo naquele momento. O serviço de publicação híbrida também varia. O suporte a API, histórico de transações, sugestões de coletores de rotas e alinhamento entre fontes RPKI e IRR variam.

Essas diferenças são importantes porque indicam aos operadores quais falhas são locais, quais são evitáveis e quais são inerentes à estrutura de confiança pai.

Uma auditoria de resiliência deve, portanto, fazer três perguntas para cada detentor de recursos. Primeiro, o que o titular pode fazer sem o pessoal do registro se algo quebrar hoje? Segundo, o que o titular pode fazer sem o portal do registro se as credenciais, status de pagamento, revisão de sanções, um processo judicial local ou filas de suporte se tornarem problemáticos? Terceiro, o que não pode ser feito sem a ação do registro pai, independentemente da competência do titular?

Para um pequeno usuário hospedado, a resposta pode ser: quase tudo depende da interface do registro e do modelo de suporte. Para um operador delegado, a resposta pode ser: a publicação rotineira de ROAs é independente, mas o estado do certificado pai, mudanças de recursos, transferência e eventos de âncora de confiança permanecem dependentes do registro. Para um titular multirregional, a resposta pode diferir entre RIRs. Para um provedor de nuvem ou trânsito downstream, a resposta pode ser invisível a menos que o titular a documente.

É por isso que "cinco RIRs oferecem RPKI" não basta. Um sistema pode estar amplamente disponível e ainda assim concentrado nos direitos de decisão. A questão não é apenas se uma funcionalidade existe. É quem pode exercê-la em momentos de estresse, quem pode anulá-la, quem pode recuperá-la, quem pode auditá-la e quem arca com o custo quando o registro e o operador discordam.

A coordenação melhora a consistência e concentra suposições

O programa RPKI do NRO é franco quanto aos seus objetivos. Para 2025, ele afirma que o programa se concentrou em transparência, robustez e segurança do sistema RPKI, incluindo uma solução de consulta com a comunidade técnica para abordar preocupações sobre a configuração atual das âncoras de confiança. Ele também visa aumentar a consistência da experiência do usuário por meio de documentação consolidada, terminologia padronizada, melhores práticas recomendadas, análise de lacunas das interfaces RPKI entre RIRs e um roteiro para um conjunto acordado de funcionalidades principais.

Isso é exatamente o que um órgão de coordenação maduro deveria fazer. RPKI é importante demais para ser deixado a cinco culturas de produto não relacionadas. Os operadores precisam de clareza. Os validadores precisam de comportamento previsível. Os titulares multirregionais precisam de conceitos semelhantes. Os pesquisadores de segurança precisam de artefatos comparáveis. A confusão aumenta erros de configuração, e uma má configuração pode tornar rotas legítimas inválidas. A coordenação pode reduzir esse risco.

O risco de concentração está na palavra "acordado". Um conjunto acordado de funcionalidades principais pode fortalecer a região mais fraca. Também pode fazer com que cada região herde o mesmo ponto cego. Se a base acordada diz pouco sobre direitos de recurso após suspensão de certificado, todas as regiões podem considerar esse silêncio como normal. Se a base acordada favorece a conveniência da hospedagem em detrimento da autonomia delegada, a adoção pode aumentar enquanto o controle do operador permanece fraco.

Se a base acordada melhora a transparência, mas não a autoridade de emergência, uma crise pode ser bem documentada enquanto permanece não resolvida. Se a base acordada normaliza a terminologia sem normalizar a notificação pública de incidentes, os operadores podem falar sobre falhas de forma mais consistente enquanto ainda carecem de melhores evidências.

RPKI é particularmente sensível a suposições comuns porque as partes confiantes tendem a automatizar. Um erro legal ou de governança não precisa convencer cada operador humano individualmente uma vez que é expresso como estado de certificado e consumido por validadores. O resultado de origem de rota pode viajar por caches, roteadores e filtros. Essa automação é o objetivo do RPKI; é também por que a governança deve ser precisa.

A resposta correta não é manter cada RIR diferente. A diferença arbitrária também é uma falha. Se uma região carece de serviço delegado, acesso a API, histórico de transações ou suporte confiável, os operadores sofrem. Se uma região usa terminologia confusa, a adoção sofre. Se uma região tem controles de segurança fracos, todo o sistema é menos crível. A resposta correta é classificar quais diferenças são prejudiciais e quais diferenças trazem resiliência.

Diferenças prejudiciais incluem gerenciamento de ROA pouco claro, autenticação fraca, histórico de transações ausente, má disponibilidade de repositório, suporte inconsistente, conselhos inconsistentes sobre maxLength, instruções de TAL vagas e pouca visibilidade entre modo hospedado e delegado. Diferenças de resiliência incluem revisão independente de incidentes, garantias legais específicas da região, arranjos de publicação alternativos, capacidade de executar serviços delegados, equipes operacionais separadas, pilhas de software diversas, vias de recurso locais, medições de serviço público e planos de transferência publicados.

O NRO pode coordenar a primeira categoria sem apagar a segunda. Ele pode exigir que cada RIR suporte uma linha de base segura enquanto permite diferentes designs de responsabilidade. Ele pode alinhar a terminologia enquanto preserva as divulgações legais locais. Ele pode normalizar os rótulos de gravidade de incidentes enquanto exige que cada RIR publique sua própria declaração de causa raiz. Ele pode recomendar o serviço delegado sem forçar cada operador a uma arquitetura idêntica. Ele pode consultar sobre a configuração das âncoras de confiança enquanto publica uma análise de domínios de falha para as opções.

A expressão "sistema RPKI global único" deve, portanto, ser manuseada com cuidado. A camada de segurança de roteamento é global em seu efeito. A hierarquia de alocação é global em sua estrutura. O ecossistema de partes confiantes é global em seu consumo. Mas a resiliência melhora quando o sistema contém diversidade controlada: caminhos de publicação independentes, revisão independente, razões regionais independentes e a capacidade do operador de delegar para longe de uma dependência hospedada desnecessária. Um sistema global único não deve significar uma suposição de governança única e incontestada.

Domínios de falha que devem ser medidos

O primeiro domínio de falha é a autoridade. Quem tem o direito de criar, revogar, modificar ou recusar objetos RPKI? A resposta pode envolver o titular dos recursos, o usuário do portal, o representante legal, o pessoal do registro, a organização patrocinadora, o NIR, a contraparte de transferência, o oficial nomeado pelo tribunal ou o operador de emergência. Se esses papéis são confusos, o risco não é técnico. É ambiguidade de autoridade expressa por estado técnico.

O segundo domínio é o controle de contas. O RPKI hospedado depende de portais. Os portais dependem de credenciais, autenticação multifatorial, atribuição de funções, suporte de pessoal e recuperação. A visão geral de serviços do NRO relata funcionalidades de autenticação multifatorial nos portais dos RIRs, com diferentes métodos e limites obrigatórios. Uma auditoria de segurança não deve simplesmente perguntar se a autenticação multifatorial existe. Deve perguntar quem pode adicionar um usuário, redefinir um fator, aprovar uma função, recuperar de um comprometimento e ver o rastro de transações.

O terceiro domínio é a publicação. RPKI usa repositórios para certificados, ROAs, manifestos e objetos associados. Uma falha de repositório, conteúdo desatualizado, problemas de manifesto, problemas com RRDP ou rsync, e o comportamento de recuperação do validador podem todos afetar as informações de origem de rota. O domínio não se limita ao data center do RIR. Inclui distribuição de conteúdo, suporte a protocolos, monitoramento, avisos de incidentes e comportamento de cache das partes confiantes.

O quarto domínio é a configuração de âncoras de confiança. Os TALs devem ser distribuídos de forma segura, configurados pelas partes confiantes e mantidos através de mudanças de chave ou local. Uma preocupação com uma âncora de confiança pode afetar todos os operadores que dependem de um determinado TAL. Se vários RIRs coordenam mudanças de âncoras de confiança através do mesmo programa e cronograma, a comunicação melhora, mas um risco de temporização comum aparece. Se eles não coordenam nada, as partes confiantes enfrentam confusão. O design de resiliência deve equilibrar esses riscos.

O quinto domínio é o modo de serviço. Arranjos hospedados e delegados impõem responsabilidades diferentes ao registro e ao titular. Uma auditoria madura deve indicar a porcentagem de recursos em serviço hospedado, serviço delegado e publicação híbrida quando disponível, e não apenas se a opção existe. Uma funcionalidade não utilizada pela maioria dos titulares não é uma camada de resiliência eficaz.

O sexto domínio é a intervenção legal. Ordens judiciais, listas de sanções, insolvência, administração judicial, fusões, reivindicações de credores, investigações de fraude e solicitações governamentais podem todas criar pressão sobre o estado do certificado. O registro deve saber quais fatos pode verificar e quais exigem julgamento externo. Também precisa de remédios reversíveis: congelamentos temporários, anotações, congelamentos estreitos, auditorias independentes, suspensões de emergência e atualizações em fases, em vez de revogação irreversível quando as evidências são incompletas.

O sétimo domínio é a direção comum do programa. Se o programa do NRO define um roteiro de funcionalidades, terminologia, melhores práticas e postura de resposta, esse programa se torna um domínio de falha para suposições. Deve, portanto, publicar não apenas resultados, mas também alternativas consideradas, opções rejeitadas, trade-offs de risco e pontos de vista técnicos divergentes quando existem.

O oitavo domínio é o comportamento dos validadores. Os RIRs publicam conteúdo assinado, mas o software das partes confiantes e os filtros dos operadores decidem como esse conteúdo afeta o roteamento. Se os principais validadores interpretam casos limite de forma diferente, o mesmo estado de repositório pode produzir resultados operacionais diferentes. Se as principais redes convergem para uma única implementação, a diversidade de software diminui. Se os servidores de rota aplicam filtragem RPKI de forma localizada, o efeito difere da filtragem de nível 1.

Esses domínios downstream estão além dos logotipos dos RIRs, mas moldam a resiliência real.

O nono domínio é a continuidade de emergência. O rascunho do documento de governança de RIRs 2025 define conceitos de continuidade de emergência e operador de emergência, e o Fundo de Estabilidade do NRO descreve suporte mútuo em caso de interrupções graves. A continuidade RPKI deve fazer parte de qualquer plano de emergência. O público deve saber o que continua, o que é congelado, quem pode assinar, quem pode publicar, como objetos antigos são tratados e como a autoridade retorna ao normal.

O último domínio é a evidência pública. Os operadores precisam de evidências, não de conforto. Medidas de disponibilidade de serviço, saúde do repositório, relatórios de incidentes, avisos de mudança de TAL, histórico de transações, tempos de resposta de suporte, adoção de serviço delegado, resultados de recurso e exercícios de emergência devem ser suficientemente visíveis para permitir que o mercado avalie a resiliência. Sem evidências, cinco logotipos tornam-se teatro.

O que acontece quando a governança se torna estado de certificado

Considere uma transferência. O vendedor tem ROAs. O comprador precisa de autorização de origem de rota. O registro deve reconhecer a transferência, atualizar os registros de recursos, preservar a continuidade e evitar que ROAs antigos persistam por muito tempo. Se a transferência é ordinária, o processo é administrativo. Se a transferência é contestada, financiada, transfronteiriça, afetada por tribunal, filtrada por sanções ou atrasada por documentação, o estado RPKI torna-se uma superfície de risco. A autorização antiga pode sobreviver por muito tempo. A nova autorização pode chegar tarde demais.

Um erro de maxLength pode tornar rotas mais específicas legítimas inválidas. Um atraso no suporte pode criar uma interrupção no cliente.

Agora considere uma sucessão empresarial. Um titular histórico muda de nome, funde-se ou dissolve-se em uma subsidiária. O registro deve identificar quem pode agir. Um usuário do portal ainda pode ter credenciais, mas não autoridade. Um diretor pode ter autoridade, mas não acesso ao portal. Um banco pode exigir provas. Um tribunal pode emitir uma ordem. O serviço RPKI hospedado pode se tornar o lugar onde esses papéis colidem. O estado do certificado não deve mudar até que a autoridade esteja clara, mas um atraso indefinido pode prejudicar o roteamento. O remédio não é amplo poder discricionário.

É uma escala de evidências com continuidade temporária.

Considere uma crise de registro. Se um registro não pode operar normalmente, questões de RPKI surgem imediatamente. Os certificados existentes podem permanecer válidos? Quem monitora a atualidade do repositório? Quem responde a solicitações urgentes de correção de ROA? Quem pode suspender mudanças perigosas sem congelar o serviço ordinário? Quem se comunica com as partes confiantes? Um operador de emergência tem autoridade de assinatura, autoridade de publicação ou apenas autoridade de suporte? Como as chaves são protegidas? Como a devolução é auditada?

O rascunho de governança do ciclo de vida do NRO é relevante porque reconhece que a operação dos RIRs e uma possível perda de reconhecimento exigem mais do que critérios de entrada. Mas RPKI precisa de um anexo de continuidade ainda mais detalhado. Um registro pode ser reconhecido em geral e ainda ter um problema temporário de assinatura RPKI. Um registro pode ter RPKI em operação e ainda carecer de confiança dos membros. Uma proposta de perda de reconhecimento pode levar tempo enquanto a evidência de roteamento deve ser mantida diariamente. A camada de certificado não espera que a teoria institucional se acalme.

O mesmo se aplica a sanções e restrições legais. Um registro pode precisar cumprir a lei aplicável. Pode precisar impedir serviços a uma parte sancionada. Pode precisar evitar facilitar a fraude. Mas uma retenção legal deve ser precisa. Deve dizer se os ROAs existentes permanecem, se novos ROAs são bloqueados, se a revogação é necessária, se a publicação delegada continua, se um tribunal ou regulador se pronunciou, se os prefixos não afetados continuam e se o titular tem via de recurso. Caso contrário, o estado do certificado torna-se uma aplicação oculta.

O padrão de governança deve ser a evidência de roteamento menos destrutiva. Quando os fatos são incertos, preservar o último estado seguro conhecido, se possível. Quando uma autorização de rota é claramente não autorizada, corrija-a. Quando a autoridade é contestada, marque e suspenda a ação contestada em vez de quebrar o serviço não afetado. Sob coação legal, descreva a consequência no serviço tão estreitamente quanto a confidencialidade permitir. Em caso de erro do registro, publique a correção e o cronograma. Quando uma ação de emergência é tomada, torne-a reversível, a menos que a segurança imediata exija o contrário.

Esse padrão não enfraqueceria o RPKI. Fortaleceria a confiança ao tornar o estado do certificado crível. Os operadores não precisam de conforto perfeito. Eles precisam saber se uma mudança de validade reflete autorização de roteamento, dados desatualizados, restrição legal, comprometimento de conta, atraso de transferência, falha de registro ou crise de governança. Estes são fatos diferentes com remédios diferentes.

A confiança comum precisa de evidências independentes

O papel de coordenação do NRO pode produzir um sistema RPKI mais forte se insistir em evidências independentes dentro de padrões comuns. Uma linha de base compartilhada não deve apenas dizer que todos os RIRs fornecem serviço hospedado. Deve publicar métricas de serviço comparáveis: disponibilidade do repositório, latência de atualização, número de incidentes, tempo de resposta do suporte, prazos de aviso de mudança de TAL, disponibilidade de histórico de transações, adoção de serviço delegado, exercícios de emergência e publicação de causas raiz.

Evidências comparáveis permitem que os operadores vejam onde a resiliência é real e onde é aspiracional.

A linha de base também deve publicar mapas de domínios de falha. Para cada RIR, o mapa deve mostrar o portal hospedado, o caminho delegado, a publicação do repositório, o gerenciamento de TALs, CPS, recuperação de conta, transferência, retenção legal, operador de emergência, escalonamento de suporte e canal de incidente público. Para o programa do NRO como um todo, o mapa deve mostrar quais decisões são conjuntas, quais são regionais, quais envolvem ICANN, quais envolvem IANA, quais dependem de comportamento definido por RFC e quais dependem da implantação de operadores privados.

A revisão independente deve fazer parte do mapa. Se um titular de recursos acredita que uma alteração de ROA foi recusada incorretamente, quem revisa? Se um ponto de publicação delegado é mal classificado, quem revisa? Se uma transferência deixa uma autorização desatualizada, quem revisa? Se um registro invoca uma restrição legal, um titular afetado pode ver o suficiente para contestar a consequência no serviço? Se uma prática comum de RPKI do NRO causa dano, existe uma via para contestar a prática comum ou apenas cinco tickets de suporte locais?

O órgão de revisão não precisa ser um tribunal. Muitos problemas são técnicos e urgentes. O primeiro revisor pode ser uma equipe de escalonamento interno. O segundo pode ser um painel técnico independente. O terceiro pode ser um recurso institucional se o problema diz respeito a autoridade ou justiça. Os tribunais permanecem relevantes para direitos legais, fraude, autoridade corporativa ou coação legal. O ponto é que a evidência de roteamento automatizada não deve remover a contestabilidade humana quando a disputa é sobre a autoridade do registro em vez da sintaxe criptográfica.

A dissidência também deve ser visível. Se um RIR acredita que uma linha de base comum de RPKI proposta cria risco legal em sua região, essa dissidência deve ser publicada com razões. Se um RIR não pode implementar uma funcionalidade devido à lei local, a lacuna deve ser nomeada. Se um RIR excede a linha de base com autonomia de serviço delegado mais forte ou direitos de recurso, essa melhoria não deve ser escondida na documentação regional. A confiança comum é mais forte quando os operadores podem ver a variação e julgá-la.

Engenheiros de segurança às vezes temem que muita discussão sobre governança desacelere a implantação. Esse risco é real. A adoção de RPKI já levou anos, e vazamentos de rota e sequestros continuam sendo ameaças operacionais. Mas o risco de governança oculto também desacelera a adoção. Os operadores hesitam quando temem erros unilaterais de certificado, revogação pouco clara, custódia hospedada, recuperação fraca ou retirada legal. Um modelo de domínio de falha mais claro pode aumentar a adoção porque mostra o que é controlado e o que permanece arriscado.

Portanto, o melhor argumento para o programa do NRO não é "confie em nós, os cinco RIRs concordam". É "aqui estão as bases comuns, aqui estão os domínios independentes, aqui estão as lacunas conhecidas, aqui está a via de recurso, aqui está o plano de emergência, aqui estão as evidências". É uma mensagem de segurança mais forte porque trata a confiança como verificável.

A resiliência deve ser testada por exercícios, não por declarações

A continuidade RPKI precisa de exercícios. Os exercícios devem ser suficientemente públicos para melhorar a confiança e suficientemente privados para proteger chaves e superfícies de ataque. Um exercício de comunicação de âncora de confiança pode testar se as partes confiantes recebem o aviso, entendem o cronograma e atualizam os validadores com segurança. Um exercício de falha de repositório pode testar o comportamento de cache desatualizado e a mensagem do operador. Um exercício de comprometimento de portal hospedado pode testar o congelamento de contas, a revisão de transações e a notificação ao titular.

Um exercício de transferência pode testar a limpeza de ROAs antigos e o tempo de novos ROAs. Um exercício de falha de serviço delegado pode testar a coordenação pai sem assumir controle desnecessário.

Um exercício de emergência de registro é particularmente importante. Deve perguntar o que acontece se um registro perde pessoal crítico, enfrenta insolvência, perde autoridade do conselho, sofre um cenário de administrador nomeado pelo tribunal, ou não pode operar seu portal. O Fundo de Estabilidade Conjunto dos RIRs reconhece cenários como dificuldade financeira, perda de pessoal crítico, desastres naturais, instabilidade política, atividade criminosa e problemas de infraestrutura estrutural. RPKI deve ser um serviço nomeado em qualquer evento desse tipo.

O exercício deve identificar quem pode manter o material existente válido, quem pode publicar avisos de emergência, quem pode processar correções de segurança urgentes e quais ações são congeladas até que a autoridade seja restaurada.

O resultado não deve revelar detalhes sensíveis sobre gerenciamento de chaves. Deve revelar classes de serviço. Por exemplo: a publicação do repositório existente continua; a criação de novos ROAs está disponível para titulares autenticados; a recuperação de conta de alto risco requer aprovação dupla; mudanças de certificado relacionadas a transferência são processadas sob revisão de emergência; mudanças legais contestadas são suspensas; recursos não afetados continuam; atualizações públicas aparecem em uma cadência definida. Tais declarações transformam a resiliência de uma garantia em uma promessa operacional.

Os exercícios também devem incluir titulares multi-RIR. Uma empresa com recursos em múltiplas regiões pode enfrentar diferentes controles de portal, opções delegadas, horários de suporte e requisitos legais. Um incidente global pode exigir mudanças em mais de uma região. Se o programa do NRO deseja remover barreiras para operadores que criam objetos RPKI através de múltiplos RIRs, deve testar o percurso de emergência multirregional do usuário.

As partes confiantes devem fazer parte do exercício. RPKI só é completo quando validadores e redes consomem os dados. Um registro pode publicar corretamente enquanto validadores armazenam em cache incorretamente, interpretam mal casos limite ou falham em alertar operadores. Um exercício deve envolver as principais implementações de validadores, servidores de rota, provedores de trânsito, pontos de troca e grandes redes em nuvem, quando aplicável. O NRO não os controla, mas pode coordenar a comunicação e publicar lições.

A auditoria deve rejeitar métricas de vaidade. O número de ROAs é útil, mas incompleto. A porcentagem de prefixos roteados cobertos é útil, mas incompleta. O número de RIRs oferecendo uma funcionalidade é útil, mas incompleto. A resiliência exige tempo de detecção, tempo de correção, comportamento em dados desatualizados, caminho de suporte, contestabilidade do titular, fallback delegado, transparência de incidentes e autoridade de emergência.

A métrica mais séria é o raio da explosão. Se um registro toma uma decisão RPKI errada, até onde o efeito se propaga? Se uma linha de base do NRO contém uma suposição errada, quantas regiões a herdam? Se um comportamento de validador está errado, quantas redes o aplicam? Se uma comunicação de âncora de confiança falha, quantas partes confiantes são afetadas? Se uma teoria legal congela mudanças de certificado, quantos prefixos perdem flexibilidade operacional? Um sistema que não pode responder a perguntas sobre o raio da explosão não é suficientemente resiliente.

Público não deve ter que deduzir o modelo de confiança

A confiança RPKI deve ser explicada em linguagem pública. Nem todos os operadores são especialistas em PKI. Nem todos os advogados entendem ROAs. Nem todos os tribunais entendem validadores. Nem todos os conselhos conhecem a diferença entre serviço hospedado e delegado. Um sistema de registro maduro deve tornar o modelo de confiança legível sem simplificá-lo excessivamente.

Os documentos básicos do NRO são um bom começo. Eles comparam modos de serviço, suporte a objetos, APIs, autenticação e funcionalidades relacionadas. O repositório de conteúdo direciona para portais, informações de TAL e documentos CPS. A página do programa explica por que a consistência é um objetivo. O roteiro nomeia datas-alvo. Esses documentos tornam o sistema mais fácil de inspecionar.

A camada ausente é a tradução da governança. Cada RIR deve publicar um breve documento público que responda: o que nosso certificado RPKI prova; o que não prova; quem pode solicitar alterações; como os papéis são verificados; como lidamos com transferências; como lidamos com disputas; como lidamos com comprometimento de conta; o que acontece sob restrição legal; o que acontece em emergência do registro; como um titular pode obter revisão urgente; como uma parte confiante pode relatar problemas de repositório ou TAL; como os serviços hospedado e delegado diferem em controle?

Esta tradução deve evitar alegações legais excessivas. Um certificado é uma evidência do estado reconhecido de titularidade de recursos e do relacionamento de autorização, não uma verificação de identidade universal. Um ROA é uma autorização de origem de rota, não uma garantia de segurança completa. Um resultado de origem de rota válido não significa que o caminho é seguro. Um resultado inválido pode vir de má configuração tanto quanto de ataque. RPKI melhora a evidência de roteamento; não remove o julgamento operacional.

A explicação pública também deve evitar subestimação institucional. Se a ação do registro pode afetar a validade da origem da rota, o registro deve dizer. Se um atraso no suporte pode afetar o roteamento, diga. Se o serviço delegado reduz alguma dependência, mas não a dependência da confiança pai, diga. Se uma mudança de TAL requer atenção das partes confiantes, diga. Os usuários confiam mais em instituições quando os limites são visíveis.

A linguagem deve ser consistente, mas não vazia. "Robusto, coordenado e seguro" é uma declaração de missão. Os operadores precisam dos nomes por trás: chave, TAL, repositório, ROA, manifesto, conta, função, log, incidente, recurso, contato de emergência, devolução, auditoria. A governança se torna crível quando esses nomes estão ligados a decisões.

Um padrão melhor para o programa do NRO

O NRO deve continuar a coordenar RPKI. A alternativa é pior: cinco serviços desiguais, confusão evitável, controles de segurança mais fracos e adoção multirregional mais difícil. Mas a coordenação deve ser julgada por um padrão mais alto do que simples alinhamento de funcionalidades. O programa deve publicar um registro de domínios de falha.

O registro listaria cada função RPKI principal e classificaria sua independência. Criação de ROA hospedado: portal regional com linha de base comum. Serviço delegado: disponibilidade regional com confiança pai. Configuração de âncoras de confiança: TALs regionais com risco de consulta conjunta. Publicação de repositório: infraestrutura regional com consumo global por partes confiantes. Gerenciamento de API: implementação regional com objetivo de funcionalidade comum. Relato de incidentes: dever regional com termos de gravidade comuns. Continuidade de emergência: suporte conjunto com autoridade regional.

Restrição legal: direito regional com consequências de roteamento globais. Comunicação de validadores: ecossistema compartilhado além do controle dos RIRs.

Para cada função, o registro deve nomear a falha primária, dependências secundárias, mitigação do titular, mitigação da parte confiante, métrica pública e caminho de revisão. Isso tornaria a resiliência testável. Também mostraria onde os padrões comuns reduzem o risco e onde o concentram.

O programa também deve publicar uma taxonomia comum de incidentes. Uma falha de repositório não é o mesmo que uma falha de portal. Uma falha de notificação de TAL não é o mesmo que um ROA incorreto. Um ROA de transferência desatualizado não é o mesmo que um comprometimento de conta. Uma retenção legal não é o mesmo que uma falha técnica. Os operadores precisam dessas distinções porque as remediações diferem.

Finalmente, o programa deve proteger evidências regionais independentes. Cada RIR deve publicar seus próprios CPS, histórico de incidentes, métricas de serviço, adoção de serviço delegado, compromissos de suporte e restrições legais locais. O NRO deve agregar sem apagar. O valor dos cinco RIRs não é exibir cinco emblemas. É preservar independência regional suficiente para que falhas, aprendizado e reforma não ocorram todos em uma única sala fechada.

Fontes e limites

Esta análise baseia-se na RFC 6480 para arquitetura RPKI, RFC 6490 para estrutura do Trust Anchor Locator, página do programa RPKI do NRO para objetivos do programa comum, documentos de base RPKI comum do NRO e visão geral de serviços para funcionalidades entre RIRs, repositório de conteúdo RPKI do NRO para referências de TAL e CPS, e roteiro do NRO para alinhamento de funcionalidades alvo. Também utiliza documentos de governança do NRO apenas para contextualizar continuidade de emergência e reconhecimento. As fontes apoiam a afirmação de que RPKI é coordenado entre os cinco RIRs e que as funcionalidades de serviço variam.

Elas não provam uma falha comum real, uma decisão oculta sobre âncoras de confiança ou uma concentração ilícita. O argumento é um padrão de resiliência: conte os domínios de falha, não os logotipos.