RIPE ya enseña a prevenir fugas de rutas. Esto es lo que significa.
El curso de seguridad del enrutamiento BGP de RIPE NCC incluye ya la teoría de prevención y detección de fugas de rutas basada en el RFC 9234, junto con un laboratorio práctico sobre cómo configurar BGP Roles y explorar Only-To-Customer. 1
Cuando el registro regional mete algo en su temario estándar, el tema ha pasado de propuesta experimental a práctica operativa recomendada.
El hueco que deja RPKI
La semana pasada escribimos sobre dónde se detiene RPKI. La limitación principal merece repetirse: RPKI no elimina las fugas de rutas.
Una fuga de ruta no es un origen falsificado. El origen es legítimo y el ROA valida perfectamente. El problema está en la propagación. Una red recibe una ruta de un peer o de un proveedor de tránsito y la reanuncia a otro, adonde no debía ir. De repente una red regional pequeña se anuncia como camino hacia buena parte de internet, y el tráfico la sigue, porque BGP se cree lo que le cuentan.
Históricamente, las fugas de rutas han provocado algunos de los mayores incidentes de enrutamiento registrados, y casi siempre son accidentes: un filtro que falta, una política aplicada a la sesión equivocada, una plantilla copiada de otro vecino.
RPKI no ve nada de esto, porque cada anuncio de la cadena tiene un origen válido.
Roles y OTC, en corto
El RFC 9234 coge lo que todo el mundo ya sabe de manera informal —esta sesión es con un cliente, aquella con un proveedor de tránsito, la otra con un peer— y lo hace explícito dentro del propio protocolo. 2
En cada sesión eBGP configuras un rol: provider, customer, route server, route server client o peer. La capacidad Role se intercambia en el mensaje OPEN, así que ambas partes confirman la relación y rechazan configuraciones incompatibles. Una vez conocidos los roles, el atributo Only-To-Customer, un atributo de camino opcional y transitivo, permite a los routers marcar y detectar anuncios que han viajado adonde la relación comercial no permite. 2
Lo elegante es que añade una comprobación a nivel de protocolo a lo que siempre fue un problema de filtrado. Prevenir fugas a la manera clásica significa mantener filtros de prefijos exactos para cada vecino: un trabajo enorme, propenso a errores y permanentemente desactualizado. Roles y OTC permiten a los routers compatibles detectar muchas fugas de forma estructural, a partir de la propia relación, dependiendo menos de los filtros por vecino.
Dependiendo menos, no sustituyéndolos. El RFC 9234 se suma a tus mecanismos actuales en lugar de retirarlos, así que sigues necesitando filtrado por IRR, validación de origen por RPKI, límites max-prefix y filtrado de bogons. Lo que desaparece es la suposición de que esos filtros son lo único que separa una política mal escrita de una fuga.
Además se despliega con relativa facilidad: unas pocas líneas por sesión en BIRD, FRR o JunOS, y degrada con elegancia cuando el otro extremo no lo soporta.
El control que damos a los clientes
Operamos AS210464, y nuestra postura es que un cliente debe poder controlar su propio enrutamiento sin abrir un ticket.
Eso empieza por validar con RPKI las rutas que aceptamos, es decir, validación de origen como mínimo indispensable. Y sigue con un juego completo de comunidades BGP que te da controles «con forma de fuga» directamente en tus anuncios: no anunciar a un AS concreto, a clientes, a peers directos, a peers de IXP, a servidores de rutas o a proveedores de tránsito, más controles regionales, prepending de una a tres veces, local-preference para rutas de respaldo y blackholing activado de forma remota cuando necesitas que el prefijo se descarte en nuestro borde y no en tu servidor.
Ese juego de comunidades existe porque el alcance de un anuncio debería decidirlo tú, expresado en el propio anuncio, y no un filtro que alguien de nuestro lado mantiene a mano y tarde o temprano se equivoca.
Las sesiones BGP empiezan en 5 €/mes. Cada máquina virtual viene con un /48 de IPv6 enrutado; si necesitas espacio para anunciar y no solo para usar, o traes el tuyo o nos lo alquilas. Las sesiones se levantan contra direcciones locales de pasarela, 10.0.0.1 y fd10::1, con multihop activado en tu lado y TTL 255, y lo que ven de verdad nuestros routers puedes comprobarlo con el looking glass desde Tirana, Skopie, Ámsterdam o Dublín, sin cuenta y sin llamada comercial.
Tres cosas que valen una tarde
Si operas BGP, empieza por poner roles en tus sesiones eBGP, y hazlo primero con tus proveedores de tránsito, que es donde una fuga hace más daño.
Ya que estás, audita tus ROA. Los fallos operativos, como ROA caducados o valores de maxLength demasiado generosos, siguen estando entre las causas más comunes de anuncios inválidos para RPKI, así que el incidente de enrutamiento más probable de tu futuro sigue siendo el que provoques tú.
Y haz el curso de RIPE si estás en la región. Los laboratorios son la forma más rápida de coger soltura con los roles y con OTC.
Las fugas de rutas siguen siendo uno de los pocos modos de fallo de internet en los que una sola sesión mal configurada puede degradar el servicio de redes que jamás han oído hablar de ti. La solución ya está estandarizada, se enseña y es barata. Quedan pocas excusas.