Adopción de RFC 9234: Roles BGP y el atributo Only-to-Customer para la prevención de fugas de rutas

El problema fundamental que RFC 9234 aborda es la fragilidad inherente de Border Gateway Protocol (BGP) frente a las fugas de rutas, un desafío que ha persistido desde los inicios de Internet. Históricamente, la prevención de estas fugas ha recaído en políticas de enrutamiento manuales y propensas a errores, implementadas de forma independiente por cada Sistema Autónomo (AS). Estas políticas son complejas de mantener y escalar, y su incorrecta configuración puede llevar a la propagación de rutas no intencionadas, causando interrupciones de servicio y degradación del rendimiento a escala global.

RFC 9234 introduce un mecanismo estandarizado y en banda para codificar la intención de las relaciones de enrutamiento directamente dentro del protocolo BGP. Al definir 'BGP Roles' (Provider, Customer, Peer, RS, RS-Client) y el atributo 'Only-to-Customer' (OTC), el protocolo permite que los routers validen y rechacen automáticamente rutas que violan las relaciones esperadas, eliminando la necesidad de políticas manuales complejas. Esto representa un cambio significativo de un modelo de "confianza implícita" a uno de "validación explícita" en la propagación de rutas, mejorando la resiliencia y seguridad de la infraestructura de enrutamiento de Internet.

La relevancia de esta solución es crítica en el contexto actual de una Internet cada vez más interconectada y dependiente. Las fugas de rutas no solo causan interrupciones, sino que también pueden ser explotadas para ataques de denegación de servicio o intercepción de tráfico. La adopción generalizada de RFC 9234 es esencial para fortalecer la columna vertebral de Internet contra estos vectores de ataque y errores operativos, proporcionando una capa de seguridad programática que antes dependía de la diligencia humana.

Arquitectura del Sistema

RFC 9234 introduce dos componentes clave en la arquitectura de BGP: BGP Roles y el atributo Only-to-Customer (OTC). Los BGP Roles se negocian durante el establecimiento de la sesión eBGP (External BGP) y definen la relación entre dos AS vecinos (e.g., Provider-Customer, Peer-Peer). Esta negociación ocurre a través de una nueva capacidad en los mensajes BGP OPEN. Si las roles no coinciden o si un lado requiere 'strict mode' y el otro no envía la capacidad, la sesión es rechazada, previniendo malentendidos latentes que podrían derivar en fugas de rutas.

El atributo OTC es un atributo de ruta opcional transitivo (tipo de código 35) que lleva un número de AS. Este atributo se adjunta a una ruta la primera vez que deja de viajar estrictamente "hacia arriba" en la jerarquía de AS, marcando el "pico" del camino. Una vez que una ruta tiene el atributo OTC, solo puede propagarse "hacia abajo" a los clientes. Las reglas para establecer y verificar OTC son cruciales: un router establece OTC con su propio ASN al anunciar a un cliente, peer o RS-client, o con el ASN del vecino al recibir de un provider, peer o RS si OTC no está presente. Un router que recibe una ruta con OTC de un provider, peer o RS, o que intenta anunciar una ruta con OTC a un provider, peer o RS, la considera una fuga y la rechaza.

La implementación de RFC 9234 requiere que los routers BGP soporten estas nuevas capacidades y atributos. La detección de fugas se vuelve automática: un router que entiende OTC puede rechazar una ruta filtrada sin necesidad de políticas de operador escritas manualmente. La naturaleza opcional transitiva de OTC significa que incluso los routers que no soportan RFC 9234 deben reenviar el atributo, aunque no lo interpreten. Esto es vital para la adopción gradual y la visibilidad de las fugas en entornos de despliegue parcial. Cloudflare utiliza su red global y feeds BMP (BGP Monitoring Protocol) para observar la presencia y el valor del atributo OTC en las rutas recibidas de sus peers, permitiendo una evaluación directa de la conformidad con RFC 9234 y la identificación de ASes que eliminan el atributo.

➜ ~ monocle search -D rib \
--start-ts "2026-08-18T00:44:00Z" \
--end-ts "2026-08-18T03:44:00Z" \
-p 8.44.61.0/24 \
-a '^1299 13335$' \
--collector route-views4 \
-f type,timestamp,peer_asn,prefix,as_path,only-to-customer \
--json

Fundamentos Teóricos

El concepto de "valley-free routing" es un principio fundamental en el diseño de BGP y las políticas de enrutamiento inter-AS, formalizado en trabajos como el de Gao y Rexford (2001) sobre la estructura jerárquica de las relaciones de enrutamiento en Internet. Este principio establece que una ruta no debe "subir" en la jerarquía de relaciones (de cliente a proveedor) después de haber "bajado" (de proveedor a cliente), ni tampoco "subir" después de haber viajado "lateralmente" (entre peers). Las fugas de rutas son precisamente violaciones de esta propiedad "valley-free", donde el tráfico se desvía por caminos no autorizados por las relaciones contractuales y de confianza entre los ASes.

RFC 9234 se basa en esta comprensión teórica de las relaciones AS y las propiedades deseadas de las rutas. Al codificar explícitamente los roles de los vecinos BGP y el atributo Only-to-Customer (OTC), el protocolo proporciona un mecanismo algorítmico para hacer cumplir la propiedad "valley-free" de manera distribuida. Esto contrasta con enfoques anteriores que dependían de la inferencia de relaciones y la aplicación de políticas locales, que eran inherentemente más propensas a errores y difíciles de coordinar a escala global. La capacidad de rechazar rutas que violan el OTC es una aplicación directa del principio de "valley-free routing" en el plano de control de BGP, moviendo la validación de un proceso externo y manual a una verificación intrínseca del protocolo.