Vazamento da Cox 2025: prova da contenção do RPKI

Resumo

A análise da APNIC dos logs de atualização BGP constatou que o AS22773 apareceu como origem de 4.651 rotas IPv4 adicionais em 1º de maio de 2025. O ponto de observação intencionalmente não rejeitou rotas RPKI Inválidas, o que tornou visíveis rotas que um speaker rejeitador de Inválidas excluiria. [1]
As adições apareceram em duas ondas amplas. A APNIC registrou cerca de 3.365 rotas entre aproximadamente 16:45 e 16:50 UTC, depois cerca de 1.141 entre aproximadamente 17:50 e 17:55. Retiradas amplas também ocorreram em dois estágios, por volta de 21:30 a 21:45 e 22:30 a 22:40. Estes são horários de recebimento em um observador, não timestamps de uma mudança interna da Cox. [1]
Das 4.651 rotas adicionais, 4.644 seriam RPKI Inválidas para um speaker validador. Sete não eram cobertas por uma ROA válida. Esse resultado demonstra uma grande diferença de contenção entre um ponto de observação não validador e uma rede que rejeita rotas Inválidas, sem provar o que cada rede aceitou ou exportou. [1]
Uma ROA fornece autorização para que um prefixo seja originado por um AS, e a Validação de Origem de Rota (ROV) avalia o par prefixo-origem observado em relação aos dados de autorização validados. A ROV não autentica todos os AS no caminho, prova a relação comercial por trás de um anúncio ou estabelece que uma rota era operacionalmente pretendida. [8][10][11]
O prejuízo confirmado é para a integridade do roteamento. Origens errôneas entraram na informação BGP retida pelo observador e permaneceram disponíveis para redes que não rejeitaram rotas Inválidas. O registro fornecido não estabelece uma interrupção visível ao usuário, desvio de pacotes, interceptação, perda de clientes, ação regulatória ou dano monetário. [1][8]
A contenção por redes downstream não desculpa a origem. A Cox controlou a criação de rotas, redistribuição, política de saída, revisão de implantação, monitoramento, retirada e divulgação. Os detentores de recursos controlaram a precisão das ROAs, enquanto peers e provedores de trânsito controlaram separadamente os filtros de importação, ROV e decisões de propagação.
O número então atual da APNIC de que as ROAs cobriam cerca de 95,06% do conjunto de prefixos IPv4 anunciados pela Cox é um contexto de adoção útil, não uma prova da configuração exata em 1º de maio e não uma explicação da validade de cada rota vazada. As visualizações atuais do APNIC Labs, RIPEstat e Cloudflare Radar não devem ser lidas retrospectivamente como instantâneos históricos. [1]-[3][5][6]
Verificações de origem no lado da exportação, Funções BGP, o mecanismo Only-to-Customer, filtros explícitos de prefixo e caminho AS, e defesas orientadas a caminho como Peerlock representam diferentes classes de controle. Seus padrões e registros de pesquisa mostram o que os operadores podem implantar, mas não estabelecem quais controles a Cox ou qualquer vizinho havia habilitado durante este evento. [12]-[17]
A evidência pública pode apoiar uma conclusão de contenção apenas se seus limites permanecerem visíveis. Um único observador não validador mostra recebimento naquele local. Não mostra aceitação vizinho por vizinho, seleção de rota, exportação adiante, fluxo de tráfego, alcance global ou o momento exato e a causa de uma correção interna.
Um registro de responsabilidade crível adicionaria um inventário de prefixos pretendidos, testes semânticos de política de exportação, alarmes de origem anormal, evidências de implantação em estágios, dados de rejeição de vizinhos, instantâneos históricos de ROA, tempo exato de retirada e uma explicação pós-evento do gatilho, propriedade e reparo. Até que essas evidências existam, vazamento acidental e contenção material da ROV permanecem conclusões prováveis, enquanto a causa raiz, impacto ao usuário e remediação permanecem desconhecidos.

O contraste é a evidência

O fato mais importante neste evento não é simplesmente que milhares de rotas apareceram com uma origem inesperada. Vazamentos de rota são frequentemente descritos pelas rotas que propagaram, pelos serviços que falharam ou pelas organizações que depois explicaram um erro de configuração. O registro fornecido para 1º de maio de 2025 é diferente. Ele fornece um contraste observacional controlado entre um ponto de observação BGP que reteve intencionalmente rotas Inválidas e o conjunto de rotas que permaneceria utilizável sob uma política que as rejeita.

Geoff Huston, da APNIC, relatou 4.651 rotas IPv4 adicionais com AS22773 como origem observada. Em seguida, avaliou esses pares prefixo-origem contra dados de autorização RPKI. Do conjunto total, 4.644 teriam sido classificadas como Inválidas por um speaker consciente de RPKI. Sete não tinham cobertura ROA válida. [1] Esses números não mostram que toda rede validadora se comportou de forma idêntica, mas identificam um limite técnico claro: quase todo o conjunto observado era suscetível à rejeição por validação de origem porque o registro de autorização não permitia que AS22773 o originasse.

Isso é evidência de controle positiva. Os dados de autorização existiam independentemente do evento. As redes podiam obtê-los e validá-los independentemente. Cada rede podia então aplicar sua própria política de roteamento ao estado de validade resultante. Uma rede rejeitando rotas Inválidas não precisou que a Cox identificasse o erro, publicasse um postmortem ou pedisse que cada rota fosse filtrada. A incompatibilidade entre a origem observada e a autorização publicada era testável por máquina.

A mesma evidência também define o que não pode ser reivindicado. O observador da APNIC foi deliberadamente configurado para não descartar as rotas apenas por serem Inválidas. Sua visão, portanto, não pode ser apresentada como a visão de uma rede validadora típica. Inversamente, a classificação não prova que toda rede que afirma realizar ROV tinha dados atualizados, aplicou rejeição a todas as sessões ou impediu que cada rota fosse selecionada ou exportada. O resultado é um forte contrafactual de política, não um censo global.

