Experimento BGP RIPE-Duke 2010: estándares y responsabilidad

Resumen

Un atributo BGP transitivo opcional válido se corrompió cuando los sistemas IOS XR afectados lo propagaron, lo que provocó reinicios de sesión en los sistemas receptores y una inestabilidad de enrutamiento más amplia.
La rendición de cuentas sigue puntos de control separados: alcance y supervisión del experimento, comportamiento y reparación del producto, controles de continuidad del operador y manejo de errores del protocolo.

El 27 de agosto de 2010, el personal de RIPE NCC que opera el Routing Information Service, o RIS, colaboró con un grupo de investigación de Duke University en un experimento en vivo con el Protocolo de Puerta de Enlace Fronteriza. Los investigadores estudiaban un diseño de enrutamiento seguro que incorporaba información de certificación en un atributo de ruta transitivo opcional. A las 08:41 UTC, RIPE NCC originó 93.175.144.0/24 desde el AS12654 del RIS a través de las conexiones en AMS-IX y GN-IX. La ruta se retiró según lo previsto a las 09:08 UTC.[1]

El anuncio era inusual porque el atributo era nuevo en la Internet pública. Sin embargo, inusual no significaba mal formado. RIPE NCC y Cisco describieron el atributo inicial como válido o conforme a los estándares.[1][2] Esa distinción determina cómo debe analizarse el evento. El experimento no demostró simplemente que los enrutadores rechazan entradas no válidas. Demostró que una entrada conforme a los estándares podía superar comprobaciones formales, encontrar un defecto en el software desplegado, corromperse durante la propagación y activar después un manejo de errores severo en otros puntos.

Cisco informó de que los sistemas IOS XR afectados manejaban incorrectamente el atributo transitivo válido pero no reconocido al reenviarlo. Un enrutador vecino podía recibir el UPDATE corrupto resultante y reiniciar la sesión de peering BGP. Dado que una sesión BGP transporta muchas rutas, una respuesta a un único UPDATE defectuoso podía retirar temporalmente información de alcanzabilidad válida no relacionada. Si el enrutador responsable de la corrupción saliente no detectaba su propio error, podía anunciar nuevamente la información problemática después de restablecerse la sesión, renovando la inestabilidad.[2][3]

Las mediciones de RIPE NCC respaldan una conclusión de impacto acotado pero material. El evento produjo tasas de actualización de hasta veinte veces la línea base circundante. RIPE estimó que un 0,5 % adicional de prefijos quedó completamente inalcanzable durante más tiempo del normal. La proporción de prefijos inestables alcanzó un máximo del 1,4 %, lo que representa casi 4.500 prefijos y aproximadamente nueve veces el nivel habitual observado alrededor del evento. Los resultados variaron según el colector y la ubicación, con una actividad de actualización especialmente intensa visible en el colector de Viena.[1]

Esas cifras son significativas, pero no autorizan a afirmar que desapareció un porcentaje conocido de usuarios, enrutadores, redes o tráfico. Las observaciones del plano de control cuentan comportamiento de enrutamiento, no personas. El análisis DNSMON de RIPE no encontró fallos en los servidores raíz.

Sí detectó una pérdida limitada de consultas para algunos dominios supervisados y problemas más visibles en partes de la infraestructura autoritativa de.si y.fr, mientras que los servidores redundantes siguieron respondiendo.[1] Los comentarios contemporáneos de los operadores mencionaron problemas de acceso y cambios en el tráfico de intercambio, pero esos informes no constituyen un relato cuantitativo completo.[4][6]

La lección de rendición de cuentas es, por tanto, más limitada y más útil que la historia de un actor que «rompe Internet». RIPE NCC controlaba si su infraestructura de medición originaba una ruta experimental visible en Internet, junto con el calendario, el aviso, la supervisión y la retirada. Los investigadores de Duke controlaban el diseño de la investigación y la implementación del lado de la investigación. Cisco controlaba el manejo por parte de IOS XR de un atributo válido no reconocido, sus pruebas de producto, la divulgación y las correcciones de mantenimiento.

Los operadores de red controlaban su software instalado, las políticas de enrutamiento, las protecciones de pares, la supervisión y la restauración dentro de sus propias redes. Las reglas del protocolo de la época proporcionaron un mecanismo de amplificación al permitir que un único UPDATE mal formado causara una falla a nivel de sesión.

Las reparaciones también pertenecían a capas separadas.

Cisco emitió un aviso el mismo día del evento y preparó actualizaciones de mantenimiento.[2] RIPE NCC conservó evidencia, proporcionó información al proveedor, publicó un análisis y se comprometió a controles más estrictos para futuros experimentos cooperativos.[1] Su Consejo Ejecutivo apoyó posteriormente la continuación de la investigación, al tiempo que enfatizó una comunicación adecuada.[5] La corrección del producto redujo el riesgo de implementación; una gobernanza más sólida del experimento redujo el riesgo de descubrir una interacción desconocida a través de un dominio de falla público innecesariamente amplio.

Los estándares posteriores ayudan a explicar cómo aprendió la industria de esta clase de fallos, pero no pueden usarse como prueba de lo que estaba desplegado o era obligatorio en agosto de 2010.

La RFC 7606 promovió más tarde un manejo más limitado de los UPDATE BGP mal formados porque reiniciar una sesión completa puede descartar muchas rutas válidas.[13] Las recomendaciones operativas sobre política externa explícita, prevención de fugas de rutas, validación de origen, RPKI y BGPsec iluminan controles adyacentes, pero ninguna establece retroactivamente negligencia y ninguna corrige por sí sola el defecto preciso de corrupción saliente expuesto por este evento.[14][15][16][17][18][19][20]

La conclusión central es mesurada: un anuncio experimental válido desencadenó una cadena en la que un defecto de implementación corrompió información, el manejo de errores a nivel de sesión amplificó esa corrupción y unos controles de experimento en vivo insuficientemente acotados expusieron la interacción en la Internet pública. La rendición de cuentas sigue la asignación del control, no la simplicidad del primer desencadenante visible.

1. Por qué este evento merece un análisis limitado

Los incidentes BGP suelen comprimirse en etiquetas como fuga, secuestro, interrupción o configuración incorrecta. Esas etiquetas pueden ser útiles cuando la evidencia encaja con ellas, pero también pueden borrar el mecanismo que realmente importa. Este evento exige un límite más preciso.

El objeto de análisis es únicamente el experimento RIPE NCC–Duke University del 27 de agosto de 2010. No es un relato de fugas de rutas posteriores, secuestros posteriores ni de todos los fallos BGP subsiguientes. La taxonomía posterior de fugas de rutas de la RFC 7908 es útil para distinguir categorías, pero no justifica reclasificar este experimento como una fuga de rutas convencional sin evidencia de que se produjeron las condiciones de fuga especificadas.[16]

El experimento originó una ruta deliberadamente construida que transportaba un nuevo atributo transitivo opcional. Su visibilidad pública fue intencionada. La inestabilidad resultante no lo fue. Esa combinación plantea tres preguntas que no deberían fundirse en una sola:

¿Era válido el UPDATE BGP inicial?
¿Qué componente convirtió información válida en información corrompida?
¿Qué controles permitieron que la falla resultante se extendiera más allá de una prueba estrictamente acotada?

El registro disponible responde a las dos primeras preguntas con una confianza relativamente alta. RIPE NCC y Cisco caracterizaron el atributo original como válido o conforme a los estándares, mientras que Cisco identificó una vulnerabilidad de IOS XR relacionada con la corrupción durante la propagación.[1][2] NVD registra el problema del producto como CVE-2010-3035.[3]

