Com o , as redes da internet dizem umas às outras que endereços alcançam. Em 2024, o Office of the National Cyber Director do governo dos EUA contou "approximately 74,000 independently operated but interconnected networks called Autonomous Systems (ASes)", cerca de 74 mil redes (National Cyber Director, página 3), e o BGP acredita no que cada uma delas diz. Depois da leitura, você consegue distinguir um hijack de um , explicar por que a rota mais específica vence, ler os incidentes nos registros de quem os viveu e associar cada falha à sua defesa. O protocolo em si está no primer de BGP, e a série começa em tabelas de roteamento.

O que o BGP presume, e por quê

O (RFC) que definiu o BGP-4 em março de 1995 tratou de segurança numa frase só: "Security issues are not discussed in this document", a segurança ficou de fora (RFC 1771, Security Considerations). A análise de 2006 é direta: "There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data", nada interno protege os dados (RFC 4272, Abstract).

A premissa por baixo aparece na arquitetura da Resource Public Key Infrastructure (): "BGP is based on the assumption that the AS that originates routes for a particular prefix is authorized to do so by the holder of that prefix", presume-se a autorização do titular (RFC 6480, seção 3). Nada num UPDATE prova isso. O roteador escolhe rotas por política local (RFC 4271, seção 9.1), e a única checagem do protocolo base do lado da origem, a de que o primeiro sistema autônomo (AS) do caminho é o próprio vizinho, é opcional (seção 6.3). A autenticação da sessão protege a conexão, não o conteúdo: não impede informação falsa vinda de um peer legítimo (RFC 4272, seção 1). A ideia de path vector está em Roteamento dinâmico comparado.

Dois jeitos de errar: hijacks e route leaks

Um hijack de prefix, nas palavras do roadmap americano, é "networks originating false or unauthorized announcements of destination addresses to cause misdelivery of Internet traffic", anúncios falsos que desviam tráfego (National Cyber Director, página 5): é uma questão de quem pode originar. Um route leak, uma rota verdadeira no lugar errado, é "the propagation of routing announcement(s) beyond their intended scope", além do escopo pretendido (RFC 7908, seção 2). A maioria dos route leaks é acidental (seção 2), e o roadmap diz o mesmo dos incidentes de BGP em geral (página 5).

A RFC 7908 divide os route leaks em seis tipos; é o provedor de acesso (Internet Service Provider):

TipoNome na RFC 7908O que vai para onde
1Hairpin Turn with Full Prefixum AS com dois upstreams repassa a rota de um ISP para o outro
2Lateral ISP-ISP-ISP Leako ISP-B repassa ao ISP-C uma rota recebida do ISP-A
3Leak of Transit-Provider Prefixes to Peerrotas do provedor de trânsito vão para um peer lateral
4Leak of Peer Prefixes to Transit Providerrotas de um peer lateral vão para o próprio provedor de trânsito
5Prefix Re-origination with Data Path to Legitimate Origino AS reorigina a rota; os pacotes ainda chegam ao destino real, passando por ele
6Accidental Leak of Internal Prefixes and More-Specific Prefixesrotas internas saem para provedores ou peers

Os tipos 1 a 4 violam política e diferem nos papéis dos AS envolvidos (seção 4); o tipo 1 se espalha porque o segundo ISP prefere o anúncio de um cliente ao de um peer (seção 3.1).

Por que a rota mais específica vence

O encaminhamento segue o longest match: entre as rotas que cobrem um destino, vence o prefix mais longo, que o BGP chama de rota mais específica (RFC 4271, seção 9.1.4). A norma do Classless Inter-domain Routing () tira a consequência: "Traffic can be hijacked by advertising a prefix for a given destination that is more specific than the aggregate that is normally advertised for that destination", o mais específico desvia o tráfego (RFC 4632, seção 12). Um agregado não ganha de uma rota mais longa já aceita.

A mesma seção põe a defesa na borda: filtros de política e limites de comprimento de prefix tirados das alocações de cada registro regional (RIR, Regional Internet Registry) (seção 12). Por isso o estrago depende da primeira rede que ouve o erro. Sobre 2019, a Cloudflare escreveu que o leak deveria ter parado na Verizon (Cloudflare, 24 de junho de 2019); em 2024, as redes que aceitaram e redistribuíram os anúncios ampliaram o impacto (Cloudflare, 4 de julho de 2024).

