Em 20 de maio de 2025, um AS na região da Ásia-Pacífico enviou uma BGP UPDATE contendo um atributo Prefix-SID corrompido (opcional, transitivo, código de atributo 40). O que aconteceu depois não foi um sequestro nem um vazamento (route leak).
Cisco IOS-XR e Nokia SR-OS fizeram o que a RFC 7606 determina: descartaram o atributo malformado e seguiram em frente. O sistema operacional JunOS da Juniper repassou a mensagem intacta. Os roteadores Arista que o receberam responderam reiniciando suas sessões BGP. Os servidores de roteamento em diversos IXP retransmitiram o atributo sem filtrá-lo. Em dez segundos, o sistema de roteamento global registrou mais de 150.000 atualizações, e houve flapping de rotas na Starlink, Disney, Zscaler e ByteDance, entre outras. A Arista alterou o comportamento no EOS 4.28.11 e versões posteriores.
Em nenhum ponto da cadeia foi violada alguma das validações do RPKI. Peça a um operador para classificar o evento e ele vai dar de ombros: não é um sequestro, não é um vazamento, é “alguma coisa relacionada a um atributo”. Isso reflete a pouca atenção que esse tipo de problema tem recebido.
Essa lacuna foi um dos pontos de partida de uma pesquisa que acabamos de publicar no IEEE Communications Surveys & Tutorials, que revisita as questões em aberto levantadas na pesquisa de segurança de roteamento de Huston, Rossi e Armitage de 2011 e questiona o que realmente mudou em quinze anos. Este artigo trata da parte da resposta que nos surpreendeu.
Quatro macrocategorias
Finalmente, chegamos a uma taxonomia de quatro macrocategorias e oito microcategorias. A contribuição não é a introdução de novos conceitos de ataque —a maioria dessas distinções já existe nas RFC e na prática operacional— mas sim uma estrutura única com nomenclatura consistente, de forma que cada classe possa ser mapeada sistematicamente às defesas que a combatem.
Manipulação de rotas: modificação não autorizada das informações de prefixos ou rotas. Sequestro de prefixos (PRH) em suas variantes completo, incompleto, de interceptação e abusivo; manipulação de AS_PATH (ASM), que abrange o envenenamento, a injeção de origem falsificada, o encurtamento de rotas e a extensão de rotas.
Consistência do roteamento: ataques à estabilidade da tabela de roteamento, não a seu conteúdo. Volatilidade do estado (VOL): flapping problemático, inundação induzida por oscilações, injeção de flutuação de rotas (churn) amplificada, convergência atrasada. Desagregação de prefixos (DEG): maliciosa, negligente, exploratória e inundação de fragmentação.
Violação de políticas: vazamentos de roteamento (RLK) nas quatro direções definidas na RFC 7908 e manipulação de políticas (POL) mediante Local Preference, MED, comprimento de AS_PATH e propagação seletiva.
Baseado em sessões: restabelecimento de sessões baseado em atributos (ATR): injeção de atributos transitivos opcionais malformados, exploração de atributos específicos do fornecedor, abuso das políticas de tratamento de erros. É aqui que se enquadra o evento de maio de 2025.
Onde a cobertura realmente está
Colocar as defesas sobre esta estrutura produz uma imagem desequilibrada que é fácil passar despercebida quando um mecanismo de forma isolada é avaliado.
PRH é um caso de sucesso, com algumas ressalvas. IRR e RPKI fornecem validação de origem e a cobertura por ROA continua aumentando. Mas a cobertura não é sinônimo de cumprimento: um estudo longitudinal feito em mais de 28.000 sistemas autônomos (AS) revelou que 36,2% não implementam ROV de forma alguma e apenas 12,3% alcançam proteção total. O maxLength permissivo amplia a superfície de ataque em vez de reduzi-la: daí a RFC 9319. Além disso o sequestro abusivo de espaços não anunciados continua sendo totalmente viável quando os objetos não são mantidos.
ASM é abordada parcialmente em princípio, mas quase nada na prática. O BGPsec existe, está implementado e, basicamente, não é usado: um único sistema autônomo que não o adote no caminho remove as informações de segurança, o que torna sua implementação parcial praticamente inútil.
RLK é onde estão ocorrendo os avanços mais promissores. Os objetos ASPA podem ser publicados nos repositórios dos RIR desde dezembro de 2025 (1314 deles estavam registrados no momento da redação deste texto), e as análises sugerem que a implantação pelos sistemas autônomos estrategicamente posicionados poderia reduzir o número de AS afetados por vazamentos em até 96%. O atributo OTC e a comunidade Down Only, ambos baseados nas funções definidas na RFC 9234, poderiam suprimir mais de 98% dos vazamentos multi-hop se adotados seletivamente em redes Tier-1 e Tier-2 bem conectadas.
VOL, DEG, POL e ATR não possuem nenhuma resposta criptográfica. Nenhuma. Essas vulnerabilidades são abordadas por meio de reforço operacional, monitoramento do plano de controle, limites máximos de prefixos (max-prefix-limit), filtros de comprimento de prefixo, higiene das políticas, tratamento robusto dos erros e filtragem de atributos nos servidores de rotas. Todas essas medidas são locais, reativas e não verificáveis para a parte que sofre as consequências. Não existe equivalente a “verificar o ROA e descartar as rotas inválidas”, não há um estado global que alguém possa consultar. Quando um operador pergunta se está protegido contra uma inundação de fragmentação de um peer, a resposta honesta é: há um limite máximo de prefixos e uma esperança.
Por que as classes não cobertas importam mais do que antes?
Dois fatores alteraram o perfil de risco.
O primeiro é a aritmética do IPv6. O abuso de desagregação no IPv4 é limitado pelos recursos que o atacante realmente tem. No IPv6 não é assim: dentro de um único /29, até 524.288 /48 diferentes podem ser gerados e anunciados. A tabela BGP global do IPv6 contém atualmente cerca de 219.000 entradas. Basta uma única designação, um único roteador, para que a tabela se duplique. A proteção —um limite estático para o número máximo de prefixos— também impede o crescimento legítimo se for definido de forma muito restritiva, e é precisamente por isso que os operadores o configuram com uma ampla margem.
O segundo fator é que o sucesso parcial da validação de origem redistribui a atenção do atacante. À medida que a implementação da validação de origem aumenta, o retorno marginal da apropriação indevida de um prefixo diminui, enquanto o retorno marginal das classes que ninguém valida aumenta. Isso não é uma declaração sobre as intenções de ninguém; é a economia usual de um controle que funciona bem para um aspecto específico.
As quatro questões que permanecem sem resposta após quinze anos
Analisando as questões em aberto de 2011 à luz do exposto acima, há quatro que continuam em vigor:
1. Informações de roteamento versus estado de encaminhamento. Pode uma parte confiante (relying party) validar não apenas que o atributo AS_PATH de uma mensagem UPDATE corresponde à rota percorrida pelo anúncio, mas também que o estado de encaminhamento real da rede está alinhado com ela? Todos os mecanismos de validação de rotas, incluindo ASPA e BGPsec, protegem o plano de controle, mas não informam para onde os pacotes realmente vão. Propostas como FC-BGP e SBAS tentam resolver esse problema, e ambas permanecem experimentais. Este é o problema mais complexo do ponto de vista técnico que ainda precisa ser resolvido nesta área.
2. O problema de uma implantação parcial. Se um quadro abrangente se mostrar inviável, um menos abrangente poderá produzir resultados aceitáveis? As evidências indicam que sim, e também que a eficácia depende das políticas dos operadores: uma pesquisa feita a 100 operadores constatou que a validação parcial de rotas oferece boa proteção quando as políticas priorizam rotas seguras, e uma proteção muito menor quando priorizam rotas curtas. A implantação parcial deveria ser a premissa básica de projeto para novas propostas, não o caso degradado.
3. Aprimorar o que já existe. O custo computacional deixou de ser o principal obstáculo como era em 2011, uma vez que os roteadores modernos conseguem lidar com a criptografia. No entanto, a complexidade operacional é sim. Gerenciar os ROA, os registros IRR, os relacionamentos da ASPA e os certificados é um verdadeiro fardo, desproporcionalmente maior para as redes menores com pessoal limitado. Propostas como as listas de prefixos assinados, que substituem um comprimento máximo permissivo de prefixo pela enumeração explícita dos anúncios previstos, são interessantes precisamente porque pressupõem um pouco mais de manutenção em troca de muito menos ambiguidade.
4. Ferramentas auxiliares. Dado que a segurança ao nível do protocolo é incompleta e continuará sendo, o monitoramento e a avaliação de riscos têm um peso maior do que a sua condição de “complementares” sugere. ARTEMIS, ROSE-T, os sistemas de detecção de mudança de origem e a pontuação de riscos derivada das tabelas de roteamento dos IXP oferecem valor sem exigir alterações no BGP ou coordenação entre sistemas autônomos. Sua eficácia, no entanto, depende inteiramente da qualidade dos registros IRR, dos repositórios RPKI e dos dados de relacionamento entre sistemas autônomos, cuja manutenção não é consistente. A melhoria desses conjuntos de dados é um pré-requisito para todo o resto.
O que os últimos quinze anos nos ensinaram
Há três observações que permeiam tudo isso e que, em nossa opinião, merecem ser debatidas:
Implementável sempre é melhor do que ótimo. Embora o S-BGP, soBGP e psBGP ofereciam garantias mais robustas do que qualquer sistema implementado na atualidade, não prosperaram. O RPKI, IRR e agora ASPA ganharam força porque podem ser adotados gradativamente. No roteamento entre domínios, “bom o suficiente e implementável” é sempre a opção vencedora.
A adoção universal não é uma suposição realista e os desenhos que a exigem não têm um bom histórico.
Os custos são individuais e os benefícios são coletivos, que é o problema clássico da ação coletiva e a razão pela qual mecanismos bem projetados estagnam. É aqui que as alavancas institucionais entram em jogo: NIS2, a proposta da Lei de Redes Digitais, estratégias nacionais; embora sua eficácia dependa da aplicação e do monitoramento do cumprimento das normas, que continuam desiguais entre as diferentes jurisdições.
Um convite à discrepância
O aspecto sobre o qual temos menos certeza é a fronteira entre ataque e acidente. Para quase todos os incidentes nas quatro classes descobertas há uma explicação inocente: uma redistribuição mal configurada, um script que foi executado duas vezes, um bug do provedor. Essa ambiguidade é precisamente o motivo pelo qual essas classes são pouco estudadas: é difícil construir um modelo de ameaças em torno de eventos que você não pode atribuir. Isso também poderia significar que estamos superestimando o risco.
Preferimos que os responsáveis pelas redes nos corrijam sobre este assunto em vez de termos razão em uma revista especializada. Se a sua experiência operacional indicar que o limite máximo de prefixos é adequado, ou que a conformidade com o RFC 7606 já é suficiente, essa é a conversa que esperamos iniciar.
“Survey on Internet Routing Security: Stakeholder Interests, Current and Future Research Directions” está disponível sob a licença CC BY 4.0 em IEEE Communications Surveys & Tutorials — DOI: 10.1109/COMST.2026.3714569. O trabalho é uma colaboração entre a Universidade Sapienza de Roma, a Namex (IXP de Roma) e a Agência Nacional Italiana de Segurança Cibernética (ACN).
