Um ROA defeituoso pode transformar a segurança de rota em uma indisponibilidade de modo comum

Resumo

• Em 18 de março de 2025, fontes públicas de análise de rede relataram que rotas BGP associadas à Coreia do Norte tornaram-se inválidas para RPKI após a publicação de uma Autorização de Origem de Rota defeituosa, aparentemente autorizando um /22 enquanto a rede anunciava quatro /24s.
• O incidente é um caso de responsabilização útil porque o mecanismo de segurança de rota funcionou como projetado da perspectiva do validador: redes que rejeitam rotas inválidas reduziram a acessibilidade para rotas que eram operacionalmente legítimas, mas inconsistentes com o novo ROA.
• Portanto, a falha não foi um argumento contra o RPKI. Foi uma evidência de que os dados do RPKI se tornaram uma infraestrutura compartilhada e devem ser geridos com revisão de mudanças, preparação, disciplina de maxLength, monitoramento, reversão e alerta.
• A dependência de modo comum é o principal risco. À medida que mais redes adotam a validação de origem de rota e rejeitam inválidos, um único erro de publicação por parte de um detentor de recurso ou lado do RIR pode ter consequências operacionais mais amplas porque muitas redes consomem a mesma declaração criptográfica.
• O padrão de reparo deve ser verificável: identificar os prefixos inválidos, corrigir o ROA, medir a recuperação da propagação da rota, preservar a linha do tempo e publicar evidências suficientes para que outros operadores possam auditar seus próprios controles de maxLength e alerta.

Registro de evidências e como é usado

Este artigo trata o registro público como evidência em camadas. Relatórios de incidentes, padrões, medições de navegador ou roteamento, materiais regulatórios ou de políticas, e orientações atuais de operadores são usados para diferentes alegações. Fontes de autoria de empresas são atribuídas como posições da empresa. Padrões e orientações posteriores são usados para explicar controles e apresentar expectativas de responsabilização, não para inventar fatos privados ou impor retroativamente obrigações posteriores onde o registro público não suporta essa alegação.

O RPKI tornou o erro visível e consequente

O RPKI existe porque o BGP comum dá às redes muita margem para acreditar em alegações de acessibilidade falsas. As Autorizações de Origem de Rota permitem que os detentores de recursos digam qual sistema autônomo pode originar qual prefixo e, através do maxLength, quão específico pode ser o anúncio. As redes que realizam a Validação de Origem de Rota podem então tratar as rotas como válidas, inválidas ou não encontradas e aplicar políticas. Essa é uma grande melhoria de segurança. O incidente do ROA defeituoso da Coreia do Norte mostra que a melhoria cria uma nova dependência operacional na precisão dos dados de autorização publicados.

A Kentik relatou que, em 18 de março de 2025, as rotas BGP da Coreia do Norte tornaram-se RPKI-inválidas devido à publicação de um ROA defeituoso. Outros relatos públicos descrevem uma autorização /22 com maxLength /22 enquanto a rede anunciava quatro prefixos /24. Sob a lógica do ROV, uma rota pode ser inválida mesmo que o AS de origem corresponda quando o prefixo anunciado é mais específico do que o ROA permite. Se os operadores rejeitam inválidos, a acessibilidade cai. Em outras palavras, o sistema não falhou ao ignorar o ROA. Falhou porque o ROA descrevia incorretamente o roteamento de produção.

Esse é o ponto de modo comum. Antes do RPKI, os filtros de rota e o julgamento de cada rede podiam falhar de maneiras diferentes. Com o RPKI, muitas redes podem consumir o mesmo objeto assinado. Isso é bom quando o objeto está correto: um sequestro de origem errada pode ser rejeitado amplamente. É perigoso quando o objeto está errado: rotas legítimas podem ser rejeitadas amplamente. A fonte compartilhada de verdade torna-se um modo de falha compartilhado.

A resposta não é evitar o RPKI. Recusar-se a validar porque as autorizações podem estar erradas deixa o antigo problema de confiança do BGP intacto. A resposta é tratar os dados do ROA como controle de mudanças de produção. Criar o primeiro ROA para um detentor de recurso, alterar o maxLength, mover origens ou desagregar prefixos deve ser tratado como uma mudança de roteamento de alto impacto. Precisa de revisão, simulação, monitoramento, reversão e alerta.

