A Cloudflare publicou uma análise sobre a disseminação do padrão RFC 9234, usado para limitar vazamentos de roteamento no protocolo BGP, com base em dados de sessões de troca com suas redes e em experimentos nos quais anunciou rotas de teste pela Internet. A empresa constatou que 67 redes adicionavam o atributo Only to Customer, ou OTC, às rotas que enviavam diretamente, mas também descobriu que várias redes removiam esse atributo ao encaminhar as rotas, enfraquecendo a capacidade das redes compatíveis de detectar e rejeitar vazamentos.
Os vazamentos de BGP ocorrem quando uma rede anuncia uma rota aprendida de um provedor ou peer a outro provedor ou peer, contrariando as relações comerciais e a lógica hierárquica presumida das rotas da Internet. Isso pode fazer com que o tráfego de dados passe por uma rede que não está preparada para recebê-lo ou que não está autorizada a encaminhá-lo, com possibilidade de aumento da latência, perda de pacotes ou falhas mais amplas.
Transferindo as regras de prevenção de vazamentos para o protocolo
Os mecanismos tradicionais de proteção exigem que cada operador configure políticas manualmente, como filtros de prefixos e políticas extraídas de registros IRR, o que requer a definição precisa da relação de cada sessão BGP. O RFC 9234 propõe transferir parte desse trabalho para o próprio protocolo por meio de dois componentes: BGP Roles e o atributo OTC.
As funções BGP definem a natureza da relação entre os vizinhos em uma sessão eBGP, como Provider, Customer e Peer, além de RS e RS-Client, associados a servidores de rotas em pontos de troca de Internet. Quando as partes anunciam funções incompatíveis, a sessão é rejeitada com uma notificação Role Mismatch, em vez de continuar até que o erro apareça posteriormente como um vazamento efetivo. Em casos de adoção parcial, a sessão pode funcionar se apenas uma das partes enviar a função, a menos que o operador ative o modo estrito, que rejeita sessões nas quais a parte oposta não anuncia nenhuma função.
O atributo OTC registra o número do sistema autônomo que o adicionou pela primeira vez quando a rota deixa de subir pela hierarquia e começa a ser encaminhada para clientes. Uma vez presente, a rota não deve ser encaminhada a um provedor, peer ou servidor de rotas; um roteador compatível também pode rejeitar uma rota que contenha OTC se ela chegar por uma relação que não permita isso. Assim, a prevenção se torna automática após a configuração das funções, em vez de depender exclusivamente de uma política escrita pelo operador para cada sessão.
O que a Cloudflare mediu de fato?
A Cloudflare utilizou dados BMP de seus roteadores e monitorou o valor de OTC recebido de vizinhos diretos durante três meses. A rede foi considerada candidata à conformidade quando o valor do atributo era igual ao número do sistema do vizinho, um método que reduz a ambiguidade que surge ao analisar rotas que passaram por várias redes. Essas medições mostraram 67 sistemas autônomos que adicionavam OTC, observando-se que os servidores de rotas podem adotar novos recursos mais rapidamente e que algumas redes operadas por indivíduos apareceram em proporção significativa nos resultados.
Já a análise de dados RIB públicos do RouteViews e do RIPE RIS produziu resultados mais conservadores. Após tentar distinguir entre as redes que adicionam OTC ao enviar e aquelas que preenchem um valor ausente ao receber, a Cloudflare identificou 18 redes que provavelmente adicionam o atributo e 20 redes que provavelmente o preenchem; combinando os resultados dos vizinhos diretos, chegou a 36 redes provavelmente compatíveis com o RFC 9234. A empresa afirma que a metodologia pode deixar de identificar redes com um número limitado de rotas ou vizinhos.
As redes que removeram o OTC
A Cloudflare testou a disseminação do OTC anunciando um prefixo IPv4 e outro IPv6 que continham o valor 13335 a partir de seus pontos de troca, e depois analisou mensagens BGP durante o anúncio e a retirada usando dados do RIPE RIS, do RouteViews e dados BMP locais. Na primeira etapa, identificou seis sistemas autônomos que removiam o atributo, incluindo as redes de nível 1 GTT, AS3257 e Arelion, AS1299. A continuação da análise das rotas mais longas levou à identificação de outras nove redes que removiam o OTC.
O atributo estava ausente em 33,1% dos AS_PATH de IPv4 e em 17% dos de IPv6 no experimento. GTT ou Arelion, ou ambas, apareciam em 96,6% das rotas IPv4 que perderam o OTC e em 92,9% das rotas IPv6, com a Arelion respondendo pela maioria dos casos. Ao examinar as rotas cujo próximo salto era uma das duas redes, a Cloudflare constatou que a GTT removia o atributo de forma consistente, enquanto a Arelion o removia em 71,4% das rotas IPv4 e em 40,7% das rotas IPv6 da amostra correspondente.
A Cloudflare afirmou que as duas redes confirmaram que a remoção do OTC fazia parte de práticas defensivas surgidas após incidentes relacionados ao tratamento de erros de BGP. Segundo os resultados publicados, as configurações da GTT continuaram removendo o atributo, enquanto a Arelion passou a preservá-lo após entrar em contato com a Cloudflare, algo verificado por uma análise posterior das rotas de teste.
O que muda na prática para os operadores de rede?
Os resultados mostram que a adoção do RFC 9234 não depende apenas do suporte dos roteadores ao recurso, mas também da continuidade das redes intermediárias em encaminhar o atributo transitório opcional. A remoção do OTC em uma rede com posição central pode impedir que uma rede compatível localizada várias etapas depois detecte um vazamento que poderia ter sido evitado.
A Cloudflare informa que o Junos OS e o Junos OS Evolved oferecem suporte ao RFC 9234 e que o suporte ao Cisco IOS XR estava previsto para a versão 26.4.1, enquanto outras implementações foram incluídas em sua tabela sem uma definição de suporte completa, entre elas Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, RouterOS, BIRD, OpenBGPD, FRR, ArcOS, GoBGP e ExaBGP. A empresa recomenda que os operadores que disponham do recurso configurem gradualmente as funções BGP durante janelas de manutenção, pois sua aplicação exige a redefinição das sessões BGP. A Cloudflare também começou a distribuir gradualmente as configurações em sua frota global e planeja disponibilizar dados de adoção na seção de roteamento do Cloudflare Radar.