A distinção importa para a responsabilidade. Se o evento é descrito apenas como um vazamento que foi "parado pelo RPKI," a frase esconde os atores e decisões que produziram o resultado. Os detentores de recursos tiveram que publicar autorizações precisas. Repositórios e validadores RPKI tiveram que disponibilizar dados utilizáveis. Operadores tiveram que optar por validar e rejeitar. Monitores tiveram que preservar uma visão não validadora para que a diferença pudesse ser observada. Enquanto isso, a rede originadora ainda tinha que controlar o que originava e exportava.

A contenção emergiu de camadas independentes, não de um escudo automático.

Esse resultado em camadas é o nexo direto de infraestrutura de rede do artigo. Remova a origem BGP, os dados ROA e a política de rejeição local, e tanto o evento quanto a comparação de evidências desaparecem. A questão da responsabilidade não está anexada ao roteamento como uma analogia. Ela decorre de quem controlou os anúncios, quem controlou os objetos de autorização, quem controlou a aceitação e quem reteve evidências suficientes para testar a alegação de contenção.

Um evento em dois estágios visto de um ponto de vista

A linha do tempo começa com o observador, não com uma suposta mudança interna. A APNIC relatou uma primeira grande adição de cerca de 3.365 rotas entre aproximadamente 16:45 e 16:50 UTC. Uma segunda adição de cerca de 1.141 rotas seguiu entre aproximadamente 17:50 e 17:55. Retiradas amplas apareceram mais tarde em dois estágios, com as maiores mudanças por volta de 21:30 a 21:45 e 22:30 a 22:40. [1]

Esses números devem permanecer em seus contextos relatados. Os dois intervalos de contagem são observações amplas de mudança, enquanto 4.651 é a contagem da análise para o conjunto adicional de rotas ao longo do evento. Eles não devem ser forçados a uma nova decomposição aritmética ou usados para inferir um terceiro estágio não documentado. A declaração defensável é que o observador viu duas ondas dominantes de adições, um conjunto total de 4.651 origens adicionais e duas ondas dominantes de retiradas.

O tempo de recebimento também não é tempo de ação. Um coletor BGP registra atualizações após elas terem passado por relacionamentos de roteamento e decisões de política até alcançá-lo. A primeira atualização visível às 16:45 UTC não é prova de que um operador, sistema de automação ou roteador da Cox mudou de estado exatamente às 16:45. A última retirada visível por volta de 22:40 não é prova de que o reparo interno terminou naquele momento. A linha do tempo pública mede quando um observador recebeu informações de roteamento.

Essa cautela não enfraquece a linha do tempo. A forma é operacionalmente importante. Milhares de origens chegaram em um curto intervalo, outro grande conjunto chegou cerca de uma hora depois, e a remoção ampla ocorreu várias horas após as primeiras observações. A sequência é consistente com exportação não intencional e correção subsequente, razão pela qual a análise fornecida trata um vazamento acidental como provável. Não é evidência de intenção maliciosa e não identifica a mudança que produziu os anúncios.

As duas ondas convidam a perguntas de controle sem respondê-las. Dois caminhos de política ativaram-se separadamente? Uma configuração afetou diferentes grupos de rotas em momentos diferentes? O monitoramento detectou a primeira onda antes da segunda? As retiradas foram escalonadas por necessidade técnica, por dispositivos separados ou por grupos de política separados? Nada no registro fornecido escolhe entre essas possibilidades. Um relato responsável pode identificar as perguntas porque os timestamps as tornam mensuráveis, mas não pode convertê-las em conclusões.

As retiradas também mostram correção na visão de roteamento, não remediação durável. Remover um anúncio errôneo é necessário. Não estabelece por que o anúncio foi criado, se a configuração responsável foi revertida, se uma proteção foi adicionada, se um caminho similar permaneceu em outro lugar ou se um reparo testado evitou recorrência. Um registro pós-evento precisaria conectar as retiradas observadas a evidências de mudança interna.

É aqui que a observação independente apoia a responsabilidade. O operador controla seus logs internos e registros de mudança. Monitores externos controlam evidências separadas do que os alcançou e quando desapareceu. Quando esses registros são comparados, eles podem testar declarações sobre detecção, resposta e propagação. Sem o registro externo, o público teria apenas a linha do tempo que a origem escolhesse divulgar. Sem registros internos, o observador pode descrever a visibilidade da rota, mas não a causa raiz.

O que as 4.644 classificações Inválidas significam

O BGP fornece informações de alcançabilidade entre sistemas autônomos. A linha de base do protocolo descreve como os speakers trocam informações de roteamento e usam atributos, incluindo um caminho AS, para tomar decisões de roteamento. Ela não prova, por si só, que a origem no final de um caminho recebido foi autorizada pelo detentor do espaço de endereço. [9]

O RPKI adiciona uma camada de autorização separada. Uma Autorização de Origem de Rota (ROA) declara que um AS está autorizado a originar um prefixo coberto. As especificações de validação de origem descrevem como um speaker BGP pode comparar um prefixo e AS de origem observados com dados de autorização validados e atribuir um resultado de validade. [10][11] Neste evento, essa comparação foi decisiva: o observador viu AS22773 como origem, enquanto o estado de autorização tornou 4.644 das 4.651 rotas adicionais Inválidas para um speaker validador. [1]

Inválido é um resultado preciso, mas não é um veredito completo sobre a rota. Ele diz que o par prefixo-origem observado conflita com o estado de autorização validado. Não prova por que o conflito ocorreu. Uma exportação ruim, um caminho de redistribuição não intencional, política local desatualizada ou algum outro evento operacional pode produzir a incompatibilidade. O registro público aqui não identifica qual deles ocorreu.

