Resumen

  • El artículo publicado por LACNIC el 28 de julio comienza con un atributo BGP Prefix-SID mal formado, código 40, observado el 20 de mayo de 2025 y una ráfaga superior a 150.000 actualizaciones en diez segundos.
  • El relato atribuye tres conductas a la cadena: IOS-XR y SR OS descartaron el atributo, Junos lo retransmitió, EOS reinició sesiones y servidores de rutas de varios IXP lo propagaron.
  • La RFC 8669 exige descartar y registrar un Prefix-SID mal formado, pero esa norma no demuestra qué versión, opción de tolerancia a errores o plantilla heredada estaba activa en un router real.
  • La comparación debería incorporar una matriz con bytes de prueba, versión exacta, configuración efectiva, tipo de relación, acción, huella del mensaje reenviado y efecto en las tablas de rutas.

La escena útil está en los verbos

LACNIC publicó el 28 de julio un texto sobre las clases de incidentes de enrutamiento que quedan fuera de la validación criptográfica. En vez de comenzar con una abstracción, el artículo abre con un objeto preciso: el 20 de mayo de 2025 circuló un BGP UPDATE con un atributo Prefix-SID corrupto. Se trata de un atributo opcional y transitivo; su código es 40.

La secuencia descrita es llamativa porque el mensaje no habría recibido una sola respuesta. Cisco IOS-XR y Nokia SR OS descartaron el atributo mal formado. Junos lo dejó seguir. Equipos Arista que lo recibieron reiniciaron sesiones BGP. Servidores de rutas en varios puntos de intercambio también lo reenviaron. Durante diez segundos, señala el artículo, el sistema global registró más de 150.000 actualizaciones y aparecieron fluctuaciones en rutas de varias redes conocidas. EOS cambió la conducta a partir de la versión 4.28.11.

La aportación inmediata es correcta y acotada: aquello no era necesariamente un secuestro de prefijo, tampoco una fuga de rutas, y RPKI no tenía nada que validar en el atributo defectuoso. Una autorización de origen puede ser válida mientras otro campo del UPDATE activa un error en un receptor posterior.

El problema comienza cuando el lector convierte el nombre del fabricante en una configuración. Cisco, Nokia, Juniper y Arista no identifican por sí solos un parser, un nivel de parche, una política de vecino ni el resultado de la herencia de plantillas. La marca no dice si la sesión era interna, de cliente, de tránsito, de peering o de un servidor de rutas.

La RFC define la acción, no inventaría el despliegue

La RFC 8669 define Prefix-SID como un conjunto de TLV. También fija qué hacer ante varios errores de sintaxis: si el atributo es demasiado corto, si una longitud es inválida o si un TLV rebasa el final declarado, el receptor debe descartar el atributo y registrar el error. La acción remite al Attribute discard de la RFC 7606.

Esa obligación normativa es una referencia exacta. No es una medición de todos los equipos instalados.

El relato contemporáneo de Ben Cox conserva una condición que el resumen de LACNIC no muestra. Según ese análisis, IOS-XR y SR OS filtraban el objeto suponiendo que sus sistemas estaban configurados para la tolerancia a errores de la RFC 7606. La diferencia entre “el producto descartó” y “el producto descartó bajo esta configuración” puede parecer pequeña en una crónica; para quien prepara un cambio de red, es la diferencia entre una expectativa y una prueba.

No hace falta leerlo como una rectificación hostil. La investigación necesita términos comparables y una noticia necesita una frase comprensible. Tampoco es normal que un incidente distribuido entregue, de inmediato, una transcripción de laboratorio. La solución razonable es mantener la conclusión y añadir sus condiciones.

