Durante muito tempo, boa parte do roteamento da internet funcionou num modelo desconfortável: uma rede dizia que sabia chegar a determinado bloco de IPs, e as outras precisavam acreditar. Quando isso dava errado — por acidente ou abuso — o tráfego podia ir para o lugar errado e um serviço simplesmente desaparecer da rede.
Um levantamento recente da IPinfo mostra que o RPKI agora valida 70,3% dos prefixos roteados na internet, contra 54% um ano antes. É uma melhora grande, mas a parte mais útil da história não é o número bonito: é entender o que esse mecanismo já bloqueia e onde ele ainda deixa brecha.
O problema que o RPKI tenta resolver
O BGP é o protocolo que faz redes autônomas trocarem anúncios sobre quais endereços conseguem alcançar. É essencial para a internet funcionar, mas historicamente foi bastante permissivo. Se um provedor aceitasse e repassasse um anúncio indevido, ele poderia ganhar escala rapidamente.
O caso clássico aconteceu em 2008: o Pakistan Telecom tentou bloquear o YouTube localmente com uma rota mais específica. O anúncio escapou pelo upstream e desviou tráfego do YouTube no mundo inteiro por cerca de duas horas. Não foi um ataque sofisticado; foi uma combinação de anúncio ruim e confiança demais.
O RPKI adiciona uma checagem de origem. Quem controla um bloco de IP publica uma autorização assinada, chamada ROA, dizendo quais sistemas autônomos podem anunciar aquele prefixo. Redes que validam RPKI conseguem comparar o anúncio com essa autorização e derrubar o que não bate.
Sete em cada dez rotas já passam pela checagem
Segundo a IPinfo, a parcela de prefixos válidos subiu de 54,0% em setembro de 2025 para 70,3% em setembro de 2026. O salto foi bem maior que os anos anteriores. A China teve peso decisivo: a participação de seus endereços IPv4 em rotas válidas foi de 3,7% para 83,0% no período.
Mais importante ainda: as rotas inválidas quase não se propagam. No recorte da pesquisa, uma rota válida típica era vista por 596 pontos de observação e uma rota sem registro RPKI por 595. Já uma rota inválida aparecia, em mediana, em apenas dois. Quase metade delas chegava a um único ponto.
Esse é o tipo de dado que mostra a diferença entre adotar uma especificação e fazê-la valer no tráfego real. Há mais operadores filtrando anúncios que não deveriam existir — e o filtro está mudando o alcance desses erros.
Validar origem não é validar tudo
RPKI não é um selo mágico de rota segura. Ele responde a uma pergunta específica: este sistema autônomo está autorizado a originar este prefixo? Ele não valida o caminho inteiro e pode aceitar um anúncio malicioso se a própria configuração do ROA abrir espaço para ele.
A análise cita um incidente de agosto de 2026 envolvendo um bloco da Hetzner. Um anúncio forjado para um /24 continuou válido porque o ROA do bloco maior permitia prefixos menores. Como não havia uma rota legítima concorrente daquele tamanho, a regra de longest prefix match fez com que a rota forjada fosse preferida. O resultado foi suficiente para viabilizar um certificado TLS real e distribuir uma atualização maliciosa.
Não foi uma falha do RPKI; foi uma autorização ampla demais. A IPinfo estimou que 16,2% das rotas IPv4 cobertas por RPKI ainda tinham esse tipo de janela para anúncios mais específicos.
O checklist que vale para quem opera rede
- Publique ROAs para tudo o que anuncia. Uma rota sem ROA continua funcionando, mas não ganha a proteção de origem.
- Evite
maxLengthquando não for necessário. Autorizar subprefixos por comodidade pode abrir justamente a brecha que você queria fechar. - Monitore ROAs como monitora DNS e certificados. Quando uma autorização some, o serviço não necessariamente cai — e por isso o problema pode passar despercebido.
- Comece a olhar para ASPA. Esse registro ajuda a validar relações de trânsito e a detectar vazamentos de rota que o RPKI de origem não alcança.
O próximo gargalo é operacional
O RPKI já saiu da fase de promessa distante: ele cobre a maior parte dos prefixos e torna anúncios inválidos pouco visíveis. Mas o restante depende menos de uma novidade técnica e mais de trabalho operacional repetitivo: publicar o registro correto, revisar a granularidade, alertar para expiração e conferir mudanças de provedor.
Para quem trabalha com infraestrutura, esse é um lembrete útil. Segurança de rede não costuma falhar porque faltou uma sigla; ela falha quando uma configuração aparentemente inofensiva fica anos sem revisão.
