Resumo

  • O RPKI hospedado retira do titular do recurso as tarefas complexas de gerenciamento de certificados, renovação, manifestos, listas de revogação e gerenciamento de depósito. Permitiu que organizações sem equipes especializadas em criptografia de chave pública criassem e gerenciassem autorizações de origem de rota.
  • O serviço também concentra os controles. Dependendo do RIR, o registro pode manter a chave privada da autoridade certificadora (CA) hospedada, traduzir configurações do portal em objetos assinados, publicar esses objetos, atualizar o escopo do certificado a partir das entradas de recursos e removê-los quando o serviço terminar.
  • Uma falha no portal não invalida automaticamente ROAs existentes. O risco mais agudo é a perda da capacidade de alteração e recuperação, ou uma decisão do registro que revogue a CA hospedada ou exclua seus objetos. Nesse caso, o usuário pode não ter uma chave independente e um caminho de publicação para manter as autorizações pretendidas.
  • O RPKI delegado dá ao titular sua própria CA e chave privada. Pode melhorar a automação, o gerenciamento multi-RIR e a independência de uma interface de assinatura hospedada. No entanto, não escapa do pai: o RIR ainda emite o certificado de recurso e pode restringi-lo ou revogá-lo.
  • Configurações híbridas separam a custódia da chave da operação do depósito. Muitas vezes oferecem o melhor equilíbrio prático, mas a publicação pelo pai continua sendo uma dependência de serviço, e uma CA delegada desatualizada pode em si ser um risco para as partes confiantes.
  • Os operadores devem escolher um modelo com base nas consequências, não na moda. Serviços públicos críticos, redes multi-origem complexas e grandes delegações downstream merecem controle mais forte e uma transição testada; redes pequenas e simples podem permanecer racionalmente no modo hospedado se as salvaguardas processuais e as capacidades de recuperação forem críveis.
  • A Number Resource Society pode ajudar publicando uma tabela de comparação dos modelos, testes de continuidade e perguntas para os conselhos dos RIRs. Deve fortalecer a escolha informada, em vez de apresentar o auto-hospedagem como mera soberania.

O colapso começa quando uma alteração válida não pode ser feita

Uma rede move um serviço de um AS de origem para outro. Seus engenheiros configuraram o novo anúncio BGP e pretendem criar a nova ROA antes de retirar a rota antiga. No RPKI hospedado, eles devem usar o portal ou interface do RIR. Se a conta não estiver acessível, a interface estiver indisponível ou o RIR tiver suspenso a certificação, o operador não pode assinar um substituto por conta própria. Ele não possui a chave da CA hospedada.

Isso não significa que a rota existente falhe imediatamente. A ROA existente pode continuar publicada e válida enquanto o portal estiver indisponível. Nesse caso, o perigo imediato é a paralisia da alteração. A nova origem pode se tornar inválida se a ROA de cobertura antiga permitir apenas o AS antigo. Os engenheiros podem adiar uma migração necessária, operar uma rota que algumas redes rejeitam ou pedir ao registro que restaure o acesso com urgência.

Um evento mais grave ocorre quando a CA hospedada é revogada ou seus objetos assinados são excluídos. O operador não pode republicar os mesmos objetos sob a mesma chave a partir de um backup, pois a chave nunca esteve sob seu controle. Ele não pode criar um filho delegado depois que o pai encerrou o serviço sem sua cooperação. A instituição que fornece a conveniência tornou-se o caminho obrigatório para a recuperação.

Essa é a armadilha da comodidade. Não é a afirmação de que o RPKI hospedado é sempre não confiável, nem que toda interrupção de serviço remove ROAs. É a concentração de autoridade no momento em que o usuário mais precisa de uma opção independente. Um serviço pode ser simples na operação normal, mas frágil em caso de disputa, transferência, comprometimento ou mudança urgente de roteamento.

A comparação correta começa, portanto, com os caminhos de controle, não com slogans. Quem pode expressar a intenção de roteamento? Quem possui a chave de assinatura? Quem determina os recursos certificados? Quem publica os objetos? Quem pode revogá-los? Quem pode manter uma autorização válida visível durante uma migração? O RPKI hospedado e o delegado respondem a essas perguntas de forma diferente.

Conveniência resolveu um problema real de adoção

Operar uma CA de RPKI não é o mesmo que criar um certificado de conexão comum. A CA deve proteger chaves, solicitar e renovar certificados de recurso, emitir objetos assinados, gerenciar manifestos e listas de revogação, publicar material atual, sobreviver a falhas e interagir corretamente com sistemas pai. Seu depósito deve estar acessível às partes confiantes, diretamente ou por meio de um provedor de publicação. Erros podem alterar a validação de origem de rota.

A maioria dos operadores de pequeno e médio porte não formou equipes para essa tarefa. Eles queriam autorizar seus prefixos sem se tornarem especialistas em infraestrutura de chave pública. O RPKI hospedado permitiu que eles selecionassem um AS de origem e um prefixo em um portal de membros familiar, enquanto o RIR cuidava da emissão, assinatura, renovação e publicação dos certificados.

Os serviços regionais descrevem abertamente esse benefício. A ARIN considera o RPKI hospedado a opção mais simples, afirmando que opera a CA e um depósito de alta disponibilidade. O RIPE NCC afirma que os usuários hospedados só precisam alinhar as ROAs com o roteamento BGP pretendido, enquanto seu sistema gerencia as operações criptográficas e a publicação. A APNIC gerencia a infraestrutura de certificados e publicação para usuários hospedados, gerando as chaves privadas em seu nome. A LACNIC oferece um serviço hospedado desde 2011.