Inválido também não autentica o caminho AS completo. Uma rota pode ter uma origem autorizada enquanto ainda é propagada de forma que viola relações de negócios pretendidas. Também pode ter uma origem não autorizada mesmo que o caminho visível contenha números AS reais. A ROV responde à questão da autorização de origem. Ela não prova que toda relação de trânsito, segmento de caminho ou decisão de exportação era legítima.

Esse limite é por que as sete rotas descobertas importam. Elas não compartilhavam a mesma base ROA válida para uma classificação Inválida. A ausência dessa cobertura de autorização não as torna demonstravelmente legítimas, e não prova que redes as aceitaram ou usaram. Significa que este mecanismo de contenção específico não poderia rejeitá-las na mesma base Inválida. Diferentes filtros, política de rota ou decisões do operador teriam que arcar com o ônus do controle.

O número 4.644 é, portanto, evidência de precisão de autorização fora do próprio sistema de exportação da origem vazadora. Os detentores de recursos publicaram informações que permitiam a uma rede validadora distinguir uma origem AS22773 não autorizada de uma autorizada. O valor dessa informação tornou-se visível precisamente porque o evento de origem estava errado. Uma rota correta e uma rota errada podem parecer semelhantes ao nível da sintaxe BGP comum; o RPKI dá à política uma entrada de autorização externamente verificável.

A APNIC também relatou a cobertura ROA então atual de cerca de 95,06% para o conjunto de prefixos IPv4 anunciados pela Cox. [1][2] Esse número pertence ao registro, mas não deve ser confundido com a classificação de 4.644. A métrica de cobertura da Cox descreve o contexto de autorização para prefixos que a Cox anunciou. O conjunto vazado envolveu AS22773 aparecendo como origem para rotas adicionais cujo estado de autorização em grande parte não permitia essa origem. A contenção dependia dos dados de autorização dos detentores de recursos relevantes e da política de validação de cada rede receptora.

A visão RPKI associada do APNIC Labs pode fornecer contexto de comportamento, enquanto o registro RDAP da ARIN estabelece o contexto de registro para AS22773. [3][4] RIPEstat e Cloudflare Radar oferecem contexto de roteamento adicional para o ASN. [5][6] Nenhuma dessas superfícies atuais deve ser usada como substituto para um instantâneo histórico de 1º de maio. O estado do painel pode mudar à medida que rotas, autorizações e métodos de medição mudam. A conclusão do evento baseia-se na análise histórica e seus dados de atualização observados, não na leitura retrospectiva de um gráfico atual.

Contenção é um contrafactual de política, não uma alegação de alcance global

A frase "RPKI conteve o vazamento" só é defensável quando seus termos são explícitos. O ponto de observação da APNIC reteve rotas Inválidas. Um speaker usando o mesmo estado de autorização validado e uma política que rejeita rotas Inválidas excluiria 4.644 rotas do conjunto utilizável. O contraste observado demonstra o que a política de rejeição poderia conter. Ele não enumera todas as redes que aplicaram essa política.

Essa diferença separa recebimento, classificação, aceitação, seleção e propagação. Um roteador pode receber uma atualização de um vizinho e classificar seu estado de origem. A política local então determina se essa atualização permanece elegível. Uma rota rejeitada ainda pode estar presente em um registro diagnóstico mesmo que não seja selecionada para encaminhamento ou anunciada adiante. A evidência da APNIC diz respeito a rotas retidas por um observador não rejeitador e a classificação que receberiam sob validação. Não é telemetria de pacotes.

Como resultado, a análise não prova que o tráfego foi desviado para AS22773. Não prova que um cliente experimentou perda, latência ou falha de alcançabilidade. Não prova interceptação. Também não prova que nenhum usuário foi afetado. Esses resultados requerem medições de tráfego, declarações de redes afetadas ou evidências de serviço que não estão no registro fornecido.

A mesma disciplina se aplica à propagação. O recebimento por um observador prova que os anúncios cruzaram limites de política suficientes para alcançar esse observador. Não estabelece alcance global. Não identifica todos os vizinhos que aceitaram as rotas, todos os upstreams que as exportaram, todos os servidores de rota que as retransmitiram ou todas as redes que as rejeitaram. Uma reprodução multi-coletor poderia produzir um mapa de propagação mais amplo, mas essa evidência não é fornecida aqui.

A metodologia de monitoramento RPKI do NIST é relevante porque as medições de validação dependem de dados, ponto de vista, tempo e método de classificação. [7] Uma conclusão de validade histórica deve vincular a visão da rota ao estado de autorização usado naquele momento. Uma verificação de validade atual pode ser informativa, mas pode não reproduzir o que os validadores sabiam durante o evento. É por isso que instantâneos históricos de ROA fazem parte da evidência faltante.

O guia de práticas do NIST explica a arquitetura e os riscos de integridade de roteamento que a validação de origem visa abordar. [8] Pode apoiar a conclusão de que origens não autorizadas criam um problema de controle e que a ROV fornece uma defesa prática. Não pode transformar o evento da Cox em uma interrupção ou perda comprovada. Classes gerais de dano não são conclusões de dano específicas do evento.

A conclusão mais forte é mais restrita e mais útil. O vazamento alcançou um observador deliberadamente não validador. Quase todos os pares prefixo-origem adicionais eram incompatíveis com dados de autorização validados. Portanto, um operador rejeitando rotas Inválidas tinha uma base concreta e localmente aplicável para impedir que essas rotas entrassem em seu conjunto de rotas utilizável. A evidência apoia potencial de contenção material e provável contenção real, enquanto o resultado exato rede por rede permanece desconhecido.

O dano confirmado é à integridade do roteamento

