Resumo

  • Uma autorização de origem de rota não é uma declaração independente. Ela é aceita apenas por meio de um caminho de certificado válido com raiz em uma âncora de confiança de um RIR. A AC pai pode emitir, substituir, reduzir ou revogar o certificado sob o qual as ROAs de um operador são assinadas.
  • Registro e certificação são deliberadamente alinhados. Isso faz com que a declaração criptográfica reflita os registros atuais de recursos, mas também significa que uma decisão de transferência, erro de status contratual, ordem judicial ou ação na conta pode alterar o conjunto de autorizações de rota vistas pelas partes confiantes.
  • A revogação não emite um comando para a tabela de roteamento global. Uma ROA perdida pode fazer com que um anúncio se torne NotFound, enquanto uma autorização alterada ou concorrente pode torná-lo Invalid. As redes então aplicam suas próprias políticas de roteamento. O efeito é distribuído, variável e potencialmente sério.
  • O incidente de recursos legados de dezembro de 2020 do RIPE NCC demonstrou o mecanismo de propagação: um erro no status contratual reduziu certificados, excluiu ROAs hospedadas e fez com que ROAs delegadas desaparecessem ou reivindicassem demais. É evidência de um caminho de controle real, não evidência de uma taxa de falha universal.
  • O RPKI delegado dá ao operador sua própria chave de assinatura e controle operacional sobre sua CA filha. Ele não remove o pai RIR. O pai ainda determina o conjunto de recursos certificados e pode revogar o certificado filho sob condições declaradas.
  • Uma governança mais forte deve incluir motivos prospectivos de revogação, notificação baseada em risco, prévias de mudanças legíveis por máquina, planos de transferência make-before-break, restauração de emergência, razões escritas, revisão independente e contabilidade pública de incidentes. Exclusões de responsabilidade não devem substituir a prevenção e a reparação.
  • A Number Resource Society pode contribuir construtivamente comparando regras de AC pai, publicando listas de verificação de continuidade e representando titulares menores em debates de política técnica. Sua defesa não confere autoridade de certificação nem prova um arranjo de confiança alternativo.

O pacote decisivo é avaliado longe do registro

Considere um anúncio comum de um prefixo do sistema autônomo de um operador. O operador configurou o BGP corretamente. Seus provedores de trânsito recebem a rota. Em outro lugar, no entanto, um validador de parte confiante buscou material RPKI, construiu um conjunto de autorizações de origem de rota validadas e passou os pacotes resultantes para os roteadores. Esses roteadores comparam o prefixo e a AS de origem com o conjunto de pacotes. O anúncio pode ser Valid, Invalid ou NotFound. Cada rede então aplica sua própria política.

O registro não está no caminho do pacote. Ele não pressiona um botão que retira a rota de todos os roteadores. No entanto, ele está acima da evidência criptográfica usada nessa decisão distribuída. Se o caminho do certificado para a ROA do operador deixar de validar, essa ROA não contribui mais com um pacote válido. Se outra autorização abrangente permanecer, a rota pode se tornar Invalid. Se nenhuma permanecer, geralmente se tornará NotFound. Uma rede que rejeita rotas Invalid pode então recusar o anúncio; uma rede que aceita rotas NotFound pode continuar a transportá-lo.

Essa sequência é o mecanismo que importa. O evento administrativo ocorre em uma AC pai. Repositórios distribuem os objetos alterados. Validadores atualizam suas visões locais. Roteadores recebem novos dados de validação. Políticas de rede independentes convertem esses dados em consequências de acessibilidade.

As lacunas e caches nessa cadeia são importantes. Validadores diferentes atualizam em momentos diferentes. Os operadores podem reter dados durante problemas no repositório. A política do roteador não é uniforme. Não há base honesta para afirmar que um evento de certificado desconecta instantaneamente um prefixo em todos os lugares. Há igualmente pouca base para tratar a revogação como uma edição administrativa inofensiva. A arquitetura foi projetada para que o status criptográfico pudesse influenciar o roteamento. A governança deve levar essa influência a sério sem exagerar sua uniformidade.

A assinatura do operador é condicional

A história atraente do RPKI é o controle do titular. Um titular de endereço autoriza uma AS de origem criando uma ROA. A criptografia permite que outros verifiquem que a declaração veio de uma chave associada aos recursos certificados. Esta é uma correção valiosa para um sistema de roteamento no qual os anúncios BGP não trazem nenhuma prova incorporada de que a origem é autorizada.

Mas a chave do titular não é soberana. A RFC 6480 descreve uma hierarquia alinhada com a alocação de recursos numéricos da Internet. Um certificado de recurso vincula uma chave pública a blocos de endereços IP e números AS. A validade de um objeto assinado depende de um caminho de certificação para uma âncora de confiança selecionada, da validade do certificado, das informações de revogação e dos recursos permitidos em cada nível.

Um operador que usa uma CA delegada controla a chave privada dessa filha. Um pai não pode usar essa chave para forjar a assinatura da filha. Essa distinção é substancial. Ela protege a integridade do próprio ato de assinatura do operador e permite automação local, subdelegação e escolhas de gerenciamento de chaves.

