RPKI no impide que te secuestren la ruta: firmar el origen no asegura el camino

Esta tarde, el observatorio público de enrutado de Cloudflare veía 1.445.943 rutas en la tabla global de BGP. De ellas, 1.016.683 —el 70,31%— llevaban firma RPKI válida. Y 15.300 estaban cubiertas por una firma que decía justo lo contrario: inválidas, y ahí seguían, visibles desde 79 puntos de observación. Ese número pequeño resume el estado real del enrutado mejor que cualquier porcentaje de adopción: firmar es fácil, validar es otra cosa, y ninguna de las dos frena el secuestro que de verdad se utiliza.

Escribimos esto desde el lado del que sesiona BGP a diario: operamos red propia con tránsito y peering, y publicamos un looking glass abierto en lg.everywan.com precisamente para que cualquiera pueda mirar qué vemos y qué anunciamos. Con esa perspectiva, la frase que más se oye en las reuniones —«tranquilo, ya tenemos RPKI»— no es mentira, pero está incompleta de una forma peligrosa. Un ROA firma quién puede originar un prefijo. No firma por dónde viaja el tráfico, ni quién tenía derecho a pasártelo.

Qué dice un ROA exactamente (y qué se calla)

Un ROA es una afirmación firmada con tres campos: este prefijo, este número de sistema autónomo como origen, y hasta esta longitud. El router compara el anuncio con la firma y le pone una etiqueta —válido, inválido o no encontrado— según el RFC 6811. Lo que decida hacer con esa etiqueta ya es política local, y ahí empiezan los problemas. Tres cosas que un ROA no cubre y conviene tener presentes:

El secuestro que pasa la validación en verde

Aquí está el punto que rompe la tranquilidad. Un atacante que quiere tu prefijo no pelea contra tu ROA: lo copia. Anuncia tu prefijo poniendo tu número de sistema autónomo en la posición de origen y colocando el suyo delante, como si fuera el vecino que te da tránsito. El router que recibe eso hace su validación de origen, comprueba el origen del AS_PATH contra tu ROA, y le sale válido. El semáforo se pone verde para un anuncio que no has hecho tú. Cuánto tráfico se lleva ya no depende de la criptografía sino de la geografía del asunto: se queda con el de las redes para las que su camino resulte preferible, o con el de todas si además anuncia un prefijo más específico que el tuyo.

¿Y la pieza que firmaría el camino entero? Existe sobre el papel —BGPsec— y sigue sin desplegarse, por un motivo que resume bien el análisis publicado en RIPE Labs el 21 de julio de 2026: basta con que un solo sistema del camino no lo implemente para que la información de seguridad desaparezca. Una cadena que necesita que todos los eslabones existan, en una red de más de cien mil actores independientes, es una cadena que no se cierra. Mientras tanto, el ataque cuesta lo que cuesta una línea de configuración en un router.

El contador de hoy, con su letra pequeña

Consultamos la API pública de Cloudflare Radar mientras escribíamos esto, y los contadores no dejan mucho margen a la interpretación: 3.188 eventos de conflicto de origen —lo que Radar etiqueta como secuestro— en los últimos 30 días, y 6.537 fugas de ruta en el mismo periodo. En las últimas 24 horas, 88 y 515 respectivamente. A eso se suman 413.960 rutas sin ROA, el 28,6% de la tabla: ni válidas ni inválidas, sencillamente sin firmar. Casi un tercio de internet no ha llegado todavía al punto de partida.

Y ahora el matiz, que es la mitad del valor de cualquier número: la mayoría de esos eventos no son ataques. Son detecciones automáticas de conflictos de origen y de anuncios que van donde no deben, y detrás de casi todos hay un dedo gordo, una desagregación mal pensada, un filtro que no estaba o un laboratorio que se escapó a producción. Quien lo lea como «hay más de tres mil ciberataques al mes contra el enrutado» está exagerando. Pero el consuelo dura poco, porque la lectura correcta incomoda igual: si un error de configuración de un desconocido puede desviar tráfico ajeno hasta que alguien se da cuenta, quien lo haga a propósito consigue lo mismo con menos ruido. La diferencia entre el accidente y el ataque es la intención, no la dificultad.

Las cuatro familias que nadie está validando

El trabajo de RIPE Labs que citábamos ordena los ataques al enrutado en cuatro grandes categorías. Vale la pena leerlas seguidas, porque enseñan de un vistazo dónde llega la criptografía y dónde no:

Y el dato que ordena todo lo anterior, del mismo análisis, medido en un estudio longitudinal sobre más de 28.000 sistemas autónomos: el 36,2% no implementa validación de origen en absoluto, y solo el 12,3% consigue protección completa en sus rutas. Léelo junto al 70,31% de rutas firmadas del principio y verás la brecha: la comunidad ha firmado siete de cada diez rutas y valida del todo poco más de una de cada diez redes. Firmar es un trámite administrativo que se hace una vez en el panel del RIR. Validar es tocar la configuración de todos tus routers y asumir que, si te equivocas, tú mismo te quedas sin ver medio internet. Por eso una cifra sube y la otra no.

La lista con la que revisamos una red

No hay bala de plata, hay siete cosas aburridas que hacen casi todo el trabajo. Este es el criterio con el que revisamos una red y lo que le pedimos a un tránsito antes de firmar nada:

Lo caro no es ninguna de las siete: lo caro es que nadie tenga el encargo de revisarlas cada trimestre, que es donde se pudren. Y el patrón de fondo es el mismo que ya contamos con los ataques de denegación de servicio: la caja del rack no salva tu enlace porque el problema ocurre aguas arriba, fuera de tu perímetro. Con el enrutado pasa igual: lo que decide si te secuestran no está en tu firewall, está en la política de los vecinos de tus vecinos.

