La inestabilidad del enrutamiento de Internet fue provocada por un bug en el procesamiento de BGP

 (blog.benjojo.co.uk)
1 puntos por GN⁺ 2025-05-29 | 1 comentarios | Compartir por WhatsApp
  • Un mensaje BGP dañado propagado el 20 de mayo de 2025 a las 07:00 UTC provocó un comportamiento inesperado en dos implementaciones principales, lo que reinició múltiples sesiones BGP de conectividad a Internet y causó inestabilidad de enrutamiento o breves pérdidas de conexión en algunas redes
  • La actualización problemática incluía un BGP Prefix-SID Attribute que normalmente no se espera en actualizaciones BGP de Internet, y estaba dañado con todos sus datos internos en 0x00
  • IOS-XR y Nokia SR-OS, con tolerancia a errores basada en RFC7606, lo filtraron correctamente, pero JunOS lo retransmitió y Arista EOS reinició la sesión, lo que pudo afectar a usuarios de Arista conectados a carriers de tránsito basados en JunOS
  • En las observaciones de bgp.tools, AS9304, AS135338, AS151326 y AS138077 aparecieron repetidamente, y es muy probable que quien añadió el atributo defectuoso haya sido Starcloud AS135338 o Hutchison AS9304
  • Durante el incidente, la tasa promedio de mensajes en 10 segundos del route collector de bgp.tools saltó de los habituales 20,000~30,000 por segundo a más de 150,000/s, mostrando que las diferencias en el manejo de errores BGP pueden sacudir la estabilidad real de las rutas en Internet

Incidente de actualización BGP del 20 de mayo de 2025

  • Un mensaje BGP propagado el martes 20 de mayo de 2025 a las 07:00 UTC provocó un comportamiento inesperado en dos implementaciones principales de BGP usadas con frecuencia para transportar tráfico de Internet
  • El impacto se amplificó cuando muchas sesiones BGP de conectividad a Internet se cerraron automáticamente
    • Se confirmó inestabilidad de enrutamiento en algunas redes
    • En el peor caso, pudo haber breves pérdidas de conexión

El mensaje BGP problemático

  • La actualización observada en las sesiones suministradas a bgp.tools era un BGP Update relativamente normal para un /16, pero incluía el problemático BGP Prefix-SID Attribute
  • Ese atributo era riesgoso por dos razones
    • Es un atributo que no se espera ver en actualizaciones BGP de la tabla de Internet
    • Es un atributo dañado con todos sus datos internos en 0x00
  • La mayoría de las implementaciones, como IOS-XR y Nokia SR-OS, lo filtran correctamente y no causan problemas si tienen configurada la “BGP error tolerance” basada en RFC7606
  • Con la combinación de JunOS y Arista EOS apareció un resultado distinto
    • JunOS retransmitió el mensaje dañado
    • Los equipos Arista EOS reinician la sesión cuando reciben ese mensaje, aparentemente proveniente de un equipo JunOS
  • Como muchos carriers de tránsito de Internet usan hardware Juniper ejecutando JunOS, es posible que las redes que operaban Arista EOS y estaban conectadas a routers upstream de tránsito basados en JunOS hayan perdido acceso a Internet durante un tiempo
    • Se estima una duración máxima de aproximadamente 10 minutos

AS candidatos que añadieron el atributo defectuoso

  • Al filtrar el archivo de bgp.tools de ese período, parece que varios AS de origen estuvieron involucrados en el incidente
  • Esto sugiere que el atributo pudo haber sido añadido no por la red que originó el prefijo, sino por un carrier intermedio en el camino hacia el Internet más amplio
  • Los cuatro candidatos que aparecieron repetidamente en todos los mensajes problemáticos son los siguientes
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools observó el prefijo afectado en la ruta […] 151326 138077 […] sin el atributo BGP defectuoso
    • Por lo tanto, es muy probable que quien añadió el atributo defectuoso haya sido Starcloud AS135338 o Hutchison AS9304
  • Algunos de los prefijos observados en actualizaciones que incluían el atributo son los siguientes
    • 156.230.0.0/16
    • 138.113.116.0/24
    • 163.171.102.0/24
    • 163.171.103.0/24
    • 163.171.104.0/24

Rutas que se extendieron a los Internet Exchange

  • El incidente se agravó porque Hutchison/AS9304 estaba conectado a muchos Internet Exchange
  • Los mensajes problemáticos se enviaron a servidores de ruta de IX, y estos route servers normalmente ejecutan bird
  • Bird no soporta BGP SID, así que no pudo filtrar el mensaje y lo distribuyó tal cual a varios Internet Exchange de múltiples terabits
  • Como resultado, el caos se expandió más allá de las sesiones de tránsito de Internet hacia un alcance mucho mayor

La naturaleza de BGP Prefix-SID

  • El BGP Prefix-SID Attribute normalmente solo debería aparecer en sesiones BGP internas
  • El propósito definido en RFC8669 es ayudar a determinar qué ruta tomará el tráfico hacia un destino dentro de una sola red
  • La razón por la que este atributo se filtró a la tabla de enrutamiento global podría ser que una sesión BGP externa fue configurada como si fuera una sesión interna