Esse modelo cria externalidades positivas. Um titular de recurso que nunca operaria uma CA delegada ainda pode publicar autorizações precisas. As interfaces dos RIRs podem alertar quando uma ROA proposta invalidaria um anúncio conhecido. Sistemas centralizados podem automatizar renovação, troca de chaves, manifestos e disponibilidade do depósito. A equipe de suporte pode ajudar os membros a corrigir erros.

Seria perverso definir maturidade como a obrigação de toda rede comunitária, universidade ou provedor local de operar uma CA. Uma segurança que apenas grandes operadores podem gerenciar permanece incompleta. A crítica à dependência excessiva deve preservar o acesso fácil ao RPKI.

O objetivo político é a opcionalidade com padrões seguros. O serviço hospedado deve continuar sendo uma opção padrão acessível. O serviço delegado e o híbrido devem ser saídas práticas para usuários cujo risco exija mais controle. A mudança de um para outro não deve criar uma lacuna evitável. A conveniência é valiosa quando é uma escolha, menos quando se torna silenciosamente um cativeiro.

Cinco controles se escondem atrás de um único portal

A interface hospedada apresenta um único serviço, mas abaixo dela existem pelo menos cinco controles.

O primeiro é o escopo de registro. O RIR decide quais blocos de endereços IP e números AS são atribuídos ao titular em seus registros e incluídos em um certificado de recurso. Um portal não pode autorizar um prefixo fora desse escopo.

O segundo é a intenção de roteamento. O titular seleciona o AS de origem, o prefixo e, opcionalmente, o comprimento máximo. Em um serviço hospedado bem projetado, a equipe não inventa essa intenção. O usuário a submete por meio de controles autenticados, e o sistema alerta sobre conflitos óbvios.

O terceiro é a custódia e assinatura da chave. O provedor de hospedagem gera ou armazena a chave privada e a utiliza para criar objetos assinados. Os termos do RIPE NCC definem uma CA hospedada como uma CA pela qual é responsável pelas operações criptográficas e hospeda o par de chaves pública e privada do titular. A APNIC também afirma que gera as chaves privadas para usuários hospedados.

O quarto é a publicação. O depósito do RIR disponibiliza certificados, manifestos, listas de revogação e objetos assinados para as partes confiantes. A publicação deve permanecer atualizada e globalmente acessível. Uma assinatura correta que não esteja acessível aos validadores tem pouco valor operacional.

O quinto é o gerenciamento do ciclo de vida. O serviço renova, substitui e revoga certificados e remove objetos quando os recursos ou o status do serviço mudam. É aqui que o registro, os contratos e as evidências de roteamento se encontram.

O portal oculta essa complexidade por boas razões. O problema surge quando a governança também a oculta. Um usuário pode acreditar que controla o RPKI porque pode clicar em "Criar ROA", enquanto o provedor controla a chave, a publicação e o encerramento. O provedor pode enfatizar que os roteadores tomam decisões locais, enquanto minimiza como sua ação no ciclo de vida altera os dados que esses roteadores recebem.

Um acordo de serviço útil deve nomear cada controle e atribuir responsabilidade. Sem esse mapa, a responsabilidade só aparece após um incidente, quando cada parte aponta para outra camada.

Custódia de chave hospedada não é terceirização comum

Organizações frequentemente terceirizam e-mail, folha de pagamento e computação em nuvem. O RPKI hospedado difere em um aspecto: o provedor de serviços é ao mesmo tempo a autoridade pai que determina o escopo do certificado. Portanto, pode combinar o poder de definir o que pode ser assinado com a capacidade de assinar.

Essa concentração é eficiente. O provedor pode atualizar automaticamente os certificados quando os recursos mudam, renovar objetos antes da expiração e remover autorizações para recursos não mais registrados no usuário. Pode manter chaves em um módulo de segurança de hardware e separar funções operacionais de forma mais eficaz do que um operador pequeno.

Também altera o modelo de ameaça. Uma conta de usuário comprometida poderia criar intenções de roteamento maliciosas se a autenticação e a autorização forem fracas. Um ambiente de assinatura hospedado comprometido poderia afetar muitas CAs. Uma atualização de registro defeituosa poderia remover recursos e desencadear alterações de objetos. Um administrador interno poderia ter poderes que nenhum funcionário deveria ter. Uma decisão legal ou contratual pode ser implementada sem que o titular realize uma ação de assinatura separada.

Estas não são acusações de que os RIRs abusam das chaves. São as consequências da concentração de controles. A resposta está em um design de serviço sólido: autenticação multifator, autorização baseada em funções, alterações de alto risco atrasadas, auditoria independente, proteção de hardware, registro imutável e separação entre alterações de registro e execução que afeta certificados.

O titular deve poder exportar um relatório completo e assinado de suas intenções de roteamento e do conjunto atual de objetos. Ele não pode exportar a chave privada se o serviço a mantiver corretamente irrecuperável, mas pode armazenar informações suficientes para recriar as autorizações sob uma CA delegada ou uma CA hospedada sucessora. Portabilidade de dados não é portabilidade de chave.

O provedor também deve divulgar se um administrador de conta, um funcionário do RIR ou um evento automatizado pode revogar toda a CA hospedada; quais autorizações são necessárias; e dentro de quanto tempo uma revogação incorreta pode ser desfeita. Um serviço de segurança se torna confiável quando os controles em torno do uso da chave são tão visíveis quanto o rótulo verde "Válido" no portal.