La conversación en NANOG del mismo día ayuda a dibujar el borde. Allí se relaciona la conducta de EOS con el bug 899981 y se mencionan correcciones en cuatro ramas: 4.28.11, 4.29.8, 4.30.6 y 4.31.2. Al mismo tiempo, los participantes preguntan si la corrección habría cambiado de manera limpia la respuesta al mensaje exacto. Una presentación posterior de Arista en JANOG 57 reproduce la comparación y las versiones. Todo ello fortalece la reconstrucción, pero no sustituye un replay controlado y común para las cuatro familias.

Una tasa no es un censo

El número de 150.000 hace visible la amplificación, siempre que se preserve su unidad. La fuente lo presenta como tasa de mensajes observada por un colector sobre un promedio de diez segundos. No son 150.000 prefijos únicos, sesiones, routers, operadores ni cortes de servicio.

La lista de redes merece la misma prudencia. Observar flapping en rutas asociadas con Starlink, Disney, Zscaler o ByteDance no permite deducir qué equipo utilizaba cada una, si recibió los mismos bytes del mismo vecino o si todos sus usuarios notaron una interrupción. El plano de control distribuido ofrece rastros, no una encuesta completa de plataformas.

Tampoco se ha probado una intención maliciosa en el AS de origen. El propio artículo reconoce que las categorías estudiadas admiten explicaciones inocentes: una redistribución incorrecta, un script duplicado o un bug. Clasificar el mecanismo no convierte el episodio en ataque deliberado.

La columna que falta

La mejora no exige que LACNIC controle software ajeno ni que publique una topología sensible. Puede presentar una ficha de conformidad, fechada y reproducible, basada en un vector de prueba saneado que conserve los mismos bytes relevantes.

La primera columna debe ser la huella inmutable del UPDATE. Después: código, flags, longitud declarada y error TLV. A continuación, plataforma, versión exacta, identificador de la corrección y configuración efectiva después de aplicar grupos, plantillas y opciones específicas del vecino.

La naturaleza de la frontera también cuenta. Un atributo puede recibir políticas distintas en iBGP, frente a un cliente, un proveedor de tránsito, un peer o un servidor de rutas. La expresión “servidor de rutas” no define un único producto ni una política universal.

El resultado debe expresarse con vocabulario operativo: reinicio, deshabilitación de una familia, treat-as-withdraw, descarte del atributo, aceptación u otra acción definida. Si el mensaje salió, la ficha puede publicar la huella de los bytes reenviados. Si no salió, debe registrarlo. Finalmente, conviene unir la acción con el estado de la sesión y con los cambios observados en Adj-RIB-In, Loc-RIB y FIB dentro del ensayo.

Nada de esto obliga a revelar direcciones de peers, clientes, credenciales o configuraciones completas. El vector saneado, el método, la pérdida de captura, el resultado agregado, el historial de correcciones y la fecha del retest pueden ser públicos. Las capturas sin depurar pueden mantenerse bajo acceso controlado.

La división de responsabilidades queda entonces más limpia. Las RFC fijan la conducta requerida. Los fabricantes implementan y reparan. Los operadores eligen versiones y política. Quienes administran route servers deciden qué atraviesa su servicio. LACNIC puede documentar y ofrecer un método regional; no se convierte por ello en regulador del router.

Lo que no puede concluirse

Las fuentes no afirman que LACNIC originara el UPDATE, operara un equipo afectado o pudiera detener la secuencia. No miden una población de usuarios ni una duración única para todas las redes. Tampoco prueban que un fabricante se comporte siempre de la forma resumida.

El episodio no es un fracaso de RPKI. RPKI responde si un origen está autorizado para un prefijo. La seguridad sintáctica de cada atributo opcional y transitivo pertenece a otro control. Confundirlos inflaría el mandato de la infraestructura criptográfica y ocultaría la responsabilidad local.

La noticia, por tanto, no es que falte una solución mágica. Es que LACNIC ha publicado una comparación operacionalmente valiosa cuya próxima versión puede ser verificable. Ya están los verbos. Falta indicar bajo qué versión y configuración fue cierto cada uno.

Fuentes