A análise de risco muitas vezes enfraquece quando um mecanismo dramático é usado para carregar uma alegação de impacto não suportada. Isso é desnecessário aqui. O evento tem um dano confirmado mesmo sem evidência de uma interrupção: a informação de roteamento foi contaminada por milhares de origens adicionais que o sistema de autorização identificou em grande parte como Inválidas.

A integridade do roteamento é importante porque os operadores dependem dos anúncios recebidos para decidir onde os prefixos são alcançáveis. Uma origem errônea cria exposição em toda rede que a recebe sem uma regra de rejeição eficaz. A exposição não é idêntica ao desvio de tráfego, mas é a pré-condição que pode tornar uma rota errada operacionalmente disponível.

O observador não validador demonstra essa exposição diretamente. Sua política preservou os anúncios, mostrando que a propagação BGP ordinária poderia carregá-los até aquele ponto. Uma rede com visibilidade comparável mas sem rejeição de Inválidos poderia tê-los retido como candidatos. Se os selecionou ou exportou dependeria de suas outras rotas e política. A evidência pública não resolve essas decisões downstream.

Esse limite impede tanto subestimação quanto exagero. Chamar o evento de inofensivo porque grande parte da Internet pode ter aplicado ROV ignoraria a contaminação observada e as sete rotas sem a mesma cobertura de autorização. Chamá-lo de uma grande interrupção inventaria um resultado. A declaração de impacto correta é que as origens adicionais de AS22773 criaram exposição de integridade de roteamento, enquanto ROAs precisas e política ROV local forneceram uma camada de contenção mensurável.

A classificação de impacto deve, portanto, refletir significância de controle em vez de perda de cliente assumida. O evento testou uma salvaguarda de roteamento da Internet contra um grande conjunto de origens errôneas. Também mostrou a exposição residual de redes não validadoras e rotas descobertas. Isso é um evento de infraestrutura significativo, mesmo que as fontes fornecidas não estabeleçam uma vítima nomeada ou consequência financeira.

O sucesso downstream não transfere o dever da origem

O erro de responsabilidade mais importante seria tratar a filtragem downstream bem-sucedida como permissão para uma rede originadora depender de seus vizinhos. A ROV é valiosa porque redes independentes podem se proteger. Essa independência não muda quem controlou a criação e exportação das origens ruins.

A Cox controlou os sistemas e políticas que fizeram AS22773 aparecer como origem. O registro público não revela o mecanismo interno, mas as categorias de controle são claras: criação de rota, redistribuição de rota, política de saída, implantação de mudança, monitoramento, escalação, retirada e divulgação. Cada categoria permanece com o operador mesmo quando outra rede rejeita o resultado.

Um inventário de prefixos pretendidos é a primeira unidade de evidência. Um operador deve ser capaz de declarar quais prefixos cada AS de origem e cada contexto de exportação pode anunciar. Esse inventário deve ser utilizável para geração e teste de política, não meramente documentado após o evento. Uma mudança que faria um AS originar milhares de prefixos adicionais deve ser comparada com o conjunto pretendido antes de atingir uma sessão externa.

Teste semântico é diferente de verificar se uma configuração é analisável sintaticamente. Uma política sintaticamente válida ainda pode exportar as rotas erradas. O teste relevante pergunta o que a política resultante anunciaria após redistribuição de rota, transformações locais e regras específicas de sessão serem aplicadas. Um teste deve falhar quando o resultado efetivo excede o limite de prefixo e origem pretendido.

Implantação em estágios é outro controle do lado da origem. Uma política que muda a elegibilidade de rota em muitas sessões não deve precisar do sistema de roteamento global para revelar seu significado. Lançamento limitado, inspeção de diferença de rota e condições automáticas de parada podem expor uma grande mudança no conjunto de origens antes que ela atinja todas as egressas afetadas. O registro fornecido não estabelece se a Cox usou tais controles.

O monitoramento deve procurar mudança semântica, não apenas saúde do dispositivo. Um roteador pode estar disponível e uma sessão BGP pode permanecer estabelecida enquanto as rotas enviadas através dela estão erradas. Um alarme de origem anormal pode comparar o conjunto originado atual com uma linha de base aprovada. Um limite de mudança máxima pode exigir revisão quando milhares de rotas aparecem. Monitores independentes podem confirmar o que escapou da própria telemetria da rede.

A evidência de resposta então conecta detecção a retirada. A remoção observada em dois estágios fornece timestamps externos. O registro interno da Cox poderia mostrar quando a anomalia foi detectada pela primeira vez, quem era o dono da decisão, quais sessões ou políticas foram alteradas, por que a retirada ocorreu em duas ondas amplas e quais verificações confirmaram a conclusão. Sem esse registro, o público pode ver correção no feed de rota, mas não o caminho de controle por trás dela.

A divulgação é parte da responsabilidade operacional porque a origem possui fatos que estranhos não podem recuperar apenas do BGP. Uma explicação pós-evento não precisa expor configuração sensível. Pode identificar a classe de controle que falhou, a escala da exportação não intencional, a fonte de detecção, a sequência de correção, as salvaguardas adicionadas e a evidência usada para testá-las. Nenhum postmortem da Cox está presente no registro fornecido, então nenhum desses detalhes pode ser reivindicado.

A precisão da ROA pertence aos detentores de recursos

O evento também mostra por que os dados de autorização são um controle operacional, não metadados de registro decorativos. Os 4.644 resultados Inválidos foram possíveis porque os detentores de recursos relevantes haviam fornecido autorização que não permitia AS22773 como origem. Sua ação de controle ocorreu antes do vazamento, e redes downstream puderam consumi-la sem coordenar com a Cox durante o evento.