La tercera pregunta es distribuida. Los investigadores no controlaban cada enrutador desplegado. Cisco no decidió que el RIS originara la ruta experimental. Los operadores individuales no diseñaron el experimento ni la implementación afectada. Las conexiones de los puntos de intercambio de Internet no demostraron, por su mera presencia, la aprobación de cada atributo transportado a través de ellas. Por tanto, la atribución debe seguir los puntos de control reales.

Este evento importa porque rompe una suposición fácil pero insegura: que el cumplimiento de los estándares en el origen basta para establecer la seguridad operativa en un sistema de enrutamiento heterogéneo. El cumplimiento es necesario, pero el comportamiento desplegado decide si un paquete o UPDATE sobrevive al contacto con el código en ejecución. El experimento superó un tipo de frontera de validez y falló en otra.

El propio RIS existe para recopilar y exponer información de enrutamiento desde múltiples puntos de observación.[7][8] Los registros de RIPEstat y de RIPE Database proporcionan contexto identificativo para AS12654, pero un registro de sistema autónomo no puede revelar todos los comportamientos de software encontrados a lo largo de una ruta propagada.[9][10] Los sistemas de colectores de rutas como RIS y Route Views son valiosos precisamente porque ningún registro de registro único, declaración de pares o registro local puede describir todo el sistema de enrutamiento interdominio.[11]

La lección no es que los estándares sean irrelevantes. Es que un estándar describe el comportamiento requerido, mientras que la rendición de cuentas exige evidencia de que las implementaciones, los despliegues y los controles operativos producen ese comportamiento en condiciones reales.

2. Cronología: de un anuncio programado a una perturbación no intencionada

Antes de las 08:41 UTC: diseño y comprobaciones previas al anuncio

El grupo de investigación de Duke estudiaba un diseño de enrutamiento seguro en el que la información de certificación viajaría en un atributo de ruta BGP transitivo opcional. Duke proporcionó una implementación modificada de Quagga dentro del esfuerzo de investigación. Las comprobaciones previas al anuncio establecieron que el atributo tenía una forma de protocolo aceptable, y una segunda instancia de Quagga no reprodujo el comportamiento observado posteriormente en los equipos desplegados afectados.[1]

Ese resultado fue informativo pero incompleto. Demostró que la implementación inicial y un entorno receptor similar podían procesar el atributo. No demostró que cada familia de enrutadores, versión de software o ruta de reenvío en la Internet pública preservara el atributo correctamente.

Esta fue la brecha de detección crítica. La ruta de prueba evaluó la estructura formal y un comportamiento de implementación limitado. No reprodujo la base instalada heterogénea a través de la cual podía viajar un atributo transitivo. Sobre todo, no expuso un defecto por el que un enrutador aceptaba un atributo desconocido válido pero lo corrompía al reenviarlo.

El registro público no establece el historial completo de aprobaciones, todos los riesgos contemplados ni todos los controles discutidos antes del evento. Por tanto, sería inapropiado inventar un proceso de decisión no documentado. Lo que puede afirmarse es que los controles utilizados antes del anuncio no detectaron la interacción que produjo la perturbación pública.

08:41 UTC: la ruta se hace visible

A las 08:41 UTC del 27 de agosto de 2010, el AS12654 del RIS comenzó a anunciar 93.175.144.0/24 con el atributo transitivo opcional experimental. El anuncio viajó a través de las conexiones de RIPE NCC en AMS-IX y GN-IX.[1]

Este momento fue el evento desencadenante. Sin embargo, «desencadenante» no es sinónimo de «causa raíz». Un desencadenante es el evento que activa una condición latente. Si una entrada válida encuentra una implementación defectuosa, la entrada válida inicia la secuencia observada, pero el defecto explica por qué la secuencia se aparta del comportamiento especificado.

La visibilidad pública de la ruta también creó la exposición de la gobernanza del experimento. Una prueba en un sistema cerrado o estrictamente acotado puede revelar un defecto sin permitir que atraviese un amplio conjunto de redes autónomas. Una vez que la ruta entró en la propagación interdominio ordinaria, el resultado dependió de software y políticas fuera del control directo de las partes iniciadoras.

Durante la propagación: la información válida se corrompe

Los sistemas IOS XR afectados recibieron un atributo que no reconocían. Según el diseño transitivo opcional de BGP, la falta de reconocimiento no era en sí misma motivo para rechazar el atributo. El comportamiento relevante era preservarlo y propagarlo.

El relato de Cisco identificó una falla en esa ruta de propagación: los sistemas afectados corrompían el atributo, por lo demás válido, al enviarlo a un vecino.[2] La evidencia disponible no justifica inventar la mutación precisa a nivel de bytes para cada ruta afectada. El hallazgo fiable es funcional: información desconocida válida entró en una implementación afectada y de la propagación salió información corrompida.

Esa distinción ubica el defecto del producto con más precisión que decir que el enrutador simplemente «no soportaba» la característica experimental. La transitividad opcional existe para que un enrutador pueda transportar un atributo sin comprender su semántica completa. Una implementación conforme no necesita actuar sobre la información de certificación. Sí necesita preservar el atributo correctamente si lo propaga.

La corrupción cruzó entonces una frontera de implementación. Un vecino en sentido descendente recibió un UPDATE que ya no era equivalente al válido originado por el experimento.

Recepción en sentido descendente: un UPDATE amenaza toda una sesión

Según las reglas de manejo de errores asociadas con la línea base de estándares de la época, un atributo de ruta mal formado podía producir un error de mensaje UPDATE y el cierre de la sesión BGP.[12] Esta respuesta era severa por diseño: un enrutador que no podía interpretar con seguridad la información de enrutamiento se protegía terminando la sesión.

El efecto secundario operativo fue amplio. Una sesión BGP normalmente transporta muchas rutas, no solo el prefijo experimental. Cerrar la sesión podía por tanto retirar rutas válidas no relacionadas aprendidas de ese par. Las redes buscarían entonces alternativas, intercambiarían nuevos UPDATE y volverían a converger.

Era posible además un mecanismo de repetición. El enrutador que corrompió el atributo saliente no se identificaba necesariamente como la fuente de la corrupción. Después de que una sesión vecina se recuperara, la misma ruta podía anunciarse de nuevo. La misma corrupción podía repetirse, el sistema receptor podía reiniciar otra vez y la inestabilidad de enrutamiento podía renovarse.[2]

La cadena de fallos fue en consecuencia mayor que el prefijo experimental:

Un atributo válido pero desconocido entró en un enrutador afectado.
El enrutador lo corrompió durante la propagación posterior.
Un vecino recibió un UPDATE mal formado.
El vecino pudo terminar la sesión BGP.
Rutas no relacionadas con el experimento pudieron desaparecer de esa adyacencia.
La reconvergencia produjo un mayor volumen de actualizaciones.
El reanuncio pudo repetir la secuencia.

Por eso el evento se convirtió en una prueba de rendición de cuentas y no en una mera curiosidad de interoperabilidad. Cada etapa estaba controlada por un componente u organización diferente.

09:08 UTC: retirada programada

RIPE NCC retiró el anuncio experimental a las 09:08 UTC, según lo previsto.[1] Por tanto, la ruta se originó durante aproximadamente veintisiete minutos.

La retirada era necesaria, pero una retirada no es un borrador instantáneo. BGP es distribuido. Las actualizaciones ya aceptadas o propagadas deben viajar por otras sesiones, mientras los enrutadores recalculan rutas y restablecen adyacencias. Una retirada planificada puede detener la originación continua en el punto iniciador sin cancelar de inmediato cada copia, actualización en cola, reinicio o proceso de reconvergencia ya en marcha.