Isso é especialmente importante para redes pequenas ou concentradas. A pegada pública da Internet da Coreia do Norte é limitada em comparação com um provedor de hiperescala, o que tornou o incidente mais fácil de analisar. Mas o mesmo padrão pode afetar universidades, governos, bancos, CDNs, operadoras regionais ou redes de serviços de emergência. Um pequeno número de prefixos ainda pode transportar serviços críticos. Um ROA errado pode transformar um controle de segurança em um incidente de disponibilidade.

maxLength é uma decisão política, não um campo de formulário

O campo opcional maxLength é onde muitos erros de ROA se tornam indisponibilidades. Um ROA para um prefixo de cobertura pode autorizar apenas esse comprimento de prefixo ou permitir anúncios mais específicos até um máximo declarado. Se a rede normalmente anuncia /24s sob um /22, mas o ROA autoriza apenas o /22, os validadores veem os /24s como inválidos. Essa parece ser a explicação pública do incidente da Coreia do Norte. O campo não era um detalhe cosmético; ele codificava se as rotas de produção podiam existir.

Os operadores às vezes preferem valores estreitos de maxLength porque autorizações excessivamente amplas podem enfraquecer a proteção. Se um ROA /22 permite /24s, então específicos não autorizados usando a mesma origem podem ser mais fáceis de tratar como válidos. Se não permite /24s, a engenharia de tráfego legítima ou a desagregação podem falhar. O valor correto depende da intenção real de roteamento, planos de emergência e monitoramento. Não existe uma configuração de piloto automático universalmente segura.

Isso torna o maxLength uma questão de governança. Quem conhece o conjunto de rotas de produção? Quem aprova a desagregação? Quem mantém os ROAs quando prefixos se movem, anúncios mudam ou provedores são adicionados? Quem recebe alertas quando uma rota se torna inválida? Quem pode corrigir o objeto fora do horário comercial? Quem verifica se um ROA recém-publicado corresponde ao BGP antes que as redes dependentes comecem a rejeitar inválidos? Essas perguntas parecem processuais, mas determinam se uma implantação de segurança protege ou quebra a acessibilidade.

A orientação da APNIC sobre limpeza de rotas inválidas e os materiais dos RIRs sobre ROAs incorretos apontam para o caminho prático de reparo: encontrar a rota inválida, inspecionar o ROA, corrigir o maxLength ou a origem e aguardar a convergência dos caches das partes confiantes e da propagação BGP. Essa sequência deve ser ensaiada. Um primeiro ROA para um país, agência ou empresa não deve ser publicado como se fosse uma atualização burocrática de baixo risco.

O problema também está na linguagem do contrato. Provedores de rede gerenciados, titulares de contas em RIRs e equipes de roteamento terceirizadas podem compartilhar a responsabilidade pela criação do ROA. Um cliente pode não saber que um provedor alterou um ROA até que os usuários relatem falhas de redes validadoras. Os contratos devem especificar quem possui os dados do ROA, quem aprova o maxLength, que monitoramento existe e que evidência é fornecida após uma mudança de estado de validade.

Os incentivos fail-open e fail-closed são desconfortáveis

O RPKI cria uma tensão de incentivos. Se as redes rejeitam rotas inválidas, ajudam a impedir sequestros e origens incorretas. Se aceitam rotas inválidas, evitam quebrar a acessibilidade quando uma rede legítima publica um ROA defeituoso. O incidente da Coreia do Norte está nessa tensão. As rotas tornaram-se inválidas. As redes que aplicaram a rejeição reduziram a acessibilidade. As redes que foram permissivas podem ter mantido caminhos disponíveis, mas também preservaram uma fraqueza na segurança de rota.

Essa tensão é às vezes usada como argumento contra a validação estrita. Isso é muito simplista. Um controle de segurança que nunca bloqueia nada não pode proteger contra o ataque que foi construído para parar. Mas um controle de segurança que bloqueia o tráfego de produção devido a dados desatualizados ou errados criará pressão para desativá-lo. A resposta sustentável é melhorar a higiene dos dados e os alertas para que rotas inválidas legítimas se tornem raras, rapidamente detectadas e rapidamente corrigidas.

