Error BGP de Level 3 en 2017 y responsabilidad del backbone

Resumen

Límite del suceso:El 6 de noviembre de 2017, la monitorización independiente vinculó una interrupción de conectividad de gran escala de Comcast a cambios de enrutamiento asociados con Level 3 Communications y AS3356. ThousandEyes situó el impacto principal observado en Comcast aproximadamente entre las 09:45 y las 11:25 de hora del Pacífico, con inconsistencias de enrutamiento visibles desde alrededor de las 09:30. [2] Informes contemporáneos recogieron la declaración de Level 3 de que un problema de configuración causó la interrupción. [1][5][6] Este artículo no combina el suceso con la salida de 2016 de Level 3, la interrupción de CenturyLink de diciembre de 2018 que afectó al transporte y al servicio de 911, o el incidente FlowSpec de AS3356 de agosto de 2020.
Mecanismo observado:ThousandEyes informó anuncios más específicos para más de mil prefijos de subsidiarias y clientes de Comcast y observó tráfico que antes cruzaba el backbone AS7922 de Comcast y que ahora era dirigido a través de Level 3 AS3356, con mayor pérdida de paquetes y latencia. [2] Esto es evidencia sólida de una falla de política de enrutamiento y de sus consecuencias de encaminamiento. No revela el comando interno exacto, el objeto de política de rutas generado, el proceso de despliegue o el conjunto completo de usuarios afectados.
Límite de responsabilidad:Level 3 controlaba la generación de su configuración, su aprobación, el alcance de despliegue, la política de exportación BGP, el monitoreo de rutas, la autoridad de rollback y la comunicación del incidente. Los pares y las redes descendentes controlaban la política de importación, las expectativas del cono de clientes, los límites de prefijos, la detección de anomalías y las decisiones de failover. Comcast controlaba la comunicación con sus suscriptores y partes de la ruta de recuperación orientada al usuario. Los clientes y usuarios finales podían observar el fallo pero no reparar el estado de enrutamiento interdominio.
Lección de control:Una configuración puede ser sintácticamente válida y, aun así, violar una invariancia operativa. El control de cambios del backbone debe probar la alcanzabilidad prevista, el alcance de exportación, los cambios de ruta y el radio de impacto antes del despliegue, y luego comparar el estado de rutas en vivo y la accesibilidad de usuario con esas expectativas. Batfish utilizó el suceso para defender la validación de red basada en modelos en lugar de confiar solo en revisiones manuales. [3]
Capa de realidad:Los registros de registro y ASN ayudan a identificar recursos y operadores responsables, pero no imponen política BGP. Los recolectores de rutas muestran qué rutas están anunciando y aceptando las redes en ejecución; las sondas de reenvío muestran si el tráfico alcanza el destino previsto. La responsabilidad depende de conectar la política prevista, los anuncios en ejecución, las trayectorias de paquetes, los registros de rollback y la restauración visible para el usuario.

El incidente debe quedar acotado al 6 de noviembre de 2017

El primer requisito de una reconstrucción con responsabilidad es definir qué suceso se está examinando. Level 3 y la posterior organización CenturyLink o Lumen aparecen en varios registros de grandes interrupciones. Combinar esos registros produciría una narrativa más larga, pero conclusiones más débiles porque los mecanismos, los responsables de control y la evidencia difieren.

Este artículo trata del evento BGP observado el lunes 6 de noviembre de 2017. ThousandEyes informó que sus empleados usando conexiones de Comcast encontraron fallos en servicios como Slack, Gmail y Webex. Sus mediciones ubicaron el impacto principal de Comcast desde aproximadamente las 09:45 hasta las 11:25 de hora del Pacífico. También identificó inconsistencias en BGP desde alrededor de las 09:30, antes del intervalo de impacto visible al usuario que describió. [2]

Wired informó que un error de configuración de Level 3 afectó partes del acceso a Internet en EE. UU. y que el proveedor indicó que el servicio se restauró tras corregir el problema. [1] Otros informes contemporáneos describieron quejas generalizadas entre varios proveedores de acceso y aportaron una explicación de Level 3 centrada en un problema de configuración. [5][6] Esas fuentes establecen una señal amplia de impacto público, pero los mapas de quejas y los informes simultáneos no prueban que toda la red fallara por la misma causa técnica.

ThousandEyes proporciona el puente público más sólido entre el estado de ruta y la experiencia del usuario. Su análisis describió pérdida de paquetes dentro de rutas de Comcast y Level 3, cambios de ruta para destinos relacionados con Comcast y un retorno a la normalidad tras la retirada de las rutas filtradas por Level 3. [2] La revisión de seguridad de enrutamiento de APNIC también identificó el suceso como uno de los eventos de enrutamiento de gran escala destacados en 2017. [4]

Tres exclusiones son esenciales.

Primero, el suceso no es la salida de 2016 de Level 3. Ese evento independiente, posterior, atrajo escrutinio regulatorio y sectorial y utilizó un mecanismo diferente. [8] Segundo, no es la interrupción de CenturyLink de diciembre de 2018 que impactó el transporte y el servicio 911. Tercero, no es el incidente FlowSpec de AS3356 de agosto de 2020, en el que una acción de filtrado de tráfico se propagó por un backbone y generó un patrón de fallo distinto.

La historia compartida de operador puede apoyar preguntas de gobernanza comparativa. No puede sustituir la evidencia de un evento por la de otro. La conclusión de 2017 debe sostenerse en observaciones de ruta de 2017, la declaración del proveedor y evidencia contemporánea de trayectorias de usuarios.

AS3356 convirtió un cambio de configuración en un evento interredes

