Resumo

  • Em 8 de abril de 2010, segundo a BGPMon, o AS23724, identificado em registros públicos como uma rede de data center da China Telecom, anunciou cerca de 37.000 prefixos únicos por aproximadamente quinze minutos, embora normalmente originasse algo em torno de 40 prefixos.
  • A evidência pública sustenta um evento anômalo no plano de controle, com propagação parcial para fora da rede chinesa, mas não prova intenção maliciosa, inspeção de pacotes, armazenamento de dados, interceptação ou qualquer percentual fixo de tráfego global desviado.

O episódio de 8 de abril de 2010 envolvendo AS23724 e AS4134 continua sendo útil não porque permita uma narrativa simples sobre “dez por cento da Internet”, mas porque força uma pergunta operacional mais difícil: quem tinha controle sobre cada fronteira de roteamento, quais políticas deveriam ter limitado a propagação e que tipo de evidência verificável seria necessário para provar que a falha não pode se repetir da mesma forma. O ponto central é infraestrutura de rede, não geopolítica ampla, especulação sobre intenção ou inferência a partir de medo retrospectivo.

A unidade de análise correta é o caminho BGP observado, a autorização de prefixos, a aceitação por vizinhos, a redistribuição por relacionamentos comerciais e a retirada confirmada por pontos de medição independentes.

Na conta original da BGPMon, o AS23724 anunciou um conjunto muito maior de prefixos do que o seu padrão normal. A BGPMon descreveu a rede como uma rede de data center da China Telecom e afirmou que ela normalmente anunciava cerca de 40 prefixos. Durante a janela observada, porém, o conjunto chegou a aproximadamente 37.000 prefixos únicos. A própria BGPMon marcou a primeira observação anômala às 17:54:31 UTC e a última às 18:10:14 UTC. Esses horários devem ser lidos como observações de coletores, não como prova de que todos os roteadores do mundo começaram e terminaram a experiência exatamente nesses segundos.

Em BGP, o que se mede a partir de coletores públicos é uma visão parcial de atualizações, caminhos e retiradas visíveis em determinados pontos da rede global.

O caminho comum observado continha AS4134 seguido de AS23724. Essa sequência importa porque separa duas responsabilidades. O AS23724 aparece como a origem que exportou rotas para prefixos que não lhe pertenciam. O AS4134 aparece como a fronteira visível de importação e de anúncio posterior, isto é, a rede que recebeu as rotas e permitiu que pelo menos parte delas circulasse além do ponto inicial. Dizer isso não exige presumir que AS4134 tenha criado o problema original, nem que todos os seus vizinhos tenham aceitado tudo.

A afirmação defensável é mais específica: na evidência pública disponível, o controle do exportador e o controle do primeiro limite visível de importação não contiveram toda a anomalia antes que ela chegasse a observadores externos.

A contagem de cerca de 37.000 prefixos é um sinal de volume no plano de controle. Ela não é uma medida de tráfego. Essa distinção é o teste de responsabilidade que o caso tornou inevitável. Em uma revisão posterior, a BGPMon explicou que esse conjunto correspondia a algo em torno de onze por cento da tabela de roteamento da época, mas advertiu explicitamente que participação em prefixos não é participação em tráfego. Um prefixo pequeno, pouco usado ou sem fluxo relevante naquele momento não equivale a um prefixo carregando serviços de alto volume.

Da mesma forma, um anúncio BGP aceito por algum vizinho não prova que usuários finais tenham enviado grandes volumes de pacotes por aquele caminho, nem que os pacotes tenham sido lidos, gravados, alterados ou desviados em escala determinada.

A própria BGPMon também limitou a propagação observada. Segundo sua análise, apenas cerca de dez por cento dos prefixos anunciados se propagaram para fora das redes chinesas, e 28 por cento dos coletores RIPE RIS usados na análise detectaram alguma parte do evento. Esses números precisam ficar juntos. O valor de 37.000 descreve o conjunto anunciado pelo AS23724 na visão da BGPMon. O percentual de aproximadamente dez por cento descreve a parte que, naquela observação, saiu do ambiente chinês. O valor de 28 por cento descreve a fração de coletores RIPE RIS que viram algum pedaço do episódio.

Nenhum desses números autoriza a frase de que uma porcentagem fixa de todo o tráfego da Internet foi desviada. Prefixos são unidades de roteamento; tráfego é volume de pacotes no plano de dados.