O ponto único é revogação e recuperação, não qualquer falha

Chamar o RPKI hospedado de ponto único de falha pode ser muito grosseiro. O depósito pode ser replicado. Objetos existentes têm períodos de validade. O software das partes confiantes armazena em cache dados validados e tem regras para depósitos indisponíveis. Uma breve interrupção do portal pode deixar a validação de rota inalterada. Um RIR pode operar uma infraestrutura muito mais resiliente do que o membro poderia pagar.

O ponto único mais crítico é a autoridade de revogação e recuperação. Se o RIR revogar a CA hospedada ou encerrar o acesso à certificação, o usuário não pode mais assinar sob essa CA. Se o RIR excluir os objetos hospedados no encerramento do serviço, o operador não pode forçar o depósito antigo a fornecê-los indefinidamente. O pai deve emitir um novo certificado delegado ou restaurar o serviço hospedado para que o usuário tenha um caminho válido novamente.

Os termos atuais ilustram o problema. Os termos do RIPE NCC afirmam que todos os objetos assinados são excluídos no encerramento do serviço de certificação e permitem a revogação se um certificado entrar em conflito com registros de registro, por razões técnicas ou de segurança, por violação dos termos ou se o titular rescindir o serviço. O acordo da ARIN lista vários motivos para rescisão imediata, vincula a elegibilidade do RPKI a outros acordos e também retém o direito de rescindir com aviso prévio.

A linguagem legal difere por região e não deve ser nivelada a uma única regra global. Um direito contratual também não prova que foi usado injustamente. O ponto é estrutural: os usuários hospedados dependem da mesma contraparte para assinatura contínua e para a transição desse acordo de assinatura.

Um serviço hospedado crível precisa de uma garantia de saída. Em caso de rescisão não urgente, deve oferecer um período definido para configurar uma CA delegada ou substituta, exportar configurações, verificar a publicação e coordenar mudanças de rota. Uma revogação de emergência deve incluir um rápido novo registro sob uma chave própria se o titular ainda for elegível para certificação. Disputas sobre pagamento ou identidade devem ter um caminho rápido de revisão antes que as evidências de roteamento sejam desnecessariamente destruídas.

Sem essas salvaguardas, a alta disponibilidade na operação normal não responde ao modo de falha mais consequente.

RPKI delegado muda quem pode assinar

No RPKI delegado, o titular opera uma CA filha e controla sua chave privada. O RIR pai emite um certificado de recurso para essa CA filha. O titular pode então criar ROAs e outros objetos autorizados, automatizar alterações a partir de seus sistemas de rede e, se suportado, emitir certificados filho adicionais.

Isso dá ao operador três formas de independência. Ele não precisa do portal de assinatura hospedado para cada alteração de roteamento. Pode proteger a chave de acordo com sua própria política de segurança. Pode gerenciar recursos recebidos de vários RIRs pai por meio de um único sistema local, reduzindo ações manuais inconsistentes entre interfaces regionais.

A independência é criptograficamente significativa. O RIR pai não pode assinar um objeto falso com a chave do filho só porque emitiu o certificado filho. Um registro de auditoria mantido localmente pode mostrar exatamente o que o titular assinou e quando. O operador pode decidir o quão estritamente as mudanças na intenção BGP e nos objetos RPKI são acopladas.

A delegação não torna o titular seu próprio ponto de ancoragem de confiança para os recursos. O pai ainda decide quais recursos estão no certificado. Pode substituir um certificado por um mais restrito após uma transferência ou devolução. Pode revogar o certificado filho. Se o titular assinar além do escopo válido, as partes confiantes rejeitarão a alegação excessiva.

Esse limite é importante em uma disputa. A delegação protege contra a dependência da chave e interface hospedada do pai; não permite que um ex-titular mantenha a certificação após uma transferência legítima. Não torna os registros de registro obsoletos. Dá ao operador controle sobre as declarações dentro do escopo que o pai certifica atualmente.

A delegação deve, portanto, ser apresentada como separação de funções, não como secessão. Seu valor está em que nenhuma instituição única possui todas as chaves de assinatura e controla todas as decisões dos pais. Seu limite é que a hierarquia de recursos ainda precisa de um pai autoritativo.

Publicação cria um terceiro modelo

A comparação usual entre RPKI hospedado e delegado ignora um meio-termo útil. Um titular pode operar sua própria CA e chave privada enquanto usa o serviço de publicação do depósito do RIR. A ARIN chama isso de Serviço de Publicação de Repositório. O RIPE NCC oferece "Publicar no Pai". A APNIC oferece publicação para clientes que auto-hospedam.

Esse modelo híbrido separa a custódia da assinatura da distribuição. O operador pode criar objetos sem a CA hospedada do RIR, enquanto o RIR fornece um depósito de alta disponibilidade já acessado pelas partes confiantes. Isso evita que cada titular precise fornecer e defender um serviço de publicação global.

O serviço híbrido geralmente oferece o melhor equilíbrio para um operador competente. O controle local da chave reduz a dependência da interface de assinatura hospedada. A publicação pelo pai reduz a carga operacional e a proliferação de depósitos frágeis. Padrões como RFC 8181 definem solicitações autenticadas de publicação e remoção, permitindo que CA e depósito sejam gerenciados por partes diferentes.