Un sistema autónomo es una red o grupo de redes que presenta una política de enrutamiento común ante internet. BGP permite a los sistemas autónomos intercambiar información de alcanzabilidad, incluidos los prefijos que alcanzan y la secuencia de sistemas autónomos representados en una ruta. El RFC 4271 define la mecánica del protocolo y el marco de decisión dentro del cual los operadores aplican políticas locales. [14]

Level 3 operaba AS3356, una red de tránsito global de gran escala. Los registros de RIPEstat proporcionan un recurso público y una vista de enrutamiento para ese ASN. [10] Un registro ASN ayuda a identificar al operador asociado a observaciones de ruta. No muestra cada contrato privado de peering, relación de clientes o política de enrutamiento activa durante un incidente.

La escala cambia la responsabilidad de la configuración. Una pequeña empresa puede anunciar un conjunto limitado de prefijos a un proveedor. Una red de tránsito grande intercambia rutas con proveedores de acceso, redes de contenido, empresas y otros carriers. Un error de política en esa posición puede influir en rutas más allá de los clientes directos de detalle minorista del operador.

Internet no tiene un controlador central que apruebe cada ruta. Cada red decide qué anunciar y qué aceptar. Ese diseño permite operación independiente, pero también significa que un anuncio incorrecto puede propagarse cuando varias redes lo consideran aceptable según sus políticas locales. Las consecuencias dependen de la especificidad del prefijo, los atributos de ruta, las relaciones comerciales, los filtros y el momento de la selección de ruta.

ThousandEyes describió que Level 3 anunciaba rutas más específicas asociadas con redes subsidiarias y clientes de Comcast. Se observó tráfico que antes había pasado por el backbone AS7922 de Comcast ahora pasando por AS3356. [2] Las rutas más específicas importan porque el encaminamiento sigue normalmente el prefijo más largo coincidente. Un anuncio que cubre un bloque de direcciones más estrecho puede atraer tráfico aunque un anuncio más amplio siga siendo visible.

La evidencia no significa que un solo router determinó toda internet. Significa que una red con alta interconexión originó o propagó información que bastantes redes aceptaron para producir cambios sustanciales de encaminamiento. Cada aceptación fue una decisión de política local, pero Level 3 controló el cambio que introdujo el estado de ruta observado.

Por eso un evento de backbone no puede tratarse como un detalle administrativo interno. Su salida práctica es un conjunto de afirmaciones consumidas por otros sistemas autónomos. Cuanto mayor es la huella de interconexión, mayor es la obligación de modelar el alcance de exportación, encadenar el despliegue y verificar el efecto externo.

La evidencia de BGP y la evidencia de reenvío responden preguntas distintas

Recolectores de rutas y sondas de trayectoria de usuario observan partes relacionadas, pero diferentes, del incidente.

Un recolector de rutas registra actualizaciones BGP de pares participantes. Los archivos históricos de RouteViews aportan datos de actualizaciones de noviembre de 2017. [11] De forma similar, el Servicio de Información de Enrutamiento de RIPE NCC recopila información de enrutamiento de puntos de observación en todo el mundo. [12] BGPStream de CAIDA proporciona herramientas e interfaces de datos para analizar eventos de BGP. [13]

Estos sistemas pueden ayudar a reconstruir cuándo se anunció o retiró un prefijo, qué origen y ruta apareció en un recolector y cómo cambió la visibilidad con el tiempo. No pueden ver todas las rutas de todos los routers. Una ruta no visible en un recolector puede haber existido en otro lugar. Una ruta visible puede no haber llevado tráfico sustancial. La preferencia local, la ingeniería de tráfico y el peering privado pueden producir comportamientos de reenvío no representados plenamente en los feeds públicos de recolectores.

Las mediciones de reenvío y aplicaciones añaden otra capa. ThousandEyes informó cambios de path, latencia y pérdida de paquetes desde agentes distribuidos. [2] Esas mediciones muestran lo que experimentaron paquetes seleccionados desde ubicaciones seleccionadas. Están más cerca del impacto en usuario que una actualización de plano de control sola, pero tampoco representan a cada usuario o trayectoria.

Una investigación con responsabilidad une las capas:

la política de ruta prevista antes del cambio;
la diferencia de configuración exacta o la política generada;
anuncios y retiros de BGP vistos internamente;
anuncios observados por recolectores independientes;
trayectorias de reenvío en redes diversas;
pérdida de paquetes, latencia y transacciones correctas;
quejas de clientes y actualizaciones del estado del proveedor;
la acción de rollback o cambio correctivo;
confirmación independiente de restauración de enrutamiento y alcanzabilidad.

Sin esta unión, los equipos pueden clasificar el suceso de forma incorrecta. Una actualización de ruta puede ser visible sin causar daño material. Puede haber pérdida de paquetes sin una causa BGP. Una aplicación puede fallar porque DNS, identidad o una dependencia en la nube falló mientras su ruta permaneció estable.

La evidencia de 2017 es persuasiva porque observaciones de ruta y de reenvío apuntan en la misma dirección. ThousandEyes vio inconsistencias de ruta y cambios de AS path junto con mayor latencia y pérdida de paquetes. [2] El proveedor atribuyó la interrupción a configuración. [1][5][6] Esa combinación respalda una conclusión de mala configuración BGP, preservando la incertidumbre sobre la implementación interna.

La misma disciplina aplica a la recuperación. Que se retire una ruta en un recolector no basta para declarar restauradas todas las rutas de usuario. Los operadores deben confirmar estado de ruta estable, selección de ruta esperada, reducción de pérdida, normalización de latencia y transacciones de aplicación correctas en las regiones pertinentes.

