El 20 de mayo de 2025, un AS de la región de Asia-Pacífico envió un BGP UPDATE que contenía un atributo Prefix-SID corrupto (opcional, transitivo, código de atributo 40). Lo que ocurrió después no fue ni un secuestro ni una fuga de rutas (route leak).
Cisco IOS-XR y Nokia SR-OS hicieron lo que dice la RFC 7606: descartaron el atributo mal formado y listo. El sistema operativo JunOS de Juniper transmitió el mensaje intacto. Los routers Arista que lo recibieron respondieron reiniciando sus sesiones BGP. Los servidores de ruta en varios IXP reenviaron el atributo sin filtrarlo. En diez segundos, el sistema de enrutamiento global registró más de 150.000 actualizaciones y hubo flapping de rutas en Starlink, Disney, Zscaler y ByteDance, entre otros. Arista modificó el comportamiento en EOS 4.28.11 y versiones posteriores.
En ningún punto de la cadena se violó ninguna de las validaciones de RPKI. Si le pedimos a un operador que clasifique el evento, se limitará a encogerse de hombros: no es un secuestro, no es una fuga, es “algo relacionado con un atributo”. Esto refleja la escasa atención que ha recibido este tipo de problema.
Esa brecha fue uno de los puntos de partida de una encuesta que acabamos de publicar en IEEE Communications Surveys & Tutorials y que retoma las preguntas abiertas planteadas en la encuesta sobre seguridad del enrutamiento de Huston, Rossi y Armitage de 2011 y pregunta qué ha cambiado realmente en quince años. Este artículo es sobre la parte de la respuesta que nos sorprendió.
Cuatro macrocategorías
Al final, terminamos con una taxonomía de cuatro macrocategorías y ocho microcategorías. La contribución no es la introducción de nuevos conceptos de ataque —la mayoría de estas distinciones ya existen en las RFC y en la práctica operativa— sino una estructura única con una nomenclatura coherente, de modo que cada clase se pueda mapear sistemáticamente a las defensas que la abordan.
Manipulación de rutas: modificación no autorizada de la información de prefijos o rutas. Secuestro de prefijos (PRH) en sus variantes completo, incompleto, de intercepción y abusivo; manipulación de AS_PATH (ASM), que abarca el envenenamiento, la inyección de origen falsificado, el acortamiento de rutas y la extensión de rutas.
Consistencia del enrutamiento: ataques a la estabilidad de la tabla de enrutamiento, no a su contenido. Volatilidad del estado (VOL): flapping problemático, inundación inducida por oscilaciones, inyección de fluctuación de rutas (churn) amplificada, convergencia demorada. Desagregación de prefijos (DEG): maliciosa, negligente, explotadora e inundación de fragmentos.
Violación de políticas: fugas de enrutamiento (RLK) en las cuatro direcciones definidas en la RFC 7908 y manipulación de políticas (POL) mediante Local Preference, MED, longitud de AS_PATH y propagación selectiva.
Basado en sesiones: restablecimiento de sesiones basado en atributos (ATR): inyección de atributos transitivos opcionales mal formados, explotación de atributos propios del proveedor, abuso de las políticas de manejo de errores. A esta categoría pertenece el evento de mayo de 2025.
Dónde está realmente la cobertura
Aplicar las defensas a esta estructura produce una imagen distorsionada que es fácil pasar por alto cuando se evalúa un mecanismo de forma aislada.
PRH es el caso de éxito, con salvedades. IRR y RPKI proporcionan validación de origen y el espacio cubierto por ROA sigue aumentando. Pero la cobertura no es sinónimo de cumplimiento: un estudio longitudinal realizado en más de 28.000 sistemas autónomos (AS) reveló que el 36,2 % no implementa ROV en absoluto y que solo el 12,3 % logra una protección total. Un maxLength permisivo amplía la superficie de ataque en vez de reducirla, de ahí la RFC 9319. Además, el secuestro abusivo de espacio no anunciado sigue siendo totalmente factible cuando no se mantienen los objetos.
ASM se aborda parcialmente en principio, pero apenas en la práctica. BGPsec existe, está implementado y básicamente no se ha desplegado: un único sistema autónomo que no lo adopte en el camino elimina la información de seguridad, lo que hace que su despliegue parcial sea prácticamente inútil.
RLK es donde se están produciendo los avances más prometedores. Los objetos ASPA se pueden publicar en los repositorios de los RIR desde diciembre de 2025 (al momento de redactar este informe hay 1314 registrados) y los análisis sugieren que su despliegue por parte de sistemas autónomos estratégicamente ubicados podría reducir hasta en un 96 % el número de sistemas autónomos afectados por fugas. El atributo OTC y la comunidad Down Only, ambos basados en las funciones definidas en la RFC 9234, podrían suprimir más del 98 % de las fugas multi-hop si se adoptaran selectivamente en redes Tier 1 y Tier 2 bien conectadas.
VOL, DEG, POL y ATR no tienen ninguna respuesta criptográfica. Ninguna. Se abordan mediante endurecimiento operativo, monitoreo del plano de control, límites a la cantidad de prefijos (max-prefix-limit), filtros de longitud de prefijo, higiene de las políticas, manejo robusto de los errores y filtrado de atributos en los servidores de rutas. Todas estas medidas son locales, reactivas y no verificables para la parte que sufre las consecuencias. No existe un equivalente a “verificar el ROA y descartar las rutas inválidas”, no hay un estado global que cualquiera pueda consultar. Cuando un operador pregunta si está protegido contra una inundación de fragmentos de un peer, la respuesta honesta es: lo que hay es un límite máximo de prefijos y una esperanza.
Por qué las clases que no están cubiertas importan más que antes
Hay dos factores que han modificado el perfil de riesgo.
El primero es la aritmética de IPv6. El abuso de desagregación en IPv4 está limitado por los recursos que el atacante realmente tiene. En IPv6 no es así: dentro de un único /29, se pueden generar y anunciar hasta 524.288 /48 diferentes. Actualmente la tabla BGP global de IPv6 contiene alrededor de 219.000 entradas. Basta con una asignación, un router, para que la tabla se duplique. La protección —un umbral estático para el límite máximo de prefijos— también frena el crecimiento legítimo si es demasiado estricto, que es precisamente la razón por la cual los operadores lo configuran con un margen amplio.
El segundo factor es que el éxito parcial de la validación de origen redistribuye la atención del atacante. A medida que aumenta la implementación de validación de origen, el retorno marginal por secuestrar un prefijo disminuye y el retorno marginal por las clases que nadie valida aumenta. Esto no es una afirmación sobre las intenciones de nadie; es la economía habitual de un control que funciona bien para un aspecto específico.
Las cuatro preguntas que siguen abiertas después de quince años
Repasando las preguntas abiertas de 2011 a la luz de lo anterior, hay cuatro que siguen vigentes:
1. Información de enrutamiento versus estado de reenvío. ¿Puede una parte que confía (relying party) validar no solo que el atributo AS_PATH de un mensaje UPDATE coincida con la ruta que siguió el anuncio, sino también que el estado de reenvío real de la red esté alineado con ella? Todos los mecanismos de validación de rutas, incluidos ASPA y BGPsec, protegen el plano de control pero no dicen nada sobre dónde van realmente los paquetes. Propuestas como FC-BGP y SBAS intentan solucionar este problema y ambas siguen en etapa experimental. Este es el problema más complejo desde el punto de vista técnico que falta resolver en este campo.
2. El problema de un despliegue parcial. Si no se puede desplegar un marco integral, ¿puede uno menos integral ofrecer resultados aceptables? La evidencia dice que sí y también indica que la efectividad depende de las políticas de los operadores: una encuesta de 100 operadores encontró que la validación parcial de rutas ofrece buena protección cuando las políticas prefieren las rutas seguras y una protección mucho menor cuando prefieren las rutas cortas. El despliegue parcial debería ser la premisa de diseño básica para nuevas propuestas, no el caso degradado.
3. Mejorar lo existente. El costo computacional ya no es el principal obstáculo como lo era en 2011, ya que los routers modernos pueden ocuparse del cifrado. En cambio, la complejidad operativa sí lo es. Gestionar los ROA, los registros IRR, las relaciones de ASPA y los certificados es una verdadera carga, desproporcionadamente mayor para las redes más pequeñas con personal limitado. Propuestas como las listas de prefijos firmados, que reemplazan una longitud máxima de prefijo permisiva por la enumeración explícita de los anuncios previstos, son interesantes precisamente porque asumen un poco más de mantenimiento a cambio de mucha menos ambigüedad.
4. Herramientas auxiliares. Dado que la seguridad a nivel de protocolo es incompleta y seguirá siéndolo, el monitoreo y la evaluación de riesgos tienen mayor peso del que sugiere su condición de “complementarias”. ARTEMIS, ROSE-T, los sistemas de detección de cambios de origen y la puntuación de riesgo derivada de las tablas de enrutamiento de los IXP aportan valor sin necesidad de modificar el BGP ni de coordinar entre sistemas autónomos. Sin embargo, su eficacia depende totalmente de la calidad de los registros IRR, los repositorios RPKI y los datos de relaciones entre sistemas autónomos, cuyo mantenimiento no es consistente. Mejorar estos conjuntos de datos es un requisito indispensable para todo lo demás.
Lo que nos han enseñado los últimos quince años
Hay tres observaciones que son transversales a todo esto y que creemos que vale la pena discutir:
Desplegable siempre es mejor que óptimo. Aunque S-BGP, soBGP y psBGP ofrecían garantías más sólidas que cualquier sistema implementado en la actualidad, no prosperaron. RPKI, IRR y ahora ASPA ganaron terreno porque pueden adoptarse de forma incremental. En el enrutamiento entre dominios, “suficientemente bueno y desplegable” es siempre la opción ganadora.
La adopción universal no es una hipótesis realista y los diseños que la requieren no tienen un buen historial.
Los costos son individuales y los beneficios colectivos, que es el clásico problema de la acción colectiva y el motivo por el cual los mecanismos bien diseñados se estancan. Aquí es donde las acciones institucionales como NIS2, la propuesta de Ley de Redes Digitales y las estrategias nacionales importan. Sin embargo, su eficacia depende de la aplicación y el monitoreo del cumplimiento, que siguen siendo desiguales en las diferentes jurisdicciones.
Una invitación a discrepar
El aspecto que menos confianza nos genera es la distinción entre ataque y accidente. Para casi todos los incidentes en las cuatro categorías descubiertas existe una explicación inocente: una redistribución mal configurada, un script que se ejecutó dos veces, un bug del proveedor. Esta ambigüedad es precisamente la razón por la que estas clases están poco estudiadas: es difícil construir un modelo de amenazas a partir de eventos que no se pueden atribuir. También podría significar que estamos exagerando el riesgo.
Preferimos que los administradores de redes nos corrijan al respecto antes que tener razón en una revista especializada. Si su experiencia operativa indica que el límite máximo de prefijos es adecuado o que ahora hay suficiente cumplimiento de la RFC 7606, esa es la conversación que esperamos iniciar.
“Survey on Internet Routing Security: Stakeholder Interests, Current and Future Research Directions” está disponible bajo la licencia CC BY 4.0 en IEEE Communications Surveys & Tutorials — DOI: 10.1109/COMST.2026.3714569. El trabajo es una colaboración entre la Universidad Sapienza de Roma, Namex (IXP de Roma) y la Agencia Nacional Italiana de Ciberseguridad (ACN).
