Un cambio interesante se avecina en BGP

Sobre la fugas de rutas

Una fuga de rutas (route leaks) se define como la propagación de un anuncio más allá del alcance previsto (RFC 7908). Pero, ¿por qué ocurren? Existen muchas razones tales como  errores (alguien digita mal un número), desconocimiento, falta de filtros, ingeniería social, entre otras.

Si bien existen varias formas de prevenirlo y en los últimos 3 años la cantidad de fugas de rutas ha disminuido  (gracias a RPKI, IRR y otros mecanismos), mi idea es explicarles lo que pienso va a ser en el futuro las configuraciones en BGP. Y para eso hablaremos del RFC 9234, cuyo título es Prevención de fuga de rutas y detección de roles utilizando mensajes UPDATE y OPEN. De este concepto me interesa destacar la “detección de roles”, ya que a partir de este  RFC, en el futuro vamos a asignar roles en nuestra configuraciones BGP.

Para ir comprendiendo a qué queremos llegar recordemos algunos casos típicos en un ISP: 

• Llega un cliente nuevo con el cual hablaremos BGP;
• Se conecta a un IXP;
• El ISP contrata un nuevo upstream provider;
• Realizaremos un nuevo peering privado.

En todos esos casos es necesario tomar decisiones. Hay muchas maneras de configurar BPG: route maps, AS filters, prefix-lists, comunidades, ACLS, entre otros. Incluso puedo estar usando más de una de estas opciones.  

Y aquí es donde aparece el RFC 9324: este documento define los roles dentro del mensaje Open. Se trata de un acuerdo al que van a llegar los dos enrutadores. Por ejemplo, si yo soy un enrutador y converso con otro, le digo que soy “cliente” y él en su sesión BGP puede decir “yo soy tu proveedor”. En base a eso todas las configuraciones (léase filtros) se harán de forma automática y, en consecuencia, esto debería disminuir los route leaks.

Estas capacidades entonces se negocian en el mensaje Open de BGP.

En el RFC se definen 5 roles:

Proveedor: el emisor es un proveedor de tránsito para el vecino;

Cliente: el emisor es un cliente de tránsito del vecino;

RS: el emisor es un servidor de rutas (route server), generalmente en un punto de intercambio de tráfico (IXP);

Cliente RS: el emisor es cliente de un RS;

Peer: el emisor y el vecino son peers.

¿Cómo se configuran los roles?

Si por ejemplo tengo un router con una sesión BGP contra alguien y de un lado está el provider, del otro lado tiene que estar customer, y viceversa. Si tengo un Route Server (RS) de un lado, del otro lado debo tener un cliente route server y viceversa; y peer contra peer (ver tabla)

A continuación, podemos ver un ejemplo

Capacidades BGP

Las capacidades BGP son lo que el enrutador anuncia a sus peers BGP para informarles qué características puede admitir y, si es posible, intentará negociar esa capacidad con sus vecinos. Un router BGP determina las capacidades admitidas por su peer examinando la lista de capacidades presentes en las capacidades transportadas por el mensaje OPEN. Podríamos compararlo con dos personas políglotas que se encuentran: uno habla inglés español y portugués, y el otro francés, chino e inglés. El idioma común en el que coinciden es el inglés, por lo que se comunicarán en ese idioma. Pero no lo harán en francés, ya que solo una de ellas lo habla. Eso es lo que básicamente ha permitido que BGP haya crecido tanto y el impacto en nuestras redes ha sido muy pequeño, porque tiene esos conceptos de compatibilidad hacia atrás (backward compatibility) que funcionan perfectamente.

Este RFC añadió una nueva capacidad

¿Funciona este código? Totalmente; aquí un ejemplo:

Modo estricto

En general las capacidades se negocian entre los BGP Speakers y se utilizan exclusivamente las que ambos soportan. Strict Mode es una opción que, en el caso que se configure, ambos enrutadores deberán soportar esta capacidad.

Conclusión

En conclusión, creo que la manera como el RFC 9234 hace las cosas será el futuro de la configuración BGP a nivel global, reemplazando y mejorando notablemente la fuga de rutas y anuncios indebidos en Internet. Facilitará las configuraciones en BGP, y será un complemento a RPKI e IRR en el tema de fugas de rutas, y en que las tablas de enrutamiento se encuentren más limpias.

Puedes ver la presentación completa en el marco de LACNIC 38 LACNOG 2022 aquí