Pesquisas sobre conflitos benignos de RPKI e incentivos dos operadores fazem esse ponto em escala. Configurações incorretas persistem, e as redes que rejeitam inválidos podem perder tráfego quando o estado inválido é benigno. Isso cria pressão econômica contra a adoção. A correção não é normalizar dados ruins. É tornar os dados ruins visíveis, fornecer verificações pré-publicação, alertar os detentores de recursos antes da mudança de estado da rota e criar caminhos de correção de emergência.

A validação de origem de rota também altera quem paga pelos erros. Um detentor de recurso ou administrador de conta pode publicar um ROA defeituoso. A perda imediata de conectividade pode ser experimentada por usuários e serviços downstream. Os provedores de trânsito que aplicam o ROV podem ser culpados por interromper o tráfego, mesmo que sua política esteja fazendo o que o modelo de segurança diz que deveria fazer. A parte que criou o objeto ruim pode não receber todas as chamadas de suporte. Essa divisão de custos pode minar a confiança, a menos que as evidências identifiquem a verdadeira fonte de invalidez.

Um registro de responsabilidade maduro deve, portanto, evitar a frase preguiçosa "RPKI causou a indisponibilidade". Mais precisamente, uma autorização imprecisa tornou rotas legítimas de produção inválidas, e as redes validadoras que rejeitam inválidos aplicaram essa declaração. O problema raiz foi uma falha de governança de dados em um sistema de segurança compartilhado.

O monitoramento deve observar o plano de controle e o plano de autorização

O monitoramento tradicional de roteamento observa os anúncios BGP: origens, caminhos, comprimentos de prefixo, retiradas e propagação. O RPKI exige uma segunda camada de monitoramento: o plano de autorização. Uma rota pode mudar de validade sem que o roteador BGP mude seu anúncio. Um ROA recém-publicado, um certificado expirado, uma falha de repositório ou uma alteração de maxLength podem converter a rota válida de ontem na rota inválida de hoje. Monitorar apenas o BGP não é mais suficiente.

É por isso que serviços como os alertas de rota inválida do bgp.tools são importantes. Um prefixo que se torna RPKI inválido é um sinal de produção urgente. Pode indicar um sequestro, uma origem errada, uma incompatibilidade de maxLength, um ROA desatualizado, um problema de repositório ou uma mudança planejada que deu errado. O operador precisa saber rapidamente qual caso se aplica. Para uma rede crítica, esse alerta deve contatar alguém com autoridade para alterar o ROA ou o anúncio de roteamento.

A discussão posterior do RIPE Labs sobre análise de roteamento em tempo real e visualização de incidentes aponta para um futuro útil: combinar visualizações BGP, validade RPKI, propagação de rota e evidências de acessibilidade em um único fluxo de trabalho. Durante o incidente da Coreia do Norte, observadores externos puderam ver a mudança de validade e a queda de propagação. Um detentor de recurso deveria ter pelo menos esse nível de visibilidade para seus próprios prefixos antes de o público notar.

O monitoramento também deve ser pré-mudança. Antes de publicar um ROA, uma ferramenta deve comparar os ROAs pretendidos com os anúncios BGP atuais e sinalizar toda rota que se tornaria inválida. Se o resultado for intencional, o operador deve agendar a mudança de roteamento e a mudança de ROA juntas. Se não for intencional, a ferramenta deve impedir a publicação. Esta é uma lógica comum de gerenciamento de mudanças aplicada a dados criptográficos de rota.

As redes do setor público precisam de atenção especial. As agências geralmente dependem de contratados, serviços compartilhados ou upstreams para roteamento. Se a administração do ROA está com uma equipe e a continuidade do serviço com outra, um erro de maxLength pode cair entre as fronteiras de propriedade. Um plano de continuidade deve nomear o titular da conta RPKI, o proprietário do conjunto de rotas, o contato de emergência e as evidências necessárias para provar a recuperação.

Reparo verificável é melhor do que garantia