O pai retém um poder diferente. Ele pode emitir o certificado filho, alterar os recursos cobertos por um certificado de substituição ou colocar o certificado em uma lista de revogação. Uma assinatura filha sobre recursos não mais suportados por um caminho pai válido não pode se tornar válida por insistência matemática. O pai não precisa possuir a chave filha para fazer com que as afirmações da filha deixem de contar.

O RPKI hospedado comprime ainda mais a distinção. O RIR opera a CA do titular e armazena a chave privada em sua infraestrutura. O titular escolhe intenções de roteamento por meio de um portal ou interface, enquanto o serviço realiza a assinatura, renovação e publicação. A ROA resultante pode expressar com precisão a instrução do titular, mas a custódia criptográfica e a autoridade do pai estão localizadas dentro da mesma instituição. A conveniência, portanto, altera a alocação de controle, não apenas a quantidade de trabalho técnico.

A verdade do registro torna-se escopo criptográfico

O RPKI não foi acidentalmente anexado aos registros do RIR. Sua promessa central é que um certificado reflete uma delegação atual de recursos numéricos. A declaração de prática de certificação da APNIC explica o arranjo claramente: as organizações que emitem certificados também são as organizações que realizam a delegação e, portanto, são autoritativas sobre essa vinculação. A documentação do RIPE NCC diz que seus certificados de recurso estão vinculados a organizações registradas e mudam automaticamente quando os recursos são adicionados, devolvidos, movidos ou transferidos.

Esse alinhamento impede que um ex-titular confie indefinidamente em um certificado antigo após uma transferência legítima. Ele permite que um destinatário estabeleça novas autorizações e permite que partes confiantes rejeitem reivindicações desatualizadas. Sem um pai capaz de atualizar o escopo, o RPKI protegeria intenções de roteamento antigas em detrimento do registro atual.

O mesmo alinhamento dá aos registros administrativos uma segunda vida. Um nome, status ou relacionamento contratual em sistemas de registro não é mais usado apenas para responder quem recebe serviço ou o que aparece no RDAP. Ele pode determinar quais prefixos entram em um certificado de recurso. Esse certificado determina quais objetos assinados podem validar. O caminho do registro para a evidência de roteamento é intencional.

A questão de governança não é se deve romper esse caminho. Fazer isso derrotaria o propósito da certificação de recursos. É como restringir erros e ações discricionárias onde o caminho começa. Se um recurso é removido após uma transferência concluída, a autorização do ex-titular deve cessar. Se uma incompatibilidade temporária de conta, fatura contestada ou classificação legal equivocada produz o mesmo resultado sem salvaguardas adequadas, o mecanismo de segurança carregou um defeito administrativo para uma camada mais consequente.

A distinção entre correção precisa e aplicação prematura deve ser feita antes da revogação. A criptografia pode mostrar que um pai assinou um novo certificado ou listou um antigo em uma LCR. Não pode mostrar que a equipe interpretou corretamente uma fusão, que a notificação chegou ao oficial certo, que uma correspondência de sanções foi sólida ou que uma transferência disputada merecia efeito imediato. Essas são questões institucionais em torno do ato assinado.

A revogação não é um resultado único

A palavra revogação sugere uma única chave. O resultado do roteamento é mais condicional. A RFC 6811 define três estados de validação de origem de rota. Uma rota é NotFound quando nenhum pacote validado a cobre. É Valid quando pelo menos um pacote a cobre e corresponde. É Invalid quando pelo menos um pacote a cobre, mas nenhum corresponde.

Suponha que um titular tenha uma ROA exata para um prefixo e o caminho do certificado desapareça. Depois que os validadores param de aceitar essa ROA, nenhum pacote abrangente pode permanecer. A rota então passa de Valid para NotFound. Muitas redes aceitam NotFound porque a implantação do RPKI é incompleta e rejeitar toda rota não certificada ainda seria destrutivo. O efeito imediato pode, portanto, ser uma perda de proteção de validação, não uma perda de acessibilidade.

Agora suponha que uma ROA válida mais ampla permaneça sob outra CA, ou uma autorização de substituição cubra o prefixo com uma origem ou comprimento máximo diferente. A rota pode se tornar Invalid. Redes que rejeitam rotas Invalid podem descartá-la. Outras podem diminuir a preferência, marcá-la para monitoramento ou aceitá-la. A RFC 7115 torna a política final local; o status de validação informa o roteamento, em vez de ditar uma resposta universal.

Essa variabilidade não é motivo para complacência. Uma rota não precisa desaparecer em todos os lugares para que o dano seja material. A rejeição seletiva por grandes provedores de trânsito, redes de nuvem, pares do setor público ou plataformas de conteúdo pode fragmentar o acesso. Um prefixo que se torna NotFound perde a garantia em que os clientes podem confiar. Um operador também pode enfrentar uma necessidade urgente de recriar ROAs sob um novo certificado enquanto os caches convergem em velocidades diferentes.

A linguagem de governança deve, portanto, evitar dois erros. Não deve dizer que o RIR controla diretamente cada rota. Nem deve afirmar que uma alteração de certificado afeta apenas um rótulo de segurança opcional. O pai controla uma entrada para decisões tomadas em muitas redes autônomas. A natureza distribuída da ação final não reduz o dever de cuidado do pai nem a necessidade de planejamento de continuidade do operador.

