¿Quién está realmente ejecutando todos esos pequeños servidores RPKI?

Por qué importan los pequeños servidores RPKI

Border Gateway Protocol (BGP) aún se distribuye sin confianza integrada, lo que deja el enrutamiento expuesto a secuestros de prefijos accidentales o maliciosos. Resource Public Key Infrastructure (RPKI) pretende solucionar eso permitiendo que los titulares de direcciones IP publiquen Route Origin Authorizations (ROA) que dicen: el prefijo X puede ser originado por el ASN Y, anclado en una cadena de confianza en los cinco Regional Internet Registries (RIRs).

La mayoría de los ROA provienen directamente de ARIN, RIPE NCC, APNIC, LACNIC y AFRINIC. Pero también existe una larga cola de pequeños servidores de publicación operados de forma independiente por proveedores cloud, ISP, aficionados, instituciones educativas y vendedores de RPKI como servicio (RPKIaaS). La publicación de APNIC profundiza en quién opera estos pequeños servidores, qué publican y dónde sus configuraciones se vuelven peligrosas.

Definir “pequeño” en RPKI

El estudio clasifica un servidor de publicación como pequeño si anuncia menos de 1.300 ROAs. Ese umbral se eligió a partir de la función de distribución acumulada empírica de recuentos de ROA a través de todos los servidores RPKI conocidos, que muestra una distribución fuertemente sesgada.

Un puñado de grandes proveedores —los cinco RIRs más Amazon Web Services (AWS)— dominan el volumen de ROA. El corte de 1.300 ROA aísla a todos los demás. Una excepción: los servidores RRDP de AWS RPKI se excluyen por completo porque su arquitectura de publicación es tan inusual que los autores la tratan como fuera de alcance por ahora.

Recomendado

El laboratorio de Mira Murati presenta Inkling, un modelo abierto de 975 000 millones de p

¿Por qué ejecutar tu propio servidor RPKI?

Los RIRs ya proporcionan publicación como parte de la membresía, sin embargo muchas redes siguen operando su propia infraestructura. Según la publicación, las razones incluyen:

• RPKIaaS: RPKI gestionado con una API REST uniforme para que los clientes puedan automatizar la gestión de recursos sin manejar múltiples portales de RIR.
• Simplicidad entre RIRs: Una única interfaz para organizaciones que tienen espacio de varios RIRs (por ejemplo, ARIN y RIPE) en lugar de cuentas separadas.
• Investigación y educación: Implementaciones académicas y de aficionados de Krill (el software CA de NLnet Labs) para experimentación y medición.
• Control operativo: Control estricto sobre el firmado, los horarios de publicación y la infraestructura para redes con necesidades de seguridad o enrutamiento personalizadas.
• Diversión / aprendizaje: Configuraciones personales que existen simplemente para entender mejor el enrutamiento en Internet.

El conjunto de datos: qué publican realmente estos servidores

Usando la API de Routinator (versión 0.15.1), los autores obtuvieron todos los ROA de cada servidor que calificó el 23 de abril de 2026. El conjunto de datos resultante cubre:

• 2.467 ROAs únicos
• 3.778 prefijos
• 1.163 ASes únicos

Estadísticas clave informadas:

• Prefijos IPv4 con cobertura ROA: 1.409, cubriendo ~698.000 direcciones individuales
• Prefijos IPv6 con cobertura ROA: 2.369 (rango de direcciones descrito como “astronómico”)
• Fracción de Internet en IPv4: 0,0162%
• Total de objetos ROA analizados: 3.778, a través de 1.163 ASes únicos
• Objetos ROA válidos: 3.444 (91%)
• Objetos ROA inválidos: 48 (1,2%)
• Desconocidos: 286 (7,6%), excluidos del análisis posterior
• ROAs que usan maxLength: 53,98%
• ROAs con maxLength sin cobertura BGP: 19,6%, marcados como potencialmente en riesgo de secuestro por subprefijo

El espacio de direcciones cubierto es pequeño en términos absolutos pero no trivial. El conjunto incluye prefijos que alojan servicios gubernamentales como gov.ai, el dominio oficial del Gobierno de Anguila. La falla de estos pequeños servidores no derribaría Internet, pero podría dejar partes de él sin verificación para algunos usuarios.

Ninguno de los ROAs desconocidos tenía un anuncio BGP activo, lo cual es alentador: si lo tuvieran, los prefijos afectados quedarían totalmente abiertos a secuestros.

Dentro de los servidores: casos llamativos y rarezas

La Tabla 3 en la publicación condensa estadísticas por servidor: recuentos de prefijos, validez, uso de maxLength, alcanzabilidad BGP y solapamiento con la lista de bloqueo de Firehol (Firehol agrega diversas listas de abuso en una sola lista de bloqueo).