Isso produz um modelo de responsabilidade distribuída. Um detentor de recursos controla se suas ROAs descrevem com precisão os arranjos de origem autorizados. Um serviço RIR e o sistema de publicação RPKI mais amplo suportam a disponibilidade do material assinado. Partes confiáveis validam os dados. Operadores de rede decidem como o estado de validação afeta a política de roteamento. Nenhuma parte controla toda a cadeia.

A precisão é essencial porque um erro de autorização pode criar um modo de falha diferente. Uma autorização excessivamente restrita, desatualizada ou incorreta pode fazer com que um anúncio legítimo seja classificado como Inválido. Esse resultado inverso está fora do evento deste artigo, mas explica por que a adoção do RPKI deve incluir coordenação e teste de mudança. A evidência positiva aqui vem de dados de autorização que distinguiram as origens errôneas; não é uma afirmação de que toda ROA está sempre correta.

As sete rotas descobertas identificam o residual. Onde nenhuma autorização válida cobre uma rota, uma política de rejeição de Inválidos carece da mesma base para bloquear a origem. Isso não transfere a responsabilidade do operador de origem. Mostra que a cobertura do detentor de recursos e os controles de exportação do lado do operador resolvem partes diferentes do problema.

A evidência histórica é, portanto, parte da governança da ROA. Um painel atual não pode mostrar conclusivamente que autorização existia quando uma atualização foi observada. Detentores de recursos, repositórios e monitores devem preservar instantâneos que permitam a um revisor posterior reproduzir a classificação de validade em relação ao tempo relevante. Neste evento, um instantâneo histórico capaz de testar as contagens de 4.644 e sete fortaleceria o registro.

A política do vizinho é uma superfície de controle separada

Peers e provedores de trânsito controlaram o que aconteceu depois que os anúncios deixaram AS22773. Seus controles incluíam filtros de prefixo, filtros de caminho AS, política ROV, limites de máximo de prefixo, alertas de mudança anormal e regras de exportação adiante. O fato de a origem ser responsável pelas rotas ruins não torna as decisões do vizinho irrelevantes. Um vizinho pode restringir ou amplificar o erro de uma origem.

A ROV é a evidência mais clara do lado do vizinho neste caso. Uma rede rejeitando rotas Inválidas tinha uma razão direta para excluir 4.644 pares prefixo-origem. Essa política protegeu a rede e limitou as rotas disponíveis para propagação adiante. Também reduziu a dependência de uma lista mantida manualmente de todo prefixo que a Cox deveria originar.

No entanto, apenas a ROV não resolve todo vazamento. A taxonomia de vazamento de rota reconhece que anúncios podem escapar de uma relação pretendida mesmo quando a origem em si é autorizada. [12] Em tal caso, um par prefixo-origem pode passar na ROV enquanto o caminho viola uma expectativa de exportação. Este evento produziu um grande conjunto Inválido, então a validação de origem foi excepcionalmente eficaz. Esse sucesso não deve ser generalizado para todo vazamento de rota.

Filtragem explícita de prefixo permanece relevante para as sete rotas descobertas e para defesa em profundidade. As orientações do MANRS colocam tanto a filtragem de prefixo quanto de caminho AS no conjunto de controles do operador. [15] Um provedor que tem uma visão confiável do que um cliente pode anunciar pode rejeitar rotas fora desse limite. Regras de caminho AS também podem detectar relações ou conteúdos de caminho que não deveriam chegar de uma determinada sessão.

Controles de máximo de prefixo são úteis, mas incompletos. Um limite pode detectar uma mudança súbita na contagem de rotas, mas uma contagem sozinha não prova que cada rota é autorizada ou pretendida. Um limite alto pode permitir um grande erro; um limite baixo pode interromper uma mudança legítima. O design mais forte combina proteções baseadas em contagem com política de autorização e consciente de relacionamento.

Evidência de vizinho tornaria a alegação de contenção mensurável. Cada vizinho direto poderia relatar quantas das rotas adicionais recebeu, quantas classificou como Inválidas, quantas rejeitou, se alguma foi selecionada e se alguma foi exportada. Divulgação agregada poderia preservar confidencialidade comercial enquanto mostra o resultado do controle. Nenhum dado vizinho por vizinho está no registro fornecido.

A alocação de responsabilidade é, portanto, assimétrica, mas compartilhada. A Cox manteve responsabilidade primária por prevenir origens errôneas e corrigi-las. Vizinhos mantiveram responsabilidade por proteger seus próprios domínios de roteamento e limitar a propagação. Detentores de recursos mantiveram responsabilidade por autorizações precisas. O sucesso de uma camada é evidência de que controles em camadas funcionam, não uma razão para outra camada desaparecer.

Salvaguardas de exportação e relacionamento abordam classes de falha diferentes

O registro de padrões fornece classes de controle adicionais sem provar implantação. A RFC 8893 aborda a validação de origem RPKI no contexto de exportação e direciona a atenção para a origem efetiva após as transformações locais de roteamento de uma rede. [13] Isso importa porque uma rota pode mudar de significado dentro de um operador antes da exportação. Uma verificação que ocorre em apenas um ponto de entrada pode não avaliar o resultado prefixo-origem que um vizinho externo realmente receberá.

Para AS22773, a questão relevante é se a origem exportada efetiva e o conjunto de prefixos foram comparados com um limite aprovado e autorizado antes que as atualizações deixassem a rede. A evidência pública não pode respondê-la. O padrão mostra que a validação do lado da exportação é uma opção de controle reconhecida; não estabelece as capacidades, configuração ou aplicação do roteador da Cox em 1º de maio.

A RFC 9234 fornece um controle orientado a relacionamento através das Funções BGP e do mecanismo Only-to-Customer. [14] Esses mecanismos ajudam as redes a expressar papéis de sessão e identificar anúncios que não devem ser propagados em certas direções. Eles abordam uma dimensão diferente da autorização de origem: se a propagação de uma rota é consistente com o relacionamento representado pela sessão.