A escolha de design surgiu antes do uso operacional em massa

O arranjo moderno tomou forma ao longo de anos. O trabalho dos RIRs e da IETF precedeu a publicação de 2012 dos principais documentos de arquitetura do RPKI. Uma proposta de política do RIPE numerada 2008-08 debateu como os certificados deveriam refletir os recursos registrados e afirmou que os certificados refletiriam o status de registro em todos os momentos, embora essa proposta tenha sido posteriormente retirada. A APNIC já estava relatando trabalho de certificação de recursos em 2009. Estas não eram meras discussões sobre criptografia melhor. Elas diziam respeito a qual instituição atestaria o controle de recursos.

Os serviços de produção chegaram por volta de 2011. O RIPE NCC lançou um serviço de certificação de recursos hospedado no início daquele ano, inicialmente com um conjunto limitado de recursos. Seu anúncio de lançamento apresentou o serviço como uma forma de tornar o registro mais robusto e o roteamento mais seguro. Mais tarde, em 2011, ofereceu uma prova de conceito de certificação local na qual um operador poderia executar sua própria CA com o RIPE NCC como pai. A LACNIC registra serviço hospedado desde janeiro de 2011 e serviço delegado desde dezembro de 2019. Os prazos e capacidades regionais diferiram.

Os documentos centrais da IETF publicados em 2012 separaram as funções claramente no papel. A RFC 6480 descreveu a arquitetura. A RFC 6482 especificou ROAs. A RFC 6483 explicou a validação de origem de rota. A RFC 6492 especificou trocas pelas quais uma CA filha solicita certificados e um pai emite ou revoga. Trabalhos posteriores adicionaram protocolos de publicação e analisaram ações adversas da CA.

O acordo institucional foi pragmático. Os RIRs já mantinham registros de recursos, autenticavam titulares e coordenavam a exclusividade. Colocá-los acima dos certificados de recursos evitou a criação de uma autoridade de título global não relacionada. O serviço hospedado reduziu o custo de entrada para operadores que não queriam executar uma CA ou repositório. A delegação preservou uma rota para organizações que exigem controle de chave mais forte.

Esse acordo merece crédito. Também merece revisão constitucional periódica. Uma função que começou como um serviço de segurança opcional agora fornece evidências consumidas por mais redes e sistemas automatizados. À medida que a confiança cresce, os termos de serviço escritos para experimentação podem se tornar inadequados para uma infraestrutura cujos erros podem alterar a acessibilidade. O teste relevante não é se o design original foi malicioso. É se a governança amadureceu com a consequência operacional.

A AC pai é mais do que um relé técnico

A RFC 6492 dá aos sistemas pai e filho uma linguagem padrão para listar recursos, solicitar emissão e solicitar revogação. Ela não decide por que um pai acredita que um recurso deve ser incluído, se uma transferência está completa ou qual processo deve preceder uma mudança involuntária. O protocolo transporta fielmente uma decisão tomada em outro lugar.

Isso é comum em infraestrutura. Os padrões técnicos definem como um comando é autenticado e representado. Eles não fornecem todo o direito público da instituição autorizada a enviá-lo. Uma revogação validamente assinada ainda pode ser prematura, equivocada ou processualmente injusta. Por outro lado, um pai pode ser obrigado a revogar mesmo quando um operador preferiria atraso, como após um comprometimento confirmado ou transferência concluída.

O RIR, portanto, desempenha pelo menos três funções relacionadas. Ele mantém informações de registro. Ele decide o escopo de recursos que seu serviço de certificação atestará. Ele opera, ou é pai, de CAs que traduzem esse escopo em objetos criptográficos. No serviço hospedado, ele também pode manter a chave privada do usuário e publicar os objetos assinados do usuário.

A concentração de funções pode melhorar a consistência. Quando uma transferência é concluída, uma instituição pode atualizar o registro, substituir certificados e ajudar as partes a construir novas autorizações. Ela também pode amplificar um erro. Uma mudança de status equivocada não precisa esperar por uma organização separada para agir; a automação pode transportá-la diretamente para a emissão de certificados e o estado do repositório.

A governança deve corresponder ao papel concentrado. O pai deve documentar o mapeamento entre eventos de registro e eventos de certificado. Deve distinguir mudanças que podem ocorrer automaticamente daquelas que requerem confirmação humana. Deve identificar quem pode autorizar uma revogação de emergência, como funciona o controle duplo, que evidências são retidas e como um operador pode contestar um erro. Uma declaração de prática de certificação pode descrever a prática técnica; os termos de serviço e a política da comunidade também devem definir a legitimidade da decisão.

Um incidente de 2020 revelou o caminho de propagação

Em 17 de dezembro de 2020, o RIPE NCC relatou um erro envolvendo recursos legados. Um erro de programação na implementação de um item de registro não relacionado definiu o status contratual dos recursos legados afetados como nenhum. Esses recursos então se tornaram inelegíveis para certificação.

As consequências seguiram a hierarquia. Certificados de recursos para 36 CAs foram atualizados para conter menos recursos certificáveis. Quarenta e uma ROAs hospedadas, produzindo 202 pacotes validados, foram excluídas de 24 CAs. Certificados emitidos para CAs delegadas afetadas encolheram; dependendo de seu software, suas ROAs desapareceram ou foram rejeitadas por reivindicação excessiva. O RIPE NCC restaurou o status contratual de 105 recursos afetados e recriou as ROAs hospedadas. Os operadores delegados foram aconselhados a verificar se precisavam recriar as suas.

