Resumo

  • Em 16 de abril de 2021, análises públicas associaram o AS55410, da Vodafone Idea, à origem anômala de dezenas de milhares de rotas BGP.
  • A Catchpoint informou que, às 13:48:58 GMT, o AS55410 aparecia como origem de mais de 34.000 redes; esse número e sua unidade pertencem à medição publicada pela Catchpoint.
  • A mesma análise descreveu aproximadamente 225.000 mensagens de atualização BGP entre 13:45 e 15:00 GMT no coletor RIPE RIS rrc00, com 64 de 73 peers recebendo ao menos uma rede afetada.
  • A MANRS apresentou uma contagem separada: segundo sua análise, o AS55410 normalmente anunciava 824 rotas e passou a anunciar mais de 31.000 rotas adicionais.
  • A responsabilidade começa nos controles de origem e exportação da rede fonte, mas também alcança autorização de prefixos de clientes, limites máximos, validação de origem, propagação, monitoramento e retirada nos upstreams.
  • Dados de registros, IRR, ROAs e coletores são evidências importantes, porém não configuram políticas de roteadores nem comprovam todos os resultados de encaminhamento.
  • A validação de origem por RPKI pode rejeitar uma origem inválida coberta por um ROA, mas não valida todo o caminho de sistemas autônomos nem protege prefixos sem cobertura.
  • RIPE RIS e RouteViews preservam observações de peers participantes; não autorizam rotas e não demonstram que todas as redes escolheram o mesmo caminho.
  • A evidência pública sustenta a ocorrência e a escala da anomalia, mas não comprova motivo, negligência, ilegalidade, ocultação, responsabilidade jurídica ou intenção maliciosa.
  • A responsabilização operacional deve acompanhar quem podia impedir, rejeitar, limitar, observar, interromper, retirar e corrigir os anúncios em cada fronteira da rede.

Um evento grande, observado por janelas diferentes

O BGP distribui informações de alcançabilidade entre sistemas autônomos. Cada anúncio comunica que determinado prefixo pode ser alcançado por um caminho cujo primeiro elemento relevante para validação de origem é o AS apresentado como originador. O protocolo permite que redes independentes componham a conectividade global sem uma autoridade central escolhendo todas as rotas. Essa flexibilidade, no entanto, transforma erros de política em eventos potencialmente amplos: uma rota aceita por um vizinho pode ser anunciada a outros, que por sua vez podem propagá-la conforme suas próprias regras.

Em 16 de abril de 2021, observadores públicos registraram um conjunto incomum de anúncios associado ao AS55410, da Vodafone Idea. A reconstrução disponível não vem de uma visão onisciente da Internet. Ela resulta de relatórios que analisaram dados de determinados coletores, peers e intervalos. Por isso, cada número precisa permanecer ligado à fonte que o mediu, à unidade utilizada e à janela observada.

A Catchpoint informou que, às 13:48:58 GMT, o AS55410 aparecia como origem de mais de 34.000 redes. “Redes”, nessa afirmação, é a unidade usada pela publicação; não se deve transformar automaticamente o número em uma contagem universal de prefixos únicos vista, aceita ou selecionada por cada operador. A medição revela escala extraordinária no ponto de observação utilizado, não uma fotografia completa de todas as tabelas BGP naquele segundo.

Ao examinar o coletor RIPE RIS rrc00, a Catchpoint descreveu aproximadamente 225.000 mensagens de atualização BGP entre 13:45 e 15:00 GMT. Mensagens de atualização não equivalem a 225.000 prefixos distintos, usuários ou interrupções. Um mesmo prefixo pode gerar vários anúncios e retiradas, e peers diferentes podem entregar observações diferentes ao coletor. O volume, ainda assim, indica intensa mudança no plano de controle durante a janela analisada.

