Inestabilidad en el enrutamiento de Internet por un bug en el procesamiento de BGP

• Un bug en el procesamiento de mensajes BGP provocó el 20 de mayo de 2025 una gran inestabilidad de enrutamiento y, en algunas redes, cortes de conectividad a Internet
• La causa fue un BGP Prefix-SID Attribute malformado, que desencadenó reacciones excepcionales en implementaciones BGP importantes, especialmente JunOS y Arista EOS
• Algunos carriers de tránsito, incluidos Hutchison y Starcloud, retransmitieron el mensaje causante y ampliaron el impacto
• El incidente provocó reseteos masivos de sesiones BGP e inestabilidad en más de unas 100 redes
• Lo ocurrido puso en evidencia lagunas en el manejo tolerante a errores de BGP según el proveedor y la necesidad de mejorarlo

---

27 de mayo de 2025

Inestabilidad global en el enrutamiento de Internet por un bug en el procesamiento de BGP

El martes 20 de mayo de 2025 a las 7:00 (UTC), se propagó un mensaje BGP que provocó comportamientos inesperados en dos implementaciones BGP importantes que se usan con frecuencia para manejar tráfico de Internet

Como resultado, múltiples “sesiones BGP de conectividad a Internet” se cerraron automáticamente, causando desde una inestabilidad de enrutamiento mínima hasta, en el peor caso, una interrupción de conectividad temporal en algunas redes

El mensaje BGP problemático

• El análisis de sesiones recopiladas por bgp.tools muestra que el mensaje BGP Update que causó este fenómeno parecía normal, pero contenía un BGP Prefix-SID Attribute dañado con datos internos rellenados con 0x00
• La mayoría de las implementaciones BGP (IOS-XR, Nokia SR-OS) lo filtran correctamente de acuerdo con RFC7606 (tolerancia a errores en BGP), pero el problema surgió en la interacción entre JunOS y Arista EOS
  • JunOS conserva y reenvía el mensaje dañado, y Arista EOS restablece la sesión BGP al recibirlo
• En entornos donde se usa mucho hardware de Juniper (JunOS), si está conectado a Arista EOS, puede haber interrupciones de acceso a Internet de hasta unos 10 minutos

Quién emitió el mensaje problemático

• El análisis del archivo de bgp.tools para ese período muestra que hubo varios orígenes AS involucrados

• Esto sugiere que no fue la red que generó el prefijo, sino un carrier de tránsito en el camino el que añadió el Attribute incorrecto

• Los principales AS vinculados al problema son los siguientes

  • AS9304 (Hutchison Global Communications Limited)
  • AS135338 (Starcloud Information Limited)
  • AS151326 (DCConnect Communication Pte. Ltd.)
  • AS138077 (PT Abhinawa Sumberdaya Asia)

• Según los datos de bgp.tools, es muy probable que quien realmente añadió el Attribute haya sido Starcloud (AS135338) o Hutchison (AS9304)

• Algunos prefijos representativos a los que se propagó ese Attribute son 156.230.0.0/16 y 138.113.116.0/24

• Hutchison/AS9304 está conectado a múltiples Internet Exchange (IX), y el mensaje también se propagó a route servers usados por bird

• Como Bird no soporta BGP SID, envió el mensaje a numerosos IX sin filtrarlo, amplificando el caos a nivel de red

¿Qué es BGP Prefix-SID?

• El BGP Prefix-SID Attribute normalmente solo debería usarse en sesiones BGP internas, y se utiliza para definir la ruta hacia un destino dentro de una misma red (RFC8669)
• La razón por la que ese Attribute se filtró a la tabla de enrutamiento global podría ser que una sesión BGP externa estuviera configurada como si fuera una sesión interna

Redes afectadas

• Es difícil identificar con precisión a las víctimas, pero se confirmó el problema en alrededor de 100 redes que mostraron una enorme variación (churn) tras el mensaje BGP inicial
• Normalmente, el route collector de bgp.tools recopila entre 20 mil y 30 mil mensajes por segundo, pero en el momento del incidente registró más de 150 mil en promedio cada 10 segundos
• Esa cifra es una señal de que hubo una interrupción grave en rutas de Internet de gran alcance

Responsabilidad de los vendors e implicaciones