Essa distinção importa porque um operador pode produzir pelo menos duas classes amplas de erro. Pode originar um prefixo que não está autorizado a originar, o que a ROV pode identificar quando a autorização existe. Ou pode propagar uma rota com uma origem autorizada além de seu relacionamento pretendido, o que pode exigir controles de caminho e relacionamento. Um design de roteamento robusto trata essas como verificações complementares.

As orientações de filtragem do MANRS tornam a expectativa operacional explícita ao incluir controles de prefixo e caminho AS em vez de reduzir a segurança de roteamento a um único sinalizador de validade. [15] A estrutura de medição do MANRS Observatory também reconhece vazamentos de rota e as redes que permitem a propagação como fenômenos mensuráveis. [16] Medição não atribui responsabilidade legal, mas pode mostrar se um operador repetidamente origina, aceita ou propaga informações de roteamento anômalas.

A pesquisa Peerlock fornece evidência de que defesas orientadas a caminho podem restringir a propagação de vazamentos de rota. [17] Sua relevância aqui não é que Peerlock foi necessariamente implantado pela Cox ou seus vizinhos. O registro fornecido não diz isso. A pesquisa demonstra que os operadores têm opções de controle além da ROV quando o caminho ou relacionamento, em vez da autorização de origem, carrega o aviso.

Essas classes de controle não devem ser colapsadas. A ROV verifica autorização de origem. Filtros de prefixo comparam anúncios com um conjunto permitido. Filtros de caminho AS inspecionam o conteúdo do caminho. Funções BGP e OTC comunicam expectativas de relacionamento. Política estilo Peerlock restringe caminhos envolvendo redes protegidas. Limites de máximo de prefixo detectam mudanças de escala. Monitoramento compara comportamento observado com linhas de base. Cada um captura um subconjunto diferente de falhas.

Observação é tanto uma função de controle quanto de evidência

A decisão do observador da APNIC de não rejeitar rotas Inválidas pode parecer contrária à política defensiva normal. Em um sistema de medição, serviu a um propósito diferente. Ao reter anúncios que uma rede de produção poderia descartar, o observador preservou evidência do que estava sendo emitido e propagado. [1]

Essa função de evidência é essencial. Se todo ponto de visão público rejeitasse as mesmas rotas antes de registrá-las, a comunidade de roteamento poderia saber que a defesa funcionou localmente, mas perderia visibilidade dos próprios anúncios ruins. Um feed deliberadamente não validador pode expor a origem, prefixos, tempo e padrão de retirada necessários para entender o evento.

Redes de produção e sistemas de medição têm, portanto, objetivos válidos diferentes. Um operador de produção pode rejeitar rotas Inválidas para proteger o tráfego e reduzir a propagação. Um monitor pode retê-las em uma visão analítica isolada para tornar anomalias observáveis. A escolha do monitor não é evidência de que redes de produção devem aceitar as rotas.

Múltiplas superfícies de observação melhoram a confiança. O ARIN RDAP fornece contexto de registro para AS22773. [4] O RIPEstat pode fornecer contexto independente de ASN e roteamento. [5] O Cloudflare Radar oferece outra visão de roteamento. [6] O APNIC Labs oferece cobertura ROA e contexto de comportamento RPKI. [2][3] O NIST descreve uma metodologia para monitoramento RPKI. [7] As contagens e linha do tempo específicas do evento, no entanto, vêm da análise da APNIC, e painéis atuais não podem substituir esse registro histórico.

Um design de monitoramento responsável preserva tanto as atualizações de rota quanto os dados de autorização usados para classificá-las. Ele registra identidade do coletor, política, base de relógio e atualidade dos dados. Distingue rotas recebidas de rotas selecionadas. Também retém informação suficiente para recalcular o resultado quando o software de validade ou dados de fonte mudam.

O mesmo design deve suportar alarmes rápidos. Uma nova origem para milhares de prefixos é um evento observável. Detentores de recursos podem monitorar seu próprio espaço de endereço para origens não autorizadas. Um operador de origem pode monitorar seu conjunto anunciado para crescimento inesperado. Vizinhos podem monitorar atualizações aceitas e rejeitadas. Serviços independentes podem comparar visões e alertar quando a propagação cruza limites esperados.

O registro fornecido não mostra quem primeiro detectou a anomalia AS22773 ou se a observação externa precedeu a detecção interna. Esse fato afetaria materialmente a análise de responsabilidade. Se a Cox detectou o evento a partir de seus próprios controles semânticos, a evidência apoiaria observabilidade interna. Se estranhos o detectaram primeiro, o caso para monitoramento mais forte do lado da origem seria mais direto. O registro atual deixa essa sequência desconhecida.

Responsabilidade segue cinco proprietários de controle

O evento pode ser alocado entre cinco proprietários práticos sem fingir que cada um tinha poder igual.

Cox e AS22773 controlaram origem e exportação.Isso inclui quais rotas entraram em um conjunto originado ou redistribuído, quais políticas as tornaram elegíveis para sessões externas, como as mudanças foram revisadas, como o crescimento anormal foi detectado, como as retiradas foram executadas e o que a empresa divulgou depois. A origem observada faz desta a superfície primária de prevenção e explicação.

Detentores de recursos controlaram a precisão da autorização.Suas ROAs permitiram que redes validadoras identificassem a maioria das origens AS22773 como Inválidas. Eles também controlaram se prefixos descobertos permaneciam fora desta camada. Sua responsabilidade é manter a autorização alinhada com arranjos de roteamento legítimos e preservar evidência de mudança.

Peers e provedores de trânsito controlaram aceitação e propagação.Cada rede escolheu se validava, se rejeitava rotas Inválidas, quais filtros de prefixo e caminho aplicar, quais limites impor e se exportava uma rota recebida adiante. Suas escolhas determinaram o alcance do evento além da origem.