Segundo a Catchpoint, 64 dos 73 peers considerados no rrc00 receberam pelo menos uma das redes afetadas. Esse resultado evidencia propagação ampla entre os observadores daquela análise. Ele não significa que 64 peers tenham escolhido a mesma rota para todos os prefixos, que tenham exportado tudo adiante ou que seus clientes tenham sofrido consequências idênticas. Receber uma atualização, aceitá-la como elegível, selecioná-la como melhor caminho, instalá-la no encaminhamento e redistribuí-la são etapas distintas.

A Catchpoint também informou que a maioria das rotas anômalas foi removida depois de aproximadamente uma hora. Essa afirmação deve permanecer dentro do contexto da publicação: “a maioria” não é sinônimo de todas, e “aproximadamente uma hora” não atribui uma duração única a cada destino nem constitui um censo completo de usuários, serviços, perdas ou experiências de conectividade.

A MANRS apresentou uma análise separada e empregou terminologia própria. Segundo sua publicação, o AS55410 normalmente anunciava 824 rotas e anunciou mais de 31.000 rotas adicionais durante o evento. Essa contagem não deve ser fundida com as mais de 34.000 redes relatadas pela Catchpoint. As fontes podem ter usado conjuntos, momentos, critérios e formas de agregação diferentes. As duas ajudam a dimensionar o evento, mas não são números intercambiáveis.

A MANRS chamou o episódio de “hijack” BGP. Em sua análise, atribuiu a propagação observada a Bharti Airtel AS9498 e observou que outros upstreams identificados não propagaram o mesmo conjunto de rotas. Trata-se de uma conclusão delimitada ao que a MANRS examinou. Ela não revela todas as sessões privadas, não descreve cada filtro de cada provedor e não autoriza uma conclusão sobre todos os upstreams possíveis. Também não demonstra, por si só, por que o AS9498 aceitou ou propagou os anúncios.

O The Register, em cobertura jornalística, resumiu o episódio como envolvendo mais de 30.000 prefixos falsos. Essa formulação é útil para compreender como o incidente foi apresentado ao público, mas não substitui evidência rota por rota. Uma reportagem pode consolidar análises técnicas e comentários de especialistas; ela não equivale a um arquivo integral de atualizações nem comprova cada decisão tomada em redes privadas.

Vazamento, anúncio indevido de origem e sequestro não são a mesma coisa

A linguagem usada para incidentes BGP frequentemente mistura três conceitos: vazamento de rota, anúncio indevido de origem e sequestro. Eles podem produzir observações parecidas, mas descrevem problemas diferentes e carregam implicações distintas.

Um vazamento de rota ocorre, em termos gerais, quando um anúncio é propagado além do escopo permitido pelas relações comerciais ou pela política pretendida. Uma rede pode, por exemplo, exportar a um provedor uma rota aprendida de outro provedor, contrariando o papel econômico esperado. A taxonomia do RFC 7908 organiza várias formas desse comportamento, mas a classificação exata depende de conhecer relações e políticas que nem sempre são públicas.

Um anúncio indevido de origem ocorre quando um AS aparece como origem de prefixos que não deveria originar segundo as autorizações e os controles aplicáveis. A observação de milhares de origens inesperadas aponta para esse tipo de anomalia, mas ainda exige cuidado: a aparência no coletor demonstra o anúncio recebido, não toda a cadeia causal que o gerou.

“Hijack” costuma ser empregado para o anúncio não autorizado de espaço de endereçamento. Em alguns contextos, a palavra sugere ação deliberada; em outros, é usada de forma mais ampla para descrever o resultado técnico, independentemente da intenção. Como a MANRS empregou o termo, é correto registrar essa escolha editorial. Não é correto converter o rótulo em prova de motivação maliciosa.

As evidências públicas usadas nesta análise não estabelecem intenção. Elas não demonstram se o evento resultou de erro de configuração, falha de automação, importação inadequada, redistribuição acidental, controle insuficiente ou outra causa. Tampouco comprovam negligência, ilegalidade, ocultação ou responsabilidade jurídica. Chamar o episódio de vazamento de rotas no título delimita o problema operacional sem transformar uma observação de plano de controle em julgamento sobre propósito.