Relatórios e estudos posteriores encontraram contagens diferentes, às vezes maiores. Essa divergência não precisa ser tratada como contradição simples. Em eventos BGP, a contagem depende dos coletores usados, da janela de tempo analisada, da definição de “prefixo afetado”, da forma de lidar com desagregação e da escolha entre contar anúncios brutos, origens alteradas, caminhos visíveis ou impactos inferidos. Um pesquisador com mais coletores, uma janela mais ampla ou uma regra diferente para prefixos mais específicos pode produzir um número diferente sem necessariamente negar a observação original.

O erro está em retirar uma contagem de seu método e convertê-la em prova universal.

A cronologia mínima, portanto, é estreita. Em 8 de abril de 2010, dentro da janela observada pela BGPMon entre 17:54:31 e 18:10:14 UTC, o AS23724 anunciou aproximadamente 37.000 prefixos únicos. O caminho comum visto incluía AS4134 e AS23724. Parte desse conjunto foi propagada por pares do AS4134 e alcançou observadores fora da China. A BGPMon atribuiu a escala e a duração aproximada a sua própria visão de coleta, depois voltou ao assunto para esclarecer que prefixos não são tráfego e que a intenção continuava desconhecida.

O autor da BGPMon considerou uma configuração acidental mais provável, mas classificou essa leitura como especulação porque não havia falado com os engenheiros da rede.

A palavra “vazamento” é adequada quando usada com precisão. Um route leak ocorre quando rotas aprendidas ou não autorizadas são propagadas de uma forma contrária à política esperada entre sistemas autônomos. A palavra “hijack” aparece em parte da literatura e em relatos sobre o episódio, mas ela carrega ambiguidade: pode indicar origem não autorizada, desvio de caminho ou apropriação de alcance de prefixos, sem por si só provar intenção criminosa. Neste caso, a formulação mais cuidadosa é que houve anúncios de origem anômalos por AS23724 e propagação parcial por caminhos que incluíam AS4134.

A responsabilidade operacional decorre do que os roteadores aceitaram e anunciaram, não da necessidade de adivinhar motivação.

A diferença entre plano de controle e plano de dados é decisiva. O BGP distribui informação de alcance: qual sistema autônomo diz que pode alcançar quais prefixos e por qual caminho. O plano de dados é o encaminhamento efetivo de pacotes. Um coletor BGP pode preservar evidência de que determinado caminho foi anunciado e aceito por certos pontos de observação. Ele não mede automaticamente o volume de pacotes que seguiu aquele caminho. Para estimar encaminhamento real, seria necessário combinar dados de tráfego, medições ativas, logs de roteadores, amostras de fluxo, telemetria de provedores ou observações de usuários.

A evidência pública do caso demonstra anomalia de controle e propagação parcial; ela não demonstra uma leitura de conteúdo, armazenamento, alteração de dados ou uma única rota global para todos os fluxos.

A primeira fronteira de controle estava no AS23724. Se uma rede normalmente origina cerca de 40 prefixos e passa a anunciar aproximadamente 37.000, o salto deveria ser incompatível com uma política de exportação baseada em lista autorizada. Um operador com controle rígido de origem não permite que rotas aprendidas, rotas de clientes errados, uma tabela completa ou prefixos sem autorização sejam exportados como se fossem seus. Uma prática defensável começa com uma fonte de verdade sobre prefixos próprios e prefixos de clientes, gera filtros a partir dessa fonte, aplica limites de volume e rejeita o que não se encaixa.

Essa defesa não depende de acreditar que todo erro será previsto. Ela depende de impedir que uma classe inteira de erro passe por uma sessão externa.

A segunda fronteira estava no AS4134, identificado no caminho observado antes do AS23724. Uma rede que recebe rotas de um vizinho não é apenas fio passivo. Ela escolhe aceitar, rejeitar, preferir, propagar ou limitar. Mesmo quando o contrato comercial permite tráfego e anúncio de rotas, a política de importação deveria perguntar se o vizinho está autorizado a anunciar aquele conjunto. Para um cliente ou participante interno, o filtro esperado é diferente do filtro aplicado a um provedor, a um peer settlement-free ou a uma sessão de trânsito. A relação importa porque o BGP não carrega, sozinho, a intenção comercial.