Fornecedores e implementadores de padrões controlaram salvaguardas disponíveis.Comportamento do roteador, linguagem de política, integração de validação, verificações de origem efetiva, Funções BGP e suporte OTC moldam o que os operadores podem aplicar de forma confiável. Disponibilidade não é implantação, e implantação não é configuração correta. O registro público não estabelece nenhum dos dois para a Cox.

Monitores independentes controlaram a observabilidade pública.Seus feeds de rota, instantâneos de autorização e métodos analíticos determinam se alegações de contenção podem ser testadas. Um monitor pode mostrar que uma rota chegou e como classificou naquele ponto de vista. Não pode fornecer o gatilho interno da Cox ou resultado de tráfego.

Esta alocação evita dois erros comuns. O primeiro é simplificação de parte única, em que toda aceitação downstream é tratada como ação da origem. Redes tomam decisões de política independentes, então o controle de propagação é compartilhado. O segundo é diluição de responsabilidade, em que controle compartilhado se torna dever de ninguém. Vizinhos da Cox poderiam conter um erro, mas apenas a Cox controlou se AS22773 o emitiu.

O ônus da evidência deve seguir esses poderes. A Cox poderia divulgar evidência de exportação pretendida e correção. Detentores de recursos e serviços RPKI poderiam preservar histórico de autorização. Vizinhos poderiam divulgar dados agregados de rejeição e propagação. Fornecedores poderiam documentar salvaguardas suportadas e comportamento testado. Monitores poderiam publicar observações reproduzíveis. Nenhum ator precisa de acesso ao sistema interno de todos os outros para provar a parte que controlou.

Divulgação deve tornar o resultado do controle reproduzível

Uma divulgação pós-evento forte começaria com o conjunto de rotas observado e separaria fato de inferência. Ela identificaria quantos prefixos adicionais foram originados, quais contextos de exportação estavam envolvidos, quando o operador detectou pela primeira vez a mudança e quando as ações corretivas começaram. Conciliaria seus timestamps internos com os tempos de recebimento e retirada externos.

A próxima seção identificaria o gatilho sem exagerar a culpa. Uma regra de redistribuição, mudança de automação, entrada de sessão de cliente, ação de manutenção ou configuração humana são todas categorias possíveis. O registro fornecido não estabelece uma. Uma divulgação deve nomear o caminho real e explicar por que a revisão ou proteções existentes não o impediram.

Evidência de controle deve seguir. O operador poderia mostrar que a política reparada produz apenas um conjunto de prefixos aprovado, que as origens efetivas são verificadas antes da exportação, que um grande aumento no conjunto de rotas dispara uma parada e que a implantação em estágios impede que uma mudança equivalente atinja todas as sessões externas. Resultados de teste são mais úteis do que uma declaração geral de que os procedimentos foram melhorados.

Evidência de contenção deve permanecer separada. A Cox poderia solicitar relatórios agregados de vizinhos diretos mostrando rejeição de Inválidos e qualquer aceitação residual. Coletores independentes poderiam reproduzir o evento. Dados históricos de ROA poderiam reproduzir as classificações de 4.644 e sete. Esses registros quantificariam o que os controles externos realizaram sem reescrevê-los como prevenção do lado da origem.

Evidência de impacto também deve permanecer delimitada. Telemetria de tráfego poderia mostrar se pacotes seguiram qualquer rota errônea. Registros de serviço poderiam mostrar se alcançabilidade ou desempenho mudaram. Redes afetadas poderiam relatar incidentes. Na ausência disso, o operador não deve implicar que ROV bem-sucedida significa que nenhum efeito ocorreu, e críticos não devem alegar uma interrupção meramente porque um vazamento foi observado.

Finalmente, a remediação deve ser vinculada a testes de recorrência. Uma retirada de rota termina o evento visível. Não prova que a condição responsável não pode recorrer. Um relato durável identificaria o controle adicionado, o cenário usado para testá-lo, o escopo da implantação e a métrica contínua que revelaria regressão.

Nenhuma divulgação da Cox está incluída no registro fornecido. Essa ausência não prova que a Cox falhou em investigar ou reparar o problema internamente. Significa que a evidência pública não pode avaliar essas ações. A responsabilidade para no limite do que pode ser mostrado.

Mapa de evidência e limites de alegação

O registro de fonte suporta diferentes alegações com diferentes forças. Manter esses papéis separados impede que um documento de padrões ou painel atual seja usado como prova do evento.