O que o BGP faz — e o que a observação não revela

O RFC 4271 descreve a troca de informações de alcançabilidade entre peers BGP e o processamento de atributos de caminho. Operadores aplicam políticas locais para decidir quais rotas importar, quais considerar elegíveis, qual caminho selecionar e o que exportar. O protocolo oferece mecanismos; a configuração concreta permanece sob controle de cada rede.

Essa separação é essencial para analisar responsabilidade. Uma atualização vista em um coletor prova que determinado peer a entregou naquele contexto. Não prova que todas as redes da Internet a receberam. Também não demonstra que o peer a preferiu para encaminhar tráfego, que a instalou em cada roteador ou que a exportou a todos os vizinhos.

A seleção de caminho depende de atributos, políticas comerciais, preferência local, comprimento do AS path, disponibilidade de alternativas e outras decisões de implementação. Duas redes que recebem o mesmo anúncio podem agir de maneira diferente. Uma pode rejeitá-lo antes de entrar no processo de seleção; outra pode aceitá-lo, mas preferir uma rota legítima; uma terceira pode escolhê-lo e propagá-lo de forma limitada.

Por isso, não se pode afirmar que todos os prefixos anunciados ficaram inalcançáveis. Alguns destinos podem ter atraído tráfego para um caminho inadequado; outros podem ter permanecido acessíveis por rotas mais específicas, preferências locais ou alternativas. Nem toda organização enfrentou a mesma duração, degradação ou perda. Também não existe, neste conjunto de fontes, uma contagem completa de usuários afetados ou um cálculo exato de prejuízo financeiro.

O evento deve ser entendido primeiro como uma falha de integridade do plano de controle. Um conjunto vasto de informações de origem inesperadas entrou no sistema de roteamento e alcançou múltiplos observadores. Os resultados no plano de dados dependem do que cada rede aceitou, escolheu, instalou e encaminhou. Confundir os dois planos produz alegações mais fortes do que as evidências permitem.

A primeira fronteira de controle: origem e exportação no AS55410

A responsabilidade operacional começa no ponto em que as rotas foram originadas ou exportadas. A rede fonte controla suas configurações, mecanismos de geração de anúncios, filtros de saída, limites, processos de mudança e sistemas de automação. Se um AS pretende anunciar um conjunto relativamente estável de prefixos e passa a anunciar dezenas de milhares de origens adicionais, existem oportunidades locais de impedir, interromper ou ao menos detectar a mudança.

Uma lista explícita de prefixos autorizados para origem é um controle direto. Ela pode ser construída a partir de inventário interno, delegações válidas e aprovações de mudança. O filtro deve ser aplicado onde o anúncio entra no BGP e novamente nas fronteiras de exportação. A duplicação não elimina todos os erros, mas reduz a chance de uma falha em um único componente alcançar vizinhos externos.

Limites máximos também são relevantes. Um aumento de centenas para dezenas de milhares de rotas é uma variação que pode ser detectada por contagem. O limite precisa ser calibrado para não interromper expansões legítimas, mas uma política sem teto deixa um erro de grande magnitude livre para atravessar a sessão. Alertas progressivos, limiares absolutos e comparação com uma linha de base histórica podem complementar a ação automática.

O controle local não se resume a listas. Mudanças em redistribuição, agregação, geração de rotas e políticas de exportação exigem validação antes e depois da aplicação. Uma implantação segura verifica o delta esperado: quantos prefixos serão adicionados, removidos ou alterados; quais origens aparecerão; quais vizinhos receberão os anúncios; e se o resultado corresponde à autorização aprovada.

A atribuição dessa primeira camada não significa que toda a responsabilidade termine na Vodafone Idea. O BGP é uma cadeia de decisões independentes. Um erro de origem pode ser bloqueado pelo primeiro provedor que recebe a rota. Quando esse provedor aceita e exporta adiante, uma nova decisão de controle é tomada em outra fronteira.

