ROA: la clave para la verificación de rutas en la Red

El Internet del presente y del futuro se empieza a cimentar sobre la base de una relación de confianza certificada, en la que sus entidades y sistemas autónomos colaboran para crear un ecosistema digital más seguro y resiliente. Esta redefinición de confianza es crucial en un mundo donde el protocolo de enrutamiento BGP, un pilar de la comunicación en Internet que ha mostrado diversas vulnerabilidades y debilidades, permitiendo la realización de redirecciones malintencionadas y manipulaciones del tráfico.

En respuesta a estas amenazas, la Infraestructura de Clave Pública de Enrutamiento (RPKI) se ha consolidado como una arquitectura fundamental de seguridad. Adoptada a nivel mundial por los Registros de Internet Regionales (RIR), provee de un marco para la verificación y autenticación de rutas, mitigando los riesgos asociados con el enrutamiento.

Los Route Origin Attestations (ROA), piedra angular de RPKI, son documentos firmados digitalmente que establecen una correlación precisa entre un conjunto de prefijos IP y los sistemas autónomos (AS, en inglés) autorizados para originar estos prefijos en los anuncios BGP. La especificación técnica de ROA se introduce en el RFC 6482, que proporciona un marco detallado para su implementación y uso.

Funcionamiento básico

El funcionamiento de los ROA es sencillo de comprender: al recibir un anuncio de prefijo por BGP, un sistema autónomo puede verificar si la entidad que origina el anuncio y la longitud del prefijo (maxLength) concuerdan con lo registrado en la RPKI. Si existe coincidencia, el anuncio BGP se reconoce como válido. Si hay discrepancias – ya sea porque se originó en un sistema autónomo diferente o porque se infringe la longitud máxima del prefijo declarada – el anuncio BGP se categoriza como inválido. Además, se introduce un tercer estado para situaciones en las que el anuncio no está respaldado por ningún ROA, es decir, no hay registro de él en RPKI; en tales instancias, el estado se designa como “desconocido” o “no encontrado”. 

- Ejemplo de creación de un ROA -

El parámetro maxLength en un ROA es crucial, ya que define la longitud máxima de los prefijos que el sistema autónomo puede anunciar. Sin embargo, es un parámetro opcional, por lo que, si no se especifica, solo se puede anunciar el prefijo exacto especificado en el ROA.

Veamos cómo funciona el parámetro con algún ejemplo. Imaginemos un ROA con un prefijo como 203.0.113/24 y un maxLength de 26 bits. Esto significa que la máscara por defecto la forman los primeros 24 bits de la dirección IP, y que el sistema autónomo autorizado puede anunciar prefijos más específicos, con una máscara máxima de 26 bits. Analicemos algunas situaciones que podrían darse de acuerdo con la aceptación de anuncios de ruta de ese AS, con los parámetros mencionados:

• 203.0.113.0/25: esta subred abarca las direcciones IP, desde 203.0.113.0 hasta 203.0.113.127. Es válida porque el tamaño de la máscara de red (25 bits) ≤ maxLength (26 bits).
• 203.0.113.128/25: esta es la segunda subred resultante y abarca las direcciones IP desde 203.0.113.128 hasta 203.0.113.255. Se obtiene modificando el prefijo y una máscara de red de 25 bits.
• 203.0.113.0/27: con una máscara de red más grande tendríamos subredes más pequeñas y específicas dentro de 203.0.113.0/24. Sin embargo, no está permitido anunciar este prefijo, porque el valor de la máscara excede el maxLength permitido por el ROA (27 > 26).

Principales desafíos

Según algunos investigadores, más del 5% de los ROA en repositorios RPKI estaban en conflicto con anuncios BGP legítimos y persistentes en 2020, y cerca del 30% estaban mal configurados. Esto podría llevar a que los AS descarten anuncios de rutas BGP legítimos, desconectando miles de destinos válidos y dejando al emisor sin protección contra secuestros de prefijos. Veamos algunas de las cuestiones más importantes que pueden provocar incidentes de seguridad:

• Acceso inseguro a la gestión de ROA: las interfaces de gestión utilizadas por los operadores de red para administrar ROA pueden presentar brechas de seguridad. Estas brechas pueden facilitar el acceso no autorizado debido a fallos de configuración, vulnerabilidades en componentes o API, entre otros. Un acceso indebido puede permitir a actores malintencionados alterar ROA, comprometiendo la validez y operatividad de las rutas de red.

• Uso inadecuado de maxLength en RPKI: como hemos visto, cuando se incorpora en un ROA, permite la autorización de subredes dentro de un bloque de dirección IP más amplio, proporcionando flexibilidad en los anuncios de rutas BGP. Sin embargo, una implementación inadecuada de maxLength puede conllevar la autorización y propagación de más prefijos IP de los que se requieren realmente, abriendo brechas de seguridad significativas en la Red.

  Un atacante con conocimiento de esta configuración podría explotar esta vulnerabilidad, realizando un hijacking de rutas para anunciar subredes más específicas dentro del rango permitido. Estos anuncios fraudulentos, al ser coherentes con el ROA, pueden ser aceptados por otros sistemas autónomos.

