Uma mudança interessante está chegando no BGP

03/11/2022

Por Alejandro Acosta – Coordenador I+D do LACNIC

Um vazamento de rotas (route leaks) é definido como a propagação de um anúncio além do alcance previsto (RFC 7908). Mas, por que eles acontecem? São vários os motivos: erros (alguém digita errado um número), desconhecimento, falta de filtros, engenharia social, entre outros.

Apesar de existirem várias formas de preveni-lo e nos últimos 3 anos o número de vazamentos de rotas ter diminuído (graças ao RPKI, IRR e outros mecanismos), minha ideia é explicar-lhes o que eu acho que vão ser as configurações do BGP no futuro. E para isso vamos falar sobre o RFC 9234, cujo título é Prevenção de vazamento de rotas e detecção de funções usando mensagens UPDATE e OPEN. Desse conceito eu quero salientar a “detecção de funções”, uma vez que a partir deste RFC, no futuro vamos designar funções nas nossas configurações BGP.

Para compreender o que queremos alcançar, vamos relembrar alguns casos típicos em um ISP: 

  • chega um cliente novo com quem falaremos BGP;
  • conecta-se a um IXP;
  • o ISP contrata um novo provedor upstream;
  • fazemos um peering privado novo.

Em todos esses casos, decisões precisam ser tomadas. Existem muitas maneiras de configurar o BGP: mapas de rotas, filtros AS, listas de prefixos, comunidades, ACLS, entre outros. Inclusive pode estar usando mais de uma dessas opções.   

E é aí que entra o RFC 9324: este documento define as funções dentro da mensagem Open. Trata-se de um acordo entre os dois roteadores. Por exemplo, se eu sou um roteador e falo com outro roteador, digo a ele que sou um “cliente” e ele pode dizer em sua sessão BGP “eu sou seu provedor”. Com base nisso, todas as configurações (leia-se filtros) serão feitas de forma automática e, consequentemente, isso deveria reduzir os vazamentos de rotas.

Essas capacidades são então negociadas na mensagem Open do BGP.

No RFC são definidas 5 funções:

  • Provedor: o emissor é um provedor de trânsito para o vizinho;
  • Cliente: o emissor é um cliente de trânsito do vizinho;
  • RS: o emissor é um servidor de rotas (Route Server), geralmente em um ponto de troca de tráfego (IXP);
  • Cliente RS: o emissor é cliente de um RS;
  • RS: o emissor é um servidor de rotas (Route Server), geralmente em um ponto de troca de tráfego (IXP);

Como as funções são configuradas?

Se, por exemplo, eu tiver um roteador com uma sessão BGP contra alguém e o provider estiver de um lado, o customer deve estar do outro lado e vice-versa. Se eu tiver um Route Server (RS) de um lado, do outro tenho que ter um cliente de servidor de rotas e vice-versa; e peer contra peer (ver tabela)

A seguir, vemos um exemplo:

Capacidades BGP

As capacidades BGP são o que o roteador anuncia a seus peers BGP para informa-lhes quais características pode suportar e, se possível, tentará negociar essa capacidade com seus vizinhos. Um roteador BGP determina as capacidades suportadas por seu peer examinando a lista de capacidades presentes nas capacidades transportadas pela mensagem OPEN. Poderíamos compará-lo a dois poliglotas que se encontram: um fala inglês, espanhol e português, e o outro francês, chinês e inglês. O idioma comum em que eles coincidem é o inglês, então eles se comunicarão nesse idioma. Mas eles não falarão em francês, pois apenas um deles o fala. Foi basicamente isso que permitiu que o BGP crescesse tanto e o impacto nas nossas redes tenha sido muito pequeno, porque tem esses conceitos de compatibilidade com versões anteriores (backward compatibility) que funcionam perfeitamente.

Este RFC adicionou uma capacidade nova:

Este código funciona? Totalmente. Veja um exemplo em FRR:

Modo estrito

Em geral, as capacidades são negociadas entre os BGP Speakers e apenas são usadas as que ambos suportam. O modo estrito é uma opção que, se configurada, ambos os roteadores deverão suportar essa capacidade.

Concluindo, eu acredito que a forma como o RFC 9234 faz as coisas será o futuro da configuração do BGP no nível global, substituindo e melhorando consideravelmente o vazamento de rotas e anúncios na Internet. Facilitará as configurações no BGP, e será um complemento para o RPKI e IRR na questão de vazamento de rotas, e em que as tabelas de roteamento sejam mais limpas.

Confira a apresentação completa no âmbito do LACNIC 38 LACNOG 2022 aqui

Suscríbete para recibir las últimas novedades en tu mail Click here to subscribe receive the latest news in your inbox. Inscreva-se aqui para receber as últimas novidades no seu e-mail