Um incidente de ROA defeituoso não deve terminar com "corrigido". Deve terminar com evidências. Qual ROA estava errado? Quais prefixos se tornaram inválidos? Qual origem foi autorizada? Qual maxLength foi definido? Quando o objeto foi publicado? Quais coletores de rota viram a queda de propagação? Quando o ROA foi corrigido? Quanto tempo os caches das partes confiantes levaram para convergir? Quais redes ainda rejeitavam a rota após a correção? Esses detalhes permitem que outros operadores aprendam e que os usuários afetados confiem no reparo.

O incidente da Coreia do Norte é documentado externamente, mas não é acompanhado pelo tipo de autópsia operacional completa que uma grande empresa ou agência pública deve fornecer após uma indisponibilidade equivalente. A análise externa pode reconstruir grande parte do evento, mas as evidências internas responderiam por que o ROA foi criado dessa forma, se existiam verificações, quem o aprovou e o que mudou depois. Esses fatos são importantes porque a mesma classe de erro pode ocorrer em qualquer lugar.

Para RIRs e provedores de ferramentas, a lição é tornar as mudanças perigosas de ROA difíceis de fazer silenciosamente. As interfaces devem mostrar os anúncios BGP atuais, simular os resultados de validade, alertar sobre conflitos de maxLength, fornecer orientação de reversão e incentivar alertas. O objetivo não é remover a autonomia do operador. É tornar a consequência de um objeto assinado visível antes que afete a acessibilidade global.

Para redes que validam RPKI, a lição é continuar aplicando enquanto melhoram o tratamento de exceções. Os operadores precisam de visibilidade das rotas inválidas que rejeitam, contatos para detentores de recursos e política para avaliação de emergência. Rejeitar inválidos não deve significar ignorar a dor do cliente; deve significar usar evidências para identificar se a rota é maliciosa, equivocada ou desatualizada e então pressionar a correção para o proprietário certo.

A conclusão é que o RPKI transforma a confiança de roteamento em dados. Isso é progresso. Mas os dados se tornam infraestrutura quando redes suficientes dependem deles. Um ROA defeituoso pode, portanto, ser um incidente de infraestrutura, não um erro administrativo. A governança tem que alcançar o poder do objeto assinado.

O controle de segurança tornou-se uma dependência de disponibilidade

A validação de origem de rota é projetada para tornar as redes mais seguras, rejeitando rotas que entram em conflito com a autorização assinada. Esse design é exatamente por que um ROA defeituoso pode causar uma indisponibilidade. O controle não é decorativo; as redes validadoras realmente o usam. Quando uma rota legítima se torna inválida devido a uma declaração errada de maxLength ou origem, as redes que rejeitam inválidos estão aplicando os dados publicados do detentor do recurso. A indisponibilidade é, portanto, um sinal de que o RPKI se tornou operacionalmente significativo, não um sinal de que é inútil.

Isso é importante para como as organizações descrevem o risco. Se os líderes disserem "RPKI nos quebrou", eles podem desabilitar o validador e retornar a um modelo de confiança mais antigo e mais fraco. Se eles disserem "nossos dados de autorização de rota não correspondiam ao nosso roteamento", eles podem corrigir o verdadeiro problema. O incidente da Coreia do Norte é melhor compreendido como uma incompatibilidade entre o plano de autorização e o plano de roteamento. Os anúncios BGP continuaram existindo. A autorização assinada mudou seu estado de validade global.

Uma dependência de disponibilidade criada por um controle de segurança deve ser governada com a mesma seriedade que qualquer outra dependência de produção. Âncoras de confiança DNSSEC, logs de transparência de certificados, respondedores OCSP, repositórios RPKI e feeds validadores estão todos nesta categoria. São sistemas de segurança, mas afetam se o tráfego de produção flui. Tratá-los como artefatos de conformidade em vez de infraestrutura ativa convida surpresas operacionais.

O risco de modo comum cresce com a adoção. Quando apenas algumas redes rejeitam rotas RPKI-inválidas, um ROA defeituoso tem alcance limitado. Quando muitas redes importantes rejeitam inválidos, o mesmo ROA defeituoso pode ter efeito amplo. Isso não é um argumento contra a adoção. É um argumento para controles de publicação rigorosos. Um mecanismo de segurança compartilhado deve se tornar mais disciplinado à medida que se torna mais bem-sucedido.

