Border Gateway Protocol

Estabelecimento de sessão e transporte TCP

Diferente da maioria dos protocolos de roteamento que implementam mecanismos próprios de transporte na camada de rede (como o OSPF com protocolo IP 89), o BGP utiliza o protocolo de transporte orientado à conexão TCP na porta de destino 179. Isso elimina a necessidade de o protocolo implementar controles próprios de fragmentação, retransmissão de pacotes perdidos, sequenciamento ou verificação de integridade.

Dois roteadores BGP que estabelecem comunicação bilateral direta são chamados de "pares" (peers) ou "vizinhos" (neighbors). Cada sessão BGP exige configuração manual explícita dos endereços IP de cada extremidade e do respectivo número de ASN, não havendo mecanismo de autodescoberta dinâmica de vizinhança por difusão (broadcast ou multicast). Na fase de inicialização, se ambos os roteadores tentarem abrir simultaneamente a conexão TCP na porta 179, ocorre uma colisão de conexão (RFC 4271 §6.8); o BGP resolve a disputa comparando os identificadores numéricos (*BGP Router IDs*), mantendo a conexão iniciada pelo roteador de maior identificador e encerrando a outra com uma mensagem NOTIFICATION com código *Cease*.

Máquina de estados finitos (FSM)

A operação de uma sessão BGP é governada por uma máquina de estados finitos (FSM) padronizada pela RFC 4271, composta por seis estados sucessivos:

1. Idle (Inativo): Estado inicial. O roteador aloca recursos de memória para a sessão, recusa conexões de entrada e aguarda um evento de inicialização manual ou automático.
2. Connect (Conectando): O roteador aguarda a conclusão do aperto de mão de três vias (three-way handshake) da conexão TCP com o vizinho. Se a conexão for bem-sucedida, envia uma mensagem OPEN e transita para OpenSent. Se a conexão falhar ou o temporizador `ConnectRetryTimer` expirar, transita para o estado Active.
3. Active (Ativo): O roteador tenta iniciar ativamente uma nova conexão TCP com o par. Se a tentativa expirar ou falhar repetidamente, o processo retorna temporariamente para Connect ou reinicia o temporizador de reconexão.
4. OpenSent (Abertura Enviada): O roteador transmitiu sua mensagem OPEN e aguarda a mensagem OPEN de retorno do par. Ao recebê-la, valida parâmetros como versão, ASN local e calcula o temporizador de retenção efetivo (*Hold Time*), adotando o menor valor entre o configurado localmente e o sugerido pelo par (`min(local, peer)`).
5. OpenConfirm (Confirmação de Abertura): Ambos os lados concordaram com os parâmetros da mensagem OPEN. O roteador envia uma mensagem KEEPALIVE e aguarda o KEEPALIVE correspondente do par.
6. Established (Estabelecido): A sessão BGP está plenamente operacional. Apenas neste estado os roteadores começam a trocar mensagens de atualização (UPDATE) com as rotas alcançáveis e a manter o enlace vivo por meio de mensagens periódicas de KEEPALIVE. Se ocorrer qualquer erro ou o temporizador de retenção expirar sem receber mensagens, uma mensagem NOTIFICATION é transmitida e a sessão retorna imediatamente ao estado Idle.

Mensagens do protocolo

O BGP opera com cinco tipos fundamentais de mensagens, encapsuladas em pacotes com cabeçalho comum de 19 bytes:

• OPEN (Abertura - Tipo 1): Primeira mensagem enviada após a conclusão da conexão TCP. Informa a versão do protocolo (normalmente 4), o ASN de origem, o tempo de retenção sugerido (Hold Time) e o Identificador BGP (um endereço de 32 bits, normalmente o IP de loopback do roteador), além de parâmetros opcionais negociados (como suporte a ASN de 32 bits, extensões multiprotocolo e capacidade de atualização de rotas).
• UPDATE (Atualização - Tipo 2): A mensagem primária de roteamento. Transmite anúncios de novas rotas alcançáveis juntamente com seus atributos de caminho (NLRI - Network Layer Reachability Information) ou, inversamente, retira prefixos que deixaram de ser acessíveis (withdrawn routes).
• NOTIFICATION (Notificação de Erro - Tipo 3): Emitida quando uma condição anômala é detectada (como atributos corrompidos, temporizadores expirados ou encerramento administrativo). Contém o código e subcódigo do erro e acarreta o fechamento imediato da sessão TCP e o cancelamento das rotas associadas.
• KEEPALIVE (Manutenção de Atividade - Tipo 4): Pacote sem carga útil, composto unicamente pelo cabeçalho padrão de 19 bytes. É enviado periodicamente (por padrão a cada 30 segundos, ou um terço do Hold Time) para assegurar aos pares que o enlace e o processo de roteamento permanecem operacionais.
• ROUTE-REFRESH (Atualização de Rota - Tipo 5): Padronizada pela RFC 2918 e atualizada pela RFC 7313, permite que um roteador solicite ao seu par a retransmissão sob demanda de toda a base de rotas aprendidas para uma família de endereços específica. Isso viabiliza a alteração e o reprocessamento de políticas de filtragem de entrada (inbound routing policies) sem exigir a interrupção da sessão TCP (recurso conhecido como soft-reset).

Formato do cabeçalho BGP

Todos os pacotes BGP possuem um cabeçalho fixo com a seguinte estrutura binária:

BGP Externo (eBGP)

O eBGP (External BGP) é utilizado para estabelecer sessões entre roteadores pertencentes a sistemas autônomos distintos. É a modalidade empregada em pontos de interconexão internacional, conexões de trânsito IP entre operadoras e em pontos de troca de tráfego (PTTs/IXPs):

• Por padrão arquitetural, as sessões eBGP utilizam pacotes IP com o campo TTL (Time to Live) fixado em 1, exigindo que os roteadores vizinhos compartilhem o mesmo enlace físico ou sub-rede direta. Para cenários com múltiplos saltos intermediários (como em balanceamento ou firewalls), utiliza-se o recurso eBGP Multihop.
• Sempre que uma rota é propagada por eBGP, o roteador transmissor insere obrigatoriamente o seu próprio número de ASN no início da lista do atributo AS-Path e atualiza o endereço de próximo salto (Next-Hop) para sua própria interface.

BGP Interno (iBGP)

O iBGP (Internal BGP) é utilizado para trocar prefixos da Internet entre roteadores situados dentro do mesmo sistema autônomo (com o mesmo número de ASN):

• Diferente do eBGP, o iBGP não altera o atributo AS-Path e não modifica, por padrão, o endereço de Next-Hop herdado da borda externa.
• Como os roteadores do núcleo interno frequentemente não possuem as sub-redes dos enlaces externos dos provedores de trânsito em suas tabelas de roteamento interno (IGP), os roteadores de borda (ASBRs) utilizam a diretiva de configuração next-hop-self, forçando a substituição do IP do próximo salto pelo seu próprio IP interno (geralmente uma interface loopback), viabilizando a resolução recursiva da rota em toda a malha.
• Regra de prevenção de laços internos: Roteadores iBGP são estritamente proibidos de repassar uma rota aprendida de um par iBGP para outro par iBGP (split-horizon rule). Essa restrição exigiria teoricamente que todos os roteadores internos de um AS mantivessem sessões iBGP com todos os demais (uma topologia em malha completa ou full-mesh, de complexidade quadrática ${\displaystyle n(n-1)/2}$).
• Para viabilizar a escalabilidade em grandes redes e operadoras, a malha completa é substituída por duas soluções padronizadas pela IETF:
  • Refletores de Rota (Route Reflectors - RFC 4456): Servidores de roteamento autorizados a refletir atualizações iBGP para clientes subordinados dentro de um cluster, preservando a imunidade a laços por meio dos atributos opcionais Originator ID e Cluster List.
  • Confederações BGP (RFC 5065): Divisão do sistema autônomo principal em múltiplos subsistemas autônomos menores com ASNs privados, que se comunicam internamente via regras análogas ao eBGP, mas apresentam-se para a Internet global como um único ASN consolidado.