• Aunque la causa raíz no está totalmente clara, el hecho de que un mensaje erróneo se haya propagado a escala de Internet demuestra que el problema existente en el manejo de errores de BGP es un riesgo real
• Otros vendors filtraron el Attribute problemático, pero Juniper lo permitió de forma indirecta y lo pasó a equipos Arista, provocando reseteos de sesión por deficiencias en el código de tolerancia a errores de BGP
• La documentación oficial de JunOS también indica que “no inspecciona el mensaje completo”
• Con este diseño, JunOS evita el riesgo de un reseteo remoto de sesión, pero sigue existiendo la posibilidad de reenviar mensajes problemáticos a otros peers o clientes

Conclusión

• Este incidente fue breve, pero sugiere que podría volverse más grave si la escala aumenta

• A medida que los servicios dependen cada vez más de IP, el impacto de una falla de Internet puede ir más allá de que un consumidor no pueda acceder a su correo y extenderse a fallas en transmisiones de TV o llamadas fallidas a servicios de emergencia

• Dado que esto podría derivar de forma realista incluso en pérdidas de vidas humanas, se subraya la necesidad de que cada vendor implemente una tolerancia a errores de BGP sólida

• Se indica la posibilidad de participación de operadores de red que quieran colaborar con el análisis de datos de bgp.tools (enlace provisto)

[GN⁺]

Comentarios de Hacker News

• En general, el principio de "ser liberal al recibir y estricto al enviar" se considera el enfoque estándar

  • Existen opciones como descartar o filtrar mensajes rotos (drop, filtro), ignorar solo el atributo y reenviar (break), o cortar la conexión por completo (como Arista)

  • Yo consideraba que la cuarta opción (la forma de Arista) era un comportamiento realmente difícil de aceptar

  • La tercera (Juniper) tampoco me parece deseable, pero no diría que sea un problema fatal

  • Edit: al releerlo, vi que Arista no era la cuarta sino la segunda (terminación de conexión)

  • Básicamente trató la conexión como inválida y la cerró; pensando en la experiencia del usuario, no parece una gran decisión, pero da la impresión de que es aceptable

  • Ya existe el RFC 7606 (manejo mejorado de errores para mensajes BGP UPDATE), donde se especifica con detalle cómo tratar mensajes rotos

    • El método más común es treat-as-withdraw (tratarlo como si la ruta hubiera sido retirada)
    • Si simplemente ignoras el mensaje roto, puede quedar preservado un estado previo que en realidad ya no es válido

  • El principio de "ser liberal al recibir y estricto al enviar" es precisamente lo que se conoce como el "robustness principle" o la "ley de Postel"

    • Es una idea que viene de los primeros años de Internet en los 80 y 90
    • Pero hoy la industria reconoce ampliamente que era una forma equivocada de pensar
    • Ese principio provocó rigidez en los protocolos e incontables problemas de seguridad

  • Aprovechando características del funcionamiento de BGP, hubo varios problemas en toda la red por el hecho de que los equipos locales podían reenviar atributos que no conocían

    • Ahora estamos viendo en la práctica las desventajas de esa "función"

  • El autor también señala este punto en el artículo relacionado

    • Esa "función" parece una idea sorprendentemente mala, porque hace que el sistema reenvíe sin criterio datos que no entiende
    • Pero gracias a esa función, nuevas capacidades como Large Communities pudieron difundirse rápidamente, y eso permitió introducir nuevas funciones de BGP

  • Yo no estoy de acuerdo con ese enfoque

    • Me parece mucho mejor ser estricto y específico tanto con lo que se acepta como con lo que se envía

• Todavía recuerdo lo frenético que fue parchear por toda la red el bug CVE-2023-4481

  • Este tipo de bug seguirá siendo una verdadera pesadilla de manejar
  • Me preocupa que, por la naturaleza del diseño y la implementación de BGP, corregir estos comportamientos tome muchísimo tiempo

• En el pasado trabajé desarrollando funciones de BGP en un fabricante de equipos de telecomunicaciones (ya hace bastante tiempo de eso)

  • Sigo pensando que BGP es demasiado complejo

  • La gente sigue agregando nuevas funciones, y los vendors siguen implementándolas conforme a estándares o borradores

  • Como BGP parece que nunca va a desaparecer, da la sensación de que estos bugs van a seguir reapareciendo sin parar

    • Antes, operadores como AT&T y vendors como Juniper o Cisco también empujaban BGP para funciones relacionadas con MPLS y VPN, y eso llevó al sistema a una complejidad profunda
      • Era excesivamente complejo, pero algunos ganaron mucho dinero con eso