RIPE describió el impacto operativo no intencionado como de unos treinta minutos de duración. La mayor parte de la inestabilidad volvió a la normalidad aproximadamente veinte minutos después del experimento, en lugar de terminar en el segundo exacto de la retirada.[1] Esas descripciones deben tratarse como intervalos operativos medidos, no convertirse en una afirmación de que todas las rutas afectadas se recuperaron simultáneamente.

Después de la retirada: respuesta de los operadores y recopilación de evidencia

Los operadores observaron y respondieron desde sus propias redes. Las discusiones contemporáneas en listas de correo incluyeron informes de problemas de acceso, cambios de enrutamiento y efectos en el tráfico de intercambio.[4][6] Esos comentarios son evidencia útil de que la perturbación era operativamente visible, pero tienen límites estrictos. No enumeran todos los sistemas autónomos afectados, no normalizan las observaciones entre ubicaciones ni aportan un recuento completo del tráfico perdido.

RIPE NCC conservó los datos del experimento y proporcionó la evidencia recopilada a Cisco. Esa conservación importaba porque el evento cruzó fronteras organizativas. Un registro del lado del origen por sí solo podía mostrar lo que envió el RIS, pero no necesariamente lo que emitió una implementación intermedia. Un informe del proveedor por sí solo podía explicar un defecto, pero no cuantificar las observaciones en toda Internet. Una reconstrucción creíble requería evidencia de más de un dominio de control.

22:00 UTC: el aviso de Cisco

Cisco publicó su aviso sobre IOS XR a las 22:00 UTC del 27 de agosto de 2010.[2] El problema se registró como CVE-2010-3035 y Cisco preparó actualizaciones de mantenimiento de software.[3]

El aviso del mismo día estableció una respuesta pública a nivel de producto. No demostró por sí solo qué versión estaba instalada en cada operador afectado, cuántos dispositivos encontraron la ruta ni si todos los operadores disponían de una mitigación utilizable de inmediato. Eso sigue siendo desconocido en el registro acotado.

31 de agosto y después: análisis público y respuesta de gobernanza

RIPE NCC publicó su análisis del incidente y de las mediciones el 31 de agosto de 2010.[1] El relato describía el experimento, la interacción de implementación, los efectos de enrutamiento observados, los hallazgos de DNSMON y los cambios previstos para futuros experimentos cooperativos.

RIPE NCC afirmó que los futuros experimentos recibirían un tratamiento más estricto, incluida una evaluación integral del impacto, un aviso previo suficiente a los operadores y un manejo responsable de las vulnerabilidades.[1] Su Consejo Ejecutivo apoyó posteriormente la continuación de la experimentación, al tiempo que enfatizó una comunicación adecuada.[5]

Esa respuesta no negó el valor de la investigación. Reconoció que un objetivo de investigación útil no elimina la necesidad de acotar la exposición operativa. Por tanto, la reparación de gobernanza no fue «dejar de experimentar». Fue condicionar la autoridad para iniciar un experimento público a controles más claros de riesgo, aviso, contención y respuesta.

3. Qué es un atributo transitivo opcional y por qué «desconocido» no significaba «inválido»

Los atributos de ruta BGP transportan información asociada a una ruta. Algunos son bien conocidos y se espera que las implementaciones BGP los comprendan. Otros son opcionales. Una distinción separada se refiere a la transitividad: si un atributo debe continuar entre hablantes BGP incluso cuando una implementación intermedia no reconoce su significado.

La RFC 4271 define el comportamiento relevante. Un atributo opcional no transitivo no reconocido no necesita reenviarse. Un atributo opcional transitivo no reconocido es diferente. Se acepta y se pasa a otros pares BGP, con el bit Partial utilizado para indicar que un sistema intermedio no reconoció completamente el atributo.[12]

Ese mecanismo permite la extensión. Sin él, cada sistema autónomo a lo largo de una ruta necesitaría soporte de software simultáneo antes de que una nueva característica transitiva pudiera cruzar Internet. La transitividad opcional permite un despliegue incremental: un enrutador puede transportar información sin interpretarla.

El diseño crea una responsabilidad de implementación estricta. Un enrutador que no comprende un atributo transitivo opcional debe manejar de todos modos su representación de forma segura. En términos prácticos, no debe convertir información opaca válida en información mal formada.

Cuatro conceptos deben permanecer separados:

Reconocimiento.¿Comprende el enrutador la semántica del atributo?

Aceptación.¿Tiene el atributo una forma que el enrutador pueda recibir de forma segura según las reglas del protocolo?

Propagación.¿Debe o puede el enrutador pasar el atributo?

Mutación.¿Altera el enrutador el atributo y, si es así, está permitida y correctamente codificada esa alteración?

El evento de 2010 no exigía que los sistemas IOS XR afectados comprendieran el esquema de certificación de la investigación. El defecto afectaba a la propagación. El relato de Cisco era que los sistemas afectados corrompían el atributo transitivo válido no reconocido al reenviarlo.[2]

Esto explica por qué una segunda instancia de Quagga no bastó para predecir el incidente. Dos implementaciones pueden coincidir sobre la forma de un atributo mientras una tercera contiene un defecto en una ruta de código diferente. Recibir, almacenar y serializar un atributo desconocido puede implicar operaciones separadas. Superar una comprobación de conformidad en la entrada no demuestra un comportamiento correcto en la salida.

El evento también demuestra la diferencia entre validez sintáctica y seguridad operativa de extremo a extremo. El UPDATE inicial podía ser válido en el origen. Un sistema intermedio podía producir después una representación no válida. Un sistema receptor podía responder correctamente según las reglas disponibles y aun así crear una consecuencia operativa dañina al cerrar una sesión completa.

Ninguna capa por sí sola explica el impacto:

El experimento suministró la entrada desconocida.
El producto afectado suministró la corrupción.
La respuesta de error en el sistema receptor suministró la pérdida de sesión.
La reconvergencia BGP suministró la amplificación de actualizaciones.
La propagación pública suministró el dominio de falla.

Llamar mal formado al atributo original borraría el defecto del producto, a menos que la evidencia de paquetes demuestre lo contrario. Llamar al evento completo solo un error del producto borraría la decisión de exponer una interacción incierta en la Internet en vivo. Llamarlo solo una respuesta dura del protocolo borraría la implementación que generó el UPDATE mal formado en el tramo descendente.

La descripción precisa es una falla encadenada con propietarios de control distintos.

4. De un UPDATE corrompido a una inestabilidad de enrutamiento más amplia

BGP distribuye alcanzabilidad entre sistemas autónomos. Cuando se cierra una sesión de peering, las rutas aprendidas exclusiva o preferentemente a través de esa sesión pueden retirarse de la tabla de enrutamiento local. El enrutador puede seleccionar alternativas y anunciar esos cambios a otros pares. Esos pares repiten a su vez sus propios procesos de selección.

Esto significa que un error asociado a una ruta puede crear cambios que afectan a muchas rutas si la respuesta elimina toda una adyacencia. El prefijo experimental no necesitaba ser el destino buscado por los usuarios afectados. Un reinicio podía perturbar otra alcanzabilidad aprendida a través de la misma sesión.

El volumen de actualizaciones del evento es coherente con este mecanismo de amplificación. RIPE observó tasas de actualización de hasta veinte veces la línea base circundante.[1] Esa es una medición del plano de control: los enrutadores intercambiaban sustancialmente más cambios de enrutamiento. No indica directamente cuánto tráfico de aplicaciones se perdió, pero muestra que la perturbación se extendió más allá de un rechazo silencioso de un único prefijo.