Comunidades BGP (BGP Communities)

Padronizadas inicialmente na RFC 1997, as Comunidades BGP são atributos transitivos opcionais anexados aos anúncios de rotas para rotular ou categorizar prefixos em grupos lógicos. A arquitetura de comunidades divide-se em três formatos principais:

• Comunidades Padrão (RFC 1997): Formato binário de 32 bits (convencionalmente expresso como `ASN:Valor`). Inclui valores bem-conhecidos globais como `NO_EXPORT` (não propagar para pares eBGP externos) e `NO_ADVERTISE` (não propagar para nenhum outro par BGP).
• Comunidades Estendidas (RFC 4360): Formato de 64 bits composto por tipo, subtipo e valor, indispensável para redes corporativas MPLS, onde viabiliza a definição de Route Targets (RT) e Route Distinguishers (RD) em VPNs de camada 3, além de transportar atributos de mobilidade e encapsulamento em redes EVPN.
• Grandes Comunidades (Large Communities - RFC 8092): Expandidas para 96 bits (`ASN:Função:Parâmetro`) para suportar a era dos ASNs de 32 bits sem conflitos de espaço.

As comunidades são amplamente empregadas por operadoras de trânsito IP e pontos de troca de tráfego (como o IX.br) para:

• Alterar dinamicamente a preferência local em roteadores de borda remotos;
• Condicionar o descarte ou a restrição de propagação de anúncios para determinados destinos;
• Implementar o mecanismo de Remotely Triggered Black Hole (RTBH), que utiliza a comunidade padronizada `BLACKHOLE` (`65535:666` / RFC 7999) para sinalizar a operadoras de trânsito o redirecionamento imediato de tráfego de ataques DDoS diretamente para a interface nula (`Null0`), mitigando a sobrecarga de links troncos.

Multiprotocol BGP (MP-BGP)

Especificado na RFC 4760, o Multiprotocol BGP (MP-BGP) introduziu novos atributos de alcance e retirada de rotas (MP_REACH_NLRI e MP_UNREACH_NLRI) que dissociam a operação do protocolo da amarração histórica exclusiva ao protocolo IPv4.

Com a definição de identificadores de família de endereços (AFI - Address Family Identifier) e sub-famílias (SAFI), uma única sessão de transporte BGP entre dois roteadores torna-se capaz de rotear concomitantemente:

• Prefixos unicast e multicast do protocolo IPv6;
• Redes privadas virtuais de camada 3 baseadas em comutação de rótulos (MPLS VPN / L3VPN), permitindo a segregação segura de clientes corporativos sobre um mesmo backbone compartilhado;
• Redes de sobreposição Ethernet EVPN (Ethernet Virtual Private Network / RFC 7432), a base arquitetural para virtualização de redes e comutação de máquinas virtuais e contêineres em centros de dados modernos.

Vulnerabilidade estrutural e sequestro de rotas (BGP Hijacking)

Concebido em uma era na qual a rede acadêmica da ARPANET reunia um círculo restrito de instituições de mútua confiança, o protocolo BGP original não dispunha de mecanismos nativos de criptografia para autenticar a veracidade dos anúncios de rotas. Um roteador de borda mal configurado ou deliberadamente hostil é capaz de anunciar um prefixo IP pertencente a outra entidade, evento denominado sequestro de BGP (BGP hijacking), ou repassar rotas de clientes a concorrentes de trânsito indevidamente, gerando um vazamento de rotas (route leak).

Na engenharia de redes, o sequestro de rotas divide-se em duas modalidades primárias com impactos distintos:

• Sequestro de Prefixo Exato (Exact-Match Hijack): O atacante anuncia exatamente o mesmo comprimento de prefixo do operador legítimo (por exemplo, ambos anunciam o mesmo bloco `/22`). Neste caso, o tráfego global é dividido entre os dois destinos com base na extensão do AS-Path e nas preferências locais de cada provedor na Internet, capturando apenas uma fração do tráfego mundial.
• Sequestro de Sub-prefixo (More-Specific Hijack): O invasor anuncia um bloco menor e mais específico contido dentro da faixa da vítima (por exemplo, a vítima anuncia um `/22` e o atacante anuncia um `/24` correspondente). Devido à regra universal de encaminhamento IP do Mais Longo Casamento de Prefixo (Longest Prefix Match - LPM), 100% do tráfego global destinado àquela faixa de IPs é desviado irresistivelmente para o atacante, sobrepondo-se a qualquer métrica de AS-Path ou preferência de rota.

Incidentes históricos notórios demonstraram a vulnerabilidade intrínseca dessa arquitetura de confiança cega:

• Em 2008, a empresa estatal Pakistan Telecom, ao tentar censurar o acesso ao YouTube dentro do território paquistanês através de uma rota falsa `/24`, propagou acidentalmente o anúncio para sua operadora de trânsito internacional, sequestrando o tráfego global do serviço de vídeos e deixando o YouTube inacessível mundialmente por cerca de duas horas.
• Em 2018, criminosos forjaram anúncios BGP de prefixos pertencentes à infraestrutura de DNS da Amazon Route 53, desviando consultas de servidores de autenticação do serviço de carteiras de criptomoedas MyEtherWallet para desviar fundos de usuários.
• Em 4 de outubro de 2021, uma falha interna de manutenção de rotina na infraestrutura de roteamento troncal do Facebook retirou acidentalmente todos os anúncios BGP de seus centros de dados e servidores de nomes, gerando um apagão global de mais de seis horas nos serviços Facebook, WhatsApp e Instagram.

Mecanismos de mitigação e proteção

Para mitigar a fragilidade do modelo tradicional e blindar a cadeia de conectividade, a comunidade global e as entidades regulatórias desenvolveram e implementaram soluções de validação criptográfica:

• RPKI (Resource Public Key Infrastructure): Estrutura criptográfica formal de chave pública padronizada pela IETF (RFC 6480) e operada pelos Registros Regionais de Internet (RIRs, como o LACNIC na América Latina). No ecossistema RPKI, o titular legítimo de um bloco IP emite digitalmente uma Autorização de Origem de Rota (ROA - Route Origin Authorization), especificando quais números de ASN possuem permissão formal para anunciar seus prefixos e comprimentos máximos (maxLength). Roteadores de borda modernos realizam a Validação de Origem de Rota (ROV - RFC 6811), classificando cada anúncio recebido em três estados estritos:
  • Valid (Válido): O prefixo é coberto por um ROA registrado, o ASN originador coincide e o comprimento do prefixo não excede o limite máximo permitido.
  • Invalid (Inválido): Existe um ROA cobrindo o bloco, mas o ASN originador diverge ou o prefixo anunciado é mais específico do que o permitido pelo maxLength. As boas práticas internacionais recomendam o descarte sumário (Drop Invalid).
  • NotFound / Unknown (Não Encontrado): Não há nenhum ROA emitido nos registros para aquele bloco de endereços, seguindo a rota o fluxo convencional de decisão.
• Internet Routing Registry (IRR): Bancos de dados distribuídos que registram intenções e políticas de roteamento expressas formalmente na linguagem RPSL (Routing Policy Specification Language / RFC 2622), permitindo a geração automatizada de listas de controle de acesso (filtros de prefixo) para bloquear anúncios não autorizados de clientes.
• Iniciativa MANRS: Projeto global apoiado pela Internet Society (ISOC) que estabelece as Normas Mutuamente Acordadas para Segurança de Roteamento (Mutually Agreed Norms for Routing Security), definindo um conjunto de quatro ações mandatórias para operadores de rede: filtragem estrita de prefixos, prevenção de falsificação de endereços de origem (anti-spoofing), coordenação comunitária atualizada no PeeringDB e validação ativa de RPKI.