Os números devem ser mantidos dentro do evento. Eles não estabelecem uma taxa de erro anual, um denominador global ou uma medida de falha comparativa para RIRs. A autópsia também não prova que cada rota afetada se tornou inalcançável. O estado de validação e a política de rede determinam esse resultado.

O que o incidente prova é o mecanismo. Um erro de status contratual no ambiente de registro propagou-se para o escopo do certificado e o material de autorização de rota. Usuários hospedados e delegados experimentaram diferentes obrigações de recuperação. O RIR poderia recriar ROAs hospedadas que operava, enquanto os titulares delegados podem precisar agir dentro de suas próprias CAs.

O RIPE NCC disse que melhoraria a garantia de qualidade, os testes de aceitação e a análise de impacto baseada em risco. Essas são medidas sensatas. A lição mais ampla é que as mudanças próximas ao limite registro-certificado merecem o mesmo cuidado que as mudanças em uma plataforma de roteador. Os testes devem incluir o diff esperado do certificado, o impacto na ROA e no pacote validado, os efeitos da transferência, o comportamento do cliente delegado e o caminho de restauração. Uma mudança de registro que parece administrativa pode ter um raio de explosão criptográfico.

A transferência é o caso comum mais difícil

O comprometimento de emergência é dramático, mas a transferência é o teste de governança recorrente. O registro deve parar de certificar o ex-titular e começar a certificar o destinatário. O roteamento pode precisar continuar durante todo o processo. A AS de origem pode permanecer a mesma, mudar uma vez ou mudar em etapas. O vendedor, comprador, corretor, provedor de trânsito e RIR podem controlar cada um uma parte diferente da sequência.

A orientação do RIPE NCC diz que quando um recurso é movido ou transferido, a organização registrada e o certificado mudam; as ROAs subjacentes são removidas e devem ser recriadas. Sua documentação hospedada também diz que os recursos são automaticamente adicionados ou removidos dos certificados à medida que as participações registradas mudam. Esse comportamento protege o destinatário de reivindicações desatualizadas do ex-titular. Ele cria uma dependência de corte que deve ser tratada como parte do acordo.

Um plano de transferência de alta qualidade começa antes da atualização do registro. As partes devem inventariar cada ROA e anúncio real, incluindo mais específicos, origens múltiplas e provedores de mitigação temporária. Eles devem concordar quais autorizações devem existir após o fechamento, quem as criará, como o acesso à CA do destinatário será confirmado e como os validadores serão observados. O RIR deve fornecer uma prévia legível por máquina do que será removido e do que o destinatário pode criar.

O princípio é make before break sempre que a arquitetura o permitir. A autorização de saída deve permanecer válida até que a autorização de entrada seja publicada e recuperável, a menos que a segurança ou a lei exijam remoção imediata. Onde os sistemas regionais não podem suportar certificação sobreposta, a limitação deve ser explícita e o corte deve ter uma rota de reversão testada ou restauração acelerada.

Nem toda sobreposição é segura. Certificar duas partes para os mesmos recursos pode criar reivindicações concorrentes ou estender o poder do ex-titular. Uma transição limitada pode, no entanto, ser mais segura do que uma lacuna não anunciada. O design da política deve especificar duração, objetos permitidos, aprovação, monitoramento e expiração automática. A continuidade da transferência não é um pedido para preservar direitos obsoletos indefinidamente; é um pedido para sequenciar direitos válidos sem danos de roteamento evitáveis.

A notificação deve chegar antes do evento criptográfico, quando possível

A notificação tradicional é muitas vezes um e-mail dizendo que o status de uma conta mudou. Isso é muito fraco quando o evento pode alterar o escopo do certificado. A mensagem pode chegar a um contato de faturamento em vez da equipe de segurança de roteamento. Pode descrever uma questão contratual sem listar os prefixos, certificados ou ROAs em risco. Pode chegar depois que os sistemas automatizados já agiram.

A notificação deve ser baseada em risco. Um comprometimento confirmado de chave privada pode justificar revogação imediata, seguida de notificação rápida e substituição. Uma transferência voluntária concluída segue um cronograma acordado. Um pagamento disputado, correspondência de sanções, suspeita de violação de política ou sucessão corporativa incerta geralmente permite um período de aviso, a menos que uma ameaça concreta exija urgência.

Para ações não emergenciais, o operador deve receber uma prévia precisa: recursos afetados, identificadores de certificado atuais, objetos assinados que devem parar de validar, hora efetiva, motivo, autoridade, cura disponível e rota de revisão. A prévia deve estar disponível no portal e em formato legível por máquina assinado, para que grandes operadores possam compará-la com a intenção de roteamento.

A entrega deve usar contatos operacionais e legais mantidos independentemente, não apenas a credencial de conta que pode estar em disputa ou comprometida. O reconhecimento deve ser registrado, mas a falta de reconhecimento não deve criar um veto interminável. A escalada pode prosseguir através de canais repetidos e um cronograma publicado.