Si no tienes AS propio (que es lo normal)

La inmensa mayoría de las empresas no habla BGP con nadie, y no le hace ninguna falta. Su palanca no es técnica: es la conversación con quien le da la conectividad. Hay una pregunta que vale por todas las demás y se contesta en un correo: «¿descartáis las rutas RPKI inválidas o solo las marcáis?». Si la respuesta es que las marcan y las aceptan igual, ya sabes lo que hay; y si es que las descartan, se puede comprobar desde fuera. La segunda, para quien tenga direcciones independientes del proveedor, es igual de incómoda: ¿quién mantiene ese ROA, con qué longitud máxima, y quién lo revisa el día que cambies de operador? Ese objeto sobrevive a los contratos, y hemos visto demasiadas firmas apuntando a un sistema autónomo que ya no da servicio a nadie.

ASPA: la pieza que falta, y su matiz honesto

La respuesta que se está construyendo para lo que RPKI no cubre se llama ASPA: cada titular de un sistema autónomo declara, firmado, quiénes son sus proveedores. Con esa información, un camino que pasa por donde no debería pasar deja de ser una sospecha y pasa a ser comprobable. Los objetos son publicables en los repositorios de los registros regionales desde diciembre de 2025, y el análisis de RIPE Labs estima que un despliegue en sistemas estratégicamente situados podría reducir hasta un 96% el número de sistemas autónomos afectados por las fugas —que no es lo mismo que reducir las fugas—.

Y ahora la parte que no sale en las presentaciones: ese mismo análisis contaba 1.314 objetos ASPA registrados. No son cifras directamente comparables —una cuenta objetos publicados en los repositorios y la otra sistemas vistos anunciando—, pero puestas al lado sale el orden de magnitud del asunto: 1.314 frente a los 116.353 orígenes distintos que Radar veía hoy en la tabla global. Es la dirección correcta, es barato de publicar y merece la pena hacerlo. Pero si alguien te vende hoy que ASPA te protege, te está vendiendo un despliegue que todavía no existe. Publica el tuyo por lo que suma al conjunto, no porque vayas a dormir mejor esta noche.

El último mito: que esto va contigo

Hay un mito simétrico al del principio, y también conviene desmontarlo: el de que, después de leer todo esto, hay que salir corriendo a montar algo. Si tus direcciones te las da el operador, si no tienes sistema autónomo y si tu conectividad es una fibra con un router del proveedor, nada de esto es una tarea tuya. No montes un validador ni pidas un AS «por seguridad»: tu palanca es la conversación de arriba y el contrato. Y si tienes un /24 y un número de sistema autónomo porque un día pareció buena idea, pero un solo tránsito y nadie que mire la tabla, tu riesgo real no es el secuestro sofisticado: es que el día que pase algo no habrá nadie de guardia que sepa dónde mirar. Eso también hay que decirlo.

Lo que sí puedes hacer

El enrutado de internet funciona porque decenas de miles de desconocidos se creen lo que se dicen entre ellos. RPKI no cambia eso: solo ha convertido una parte de esa confianza en algo comprobable. Es mucho y es poco a la vez. Firmar tus prefijos con criterio, descartar de verdad lo inválido, filtrar a tus vecinos y mirar por dónde va el tráfico no impide el ataque, pero acorta muchísimo el rato en que nadie se entera. Y en enrutado, ese rato es todo lo que hay.

Si quieres que miremos cómo está tu conectividad —qué se anuncia en tu nombre, qué filtra tu proveedor y qué pasaría un domingo—, eso es parte de lo que hacemos en redes y comunicaciones.

Fuentes (verificadas): las cifras de la tabla global de BGP y de eventos proceden de la API pública de Cloudflare Radar, consultada por nosotros el 6 de agosto de 2026 a las 15:30 UTC (79 puntos de observación): 1.445.943 rutas, 1.016.683 válidas (70,31%), 413.960 sin ROA (28,6%), 15.300 inválidas, 116.353 orígenes distintos; 3.188 eventos de secuestro y 6.537 fugas de ruta en 30 días, y 88 y 515 respectivamente en 24 horas. Son contadores vivos: se mueven entre consultas, así que las cifras valen para el momento en que las tomamos, no para siempre. Además, los eventos que Radar etiqueta como secuestro son detecciones automáticas de conflictos de origen: incluyen errores de configuración y no equivalen a ataques confirmados, y así lo hemos escrito en el post. El reparto de ataques en cuatro familias, las cifras de validación de origen (36,2% de sistemas sin ROV y 12,3% con protección completa, medidas en un estudio longitudinal sobre más de 28.000 sistemas autónomos), el estado de BGPsec, la publicabilidad de ASPA desde diciembre de 2025, los 1.314 objetos registrados y la estimación de reducción del número de sistemas afectados por fugas proceden del análisis de Antonio Prado publicado en RIPE Labs el 21 de julio de 2026. Los estándares citados son el RFC 6811 (validación de origen de prefijos BGP), el RFC 7908 (definición y clasificación de las fugas de ruta, que describe seis tipos), el RFC 9319 / BCP 185 (uso de maxLength en la RPKI, octubre de 2022) y el RFC 9234 (prevención y detección de fugas mediante roles). Fotografía de la imagen social: vista aérea del enlace entre las autopistas 401, 403 y 410 de Ontario, de Coolcaesar, Wikimedia Commons, licencia CC BY 4.0.