A separação não é independência completa. O provedor de publicação pode recusar uma alteração, ficar indisponível ou excluir material de acordo com seus termos. O pai ainda emite o certificado de recurso filho. Um operador que precisa da maior autonomia pode operar tanto a CA quanto o depósito, mas então aceita as responsabilidades de disponibilidade e segurança associadas.

A discussão da APNIC em 2025 sobre disponibilidade de RPKI descreve a compensação diretamente. Uma CA delegada dá ao titular mais controle sobre seu estado RPKI e a responsabilidade pela emissão e renovação de objetos. No entanto, permanece dependente do ponto de ancoragem de confiança da APNIC e, se usar a publicação da APNIC, desse depósito. O documento também alerta que muitos depósitos delegados são pontos únicos em um único local.

O modelo útil é, portanto, um espectro. O modo hospedado coloca assinatura e publicação no RIR. O modo híbrido mantém a assinatura localmente e a publicação com um provedor. O modo totalmente delegado mantém ambos localmente. A certificação pai permanece sobre todos os três. As organizações devem escolher conscientemente a dependência que estão dispostas a absorver.

Auto-hospedagem tem sua própria armadilha de revogação

Um argumento para o RPKI delegado que ignora falhas operacionais é incompleto. Uma CA deve emitir manifestos e listas de revogação atuais antes de seus próximos tempos de atualização. Seu depósito deve fornecer material consistente. As chaves devem sobreviver a falhas de hardware sem serem facilmente roubadas. A equipe deve entender declarações excessivas, troca de chaves e intercâmbio com o pai.

Uma CA delegada negligenciada pode sobrecarregar as partes confiantes e tornar seus próprios objetos inutilizáveis. O documento RIPE-847 trata de um caso extremo: se o RIPE NCC não conseguir encontrar e validar o manifesto atual e a lista de revogação de uma CA delegada por mais de três meses, ele deve revogar o certificado de recurso após esforços razoáveis de busca e notificação. A política visa explicitamente CAs permanentemente não funcionais, não falhas curtas comuns.

Essa política revela a obrigação mútua. A delegação dá ao titular o controle sobre a assinatura, mas o pai e a comunidade de partes confiantes precisam da garantia de que o filho não permaneça permanentemente defeituoso. O pai deve ser capaz de podar um ramo morto. O titular deve receber evidências do erro de validação, aviso prévio e um caminho de recuperação.

O operador também está sujeito ao risco de continuidade de pessoal. O único engenheiro que configurou a CA pode sair. Chaves de backup podem existir, mas serem ilegíveis. Uma aquisição corporativa pode separar a equipe de rede da instalação de segurança. Uma crise pode revelar que a soberania local dependia de um único laptop e de uma única memória.

O serviço delegado não é necessariamente intensivo em computação; software moderno de CA pode rodar em hardware modesto. Os custos reais são institucionais: propriedade, responsabilidade pela prontidão, revisão de mudanças, teste de backups, monitoramento do depósito e planejamento de sucessão. Grandes operadores podem falhar nessas tarefas, enquanto um operador pequeno e disciplinado pode executá-las corretamente.

A comparação com o serviço hospedado deve, portanto, contar ambos os pontos únicos de revogação. Usuários hospedados correm o risco de depender da decisão e recuperação do provedor. Usuários delegados correm o risco de se tornar a autoridade falha dentro de seu próprio ramo. Um design híbrido e um processo pai sólido podem reduzir ambos os riscos, mas não eliminá-los.

Migração é onde a opcionalidade é testada

Um mercado só oferece escolha se os usuários puderem mudar sua escolha. A migração entre RPKI hospedado e delegado é tecnicamente delicada, pois a CA antiga e a nova podem cobrir os mesmos recursos enquanto as partes confiantes recuperam os dados em momentos diferentes.

A documentação do RIPE NCC sobre hospedagem afirma que um usuário que muda para um serviço delegado deve primeiro revogar a CA hospedada e que uma migração make-before-break atualmente não é possível. A APNIC afirma que os modos hospedado e auto-hospedado podem operar em paralelo durante as transições. A ARIN pede que os usuários entrem em contato com os serviços de registro ao alterar o modo de implantação. Estas são experiências operacionalmente substancialmente diferentes.

A transição ideal preserva intenções de roteamento válidas enquanto a chave e os pontos de publicação mudam. O usuário deve exportar suas autorizações atuais, preparar a nova CA, testar o intercâmbio com o pai e o depósito, publicar objetos equivalentes e observá-los de validadores independentes antes que a CA antiga desapareça. Se a política regional proibir sobreposição, o serviço deve suportar um failover planejado com reversão rápida.

Certificação paralela não é automaticamente inofensiva. Objetos duplicados ou inconsistentes podem confundir os operadores, e uma chave antiga não deve reter autoridade por mais tempo do que o necessário. Uma sobreposição segura requer duração fixa, escopo de recurso equivalente, responsabilidade clara e encerramento automático. A alternativa, no entanto, não deve ser um período inexplicado em que o usuário não tem controle hospedado nem delegado.

A migração também importa em uma transferência, fusão ou reestruturação corporativa. Um comprador pode querer controle delegado, enquanto o vendedor usava um serviço hospedado. Um grupo que opera em vários RIRs pode consolidar suas CAs. O RIR deve tratar a transição de RPKI como parte padrão do movimento de recursos, não como uma reflexão tardia deixada para o dia do fechamento.

