Resumen

  • Los roles BGP permiten que redes adyacentes comparen sus expectativas de proveedor, cliente, par o servidor de rutas antes de intercambiar anuncios; una incompatibilidad confirmada puede impedir la sesión eBGP.
  • OTC transporta una frontera de propagación con la ruta, pero no autentica el acuerdo comercial, no sustituye las políticas explícitas y no describe relaciones complejas que cambian por prefijo.

Análisis

Una fuga de rutas no exige un origen falso. RFC 7908 la define como la propagación de un anuncio más allá del ámbito previsto. Una ruta puede llevar al destino correcto y aun así pasar de un proveedor a otro, o de un par hacia un proveedor, en una dirección que las relaciones no permitían. El fallo está en la cadena de entregas.

Durante años esa cadena dependió de la configuración local. Un operador clasificaba a su vecino como cliente, proveedor o par, creaba filtros alrededor de esa creencia y confiaba en que el otro extremo describiera la misma relación. La sesión no tenía que comparar ambas versiones. Un error tipográfico, un filtro ausente o una automatización defectuosa podían convertir una equivocación local en una ruta aceptada lejos.

RFC 9234 introduce un intercambio previo. El mensaje BGP OPEN puede incluir la capacidad de rol. Los valores normales son Provider, Customer, Route Server, Route Server Client y Peer. Cuando ambos vecinos anuncian un rol, la pareja debe ser coherente: Provider con Customer, Route Server con Route Server Client y Peer con Peer. Si no lo es, la conexión se rechaza mediante Role Mismatch.

Es una comprobación de coherencia del protocolo, no un oráculo comercial. El router no lee contratos de tránsito, facturas ni compromisos de tráfico. Dos redes podrían configurar una pareja compatible pero falsa. También pueden mantener una relación que cambia según prefijo, servicio o geografía. RFC 9234 la considera compleja y prohíbe asignarle un único rol. Si es posible se separa en sesiones normales; de lo contrario sigue haciendo falta política por prefijo.

El segundo mecanismo viaja con los UPDATE. Only to Customer, u OTC, es un atributo de ruta opcional y transitivo con código 35. Su valor de cuatro octetos contiene un ASN. Cuando una ruta ha sido enviada hacia un cliente, un par o un cliente de servidor de rutas, OTC señala que después solo debe propagarse hacia clientes.

Una ruta con OTC recibida de un cliente o de un cliente de servidor de rutas se considera fuga y queda inhabilitada. Una discordancia definida al recibirla de un par produce el mismo resultado. Al exportar, una ruta que ya contiene OTC no debe enviarse a proveedores, pares ni servidores de rutas. Por eso la señal puede prevenir una fuga local y detectarla varios saltos después.

El despliegue parcial aporta valor. Si una ruta llega de un proveedor, par o servidor de rutas sin OTC, un receptor compatible puede añadirlo. El RFC afirma que esto beneficia a quienes adoptan temprano. Sin embargo, OTC no está protegido criptográficamente: un AS intermedio puede quitarlo y una marca equivocada puede limitar rutas legítimas.

La compatibilidad también exige decidir. Si un vecino anuncia el rol y el otro no, el comportamiento habitual es continuar con el rol configurado localmente. El modo estricto puede rechazar al vecino sin capacidad. RFC 9234 desaconseja que sea el valor predeterminado porque una actualización de software podría impedir que la sesión se establezca.

RFC 8212 sigue siendo la base: no se deben importar ni exportar rutas eBGP sin políticas explícitas. Los roles y OTC no validan el origen, no corrigen una política permisiva y no reemplazan los filtros de prefijo o camino. IANA confirma los códigos —atributo 35 y subcódigo 11—, pero no demuestra el uso por una red o versión concreta.

Fuentes