A segunda fronteira: autorização de prefixos de clientes no upstream

Um provedor upstream sabe que uma sessão pertence a determinado cliente e pode estabelecer quais prefixos esse cliente está autorizado a anunciar. Essa informação pode vir de contratos, inventários operacionais, dados de registros, objetos de rota em IRRs, ROAs e confirmações diretas. Nenhuma fonte é perfeita isoladamente, mas a combinação permite formar uma política de aceitação restrita.

A pergunta decisiva não é apenas se um registro dizia que certo recurso pertencia a alguém. É se a política executada no roteador comparou o anúncio recebido com uma autorização atual e suficientemente específica. Um registro correto que não alimenta o filtro não impede propagação. Um filtro alimentado por dados obsoletos pode rejeitar uma rota legítima ou aceitar uma indevida.

O limite máximo por sessão é outro controle do upstream. Se um cliente normalmente apresenta uma ordem de grandeza muito menor, um salto para dezenas de milhares merece contenção. O provedor pode encerrar a sessão, recusar o excedente ou colocar os anúncios sob análise, conforme sua arquitetura e tolerância a risco. A política deve considerar redundância e continuidade: um limite rígido mal administrado também pode causar indisponibilidade.

A análise da MANRS atribuiu a propagação observada ao Bharti Airtel AS9498, ao mesmo tempo em que registrou que outros upstreams identificados não propagaram o mesmo conjunto. A assimetria é operacionalmente importante porque sugere que fronteiras diferentes produziram resultados diferentes. No entanto, os dados públicos não informam quais controles privados existiam em cada sessão, se a diferença resultou de filtros, topologia, disponibilidade, política comercial ou outra condição.

A responsabilização correta, portanto, formula perguntas verificáveis: qual lista de prefixos estava autorizada para o cliente? Quando foi atualizada? Existia limite máximo? A validação RPKI estava habilitada para rotas de clientes? Qual ação era aplicada a estados inválidos? O provedor mantinha registros da política efetivamente carregada? Quando o alerta surgiu e quem tinha autoridade para suspender a aceitação ou a propagação?

RPKI e ROAs: evidência de origem, não validação completa do caminho

A infraestrutura RPKI permite que titulares publiquem ROAs, declarações criptograficamente verificáveis que associam prefixos a sistemas autônomos autorizados e a um comprimento máximo. Roteadores ou plataformas auxiliares podem usar esses dados para classificar anúncios como válidos, inválidos ou não encontrados, de acordo com a cobertura e a correspondência de origem.

Se um prefixo estiver coberto por um ROA e aparecer com uma origem não autorizada, a validação de origem poderá classificá-lo como inválido. Uma política que rejeite rotas inválidas pode impedir que esse anúncio seja aceito ou propagado. Isso representa uma barreira relevante contra várias formas de anúncio indevido.

O alcance do controle, porém, é limitado. A validação de origem não confirma todo o AS path. Uma rota pode apresentar uma origem autorizada e ainda percorrer ou ser exportada por uma sequência contrária à política comercial esperada. O mecanismo também não protege prefixos sem cobertura por ROA, classificados como “não encontrados”. Operadores precisam decidir como tratar cada estado e como evitar interrupções causadas por dados incorretos ou expirados.

O RFC 6811 descreve a validação de origem, enquanto o RFC 8893 organiza terminologia e considerações de implantação. Esses documentos mostram como o controle pode funcionar; não provam que a Vodafone Idea, Bharti Airtel ou qualquer outra rede o tenha aplicado de uma forma específica em abril de 2021. A existência de um padrão não equivale à sua implantação, e a implantação não equivale necessariamente a uma política de rejeição.

ROAs também precisam ser mantidos. Uma autorização incorreta, excessivamente ampla ou desatualizada reduz o valor do sistema. Titulares de prefixos têm responsabilidade pela precisão da autorização; operadores que consomem os dados têm responsabilidade pela atualização dos validadores, disponibilidade dos caches, tratamento de falhas e aplicação coerente da política.