Sem uma camada de política por relacionamento, uma rota aprendida em uma direção pode escapar para outra, criando exatamente o tipo de propagação que torna vazamentos visíveis fora do ponto original.

A terceira fronteira estava nos peers e redes de trânsito que receberam parte dos anúncios a partir do AS4134 ou por caminhos relacionados. Cada uma dessas redes controlava sua própria aceitação, preferência local, filtros, limites máximos de prefixos e redistribuição. O fato de a BGPMon ter observado apenas cerca de dez por cento do conjunto propagado para fora das redes chinesas sugere contenção parcial em algum conjunto de fronteiras. Essa contenção parcial é importante, mas não absolve o evento. Um sistema resiliente não mede apenas se a catástrofe foi menor do que poderia ter sido.

Ele mede qual camada interrompeu a propagação, quais camadas falharam, quanto tempo levou para retirar os anúncios e se a retirada foi confirmada por observadores independentes.

Prefix holders, ou detentores de prefixos, tinham outro tipo de controle. Eles não controlavam filtros em AS23724, AS4134 ou em redes intermediárias, mas controlavam registros de autorização, ROAs quando disponíveis, dados IRR, contatos de escalonamento e monitoramento externo. Esses registros não impõem roteamento por si mesmos. Um ROA correto não força um roteador remoto a rejeitar uma origem inválida se esse roteador não estiver fazendo validação. Um objeto IRR correto não obriga um operador a gerar filtros atualizados.

Ainda assim, registros precisos reduzem ambiguidade: quando uma origem inesperada aparece, operadores e sistemas automáticos conseguem distinguir com mais rapidez entre anúncio autorizado, erro de registro e vazamento.

A RPKI ajuda, mas não fecha todos os caminhos. A validação de origem baseada em RPKI pode rejeitar anúncios em que a origem não está autorizada para um prefixo coberto por ROA válido. Para um evento em que um AS estranho origina grandes quantidades de prefixos, isso é uma defesa relevante quando a cobertura de ROA existe e quando os vizinhos aplicam política de rejeição para inválidos. Porém, RPKI origin validation não prova que o AS path inteiro seja legítimo. Ela não resolve todos os vazamentos em que a origem permanece válida, nem substitui filtros por relacionamento.

A cadeia de defesa precisa combinar autorização de origem, política de importação, limites de prefixos, classificação de relacionamento e monitoramento de anomalias.

Os RFCs e documentos técnicos posteriores apontam para essa combinação, não para uma bala única. Boas práticas de segurança operacional em BGP recomendam filtros explícitos, configuração conservadora e proteção de sessões. O comportamento padrão de rejeitar rotas externas até que exista política explícita reduz o risco de aceitar anúncios por descuido. A taxonomia de route leaks ajuda a separar vazamentos por tipo de relação e direção. O arcabouço de RPKI define a infraestrutura de certificação de recursos e a validação de origem define como tratar anúncios válidos, inválidos ou não encontrados.

BGP Roles e mecanismos relacionados atacam outro problema: tornar explícita a função da sessão e impedir certos vazamentos por incompatibilidade de papéis. Nenhum desses controles elimina a necessidade de operação disciplinada.

O caso AS23724-AS4134 também mostra por que “retirada” precisa ser verificada, não apenas declarada. Uma recuperação verificável identificaria quando o anúncio anômalo começou, quando cada vizinho relevante o aceitou, quando os alertas chegaram a uma equipe responsável, qual configuração foi alterada, quando withdrawals foram enviados e quando coletores independentes deixaram de observar o conjunto indevido. A retirada em um roteador local não basta se outro caminho ainda propaga a rota.

O encerramento defensável de um incidente BGP exige olhar de fora para dentro: os pontos de observação precisam confirmar que o estado esperado voltou, e medições ativas podem ajudar a separar o fim do anúncio do fim do efeito percebido.

Também é preciso registrar o que não se sabe. A evidência pública não identifica o comando ou alteração de configuração que iniciou o evento. Não prova se houve intenção. Não quantifica o volume de tráfego de dados para cada prefixo afetado. Não mostra se qualquer dado foi inspecionado, armazenado ou modificado. Não revela a cronologia interna de alerta, escalonamento e rollback. Não preserva, ao menos publicamente, a política exata de importação e exportação ativa em cada sessão externa no momento do incidente. Esses vazios não tornam o evento irrelevante.

Eles definem a diferença entre análise de responsabilidade de rede e acusação sem base.