La fuga de ruta es más precisa que el secuestro, pero sigue exigiendo atribución

La discusión pública suele usar route leak y route hijack de forma intercambiable. La distinción importa porque modela afirmaciones sobre intención, autorización y prevención.

El RFC 7908 define una route leak como la propagación de anuncios más allá de su alcance previsto. [16] El documento describe categorías según relaciones entre redes y dirección en la que se propagan rutas. Una fuga puede ocurrir cuando un cliente exporta rutas aprendidas del proveedor a otro proveedor, cuando rutas internas se escapan o cuando una red anuncia información contraria a una relación comercial prevista.

Un route hijack suele referirse a un origen o ruta no autorizados que atrae tráfico, a veces de forma maliciosa. La evidencia pública para el 6 de noviembre de 2017 apoya un error de configuración inadvertido, no una inferencia de intención maliciosa. Los reportes contemporáneos describieron un problema de configuración, y ThousandEyes usó la terminología de route leak. [1][2][5][6]

Incluso la etiqueta de fuga debe vincularse con evidencia. Los observadores públicos no tenían acceso a la intención de política completa de Level 3, ni a contratos ni a configuraciones de routers. ThousandEyes observó anuncios más específicos y cambios de path incoherentes con el enrutamiento normal de Comcast. [2] Ese comportamiento es coherente con una fuga, y analistas identificados la calificaron de ese modo. El artículo debe preservar esa atribución en lugar de reclamar acceso a intención privada.

La terminología también afecta el análisis de control. Si el problema central es un origen no autorizado, la validación del origen de rutas puede cubrir parte del riesgo. Si el origen sigue autorizado pero el alcance de exportación viola una política de relación, la validación de origen aún puede marcar la ruta como válida. Si una ruta más específica está técnicamente autorizada pero operativamente errónea, la aceptación exige otros controles de política.

La conclusión más sólida, por tanto, es limitada: Level 3 reconoció un problema de configuración; mediciones independientes observaron cambios de rutas relacionados con AS3356 y deterioro de reenvío; los analistas caracterizaron el suceso como una route leak. Las fuentes no establecen sabotaje, compromiso de credenciales, intención de intercepción ni un comando interno exacto.

Ese límite no es evasivo. Evita que la incertidumbre técnica se convierta en acusación. También mantiene la remediación centrada en los controles que la evidencia respalda: validación de cambios, política de exportación, filtrado entre pares, monitoreo de rutas y rollback.

Una configuración sintácticamente válida puede seguir siendo operativamente incorrecta

Los sistemas de cambio de red suelen comprobar si el texto de configuración se analiza correctamente y si un dispositivo lo acepta. Esas comprobaciones son necesarias, pero no prueban que el comportamiento resultante de la red coincida con la política.

Una configuración BGP puede ser válida para un router y, sin embargo, violar una invariancia operativa. Puede exportar una ruta al vecino equivocado, aceptar una ruta de cliente fuera del conjunto esperado, crear una ruta más específica con alcance no previsto, alterar la preferencia o retirar un filtro. El router ejecuta el comando que recibió. El fallo está en la brecha entre validez sintáctica y estado operativo previsto.

El análisis de Batfish del evento de Level 3 defendió probar la configuración de red frente a propiedades previstas antes del despliegue. [3] La validación basada en modelos puede comprobar si destinos importantes siguen alcanzables, si aparecen rutas prohibidas, si rutas se escapan de su alcance previsto, si la redundancia sobrevive a una falla y si un cambio afecta a más dispositivos o prefijos de los esperados.

Eso no significa que un modelo pueda reproducir perfectamente internet. Los pares externos tienen políticas privadas, el estado de ruta cambia continuamente y algunas relaciones no están documentadas. Un modelo útil debe ser explícito sobre esos límites.

Por tanto, la cadena de control de cambios debe contener varias comprobaciones:

Control de fuente:la configuración o política propuesta se almacena como una diferencia revisable con un propietario identificado.
Validación de esquema y sintaxis:las herramientas confirman que la configuración se acepta y que las referencias apuntan a objetos válidos.
Invariantes de política:pruebas automáticas verifican alcance de exportación, prefijos aceptados, orígenes esperados, restricciones de path y alcanzabilidad.
Cálculo de radio de impacto:el sistema estima routers, sesiones, prefijos y clases de clientes potencialmente afectados.
Prueba representativa en staging:el cambio se prueba sobre estado de topología y política cercano a producción para revelar conflictos con sentido.
Despliegue canario:una parte observable y acotada recibe el cambio antes de un despliegue más amplio.
Telemetría independiente:recolectores de rutas, vistas de pares y sondas de reenvío comparan estado previsto y estado observado.
Condiciones de parada automáticas:cambios de recuento de rutas, de path, pérdida o latencia bloquean despliegue adicional.
Autoridad de rollback:un operador identificado puede revertir el cambio sin depender de una cadena de aprobación prolongada.
Verificación post-cambio:el equipo demuestra que las rutas y servicios esperados permanecen estables.

Ninguna comprobación elimina por completo el riesgo. En conjunto, reducen la probabilidad de que un error administrativo se convierta en un incidente de backbone.

La responsabilidad exige evidencia de que estos controles existían y operaban. Un postmortem que diga que hubo una configuración errónea no responde si el cambio tuvo revisión por pares, si las pruebas cubrían el comportamiento de exportación, qué alarmas se activaron o con qué rapidez se autorizó el rollback.

El radio de impacto debe ser una propiedad previa al despliegue