O período de aviso deve suportar uma correção. Se o registro anexou a organização errada, interpretou mal um documento de fusão ou correspondeu à parte sancionada errada, a equipe deve poder pausar a ação não emergencial enquanto a evidência é revisada. Se a ação estiver correta, o operador ganha tempo para preparar novas ROAs ou clientes para uma mudança de estado de validação.

Uma boa notificação não é uma promessa de que cada rota permanecerá Valid. É uma transferência disciplinada entre autoridade administrativa e operações de rede. Reduz a surpresa, cria um registro probatório e torna possível a responsabilização posterior.

Razões e revisão são controles de segurança

As instituições às vezes tratam o devido processo como um atraso imposto à segurança técnica. Aqui, faz parte da segurança. Um pai que pode revogar rapidamente precisa de controles contra tomada de conta, erro interno, reivindicações legais falsas e mudanças de registro mal compreendidas. Razões escritas e revisão independente forçam a decisão a ser vinculada a evidências e autoridade.

Os motivos de revogação devem ser prospectivos e finitos. Exemplos incluem comprometimento confirmado de chave, solicitação do titular, inconsistência do certificado com uma alteração de registro concluída, expiração do relacionamento de serviço relevante, uma ordem legal vinculante, fraude demonstrada ou falha persistente de uma CA delegada sob uma política publicada. Frases amplas como razões operacionais devem ser acompanhadas de limites, funções de aprovação e deveres de restauração.

A revisão deve caber na escala de tempo. Um recurso de rotina decidido meses depois não pode proteger um corte de rota que ocorre esta tarde. A primeira camada deve ser uma verificação técnica e de registro rápida por pessoal não responsável pela ação inicial. Uma segunda camada pode considerar disputas contratuais ou políticas. A ação de emergência pode permanecer em vigor durante a revisão quando a certificação continuada criar um risco sério, mas a instituição deve explicar o porquê.

O revisor precisa de mais do que o registro atual. Deve ver o histórico do evento: quem alterou o status do registro, qual regra foi aplicada, qual diff de certificado resultou, quais notificações foram enviadas, quais aprovações foram obtidas e quais opções de restauração existem. Os operadores devem receber o máximo desse raciocínio que a segurança e a privacidade permitirem.

A publicação de classes de decisão anonimizadas pode melhorar a consistência. Os membros podem ver com que frequência os fundamentos de emergência e não emergência são usados, com que rapidez os erros são restaurados e se a política regional produz lacunas de transferência recorrentes. A notificação agregada não deve inventar precisão onde os eventos são raros, mas o silêncio deixa a comunidade incapaz de avaliar o poder concentrado.

A delegação estreita uma dependência, não a hierarquia

O RPKI delegado é às vezes apresentado como a resposta ao controle do RIR. É uma resposta parcial. O operador gera e protege sua chave privada, executa seu software de CA e decide quais objetos assinar. Ele pode integrar mudanças de autorização com operações de rede, gerenciar recursos de vários pais em um sistema e potencialmente emitir certificados filhos.

Estes são controles importantes. Uma interrupção do portal de serviço hospedado não precisa impedir o titular delegado de criar uma nova ROA. A equipe do RIR não pode usar a chave privada da filha para assinar uma declaração diferente. O titular pode reter seu próprio histórico de eventos assinados e escolher um serviço de publicação separado.

O pai ainda controla o certificado que torna a filha autoritativa para um conjunto de recursos. A RFC 6492 permite que o pai emita e revogue certificados. Se o registro mudar, o pai pode fornecer um certificado com menos recursos. Se a filha continuar assinando o escopo antigo, os validadores rejeitarão a reivindicação excessiva. A delegação, portanto, separa a custódia da assinatura da autoridade de registro; não abole a autoridade de registro.

O RIPE-847 torna isso explícito em outro contexto. Desde outubro de 2025, se o RIPE NCC não conseguir descobrir e validar o manifesto e a LCR atuais de uma CA delegada por mais de três meses, o certificado de recurso deve ser revogado após esforços razoáveis para descobrir material atual e notificar o operador. A política aborda CAs delegadas persistentemente não funcionais e o ônus que impõem às partes confiantes, não imperfeições breves.

Essa é uma função legítima do pai com consequências de governança. Um operador delegado ganha controle e assume deveres. O pai ganha um motivo para revogação e deve aplicá-lo de forma previsível. O monitoramento deve evitar falsos positivos causados pelos próprios problemas de acessibilidade do pai. A notificação deve identificar verificações com falha e permitir que o titular demonstre publicação válida. A restauração deve ser documentada.

A delegação é melhor entendida como separação constitucional dentro da hierarquia. Impede que o pai faça tudo, mas não que faça qualquer coisa.

Os repositórios formam uma segunda superfície de controle

Certificados e ROAs precisam alcançar as partes confiantes. Os repositórios RPKI publicam certificados, listas de revogação, manifestos e objetos assinados. A RFC 8181 define um protocolo pelo qual uma CA pode solicitar a um servidor de publicação que publique ou retire objetos. O serviço hospedado normalmente combina operação de CA e repositório. Titulares delegados podem publicar por conta própria ou usar o serviço de publicação de um RIR.