IRR, registros e dados de topologia como evidência delimitada

Registros de recursos e objetos de rota podem documentar relações entre prefixos, ASNs e mantenedores. IRRs são usados por muitos provedores para gerar filtros de clientes. Esses dados são valiosos porque transformam autorizações em entradas que podem ser consultadas e processadas. Ainda assim, permanecem registros: não empurram sozinhos uma configuração segura para cada roteador.

Objetos amplos, desatualizados ou sem manutenção podem comprometer filtros. Dados corretos, mas não consumidos, não mudam o comportamento da sessão. Uma operação madura trata o registro como parte de um ciclo: autorização, atualização, geração de política, validação do resultado, implantação e monitoramento do estado efetivo.

CAIDA ASRank, CIDR Report e RIPE Stat oferecem contexto sobre AS55410, recursos anunciados e relações observáveis. Eles podem ajudar a examinar o ecossistema em torno do AS. Respostas atuais dessas ferramentas, contudo, não devem ser descritas como uma reprodução perfeita de abril de 2021. Relações mudam, anúncios mudam, registros são atualizados e metodologias inferem parte da topologia.

A investigação histórica exige dados com data, origem e metodologia. Uma consulta atual pode confirmar que certo recurso está associado ao AS hoje, mas não prova qual política estava carregada no momento do incidente. Da mesma maneira, uma relação inferida publicamente não revela todos os termos comerciais ou todas as sessões privadas.

O papel correto de RIPE RIS e RouteViews

RIPE RIS e RouteViews coletam atualizações e tabelas BGP de peers participantes. Esses sistemas fornecem uma janela indispensável para pesquisa, detecção e reconstrução. Eles permitem comparar quando um anúncio apareceu, quais atributos foram observados, como certas rotas chegaram a determinados coletores e quando retiradas se tornaram visíveis.

O rrc00, usado na análise da Catchpoint, preservou observações úteis sobre o evento. A informação de que 64 de 73 peers receberam pelo menos uma rede afetada mostra a extensão entre aquele conjunto de participantes. Não converte o coletor em autoridade de autorização. O RIPE RIS não decide se uma rota pode existir e não controla a política do peer que envia dados.

O mesmo vale para RouteViews. A plataforma oferece visibilidade histórica e contemporânea a partir de seus participantes. Uma rota ausente de um coletor pode ter sido vista em outro lugar; uma rota presente não foi necessariamente selecionada por todas as redes. A cobertura é parcial por construção.

Coletores também não provam cada resultado de encaminhamento. Para isso, seriam necessários dados adicionais do plano de dados, telemetria de redes, medições de conectividade e contexto operacional. Mesmo com essas informações, diferenças geográficas, temporais e de política poderiam produzir experiências distintas.

A função dos coletores na responsabilização é preservar evidência independente. Eles ajudam a estabelecer que um anúncio existiu, quando apareceu para certos peers, quais caminhos foram expostos e quando as retiradas se tornaram observáveis. Essa evidência pode ser comparada com registros internos para verificar rapidez de detecção, contenção e retirada.

Controles de prevenção

A prevenção deve ser distribuída. Na rede fonte, o objetivo é impedir a criação ou exportação indevida. No upstream, é recusar anúncios de clientes fora da autorização. Em outras redes, é limitar a aceitação de rotas inválidas ou incompatíveis com relações conhecidas.

O RFC 7454 reúne práticas de segurança BGP, incluindo filtragem e precauções operacionais. O RFC 8212 reforça o valor de políticas explícitas de importação e exportação: na ausência de política, o comportamento seguro deve evitar propagação implícita. Essas recomendações ajudam a reduzir configurações permissivas, mas não demonstram o que cada rede citada havia implantado.

BGP Roles e o atributo Only-to-Customer, definidos no RFC 9234, podem expressar papéis de relacionamento e restringir propagação inesperada. O mecanismo procura tornar parte da intenção comercial verificável na troca de rotas. Seu valor depende de suporte, negociação, configuração coerente e tratamento correto pelos participantes. Não há evidência, neste conjunto de fontes, de que esse mecanismo tenha sido usado no evento de 2021.

