Qué es RPKI y por qué importa
El tráfico entre redes de Internet se enruta conforme a BGP (protocolo de puerta de enlace fronteriza). BGP presupone que cada sistema autónomo (AS) es honesto al anunciar los prefijos IP que controla. Este modelo de confianza es débil. Anuncios ilegítimos, errores de configuración o ataques deliberados pueden publicar prefijos ajenos y provocar secuestros o fugas de rutas.Para reforzarlo se desarrolló la infraestructura de clave pública de recursos (RPKI), un sistema criptográfico que permite a los titulares de prefijos IP declarar qué AS puede originar anuncios para ellos. Otras redes validan después las actualizaciones BGP contra esas declaraciones.
El componente esencial de RPKI es la autorización de origen de ruta (ROA). Una ROA declara que un AS puede anunciar un prefijo y puede incluir una longitud máxima. Al llegar una actualización BGP, las redes que ejecutan validación de origen de ruta (ROV) comparan el anuncio con las ROAs y lo clasifican como válido, inválido o desconocido.
Hoy solo se admite la validación del origen; validar la ruta AS, es decir, el camino exacto seguido por el paquete, es un mecanismo diferente y más complejo llamado BGPsec, mucho menos desplegado.
En resumen: RPKI permite establecer una verdad básica más sólida sobre quién está autorizado a anunciar qué bloques IP. Esto añade una barrera de protección al enrutamiento mundial.
Historia, normas y gobernanza
RPKI y sus normas de apoyo surgieron del grupo SIDR (enrutamiento seguro entre dominios) del IETF.
Entre los documentos de referencia figuran RFC 6480 —arquitectura RPKI—, RFC 6482/6483 —perfiles ROA y validación— y RFC 6810 —protocolo RPKI a router—.
Cada RIR puede considerarse un ancla de confianza. Emite certificados de recursos a registros locales de Internet (LIRs) u otros titulares, reflejando la asignación de prefijos IP y números AS. Estos certificados forman la jerarquía que sustenta la emisión de ROA.
Los operadores pueden ejecutar sus propias autoridades de certificación o delegar en un servicio RPKI alojado del RIR.
Del lado consumidor, los routers obtienen datos validados de validadores de partes confiantes. Estos recopilan información ROA de repositorios RPKI distribuidos mediante protocolos como rsync o RRDP, el protocolo delta de repositorios RPKI.
No existe una única organización que imponga la adopción. La eficacia de RPKI depende mucho de los efectos de red: cuantos más firman orígenes y validan, mayor es el valor para cada participante.
Ventajas de RPKI para la seguridad del enrutamiento
Evitar secuestros y configuraciones erróneas evidentes
Una gran ventaja es detectar anuncios de origen no autorizados. Si una red anuncia un prefijo sin derechos, los pares que ejecutan ROV pueden marcarlo inválido y descartarlo o darle menor prioridad. Esto reduce el riesgo de secuestros directos.
Incluso muchos errores de enrutamiento proceden de simples configuraciones equivocadas o erratas. RPKI ayuda a mitigarlos.
Contener el radio de impacto
Como el enrutamiento es interdependiente, una red que se comporta mal puede perturbar otras muy lejanas. Al rechazar pronto orígenes inválidos, RPKI ayuda a contener el daño.
Señalar confianza y responsabilidad
Tener ROAs registradas públicamente aporta transparencia. Otros operadores ven qué prefijos están firmados, señal de disciplina operativa y buena higiene de red.
Permitir mejoras futuras y validación de rutas
Aunque RPKI se ocupa hoy principalmente del origen, forma parte de los cimientos de una seguridad más avanzada, incluido BGPsec para validar rutas o extensiones como ASPA (autorización de ruta AS).
A largo plazo, una infraestructura RPKI mundial podría elevar el coste de los secuestros para los atacantes y mejorar la confianza en el enrutamiento entre dominios.
Estado actual de adopción y desafíos Estadísticas y brechas de despliegue
La cobertura de ROAs ha crecido pero sigue siendo parcial. Según mediciones recientes, aproximadamente el 40–50 % de los prefijos IPv4 tienen ROAs válidas y la proporción es parecida o algo mayor en IPv6.
Sin embargo, menos redes aplican activamente ROV en sus routers. Cloudflare, por ejemplo, mantiene datos sobre la adopción de «firma de origen» frente a «validación de origen».
La diferencia entre firma y validación es una brecha crítica: la protección solo funciona cuando participan ambas partes.
Temor operativo: falsos positivos y pérdida de conectividad
Una razón para dudar es el temor a falsos positivos: ROAs mal configuradas pueden marcar anuncios legítimos como inválidos y provocar descartes involuntarios.
Los operadores también temen que rechazar rutas inválidas los desconecte de destinos. Estos riesgos exigen planificación, implantación gradual y políticas de respaldo.
Vulnerabilidades de validadores y repositorios
Investigaciones recientes han descubierto vulnerabilidades en software validador RPKI. Por ejemplo, CUREanalysis halló fallos que permitían envenenar rutas o desactivar la lógica de validación.
Otra clase de ataque, Stalloris, mostró cómo bloquear la obtención de datos del repositorio y obligar a los routers a volver a un funcionamiento inseguro.
Un estudio sistémico de 2024 señaló que el 56 % de los validadores RPKI mundiales sufre al menos una vulnerabilidad documentada.
Un intento de mitigación es el diseño de partes confiantes con seguridad bizantina (BRP), que busca descentralizar la validación y mejorar la resiliencia.
Políticas fragmentadas y aplicación incoherente
La lógica de ROA y validación contiene casos ambiguos o poco especificados en los RFCs, lo que ha provocado conductas divergentes entre implementaciones.
Algunas redes aplican filtrado estricto, otras solo supervisión y otras lo hacen parcialmente según categorías de prefijos.
Como el enrutamiento es mundial, las políticas incoherentes reducen las ventajas de seguridad. Si solo algunos routers descartan inválidas, los anuncios maliciosos aún pueden propagarse por rutas permisivas.
Escalabilidad, automatización y herramientas
Algunos operadores citan la facilidad, la complejidad y la falta de herramientas como obstáculos. Automatizar la gestión de ROA, sincronizar cachés de validadores e integrar plataformas de enrutamiento sigue siendo difícil.
Además, algunos expertos consideran insegura o ineficiente la dependencia de rsync para sincronizar repositorios, lo que genera propuestas de favorecer RRDP.
Algunas redes retrasan la emisión de ROA hasta que la validación esté extendida, perpetuando una adopción lenta.
Buenas prácticas para operadores que despliegan RPKI
Comenzar en modo de supervisión
Despliegue ROV pasivamente, marcando inválidas sin descartarlas. Supervise resultados involuntarios antes de aplicar el bloqueo.Diseño cuidadoso de ROA
Utilice valores conservadores de maxLength. Evite prefijos demasiado amplios o estrictos que invaliden anuncios legítimos.Aplicación gradual y respaldo
Empiece a rechazar rutas inválidas tras observarlas suficientemente y con caminos de respaldo. Endurezca la aplicación poco a poco.Infraestructura robusta de validadores
Utilice varias instancias, software fiable, supervise brechas y considere sistemas resilientes como BRP.Mantener actuales ROA y datos de validación
Sincronice con frecuencia, vigile fallos del repositorio y disponga mitigaciones ante datos obsoletos.Coordinarse con pares y upstreams
Anime a otros participantes de la ruta a validar. La participación de muchas redes refuerza el beneficio.Seguir iniciativas comunitarias como MANRS
Normas como las guías de higiene del enrutamiento complementan la adopción de RPKI.Auditar y actualizar periódicamente
Las ROAs deben revisarse con regularidad. Los cambios de titularidad AS, fusiones o reasignaciones IP exigen actualizaciones.
El dilema del efecto de red y los incentivos
Un gran obstáculo es que el beneficio solo aparece cuando validan muchas redes. Un operador que firma pero cuyos pares no lo hacen está menos protegido; aplicar validación puede romper la conectividad con redes no conformes. Esta tensión frena el despliegue.
Algunos sostienen que la regulación o incentivos sectoriales ayudarían. Otros proponen razones económicas: operadores que ofrezcan «tránsito seguro» podrían cobrar más si aplican ROV. Los proveedores de contenido también pueden exigir cumplimiento de ROV a sus alojadores.
También surgen preocupaciones jurídicas. Un artículo sobre barreras legales señaló que los tribunales rara vez considerarían defectuosos los certificados RPKI si los RIRs cumplen las normas IETF.
Limitaciones esenciales y riesgos residuales
Incluso con validación perfecta del origen, RPKI no evita todos los ataques BGP:
Manipulación de rutas: RPKI no comprueba cada salto AS; los atacantes aún pueden falsificar rutas AS. El BGPsec propuesto aborda esto, pero sigue prácticamente sin implantarse.
Ataques de degradación e interferencia de repositorios: si los atacantes bloquean repositorios RPKI o impiden el acceso del validador, las redes pueden volver a un enrutamiento inseguro.
Software validador vulnerable: como mostraron auditorías recientes de CURE, los errores pueden provocar validaciones incorrectas o envenenamiento de rutas.
Políticas parciales o incoherentes: si partes de Internet no aplican ni firman ROAs, las rutas inválidas pueden atravesar corredores permisivos.
Errores operativos: ROAs mal configuradas o sin actualizar pueden causar daños colaterales.
Por tanto, RPKI es una mejora importante, no una panacea. Su valor completo aparece combinado con filtrado de rutas, higiene entre pares y, finalmente, sistemas de validación de rutas.
El camino por recorrer: qué debe ocurrir
Resiliencia y descentralización de validadores: uso amplio de arquitecturas robustas, por ejemplo BRP, para reducir la dependencia de puntos únicos de fallo.
Mejores herramientas y automatización: mejores interfaces, integración con sistemas de enrutamiento, alertas y herramientas de ciclo de vida de ROA.
Coordinación e incentivos comunitarios: pares, IXPs y operadores firmando acuerdos mutuos o incluso exigiendo cumplimiento de ROV para interconexiones.
Mayor concienciación y formación: muchos ISPs y equipos de red aún desconocen RPKI.
Despliegue de normas complementarias: ASPA, BGPsec y normas relacionadas deben madurar y adoptarse realmente.
Si todo lo anterior converge, el tejido de enrutamiento de Internet se volverá con el tiempo mucho más resistente a secuestros y fugas.
Preguntas frecuentes (FAQ): RPKI y seguridad del enrutamiento
1. ¿Qué significa declarar una ruta «inválida»?
Si un anuncio BGP es inválido según ROV, es decir, no está cubierto por ninguna ROA o el AS de origen no coincide, los routers pueden descartarlo, darle menor prioridad o situarlo en una preferencia inferior.
2. ¿Puede un prefijo tener más de una ROA?
Sí. Pueden existir varias ROAs para un mismo prefijo, quizá con distintos ASes de origen válidos. La lógica de validación debe gestionar cuidadosamente la unión o los conflictos.
3. ¿Garantiza RPKI una seguridad de enrutamiento completa?
No. RPKI solo garantiza el origen, no verifica toda la ruta. Los atacantes aún pueden falsificar rutas AS o causar otras anomalías.
4. ¿Qué sucede si los datos del validador están obsoletos o inaccesibles?
Los routers pueden tratar por defecto los anuncios como desconocidos y permitirlos. Si falla la conectividad, ese mecanismo puede explotarse como vector de degradación.
5. ¿Cómo pueden adoptar RPKI las redes pequeñas o los alojadores de contenido?
Pueden utilizar servicios RPKI alojados de su ISP o RIR upstream. Aunque no ejecuten un validador propio, pueden emitir ROAs y señalar la autorización de origen.