Essa distinção é importante porque a posse da chave de assinatura e a capacidade de distribuir o objeto assinado são poderes diferentes. Um titular delegado que usa publicar-no-pai mantém sua chave, mas depende do repositório operado pelo pai para aceitar e servir seus objetos. Um titular que se autopublica ganha mais controle de distribuição e também assume responsabilidade pelo serviço globalmente disponível, manifestos atualizados, listas de revogação atuais e resiliência contra falhas operacionais.

A indisponibilidade do repositório não se traduz mecanicamente em rejeição imediata de rota. Os validadores armazenam material em cache e aplicam regras para repositórios desatualizados ou indisponíveis. Diferentes implementações e configurações locais podem criar diferentes tempos. Mas a publicação desatualizada pode impedir que mudanças pretendidas cheguem ao mundo, e manifestos inválidos ou informações de revogação podem fazer com que um ramo seja rejeitado.

O mapa institucional deve, portanto, declarar quatro controles separadamente: escopo de registro, certificação pai, assinatura filha e publicação. Uma organização pode controlar um, dois ou três sem controlar todos os quatro. Contratos e planos de continuidade que dizem apenas que o operador tem sua própria chave são incompletos.

A mesma separação melhora a análise de incidentes. Se uma nova ROA não aparecer, a causa pode ser uma operação de assinatura filha com falha, solicitação de provisionamento rejeitada, solicitação de publicação com falha, problema de sincronização do repositório ou cache da parte confiante. Culpar o RPKI abstrato obscurece onde a autoridade e a responsabilidade realmente estavam.

Ordens judiciais e sanções exigem uma ponte estreita

Os RIRs operam sob a lei. Um tribunal pode decidir uma disputa corporativa, ordenar a preservação ou transferência de ativos, restringir uma conta ou abordar suposta fraude. Regras de sanções podem proibir serviço a uma pessoa listada. Um registro não pode prometer ignorar deveres legais vinculantes porque a continuidade do roteamento é valiosa.

O perigo reside em traduzir pressão legal ampla em ação de certificado sem uma ponte definida. Uma ordem relativa a ações de uma empresa pode não instruir o RIR a revogar um certificado de recurso. Uma correspondência de sanções pode ser ambígua. A reivindicação de um credor pode dizer respeito a pagamento, não à validade de uma autorização de rota atual. A instituição deve identificar o ato legal, a relação de recurso e a resposta compliant menos disruptiva.

Onde a revogação imediata é necessária, o registro deve identificar quem a autorizou e por que a notificação foi limitada. Onde a preservação é permitida, o RIR pode congelar a transferência enquanto mantém a autorização existente até que um tribunal esclareça o controle. Essa escolha deve ser fundamentada na lei e na política, não improvisada pela equipe técnica.

As operações transfronteiriças complicam o cenário. Um titular de recurso, empresa-mãe, rede, RIR e tribunal podem estar em jurisdições diferentes. O RPKI não resolve conflitos de leis. Sua certeza criptográfica pode até disfarçar incerteza legal: os validadores sabem qual caminho de certificado é aceito, não se a disputa por trás de uma ação do pai foi resolvida corretamente.

Esta é outra razão para evitar apresentar a validação de rota como prova de propriedade. Os termos do RIPE NCC negam expressamente que seus certificados suportem reivindicações de propriedade. Os certificados de recurso atestam dentro de um sistema de coordenação. Os tribunais podem usar ou examinar essa evidência, mas o certificado não é uma escritura universal de título.

A responsabilidade deve seguir o controle evitável

Os atuais termos de serviço geralmente alocam grande parte do risco ao usuário. O acordo publicado da ARIN descreve amplos direitos de rescisão, incluindo rescisão imediata por vários motivos contratuais, governamentais, técnicos e de segurança, e um prazo de quatorze dias para rescisão por qualquer motivo ou sem motivo. Também contém extensas cláusulas de isenção de responsabilidade, renúncia e liberação. Os termos do RIPE NCC colocam o uso por conta e risco do titular e limitam a responsabilidade, exceto em casos que incluem dolo ou negligência grave.

O efeito legal dessas disposições depende da lei aplicável e dos fatos; um artigo comparativo não pode decidir a exequibilidade. Sua mensagem institucional é, no entanto, clara. Os RIRs querem flexibilidade para operar um serviço de segurança em evolução sem se tornarem seguradoras de cada decisão de roteamento tomada em outro lugar.

Essa preocupação é legítima. O pai não controla se uma rede remota rejeita rotas Invalid. Não pode garantir a disponibilidade de cada repositório delegado ou a correção da ROA do titular. A responsabilidade ilimitada por consequências poderia desencorajar a prestação de um serviço de interesse público.

Mas uma isenção completa é um substituto pobre para responsabilidade calibrada. O risco deve seguir o controle evitável. O titular deve responder por intenções de roteamento incorretas que submete, credenciais inseguras e falhas em uma CA que opera. Um provedor de publicação deve responder por deveres que assume expressamente, sujeito a limites razoáveis de serviço. O pai deve responder por autorização gravemente deficiente, desvio inexplicável das regras de revogação publicadas, falha em seguir uma transição prometida ou atraso evitável na restauração de seu próprio erro.