Medidas de portabilidade melhorariam a responsabilidade. Cada RIR poderia publicar as etapas normais, o período mínimo de aviso, o período esperado sem acesso a alterações, a disponibilidade de sobreposição e o contato de escalonamento para o caso de um failover malsucedido. Se a opcionalidade não puder ser exercida com segurança, o padrão hospedado tem mais aprisionamento do que sua interface simples sugere.

Redes críticas precisam de uma escolha baseada em consequências

Não existe um único modelo de implantação correto para todos os titulares. A escolha deve depender da consequência de não poder alterar uma autorização, da complexidade do roteamento e da capacidade da organização de operar uma CA.

Um pequeno provedor com alguns prefixos estáveis e uma única origem pode racionalmente usar o serviço hospedado. O RIR pode proteger chaves, renovar objetos e operar a publicação de forma mais confiável do que o provedor. A delegação poderia adicionar modos de falha sem ganho significativo. O provedor ainda deve exportar seu inventário de ROA, manter contatos de emergência e entender os termos de rescisão.

Um operador multi-RIR com mudanças frequentes de roteamento, múltiplas origens, clientes e mitigação automatizada tem um argumento mais forte para assinatura delegada. Ele pode integrar a autorização em mudanças de rede aprovadas, manter um único painel de controle em vários pais e reduzir a dependência de vários portais. A publicação híbrida pode evitar a operação de muitos depósitos públicos.

Redes públicas merecem atenção especial. Hospitais, comunicações de emergência, sistemas fiscais, nuvens públicas e redes de pesquisa podem sofrer danos desproporcionais com a fragmentação da acessibilidade. Isso não significa que toda entidade pública deva auto-hospedar. Significa que o modelo escolhido deve ter metas explícitas de continuidade, recuperação de acesso testada, mais de um administrador treinado e um caminho de escalonamento pré-estabelecido para o pai.

A responsabilidade para com entidades downstream também conta. Um titular direto pode criar ROAs para clientes que não podem participar diretamente de um serviço RIR. Se uma única conta hospedada controla muitas origens downstream, o bloqueio ou a apropriação da conta tem um raio de impacto maior. Sub-CAs delegadas podem distribuir o controle, mas apenas onde o pai e o titular puderem suportá-lo com segurança.

Os conselhos devem fazer uma pergunta simples: se o provedor atual ou a CA local se tornar indisponível durante uma mudança de roteamento, como a autorização válida seria restaurada? A resposta deve nomear pessoas, chaves, contatos dos pais, caminhos de publicação e o período máximo tolerável. Um modelo escolhido apenas por sua tela de configuração simples não passou neste teste.

Governança dos membros deve moldar o padrão

RIRs não são provedores de software comuns. Eles coordenam recursos únicos dentro de instituições regionais governadas pela comunidade. Seus termos de RPKI hospedado podem afetar membros que não podem levar os mesmos endereços para um pai concorrente. Isso coloca a responsabilidade dos membros no centro do design do serviço.

Os membros devem aprovar ou revisar as categorias de eventos que desencadeiam uma revogação, o prazo associado a cada categoria, o tratamento de contas disputadas e o caminho de saída para o serviço delegado. As comunidades técnicas devem auditar as práticas de certificados e depósitos; as comunidades jurídicas e de governança devem revisar a linguagem de rescisão e responsabilidade. Nenhuma disciplina isolada é suficiente.

O padrão deve ser o modo hospedado porque a adoção é importante, e não porque a concentração institucional é invisível. No momento da inscrição, o usuário deve receber uma comparação clara dos controles. O modo hospedado significa que o provedor gerencia a chave e o depósito. O modo delegado significa que o titular gerencia a chave e possivelmente a publicação. O modo híbrido divide essas tarefas. Todos permanecem sob o certificado pai.

Os usuários não devem precisar provar status excepcional para escolher a delegação se atenderem aos requisitos técnicos publicados. Um conselho também não deve exigir delegação para membros que não possam operá-la com segurança. As taxas de serviço devem refletir os custos reais, sem precificar a independência criptográfica como um luxo para grandes players históricos.

Alterações nos termos merecem aviso prévio à comunidade, a menos que segurança urgente ou lei tornem isso impossível. Os termos de 2026 do RIPE NCC, por exemplo, definem a custódia hospedada e delegada e estabelecem as condições de revogação. Clareza comparável deve estar disponível em cada região, mesmo que a regra exata seja diferente.

A instituição deve publicar classes de incidentes e desempenho de recuperação. Os membros não podem julgar se o acordo de conveniência permanece sólido se conhecerem apenas a disponibilidade do serviço. Um portal pode estar disponível enquanto um titular não consegue alterar objetos erroneamente; um depósito pode estar acessível enquanto um erro de registro excluiu os corretos.

Contratos devem distinguir abuso de discordância

Cláusulas amplas de rescisão protegem os provedores contra fraude, comprometimento e uso ilegal. Elas também podem misturar disputas não relacionadas com a continuidade da certificação. Uma fatura não paga, uma dúvida sobre um documento corporativo, uma alegação de abuso e uma chave privada roubada não representam o mesmo risco de roteamento.

Os termos de serviço devem separá-los. Um comprometimento confirmado de chave pode exigir revogação imediata. A perda legal após uma transferência concluída requer troca rápida de certificado. Suspeita de apropriação de conta exige congelamento de novas assinaturas, reautenticação forte e preservação de objetos válidos existentes quando seguro. Uma taxa contestada pode justificar suspensão de serviço, mas a destruição automática de autorizações de rota deve ser o último recurso quando o recurso ainda está registrado no titular.

