Incidentes de BGP hijacking estao aumentando enquanto a adocao de RPKI ainda avanca lentamente onde mais importa
Em meados de 2026, 67,43% das rotas de internet anunciadas tinham Route Origin Authorizations validas, e 70,3% do trafego global estava fluindo por caminhos com RPKI valido. Na superficie, isso representa uma vitoria real de infraestrutura: o Resource Public Key Infrastructure, o sistema criptografico projetado para impedir que redes reivindiquem falsamente a propriedade de blocos de endereco IP, passou de uma boa pratica de nicho para adocao majoritaria em menos de uma decada. E ainda assim, o Qrator Labs contabilizou sete vazamentos de rota e pelo menos um BGP hijack significativo apenas no primeiro trimestre de 2026, e operadores de rede relatam mais de 6.000 prefixos invalidos de RPKI sendo anunciados a cada dia. A adocao aumentou. Os incidentes nao desapareceram. Esses dois fatos nao sao, na verdade, uma contradicao — e entender o porque e fundamental para qualquer pessoa que opera infraestrutura dependente de um roteamento de internet confiavel.
O que o RPKI realmente resolve — e o que nao resolve
O Border Gateway Protocol, o sistema que permite que redes anunciem "eu sou o dono deste bloco de IPs, roteie o trafego por mim", foi construido numa era que pressupunha boa-fe entre os operadores. Ele nao tem autenticacao nativa: qualquer rede pode anunciar a propriedade de qualquer bloco de enderecos, e as redes vizinhas geralmente aceitam o anuncio, a menos que algo chame a atencao. O RPKI resolve a versao mais basica desse problema — uma rede assina criptograficamente uma Route Origin Authorization (ROA) comprovando que esta autorizada a anunciar um prefixo especifico, e outras redes podem validar essa assinatura antes de aceitar a rota.
O que a validacao basica de ROA do RPKI nao resolve e a falsificacao de caminho combinada com anuncios mais especificos. Esse e o mecanismo por tras da maioria dos incidentes que continuam acontecendo em redes ostensivamente bem protegidas em 2026: um atacante forja o numero de AS de origem para corresponder a uma ROA legitima e, em seguida, anuncia um sub-prefixo mais especifico do que o legitimo. O algoritmo de selecao de caminhos do BGP prefere rotas mais especificas de forma quase incondicional — trata-se de um principio de design central com decadas de existencia, nao de um bug — portanto, o anuncio forjado e ilegitimo vence a decisao de roteamento mesmo em redes que realizam a Route Origin Validation (ROV) conforme o manual. A ROA e valida. O prefixo e simplesmente errado de uma forma que o ROV sozinho nao detecta.
Por que a correcao para isso esta travada
A resposta tecnica para o hijacking de sub-prefixo com origem forjada existe: o Autonomous System Provider Authorization (ASPA), um objeto RPKI mais recente que permite que uma rede declare criptograficamente seus provedores upstream legitimos, eliminando uma categoria de ataques de falsificacao de caminho que a validacao somente por ROA nao consegue resolver. O problema e a implantacao: em meados de 2026, os objetos ASPA cobriam apenas cerca de 2,54% dos sistemas autonomos globalmente. Ele exige que cada rede em um caminho participe para que a protecao seja efetiva, o que o torna um problema classico de coordenacao — qualquer rede individual obtem beneficio limitado ao implantar o ASPA ate que vizinhos suficientes tambem o facam, e a adocao avanca a passos lentos mesmo com a tecnologia ja madura e padronizada.
Ha tambem uma razao mais simples e menos tecnica para a persistencia dos incidentes: os anuncios invalidos de RPKI na escala de 6.000 ou mais prefixos por dia nao sao, em sua maioria, obra de atacantes maliciosos testando tecnicas sofisticadas de origem forjada — sao erros de configuracao, typos e ROAs desatualizadas de operadores que implementaram o RPKI uma vez e nunca revisitaram as configuracoes a medida que suas redes foram mudando. Esses erros rotineiros criam exatamente o tipo de ruido de fundo que dificulta a identificacao do numero menor de hijacks genuinamente maliciosos misturados entre eles.
O que isso significa para quem opera infraestrutura em producao
Se a sua organizacao faz peering diretamente com provedores upstream ou opera seu proprio AS, a Route Origin Validation e o minimo exigido neste momento — implanta-la nao e mais uma tarefa dificil de justificar, e a maioria dos grandes provedores de transit ja oferece suporte nativo. Mas trate o ROV como piso, nao como teto. Monitore seus proprios prefixos em busca de anuncios mais especificos nao autorizados usando um servico de monitoramento de rotas (varios oferecem tiers gratuitos especificamente para isso), ja que um BGP hijack de sub-prefixo com origem forjada contra o seu espaco de enderecos vai passar na validacao do ROV sem disparar alertas — os mesmos alertas que a maioria das equipes supoe que ja estao cobrindo esse cenario. E se voce estiver avaliando um provedor de transit ou cloud tambem pela resiliencia de rede, pergunte especificamente se eles ja implantaram o ASPA — com menos de 3% de cobertura global, um "sim" ainda e um diferencial genuino, nao apenas mais um item de checklist que todos podem alegar ter cumprido.