Redes afectadas y métricas observadas

  • Es difícil determinar exactamente quiénes fueron afectados, pero tomando como referencia los lugares donde el churn fue muy alto en relación con el tamaño de la red justo después del primer mensaje BGP problemático, se estima que unas 100 redes sufrieron problemas
  • Ejemplos con alta confianza incluyen
  • En condiciones normales, el route collector de bgp.tools recopila alrededor de 20,000~30,000 mensajes por segundo
  • Durante este incidente, la tasa promedio de mensajes en 10 segundos superó ampliamente los 150,000/s
    • Esto indica que hubo una perturbación considerable en muchas rutas de Internet

Diferencias por proveedor en el manejo de errores

  • Aunque la causa raíz o el actor que realmente lo detonó no están completamente claros, el hecho de que un mensaje defectuoso se haya propagado a escala de Internet muestra el riesgo del manejo de errores en BGP
  • Otros proveedores detectaron el atributo defectuoso y suprimieron el anuncio de ruta, pero Juniper lo propagó a sus peers
  • Una vez que el mensaje llegó a equipos Arista, la ausencia de código de tolerancia a errores BGP o la presencia de un defecto provocó el reinicio de la sesión
  • La documentación de tolerancia a errores BGP de JunOS indica que JunOS no inspecciona todas las partes del mensaje
  • Este comportamiento hace que JunOS evite por sí mismo un reinicio de sesión provocado remotamente, pero termine retransmitiendo el mismo mensaje a otros peers o clientes