• HGC Global Communications Limited (antes Hutchison Global Communications Limited, abreviado HGC) es un proveedor de servicios de Internet de Hong Kong

  • Ver esta página de Wikipedia

• Da la impresión de que BGP sería mucho más estable si los distintos vendors de hardware alinearan mejor los estándares en estos temas

  • Me pregunto si el problema real es que cada vendor evita la estandarización para mantener atados a sus clientes (lock-in)
  • Aclaro que mi entendimiento de BGP es bastante superficial

• No sé si solo me pasa a mí, pero nunca había oído hablar de BGP hasta que escuché que había causado algún problema

  • Es un protocolo esencial para Internet, igual que TCP/IP, pero mientras que TCP/IP se enseña mucho en la escuela, en la carrera o en libros, yo nunca vi BGP
  • En casa uno puede practicar y aprender con TCP/IP, pero no tengo idea de cómo se podría "jugar en casa" con BGP

    • Me interesa saber si hay alguna forma de practicar BGP en casa

    • Puedes hacerlo comprando un router real con implementación de BGP (entre los económicos, algo como Mikrotik), o usando una implementación open source

      • Ahí están bird, que aparece en el artículo, y el muy popular FRR (Free Range Routing)
      • Puedes levantar dos contenedores Docker, establecer una sesión BGP y propagar rutas estáticas, por ejemplo
      • Si quieres un tutorial, esta guía está muy bien organizada para seguirla con software gratuito

    • DN42 es un patio de juegos para practicar tecnologías de enrutamiento

      • Pero requiere invertir tiempo, así que no es algo para intentar de forma ligera
      • Yo también trabajo bastante con networking, pero el enrutamiento WAN todavía me confunde
      • GNS3 es probablemente la forma más fácil de practicar directamente cualquier tecnología de networking
      • Wiki de DN42

    • En mi curso universitario de redes no vimos BGP, pero en una clase de posgrado sí lo estudiamos

      • Usábamos un paquete de Python con el que se podían simular varios AS, aunque no recuerdo el nombre exacto

    • En la clase de redes de licenciatura que yo llevé, BGP apenas se mencionó de pasada en el pizarrón

      • Para practicar BGP se puede usar un simulador de red, como hizo el autor
      • En nuestra clase usábamos un simulador llamado gini, que había hecho un estudiante de posgrado del profesor
      • El gns3 que usó el autor se siente como una especie de ns3 especializado en Cisco
      • ns3 me pareció difícil porque había demasiado que aprender
      • gini tiene una interfaz más sencilla, aunque con menor rendimiento
      • Información del proyecto gini
      • Documentación oficial de gns3

    • Da la impresión de que solo puedes realmente "practicar" BGP si administras una red grande conectada al tráfico real de Internet

      • En casa, lo único que puedes tocar es usar simuladores de red

• En el pasado, varios vendors también tuvieron bugs parecidos al del artículo

  • Información relacionada sobre la vulnerabilidad
  • CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS), etc.
  • Arista fue uno de los vendors no afectados en ese momento

• También hemos recibido paquetes similares en nuestros equipos de chasis IOS XR

  • Al mismo tiempo, hubo muchas anunciaciones de rutas BGP

  • No sé exactamente cuál era el equipo upstream

  • Me hace preguntarme si el protocolo BGP realmente se prueba bien con fuzzing

  • Tal vez, al ser un protocolo tan importante, nadie se atreve a provocar fallas a propósito

  • Escribir un fuzzer para BGP sería fácil, pero diagnosticar los crashes podría ser muy difícil

    • (autor de la publicación)
      • Sí, justo eso fue lo que hice realmente en mi post
      • Post relacionado

• Esto hace preguntarse si ha existido otro sistema tan vasto y cargado de complejidad accidental como el backbone de Internet

• Me sorprende que, dado el impacto potencial de este tipo de bug, no exista un consorcio que opere algo como una suite de pruebas de interoperabilidad

  • O quizá sí exista y simplemente este problema quedó fuera del alcance de las pruebas
  • Parecería obvio generar automáticamente todo tipo de errores de paquetes y crear una gran variedad de casos de prueba con fuzzers o máquinas para aumentar la cobertura
  • Aunque el tiempo de ejecución fuera de varios días
  • El autor del artículo de hecho creó y usó un fuzzer, y encontró problemas similares varias veces
  • Me resulta llamativo que los vendors no pongan más atención a investigaciones tan importantes