r.magellan.ipxo.com — el mayor servidor “pequeño”

Con 776 prefijos, todos IPv4 y todos alcanzables por BGP, r.magellan.ipxo.com (operado por IPXO) es el servidor más grande del conjunto de datos. 103 de esos prefijos están marcados en riesgo debido a amplias configuraciones de maxLength sin cobertura BGP completa en todo el rango autorizado.

repo.rpki.space — señales de infraestructura de spam

repo.rpki.space tiene 8 coincidencias de nivel 1 con Firehol de solo 79 prefijos, una proporción conspicuamente alta. Los datos DNS de BGP Tools muestran un conjunto denso de dominios de mailing, lo que sugiere fuertemente infraestructura de spam.

Una motivación plausible destacada por los autores: los RIRs mantienen procedimientos activos de abuso, y un servidor de publicación independiente introduce un paso operativo extra en cualquier retiro, añadiendo fricción para los denunciantes de abuso.

ca.nat.moe — 99 desconocidos

ca.nat.moe es un caso atípico donde los 99 ROAs tienen validez desconocida, lo que significa que todos fallaron la validación criptográfica. La publicación señala que, de los objetos válidos, el 100% son alcanzables por BGP y 64 usan maxLength.

rpki-01.pdxnet.uk — maxLength al límite

rpki-01.pdxnet.uk anuncia casi la mitad de sus prefijos con maxLength establecido a /32 para IPv4 o /128 para IPv6 — el máximo absoluto. Eso autoriza formalmente cada dirección en el bloque.

En la práctica esto no es explotable porque BGP rechaza prefijos más específicos que /24 (IPv4) o /48 (IPv6) y los prefijos base ya están en esos límites. Aun así, la configuración es muy inusual y su justificación sigue siendo poco clara.

De dónde proviene el espacio IP

Los autores también analizan a qué RIRs pertenecen los prefijos anunciados. Una suposición natural es que la publicación autoalojada está impulsada por asignaciones entre RIRs, pero los datos son mixtos.

En la vista condensada de 18 servidores, muchos publican prefijos de un solo RIR, principalmente RIPE. Para esos servidores exclusivos de RIPE, uno de los argumentos más convincentes para un servidor personalizado —no tener que gestionar varias cuentas de RIR— no se aplica.

El problema de maxLength

Más de la mitad de todos los ROAs en el conjunto de datos (53,98%) usan el parámetro maxLength para autorizar prefijos más específicos que el prefijo base del ROA, una práctica explícitamente desaconsejada por RFC 9319.

Ejemplo de la publicación: un ROA para 103.0.0.0/22 con maxLength /24 autoriza cada /23 y /24 en ese bloque (103.0.0.0/24 hasta 103.0.3.0/24) sin ROAs separados. Debido a que BGP selecciona el prefijo coincidente más específico, un atacante que controle el ASN autorizado podría (en principio) anunciar un subprefijo como 103.0.0.0/24 y ser visto como válido, si no hay un anuncio competidor más rápido y el anuncio es RPKI válido.

El estudio encuentra que ~80% de estos ROAs amplios con maxLength ya tienen sus subprefijos cubiertos por anuncios BGP reales, limitando la exposición práctica. El 19,6% restante no tiene cobertura BGP para los subprefijos autorizados y se marca como potencialmente en riesgo: un ASN legítimo podría ser abusado para originar un secuestro de subprefijo que parezca válido.

La solución recomendada es directa: crear un ROA separado por cada prefijo realmente anunciado y establecer maxLength igual a la longitud del prefijo. La contrapartida es un conjunto de ROAs más grande, deshaciendo los ahorros de agregación que maxLength pretendía proporcionar.

BGPsec: estandarizado, pero aún no usado

La publicación también comprueba el despliegue de BGPsec, que verifica que cada AS en un camino BGP ha firmado criptográficamente su conformidad. Aunque BGPsec se estandarizó en 2017, los autores encuentran que está efectivamente sin uso —no solo en este conjunto de datos, sino en general— con solo un único AS anunciando sus claves de enrutamiento.

Esto coincide con observaciones reportadas por Lisa Bruder en su entrada de blog “BGPsec – Could you run it if you wanted to?”.

Perspectiva del operador

Los investigadores contactaron a uno de los operadores más grandes, Axivora (que ejecuta rpki.cc, krill.accuristechnologies.ca y rpki.folf.systems), para entender por qué mantienen su propio servidor de notificaciones RRDP. La publicación termina observando que recibieron una respuesta, y luego se queda en suspenso antes de publicar lo que Axivora dijo.