Essa distinção não cria um direito incondicional à certificação. Ela alinha o remédio com a ameaça. O RPKI não deve se tornar um mecanismo geral de cobrança só porque é eficaz. Um RIR também não deve continuar assinando para uma parte que não possui mais o recurso.

Razões escritas são mais importantes para usuários hospedados, pois eles não podem contornar o provedor. O aviso deve indicar se a restrição afeta o acesso ao portal, a criação de novos objetos, a publicação, o escopo do certificado ou toda a CA. Um congelamento temporário de acesso é diferente de uma revogação, e os usuários precisam saber qual condição se aplica.

A revisão deve ser rápida o suficiente para a operação de roteamento. Um revisor técnico pode verificar primeiro a identidade, o escopo do recurso e a diferença de objetos. Um revisor contratual separado pode decidir sobre a disputa subjacente. Um contato de emergência deve estar disponível fora do horário comercial normal para impactos generalizados de validação.

Os termos de responsabilidade também devem refletir o controle atribuído. O usuário hospedado é responsável por instruções falsas e pela segurança das credenciais. O provedor é responsável pela execução fiel de instruções aceitas, pela proteção da chave sob sua custódia e pela adesão ao processo de revogação publicado. Redes distantes permanecem responsáveis por sua própria política de roteamento. Uma divisão clara é mais crível do que uma cláusula que implica que qualquer consequência recai sobre a parte mais fraca.

Continuidade precisa de exercícios, não apenas de uma página de política

Um operador deve testar sua recuperação de RPKI antes de uma crise. O exercício pode começar sem alterar objetos públicos. As equipes devem listar os prefixos atuais, ASes de origem, comprimentos máximos, CAs pai, configurações hospedadas, filhos delegados e provedores de publicação. Devem comparar esse inventário com anúncios BGP reais e dados validados.

Usuários hospedados devem verificar que pelo menos duas pessoas autorizadas com credenciais independentes podem acessar o serviço. Os contatos operacionais e legais devem estar atualizados. A equipe deve saber como alcançar o RIR se o acesso normal falhar e como a identidade é restaurada. Deve manter uma cópia legível por máquina das autorizações pretendidas.

Usuários delegados devem testar o backup e a recuperação de chaves em um ambiente isolado, monitorar a renovação de certificados, validar manifestos e listas de revogação e observar a publicação de fora de sua própria rede. Mais de uma pessoa deve entender o intercâmbio com o pai e o depósito. A documentação deve sobreviver a uma saída ou saída de pessoal.

Usuários híbridos devem testar ambas as metades. Uma assinatura local bem-sucedida não é suficiente se o serviço de publicação rejeitar o objeto. Eles devem ser capazes de distinguir uma falha de CA de uma falha de depósito e saber se um depósito alternativo pode ser configurado a tempo sob o pai.

Todos os usuários devem praticar uma mudança de AS de origem. O teste deve incluir a criação da nova autorização antes da troca de rota, sua observação por validadores independentes, a aplicação das mudanças BGP, a verificação do status de validação e a remoção da autorização antiga após a convergência. Se um teste ao vivo for perigoso, um ambiente de teste regional pode revelar erros de processo.

O resultado deve ser uma meta de continuidade expressa em horas, não em adjetivos. Organizações diferentes escolherão tolerâncias diferentes. O exercício é bem-sucedido se revelar a dependência exata que controla a recuperação e nomear um responsável para corrigi-la.

Partes confiantes completam o quadro de risco

O titular do recurso e o RIR não decidem sozinhos sobre a acessibilidade. As partes confiantes recuperam o material RPKI e o validam. Roteadores recebem os dados validados e aplicam políticas locais. Essa arquitetura distribuída limita o comando central, mas torna as consequências desiguais.

Se uma CA hospedada desaparecer e nenhuma autorização de cobertura existir mais, uma rota anteriormente válida pode se tornar "Não encontrada". Muitas redes ainda aceitam "Não encontrada". Se uma autorização de cobertura sobrevivente entrar em conflito com a rota, ela pode se tornar inválida, e redes que rejeitam "Inválido" podem removê-la. Caches e horários de atualização fazem com que a mudança ocorra em momentos diferentes.

Operadores não devem presumir que a disponibilidade do depósito ou a revogação do certificado produz um resultado global imediato e uniforme. O documento de disponibilidade da APNIC alerta contra uma confiança no RPKI que é mais forte do que o pretendido pela arquitetura, como exigir ROAs de clientes e rejeitar qualquer rota não coberta por uma ROA sem considerar características de disponibilidade.

Essa cautela não enfraquece o argumento para a validação de origem. Ela clama por segurança em camadas. As redes podem combinar RPKI com contratos de cliente, filtros de rota, dados do Internet Routing Registry, verificação direta e exceções de emergência governadas por controles rigorosos. Uma exceção não deve se tornar silenciosamente uma aceitação permanente de dados de roteamento ruins.

A diversidade de partes confiantes também pode ajudar na recuperação. Titulares e RIRs devem observar mais de uma implementação e visão de validador antes de declarar um failover concluído. Um depósito pode parecer saudável localmente, enquanto validadores remotos não conseguem recuperá-lo. Um objeto assinado pode estar presente, mas ser rejeitado devido a declaração excessiva ou material de suporte desatualizado.