Ref.	Papel da evidência	Uso suportado	Limite
[1]	Análise do evento APNIC	Data, origem observada, contagens de rota, linha do tempo de duas ondas, observador não validador e comparação de contenção Inválida	Um ponto de vista analítico não prova aceitação global, resultado de tráfego, gatilho interno da Cox ou remediação
[2]	Painel ROA do APNIC Labs	Contexto de cobertura ROA para AS22773, incluindo o número então atual de 95,06% relatado com a análise	Um painel em mudança não é um instantâneo histórico completo de cada prefixo vazado
[3]	Visão RPKI do APNIC Labs	Contexto sobre comportamento RPKI medido associado a AS22773	Comportamento atual não pode provar política em 1º de maio de 2025
[4]	ARIN RDAP	Contexto de registro ASN para AS22773	Identidade de registro não prova causa ou intenção operacional
[5]	Visão geral AS RIPEstat	Contexto independente de roteamento e ASN	Dados de visão geral atuais não reconstroem propagação do evento
[6]	Visão de roteamento Cloudflare Radar	Contexto de roteamento independente adicional	Um painel presente não é um mapa histórico de aceitação vizinho por vizinho
[7]	Metodologia de monitor RPKI do NIST	Como a medição de validação RPKI depende de dados e metodologia	Metodologia não é prova específica do evento
[8]	Guia de prática de integridade de roteamento do NIST	Arquitetura ROV e classes gerais de dano associadas a origens não autorizadas	Risco geral não prova uma interrupção, desvio ou perda da Cox
[9]	RFC 4271	Linha de base do protocolo BGP	Apenas troca BGP não estabelece autorização de origem
[10]	RFC 6483	Semântica de validação ROA	Validação de autorização não estabelece o caminho completo ou intenção operacional
[11]	RFC 6811	Validação de origem de prefixo BGP	Validação de origem não substitui controles de relacionamento e caminho
[12]	RFC 7908	Taxonomia de vazamento de rota	Taxonomia não identifica o gatilho interno específico em AS22773
[13]	RFC 8893	Validação de origem no lado da exportação e controle de origem efetiva	O padrão não prova que a Cox implantou ou configurou corretamente o mecanismo
[14]	RFC 9234	Funções BGP e salvaguardas Only-to-Customer	Disponibilidade em um padrão não prova implementação nas sessões do evento
[15]	Orientações de filtragem MANRS	Filtragem de prefixo e caminho AS como controles do operador	Orientação não estabelece conformidade histórica pela Cox ou um vizinho
[16]	Framework do MANRS Observatory	Conceitos de medição de vazamento de rota e facilitador de propagação	Um framework de medição não atribui falha legal específica do evento
[17]	Pesquisa Peerlock	Evidência de que defesas orientadas a caminho podem restringir propagação de vazamento	Pesquisa sobre implantação e efeito não mostra que Peerlock foi usado neste evento

Este mapa leva a uma hierarquia clara. A fonte [1] carrega os fatos do evento. As fontes [2] a [7] fornecem medição, identidade e contexto, com limites temporais. As fontes [8] a [17] explicam arquitetura de controle, padrões e defesas disponíveis. Nenhuma destas últimas pode ser substituída por um postmortem da Cox ou uma reconstrução do evento multi-coletor.

Evidência que mudaria a análise

Vários tipos de nova evidência poderiam alterar materialmente a conclusão.

Um postmortem da Cox poderia identificar o gatilho, o caminho de política responsável, a fonte de detecção, a sequência de retirada e o reparo. Poderia fortalecer a conclusão de que o evento foi acidental, ou mostrar que algumas rotas foram intencionalmente geradas em um contexto limitado. Também poderia revelar que uma categoria de controle assumida não estava envolvida.

Uma reprodução multi-coletor poderia quantificar a propagação real. Poderia mostrar que as rotas alcançaram muitas redes não validadoras, ou que a aceitação foi muito mais limitada do que o recebimento de um observador sugere. Registros de vizinhos diretos poderiam identificar onde a rejeição de Inválidos funcionou e onde não funcionou.

Instantâneos históricos de ROA poderiam reproduzir ou revisar as classificações de 4.644 Inválidos e sete descobertos. Como os dados de autorização mudam, um arquivo vinculado ao tempo é mais probatório do que uma consulta atual. Qualquer revisão dessas contagens mudaria o limite de contenção medido.

Telemetria de tráfego, monitoramento de serviço ou declarações de redes afetadas poderiam provar ou refutar dano visível ao usuário. Evidência de que o tráfego seguiu as rotas adicionais moveria a análise além da exposição de integridade de roteamento. Evidência de que as rotas nunca foram selecionadas restringiria o impacto. Nenhum dos resultados está disponível aqui.

Finalmente, evidência de que as rotas foram autorizadas, deliberadamente originadas ou confinadas a um ambiente de teste limitado desafiaria a própria caracterização de vazamento. O padrão atual torna provável uma exportação não intencional, mas probabilidade não é substituto para evidência interna.

Até que um desses registros apareça, a conclusão disciplinada é estável. AS22773 foi observado originando 4.651 rotas IPv4 adicionais. Quase todas tinham uma incompatibilidade de autorização que um speaker rejeitador de Inválidos poderia aplicar. O evento demonstra capacidade material de contenção RPKI e o valor de ROAs precisas, enquanto deixa alcance global, efeito de tráfego, gatilho, intenção e reparo não resolvidos.

Contenção é prova de uma camada, não prova de um sistema

O evento de 1º de maio dá aos operadores de rede uma comparação mensurável rara. O observador não validador reteve milhares de rotas. Os dados RPKI classificaram 4.644 delas de uma forma que permitiu que redes validadoras as rejeitassem localmente. Essa é forte evidência de que a autorização de origem pode transformar um erro de roteamento em uma condição de política contível.

Não é evidência de que o RPKI valida o caminho completo, que todas as redes rejeitaram os anúncios, que as sete rotas descobertas eram inofensivas ou que os controles de origem e exportação podem ser delegados a vizinhos. Tão pouco prova uma interrupção de cliente, interceptação, perda ou violação regulatória.

O resultado de responsabilidade segue o controle. A Cox controlou o que AS22773 originou e exportou. Detentores de recursos controlaram a precisão da autorização. Vizinhos controlaram aceitação e propagação. Fornecedores controlaram salvaguardas utilizáveis. Monitores controlaram evidência independente. Cada camada pode provar sua própria ação, e nenhuma camada pode usar o sucesso de outra para apagar seu dever.

O encerramento mais crível seria, portanto, mensurável: um inventário de prefixos pretendidos, semântica de exportação testada, alarmes de origem anormal, implantação em estágios, dados de rejeição de vizinhos, instantâneos históricos de autorização, tempo de retirada reconciliado e uma explicação pública de causa e reparo. A contenção RPKI já mostrou o que uma camada pode provar. A questão não respondida é se os outros proprietários de controle podem produzir evidência de igual precisão.

Fontes

Acesso verificado: 2026-07-25