O incidente também sugere uma métrica mais cuidadosa para programas RPKI. A porcentagem de cobertura não é suficiente. Uma rede pode ter alta cobertura de ROA e ainda criar risco se os valores de maxLength estiverem errados, desatualizados ou muito amplos. Uma métrica melhor combina cobertura, alinhamento de validade, revisão de objetos desatualizados, política de maxLength, alertas, saúde do repositório e tempo de correção. O objetivo não é apenas "temos ROAs". O objetivo é "nossos ROAs descrevem com precisão as rotas que pretendemos que a Internet aceite".

Os fluxos de trabalho do RIR e da conta fazem parte da superfície de controle

Os ROAs são frequentemente criados através de portais de RIRs ou ferramentas delegadas. Isso significa que a interface do usuário, permissões de conta, fluxo de aprovação e sistema de aviso fazem parte do controle de segurança. Um validador bem projetado não pode compensar um fluxo de trabalho de publicação que permite que um erro de maxLength de alto impacto passe sem aviso. O incidente da Coreia do Norte mostra por que a criação de ROA deve incluir simulação contra anúncios BGP atuais antes da publicação.

Um portal pode dizer a um operador: se você publicar este ROA, essas rotas atualmente visíveis se tornarão inválidas. Esse aviso não é especulativo. Segue diretamente da lógica de validação de origem de rota. Se o operador pretende retirar essas rotas, o aviso ajuda a coordenar o tempo. Se o operador não pretendia a invalidez, o aviso evita uma indisponibilidade. RIRs e fornecedores de ferramentas devem tratar essa simulação como uma proteção de segurança, não como uma conveniência opcional.

A propriedade da conta também é importante. Em muitas organizações, a pessoa que pode publicar ROAs não é a mesma que gerencia roteadores ou continuidade de serviço. Um administrador de registro pode estar agindo de uma visão de gerenciamento de endereços, enquanto o NOC vê anúncios BGP e a equipe de aplicativos vê indisponibilidades. Se essas equipes não estiverem conectadas, o plano de autorização pode mudar sem que o plano de roteamento se adapte. A correção é o mapeamento de propriedade: cada ROA deve ter um proprietário de roteamento, proprietário de serviço, contato de emergência e cadência de revisão.

As permissões devem ser escopadas. Nem todo usuário de conta de registro deve ser capaz de fazer mudanças de ROA de alto impacto sem revisão. Mudanças que invalidariam rotas atualmente observadas devem exigir confirmação, talvez um segundo aprovador para recursos críticos. Caminhos de correção de emergência devem existir, mas a criação emergencial de objetos perigosos deve ser visível e registrada. Novamente, o ponto não é burocracia. É respeitar o poder operacional de uma autorização de rota assinada.

A orientação do RIR sobre ROAs incorretos e limpeza é valiosa porque normaliza a ideia de que estados inválidos muitas vezes vêm de erros comuns. Isso é construtivo. A vergonha não melhora os dados de segurança de rota. Avisos claros, melhores ferramentas, exemplos compartilhados e caminhos rápidos de correção sim. O incidente deve motivar RIRs, provedores de serviços gerenciados e detentores de recursos a melhorar o fluxo de trabalho em torno dos dados do ROA, não a recuar da publicação.

Validadores precisam de evidências para tratamento de exceções

As redes que rejeitam rotas inválidas também precisam de uma disciplina de tratamento de exceções. Se um cliente ou serviço público reclamar que uma rota está inacessível porque é RPKI-inválida, o operador validador precisa saber que evidências justificariam qualquer substituição temporária. Aceitar cegamente rotas inválidas enfraquece a segurança. Recusar-se a ajudar a diagnosticar uma rota inválida benigna enfraquece a confiança na implantação. O caminho do meio é a triagem baseada em evidências.