A armadilha da comodidade é, portanto, visível em ambos os lados. Produtores podem se tornar dependentes de um único provedor de assinatura. Consumidores podem se tornar dependentes de uma única classe de dados de validação, sem plano para sua perda temporária. Uma segurança de roteamento madura considera o RPKI autoritativo para o que pode provar, mas se recusa a tratá-lo como a única evidência disponível em todas as emergências.

Um contrato hospedado melhor tem termos concretos

O modo hospedado pode ser melhorado sem torná-lo pesado. A primeira reforma é um registro de custódia de objetos: uma lista continuamente exportável e assinada das intenções de roteamento atuais, recursos certificados e identificadores de publicação. Ela não revelaria a chave privada hospedada. Permitiria ao titular recriar autorizações equivalentes sob uma CA substituta.

A segunda é uma escada de revogação. Problemas de conta de baixo risco devem restringir alterações enquanto preservam objetos existentes quando seguro. Eventos de registro de risco mais alto devem gerar aviso prévio e transição. Um comprometimento confirmado pode desencadear revogação imediata e uma recuperação limpa de chave. Cada degrau deve ter autorização e revisão nomeadas.

A terceira é um registro portátil. Um usuário que escolhe a delegação deve poder preparar a troca de identidade, publicação e objetos equivalentes antes que a CA hospedada seja removida, sujeito a salvaguardas contra sobreposição descontrolada. Serviços regionais que não podem suportar isso devem publicar a lacuna exata e um plano para fechá-la.

A quarta é uma confirmação independente para ações destrutivas. A revogação de uma CA hospedada inteira, a exclusão de todas as configurações ou a redução de recursos certificados deve exigir dupla verificação, a menos que renovação automatizada ou transferência pré-aprovada siga um evento verificado. O sistema deve mostrar o impacto esperado em anúncios conhecidos antes da execução.

A quinta é um relatório de serviço que mede mais do que a disponibilidade. RIRs devem relatar erros de registro com impacto em certificados, migrações malsucedidas, revogações de emergência, tempo de recuperação e desempenho de notificação. Números pequenos devem ser divulgados com cuidado, sem afirmar que sustentam taxas globais.

A sexta é um remédio estreito. Se um erro do provedor remover uma autorização válida, ele deve oferecer restauração imediata, suporte especializado, um registro de incidente retido e revisão independente. Um erro grave repetido deve chegar ao conselho e aos membros, não permanecer como um ticket de suporte privado.

Essas salvaguardas tornam o RPKI hospedado mais conveniente, não menos. Reduzem a quantidade de negociação personalizada necessária quando as suposições normais falham.

O que a Number Resource Society pode adicionar

A Number Resource Society se apresenta como defensora do registro preciso, dos direitos do titular, da participação e da redução de barreiras burocráticas. O RPKI hospedado é um lugar adequado para traduzir esses princípios em um serviço mensurável para os membros.

A NRS poderia publicar uma matriz de escolha de implantação comparando os cinco RIRs. Deve indicar quem detém a chave privada, se o serviço delegado está disponível, se a publicação no pai é oferecida, como a migração funciona, quais razões de revogação são publicadas, qual prazo se aplica e onde um titular pode solicitar revisão. Cada entrada deve referenciar o documento RIR relevante e mencionar questões em aberto.

Poderia manter três exercícios de continuidade: um para usuários hospedados, um para CAs delegadas e um para publicação híbrida. O exercício hospedado testaria a recuperação de acesso e a exportação de configuração. O exercício delegado testaria chaves, manifestos, intercâmbio com o pai e sucessão. O exercício híbrido testaria assinatura local contra publicação remota. Os resultados poderiam permanecer privados para a unidade, enquanto temas comuns de falha são publicados sem nomear taxas não suportadas.

A NRS também poderia trazer operadores pequenos para discussões de política regional. Grandes redes podem avaliar software de CA e negociar suporte urgente por meio de relacionamentos estabelecidos. Um provedor rural ou uma rede sem fins lucrativos pode não saber que acesso ao portal, escopo de certificado e publicação de objetos são controles separados. Perguntas simples em reuniões de membros podem melhorar o serviço para todos.

A contribuição deve permanecer limitada. A defesa da NRS não a estabelece como âncora de confiança RPKI, autoridade certificadora, operadora de depósito ou árbitro neutro. Não deve implicar que todo titular pode auto-hospedar com segurança ou que o serviço do RIR é inerentemente suspeito. Seu papel útil é permitir escolha informada, saída prática e responsabilidade comparável.

A crítica institucional positiva é mais sustentável do que a suspeita. Um registro que elogia um design de transição sólido e identifica um prazo fraco pode fornecer aos conselhos dos RIRs uma lista de melhorias práticas. Também pode mostrar aos operadores quando o serviço hospedado é a escolha responsável, em vez de tratar a custódia local da chave como um distintivo de status.

Objeções comuns perdem a questão da alocação

Defensores do RPKI hospedado frequentemente dizem que os RIRs já controlam o registro, então chaves delegadas não acrescentam muito. A premissa está parcialmente correta: o pai pode restringir ou revogar um certificado delegado. A conclusão está errada. O controle da chave filha ainda impede que o pai assine as intenções de roteamento do filho e permite que o operador faça alterações sem a interface hospedada. A separação não apaga a hierarquia; reduz a concentração dentro dela.

