BGP, el protocolo que conecta las redes de Internet, se diseñó sobre la confianza: cualquier red puede anunciar cualquier prefijo y sus vecinos, en principio, lo creen. Por eso siguen produciéndose secuestros y fugas de rutas, tanto por error como de forma malintencionada, que desvían o dejan sin servicio el tráfico de terceros.
RPKI (Resource Public Key Infrastructure) es el mecanismo que permite demostrar criptográficamente qué sistema autónomo está autorizado a originar cada prefijo. Si tienes recursos asignados por el RIPE NCC y anuncias tus propios prefijos, firmarlos debería estar en tu lista de tareas.
Conceptos básicos
- Certificado de recursos: el RIPE NCC emite un certificado que vincula a tu organización con sus direcciones IP y ASN.
- ROA (Route Origin Authorisation): un objeto firmado que declara "el prefijo X puede ser originado por el AS Y, con una longitud máxima Z".
- Validación de origen (ROV): los routers comparan cada anuncio BGP con el conjunto de ROA publicados y lo clasifican como válido, inválido o no encontrado.
Un anuncio es inválido cuando existe un ROA que cubre el prefijo pero el AS de origen no coincide o el prefijo es más específico de lo permitido. Cada vez más operadores de tránsito y grandes redes descartan los anuncios inválidos, lo que protege a quien ha firmado sus prefijos frente a anuncios no autorizados.
Crear ROA en el RIPE NCC
Para la mayoría de organizaciones, lo más práctico es el RPKI alojado (hosted RPKI) del RIPE NCC, que se gestiona desde el panel de recursos del portal del RIPE NCC:
- Activar el certificado de recursos para la organización.
- Revisar qué prefijos se están anunciando realmente en BGP y desde qué AS.
- Crear un ROA por cada combinación de prefijo y AS de origen legítima.
- Comprobar en las herramientas del propio portal que ningún anuncio actual pasa a ser inválido.
El orden importa: primero se revisa lo que se anuncia y después se firma. Crear ROA sin conocer todos los anuncios (por ejemplo, un prefijo que anuncia un proveedor en tu nombre desde su AS) puede dejar sin servicio parte de tu red.
El error más común: maxLength
El campo maxLength permite autorizar subprefijos más específicos. Por ejemplo, un ROA para 203.0.113.0/24 con maxLength 24 solo autoriza el /24. Un ROA para 198.51.100.0/22 con maxLength 24 autoriza el /22 y cualquier /23 o /24 contenido en él.
Poner un maxLength generoso parece cómodo, pero abre la puerta a que un atacante anuncie un subprefijo más específico falsificando tu AS de origen, y ese anuncio sería considerado válido. La recomendación actual de buenas prácticas (RFC 9319) es evitar maxLength salvo que sea necesario y crear ROA explícitos para los prefijos que realmente se anuncian.
Prefijo AS origen maxLength
198.51.100.0/22 AS64500 22
198.51.100.0/24 AS64500 24 ← solo si ese /24 se anuncia por separado
2001:db8::/32 AS64500 32
Validar en tu propia red (ROV)
Firmar tus prefijos protege tus anuncios. Para proteger tu red de los anuncios inválidos de otros, necesitas validación de origen en tus routers de borde:
- Desplegar uno o, mejor, dos validadores RPKI (Routinator, rpki-client o FORT, entre otros).
- Conectar los routers con los validadores mediante el protocolo RTR.
- Empezar en modo observación, marcando las rutas con su estado sin filtrar.
- Una vez revisado el impacto, descartar las rutas inválidas en las políticas de entrada.
Los principales fabricantes (Cisco, Juniper, Arista, MikroTik y otros) soportan RTR y ROV en sus versiones actuales de software.
Lo que RPKI no resuelve
RPKI valida el origen del anuncio, no el camino completo. Un atacante que falsifique la ruta manteniendo tu AS como origen no será detectado por ROV. Iniciativas como ASPA trabajan en esa dirección, y los filtros de prefijos por cliente y el uso de objetos de routing en la base de datos del RIPE siguen siendo imprescindibles.
En resumen
Crear ROA para tus prefijos es una tarea sencilla, de bajo coste y con un beneficio claro: reduce el impacto de secuestros y errores de terceros sobre tus rutas. Hazlo con un inventario previo de tus anuncios, evita maxLength innecesarios y, si operas routers de borde, activa la validación de origen de forma progresiva.