O hijacking de BGP continua a comprometer a internet — e o RPKI é a solução que a maioria dos ISPs ainda não implementou
Algures em abril de 2010, durante cerca de 18 minutos, aproximadamente 15% do tráfego mundial da internet foi redirecionado através da rede da China Telecom. Isto incluiu tráfego das forças armadas dos EUA, agências governamentais e grandes empresas. A China Telecom não hackeou nada. Limitou-se a anunciar que tinha melhores rotas para esses destinos, e o resto da internet acreditou — porque o Border Gateway Protocol, o sistema que encaminha todo o tráfego da internet, não tem forma de verificar se um anúncio de encaminhamento é legítimo.
Isto aconteceu há 16 anos. O problema subjacente continua por resolver.
O protocolo que funciona por confiança
O BGP data de 1989. Foi concebido numa época em que a internet era uma pequena rede de universidades e agências governamentais que se conheciam entre si. O protocolo opera na premissa de que se uma rede (chamada Sistema Autónomo, ou AS) anuncia que consegue alcançar um determinado bloco de endereços IP, o anúncio é verdadeiro. Não há verificação criptográfica, não há autenticação, não há forma de provar que se tem o direito de anunciar uma rota. Basta anunciá-la, e a internet encaminha o tráfego para si.
Isto é importante porque o BGP é a forma como cada pacote na internet encontra o seu destino. Quando carrega uma página web, o router do seu ISP consulta as tabelas BGP para descobrir o caminho até ao servidor. Se alguém injetar uma rota falsa, o seu tráfego vai para outro lugar — para uma rede que o pode ler, modificar ou simplesmente descartar.
Os hijacks de BGP acontecem regularmente. A Pakistan Telecom tirou o YouTube do ar durante duas horas em 2008 ao anunciar acidentalmente que tinha uma rota melhor. A Rostelecom na Rússia intercetou brevemente tráfego da Amazon, Google, Akamai e outros 200 fornecedores em 2020. Um ISP bielorrusso fez hijack ao espaço IP da Cloudflare em 2021. A maioria dos incidentes são configurações incorretas acidentais, mas atores estatais demonstraram capacidade para o fazer intencionalmente.
O que o RPKI deve corrigir
Resource Public Key Infrastructure — RPKI — é um enquadramento criptográfico que permite aos detentores de endereços IP assinar registos chamados Route Origin Authorizations (ROAs). Um ROA diz, em termos criptográficos: "O AS 64500 está autorizado a anunciar o prefixo 198.51.100.0/24." Se alguém anunciar o mesmo prefixo, as redes com validação RPKI ativada podem ver que o anúncio não corresponde a nenhum ROA válido e rejeitá-lo.
Os cinco Regional Internet Registries — ARIN (América do Norte), RIPE NCC (Europa/Médio Oriente), APNIC (Ásia-Pacífico), LACNIC (América Latina) e AFRINIC (África) — oferecem todos serviços RPKI. Criar ROAs é gratuito. A infraestrutura criptográfica já está construída.
O problema é que o RPKI requer dois passos para realmente parar hijacks. Primeiro, os detentores de endereços precisam de criar ROAs. Segundo, os ISPs e operadores de rede precisam de configurar os seus routers para rejeitar anúncios que falhem a validação (isto chama-se validação de origem, ou RPKI-ROV). Ambas as partes precisam de acontecer para a proteção funcionar.
Onde está realmente a adoção
No início de 2026, aproximadamente 50–55% dos prefixos IPv4 encaminhados globalmente têm ROAs válidos — o que significa que os seus detentores os assinaram com RPKI. Isso subiu de cerca de 20% em 2020, o que representa progresso real. Mas a criação de ROAs é apenas metade da equação.
A validação de origem — a filtragem que realmente rejeita rotas más — está implementada em muito menos redes. O NIST estima que cerca de 30–35% das redes Tier-1 e Tier-2 aplicam atualmente RPKI-ROV. Os grandes operadores americanos (AT&T, Verizon, Lumen/CenturyLink) têm sido lentos. Os operadores europeus, particularmente os ligados ao RIPE NCC, têm taxas de adoção mais elevadas. Algumas grandes CDNs como a Cloudflare e a Fastly aplicam-na. A maioria dos ISPs regionais e redes empresariais não o faz.
O que isto significa: mesmo que o seu ROA diga que é dono de um prefixo, uma parte significativa da infraestrutura da internet continuará a aceitar um anúncio hijacked desse prefixo por outra pessoa. A proteção é parcial, não universal.
Porque é que está a demorar tanto
As razões para a adoção lenta são maioritariamente operacionais e económicas, não técnicas. Configurar RPKI-ROV nos routers de um operador requer alterar a política de encaminhamento em todos os pontos de peering e todos os routers de fronteira. Um ROA mal configurado pode tornar uma rede legítima inacessível — a cura torna-se a causa da interrupção. Os grandes ISPs que transportam centenas de milhares de rotas compreensivelmente têm receio de ativar filtragem que possa descartar tráfego válido inadvertidamente.
Há também uma lacuna de incentivos. Os custos de um hijack de BGP recaem sobre a rede vítima. O trabalho de implementar RPKI-ROV recai sobre todas as outras redes. Para qualquer ISP individual, o cálculo tem sido historicamente: o esforço é meu, o benefício é difuso. Este é um problema clássico de coordenação.
Os reguladores estão a começar a reagir. A Cybersecurity and Infrastructure Security Agency (CISA) dos EUA e a FCC publicaram orientações incentivando a implementação de RPKI entre os operadores americanos, e os princípios "Secure by Design" da CISA referem explicitamente a segurança do BGP. A Diretiva NIS2 da UE, que entrou em vigor em 2024, exige que os operadores de serviços essenciais implementem medidas de segurança BGP — embora a aplicação ainda seja inconsistente entre os estados-membros.
Além do RPKI: o que é necessário para realmente proteger o encaminhamento
O RPKI-ROV apenas valida a origem de uma rota — o primeiro AS que a anuncia. Não valida o caminho completo que um anúncio de rota percorre. Uma solução mais completa chamada BGPsec adiciona assinaturas criptográficas a cada passo do caminho, mas requer que cada AS ao longo do caminho a suporte e tem implicações de desempenho significativas para o hardware dos routers. A implementação é essencialmente zero.
Um meio-termo chamado ASPA (Autonomous System Provider Authorization) foi padronizado pelo IETF em 2024. O ASPA permite que as redes assinem registos que indicam quais os ASes que são os seus fornecedores upstream. Isto torna possível detetar e rejeitar uma classe de route leaks que o RPKI-ROV não deteta — especificamente, casos em que uma rede anuncia acidentalmente as suas rotas de clientes aos seus outros fornecedores. O ASPA está a ganhar interesse mas está numa fase muito inicial de implementação.
A realidade subjacente é que a segurança do encaminhamento da internet é um problema de ação coletiva. Requer que a maioria das redes significativas alterem as suas práticas operacionais simultaneamente para ser totalmente eficaz. O RPKI fez progresso real nos últimos cinco anos — a trajetória é positiva — mas ao ritmo atual, um ator estatal determinado ou um router Tier-1 mal configurado ainda pode redirecionar o tráfego global da internet. A solução técnica existe. A lacuna de implementação é o problema.