O registro, nas palavras de quem viveu os incidentes

Pakistan Telecom e YouTube, 24 de fevereiro de 2008

O Réseaux IP Européens (RIPE) Network Coordination Centre (RIPE NCC) acompanhou o caso pelos coletores do seu Routing Information Service (RIS). O objetivo do Paquistão era bloquear o site do YouTube (estudo de caso do RIPE NCC). Às 18:47 , a Pakistan Telecom (AS17557) começou um anúncio não autorizado que cobria parte do espaço de endereços do YouTube, e "One of Pakistan Telecom's upstream providers, PCCW Global (AS3491) forwarded this announcement to the rest of the Internet, which resulted in the hijacking of YouTube traffic on a global scale", o upstream espalhou o anúncio pelo mundo. Em dois minutos, a rota "had spread to its largest extent in the RIS routing view", já estava no auge.

A linha do tempo registra o YouTube (AS36561) anunciando ele mesmo o trecho afetado às 20:07 e rotas mais específicas às 20:18, e a PCCW Global retirando, às 21:01, todos os prefixes originados pelo AS17557. O RIPE concluiu que configuração de roteamento adequada impede essa propagação, e citou a discussão sobre certificados para recursos de numeração: a futura RPKI.

China Telecom, 8 de abril de 2010

A U.S.-China Economic and Security Review Commission relatou que, por cerca de 18 minutos, a China Telecom anunciou rotas erradas que outras redes adotaram, levando o tráfego de cerca de 15% dos destinos da internet por servidores na China (relatório da Commission, página 244). Sobre a intenção, foi cuidadosa: "Evidence related to this incident does not clearly indicate whether it was perpetrated intentionally and, if so, to what ends", a intenção não ficou clara (página 243). A RFC 7908 classifica o evento como tipo 5 (RFC 7908, seção 3.5).

2017 em diante, no registro da FCC

A Federal Communications Commission (FCC) registra que em 2017 "traffic from a number of financial institutions, including MasterCard, Visa, and others was also routed through a Russian government-controlled telecommunications company under 'unexplained' circumstances", um desvio pela Rússia sem explicação (FCC 22-18, parágrafo 6), sem nomear a empresa. Uma notificação de 2024 acrescenta, sem nome nem data, um hijack contra um serviço de criptomoeda para cometer roubo (FCC 24-62, parágrafo 11).

Verizon e DQE, 24 de junho de 2019

A Cloudflare, uma das operadoras afetadas, escreveu no mesmo dia: a DQE Communications (AS33154) usava um BGP optimizer que gerava muitas rotas mais específicas e as anunciou ao cliente Allegheny Technologies (AS396531), que as mandou ao seu outro provedor de trânsito, a Verizon (AS701), e esta as passou para a internet inteira (Cloudflare, 24 de junho de 2019). No pior momento, a Cloudflare perdeu cerca de 15% do seu tráfego global.

Facebook, 4 de outubro de 2021: uma retirada, não um hijack

Aqui o próprio dono tirou as suas rotas do ar. A Meta escreveu que "This outage was triggered by the system that manages our global backbone network capacity", o gatilho foi o sistema de capacidade do backbone: um comando de manutenção desconectou os data centers, e os servidores DNS, feitos para retirar os anúncios BGP quando perdem os data centers, os retiraram (Meta, 5 de outubro de 2021). De fora, a Cloudflare viu sumirem as rotas para os prefixes DNS do Facebook às 15:58 UTC (Cloudflare, 4 de outubro de 2021).

1.1.1.1, 27 de junho de 2024: hijack e route leak ao mesmo tempo

A partir das 18:51 UTC, a rede brasileira Eletronet (AS267613) originou uma rota para o endereço do resolver, aceita por várias redes, entre elas pelo menos um provedor Tier 1, embora a Route Origin Authorization (ROA) da Cloudflare só autorizasse o AS13335 como origem, e uma rota que a origin validation teria marcado como Invalid (Cloudflare, 4 de julho de 2024). No mesmo período, a Nova Rede de Telecomunicações (AS262504) vazou 1.1.1.0/24 para o upstream, e essa rota passava em qualquer checagem de origem: "This BGP announcement is RPKI Valid, because the origin is correctly AS13335, but this is a route leak of 1.1.1.0/24 because the path itself is invalid", a origem estava certa, o caminho não. Mais de 300 redes em 70 países perderam o resolver; o impacto nos usuários está no artigo sobre resolvers.