Los equipos operativos describen con frecuencia el radio de impacto después de un incidente contando servicios, prefijos o usuarios afectados. Para cambios de red de alta consecuencia, ese radio también debe estimarse antes del despliegue.

La cuestión no es solo cuántos dispositivos reciben una configuración. Un cambio aplicado a un objeto de política de ruta puede afectar muchas sesiones BGP. Un cambio en un router de borde puede alterar anuncios consumidos por un gran peer. Un prefijo más específico puede redirigir tráfico sin un gran recuento de dispositivos. Plantillas compartidas pueden convertir una línea en un comportamiento de flota.

La evaluación de radio de impacto previa al despliegue debería preguntar:

qué routers y sesiones hacen referencia al objeto modificado;
qué prefijos pueden encajar en la política;
qué vecinos pueden recibir anuncios nuevos o modificados;
si el cambio afecta de forma distinta a relaciones de cliente, peer y proveedor;
qué servicios críticos dependen de las rutas afectadas;
si el rollback por sí mismo generaría una gran ráfaga de actualizaciones;
si el monitoreo cubre los caminos externos más probables;
si un canario ofrece una muestra significativa del despliegue final.

La evaluación debe incluir incertidumbre. Si las políticas de peer son desconocidas, esa incertidumbre es motivo para limitar el despliegue inicial y reforzar el monitoreo externo. No es motivo para suponer que los peers contendrán el error.

ThousandEyes informó más de mil rutas más específicas en el evento de 2017. [2] La revisión anual de APNIC situó el suceso entre incidentes de seguridad de enrutamiento de gran escala que afectaron miles de sistemas autónomos en 2017. [4] Estas cifras son observaciones de análisis citados, no un recuento interno completo. Aun así, muestran por qué el recuento de rutas y la propagación externa deberían haber sido condiciones de parada.

El objetivo operativo no es garantizar cero actualizaciones de rutas. Las redes deben cambiar. El objetivo es hacer medible el alcance previsto y detectar cuando el estado en ejecución se aparta de él.

Para un backbone, la condición de parada puede combinar recuento de rutas, patrones nuevos de origen o path, cambios de exportación por peer, visibilidad en recolectores, pérdida de paquetes y alarmas de clientes. El umbral debería vincularse a la solicitud de cambio para que los respondedores sepan si una anomalía es esperada, tolerable o motivo de rollback.

Cuando ocurre un incidente, ese modelo de radio de impacto pasa a formar parte del registro de evidencia. Los investigadores pueden comparar alcance previsto y alcance real, identificar dependencias faltantes y mejorar la siguiente prueba.

El rollback es una capacidad de producción, no una frase en un plan

Un proceso de control de cambios está incompleto si el rollback solo existe como instrucción para restaurar la configuración anterior. El rollback de BGP también puede producir convergencia, retiros y cambios de tráfico. Debe diseñarse y probarse como una acción operativa.

El registro público dice que Level 3 corrigió el problema de configuración y ThousandEyes observó retirada de rutas filtradas alrededor de las 11:25 de hora del Pacífico. [1][2] No detalla quién autorizó el rollback, si la configuración previa se restauró de forma atómica, cómo convergieron los dispositivos o qué señales externas se usaron para confirmar la recuperación.

Esas incertidumbres definen la evidencia que un operador con responsabilidad debe conservar:

el identificador de cambio y la diferencia exacta;
inicio de despliegue, alcance y operador;
primera anomalía y alerta;
declaración del incidente y propietario del comando;
decisión de detener o revertir el despliegue;
comando de rollback o política de sustitución;
completitud por dispositivo y sesión;
retiro de ruta y reanuncio previsto;
recuperación de reenvío por región y par;
confirmación de cliente y proveedor de acceso;
intervalo de estabilidad posterior al rollback.

La velocidad de rollback no es la única métrica. Una reversión rápida que deje estado de ruta obsoleto o sobrecargue sesiones puede prolongar el daño. Una rollback escalonado más lento puede justificarse si evita un segundo fallo. El registro debe explicar la decisión y mostrar su efecto.

El equipo también necesita una vía fuera de banda para controlar la red si el enrutamiento de producción está degradado. La gestión que depende de la misma trayectoria en reparación puede convertir un error de routing en fallo de recuperación. Las evidencias públicas de 2017 no dicen que Level 3 perdió acceso de gestión. Este punto es un requisito de control derivado de la clase de fallo, no una afirmación específica del incidente.

Los clientes también necesitan un plan de rollback paralelo. Una empresa de tránsito que vea un fallo de ruta aguas arriba puede cambiar tráfico, modificar anuncios o invocar otro proveedor. Esas acciones pueden crear sus propios riesgos de propagación. El cliente debe definir quién puede actuar, qué rutas son independientes y cómo verificar que un failover no empeore el evento.

El rollback se vuelve creíble cuando los operadores demuestran que funciona en ejercicios y que la evidencia en vivo coincide con las etapas previstas. Una afirmación genérica de que la configuración se corrigió es solo un hecho inicial, no prueba completa de gobierno de recuperación.

Los pares también tenían controles de contención propios

La red que introdujo una ruta incorrecta es el principal responsable de ese cambio, pero el enrutamiento interdominios distribuye la responsabilidad. Cada peer decide qué acepta, qué prefiere y qué propaga.

El RFC 7454 describe prácticas operativas de seguridad para BGP, incluyendo filtrado de prefijos, filtrado de AS-path, límites y políticas sensibles a relaciones. [15] MANRS fija también expectativas de filtrado, coordinación, validación global y anti-spoofing entre operadores. [18]

