Resumo

  • Papéis BGP permitem que redes adjacentes comparem expectativas de provedor, cliente, par ou servidor de rotas antes da troca de anúncios; uma incompatibilidade confirmada pode impedir a sessão eBGP.
  • OTC leva uma fronteira de propagação junto com a rota, mas não autentica a relação comercial, não substitui políticas explícitas e não descreve arranjos complexos que mudam por prefixo.

Análise

Um vazamento de rotas não exige origem falsa. A RFC 7908 o define como a propagação de um anúncio além do escopo pretendido. A rota pode apontar para o destino correto e ainda assim passar de um provedor para outro, ou de um par para um provedor, em direção que as relações não permitiam. A falha está na cadeia de repasses.

Por muito tempo essa cadeia dependeu principalmente da configuração local. Um operador classificava o vizinho como cliente, provedor ou par, construía filtros em torno dessa convicção e esperava que o outro lado descrevesse a mesma relação. A sessão não precisava comparar as duas versões. Um erro, filtro ausente ou automação defeituosa podia transformar uma falha local em rota aceita longe dali.

A RFC 9234 introduz uma verificação antes das rotas. A mensagem BGP OPEN pode carregar a capacidade de papel. Os papéis normais são Provider, Customer, Route Server, Route Server Client e Peer. Quando ambos os lados os anunciam, o par precisa ser coerente: Provider com Customer, Route Server com Route Server Client e Peer com Peer. Caso contrário, a conexão é rejeitada por Role Mismatch.

Essa é uma verificação de coerência do protocolo, não um oráculo comercial. O roteador não lê contrato de trânsito, fatura nem compromisso de tráfego. Duas redes podem configurar papéis compatíveis, porém falsos. A relação também pode variar por prefixo, serviço ou região. A RFC chama isso de relação complexa e proíbe um único papel na sessão. Se não for possível separar sessões normais, continua necessária uma política por prefixo.

O segundo mecanismo acompanha o UPDATE. Only to Customer, ou OTC, é um atributo de caminho opcional e transitivo com código 35. Seu valor de quatro octetos contém um ASN. Depois que a rota segue para cliente, par ou cliente de servidor de rotas, OTC indica que ela só deve continuar na direção de clientes.

Uma rota com OTC recebida de cliente ou cliente de servidor de rotas é vazamento e fica inelegível. Uma divergência específica ao recebê-la de um par tem o mesmo efeito. Na exportação, uma rota que já contém OTC não pode seguir para provedores, pares nem servidores de rotas. O sinal pode impedir o erro local e detectar um vazamento vários saltos depois.

A implantação parcial ainda ajuda. Quando uma rota chega de provedor, par ou servidor de rotas sem OTC, o receptor compatível pode acrescentá-lo. A RFC descreve isso como benefício para primeiros adotantes. Porém, o atributo não tem proteção criptográfica: um AS intermediário pode removê-lo, e uma marca incorreta pode limitar alcance legítimo.

A compatibilidade traz outra escolha. Se um vizinho anuncia o papel e o outro não, o comportamento normal é continuar usando o papel configurado localmente. O modo estrito pode rejeitar o vizinho silencioso. A RFC 9234 desencoraja seu uso como padrão porque uma atualização de software poderia impedir a sessão de subir.

A RFC 8212 permanece como base: rotas eBGP não devem ser importadas nem exportadas sem políticas explícitas. Papéis e OTC não validam origem, não consertam política permissiva e não substituem filtros de prefixo ou caminho. A IANA confirma os códigos — atributo 35 e subcódigo 11 —, não a adoção por rede ou versão específica.

Fontes