Defesas em camadas

Filtragem e higiene das sessões

"The main aspect of securing BGP resides in controlling the prefixes that are received and advertised on the BGP peerings", o essencial é controlar os prefixes (RFC 7454, seção 6). De clientes, só se aceitam os prefixes e os números de sistema autônomo (ASNs) deles (seções 6.2.2.1 e 9), e um limite de rotas por peer derruba a sessão se ele de repente mandar a tabela inteira (seção 8). As sessões devem preferir o TCP Authentication Option (TCP-AO) e usar a segurança por Time to Live () (seção 5). Desde 2017, o BGP externo (EBGP) rejeita por padrão: nenhuma rota entra ou sai sem uma política explícita (RFC 8212, seções 1 e 3). O Mutually Agreed Norms for Routing Security (MANRS) torna obrigatórios a filtragem de prefixes, os contatos atualizados e a publicação da intenção de roteamento num Internet Routing Registry (IRR), e recomenda a validação de endereço de origem e as ROAs (ações do MANRS, seções 4 e 5).

RPKI e validação de origem

A RPKI segue a árvore de alocação, da Internet Assigned Numbers Authority () aos cinco RIRs, e fornece autorização, não autenticação (RFC 6480, seções 2 e 2.1). Uma ROA é uma declaração assinada em que o titular de um bloco autoriza um AS a originar rotas para ele; sem maxLength, só o prefix exato fica autorizado (RFC 9582, Abstract e seção 4.3.2.2).

Roteadores não verificam assinaturas: caches de validação verificam a RPKI e alimentam os roteadores (RFC 8210, seção 3), e "the router cannot validate the data cryptographically from a well-known trust anchor. The router trusts the cache to provide correct data", o roteador confia no cache (RFC 7115, seção 3). O roteador compara cada rota com esses Validated ROA Payloads (VRPs) e a marca como Valid, Invalid ou NotFound (RFC 6811, seção 2). Ilustrativo, com valores de documentação (RFC 5398, seção 4) e um único VRP, 192.0.2.0/24, maxLength 24, AS64496:

RotaOrigemEstadoMotivo
192.0.2.0/24AS64496Validcoberta, comprimento dentro do maxLength, origem confere
192.0.2.0/24AS64497Invalidcoberta, origem diferente
192.0.2.128/25AS64496Invalidcoberta, mais longa que o maxLength 24
198.51.100.0/24AS64497NotFoundnenhum VRP a cobre

Descartar é decisão do operador: "An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so", excluir exige configuração explícita (RFC 6811, seção 2), regra que a RFC 8481 reafirmou para as implementações (RFC 8481, seção 5). A política recomendada é descartar as rotas Invalid (RFC 7454, seção 6.1.2.2.2), já que aceitá-las com preferência menor muitas vezes equivale a tratá-las como Valid (RFC 7115, seção 5). Os titulares devem publicar ROAs mínimas, só com os prefixes que de fato originam, e evitar o maxLength (RFC 9319, seção 5).

Route leaks: papéis e o atributo OTC

Uma rota vazada tem a origem certa, então a origin validation não a enxerga. A RFC 9234 (maio de 2022) faz cada sessão EBGP combinar um papel na mensagem OPEN (Provider, Customer, Route Server, Route Server Client ou Peer) e cria o atributo Only to Customer (OTC): "If a route already contains the OTC Attribute, it MUST NOT be propagated to Providers, Peers, or RSes", rota marcada não sobe (RFC 9234, seção 5). Em 2024, a falha foi o AS262504 anunciar a rota ao seu upstream, o AS1031 (Cloudflare, 4 de julho de 2024); para uma rota com OTC, essa regra proíbe exatamente esse passo.

Validação de caminho: BGPsec e ASPA

No , cada AS do caminho assina o UPDATE (RFC 8205, Abstract). Virou norma em setembro de 2017; basta um AS sem suporte no caminho para a garantia se perder (seção 7.9), e ele assina o plano de controle, não o trajeto dos pacotes (seção 8.1). Em 2024, o governo americano constatou que "the standard has yet to be implemented by commercial router vendors", nenhum fabricante o implementou (National Cyber Director, apêndice A). A Autonomous System Provider Authorization (), uma lista assinada dos provedores de trânsito de um AS, continua sendo um da Internet Engineering Task Force (IETF) em 19 de outubro de 2026 (draft de verificação ASPA, revisão 29).