La responsabilidad del peer no es igual en toda relación. Un proveedor tiene base más sólida para conocer el conjunto de prefijos esperado y el rol de enrutamiento de un cliente que un peer settlement-free. Un cliente puede no tener una lista completa de todas las rutas de cada proveedor. Las redes dinámicas grandes hacen más difícil mantener filtros estáticos. Los errores de política pueden ocurrir en cualquier lado.

Aun así, una red que acepta rutas debería poder explicar su modelo de confianza:

qué prefijos y orígenes se esperan de cada cliente;
si se permiten anuncios más específicos;
si un AS-path es consistente con la relación;
qué límites de recuento o máximo de prefijos aplica;
si anuncios inusuales activan alarmas o rechazo;
cómo se aprueban y expiran excepciones;
qué fuentes de datos independientes validan expectativas;
cómo se coordina de forma de emergencia con la red anunciadora.

La información de registro pública puede apoyar estos controles, pero puede estar desactualizada o incompleta. Los objetos de Internet Routing Registry, las autorizaciones RPKI y los paths observados responden a preguntas distintas. Los operadores no deben tratar una sola fuente como oráculo de política completo.

El suceso de 2017 muestra un problema de contención colectiva. Level 3 controló la configuración que produjo los anuncios observados. Otras redes aceptaron suficientes de esos anuncios para cambiar trayectorias de tráfico. Algunas pudieron tener razones operativas válidas con la información disponible para ellas. Otras quizá no tenían filtros que limitaran la propagación.

Una revisión con responsabilidad no debe atribuir culpa a peers sin sus configuraciones. Debe preguntar qué controles de contención estaban técnicamente disponibles, cuáles estaban en uso, qué alarmas se activaron y si ejercicios posteriores demuestran mejora.

La misma lógica protege contra transferencia de coste. Un backbone puede externalizar el efecto de un error de configuración hacia proveedores de acceso, redes de contenido y usuarios. Los peers pueden externalizar filtros débiles hacia el sistema de enrutamiento global. La evidencia compartida y la remediación coordinada son necesarias porque ningún operador controla cada decisión de aceptación.

RPKI ayuda con la autorización de origen, pero no en toda fuga

RPKI permite que los titulares de direcciones creen Route Origin Authorizations que identifican qué sistemas autónomos pueden originar prefijos concretos. La validación de origen de rutas clasifica una ruta según si su origen y longitud de prefijo son consistentes con una autorización válida. El RFC 6811 define ese estado de validación y cómo puede informar la política local. [17]

Es un control importante, pero su alcance debe describirse con precisión.

Si un sistema autónomo no autorizado origina un prefijo, una ROA válida puede ayudar a las redes a identificar y rechazar la ruta inválida. Si una route leak mantiene un origen autorizado pero viola el alcance de exportación, la ruta puede seguir siendo válida por origen. La validación RPKI de origen no codifica la relación comercial completa ni la ruta prevista.

El registro público de Level 3 no establece el estado de ROA para cada prefijo afectado en noviembre de 2017, la política ROV de cada peer ni un escenario contrafactual en el que un control habría evitado el incidente. Por ello, el artículo no afirma que RPKI habría detenido el evento.

RPKI forma parte del marco de remediación como una capa:

las ROA hacen explícita la autorización de origen;
la ROV puede rechazar algunos orígenes no autorizados;
los filtros de prefijos limitan qué puede anunciar un vecino;
la política de path sensible a relaciones limita la propagación de rutas;
los controles de máximo de prefijos limitan la cantidad;
la detección de anomalías identifica cambios inesperados;
la validación de cambios basada en modelos prueba el comportamiento de exportación previsto;
los recolectores y sondas de reenvío verifican resultados en vivo.

Mecanismos posteriores como BGP Roles y prevención de route leak pueden codificar de forma más directa parte de la frontera de relación. Deben evaluarse como controles posteriores, no afirmarse retroactivamente como ya desplegados en 2017.

El punto general de responsabilidad es que un control de seguridad debe adecuarse al modo de fallo. Etiquetar todos los problemas de BGP como una brecha de RPKI puede generar falsa tranquilidad. Una red puede tener autorización de origen completa y aun así exportar rutas válidas en la dirección equivocada o con una ruta más específica no prevista.

Los operadores deben informar el control que consideran habría interrumpido la cadena real. Si el fallo fue de generación de política, mostrar una nueva prueba de invariancia. Si el fallo fue un filtro de peer faltante, mostrar el filtro y el ejercicio de rechazo de ruta. Si un origen no válido se propagó, mostrar cobertura ROV. Cada afirmación debe vincularse con comportamiento observado.

Los registros de recursos son evidencia, no ejecución de ruta

La doctrina Heng.lu distingue de forma útil entre un registro y un sistema en ejecución.

Los registros ASN y de direcciones conservan identificadores, titulares de recursos, contactos e historial de traspasos. Los registros de enrutamiento pueden guardar política prevista. RPKI puede registrar la autorización de origen. Estos sistemas apoyan unicidad, trazabilidad, historiales de transferencia, metadatos de seguridad y coordinación.

No encaminan paquetes ni imponen toda la política de peers por declaración.

RIPEstat puede ayudar a un investigador a identificar AS3356 y ver datos públicos de enrutamiento. [10] RouteViews, RIPE RIS y BGPStream pueden mostrar anuncios observados por recolectores. [11][12][13] Esos registros forman parte del libro de responsabilidad. El sistema de enrutamiento en ejecución de cada red y la trayectoria de paquetes para clientes siguen siendo la capa de realidad.

Esta distinción evita dos errores.

