Resumo

  • A Cloudflare analisou uma anomalia BGP na Venezuela e apontou o AS8048, CANTV, como o sistema que pareceu vazar rotas aprendidas por AS6762 em direção ao AS52320, com prefixos originados pelo AS21980, Dayco Telecom [1].
  • A Low Orbit Security publicou exemplos de caminhos em que o AS8048 aparecia repetidamente em rotas ligadas ao espaço 200.74.224.0/20. Esses exemplos são evidência de rota, não um censo completo de impacto sobre usuários [2].
  • A APNIC alertou depois que algumas detecções públicas de vazamentos podem ser efêmeras e ligadas à convergência do BGP. Por isso duração, propagação e seleção real de tráfego importam [3].
  • RPKI Route Origin Validation ajuda quando a origem está errada. Neste tipo de evento, a origem pode permanecer correta enquanto a relação do caminho está errada. Os controles relevantes são política explícita, BGP Roles, Only-to-Customer, ASPA e telemetria preservada [1][5][6][7][8].
  • O artigo não afirma que a CANTV causou uma falha nacional. Ele pergunta quais provas CANTV e redes vizinhas deveriam apresentar para demonstrar aceitação, exportação, retirada e reparo durável da rota.

O que aconteceu

O registro público começa em dados do Cloudflare Radar e de coletores BGP. A Low Orbit Security observou que prefixos venezuelanos apareciam com AS8048 em caminhos que exigiam explicação. A Cloudflare detalhou depois que o padrão envolvia rotas aprendidas por AS6762, Sparkle, e redistribuídas em direção ao AS52320, V.tal GlobeNet, com AS21980 como origem de alguns prefixos [1][2].

Para um leitor não especialista, um caminho AS é a lista de redes que um anúncio de rota diz atravessar. Relações normais separam cliente, par e provedor. Um cliente costuma enviar suas próprias rotas e as de seus clientes a um provedor. Uma rede não deveria transformar uma rota aprendida em relação limitada em trânsito amplo para terceiros. Quando essa fronteira é cruzada, surge um vazamento de rota [5].

A fronteira da prova é essencial. A Cloudflare chamou o padrão de vazamento de rota, mas não o tratou como prova de apagão, intenção ou interceptação. A APNIC acrescentou que alguns eventos visíveis em detectores públicos podem ser curtos e desaparecer durante a convergência. Isso não torna a anomalia irrelevante. Significa que a avaliação deve começar por caminho observado, duração e propagação, antes de discutir impacto e intenção.

Por que importa

A CANTV é uma operadora nacional de telecomunicações. Sua política de roteamento pode afetar bancos, órgãos públicos, redes regionais, empresas e usuários finais. Uma regra de exportação ampla demais pode tornar um erro local visível fora do seu escopo previsto. Mesmo que o impacto final tenha sido limitado, a operadora deve explicar qual rota foi aceita, qual foi exportada, quem recebeu o alerta e como a correção foi testada.

A análise mais ampla da FastNetMon lembra que o BGP não compreende nativamente intenção, qualidade nem topologia esperada. Por isso uma rota sintaticamente válida pode se propagar mesmo quando a relação é operacionalmente estranha [4].

"Ninguém provou dano" não é padrão suficiente. Redes críticas precisam mostrar que o estado executado nos roteadores corresponde às relações comerciais e técnicas documentadas. Também precisam separar observação pública, inferência técnica e lacunas de logs privados.

A camada técnica

RPKI ROV verifica se um ASN está autorizado a originar um prefixo [8]. Neste caso, a origem podia estar correta. O problema estava no meio do caminho. A RFC 8212 exige política explícita de importação e exportação. A RFC 9234 descreve BGP Roles e Only-to-Customer. ASPA adiciona evidência de relação provedor-cliente [6][7]. Esses mecanismos não resolvem tudo automaticamente, mas apontam para o plano de controle certo.

Um fechamento técnico confiável deveria incluir prefixos, sessões, mapas de rota, papéis de relação, primeira e última observação, coletores externos, tráfego selecionado, retirada, mudança de política e teste de não recorrência. Sem isso, não se distingue um sinal curto de convergência de uma falha mais séria de política de exportação.

Quem pôde ser afetado

As fontes públicas nomeiam prefixos e caminhos AS, não todos os usuários. Uma rota pode aparecer em um coletor e ainda assim carregar pouco tráfego. Também pode afetar alguns usuários se redes relevantes a selecionarem. A investigação correta deve alinhar rotas, fluxos, perda, latência, relatos de clientes e linha do tempo operacional.

O que observar depois

É preciso acompanhar a recorrência de alertas do AS8048, caminhos semelhantes com AS6762, AS52320 e AS21980, e qualquer divulgação técnica da CANTV ou vizinhos. Sinais úteis incluem filtros de exportação, BGP Roles, OTC, prontidão ASPA, alarmes de contagem de rotas e revisão independente.

O caso fica mais grave se o padrão se repetir, se alertas forem ignorados ou se a CANTV não conseguir reconciliar coletores públicos com logs internos. Fica menos grave com causa estreita, curta duração, tráfego selecionado limitado, retirada limpa, reparo testado e estabilidade externa.

Fontes

  1. https://blog.cloudflare.com/bgp-route-leak-venezuela/
  2. https://loworbitsecurity.com/radar/radar16/
  3. https://blog.apnic.net/2026/05/25/ephemeral-leaks-and-automated-bgp-route-leak-detection/
  4. https://fastnetmon.com/2026/01/09/venezuelas-routing-anomaly-and-the-bigger-problem-with-bgp-security/
  5. https://www.rfc-editor.org/rfc/rfc7908
  6. https://www.rfc-editor.org/rfc/rfc9234
  7. https://www.rfc-editor.org/rfc/rfc8212
  8. https://www.rfc-editor.org/rfc/rfc6811