La restauración de la sesión también podía crear recurrencia. Si el enrutador afectado en el tramo ascendente conservaba la ruta y repetía su propagación defectuosa cuando la sesión volvía, el vecino podía encontrarse de nuevo con el UPDATE mal formado. El ciclo resultante combinaría:

establecimiento de la sesión;
anuncio de la ruta;
corrupción durante la propagación;
recepción del UPDATE mal formado;
cierre de la sesión;
retirada de la ruta y reconvergencia; y
nuevo establecimiento.

No todos los pares o rutas experimentaron necesariamente cada paso. La evidencia respalda un mecanismo quepodíarepetirse y observaciones de inestabilidad elevada; no aporta un registro completo paquete a paquete para cada sistema autónomo.

Esta distinción importa al asignar impacto. Un colector de rutas ve anuncios y retiradas en su punto de observación. No ve cada decisión de reenvío, cada sesión de usuario ni cada paquete descartado. Colectores distintos ven porciones distintas del sistema de enrutamiento. La actividad especialmente intensa en el colector de Viena ilustra que el efecto fue desigual.[1]

La desigualdad no es un defecto de la medición. Es una propiedad de la topología y la política de Internet. Los sistemas autónomos eligen rutas localmente. Tienen pares, software, filtros y alternativas diferentes. Un anuncio defectuoso puede pasar por una ruta, ser bloqueado en otra y no ser seleccionado jamás en una tercera.

Por tanto, el movimiento analítico correcto no es extrapolar el pico de un colector a toda Internet. Es combinar colectores, describir la distribución y preservar los límites de la inferencia.

5. Impacto acotado: qué respalda la evidencia

Las mediciones de RIPE proporcionan tres indicadores principales.

Primero, las tasas de actualización de enrutamiento alcanzaron hasta veinte veces la línea base circundante.[1] Esto demuestra una actividad excepcional del plano de control durante la ventana del evento. La expresión «hasta» importa: describe un pico, no una tasa uniforme en cada colector ni durante todo el período.

Segundo, RIPE estimó que un 0,5 % adicional de prefijos quedó completamente inalcanzable durante más tiempo del normal.[1] Esta es una medida de visibilidad a nivel de prefijo. No debe traducirse en un 0,5 % de usuarios, tráfico, enrutadores o actividad económica. Los prefijos varían mucho en tamaño, uso y tráfico, y los colectores de rutas no observan todas las rutas de reenvío.

Tercero, la proporción de prefijos inestables alcanzó un máximo del 1,4 %. RIPE asoció ese pico con casi 4.500 prefijos, unas nueve veces el nivel habitual.[1] «Inestable» no es idéntico a «universalmente inalcanzable». Un prefijo puede experimentar cambios de ruta repetidos y seguir siendo alcanzable desde algunos lugares.

Estos hallazgos respaldan la conclusión de que el evento causó una inestabilidad de enrutamiento material, medible y distribuida. No respaldan la afirmación de que el 1,4 % de Internet quedara completamente fuera de línea.

Un atajo contemporáneo según el cual el evento afectó aproximadamente al uno por ciento de Internet puede captar el orden de magnitud de algunas mediciones, pero es menos preciso que los indicadores separados de RIPE. No debería sustituirlos. La evidencia distingue la inalcanzabilidad completa adicional, la inestabilidad observada y el volumen de actualizaciones.

Variación geográfica y por colector

Los efectos variaron según la ubicación y el colector. El colector de Viena mostró una actividad de actualización especialmente alta.[1] La variación puede reflejar la topología, la selección de pares, la exposición a implementaciones afectadas y la disponibilidad de rutas alternativas.

La ubicación de un colector no es un mapa directo del impacto en los usuarios de esa ciudad o país. Los puntos de observación BGP reciben rutas de pares participantes. Su vista puede incluir rutas que sirven a redes remotas, y los usuarios locales pueden seguir rutas no visibles para el colector. La evidencia del colector es sólida para el comportamiento de enrutamiento y más débil para asignar un recuento geográfico de personas afectadas.

Observaciones de DNS

RIPE utilizó DNSMON para examinar si la perturbación de enrutamiento produjo efectos DNS visibles. No encontró una falla del sistema de servidores raíz.[1] Ese hallazgo negativo es importante porque una inestabilidad de enrutamiento amplia no implica automáticamente la falla de todos los servicios críticos.

El análisis sí observó una pérdida limitada de consultas para algunos dominios supervisados y dificultades más notables en partes de la infraestructura autoritativa de.si y.fr. Los servidores redundantes siguieron respondiendo.[1] Por tanto, la evidencia respalda efectos DNS parciales y desiguales, no una falla DNS universal.

La disponibilidad continuada de los servidores redundantes es también un recordatorio de que la rendición de cuentas del enrutamiento incluye la arquitectura del servicio. Una perturbación de enrutamiento puede alcanzar una ruta de servidor autoritativo mientras otra permanece alcanzable. La redundancia no elimina el defecto de enrutamiento, pero puede impedir que una falla de componente se convierta en una falla completa del servicio.

Informes de los operadores

Los foros operativos contemporáneos registraron informes de interrupción de acceso, reacciones de enrutamiento y cambios de tráfico.[4][6] Estos informes ayudan a establecer que el incidente fue visible fuera de las instituciones iniciadoras. También pueden identificar preguntas para una investigación posterior.

No sustituyen una medición normalizada. Una caída de tráfico en un intercambio u operador puede reflejar desvío de rutas, pérdida, cambios de política por precaución u otra respuesta local. Sin líneas base, topología y registros de tráfico emparejados, no puede convertirse en una cifra de impacto total en Internet.

Afirmaciones que la evidencia no respalda

El registro acotado no establece:

una lista completa de versiones de IOS XR afectadas tal como estaban desplegadas en ese momento;
un número exacto de enrutadores o dispositivos afectados;
todos los sistemas autónomos que reiniciaron una sesión;
un número exacto de usuarios afectados;
el tráfico de aplicaciones total perdido;
la falla universal del prefijo experimental;
la falla de la raíz DNS;
intención maliciosa por parte de RIPE NCC, Duke, Cisco o los operadores;
un relato completo de cada aprobación previa al evento;
que todos los operadores tuvieran una mitigación disponible antes del evento; ni
responsabilidad legal.

Estas no son advertencias menores. Definen la diferencia entre la información de infraestructura basada en evidencia y un relato de interrupción construido con multiplicaciones sin respaldo.

6. Rendición de cuentas mediante la asignación de control

La rendición de cuentas es más sólida cuando pregunta quién controló cada decisión, implementación y acción de recuperación importantes. Se debilita cuando trata la proximidad al primer evento visible como prueba de responsabilidad exclusiva.