El primer error es tratar el registro como prueba de operación sana. Un ASN correctamente registrado puede anunciar rutas bajo una política defectuosa. Los datos de recurso precisos no prueban que un cambio de configuración sea seguro.

El segundo error es tratar a los administradores de registro como controladores soberanos del enrutamiento interdominios. Los operadores eligen política local y ejecutan los routers. Los gestores de registros pueden mejorar la evidencia y el metadato de seguridad, pero no sustituyen la responsabilidad operativa.

Para el incidente de 2017, la cadena de evidencia debe conectar:

los recursos AS y direcciones registrados;
las políticas de relación previstas entre Level 3 y Comcast;
la diferencia de configuración que cambió el comportamiento de ruta;
estado de ruta interno;
anuncios observados por recolectores;
aceptación por peers;
trayectorias de reenvío reales;
pérdida y latencia visibles para usuarios;
retiro y restauración.

Ninguna capa es suficiente por sí sola. Una diferencia interna de configuración sin evidencia externa puede perder propagación. Una actualización de recolector sin intención no puede probar por qué apareció la ruta. Una queja de usuario sin datos de ruta no identifica el control fallido.

La doctrina es una regla práctica de gobernanza, no texto de advocacy. Señala que la responsabilidad debe seguir a las partes que operan el sistema en ejecución, mientras los registros precisos preservan quién controlaba recursos y qué política se había declarado.

La comunicación del incidente debe nombrar la capa fallida

Los usuarios que sufrieron la interrupción de 2017 vieron fallar o ralentizarse aplicaciones. Generalmente no vieron un objeto de política BGP, un AS path o la ruta que desvió tráfico.

Ese hueco hace de la comunicación del incidente parte del sistema técnico de control. Un mensaje que dice que hay una “interrupción de internet” es demasiado amplio para guiar a un proveedor de acceso, a una empresa o a una red de contenido. Un mensaje que dice que una configuración afectó el enrutamiento acota el problema. Una actualización útil va más lejos sin exponer detalles sensibles.

Un aviso con responsabilidad puede declarar:

la capa de red afectada;
la hora de inicio aproximada y la fuente de detección;
el alcance general conocido en ese momento;
si el operador detuvo cambios adicionales;
si las rutas se están retirando o restaurando;
qué clases de clientes o regiones de peers continúan afectadas;
qué evidencia definirá la restauración;
qué hechos permanecen sin confirmar.

Los reportes públicos llevaron la explicación de Level 3 de problema de configuración. [1][5][6] Eso resultó más informativo que un aviso de degradación no explicado. El registro público no muestra un informe posterior completo del proveedor con la secuencia interna y los cambios de control.

Los proveedores de acceso también tenían un deber de comunicación. Los usuarios de Comcast experimentaron fallos de servicio, y el análisis de ThousandEyes se centró en rutas de Comcast. [2] Comcast controlaba la relación con clientes y podía describir el impacto a sus suscriptores aunque no controlara la configuración de Level 3.

La comunicación debe preservar la incertidumbre. Informes de AT&T, Verizon, Spectrum y otras redes con problemas en tiempos similares no prueban una causa técnica común. [5][6] Un proveedor debe separar el impacto compartido confirmado de quejas correlacionadas todavía bajo investigación.

El mensaje de restauración también necesita evidencia. “Resuelto” debe significar más que que el cambio se revirtió. Debe estar respaldado por rutas estables, caminos esperados, pérdida normalizada y transacciones de clientes exitosas en un intervalo definido.

La comunicación precisa reduce coste operativo. Ayuda a clientes a decidir si hacer failover, conservar logs o esperar recuperación del upstream. También crea un registro con marcas de tiempo contra el que luego se pueden probar afirmaciones.

El impacto de usuario no debe inflarse más allá de rutas medidas

La cobertura contemporánea describió una interrupción amplia o nacional. ThousandEyes observó efectos en varias regiones de EE. UU. e informó que potencialmente se vieron afectados millones de usuarios de Comcast. [1][2][5][6] Esas fuentes establecen impacto material. No justifican afirmar que cada cliente de Comcast o cada proveedor reportado sufrió la misma interrupción.

La evaluación del impacto debe distinguir:

visibilidad de ruta en recolectores;
cambios de reenvío desde sondas específicas;
pérdida de paquetes y latencia;
incapacidad para alcanzar destinos nombrados;
quejas del servicio del proveedor de acceso;
fallos de transacciones de aplicación;
duración por geografía y red;
usuarios potenciales frente a sesiones fallidas confirmadas.

Una persona pudo tener una respuesta DNS en caché y una vía funcional mientras otra no alcanzaba el mismo servicio. Una empresa pudo usar un segundo proveedor de tránsito. Una app móvil pudo reintentar desde otro extremo. El mismo evento BGP puede producir resultados heterogéneos.

La fuente no contiene una cifra defensible agregada de pérdidas económicas. Tampoco establece una relación causal legal para cada interrupción empresarial. Este artículo no fabrica una cifra multiplicando estimación de usuarios por duración.

Un operador con telemetría interna puede hacerlo mejor. Puede informar cambios de tráfico, paquetes perdidos, sesiones fallidas, prefijos afectados, tickets de clientes y restauración por región. Los proveedores de acceso pueden medir efectos por sesión de suscriptor y nivel de aplicación. Grandes clientes pueden medir transacciones fallidas y pérdidas dependientes de servicio.

Esas medidas deben reconciliarse en lugar de colapsarse en un único número titular. El conteo de rutas mide estado de red. La pérdida de paquetes mide un síntoma de path. El volumen de quejas mide fricción visible. El fallo de transacción mide efecto de negocio. Cada métrica es útil cuando se declara su denominador y sus límites.