O que a origin validation não faz

Ela não valida o caminho de AS (RFC 7115, seção 7), e a própria norma diz que "this system is only able to provide limited protection against a determined attacker", proteção limitada (RFC 6811, seção 6). Ela só protege onde as redes a aplicam.

Como ver na prática

O RIPEstat, do RIPE NCC, confere prefix e origem contra a RPKI. A chamada documentada, rodada em 2026-10-19 para o prefix do próprio RIPE NCC, resposta aparada (documentação do RIPEstat):

$ curl --location --request GET "https://stat.ripe.net/data/rpki-validation/data.json?resource=3333&prefix=193.0.0.0/21"
{
  "time": "2026-10-19T15:08:56.987208",
  "data": {
    "resource": "3333",
    "prefix": "193.0.0.0/21",
    "validating_roas": [
      {
        "origin": "3333",
        "prefix": "193.0.0.0/21",
        "validity": "valid",
        "max_length": 21
      }
    ],
    "status": "valid",
    "validator": "routinator"
  }
}

resource é o de origem, prefix a rota com o comprimento, validating_roas as ROAs encontradas. status vale valid, invalid_asn (uma ROA que cobre o prefix nomeia outro ASN), invalid_length (mais longo que o máximo da ROA) ou unknown (nenhuma ROA).

Coletores públicos mostram o que os roteadores viram. O post da Cloudflare de 2021 reproduz o Route Views sem o prefix DNS do Facebook, e uma rota que o cobre, com caminho de AS e estado RPKI (aparado):

route-views>show ip bgp 185.89.218.0/23
% Network not in table
route-views>show ip bgp 129.134.30.0
BGP routing table entry for 129.134.0.0/17, version 1025798334
3303 6453 32934
path 7FE1408ED9C8 RPKI State not found

Isso é o plano de controle, e o plano de dados pode não segui-lo (RFC 7115, seção 7); um traceroute mostra o caminho real dos pacotes.

Os dados do National Institute of Standards and Technology () de 2026-10-19 00:00 mostram 70,86% de 1.262.159 pares prefix-origem IPv4 Valid, 27,67% NotFound e 1,47% Invalid, e 79,42% de 310.354 pares IPv6 Valid (monitor do NIST); em abril de 2019, a fatia Valid do IPv4 era de 12,5%. Isso mede assinatura, não filtragem: "The monitor does not attempt to measure the extent of deployment of RPKI-ROV in operational networks", o monitor não mede quem filtra (metodologia do NIST), sendo ROV a route origin validation. A página de teste da Cloudflare verifica se o seu provedor descarta rotas Invalid; em 2026-10-19, a resposta do título ainda era "No" (Is BGP safe yet?).

A calculadora de validação de origem de rota aplica a tabela acima a qualquer rota e lista de VRPs que você colar, e Validação de origem de rota, feita à mão percorre cada teste. A CIDR / Subnet Calculator mostra a relação de "covered", 192.0.2.128/25 dentro de 192.0.2.0/24, e o IPv6 Toolkit faz a mesma conta de prefix para IPv6. O ASN lookup e o RDAP lookup, do , perguntam ao registro quem detém um número de AS ou um bloco de endereços: registro, não roteamento nem ROAs.

Para lembrar

  • O BGP não tem meio interno de verificar um anúncio; a especificação de 1995 nem discutia segurança.
  • Hijack é uma originação não autorizada; route leak é uma rota verdadeira propagada além do escopo pretendido (seis tipos na RFC 7908); a maioria é acidental.
  • A rota mais específica vence onde quer que seja aceita, então a filtragem do primeiro upstream decide o estrago, como em 2008 e 2019.
  • Roteadores não verificam assinaturas da RPKI, os caches sim; o roteador marca Valid, Invalid ou NotFound, e descartar as Invalid é política explícita do operador.
  • A origin validation não impede route leaks (o leak de 2024 era RPKI Valid); os papéis e o OTC da RFC 9234 tratam disso, o BGPsec não está em roteadores comerciais e a ASPA ainda é draft.
  • Em 2026-10-19, o NIST contou 70,86% dos pares prefix-origem IPv4 e 79,42% dos IPv6 como RPKI Valid: assinatura, não filtragem.

Fontes