Filtros de prefixo de clientes devem preferir autorização positiva: aceitar apenas o conjunto previsto, em vez de tentar bloquear listas de rotas indevidas depois que aparecem. O processo precisa incluir comprimentos máximos, agregados, rotas mais específicas autorizadas e expiração de exceções. Exceções permanentes e não documentadas tendem a transformar um filtro restrito em autorização ampla.

ROV oferece uma camada adicional. Rejeitar origens inválidas cobertas por ROAs reduz o risco, mas não substitui filtros de cliente. Uma rota sem ROA pode continuar sendo aceita, e um vazamento com origem válida pode escapar da verificação. Controles sobre origem, relacionamento e volume precisam operar em conjunto.

Testes prévios à mudança também são prevenção. Uma configuração pode ser avaliada contra uma tabela sintética ou cópia controlada, comparando o conjunto de rotas antes e depois. Alterações grandes devem exigir dupla aprovação e um plano de reversão. O objetivo não é burocratizar cada ajuste, mas concentrar supervisão em mudanças capazes de afetar milhares de prefixos.

Detecção: observar desvios antes que se tornem incidentes longos

A detecção interna deve ocorrer em segundos ou poucos minutos, não depender apenas de uma publicação externa. Uma rede sabe quantos prefixos pretende originar e quais vizinhos devem recebê-los. Desvios de contagem, origem, comprimento de prefixo e política de exportação podem gerar alertas imediatos.

Um upstream também conhece o perfil de seus clientes. Aumento abrupto de rotas, mudanças de origem, anúncios de grandes blocos não autorizados e alteração atípica do AS path são sinais de investigação. O alerta precisa estar ligado a uma ação: identificar a sessão, congelar mudanças, preservar dados e convocar quem tem autoridade para filtrar ou suspender.

Monitoramento externo complementa a visão local. Coletores, serviços de alerta de origem e observadores distribuídos mostram o que escapou para além da fronteira. Essa comparação é valiosa porque a configuração pretendida pode divergir daquilo que peers realmente receberam.

A detecção precisa evitar a falsa precisão. Um alerta de “mais de 34.000 redes” em uma fonte e “mais de 31.000 rotas adicionais” em outra não representa necessariamente conflito. Sistemas diferentes observam tempos, peers e objetos diferentes. A resposta deve trabalhar com intervalos, atribuições e conjuntos de evidência, em vez de escolher um número conveniente como verdade universal.

Contenção e retirada

Uma vez identificada a anomalia, a prioridade é interromper novos anúncios e limitar a propagação. A rede fonte pode retirar rotas, restaurar a política anterior ou suspender a sessão que exporta o conjunto indevido. O upstream pode bloquear o cliente, instalar um filtro emergencial, impor limite máximo ou encerrar temporariamente a sessão.

A contenção deve ser precisa quando possível. Derrubar conectividade legítima pode ampliar o impacto. Entretanto, diante de dezenas de milhares de anúncios indevidos, preservar cada rota individual enquanto se investiga pode ser inviável. A organização precisa definir antecipadamente quem pode escolher entre filtragem seletiva e suspensão ampla.

Uma retirada enviada não encerra automaticamente o incidente. Ela precisa atravessar os mesmos caminhos de propagação e ser processada por redes remotas. Algumas rotas podem persistir por diferenças de sessão, convergência, políticas ou rotas alternativas. A Catchpoint relatou que a maioria das rotas anômalas foi removida depois de aproximadamente uma hora; isso não prova retirada simultânea e completa em toda a Internet.

A retirada deve ser verificada em três níveis. Primeiro, a rede fonte confirma que não está mais originando ou exportando o conjunto. Segundo, upstreams confirmam que a sessão deixou de fornecer as rotas e que não as anunciam adiante. Terceiro, observadores externos mostram queda consistente das origens anômalas em múltiplos pontos.