Dominio de control	Qué controlaba el participante	Qué no controlaba el participante	Evidencia necesaria para una evaluación más sólida
RIPE NCC	Uso de la infraestructura del RIS, originación visible en Internet, calendario, comunicación, supervisión, retirada, conservación de evidencia y política de experimentos futuros	El comportamiento del software en cada enrutador externo y la recuperación de cada operador	Registro de aprobaciones, evaluación de riesgos, plan de aviso, umbrales de supervisión, criterios de retirada y observaciones conservadas
Investigadores de Duke	Diseño de la investigación, construcción del atributo experimental, cambios de Quagga del lado de la investigación y pruebas del lado de la investigación	El código IOS XR desplegado, las políticas de sesión del tramo receptor y el despliegue de software de los operadores	Vectores de prueba, bytes del UPDATE generado, registros de la implementación de investigación y el alcance de las pruebas de interoperabilidad
Cisco	Análisis, almacenamiento y comportamiento de propagación de IOS XR; cobertura de pruebas del producto; divulgación; correcciones de mantenimiento	La decisión de originar el experimento y los calendarios de instalación de los operadores	Análisis del defecto, matriz de versiones afectadas, resultados de regresión, evidencia del código corregido y guía de despliegue
Operadores de red	Software instalado, mantenimiento, política de importación y exportación, controles de pares, filtrado, supervisión y restauración dentro de sus redes	El diseño experimental, el código del proveedor en el tramo ascendente y la ruta de propagación global completa	Registros de dispositivos, capturas de paquetes, configuraciones, versiones de software, historial de sesiones y registros de restauración
Implementaciones BGP receptoras	El manejo local del UPDATE mal formado según las reglas que implementaban	La creación del atributo válido original o la corrupción en el tramo ascendente	Registros de errores de UPDATE, notificaciones de sesión y prueba de un manejo más limitado donde esté soportado
Puntos de intercambio de Internet	La conectividad a través de la cual las redes participantes intercambiaban rutas	Por defecto, el contenido y la corrección del anuncio BGP de cada participante	Evidencia de cualquier función específica de servidor de rutas, filtrado u operativa antes de asignar más control

El control de RIPE NCC

RIPE NCC controló el acto que introdujo la ruta experimental en la propagación pública. El AS12654 del RIS fue el origen utilizado para la prueba, y el anuncio atravesó las conexiones de RIPE NCC en AMS-IX y GN-IX.[1] RIPE NCC también controló la retirada planificada, su recopilación de evidencia y sus reglas futuras para investigaciones cooperativas similares.

Ese control establece la rendición de cuentas de la gobernanza del experimento. No establece que RIPE NCC creara el defecto del producto. El atributo inicial se describió como válido. La pregunta relevante para RIPE NCC no es si debía haber predicho con certeza el fallo exacto no documentado. Es si la incertidumbre del experimento se evaluó, comunicó, supervisó y contuvo en proporción a su posible alcance público.

El compromiso posterior de realizar una evaluación de impacto más completa, avisar con antelación a los operadores y manejar las vulnerabilidades de forma responsable indica que RIPE NCC identificó por sí misma mejoras de gobernanza.[1] El apoyo del Consejo Ejecutivo a la continuación de la experimentación con una comunicación adecuada refuerza la distinción entre la legitimidad de la investigación y la idoneidad de sus controles operativos.[5]

El control de Duke

Los investigadores de Duke controlaron el diseño de la investigación sobre enrutamiento seguro y suministraron la modificación de Quagga utilizada dentro de su alcance. Su trabajo ayudó a crear la entrada experimental válida. El registro disponible no muestra que controlaran el manejo interno de IOS XR ni la respuesta de error de los enrutadores receptores.

La rendición de cuentas del lado de la investigación se refiere a las suposiciones de diseño y a la amplitud de las pruebas de interoperabilidad. Una segunda instancia de Quagga podía demostrar el comportamiento en un entorno de software similar. No podía establecer la seguridad en todas las implementaciones desplegadas relevantes.

La evidencia pública no revela la división completa de las decisiones previas al evento entre Duke y RIPE NCC. Sería inapropiado inventarla. Cualquier asignación más granular requeriría planes de experimento, registros de pruebas y comunicaciones que identifiquen quién aprobó las condiciones de propagación pública.

El control de Cisco

Cisco controlaba la implementación afectada de IOS XR. Su aviso identificó la corrupción de un atributo transitivo válido no reconocido durante la propagación.[2] Ese comportamiento se sitúa dentro del dominio de control del producto: análisis, retención, serialización, tratamiento de los indicadores de atributo y pruebas de regresión.

Cisco también controló su respuesta de divulgación y mantenimiento. El aviso apareció el mismo día del incidente y se prepararon actualizaciones de mantenimiento de software.[2] CVE-2010-3035 proporciona el identificador público de vulnerabilidad.[3]

La rendición de cuentas del producto debe seguir basada en evidencia. El registro no establece todas las versiones desplegadas, el número de dispositivos afectados ni si el defecto se había descubierto antes. Una evaluación más sólida requeriría pruebas específicas por versión, historial del defecto y evidencia de instalación.

El control de los operadores

Cada operador de red controlaba una porción local del sistema: selección e instalación de software, calendario de mantenimiento, política de peering, filtros, supervisión, protección de sesiones y restauración. Estos controles podían afectar a la exposición y la recuperación.

Eso no hace responsables a los operadores de predecir un defecto de corrupción desconocido del proveedor. Tampoco demuestra que todos los operadores tuvieran un parche o una mitigación de configuración disponible antes del experimento. La rendición de cuentas del operador está condicionada a lo que era conocible y controlable en el momento relevante.

Después de la divulgación, la evidencia necesaria para la garantía continua cambia. Se puede pedir a los operadores que identifiquen versiones afectadas, apliquen correcciones, prueben el comportamiento y conserven pruebas. Antes de la divulgación, las afirmaciones sobre una inacción irrazonable requerirían evidencia de que el riesgo y una mitigación viable ya eran conocidos.

Por qué no debe asignarse a los puntos de intercambio un papel inventado

El experimento utilizó conexiones en AMS-IX y GN-IX.[1] Ese hecho establece una ruta de propagación. No establece, sin evidencia adicional, que alguno de los intercambios diseñara el experimento, aprobara el atributo, operara un enrutador afectado o controlara las políticas de exportación de los participantes.

La información sobre infraestructura confunde a menudo el tránsito físico o lógico con la autoridad de decisión. Un intercambio mencionado puede formar parte de la ruta sin ser el actor que originó, corrompió o aceptó el UPDATE. La rendición de cuentas no debe inferirse solo de la topología.

7. La reparación del producto y la reparación de la gobernanza del experimento son diferentes

Una respuesta completa requería dos vías de reparación.

Reparación del producto

El defecto del producto era la corrupción de un atributo transitivo válido no reconocido durante la propagación por parte de los sistemas IOS XR afectados. La reparación directa pertenecía al software y a sus pruebas.

Una reparación creíble del producto demostraría que:

se puede recibir un atributo transitivo opcional desconocido válido;
se almacena sin mutación destructiva;
se propaga en la forma requerida por el protocolo;
los indicadores de atributo y los campos de longitud relevantes permanecen coherentes;
el establecimiento repetido de la sesión no recrea la corrupción;
las variantes mal formadas se contienen según el comportamiento de manejo de errores soportado;
las pruebas de regresión cubren tanto las rutas de reconocimiento como las de propagación opaca; y
la versión corregida es identificable para los operadores.

El aviso de Cisco y las actualizaciones de mantenimiento fueron las acciones públicas inmediatas que abordaron esta capa.[2] Un aviso comunica el defecto; una actualización cambia la implementación. Ambas están relacionadas pero no son intercambiables.

La verificación también requiere evidencia de despliegue. Un proveedor puede demostrar que una compilación corregida supera las pruebas de regresión, mientras que un operador puede demostrar qué compilación se ejecuta en un enrutador concreto. Ninguno de los dos registros por sí solo establece tanto la corrección del producto como la adopción en el terreno.

Reparación de la gobernanza del experimento

El defecto de gobernanza no fue que se realizara investigación. Fue que se probara una interacción incierta a través de la infraestructura de enrutamiento pública sin controles suficientes para prevenir o limitar rápidamente el radio de impacto observado.