Críticos dizem que o serviço hospedado é inseguro porque o RIR detém a chave. Isso também é muito geral. Um RIR bem administrado pode proteger chaves, renovar objetos e publicar depósitos de forma mais confiável do que muitos membros. A questão relevante é se seus controles de segurança, autorização e recuperação correspondem à concentração de poder.

Outra objeção é que a migração paralela enfraquece a exclusividade. Isso pode ser o caso se mal projetada. Uma sobreposição curta e controlada para autorizações equivalentes é diferente de uma certificação concorrente ilimitada. Se mesmo uma sobreposição curta for inaceitável, um failover planejado e reversão rápida ainda são possíveis.

Alguns argumentam que a política local das partes confiantes torna a continuidade do produtor menos urgente. A política local mitiga ou varia a consequência, sim. Não pode recriar uma autorização válida ausente e não impede perda seletiva de acessibilidade. Produtores ainda precisam de evidências precisas e contínuas.

Finalmente, alguns membros dirão que opções sofisticadas aumentam as taxas para todos. Comunidades regionais podem manter o serviço hospedado simples enquanto cobram uma taxa transparente para suporte delegado ou publicação. As salvaguardas essenciais – razões, prazos, exportação e recuperação – não são recursos de luxo. São obrigações básicas de um serviço vinculado a recursos únicos.

Cada objeção fica mais clara quando formulada em termos de alocação. Qual parte controla o risco, qual parte pode preveni-lo e qual parte pode corrigi-lo? Modelos hospedados e delegados devem ser julgados por essas respostas, não por uma preferência ideológica por operação central ou local.

Evidências devem melhorar antes que a confiança se torne absoluta

Material público explica arquiteturas, termos e incidentes individuais, mas não fornece um conjunto de dados completo entre RIRs sobre CAs hospedadas revogadas, migrações malsucedidas, alterações bloqueadas, tempos de recuperação ou impactos de roteamento. Páginas de serviço revelam recursos, não todos os resultados operacionais. Casos de suporte privados e eventos de segurança corretamente não são todos públicos.

Isso limita afirmações empíricas. Não é possível estimar uma probabilidade geral de que o RPKI hospedado cause perda de rota. Evidências públicas também não podem provar que a operação delegada é mais confiável para todos os titulares. Modelos de serviço regionais e caminhos de controle são observáveis; taxas de falha comparativas não são.

Relatórios dos RIRs podem fechar parte da lacuna. Eles devem distinguir indisponibilidade de portal, erros de assinatura, indisponibilidade de depósito, erros de certificado pai, configuração incorreta do usuário e rescisão não intencional. Devem registrar se os objetos atuais permaneceram válidos, se o status da rota mudou e quanto tempo a recuperação levou.

Operadores podem contribuir com relatórios anônimos com cronogramas verificáveis. Pesquisadores podem observar mudanças em certificados e objetos públicos, mas devem evitar inferir intenção apenas a partir do desaparecimento. Uma transferência, troca de chave ou remoção consciente de ROA pode parecer uma falha externamente.

A confiança deve, portanto, ser mais forte na arquitetura e mais fraca na prevalência. O serviço hospedado concentra os controles nomeados. O serviço delegado distribui alguns deles. Ambos permanecem sob um RIR pai. Estes são fatos documentados. Com que frequência cada arranjo causa dano material permanece insuficientemente medido.

Um programa de governança que admite esse limite é mais crível do que um que seleciona algumas falhas ou números de disponibilidade para provar um caso universal. Melhores evidências permitirão que comunidades futuras ajustem o padrão sem suposições.

Conveniência deve ser reversível

O RPKI hospedado fez o que uma boa infraestrutura muitas vezes faz: tornou uma prática de segurança difícil comum. Operadores podem criar autorizações de rota sem configurar uma CA, gerenciar manifestos ou defender um depósito público. Essa conquista deve ser preservada.

O perigo surge quando a fácil adoção é acompanhada pela falta de uma saída segura. Se o registro detém a chave, publica os objetos, altera o escopo do certificado e controla o novo registro, uma disputa ou erro pode deixar o operador incapaz de manter sua própria intenção de roteamento. A alta disponibilidade normal não elimina essa dependência estrutural.

O RPKI delegado oferece um contrapeso significativo. O titular assina com sua própria chave, pode automatizar alterações locais e gerenciar vários pais de forma consistente. A publicação híbrida reduz a carga. Nenhuma opção elimina a CA pai ou os deveres de uma operação confiável.

O compromisso maduro é a pluralidade. O serviço hospedado continua sendo o padrão para usuários simples. A assinatura delegada é um direito padrão para titulares capazes. A publicação no pai está disponível como meio-termo. A migração é testada e, quando seguro, feita como make-before-break. As razões de revogação são precisas, disputas comuns não desencadeiam consequências de roteamento desproporcionais, e medidas de emergência envolvem revisão e recuperação rápida.

Conveniência não é o oposto de controle. É uma forma de emprestar o controle de outra instituição para operação de rotina. O acordo é sólido apenas se o tomador puder ver os termos, restaurar suas intenções, escolher um arranjo diferente e se recuperar se o emprestador de conveniência cometer um erro.

O RPKI exige que as redes confiem em declarações criptográficas. Sua governança deve aplicar a mesma disciplina a promessas institucionais. Quem detém a chave, quem pode revogar, quem publica e quem recupera deve ser tão claro quanto o prefixo e o AS de origem em uma ROA. Quando essas respostas são explícitas e reversíveis, o serviço hospedado é uma rampa. Quando estão ocultas e inevitáveis, é uma armadilha.

Fontes