• ROA incoherentes en los repositorios: eliminar los ROA obsoletos o redundantes es considerada una buena práctica para mantener la precisión y la seguridad en la infraestructura de RPKI y, en última instancia, en el sistema de enrutamiento de Internet. No obstante, el proceso de eliminación puede ser complejo debido a los desafíos asociados a la sincronización de información en sistemas distribuidos. Cuando se elimina o modifica un ROA, es crucial que dichas actualizaciones se propaguen y reflejen de manera coherente y oportuna en todos los repositorios y sistemas que dependen de esta información para la validación de rutas BGP.

  No obstante, los sistemas de caché, que conservan temporalmente información de los ROA pueden experimentar demoras en la actualización de los datos. Esto significa que pueden persistir ROA que ya se han modificado o eliminado, lo que a su vez puede generar conflictos o inconsistencias en el proceso de validación de rutas. En consecuencia, revisar activamente los ROA es esencial para mantener la seguridad y la coherencia en el enrutamiento de Internet. Como en el caso anterior, se debe priorizar la creación de ROA con validez adecuada.

Consejos para una implementación segura

MANRS proporciona una serie de prácticas recomendadas para prevenir los incidentes de enrutamiento más comunes y perjudiciales, como la suplantación de IP y la propagación de rutas incorrectas. La guía denominada ‘Common ROA Management Requirements and Security Standards for Operators of RPKI Services (ORS)’ es un recurso crucial para los operadores de servicios RPKI en la implementación segura de ROA. A continuación, presentamos en resumen de estas prácticas, que podrían ayudar a mitigar los riesgos más importantes.

• Gestión de los parámetros ROA: el uso correcto de los parámetros ROA es vital para asegurar la integridad en los anuncios de rutas de red. Para una administración eficiente y segura, los operadores de servicios deben renovar automáticamente todas las ROA al menos 90 días antes de su vencimiento y asegurar una validez mínima de dos años para cada uno, minimizando así problemas de caducidad y cumplimiento de certificados. También, es crucial que los operadores de red reciban alertas de expiración o renovación de ROA, permitiendo una pronta respuesta y ajustes necesarios, contribuyendo a una red más segura y resiliente. Además, es imperativo configurar correctamente el atributo maxLength, autorizando únicamente los prefijos IP necesarios y evitando la exposición de direcciones IP no utilizadas o no asignadas. En este sentido, se debe priorizar la creación de ROA mínimos.
• API y seguridad: la gestión segura de ROA, especialmente en operadores de red con espacios de direcciones extensos, exige herramientas robustas y seguras para mantener correctamente las rutas. Una solución clave para esto son las API, que facilitan la administración automatizada y escalable de ROA. No obstante, estas API deben ser diseñadas y proporcionadas bajo estándares de seguridad. Los ORS, encargados de ofrecer estas API, deben garantizar que cualquier interacción a través de estas interfaces sea segura. Además, es vital que los tokens utilizados para acceder a estas API no solo estén protegidos y cifrados, sino que, también, tengan limitaciones, tanto en tiempo de validez como en niveles de acceso. Esta precaución reduce el riesgo de accesos no autorizados o de acciones malintencionadas, asegurando que la gestión de las ROA ocurra en un entorno seguro y controlado.
• Salvaguardas para cambios en ROA: los cambios en una ROA pueden tener implicaciones significativas en la planificación y operación de las rutas de red. Por ello, los ORS deben validar meticulosamente cualquier modificación propuesta en una ROA para prevenir posibles comportamientos adversos. Si un cambio en un ROA puede invalidar los anuncios BGP existentes, se deben emitir advertencias bloqueantes, aunque los operadores de red deben tener la facultad de anular manualmente estas advertencias si entienden y aceptan los riesgos asociados.
• Métricas de salud de la infraestructura: la confiabilidad de la infraestructura es crucial. Los ORS deben asegurarse de que las partes interesadas puedan disponer de un nivel de visibilidad significativo sobre la salud y el estado del servicio de enrutamiento. Este nivel de transparencia es crucial para monitorizar la integridad del sistema y para identificar cualquier incoherencia o anomalía en las ROA. Disponer de sistemas de alerta y notificación eficaces que informen a las partes interesadas de cualquier degradación del servicio o anomalía detectada en tiempo real es fundamental.

Conclusión

Las ROA, dentro del marco de RPKI, se convierten en un pilar para afrontar los retos y amenazas de la seguridad de Internet, proporcionando un terreno para la autenticación y la verificación de rutas y, por ende, para la mitigación de riesgos en el enrutamiento. Pero un sistema de certificación no hace que la infraestructura sea completamente segura: sistemas de gestión vulnerables, mal uso de los parámetros o fallos de configuración son algunos de los desafíos que se plantean. La adopción de buenas prácticas de seguridad, como se ha visto, ayuda a mantener la integridad y coherencia de estos objetos certificados.