As soluções não precisam começar com grandes indenizações. Podem incluir restauração de emergência, créditos de taxa, assistência técnica financiada, preservação de provas, investigação independente e publicação de conclusões. Para perda grave comprovada, um acordo de compensação com limite máximo ou mecanismo de seguro poderia ser considerado por cada comunidade regional. O ponto central é que a instituição que detém o controle decisivo não deve ser responsável apenas em teoria.

Uma carta de ação do pai tornaria o poder legível

Cada RIR deve publicar uma carta compacta para ações no limite registro-certificação. Ela não substituiria a política técnica de certificado ou o acordo geral de serviço. Ela diria a um operador o que pode acontecer com seu estado de certificação e sob qual autoridade.

A carta deve classificar os eventos. Eventos voluntários incluem revogação solicitada pelo titular, troca de chave e transferência. Eventos de segurança incluem comprometimento e solicitações de emergência autenticadas. Eventos de registro incluem devolução, transferência e delegação corrigida. Eventos de conformidade incluem sanções, ordens judiciais e rescisão contratual. Eventos operacionais incluem publicação delegada persistentemente inválida.

Para cada classe, a carta deve declarar o limite de evidência, período de aviso, aprovadores, se make-before-break está disponível, efeito esperado na segurança de roteamento, caminho de revisão, alvo de restauração e registros retidos. Deve explicar as diferenças entre usuários hospedados e delegados. Deve listar interfaces pelas quais os operadores podem obter um inventário atual de objetos e visualizar uma alteração de certificado proposta.

A carta também deve definir autoridade negativa: o que o RIR não decidirá por meio do RPKI. Uma AC pai não deve usar a revogação para punir críticas legítimas de políticas, resolver uma dívida privada não relacionada ao serviço, escolher entre arquiteturas de rede concorrentes ou conferir título de propriedade. Se a política regional autorizar uma ação mais ampla, a autoridade deve ser explícita e revisável.

A auditoria independente pode testar se os eventos reais seguem a carta. A amostragem deve focar não apenas na proteção criptográfica de chave, mas na correção dos gatilhos dos sistemas de registro. Os auditores devem examinar autorização, tempo, notificação e recuperação. Resumos públicos podem divulgar classes e conclusões de controle sem expor segredos do titular.

Isso não é burocracia adicionada à segurança. É a constituição operacional de um serviço de segurança com efeitos externos.

O que a Number Resource Society pode fazer sem reivindicar a chave

A Number Resource Society argumenta publicamente por registro preciso, controle do titular, participação e interferência arbitrária reduzida. Esses princípios são relevantes para uma AC pai porque a proteção mais forte contra excessos não é a negação da hierarquia; é o uso transparente e limitado da hierarquia.

A NRS pode contribuir concretamente mantendo um índice comparativo de ações do pai. Para cada RIR, poderia registrar os fundamentos publicados para substituição e revogação de certificados, regras de notificação, instalações de transição, canais de recurso, linguagem de responsabilidade e opções de publicação delegada. Poderia testar se as páginas são compreensíveis para um pequeno operador e identificar termos que deixam consequências de roteamento inexplicadas.

Poderia também publicar uma lista de verificação de continuidade de transferência construída em torno de inventário de objetos, prontidão do destinatário, origens múltiplas, delegações de clientes, observação de validador e contatos de reversão. Membros menores geralmente não possuem uma equipe dedicada de chave pública. Uma lista de verificação neutra e um exercício de simulação traduziriam o risco institucional em preparação prática sem pedir que a NRS opere uma CA.

Finalmente, a NRS poderia coletar experiências documentadas de membros sob regras estritas de evidência: data, serviço regional, tipo de evento, notificação, efeito no estado de validação, recuperação e incerteza não resolvida. A agregação deve evitar reivindicar uma taxa sem um denominador conhecido. O valor seria revelar modos de falha recorrentes e lacunas de política.

Essas funções são positivas, mas limitadas. A carta e as páginas explicativas da NRS são defesa de primeira parte. Elas não provam que a NRS é uma âncora de confiança reconhecida, registrador autorizado, árbitro neutro ou operador de certificado tecnicamente superior. Sua posição mais forte é como uma instituição cívica em torno da hierarquia: tornar as regras comparáveis, ajudar os titulares a se preparar e pressionar as comunidades regionais a conectar o poder criptográfico com o dever processual.

As objeções são sérias, mas administráveis

Uma objeção é que o aviso prévio ajuda um atacante com uma chave comprometida. É por isso que a disciplina proposta distingue a ação de segurança de emergência da mudança administrativa ordinária. A revogação imediata pode permanecer disponível quando o atraso prolongaria uma ameaça concreta. A autorização dupla, a substituição rápida e a revisão pós-ação tornam o poder de emergência mais seguro sem torná-lo lento.

Uma segunda objeção é que make-before-break pode certificar dois reivindicantes. Às vezes pode, e uma sobreposição descuidada enfraqueceria o sistema. A resposta não é uma sobreposição universal. É uma ferramenta de transição estreita usada apenas onde a autoridade de registro, o consentimento das partes e as restrições técnicas a suportam, com curta expiração e monitoramento visível. Onde a sobreposição é inaceitável, a pré-validação e um corte acordado ainda podem reduzir a lacuna.