La respuesta de RIPE NCC identificó requisitos futuros más estrictos: evaluación integral del impacto, aviso previo suficiente para los operadores y tratamiento responsable de las vulnerabilidades.[1] Estos abordan las decisiones tomadas antes y durante un experimento.

Una reparación creíble de la gobernanza incluiría:

un objetivo técnico claramente acotado;
la identificación de cada atributo y ruta que se originará;
un límite de propagación documentado o una explicación de por qué se requiere una propagación más amplia;
pruebas de implementación heterogénea adecuadas al riesgo;
comunicación previa a los operadores afectados cuando sea factible;
una ventana de prueba definida;
observación de colectores de rutas en tiempo real;
sondas de plano de datos o de servicio cuando sean relevantes;
criterios cuantitativos de interrupción;
una persona autorizada capaz de retirar de inmediato;
un procedimiento de retirada ensayado;
criterios para contactar con los proveedores;
datos previos y posteriores al evento conservados; y
un relato público del incidente cuando se produzca un impacto externo no intencionado.

Los controles de gobernanza no pueden garantizar que nunca aparezca un defecto desconocido. Su propósito es reducir la probabilidad de que el descubrimiento produzca consecuencias externas no controladas y acortar el tiempo entre la detección y la contención.

Por qué una reparación no puede sustituir a la otra

Si Cisco corrigiera IOS XR pero los controles del experimento permanecieran sin cambios, un experimento posterior podría exponer un defecto desconocido diferente en otra implementación. El riesgo específico del producto disminuiría, mientras que el riesgo de descubrimiento permanecería.

Si RIPE NCC reforzara los controles del experimento pero el software afectado siguiera sin corregir, el tráfico ordinario de Internet que transportara otro atributo transitivo desconocido válido podría encontrar todavía el defecto latente. El riesgo de la prueba pública disminuiría, mientras que el riesgo del producto permanecería.

Por tanto, el evento exige dos preguntas de cierre independientes:

¿Está corregido y desplegado el defecto de implementación donde corresponde?
¿Están los futuros experimentos en vivo acotados, observables y gobernados de forma acorde con su incertidumbre?

Un informe que responda solo a una no ha demostrado una reparación completa.

8. Los estándares posteriores como contexto analítico, no como juicio retroactivo

Los estándares publicados después de agosto de 2010 ayudan a describir mejores prácticas de contención y política. No demuestran que esas prácticas estuvieran desplegadas durante el evento, ni pueden convertir retroactivamente recomendaciones posteriores en un hallazgo de negligencia.

RFC 4271: la línea base histórica

La RFC 4271 describe BGP-4, incluidos los atributos transitivos opcionales y el manejo de errores.[12] Sus reglas de propagación explican por qué un atributo transitivo no reconocido debe transportarse. Su manejo de errores de UPDATE también ayuda a explicar por qué un atributo mal formado podía conducir a la terminación de la sesión.

Esa combinación produjo una interacción peligrosa. La extensibilidad dependía de una propagación opaca segura, mientras que una entrada mal formada podía activar una respuesta amplia. Cuando una implementación intermedia corrompió información opaca, el sistema receptor se enfrentó a una condición de error con consecuencias mayores que la de una sola ruta.

RFC 7606: reducción del dominio de falla

La RFC 7606 revisó más tarde el manejo de errores de UPDATE BGP porque el reinicio de la sesión puede descartar un gran número de rutas válidas y causar una perturbación sustancial del enrutamiento.[13] En general, promueve respuestas más limitadas, incluido tratar las rutas afectadas como retiradas en casos definidos, en lugar de destruir automáticamente toda la sesión.

Aplicada como contexto analítico, esto muestra cómo puede reducirse el dominio de falla. Si un anuncio mal formado puede contenerse en la ruta afectada mientras la sesión y las rutas no relacionadas permanecen, un atributo corrompido tiene menos poder para desestabilizar una adyacencia.

Sería inexacto decir que la RFC 7606 era la regla que regía el evento de 2010. Se publicó más tarde. También sería inexacto suponer que todas las implementaciones actuales aplican cada recomendación de manera uniforme. La RFC explica una dirección de reparación arquitectónica; la evidencia de despliegue sigue siendo necesaria.

RFC 7454 y RFC 8212: política externa explícita

La RFC 7454 recopila recomendaciones de seguridad operativa para BGP, mientras que la RFC 8212 establece una expectativa de política explícita para los anuncios y la aceptación de BGP externo.[14][15] Juntas refuerzan un principio de control básico: las rutas externas no deben intercambiarse simplemente porque exista una sesión.

Las políticas explícitas de importación y exportación pueden reducir la propagación accidental y hacer auditables las relaciones previstas. En un experimento acotado, una política cuidadosamente definida podría ayudar a limitar qué pares reciben una ruta de prueba.

Estas medidas no corrigen directamente un enrutador que corrompe un atributo que debe propagar. Operan en el límite de la política, no dentro de la ruta de serialización defectuosa. Pueden reducir la exposición, pero solo si la ruta o la sesión pueden distinguirse y restringirse sin frustrar el objetivo legítimo del experimento.

RFC 7908: taxonomía de fugas de rutas

La RFC 7908 describe tipos de fugas de rutas.[16] Es útil aquí principalmente como frontera contra la terminología laxa. El evento de 2010 implicó una ruta experimental originada intencionadamente y un defecto de implementación que afectaba a un atributo transitivo opcional. La evidencia disponible no debe estirarse para situarlo en una categoría de fuga posterior sin que coincidan las condiciones de la categoría.

La taxonomía respalda la rendición de cuentas cuando impide fusionar mecanismos no relacionados. La socava cuando una etiqueta familiar sustituye al análisis causal.

Validación de origen RPKI

La RFC 6480 describe la arquitectura de la Infraestructura de Clave Pública de Recursos y la RFC 6811 define la validación de origen de prefijos BGP.[17][18] La validación de origen pregunta si un sistema autónomo de origen está autorizado por una Autorización de Origen de Ruta relevante para un prefijo.

Ese control aborda una pregunta distinta de la expuesta aquí. Una ruta puede tener una relación de origen aceptable y, al mismo tiempo, transportar un atributo que un producto intermedio corrompe después. La validación de origen no demuestra que cada atributo de ruta esté correctamente codificado o preservado.

No es necesaria ninguna conclusión sobre el estado RPKI real del experimento. El punto analítico es limitado: la validación de origen, por sí sola, no probaría la ruta de manejo saliente afectada.

BGPsec

La RFC 8205 especifica la validación de rutas BGPsec.[19] BGPsec aborda la protección criptográfica de la información de ruta en una arquitectura definida. Está relacionada con el objetivo más amplio de enrutamiento seguro estudiado por el grupo de Duke, pero no es evidencia de lo que estaba desplegado durante este experimento de 2010.

Tampoco debe presentarse como una corrección automática de todos los defectos de implementación. Los mecanismos de seguridad se implementan a su vez en software. El análisis seguro, la serialización, la contención de fallos y las pruebas de interoperabilidad siguen siendo necesarios.

Guía de seguridad de enrutamiento del NIST

La publicación NIST SP 800-189 proporciona orientación posterior para asegurar el intercambio de tráfico interdominio, incluidas las protecciones de enrutamiento y las prácticas operativas.[20] Es útil para estructurar las expectativas actuales en torno al filtrado, la supervisión, la validación y la respuesta.

No establece un deber legal en 2010 ni demuestra lo que sabía cada participante en ese momento. Su uso adecuado es prospectivo: preguntar qué evidencia debería conservar ahora una red y qué controles pueden reducir cadenas de fallos similares.

