Em 24 de fevereiro de 2008, a operadora estatal Pakistan Telecom (AS17557) tentou bloquear o YouTube dentro do Paquistão anunciando internamente uma rota falsa para o endereço IP do site. O erro escapou: a operadora de trânsito PCCW Global (AS3491) propagou esse anúncio para o resto do mundo, e por cerca de duas horas e catorze minutos boa parte do tráfego global destinado ao YouTube foi parar em Islamabad, derrubando o serviço para usuários em vários continentes, segundo a reconstrução técnica feita pela RIPE NCC. O incidente se tornou o exemplo didático clássico de um problema estrutural da internet: o protocolo que decide para onde o tráfego mundial deve ir nunca teve, desde sua criação, um mecanismo para verificar se quem está anunciando uma rota realmente tem o direito de fazê-lo.
Dez anos depois, em abril de 2018, o mesmo tipo de falha foi explorado de forma criminosa e lucrativa: a rede eNET (AS10297) sequestrou blocos de IP do serviço de DNS Route 53, da Amazon, redirecionando por cerca de duas horas o tráfego de usuários do site MyEtherWallet para um servidor falso que roubou carteiras de criptomoeda, conforme documentado pela Internet Society. Esses dois casos, separados por uma década, resumem por que engenheiros de rede do mundo inteiro passaram os últimos anos construindo uma infraestrutura criptográfica chamada RPKI para resolver esse buraco de segurança. O problema é que pesquisas técnicas recentes mostram que essa solução, mesmo quando funciona exatamente como projetada, pode não impedir o próprio ataque que foi criada para bloquear — e o motivo revela um dos paradoxos mais incômodos da segurança de infraestrutura crítica: proteção que depende de adoção coletiva só é tão forte quanto o elo mais fraco que ainda não aderiu.
Este texto explica, sem pressupor conhecimento prévio de redes, como o roteamento global funciona, por que ele nasceu sem verificação de confiança, o que o RPKI e a validação de origem de rota (ROV) fazem para consertar isso — e por que um estudo publicado em outubro de 2025 por pesquisadores da Universidade Tsinghua documentou um sequestro de rota real, ocorrido em 2025, que passou pelo crivo do ROV sem ser detectado.
Como a internet decide para onde vai o seu tráfego
A internet não é uma rede única: é uma federação de dezenas de milhares de redes independentes — provedores de internet, empresas de telecomunicações, data centers, universidades, gigantes de tecnologia — cada uma identificada por um número chamado Sistema Autônomo, ou AS (Autonomous System). Cada AS é dono de um ou mais blocos de endereços IP, chamados de prefixos (por exemplo, “203.127.225.0/24” representa um bloco de 256 endereços). Para que um pacote de dados saia de um computador em São Paulo e chegue a um servidor em Tóquio, dezenas de ASes precisam concordar, em tempo real, sobre qual caminho seguir.
Esse acordo é negociado pelo BGP (Border Gateway Protocol), o protocolo que cada AS usa para anunciar aos seus vizinhos: “eu controlo este bloco de endereços IP, e você pode me alcançar através de mim”. Cada rede repassa esses anúncios adiante, como um boato que se espalha, até que a informação chegue a praticamente todos os cantos da internet. O problema é que o BGP foi desenhado nos anos 1980, numa época em que a internet era uma rede pequena e de confiança mútua entre poucas instituições acadêmicas e militares — e ele carrega esse projeto original até hoje: nenhum AS é obrigado a provar que realmente é dono do endereço que está anunciando. É, na prática, um sistema em que qualquer participante pode declarar “este endereço é meu” e os vizinhos, por padrão, acreditam.
Esse “sequestro de rota” (BGP hijacking) pode ser acidental — um erro de configuração, como no caso do Paquistão em 2008 — ou deliberado, como no golpe contra o MyEtherWallet em 2018. Em ambos os casos, o efeito é o mesmo: tráfego que deveria ir para um destino legítimo passa a ser desviado para outro lugar, com potencial para espionagem, roubo de credenciais, interrupção de serviços ou fraude financeira.
RPKI e ROV: a resposta criptográfica ao problema
A solução desenvolvida pela comunidade técnica da internet para esse buraco de confiança é a RPKI (Resource Public Key Infrastructure, ou Infraestrutura de Chave Pública de Recursos). A ideia é simples de entender por analogia: assim como um cartório registra quem é o dono legítimo de um imóvel, a RPKI permite que o dono de um bloco de endereços IP emita um certificado digital assinado criptograficamente — chamado ROA (Route Origin Authorization, ou Autorização de Origem de Rota) — declarando “eu, AS número X, sou autorizado a anunciar este prefixo específico”. Esse certificado fica registrado junto aos Registros Regionais de Internet (como o NIC.br no Brasil, via LACNIC).
A partir daí, entra em cena o ROV (Route Origin Validation, ou Validação de Origem de Rota): quando uma rede recebe um anúncio BGP, ela pode consultar o banco de dados de ROAs e checar se aquele anúncio bate com o certificado registrado. Se um AS não autorizado tentar anunciar um prefixo que não lhe pertence, o anúncio é marcado como “inválido” e, idealmente, descartado pela rede que o recebeu — o equivalente a um cartório invalidando uma escritura falsificada.
A adoção do RPKI vem, de fato, avançando de forma consistente nos últimos anos, embora de forma desigual. Segundo dados compilados por pesquisadores da Kentik e divulgados no NANOG, em maio de 2024 a maioria dos prefixos IPv4 anunciados globalmente passou, pela primeira vez, a ter cobertura de ROAs — ultrapassando os 50%, com o IPv6 batendo 52%, e o tráfego destinado a rotas “válidas” subindo para cerca de 70,3%. O avanço continuou em 2026: segundo o blog da MANRS, entre abril e julho daquele ano a China elevou sua cobertura de ROAs de apenas 4% para 81%, puxando a cobertura da região Ásia-Pacífico administrada pela APNIC de 55% para 77%. Já segundo dados da Hurricane Electric citados pela ipregistry.co, em 29 de junho de 2026 cerca de 67% das rotas globalmente anunciadas já contavam com uma ROA assinada.
O paradoxo: proteção parcial pode ser proteção nenhuma
Esses números soam animadores — e são, de fato, um avanço real. Mas escondem uma limitação estrutural que uma equipe de pesquisadores da Universidade Tsinghua, liderada por Yihao Chen, expôs em detalhe em um artigo publicado no blog da APNIC em outubro de 2025: o ROV só filtra anúncios inválidos nas redes que efetivamente o implementam. Ele não tem nenhum efeito sobre o comportamento das redes vizinhas que ainda não adotaram a validação — e, como o tráfego da internet atravessa em média vários ASes até chegar ao destino, basta que um único elo da cadeia não filtre para que o sequestro continue funcionando, mesmo que todos os outros elos estejam “protegidos”.
Os pesquisadores documentaram um caso real que ilustra exatamente esse mecanismo. Em 2025, o AS17894 anunciou de forma indevida o bloco 203.127.225.0/24 — um “sub-prefixo”, ou seja, uma fatia mais específica dentro de um bloco maior (um /16) que pertence legitimamente ao AS3758. Como o BGP sempre prefere o anúncio mais específico disponível, essa técnica de sub-prefix hijack é particularmente eficaz para desviar tráfego. O AS37100, que tem ROV habilitado, fez exatamente o que deveria: identificou o anúncio como inválido e o descartou. Só que isso não impediu o sequestro. O tráfego destinado àquele bloco continuou sendo desviado porque chegava ao destino errado através de outro caminho, passando pelo AS6762 — uma rede legada, sem validação de ROV, que repassou o anúncio malicioso sem questionar. Do ponto de vista do AS37100, o ataque simplesmente não existia: o sistema de validação funcionou perfeitamente e, mesmo assim, o desvio de tráfego aconteceu de forma invisível, sem deixar rastro no plano de controle (os anúncios de rota que as redes trocam entre si) que os operadores normalmente monitoram para detectar hijacks.
É esse o paradoxo que dá nome a este artigo: o ROV não é uma falha de segurança no sentido tradicional — ele funciona exatamente como projetado em cada rede que o implementa. O problema é de ação coletiva: a proteção de um usuário final depende não apenas de sua própria rede ter ROV, mas de todas as redes ao longo do caminho percorrido pelo tráfego terem ROV também, algo que nenhum operador individual controla nem consegue garantir. Os próprios autores do estudo da Tsinghua estimam que a adoção completa do ROV deve permanecer parcial “pela próxima década”, o que significa que esse tipo de ponto cego deve continuar existindo por bastante tempo — de forma cada vez mais rara, mas não eliminada.
Além da origem: o que o RPKI nunca prometeu resolver
Vale reforçar um ponto técnico que se perde com facilidade no discurso de marketing em torno do RPKI: mesmo quando implementado por todos os elos de uma cadeia, o ROV só valida quem tem autorização para ser a origem de um anúncio de rota — não valida o caminho completo que esse anúncio percorre depois. Uma análise recente da ipregistry.co, com base em dados de junho de 2026, cataloga pelo menos quatro classes de ataque que continuam possíveis mesmo numa internet com boa cobertura de ROAs: manipulação de rota com origem forjada (quando um atacante copia uma ROA legítima e “empilha” seu próprio número de AS no caminho anunciado, passando pela validação), ataques de consistência de roteamento (inundações de anúncios cada vez mais específicos, que dependem de limites de configuração local em vez de validação criptográfica), violação de política através de vazamento de rotas (quando um anúncio legítimo é propagado por um caminho que viola acordos comerciais entre redes, algo que o ROV simplesmente não verifica, pois ele checa apenas a origem) e ataques baseados em sessão, que exploram falhas no próprio mecanismo do protocolo BGP sem nunca mentir sobre a rota em si.
Isso não desqualifica o RPKI — pelo contrário, ele fecha a porta mais óbvia e mais historicamente explorada, a de origem falsa e não autorizada, como nos casos do Paquistão em 2008 e do MyEtherWallet em 2018. Mas confirma que tratar “ter RPKI implementado” como sinônimo de “roteamento seguro” é um erro de simplificação perigoso, porque cria uma falsa sensação de segurança completa numa área em que a proteção real ainda é parcial e fragmentada entre operadores.
O que isso significa na prática
Para quem opera uma rede, o recado é direto: implementar RPKI e ROV continua sendo uma medida de segurança essencial e comprovadamente eficaz — os dados mostram que ela reduziu de forma mensurável a propagação de rotas inválidas globalmente. Mas nenhum operador deveria tratar a adoção do ROV, isoladamente, como uma garantia de imunidade a sequestros de rota, especialmente contra ataques mais sofisticados que exploram justamente as lacunas entre redes que já validam e redes que ainda não validam.
Para o usuário final e para quem depende da infraestrutura de internet no dia a dia — bancos, provedores de serviços críticos, empresas de e-commerce — a lição é sobre expectativa realista: a segurança do roteamento da internet é, e provavelmente continuará sendo por anos, um projeto coletivo inacabado. Cada nova rede que adota RPKI e ROV reduz a superfície de ataque disponível, como mostrou o salto da China entre abril e julho de 2026. Mas até que a adoção se aproxime da universalidade — o que os próprios pesquisadores do estudo original não esperam que aconteça tão cedo —, sequestros de rota “invisíveis”, que escapam da validação por tomarem caminhos alternativos através de redes ainda não protegidas, continuarão sendo tecnicamente possíveis. Entender esse paradoxo é o primeiro passo para que operadores de rede, e não só entusiastas de segurança, tratem a adoção do RPKI como uma corrida coletiva ainda em andamento — não como uma caixa já marcada.
Fontes citadas neste artigo:
- Understanding stealthy BGP hijacking risk in the ROV era — APNIC Blog (16 de outubro de 2025)
- YouTube Hijacking: A RIPE NCC RIS case study — RIPE NCC
- What Happened? The Amazon Route 53 BGP Hijack to Take Over Ethereum Cryptocurrency Wallets — Internet Society
- A Brief Review: The Latest RPKI ROV Deployment Metrics — NANOG
- China Rolls out the ROAs — MANRS Blog (27 de julho de 2026)
- RPKI Covers 67% of Routes, But Four Attack Classes Slip Right Past It — ipregistry.co (27 de julho de 2026)
- Helping build a safer Internet by measuring BGP RPKI Route Origin Validation — Cloudflare Blog