Cloudflare publicó un análisis sobre la propagación del estándar RFC 9234, utilizado para limitar las fugas de enrutamiento en el protocolo BGP, basándose en datos de sesiones de interconexión con sus redes y en pruebas durante las cuales anunció rutas de prueba a través de Internet. La empresa constató que 67 redes añadían el atributo Only to Customer, u OTC, a las rutas que enviaban directamente, pero también descubrió que varias redes eliminaban este atributo al reenviar las rutas, lo que debilita la capacidad de las redes compatibles para detectar y rechazar fugas.
Las fugas de BGP se producen cuando una red anuncia a otro proveedor o par una ruta que aprendió de un proveedor o par, contrariamente a las relaciones comerciales y a la supuesta lógica jerárquica de las rutas de Internet. Esto puede hacer que el tráfico de datos pase por una red que no estaba preparada para soportarlo o que no estaba autorizada originalmente a transportarlo, con la posibilidad de aumentar la latencia, perder paquetes o provocar interrupciones más amplias.
Trasladar las reglas de prevención de fugas al protocolo
Los mecanismos de protección tradicionales obligan a cada operador a configurar políticas manuales, como filtros de prefijos y políticas extraídas de registros IRR, lo que requiere definir con precisión la relación de cada sesión BGP. RFC 9234 propone trasladar parte de esta carga al propio protocolo mediante dos componentes: BGP Roles y el atributo OTC.
Los roles de BGP determinan la naturaleza de la relación entre los vecinos de una sesión eBGP, como Provider, Customer y Peer, además de RS y RS-Client, asociados a los servidores de rutas en los puntos de intercambio de Internet. Cuando las partes anuncian roles incompatibles, la sesión se rechaza con una notificación Role Mismatch, en lugar de continuar hasta que el error aparezca posteriormente como una fuga real. En los casos de adopción parcial, la sesión puede funcionar si solo una parte envía el rol, a menos que el operador active el modo estricto, que rechaza las sesiones en las que la parte contraria no anuncia ningún rol.
El atributo OTC registra el número de sistema autónomo que lo añadió por primera vez cuando la ruta deja de ascender por la jerarquía y comienza a dirigirse hacia los clientes. Una vez presente, la ruta no debería pasar a un proveedor, par o servidor de rutas; asimismo, un router compatible puede rechazar una ruta que contenga OTC si llega desde una relación que no lo permite. De este modo, la prevención se vuelve automática después de configurar los roles, en lugar de depender exclusivamente de una política escrita por el operador para cada sesión.
¿Qué midió realmente Cloudflare?
Cloudflare utilizó datos BMP de sus routers y observó el valor de OTC recibido de los vecinos directos durante tres meses. Consideró que una red era candidata al cumplimiento cuando el valor del atributo coincidía con el número de sistema del vecino, un método que reduce la ambigüedad que aparece al analizar rutas que han pasado por varias redes. Estas mediciones mostraron 67 sistemas autónomos que añadían OTC, con la observación de que los servidores de rutas pueden adoptar las nuevas funciones con mayor rapidez y de que algunas redes gestionadas por particulares aparecieron en una proporción notable de los resultados.
En cambio, el análisis de datos RIB públicos de RouteViews y RIPE RIS ofreció resultados más conservadores. Tras intentar distinguir entre las redes que añaden OTC al enviar y aquellas que rellenan un valor faltante al recibir, Cloudflare identificó 18 redes que probablemente añadían el atributo y 20 redes que probablemente lo rellenaban. Al combinar los resultados de los vecinos directos, llegó a 36 redes que probablemente cumplían RFC 9234. La empresa confirma que la metodología puede pasar por alto redes con un número limitado de rutas o vecinos.
Las redes que eliminaron OTC
Cloudflare probó la propagación de OTC anunciando un prefijo IPv4 y otro IPv6 que llevaban el valor 13335 desde sus sitios de intercambio, y después analizó los mensajes BGP durante el anuncio y la retirada utilizando datos de RIPE RIS, RouteViews y datos BMP locales. En la primera fase, identificó seis sistemas autónomos que eliminaban el atributo, entre ellos las redes de nivel 1 GTT, AS3257 y Arelion, AS1299. El análisis posterior de las rutas más largas permitió identificar nueve redes adicionales que eliminaban OTC.
El atributo estaba ausente en el 33,1 % de las rutas AS_PATH de IPv4 y en el 17 % de las rutas IPv6 de la prueba. GTT, Arelion o ambas aparecieron en el 96,6 % de las rutas IPv4 que perdieron OTC y en el 92,9 % de las rutas IPv6, con Arelion concentrando la mayoría de los casos. Al examinar las rutas cuyo siguiente salto era una de las dos redes, Cloudflare constató que GTT eliminaba el atributo de forma constante, mientras que Arelion lo eliminaba en el 71,4 % de las rutas IPv4 y en el 40,7 % de las rutas IPv6 de la muestra correspondiente.
Cloudflare afirmó que ambas redes confirmaron que la eliminación de OTC formaba parte de prácticas defensivas surgidas después de incidentes relacionados con el procesamiento de errores de BGP. Según los resultados publicados, las configuraciones de GTT continuaban eliminando el atributo, mientras que Arelion comenzó a conservarlo después de ponerse en contacto con Cloudflare, algo que un análisis posterior de las rutas de prueba verificó.
¿Qué cambia en la práctica para los operadores de redes?
Los resultados muestran que la adopción de RFC 9234 no depende únicamente de que los routers admitan la función, sino también de que las redes intermedias sigan transmitiendo el atributo transitivo opcional. La eliminación de OTC en una red con una posición central puede impedir que una red compatible situada varios saltos más adelante detecte una fuga que podría haberse evitado.
Cloudflare señala que Junos OS y Junos OS Evolved admiten RFC 9234 y que el soporte de Cisco IOS XR estaba previsto para la versión 26.4.1, mientras que incluyó otras implementaciones en su tabla sin especificar un estado de soporte completo, entre ellas Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, RouterOS, BIRD, OpenBGPD, FRR, ArcOS, GoBGP y ExaBGP. La empresa recomienda a los operadores que disponen de la función configurar gradualmente los roles de BGP durante las ventanas de mantenimiento, ya que su aplicación requiere reiniciar las sesiones BGP. Cloudflare también comenzó a desplegar gradualmente las configuraciones en su flota global y planea poner a disposición los datos de adopción en la sección de enrutamiento de Cloudflare Radar.