9. Contrafactuales: ¿qué hecho modificado habría reducido el impacto?

El análisis contrafactual es útil solo cuando cada escenario cambia una condición definida y preserva el resto de la evidencia. No puede demostrar qué habría ocurrido con certeza, pero puede identificar controles de alto valor.

Contrafactual 1: IOS XR conserva el atributo correctamente

Cambie un hecho: los sistemas IOS XR afectados reciben el atributo transitivo válido no reconocido y lo propagan sin corrupción.

El UPDATE mal formado en el tramo descendente no surge de esa ruta de producto. El mecanismo de reinicio de sesión atribuido al UPDATE corrompido no se activa por este defecto. El anuncio sigue siendo inusual y experimental, pero la cadena de fallos documentada se interrumpe en su principal punto de implementación.

Este es el contrafactual de producto más fuerte porque elimina el mecanismo de corrupción identificado. No demuestra que ninguna otra implementación hubiera reaccionado mal.

Contrafactual 2: las pruebas heterogéneas reproducen el comportamiento desplegado

Cambie un hecho: las pruebas previas a la publicación incluyen una implementación afectada suficientemente representativa y activan la corrupción saliente.

El defecto puede investigarse antes de que la ruta entre en la propagación pública amplia. Cisco puede recibir el caso de prueba, mientras que RIPE NCC y Duke pueden decidir si posponer, restringir o rediseñar el experimento.

La limitación es la representatividad. Ningún laboratorio puede reproducir todas las rutas de Internet. El valor reside en ampliar más allá de dos extremos Quagga similares y probar específicamente el comportamiento de recepción y propagación opaca entre implementaciones distintas.

Contrafactual 3: el experimento se realiza en un entorno de enrutamiento acotado

Cambie un hecho: el mismo atributo y el software afectado interactúan en un entorno de prueba cerrado o estrictamente controlado, en lugar de a través de la propagación pública ordinaria.

El defecto puede seguir reiniciando una sesión, pero el número de rutas no relacionadas y de redes externas expuestas puede limitarse. La evidencia puede capturarse en cada salto.

La limitación es el realismo. Un entorno acotado puede no reproducir la topología, la política o las combinaciones de software que se encuentran en la Internet pública. Por eso es preferible una escalada por etapas: comenzar con diversidad acotada y ampliar solo cuando el riesgo y la evidencia lo justifiquen.

Contrafactual 4: los enrutadores receptores utilizan un manejo de errores de UPDATE más limitado

Cambie un hecho: un enrutador receptor contiene el anuncio mal formado sin cerrar toda la sesión BGP, cuando es aplicable una respuesta limitada de estilo posterior.

La ruta experimental puede descartarse, pero las rutas válidas no relacionadas aprendidas por la sesión permanecen disponibles. La amplificación de actualizaciones y la presión de reconvergencia deberían ser materialmente menores.

Este contrafactual refleja la dirección formalizada más tarde en la RFC 7606.[13] Debe permanecer analítico porque esa RFC es posterior al evento y el manejo exacto depende de la clase de error y de la implementación.

Contrafactual 5: el aviso previo llega a los operadores afectados

Cambie un hecho: los operadores reciben un aviso técnico suficiente del prefijo, el atributo, la ventana, el comportamiento esperado y las condiciones de parada.

Algunos operadores pueden supervisar más de cerca las sesiones relevantes, preparar al personal, restringir la exposición o coordinarse rápidamente después de que aparezcan anomalías. El diagnóstico puede acelerarse porque la ruta se reconoce como un experimento y no como un evento inexplicado.

El aviso no repara IOS XR. También puede requerir un manejo cuidadoso de las vulnerabilidades si se espera que una prueba exponga comportamientos inseguros. La comunicación es, por tanto, un control de mitigación y coordinación, no un mecanismo completo de contención.

Contrafactual 6: criterios cuantitativos de interrupción desencadenan una retirada más temprana

Cambie un hecho: la supervisión identifica tasas de actualización anormales o reinicios de sesión lo bastante pronto como para cruzar un umbral de parada predefinido antes de las 09:08 UTC.

RIPE NCC retira antes. La originación continua termina antes, lo que puede reducir las repeticiones y el tiempo de exposición.

La limitación es el estado distribuido de BGP. Las actualizaciones ya propagadas seguirían requiriendo retirada y reconvergencia. Una acción más temprana podría reducir la duración, pero no restauraría instantáneamente todas las rutas afectadas.

Contrafactual 7: la política limita la propagación a pares seleccionados

Cambie un hecho: las políticas de importación y exportación restringen la ruta experimental a redes explícitamente participantes.

El dominio de falla se reduce y los operadores participantes pueden capturar evidencia. Esto se alinea con el énfasis posterior en la política externa explícita.[14][15]

La limitación es la pregunta de investigación. Si el objetivo requiere observar implementaciones públicas diversas, la contención estricta cambia lo que puede aprenderse. Esa compensación debe hacerse explícitamente y no darse por resuelta.

Contrafactual 8: los colectores de rutas y las sondas de servicio proporcionan alarmas correlacionadas inmediatas

Cambie un hecho: las observaciones del plano de control, la telemetría de sesión y las sondas de servicio relevantes se correlacionan en tiempo real.

Los investigadores pueden distinguir antes un anuncio novedoso inofensivo de la amplificación de actualizaciones, la invisibilidad de prefijos y los efectos en el servicio. La decisión de retirada se basa en evidencia.

Esto no impide la primera corrupción. Mejora la detección y acorta el intervalo en el que persiste la incertidumbre.

Contrafactual 9: el experimento nunca se produce

Cambie un hecho: no se realiza ningún anuncio público.

El desencadenante del 27 de agosto desaparece, por lo que este evento no expone el defecto. Sin embargo, el fallo del producto puede permanecer latente y podría activarse más tarde por otro atributo desconocido válido.

Este contrafactual aclara por qué «no experimentar» no es una estrategia de seguridad suficiente. Evitar la prueba evita este incidente, pero no corrige el software en ejecución. El mejor objetivo es el descubrimiento seguro: experimentos acotados combinados con la reparación del producto.

10. Cómo sería una reparación verificable

Una afirmación de reparación debe estar vinculada a artefactos y observaciones, no a garantías.

Evidencia del producto

Para la implementación afectada, la evidencia creíble incluiría:

las versiones de software corregidas exactas;
una descripción del proveedor de la ruta de manejo defectuosa con un nivel de detalle apropiado;
pruebas de regresión con atributos transitivos opcionales desconocidos válidos;
pruebas que muestren una propagación que conserve los bytes o sea conforme de otro modo;
pruebas con variantes mal formadas o deliberadamente corrompidas;
evidencia de que el manejo de errores limitado soportado preserva las rutas no relacionadas cuando corresponde;
pruebas repetidas de ciclos de sesión para detectar recurrencia;
registros de los operadores que identifiquen las versiones instaladas; y
observaciones posteriores a la instalación que muestren que el defecto ya no se reproduce.

El CVE público y el aviso identifican el problema y la respuesta.[2][3] Son el comienzo de la verificabilidad, no toda la prueba del cierre en el terreno.

Evidencia del experimento

Para un futuro experimento de enrutamiento en vivo, la evidencia creíble incluiría:

el prefijo y el origen de la prueba;
la codificación del atributo propuesta;
los pares participantes y el alcance de propagación previsto;
resultados de interoperabilidad entre implementaciones materialmente diferentes;
una evaluación de impacto que abarque las consecuencias en el plano de control y en los servicios;
un registro de aviso previo;
umbrales de parada cuantitativos;
una autoridad de retirada inmediata;
un ensayo de retirada;
supervisión de colectores en vivo;
comprobaciones relevantes del plano de datos o del servicio;
marcas de tiempo de anomalías y decisiones;
datos UPDATE conservados; y
un relato posterior al evento que compare el comportamiento esperado y el observado.

RIS y Route Views ilustran el valor de múltiples puntos de observación de enrutamiento.[7][11] No sustituyen los registros de dispositivos ni las capturas de paquetes, pero pueden mostrar de forma independiente si un anuncio se propagó, si las retiradas se multiplicaron y si los efectos difirieron según el punto de observación.

Evidencia del operador

Un operador que afirme que su red está protegida debería poder mostrar:

si el software IOS XR afectado está o estuvo presente;
qué versión correctiva está instalada;
cómo se define la política de rutas externas;
cómo maneja el software actual los UPDATE mal formados;
cómo se detectan los reinicios de sesión;
cómo se mide la pérdida de rutas no relacionadas;
qué protecciones de pares están habilitadas;
cómo se registran las decisiones de restauración; y
si se ha completado una prueba de regresión controlada.

Esta es la continuidad operativa en forma concreta. Una declaración de configuración sin evidencia de la versión en ejecución está incompleta. Una versión de software sin evidencia de política y observación también está incompleta.

Criterios de cierre

El evento puede considerarse técnicamente comprendido cuando los bytes originales, la mutación intermedia y la respuesta en el tramo descendente estén vinculados por evidencia. El problema del producto puede considerarse reparado cuando el software corregido supere las pruebas de regresión relevantes y se demuestre su despliegue donde sea necesario. El problema de gobernanza puede considerarse reparado cuando un experimento futuro no pueda realizarse sin un alcance, un aviso, una supervisión, una autoridad de detención y una conservación documentados.

Estos criterios de cierre están deliberadamente separados. Un informe público de incidentes debe indicar cuáles se cumplen y cuáles siguen siendo desconocidos.

11. Evidencia que alteraría la conclusión

La conclusión actual depende de la evidencia. Varios descubrimientos exigirían una revisión material.

Capturas de paquetes que muestren que el atributo inicial era mal formado

Si capturas autoritativas demostraran que el AS12654 del RIS originó un atributo mal formado antes de llegar a un sistema IOS XR afectado, la conclusión de que una entrada válida fue corrompida por primera vez durante la propagación tendría que cambiar.

La responsabilidad se desplazaría hacia la generación y la validación previa al anuncio, aunque cualquier mutación o amplificación adicional seguiría requiriendo un análisis separado. El requisito clave sería una comparación de bytes de extremo a extremo: lo que transmitió el origen, lo que recibió cada sistema intermedio y lo que emitió.

Registros de dispositivos que identifiquen un punto de corrupción diferente

Si registros o capturas mostraran que otra implementación, servidor de rutas o intermediario creó la corrupción, la atribución del producto necesitaría revisión. Un aviso de Cisco puede identificar un defecto real sin demostrar que el mismo defecto explica todas las rutas observadas.

El evento pudo contener más de un modo de fallo. Solo la evidencia específica de cada ruta puede establecer si todos los reinicios compartieron un único punto de corrupción.

Datos de colectores que revisen materialmente las estimaciones de impacto

Si los datos conservados de los colectores mostraran que la línea base, el número de prefijos afectados o la duración fue materialmente diferente, la evaluación del impacto acotado debería actualizarse. Las correcciones podrían aumentar o reducir el alcance medido.

Una revisión no cambiaría automáticamente el mecanismo de implementación. La causa y la magnitud son preguntas probatorias relacionadas pero independientes.

Registros de aprobación y riesgo que muestren controles adicionales

Si los registros completos del experimento mostraran controles sustanciales de contención, notificación o parada no visibles en el relato público, la evaluación de gobernanza debería reconocerlos. Entonces habría que explicar por qué esos controles no impidieron ni acortaron la perturbación observada.

A la inversa, los registros que mostraran que se aceptaron riesgos de alto impacto identificados sin mitigación reforzarían la crítica de gobernanza. El relato público por sí solo no establece ninguno de los dos escenarios.

Registros del producto que muestren una identificación previa y un control eficaz

Si los registros de pruebas del producto demostraran que el defecto se había identificado y controlado eficazmente antes del experimento, la cronología y la asignación de responsabilidad cambiarían. Los investigadores tendrían que preguntar si los sistemas desplegados afectados carecían de una corrección disponible, si los operadores habían recibido un aviso aplicable y si el comportamiento observado provino de otro mecanismo.

El registro actual no establece tal identificación previa.

Evidencia de un impacto en el servicio más amplio o más limitado

Mediciones de tráfico completas, registros de operadores o telemetría de servicio podrían mejorar la evaluación de las consecuencias visibles para los usuarios. Podrían mostrar que la inestabilidad del plano de control causó más interrupción de aplicaciones de la documentada actualmente, o que la redundancia mantuvo la mayoría de los servicios disponibles a pesar del movimiento de rutas.

Esa evidencia cambiaría la sección de impacto, pero no justificaría reescribir la validez del UPDATE original sin pruebas a nivel de paquete.

12. Una conclusión mesurada

El experimento RIPE-Duke de 2010 no fue un secuestro de rutas malicioso convencional, y la evidencia disponible no respalda presentarlo como tal. Tampoco fue simplemente una prueba de estándares inofensiva que encontró enrutadores irracionales.

Fue un experimento de enrutamiento en vivo en el que un atributo transitivo opcional válido y desconocido se encontró con una implementación IOS XR afectada. Esa implementación corrompió el atributo mientras lo propagaba. Un enrutador receptor pudo entonces responder al UPDATE mal formado reiniciando una sesión BGP, retirando rutas válidas no relacionadas y contribuyendo a reconvergencias repetidas. Las mediciones de RIPE captaron una perturbación acotada pero material: tasas de actualización excepcionales, invisibilidad adicional de prefijos y un pico de casi 4.500 prefijos inestables.[1][2]

El evento expuso dos defectos en dominios de control diferentes. Uno era un defecto de producto en el manejo de información de enrutamiento opaca válida. El otro era una debilidad de gobernanza del experimento: unas pruebas previas a la publicación limitadas y una exposición pública insuficientemente acotada permitieron que una interacción desconocida se convirtiera en un incidente de enrutamiento de Internet.

El aviso y las actualizaciones de mantenimiento de Cisco abordaron el defecto del producto. La investigación de RIPE NCC, la conservación de evidencia y los compromisos futuros más estrictos con los experimentos abordaron el defecto de gobernanza. Los estándares posteriores aportaron una mejor contención de errores y orientación de políticas, pero son contexto, no prueba retroactiva.

La lección más duradera se refiere al control. El cumplimiento de los estándares en el origen no garantiza un comportamiento seguro de extremo a extremo. Un registro o un colector de rutas puede identificar quién anunció un prefijo y mostrar cómo cambió la visibilidad, pero no puede obligar a cada implementación intermedia a preservar un atributo correctamente. Los proveedores deben demostrar que el código en ejecución es seguro. Los iniciadores de experimentos deben acotar las pruebas públicas inciertas. Los operadores deben conocer su software, sus políticas y su estado de recuperación.

Los sistemas de observación deben conservar evidencia suficiente para distinguir desencadenante, corrupción, amplificación e impacto.

La rendición de cuentas no se logra nombrando a la primera organización de la cronología. Se logra asignando cada control importante a un propietario y exigiendo evidencia de que la reparación correspondiente funciona.