A responsabilidade de rede não depende de saber intenção para avaliar controle. Se uma rede exporta um conjunto de prefixos incompatível com sua autorização, há uma falha de contenção na origem ou na cadeia de configuração que alimentou a origem. Se um vizinho aceita e propaga parte desse conjunto, há uma pergunta sobre import policy, limites e relacionamento. Se outros vizinhos aceitam o caminho, há uma pergunta sobre a própria política deles. Se detentores de prefixos não tinham registros atualizados ou monitoramento externo, há uma pergunta sobre preparação.

Se coletores mostram o evento mas não há relatório operacional público de retirada, há uma pergunta sobre evidência de recuperação. Cada pergunta fica em sua camada.

Essa separação evita dois erros opostos. O primeiro erro é inflar a narrativa: transformar 37.000 prefixos em prova de desvio de uma fração fixa do tráfego mundial, ou transformar visibilidade BGP em prova de interceptação de dados. O segundo erro é minimizar o episódio porque durou cerca de quinze minutos e teve propagação externa parcial. Em roteamento interdomínio, quinze minutos bastam para alterar caminhos, acionar preferências, afetar disponibilidade de serviços e expor fragilidades de controle. A duração curta reduz o escopo de inferência sobre impacto sustentado, mas não elimina o valor do evento como teste de prevenção e resposta.

Uma análise séria começa pelo AS23724. O fato atribuído à BGPMon é que a rede normalmente originava cerca de 40 prefixos e anunciou cerca de 37.000. Mesmo sem logs internos, esse salto é incompatível com uma política que só permite exportar origens autorizadas por uma fonte mantida e auditável. Uma rede com disciplina de exportação deveria ter limites hard e warning para prefixos, revisão para mudanças em massa, geração automática de filtros a partir de registros confiáveis e mecanismos para bloquear a saída de uma tabela aprendida.

Se a causa foi uma configuração acidental, como a BGPMon considerou mais provável em caráter especulativo, esses controles são exatamente os que deveriam reduzir o blast radius de um erro humano.

A análise prossegue pelo AS4134. A fronteira de importação de uma rede nacional de telecomunicações não pode assumir que todo anúncio de um vizinho é aceitável apenas porque a sessão BGP está estabelecida. Políticas defensáveis distinguem cliente, peer, provedor, rota interna, rota agregada e exceção temporária. Elas também impõem maximum-prefix, rejeitam origens não autorizadas quando há dados suficientes, fazem validação de origem quando possível e limitam exportações para rotas coerentes com o relacionamento.

No episódio observado, o caminho AS4134 AS23724 indica que a pergunta de responsabilidade sobre AS4134 não é “quem teve intenção?”, mas “qual política permitiu importar e redistribuir parte do conjunto?”.

Os pares externos e redes de trânsito formam a terceira camada de responsabilidade. A propagação de cerca de dez por cento para fora do ambiente chinês, segundo a BGPMon, mostra que algumas fronteiras permitiram visibilidade externa enquanto outras não. Isso cria uma oportunidade de medição comparativa. Quais redes aceitaram os anúncios? Quais rejeitaram? As que rejeitaram usaram filtros por cliente, limites de prefixos, RPKI, IRR, preferência local menor ou simplesmente não receberam a rota? A resposta determinaria quais controles realmente interromperam o evento.

Sem essa reconstrução, a comunidade aprende menos do que poderia aprender, porque a métrica vira apenas uma contagem agregada de prefixos.

O papel dos coletores é preservar evidência, não substituir engenharia. BGPMon, RIPE RIS e outras infraestruturas de observação ajudam a documentar atualizações, caminhos e retiradas. Elas permitem reconstruir parte do plano de controle e comparar perspectivas. Mas um coletor não vê todos os roteadores, não garante observar cada rota aceita por cada rede e não mede automaticamente pacotes. A cobertura de coletores em 2010 era diferente da cobertura atual, e mesmo hoje uma reconstrução completa exigiria combinar múltiplos feeds. Por isso os percentuais devem ser atribuídos à base de observação que os gerou.

A frase correta é “segundo a BGPMon, em sua observação”, não “a Internet encaminhou”.