A primeira pergunta é se a invalidez é causada por incompatibilidade de origem, incompatibilidade de comprimento de prefixo, publicação expirada ou ausente, falha de repositório ou estado do validador. Cada causa aponta para um proprietário diferente. Uma incompatibilidade de origem pode ser sequestro ou migração desatualizada. Uma incompatibilidade de comprimento de prefixo pode ser um erro de maxLength. Uma falha de repositório pode afetar muitos prefixos. Um problema de cache do validador pode ser local. Boas ferramentas devem classificar a invalidez rapidamente.

A segunda pergunta é se a perda de acessibilidade é ampla. Coletores de rota, looking glasses, RIS/RouteViews, monitoramento comercial e relatórios de clientes podem mostrar se muitas redes perderam a rota ou apenas algumas. Essa evidência ajuda a decidir urgência e comunicação. Uma única rota inválida com impacto limitado pode ser tratada através de ticket comum. Um prefixo de serviço público crítico invalidado em muitas redes validadoras requer escalação imediata.

A terceira pergunta é quem pode reparar a fonte da verdade. Se o detentor do recurso publicou o ROA errado, a correção limpa é atualizar o ROA, não pedir a cada rede validadora que substitua a política. Se o anúncio BGP está errado, a correção limpa pode ser alterar a rota. Se ambos estão mudando como parte de uma migração, a correção é um sequenciamento coordenado. O tratamento de exceções deve empurrar o reparo para o proprietário correto, em vez de normalizar desvios locais.

É aqui que os registros públicos de incidentes ajudam. Quando um incidente conhecido, como o ROA defeituoso da Coreia do Norte, é documentado, os operadores podem usá-lo como material de treinamento. Eles podem perguntar se seu NOC teria reconhecido a invalidez, se os alertas teriam disparado, se os contatos do registro estavam atualizados e se uma reversão poderia acontecer fora do horário comercial. Um bom incidente se torna um ensaio para o próximo.

A dependência de modo comum requer verificações independentes

Falha de modo comum significa que muitas partes falham da mesma forma porque dependem do mesmo componente ou suposição. No RPKI, o objeto de autorização assinado pode se tornar esse componente compartilhado. Se estiver certo, muitas redes melhoram juntas. Se estiver errado, muitas redes podem rejeitar juntas. Verificações independentes são, portanto, essenciais antes da publicação e após a mudança.

Uma verificação independente é a comparação BGP. Compare os ROAs pretendidos com os anúncios globais atuais. Outra é o monitoramento em etapas. Publique de uma forma que permita a rápida observação de mudanças de validade e reversão. Outra são alertas externos de serviços não operados pelo detentor do recurso. Um painel local pode dizer que o objeto existe; um monitor externo pode mostrar que uma rota agora é inválida em toda a Internet pública. Ambos são úteis, e nenhum deve ser o único sinal.

Uma segunda verificação independente é a revisão humana da intenção política. A rede alguma vez anuncia /24s sob este /22? Ela tem mitigação de DDoS que desagrega? Ela usa múltiplos ASNs de origem durante failover? Um provedor anuncia em seu nome? Uma migração requer origem dupla temporária? Um ROA pode estar sintaticamente correto e operacionalmente errado se ignorar essas realidades. O revisor precisa entender a intenção de roteamento, não apenas a sintaxe do registro.

Uma terceira verificação é a expiração e a saúde do repositório. Um ROA pode se tornar inválido ou indisponível através de problemas de certificado ou repositório, não apenas erros de maxLength. Os validadores têm comportamento de cache e modos de falha. Os detentores de recursos devem monitorar se seu repositório RPKI está acessível e se as visualizações das partes confiantes correspondem aos objetos esperados. Um objeto assinado que ninguém pode recuperar não é um controle confiável.

O pensamento de modo comum também afeta a comunicação. Se um ROA defeituoso invalidar uma rota crítica, muitas redes validadoras podem rejeitá-la independentemente. O detentor do recurso precisa de um canal de status público ou contato que explique a correção. Caso contrário, cada provedor pode abrir tickets separados e gastar tempo diagnosticando a mesma causa. Uma nota pública concisa pode reduzir o trabalho duplicado e acelerar a convergência.

O problema de incentivo é solucionável se as evidências melhorarem