Implicaciones operativas

  • Este outage fue breve, pero podría haber tenido un impacto mayor
  • A medida que más servicios migran a IP, el alcance de una falla de Internet puede ir más allá de no poder acceder al correo electrónico
    • Fallas en transmisiones de TV
    • Interrupciones en llamadas a servicios de emergencia
  • Este tipo de bugs aumenta la posibilidad de causar o agravar daños reales a personas en el mundo físico
  • Los operadores de red con la tabla de enrutamiento completa pueden ayudar a depurar incidentes futuros proporcionando feeds de datos a bgp.tools

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-29
Opiniones de Hacker News

  • El enfoque estándar es ser tolerante al recibir y estricto al enviar.
    Las opciones son filtrar los mensajes rotos, descartarlos, ignorar los atributos rotos pero reenviarlos, o romperse por culpa de los atributos rotos; en mi opinión, lo único realmente difícil de aceptar es la opción 4, el comportamiento al estilo Arista. La opción 3, el comportamiento al estilo Juniper, aunque no es deseable, no es fatal.
    Al releerlo, parece que Arista no estaba en la opción 4 sino más cerca de la 2: no crasheó por completo, sino que lo interpretó como una conexión inválida y la cerró. Desde el punto de vista del usuario no es bueno, pero en términos de debate es relativamente aceptable.

    • Ya existe el RFC 7606 (Revised Error Handling for BGP UPDATE Messages), que define en detalle cómo deben tratarse los mensajes BGP rotos.
      El método más común es treat-as-withdraw, que consiste en tratar una actualización de anuncio de ruta como si fuera la retirada de una ruta anunciada anteriormente. No se debe simplemente descartar un mensaje roto, porque eso haría que se siga manteniendo un estado antiguo que ya no es válido.
    • Lo que aquí se reformuló es el llamado principio de robustez, es decir, la ley de Postel.
      Es una idea surgida de la historia antigua de Internet en los años 80 y 90, pero hoy se entiende ampliamente como una mala idea que causó osificación de protocolos y numerosos problemas de seguridad.
    • El problema es que la gente aprovechó en toda la red el comportamiento de BGP de reenviar incluso atributos desconocidos que el equipo local no entiende, para todo tipo de usos.
      Ahora muchos sistemas dependen de ese comportamiento y están sufriendo las desventajas de esa “función”.
    • En el artículo relacionado, el autor señala el mismo punto.
      A primera vista, esta “función” parece una muy mala idea, porque permite que información desconocida se propague ciegamente a través de sistemas que no entienden el impacto de la información que reenvían. Pero también puede decirse que, gracias a esta función, cosas como Large Communities pudieron desplegarse de forma más rápida y amplia, e incluso que hizo posible el despliegue de nuevas funciones de BGP.
    • No estoy de acuerdo con este enfoque. Creo que es mejor ser muy estricto tanto al recibir como al enviar.

  • Todavía recuerdo haber corrido como loco para corregir CVE-2023-4481 en toda la red.
    Este tipo de bugs debe ser una verdadera pesadilla de manejar, y por la forma en que BGP fue diseñado e implementado, corregir este comportamiento va a tomar muchísimo tiempo.

  • Hace décadas, aunque ya pasó mucho tiempo, desarrollé funcionalidades de BGP en un proveedor de equipos de telecomunicaciones.
    Sigo pensando que BGP es demasiado complejo, la gente sigue agregándole funciones nuevas y los proveedores siguen implementándolas según estándares RFC o borradores.
    Como no parece que BGP vaya a retirarse, probablemente seguiremos encontrando este tipo de bugs una y otra vez.

    • Definitivamente hubo una época en la que AT&T, junto con Juniper y Cisco, empujó a BGP a un terreno completamente complejo mediante funciones relacionadas con MPLS y VPN.
      Personalmente me parecía aterradoramente complejo, pero para alguien fue muy rentable.

  • HGC Global Communications Limited es una compañía que antes se conocía como Hutchison Global Communications Limited, y es un proveedor de servicios de Internet de Hong Kong.
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • Nuestros chasis IOS XR también recibieron algunos de esos paquetes, y coincidió en el tiempo con un volumen alto de anuncios de rutas BGP. Sinceramente, no sé qué equipos usa nuestro upstream.
    Me pregunto si el protocolo BGP se está fuzzing correctamente. Quizás es un área tan importante que todos tienen miedo de intentar romperla.
    Escribir un fuzzer de BGP podría ser fácil, pero diagnosticar la causa de un crash parece que sería muy difícil.

  • Creo que nunca aprendí BGP hasta que escuché que causaba problemas. Aunque es esencial para Internet, igual que TCP/IP, TCP/IP se enseña en la universidad, uno se lo encuentra durante la carrera profesional y hay muchos libros al respecto, pero BGP casi no apareció ni en la universidad, ni en el trabajo, ni en libros
    Con TCP/IP puedes aprender “jugando” en casa con proyectos de juguete, pero con BGP no sé ni por dónde empezar. ¿Cómo se aprende BGP en casa?

    • Puedes comprar un router que incluya una implementación de BGP. Hay equipos baratos como los de Mikrotik, y también implementaciones open source
      En el artículo se menciona bird, y otra implementación muy popular es FRR (free range routing). Es muy sencillo levantar dos contenedores Docker, crear una sesión BGP entre ellos y, por ejemplo, propagar una ruta estática configurada internamente
      Si te gustan los tutoriales guiados, https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ es bastante bueno y se extiende hacia temas un poco más avanzados. Todo lo necesario para seguirlo es software libre
    • DN42[1] ofrece un espacio de juego para experimentar con tecnologías de routing. Si no piensas invertir mucho tiempo, no recomendaría meterte demasiado a fondo. Incluso para alguien bastante familiarizado con networking, el routing WAN sigue siendo confuso
      La forma más fácil de tener experiencia directa con casi cualquier tecnología de networking probablemente sea GNS3
      [1]: https://wiki.dn42.us/home
    • BGP es como el transporte marítimo internacional. Es absolutamente necesario para que el mundo funcione, pero la mayoría de la gente no necesita interactuar directamente con él
      Una forma de experimentar es esta: https://www.eve-ng.net/
      Otra opción es crear un par de máquinas virtuales con varias interfaces de red, configurar redes entre ellas y usar un daemon de routing BGP
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      Hay opciones como esas
    • En la materia de redes de pregrado no vimos BGP; en la de redes de posgrado sí
      Usamos un paquete de Python que simulaba varios AS, pero no recuerdo cuál era
    • En la clase de redes de pregrado vimos un poco de BGP, pero solo con explicación en el pizarrón
      Para experimentar con BGP, puedes usar un simulador de redes como el autor de este artículo. En clase usamos gini[1], que parecía hecho por un estudiante de posgrado del profesor, y el autor parece haber usado gns3, que se ve como una versión de ns3 especializada en Cisco. Probé ns3 una vez y tenía una curva de aprendizaje pronunciada. El simulador gini tiene una interfaz de usuario más básica, pero probablemente también sea menos potente
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • Parecería que BGP habría sido mucho más estable si varios fabricantes de hardware se hubieran puesto de acuerdo en una forma estándar de manejar este tipo de cosas
    ¿El verdadero problema será que cada proveedor quiere generar dependencia y por eso no estandariza?
    Dicho eso, mi comprensión de BGP es superficial y limitada; no soy experto

  • Considerando el impacto de bugs como este, sorprende que no exista un consorcio con una suite de pruebas de interoperabilidad
    Tal vez sí exista, pero este problema específico no esté en la suite de pruebas. Si es así, sorprende que no usen fuzzers o generación automática para explorar todos los posibles errores de paquetes y crear casos de prueba. No importaría que ejecutar la suite tomara horas o días
    El autor de este artículo creó un fuzzer con cierto nivel de cobertura y parece haberse encontrado con problemas similares antes. Sorprende que los proveedores no adopten activamente este trabajo

  • Varios proveedores ya habían sufrido este bug en el pasado: https://www.kb.cert.org/vuls/id/347067
    Hubo CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS)
    En ese momento, Arista no se vio afectada

  • Me pregunto si existe algo tan grande y con tanta complejidad accidental enredada de forma bizantina como la plomería de Internet