A medição de propagação deveria seguir uma lógica de camadas. Primeiro, contar o conjunto anunciado na origem observada. Segundo, identificar quais caminhos continham AS4134 e AS23724. Terceiro, separar coletores que viram qualquer parte do evento dos que não viram. Quarto, distinguir prefixos que permaneceram dentro de um conjunto regional dos que foram vistos fora dele. Quinto, verificar withdrawals e convergência. Sexto, quando disponível, correlacionar com medições ativas ou logs de fluxo para avaliar efeito no plano de dados. O caso de 2010 tem evidência forte nos primeiros passos e limites claros nos últimos.

A conclusão deve respeitar essa assimetria.

RPKI aparece no caso como um limite e como uma direção de melhoria. Em 2010, a implantação de ROAs e validação de origem era muito menos ampla do que em anos posteriores. Mesmo com implantação madura, porém, a defesa só funciona se os prefix holders mantêm ROAs corretos e se os ASes receptores validam e aplicam política. Um anúncio sem ROA fica em estado “not found”, não automaticamente inválido. Um anúncio com origem autorizada mas caminho indevido pode continuar passando na validação de origem.

Portanto, usar o episódio para defender RPKI como parte da pilha faz sentido; usá-lo para afirmar que RPKI sozinha resolveria todo vazamento seria tecnicamente errado.

Filtros por relacionamento preenchem parte dessa lacuna. Se uma sessão é de cliente, as rotas aceitáveis devem corresponder aos prefixos do cliente e aos de seus clientes autorizados. Se uma sessão é de peer, a rede não deveria aceitar nem exportar rotas que transformem o peer em trânsito indevido. Se uma sessão é de provedor, a exportação para terceiros deve seguir políticas diferentes. BGP Roles e mecanismos de leak prevention procuram tornar essa relação mais explícita, reduzindo a dependência de convenções informais. Ainda assim, a relação configurada precisa refletir a relação real, e as exceções precisam ter dono, justificativa e prazo.

Maximum-prefix é outro controle que teria utilidade clara em um salto de dezenas de milhares de prefixos. Um limite bem escolhido pode encerrar ou bloquear uma sessão quando o volume anunciado excede o esperado. Mas maximum-prefix também exige cuidado. Um limite muito baixo derruba tráfego legítimo durante expansão ou mudança de cliente; um limite muito alto vira decoração. A prática madura usa limites de aviso, limites duros, janelas de mudança, inventário de prefixos esperados e resposta operacional ensaiada.

No caso AS23724, a diferença entre cerca de 40 prefixos normais e cerca de 37.000 anunciados é tão grande que um limite de volume deveria ter sido um gatilho óbvio em mais de uma camada.

A autorização de prefixos precisa ser tratada como dado operacional vivo. IRR, RPKI, listas internas, contratos de cliente e inventários de rede devem convergir para a configuração que os roteadores executam. Se a fonte de verdade diz uma coisa e o roteador executa outra, a fonte de verdade é apenas documentação. Se o roteador executa filtros gerados a partir de dados antigos, a automação apenas acelera erro antigo. O padrão defensável exige vínculo entre dado de autorização, configuração gerada, configuração em execução e exceções aprovadas.

Esse vínculo é o que permite uma auditoria responder não só “qual era a política desejada?”, mas “qual política estava ativa quando o evento ocorreu?”.

A retirada independente é a outra metade da autorização. Quando uma anomalia termina, a rede envolvida pode afirmar que corrigiu a configuração. Essa afirmação precisa ser testável. Os coletores deixaram de ver os anúncios? Os peers receberam withdrawals? O caminho alternativo esperado voltou? Prefixos sensíveis ainda aparecem com origem indevida em algum ponto? Medições ativas mostram mudança compatível? Uma recuperação que só aparece em uma tela interna não é suficiente para responsabilidade interdomínio, porque o dano potencial atravessa fronteiras administrativas. A evidência de normalização precisa atravessar essas mesmas fronteiras.

O episódio também deve ser separado de eventos posteriores envolvendo China Telecom ou AS4134. A análise aqui se limita ao evento de 8 de abril de 2010 com AS23724 e AS4134. Misturar outros vazamentos, outros anos ou incidentes não relacionados enfraquece a inferência. Cada evento tem topologia, origem, propagação, duração e evidência próprias. O fato de uma rede aparecer em mais de uma discussão histórica não permite fundir cronologias. Para responsabilidade de roteamento, a precisão temporal e topológica é parte do método.