O RFC 7999 descreve uma comunidade BGP bem conhecida para blackholing acionado remotamente. Ela é relevante como contexto geral de controles de roteamento e mitigação, mas nenhuma fonte aqui demonstra que essa comunidade tenha sido usada no incidente. Blackholing também trata descarte de tráfego em circunstâncias específicas; não é substituto geral para corrigir uma origem indevida.

Recuperação não é apenas o desaparecimento das rotas

A recuperação começa quando anúncios corretos estão estáveis e termina quando a causa e as lacunas de controle foram tratadas. Restaurar conectividade sem entender como dezenas de milhares de rotas atravessaram uma fronteira deixa aberta a possibilidade de repetição.

Uma revisão técnica deve reconstruir a sequência de configurações, automações e sessões. Quais mudanças ocorreram antes do primeiro anúncio observado? Qual componente gerou as rotas? Quais filtros estavam pretendidos e quais estavam efetivamente ativos? Houve diferença entre roteadores, regiões ou peers? Quais alarmes dispararam e quem respondeu?

O upstream precisa fazer uma revisão própria. A rota foi aceita porque estava em uma lista autorizada, porque não havia lista, porque um objeto de rota permitia um conjunto excessivo, porque a validação não estava habilitada ou porque a política aplicava preferência em vez de rejeição? Sem esses dados, atribuir toda a causa a um único dispositivo ou operador é especulação.

A correção duradoura deve ser demonstrável. Isso pode incluir redução de autorizações, implantação de limites máximos, validação de origem, políticas explícitas, testes de exportação, segregação de funções e novos alertas. Mas as fontes públicas não provam quais medidas permanentes foram adotadas pela Vodafone Idea, Bharti Airtel ou outros participantes depois do evento. Não se deve apresentar uma remediação presumida como fato.

Uma cadeia prática de responsabilização

Responsabilização operacional não significa distribuir culpa jurídica a partir de um gráfico público. Significa relacionar cada resultado ao controle que uma organização realmente possuía.

A Vodafone Idea, como rede associada à origem dos anúncios, tinha controle prático sobre a geração e a exportação a partir de sua infraestrutura. As perguntas adequadas dizem respeito a listas de origem autorizada, filtros de saída, limites, automação, aprovação de mudanças, monitoramento e rapidez de retirada.

Um upstream que recebe rotas de cliente controla a aceitação naquele limite. Pode verificar autorização de prefixos, consultar IRR e RPKI, aplicar limite máximo, definir política explícita e decidir se exporta o anúncio. Quando aceita e propaga uma rota, exerce seu próprio controle, ainda que o problema tenha começado no cliente.

Outras redes controlam importação e seleção em suas fronteiras. Titulares de recursos controlam a publicação e a manutenção de ROAs e registros. Operadores de coletores controlam a preservação de observações, não a autorização das rotas. Pesquisadores e jornalistas interpretam evidências, mas seus rótulos não substituem dados operacionais.

A atribuição da MANRS ao AS9498 para a propagação observada merece investigação sobre essa fronteira específica. Ela não deve ser expandida para uma afirmação de que todos os upstreams agiram igualmente. Pelo contrário, a observação de que outros upstreams identificados não propagaram o mesmo conjunto reforça a importância de comparar controles concretos.

O teste final é simples de formular, embora difícil de executar: quem podia impedir a origem, quem podia rejeitar a aceitação, quem podia bloquear a propagação, quem podia detectar o desvio, quem podia ordenar a contenção, quem podia confirmar a retirada e quem podia provar uma correção duradoura? A resposta muda em cada etapa e não pode ser reduzida à propriedade de um prefixo registrada em uma base.

A imagem em destaque deste artigo é apenas um diagrama editorial genérico e determinístico de rede. Não é fotografia, instalação da Vodafone Idea ou da Bharti Airtel, mapa nem reconstrução visual do incidente.