El rigor importa. Declaraciones infladas hacen más fácil que el informe sea descartado. Medidas acotadas identifican dónde fallaron los controles y qué remediación debe demostrarse.

La reconstrucción independiente tiene límites que deben documentarse

Los datos de ruta públicos son excepcionalmente valiosos porque permiten estudiar un incidente fuera del operador. Esa independencia genera responsabilidad, pero no omnisciencia.

RouteViews y RIPE RIS ven las rutas enviadas a sus recolectores por peers participantes. [11][12] BGPStream ayuda a investigadores a procesar y comparar esas observaciones. [13] RIPEstat combina vistas de recursos y enrutamiento. [10] ThousandEyes añade pruebas de reenvío y servicio desde puntos de vista distribuidos. [2]

Juntas, estas fuentes pueden establecer:

que rutas seleccionadas cambiaron;
qué orígenes y paths eran visibles;
el momento aproximado de anuncios y retiros;
si el tráfico seguía un path cambiado desde ubicaciones medidas;
si la pérdida o latencia aumentó;
cuándo se recuperó la alcanzabilidad medida.

Generalmente no pueden establecer:

el comando exacto introducido por un operador;
la cadena interna de generación de política;
cada ruta de cada router;
peering privado y decisiones de preferencia local;
el conjunto completo de clientes;
el responsable de la decisión de rollout o rollback;
alarmas internas y comunicaciones del incidente;
efectividad actual de remediación.

Un informe independiente debe etiquetar cobertura de recolectores, precisión de reloj, elecciones de normalización y datos ausentes. Debe preservar referencias de actualización brutas donde sea posible para que otro analista reproduzca la conclusión.

El operador debe retener un paquete más rico. Ese paquete puede incluir versiones de configuración, logs de dispositivos, evaluaciones de política de ruta, estado de route-reflectors, notificaciones a peers, telemetría, pruebas de ruta de paquetes, tickets de incidentes y aprobaciones de cambios. Los detalles sensibles pueden compartirse con auditores o socios afectados bajo controles.

La postmortem más creíble es la que conecta las vistas privadas y públicas. Explica por qué aparecieron anuncios observados, qué control interno falló, cómo se contuvo la ruta y qué prueba evita recurrencia.

Cuando el operador no publica esa evidencia, las observaciones independientes aún pueden sostener una conclusión limitada. No deben estirarse para rellenar huecos privados.

La remediación debe ser testeable frente a una falla de ruta reproducible

El registro público revisado aquí no establece toda la remediación que Level 3 o sus pares implementaron tras noviembre de 2017. Una evaluación responsable, por tanto, define qué evidencia demostraría reparación en lugar de afirmar éxito o fracaso actual.

Un programa de remediación testeable debe cubrir cinco grupos de control.

Generación y revisión de configuración

El operador debe mostrar que la política de enrutamiento se genera a partir de datos controlados, se revisa como diferencia y se comprueba frente a invariantes. La evidencia debe identificar qué clases de rutas y relaciones puede afectar un cambio.

Despliegue en fases y condiciones de parada

El operador debería desplegar mediante canary acotado donde sea posible, comparar anuncios en vivo con lo previsto y detener cuando el recuento de rutas, cambios de path, pérdida o latencia supere el límite aprobado.

Filtrado de peers y clientes

El operador y sus peers deben mantener políticas esperadas de prefijos y relaciones, probar el manejo de excepciones y vigilar anuncios más específicos inesperados. Los controles deben usar fuentes múltiples en lugar de asumir que un registro es completo.

Rollback y recuperación

Los equipos deberían ejercitar rollback, retirada de rutas, convergencia de sesiones y gestión fuera de banda. La recuperación debe confirmarse con observaciones independientes de ruta y reenvío.

Divulgación y verificación

Los informes posteriores deben distinguir causa confirmada, controles contribuyentes, alcance, incógnitas y remediación. Pruebas posteriores deberían demostrar si el nuevo control detecta o contiene una falla representativa.

Un ejercicio realista podría introducir en laboratorio o en un dominio de ruta aislado un error de política sintético y seguro. El error debería intentar exportar una ruta más específica fuera del alcance relacional previsto. El sistema debería rechazarla en generación o validación pre-despliegue. Si llega a canary, el monitoreo debe detener el despliegue. Una prueba de peer debería demostrar filtrado de importación. Una prueba de rollback debería retirar la ruta y confirmar reenvío esperado.

El ejercicio no debe inyectar rutas dañinas en internet público. Su objetivo es probar la cadena de control en un entorno representativo y preservar evidencia auditable.

La remediación es más fuerte cuando está vinculada a la ruta de fallo original. Una inversión genérica en monitoreo no prueba validación de política de exportación. Un programa nuevo de RPKI no prueba contención de fugas con origen válido. Un procedimiento revisado no prueba que el rollback funcione con churn de rutas.

Qué deben preguntar juntas directivas y compradores de servicio

El riesgo de enrutamiento de backbone puede parecer demasiado técnico para la supervisión de consejo. Las preguntas de gobernanza relevantes son concretas.

Las juntas directivas deberían preguntar cuántos cambios pueden alterar rutas anunciadas externamente, quién puede aprobarlos, qué invariantes pre-despliegue son obligatorias y qué condiciones automáticas de parada existen. Deberían pedir evidencia de ejercicios, no una etiqueta de madurez.

Los compradores de servicio deberían preguntar si sus proveedores monitorean rutas y reenvío fuera de su propia red, qué tan rápido notifican a clientes de incidentes de enrutamiento y si las rutas alternativas son operativamente independientes. Un contrato con dos carriers no prueba diversidad de ruta si ambos dependen del mismo backbone o la misma infraestructura compartida.