Uma terceira objeção é que os operadores já aceitam os termos de serviço. O consentimento aos termos não elimina a dependência institucional. Muitos operadores têm apenas um pai regional para recursos que legitimamente possuem. A capacidade de recusar o RPKI não é uma resposta completa uma vez que clientes e pares valorizam cada vez mais a validação. A governança dos membros deve melhorar os termos em vez de fingir que o relacionamento é uma compra competitiva comum.

Uma quarta objeção é que o sistema de roteamento distribuído protege os usuários porque as redes escolhem suas próprias políticas. Isso reduz o controle direto pela CA. Também significa que o dano pode ser desigual e difícil de medir. A consequência fragmentada fortalece o caso para telemetria precisa de incidentes; não desculpa um erro evitável do pai.

A objeção final é o custo. Ferramentas de pré-visualização, revisão rápida e auditoria exigem pessoal. No entanto, o RIR já opera sistemas de autenticação, registro, transferência e certificação. Adicionar salvaguardas na interface entre eles é mais barato do que tratar cada erro como um acidente imprevisível. As taxas para serviços de certificação devem suportar os controles que os tornam confiáveis.

Meça o limite, não um mítico interruptor global

A prestação de contas precisa de medidas, mas não de percentagens globais inventadas. Os RIRs podem publicar contagens de substituições de certificados pai por causa, revogações de emergência, revogações não emergenciais, cortes de transferência, eventos de restauração e ações de CA delegada. Eles podem relatar mediana e intervalo para notificação e recuperação onde o tamanho da amostra permitir, suprimindo detalhes que identificariam um titular.

Medidas técnicas devem rastrear se uma ação correspondeu à sua prévia, se os objetos afetados foram recriados, se os clientes delegados exigiram recuperação manual e se a distribuição do repositório atingiu as metas declaradas. Medidas de registro devem registrar quantos eventos de impacto no certificado surgiram de dados corrigidos, em vez de ação planejada do titular.

Observadores independentes podem medir mudanças visíveis no RPKI, mas não podem inferir confiavelmente cada causa a partir de objetos públicos. Uma ROA ausente pode ser intencional. Uma redução de certificado pode seguir uma transferência válida. A telemetria pública deve, portanto, ser combinada com registros institucionais auditados, em vez de substituída por palpites externos.

Os operadores também precisam de suas próprias medidas. Eles devem manter um inventário atual das relações com os pais, recursos certificados, ROAs, filhos delegados, pontos de publicação e dependências de roteamento. Eles devem alertar sobre mudanças inesperadas no escopo do certificado e comparar pacotes validados de mais de uma implementação ou ponto de vista. Eles devem saber quais clientes ou serviços exigem status Valid, em vez de assumir que toda rede trata NotFound da mesma forma.

A medida mais útil é o tempo desde uma ação parental equivocada até a autorização válida restaurada. Testa detecção, contato, autoridade, assinatura e publicação juntos. Uma baixa contagem de incidentes com um caminho de restauração caótico não é governança madura.

Nenhum conjunto de dados público atualmente suporta uma probabilidade confiável entre RIRs de revogação indevida ou perda de rota. Essa incerteza deve permanecer visível. É uma razão para publicar melhores evidências, não uma licença para fabricar garantias.

A autoridade de segurança precisa de uma espinha dorsal processual

O RPKI resolve um problema real. Ele permite que a intenção de roteamento de um operador se torne criptograficamente verificável e dá às redes uma base mais forte para rejeitar origens acidentais ou maliciosas. A hierarquia não é uma falha embaraçosa escondida dentro dessa conquista. É como o sistema vincula a autorização à delegação atual de recursos.

Mas uma hierarquia carrega poder para baixo. O pai RIR decide quais recursos um certificado filho pode cobrir. Um serviço hospedado também pode possuir a chave de assinatura do titular e publicar todos os objetos. As atualizações de registro podem, portanto, tornar-se mudanças na evidência de validação de rota. O incidente de 2020 do RIPE NCC mostrou que esse caminho está operacional, enquanto os atuais termos e políticas regionais mostram que os motivos de revogação e as soluções ainda variam.

A resposta correta não é abandonar o RPKI nem fingir que a criptografia remove o julgamento institucional. As ACs pai precisam de regras prospectivas, poder de emergência estreitamente adaptado, notificação significativa, engenharia de transferência, revisão rápida, contabilidade transparente de incidentes e responsabilidade proporcional ao controle. As CAs delegadas devem ser incentivadas onde seus benefícios justificam seus deveres, mas não devem ser vendidas como fuga do relacionamento com o pai.

A frase "autoridade de certificação acima do operador" deve se tornar um lembrete de design. O operador pode originar a rota e assinar a autorização. Outra instituição determina se a assinatura está dentro de uma cadeia de recursos válida. Quando essa instituição age com precisão, previsibilidade e responsabilidade, o RPKI é mais forte. Quando seus erros administrativos ou discrição ilimitada se propagam despercebidos, a segurança de roteamento pode se tornar um canal para o risco do registro.

A próxima fase da governança do RPKI é, portanto, processual, não criptográfica. Os padrões já explicam como funcionam os certificados, listas de revogação, manifestos e ROAs. As comunidades regionais devem agora tornar igualmente claro quando o pai pode agir, como a continuidade é protegida e o que acontece quando a autoridade acima do operador está errada.

Fontes