A adoção do RPKI enfrenta um problema de incentivo porque os benefícios de rejeitar rotas inválidas são distribuídos, enquanto a dor de uma rota inválida benigna pode ser imediata e local. Um provedor que rejeita inválidos pode ser culpado por clientes quando outra pessoa publica um ROA ruim. Um provedor que aceita inválidos pode evitar a chamada de suporte, mas contribuir para um sistema de roteamento global inseguro. Evidências melhores podem reduzir essa tensão.

Se os alertas de inválido identificarem claramente o ROA responsável, prefixo afetado, origem, maxLength e provável proprietário, o provedor validador pode explicar o problema e apontar a correção. Se as ferramentas do RIR avisarem antes da publicação, menos inválidos benignos ocorrerão. Se os detentores de recursos receberem alertas imediatamente, podem corrigir antes que muitos usuários percebam. Se os relatos públicos de incidentes normalizarem a limpeza, as organizações ficam menos tentadas a esconder erros. Cada melhoria de evidência reduz o custo da validação estrita.

As compras podem ajudar. Grandes compradores devem perguntar aos provedores de trânsito e nuvem se eles rejeitam rotas inválidas e como lidam com eventos inválidos benignos. Eles também devem perguntar quem gerencia seus próprios ROAs se o comprador tiver espaço de endereço. Um comprador que pressiona os provedores a aceitar rotas inválidas durante cada erro enfraquece a segurança de roteamento. Um comprador que mantém ROAs limpos e espera validação estrita melhora o ecossistema.

Reguladores e redes governamentais devem adotar a mesma postura. Os recursos de endereço do setor público devem ter propriedade de ROA, política de maxLength, monitoramento de rota e correção de emergência. As compras governamentais podem exigir validação RPKI dos provedores, ao mesmo tempo que exigem fluxos de trabalho de suporte para diagnóstico de rota inválida. Segurança e disponibilidade devem ser gerenciadas juntas, e não trocadas sob estresse.

O incidente do ROA defeituoso da Coreia do Norte é um lembrete compacto de que a segurança de rota não é mais apenas sobre manter atacantes fora. É também sobre manter os dados de autoridade precisos. A declaração assinada tem poder. Esse poder merece controle de mudanças, monitoramento e responsabilidade.

A decisão do leitor sobre governança de ROA

Um leitor não deve tratar o caso do ROA defeituoso como uma razão para desconfiar do RPKI. A melhor decisão é tratar a governança do ROA como governança de produção. Se uma organização tem espaço de endereço, ela precisa de um proprietário para os dados do ROA, um mapa de anúncios normais e de emergência, uma política de maxLength, simulação pré-publicação, alertas para invalidez, um caminho de reversão e um contato que possa corrigir objetos rapidamente. Sem esses controles, a organização tem uma política de rota assinada, mas não uma política de rota gerenciada.

Para detentores de recursos, a pergunta imediata é se toda rota visível é coberta por um ROA intencional e preciso. Isso inclui AS de origem, comprimento de prefixo e maxLength. Inclui também casos excepcionais: provedores de DDoS, trânsito de backup, anycast, engenharia de tráfego, janelas de migração e desagregação de emergência. Se o plano de rota e o plano de ROA vivem em ferramentas diferentes com proprietários diferentes, o risco já está presente.

Para redes validadoras, a decisão é rejeitar inválidos enquanto constroem um diagnóstico humano. A validação estrita melhora a Internet, mas os clientes precisam de evidências claras quando uma rota inválida é benigna. Os operadores devem ser capazes de explicar a invalidez, apontar para o objeto responsável e ajudar o detentor do recurso a corrigir a fonte da verdade. Isso protege a segurança sem transformar cada erro em pressão para desabilitar a validação.

Para RIRs e provedores de ferramentas, a decisão é tornar as mudanças perigosas de ROA difíceis de publicar silenciosamente. Mostre anúncios atuais. Simule a validade. Aviso antes de invalidar rotas ativas. Mantenha trilhas de auditoria. Incentive alertas. Forneça orientação de correção de emergência. Uma boa interface pode prevenir uma indisponibilidade de roteamento antes que o objeto criptográfico saia do portal.