Do ponto de vista de impacto, a afirmação mínima é que o evento criou risco de encaminhamento incorreto para os prefixos propagados e observados. Para usuários finais, o impacto direto pode variar: alguns caminhos podem ter mudado, alguns serviços podem não ter sido afetados, alguns prefixos podem não ter tido tráfego relevante, e algumas redes podem ter rejeitado os anúncios. Sem medições de dados, não se deve quantificar o volume de tráfego. Sem relatos independentes de serviço, não se deve converter todo prefixo em interrupção.

A responsabilidade, aqui, está no controle que permitiu o risco, na propagação parcial e na necessidade de evidência de correção.

A pergunta de governança técnica é simples de formular e difícil de responder com documentos incompletos: quais políticas estavam em vigor antes do vazamento, quais delas falharam e quais provas demonstram que foram corrigidas? Uma resposta robusta incluiria configuração de exportação do AS23724, política de importação e exportação do AS4134, limites de prefixos, validação de origem, filtros IRR/RPKI, mudanças de configuração, timestamps de alerta, mensagens de retirada, confirmação de coletores e teste de replay.

Sem esses elementos, a análise deve ficar no nível da responsabilidade por camada, não no nível de uma conclusão fechada sobre causa interna.

Esse padrão é mais exigente do que uma nota pós-incidente genérica. Ele não pergunta apenas “o problema acabou?”. Pergunta se a rede consegue demonstrar que uma origem não autorizada não cruza mais a mesma fronteira, que um aumento de volume semelhante aciona bloqueio ou alerta, que exceções são registradas e expiradas, que mudanças são revisadas, que ROAs e registros estão coerentes, que filtros são atualizados e que observadores externos confirmam o resultado.

O teste de responsabilidade é falsificável: se uma replay controlado ou uma auditoria de configuração mostrar que o mesmo conjunto ainda poderia atravessar a fronteira AS23724-AS4134, a remediação não está comprovada.

O caso de 2010 permanece relevante porque BGP é um sistema de confiança operacional distribuída. Não existe um único soberano técnico que valide todos os caminhos em tempo real para todos os ASes. Cada operador mantém suas próprias políticas, escolhe seus registros de apoio, decide o grau de validação e aceita o risco de exceções. Essa arquitetura permite escala e autonomia, mas também transforma erro local em risco global quando vizinhos não contêm a propagação. A resposta não é tratar registros como execução automática, nem tratar execução como invisível. A resposta é alinhar registros, política e observação.

Uma leitura responsável da BGPMon, de trabalhos de medição acadêmica e de orientações técnicas como as do NIST e dos RFCs leva a uma conclusão estreita. O evento provou que um conjunto anômalo de rotas pôde ser originado por AS23724 e parcialmente propagado por caminhos que incluíam AS4134. Provou que contagens de prefixos podem soar enormes e, ao mesmo tempo, serem insuficientes para medir tráfego. Provou que coletores públicos são essenciais para accountability, mas não oniscientes.

Provou que controles isolados são frágeis: RPKI sem filtros por relacionamento deixa lacunas; filtros sem dados corretos envelhecem; limites sem resposta operacional apenas derrubam sessões; monitoramento sem dono vira arquivo histórico.

A análise também sugere uma métrica melhor para casos futuros. Em vez de perguntar apenas “quantos prefixos foram anunciados?”, a investigação deveria registrar: quantos eram autorizados para a origem; quantos tinham ROA válido, inválido ou ausente; quantos foram aceitos pelo primeiro vizinho; quantos foram exportados por relação inadequada; quantos coletores viram a propagação; quanto tempo levou para withdrawals aparecerem; quais redes mantiveram filtros efetivos; quais usuários ou serviços tiveram medições de caminho alteradas; e qual evidência mostra que o estado final voltou ao esperado.

Essa métrica transforma volume em responsabilidade verificável.

Em termos de linguagem pública, a disciplina importa. “Cerca de 37.000 prefixos por aproximadamente quinze minutos, segundo a BGPMon” é uma afirmação ancorada. “Cerca de dez por cento propagados para fora da rede chinesa, segundo a BGPMon” é uma afirmação ancorada. “28 por cento dos coletores RIPE RIS usados na análise viram alguma parte do evento” é uma afirmação ancorada. “Onze por cento da tabela de roteamento da época não significa onze por cento do tráfego” é a qualificação necessária. Qualquer salto para interceptação, inspeção de dados, intenção maliciosa ou percentual global de tráfego excede o pacote factual público.