Los operadores de red deberían preguntar si los datos de registro, RPKI y rutas observadas se reconcilian, cómo se mantienen las expectativas de cliente-cono y cómo expiran excepciones. Deben saber qué peers pueden emitir conjuntos de rutas inusualmente amplios o más específicos.

Los líderes de incidentes deberían preguntar quién puede congelar despliegue, quién puede autorizar rollback y qué evidencia define recuperación. El camino de decisión debe seguir siendo usable cuando la red afectada está inestable.

Los auditores deberían muestrear configuraciones y rutas actuales en lugar de revisar solo documentos de política. Un control que existe en una norma pero se elude por plantillas o excepciones de emergencia no está operando eficazmente.

Los reguladores deberían evitar reducir la seguridad de enrutamiento a un mandato tecnológico único. La validación de origen, filtrado, verificación de cambios, monitoreo, coordinación y continuidad cubren modos de fallo distintos. Los requisitos de evidencia pueden ser conscientes de la tecnología sin fingir que un mecanismo resuelve todas las fugas.

Estas preguntas no suponen mala conducta. Siguen un control práctico. Un operador con evidencia sólida puede mostrar que un fallo inusual pasó un control razonable y se contuvo rápidamente. Un operador sin evidencia no puede sustituir la complejidad de BGP por una demostración de diligencia.

Las preguntas abiertas forman parte del hallazgo

La evidencia pública deja preguntas importantes sin respuesta:

¿Cuál fue la configuración o política generada exacta que introdujo las rutas?
¿Qué controles de revisión y validación se ejecutaron antes del despliegue?
¿A cuántos dispositivos y sesiones llegó el cambio?
¿Qué relaciones de peers se esperaba aceptaran o rechazaran los anuncios?
¿Qué alarma interna identificó primero la propagación inesperada?
¿Quién detuvo el despliegue y autorizó el rollback?
¿Cómo se verificaron los retiros de ruta y la recuperación de reenvío?
¿Qué peers modificaron filtros tras el evento?
¿Qué remediación se implementó y se ejercitó posteriormente?

Estas incógnitas no anulan el incidente observado. Definen el límite de la conclusión y la evidencia necesaria para fortalecerla.

El registro apoya una clase de causa raíz: Level 3 atribuyó la interrupción a configuración, mientras analistas independientes observaron una route leak y degradación de reenvío que involucró AS3356. [1][2][3][4][5][6]

Apoya condiciones contribuyentes: escala de backbone, aceptación de rutas entre redes, el alcance de rutas más específicas y límites de contención externos.

Apoya un evento de disparo solo a alto nivel: un cambio o fallo de configuración de enrutamiento. El comando exacto y la cadena de despliegue no se publicaron.

Apoya una cronología de detección y recuperación a partir de mediciones externas, pero no la línea de tiempo interna completa.

Eso importa. Causa raíz, condiciones contribuyentes, disparo, detección, respuesta y recuperación están relacionados, pero no son intercambiables. Un informe que califique “error humano” como causa raíz se detiene antes de examinar por qué un cambio pudo escapar de revisión, propagarse y requerir que observadores externos explicaran el fallo.

El estándar de responsabilidad es política declarada probada en ejecución

El incidente del 6 de noviembre de 2017 no fue solo un periodo en el que varios sitios parecían lentos. Fue un evento de enrutamiento interdominios en el que cambios de BGP observados externamente redirigieron tráfico y degradaron alcanzabilidad entre límites organizativos.

La evidencia pública más sólida está acotada. ThousandEyes informó cambios de ruta y de reenvío, anuncios más específicos asociados con redes de Comcast, mayor pérdida de paquetes y latencia, y retirada por alrededor de las 11:25 de hora del Pacífico. [2] Level 3 atribuyó la interrupción a un problema de configuración. [1][5][6] Batfish utilizó el suceso para mostrar por qué la política prevista debe modelarse antes del despliegue. [3] APNIC lo ubicó entre los incidentes de seguridad de enrutamiento de 2017. [4]

Las fuentes no revelan el comando interno exacto, todos los prefijos afectados y usuarios, todas las políticas de peers, la propiedad de decisión o la efectividad actual de remediación. No respaldan afirmaciones de intención maliciosa.

La responsabilidad sigue el control práctico. Level 3 controló el cambio y su política de exportación. Los peers controlaron la aceptación y contención. Comcast controló la comunicación con suscriptores. Los clientes podían diseñar rutas alternas y monitorización externa. Los usuarios finales podían reportar impacto, pero no reparar BGP.

La doctrina Heng.lu aporta la prueba final. Los registros ASN, de recursos y de política identifican recursos y preservan intención. Son libros de responsabilidad, no control de enrutamiento. Las rutas BGP en ejecución, las decisiones de peers, las trayectorias de reenvío y la recuperación observada determinan si la red honró esa intención.

Por tanto, una reparación creíble no es solo decir que existen filtros, RPKI o procedimientos de revisión. Debe haber evidencia de que una exportación deficiente representativa se rechaza o contiene, de que cambios de ruta inesperados detienen el despliegue, de que el rollback restaura paths esperados y de que pruebas independientes confirman la alcanzabilidad.

Para un backbone cuya configuración puede influir en miles de redes, la política prevista debe probarse en estado de ejecución. Ese es el estándar de responsabilidad que hace ineludible el evento BGP de Level 3 de 2017.

Error BGP de Level 3 en 2017: una prueba de responsabilidad para el control de cambio en backbone