O incidente da Coreia do Norte é compacto porque a pegada pública era pequena o suficiente para analisar. A lição é grande porque a dependência é global. À medida que a adoção do RPKI cresce, a qualidade dos dados assinados se torna tão importante quanto a decisão de validar. A Internet deve continuar avançando para a rejeição de rotas inválidas, mas esse futuro requer melhores cuidados com os dados de autoridade que tornam as rotas válidas.

A classe de falha é maior que um país

O exemplo da Coreia do Norte é útil porque é visível, mas a classe de falha não é específica de um país. Qualquer detentor de recurso que anuncie rotas mais específicas sob uma alocação de cobertura pode criar o mesmo problema com um maxLength estreito. Qualquer organização que mova prefixos entre ASNs de origem pode criar incompatibilidade de origem. Qualquer provedor de rede gerenciada que altere ROAs sem coordenar com o NOC pode invalidar o tráfego de produção. O padrão comum é uma declaração assinada que não corresponde mais à realidade operacional.

Isso significa que todo programa RPKI deve incluir um trabalho de reconciliação periódica. Pegue as rotas visíveis no BGP global. Pegue os ROAs atualmente publicados. Compare origem e maxLength. Sinalize toda rota inválida e toda rota não encontrada que deveria ser coberta. Revise toda autorização excessivamente ampla que permite específicos que a rede não pretende anunciar. Essa reconciliação não é uma tarefa única de integração. O roteamento muda. Os provedores mudam. A mitigação de DDoS muda. Fusões, aquisições e migrações para nuvem mudam os planos de origem. O plano de autorização deve seguir o plano de roteamento.

O melhor resultado de longo prazo é cultural. Os operadores devem se tornar tão desconfortáveis com ROAs desatualizados quanto com registros DNS desatualizados para serviços críticos ou certificados expirados em endpoints públicos. O objeto assinado é pequeno, mas a dependência pode ser grande. Tratá-lo como infraestrutura viva é a diferença entre segurança de rota que ganha confiança e segurança de rota que é desativada após o primeiro erro doloroso.

Essa cultura também precisa de um hábito de revisão de mudanças. Uma edição de ROA não deve ser tratada como uma atualização administrativa de registro quando pode mudar a acessibilidade sob validação estrita. O revisor deve perguntar qual rota está ativa agora, qual rota estará ativa após uma mudança de provedor, se específicos são intencionalmente autorizados, se alguma origem de DDoS ou backup precisa de autoridade temporária e como a organização saberá se o objeto publicado tornou o tráfego inválido. O plano de reversão deve ser tão explícito quanto o plano de mudança.

Se a resposta for "esperar alguém reclamar", os dados assinados não estão sob controle de produção. Provedores de nuvem, registros, operadores de servidores de rota e grandes empresas todos têm interesse em tornar esse hábito normal, porque a validação estrita funciona melhor quando os dados de autoridade são entediantemente precisos.

O mesmo hábito deve cobrir a transferência de propriedade. Os recursos de endereço se movem através de aquisições, atualizações de registro, mudanças de provedor, migrações para nuvem e projetos de recuperação de desastres. Um ROA que estava correto sob um modelo operacional pode se tornar prejudicial sob o próximo. A governança precisa, portanto, de uma lista de verificação de transferência: quem possui os objetos, quem recebe alertas, quem aprova o maxLength, quem pode revogar autorizações desatualizadas e quem verifica a visibilidade global da rota após a mudança.

O registro da Coreia do Norte é útil porque torna a falha pequena o suficiente para entender. A próxima falha pode envolver um banco, agência pública, cliente CDN ou serviço de emergência cujo plano de roteamento muda durante o estresse. A autoridade de rota assinada deve estar pronta para esse estresse antes que a validação a aplique.

Conclusão

O padrão de responsabilidade é o controle prático unido à evidência pública. O registro mais forte não finge que cada ator controlou todos os resultados. Ele identifica quem poderia prevenir a falha, quem poderia detectá-la, quem poderia limitar o raio de explosão, quem poderia notificar as partes afetadas, quem poderia reparar a relação de confiança e que evidência prova que o reparo alcançou os sistemas e pessoas que dependiam dele.