Cloudflare, la fuga de rutas de junio de 2019 y la responsabilidad más allá del borde de la red

Resumen

• El 24 de junio de 2019, rutas optimizadas más específicas generadas dentro de la red de DQE Communications se pasaron a través del cliente AS396531 y fueron aceptadas por AS701 de Verizon. Verizon luego propagó rutas que abarcaban miles de redes. Como los enrutadores prefieren un prefijo de destino más específico, un tráfico sustancial siguió las rutas filtradas hacia enlaces que no estaban dimensionados para soportarlo; Cloudflare informó haber perdido aproximadamente el 15% de su tráfico global en el peor momento del incidente.
• El registro público de rutas respalda una cadena de fallos de control, no un eslogan de causa única. El generador de rutas no mantuvo sus rutas de optimización locales, un cliente multihomed exportó rutas aprendidas de un proveedor a otro proveedor, y una red de tránsito importante aceptó y difundió rutas que no se ajustaban a la autoridad de enrutamiento esperada del cliente. Cloudflare pudo detectar, comunicar y ayudar a retirar las rutas, pero no pudo cambiar unilateralmente la política de importación de otra red.
• La validación de origen de ruta RPKI se adaptó inusualmente bien a la parte de Cloudflare de este evento porque las autorizaciones de origen de ruta de Cloudflare permitían sus prefijos agregados solo hasta una longitud máxima establecida. Las rutas más específicas filtradas excedían esa longitud y, por lo tanto, eran inválidas. Esto no convierte a RPKI en una solución completa contra fugas de rutas: las rutas válidas en origen aún pueden violar las relaciones comerciales, por lo que el filtrado de clientes, los límites de prefijos, los roles BGP, los controles de ruta, la supervisión y los contactos de operaciones accesibles siguen siendo necesarios.
• La responsabilidad sigue a la capacidad de control. Los operadores que generan o exportan rutas excepcionales deben contenerlas y probarlas; los proveedores deben verificar lo que los clientes pueden anunciar; las plataformas en la nube deben publicar la autoridad de ruta, observar rutas externas, coordinarse rápidamente y divulgar el impacto en los clientes; los clientes deben planificar fallos de dependencia; y las juntas directivas y los reguladores deben exigir una garantía medida de seguridad de ruta en lugar de una declaración genérica de que se sigue la mejor práctica de la industria.

Una interrupción de enrutamiento, no un fallo de los servidores de Cloudflare

A las 10:34:25 UTC del 24 de junio de 2019, los colectores públicos de BGP comenzaron a registrar rutas anómalas más específicas para el espacio de direcciones de Cloudflare. La última de las rutas de Cloudflare estudiadas desapareció a las 12:38:54 UTC. Elanálisis detallado de rutas archivadasde Cloudflare reconstruye ese intervalo a partir de datos de RIPE NCC y muestra una ruta notablemente consistente: AS13335 de Cloudflare, uno de sus proveedores de tránsito, AS33154 de DQE Communications, AS396531 de Allegheny Technologies y AS701 de Verizon. Otras redes luego aprendieron la ruta a través de Verizon.

La ruta es importante porque la interrupción no comenzó con un fallo en un centro de datos de Cloudflare o un despliegue de aplicación. Las máquinas de Cloudflare continuaron anunciando sus rutas agregadas ordinarias. El sistema de enrutamiento global simplemente aprendió rutas competidoras para piezas más pequeñas del mismo espacio de direcciones. Esas piezas más pequeñas ganaban la decisión de reenvío en muchas redes y dirigían los paquetes por una ruta no deseada. La congestión y la pérdida de paquetes se produjeron antes de que las solicitudes pudieran llegar al borde de Cloudflare.

Laexplicación del incidentecontemporánea de Cloudflare informó que aproximadamente el 15% de su tráfico global se perdió en el peor momento. Esa es una medición de la empresa, no un porcentaje de interrupción universal auditado de forma independiente. Describe el tráfico de Cloudflare, no el 15% de todo Internet. Sin embargo, la observación independiente respalda el mecanismo general y el impacto en múltiples servicios. ThousandEyes informó en suanálisis de rutas de redque los usuarios tuvieron dificultades para alcanzar servicios frontend de Cloudflare y algunos servicios de AWS durante aproximadamente dos horas, mientras que larevisión del incidentede Catchpoint registró problemas de rendimiento en varios servicios en línea nombrados alrededor de las 10:30 UTC.

La distinción entre disponibilidad de ruta y disponibilidad de servidor es importante para la responsabilidad. Una plataforma puede operar servidores saludables en muchos países y aún ser inalcanzable si el plano de control de enrutamiento dirige el tráfico a otra parte. Los clientes experimentan un resultado: tiempos de espera, errores y aplicaciones no disponibles. Sin embargo, la causa de ingeniería determina qué controles podrían haber evitado la pérdida y qué parte podría operarlos.

Elregistro de estado del eventode Cloudflare primero describió problemas de rendimiento de la red, luego identificó una posible fuga de rutas y más tarde dijo que la red responsable lo había solucionado. Las copias públicas de las actualizaciones de estado sitúan el aviso de investigación a las 11:02 UTC, la identificación a las 11:36 UTC y la supervisión tras la corrección a las 12:42 UTC. El archivo BGP muestra rutas anómalas antes del primer aviso de estado. Esa diferencia no es prueba de que Cloudflare ignorara un evento conocido durante 28 minutos. Es una pregunta útil de responsabilidad: ¿cuándo detectaron los sistemas automatizados tráfico anómalo, cuándo identificaron los ingenieros el enrutamiento externo como causa y cuándo tuvo la empresa suficiente confianza para notificar a los clientes?

No hay evidencia pública que muestre intención maliciosa, inspección de tráfico o compromiso de los sistemas de Cloudflare en este evento. Una fuga de rutas puede crear una oportunidad de intercepción, pero el daño de servicio observado aquí fue congestión y pérdida a lo largo de una ruta no deseada. Por lo tanto, el artículo trata el incidente como un fallo de disponibilidad e integridad de enrutamiento. No convierte una posible propiedad de seguridad de las fugas de rutas en una acusación de que se leyó el tráfico.

Cómo una optimización local se convirtió en una ruta global

Internet es un acuerdo entre sistemas autónomos más que una red despachada centralmente. Cada sistema autónomo utiliza el Protocolo de Puerta de Enlace de Frontera, o BGP, para decir a los sistemas vecinos qué prefijos IP puede alcanzar y a través de qué ruta AS. El protocolo central enRFC 4271otorga a los operadores una considerable libertad de políticas. Esa flexibilidad admite el peering comercial, el tránsito de pago, multihoming, ingeniería de tráfico y preferencias locales. También significa que una ruta recibida de un vecino no viene acompañada de una prueba universal de que cada AS en la ruta pretendía que el anuncio viajara tan lejos.

Antes del incidente, DQE utilizaba un producto de optimización BGP de Noction. Dicho producto puede medir el rendimiento de la ruta e inyectar rutas más específicas para influir en qué enlace transporta el tráfico seleccionado. En el ejemplo publicado por Cloudflare, el anuncio normal104.20.0.0/20se dividió en104.20.0.0/21y104.20.8.0/21. Las dos /21 cubren el mismo rango de direcciones que la /20, pero cada una nombra un bloque de destino más pequeño.

Dentro de una red controlada, las rutas más específicas pueden ser un instrumento legítimo de ingeniería de tráfico. El peligro es el alcance. Las rutas estaban destinadas a influir en las decisiones internas de DQE. DQE las anunció a AS396531. AS396531 estaba conectado tanto a DQE como a Verizon y exportó las rutas aprendidas hacia Verizon. Verizon las aceptó de su cliente y las propagó hacia adelante. Una instrucción local se había convertido en una reclamación global.

Larespuesta al incidente del 26 de juniode Noction reconoció que su plataforma generó las rutas más específicas y describió tres condiciones agravantes: generación dentro de la red de su cliente, fuga a través de un ASN descendente hacia un proveedor importante y filtrado inadecuado en los tres sistemas autónomos. Noction argumentó que crear rutas más específicas es una práctica común en lugar de un defecto inherente y enfatizó el filtrado del proveedor. Esa respuesta es relevante porque confirma el papel del optimizador mientras disputa una versión de una sola parte. No es un análisis postmortem independiente, y no publica la configuración precisa, el registro de cambios o la evidencia de pruebas para el despliegue de DQE.

Elanálisis de enrutamiento independientede Qrator Labs asoció el inicio con el restablecimiento de la sesión BGP entre AS396531 y Verizon poco después de las 10:35 UTC. Su relato dice que AS396531 había perdido filtros y exportó rutas aprendidas de DQE. Eso proporciona un desencadenante plausible para por qué la condición comenzó cuando lo hizo, pero el registro público disponible no incluye configuraciones de enrutadores ni registros de AS396531, DQE o Verizon. La conclusión segura es más estrecha: la ruta observable prueba que las rutas cruzaron esos límites de AS; los relatos de los operadores identifican filtros faltantes o inadecuados; la secuencia exacta de cambios internos sigue sin ser pública.

Esta distinción previene tres errores comunes. Primero, DQE no debe ser descrito como el origen del espacio de direcciones de Cloudflare en el sentido BGP. La ruta AS observada aún terminaba en AS13335 de Cloudflare. El optimizador de DQE creó y propagó una ruta más específica manteniendo el origen legítimo. Segundo, Verizon no inventó las rutas, pero su aceptación y propagación global ampliaron enormemente su alcance. Tercero, la red de Cloudflare no eligió AS396531 como ruta preferida. Las redes remotas tomaron decisiones de reenvío basadas en los anuncios que recibieron.

Por qué las rutas más específicas vencieron a la distancia y al anycast

Para un no especialista, el evento puede sonar como si los enrutadores seleccionaran una ruta AS más corta. La preferencia decisiva ocurrió antes. El reenvío en Internet utiliza la coincidencia de prefijo más largo: una ruta que cubre el bloque de destino más específico se selecciona sobre una ruta que cubre un bloque más amplio.RFC 4632, la especificación de enrutamiento entre dominios sin clase, describe este comportamiento de coincidencia más larga y su relación con las rutas agregadas y más específicas.

Supongamos que un enrutador sabe que el104.20.0.0/20de Cloudflare es accesible a través de un proveedor normal y también aprende el104.20.0.0/21a través de Verizon, AS396531 y DQE. Un destino dentro del primer /21 coincide con ambos anuncios. El /21 es más específico, por lo que gana incluso si su ruta AS es más larga u operativamente absurda. Los atributos de ruta normales deciden entre rutas al mismo prefijo; no hacen que un /20 saludable derrote a un /21 aceptado.

Es por eso que la huella anycast de Cloudflare no enrutó automáticamente alrededor del problema. Anycast permite que muchas ubicaciones de Cloudflare anuncien los mismos prefijos, permitiendo a BGP seleccionar una instancia adecuada. Proporciona distribución geográfica y puede absorber el fallo de sitios o enlaces individuales. Pero los /21 filtrados eran más específicos que los anuncios /20 ordinarios de Cloudflare. El sistema de enrutamiento global pudo preferir el /21 antes de comparar qué ubicación anycast de Cloudflare estaba más cercana. La redundancia detrás de la ruta perdedora no restauró el tráfico.

La ruta no deseada también concentró la carga. AS396531 y sus conexiones no estaban aprovisionadas como tránsito global para Cloudflare, Amazon, Linode y las muchas otras redes afectadas. El tráfico atraído por los anuncios más específicos entró en un corredor sin la capacidad o política para transportarlo. Los paquetes se retrasaron o se descartaron. Una fuga de rutas a veces puede entregar tráfico por una ruta ineficiente; aquí, la escala convirtió la ruta en un cuello de botella.

Lataxonomía de fuga de rutas RFC 7908del Grupo de Trabajo de Ingeniería de Internet define una fuga de rutas como la propagación más allá del alcance previsto de un anuncio. El evento de junio de 2019 combina características que la taxonomía separa con fines analíticos. Involucró rutas aprendidas de un proveedor exportadas por una red multihomed hacia otro proveedor, lo que se asemeja al patrón clásico de giro en horquilla, y rutas más específicas útiles internamente que nunca fueron previstas para propagación global. La etiqueta importa menos que el invariante violado: un cliente de Verizon pareció ofrecer tránsito a prefijos fuera de su cono de cliente legítimo, y Verizon aceptó esa apariencia.

La cronología y la ventana de responsabilidad en expansión

La responsabilidad cambia a medida que un incidente avanza de la prevención a la detección y la recuperación. La siguiente cronología utiliza datos de rutas públicas y declaraciones de operadores atribuidas; no llena los vacíos con acciones internas supuestas.

El período más consecuente comenzó antes de la primera marca de tiempo. Si una junta directiva comienza su revisión a las 10:34, se centrará en alertas y llamadas. Si comienza cuando se autorizaron las rutas del optimizador para producción, puede examinar la seguridad del diseño, el alcance de la ruta, los valores predeterminados de fallo cerrado, las políticas de pares, la revisión de cambios y las pruebas de propagación independientes. La respuesta al incidente redujo la duración. Los controles preventivos determinaron si había un incidente al que responder.

Cuatro oportunidades de filtrado fallaron en la misma dirección

La ruta cruzó varios límites, cada uno con una oportunidad diferente de detenerla. Tratar esas oportunidades como capas aclara la responsabilidad sin pretender que todas las partes tenían el mismo control.

Contención del optimizador y la red de origen.DQE controlaba el entorno en el que el producto de Noction generaba rutas más específicas. Las rutas destinadas solo para decisiones locales necesitaban una barrera de exportación que no dependiera de que todos los descendentes se comportaran correctamente. Las opciones incluían una política de exportación de alcance ajustado, un contexto de enrutamiento dedicado, comunidades explícitas interpretadas por cada salida, comprobaciones automatizadas desde colectores externos y un interruptor de apagado vinculado a propagaciones inesperadas. Noction dice que realizó pruebas de despliegue y discute el uso deNO_EXPORT, pero también argumenta queNO_EXPORTno es apropiado en todos los diseños multi-AS. La comunidad bien conocida se define enRFC 1997: una ruta que la lleva no debe anunciarse fuera de un límite de confederación. Si se utilizó, se preservó, se eliminó o nunca se adjuntó en este evento no está establecido públicamente.

Control de exportación del cliente multihomed.AS396531 no debería haber ofrecido las rutas completas u optimizadas de un proveedor a otro proveedor a menos que operara intencionalmente como tránsito. Una red hoja o empresarial puede aplicar una regla de salida simple: anunciar solo sus propios prefijos autorizados y prefijos de clientes explícitamente aprobados. Una denegación por defecto es más fiable que intentar identificar cada ruta que no debe salir.RFC 8212, publicada en 2017, codificó el rechazo predeterminado de eBGP cuando no se configura una política explícita de importación o exportación. No puede evitar que un operador adjunte una política permisiva incorrecta, pero elimina una clase de propagación accidental causada por una política ausente.

Control de ingreso de cliente del proveedor.Verizon tenía el punto de parada de mayor apalancamiento. Un proveedor de tránsito sabe qué sesión es una sesión de cliente y debe saber qué está autorizado a originar o transitar ese cliente. El análisis detallado de Cloudflare encontró que la información del registro de rutas asociada con el cliente no incluía el ASN de Cloudflare ni las otras redes filtradas. Un filtro de prefijo específico del cliente y de ruta AS podría, por lo tanto, haber rechazado los anuncios. Laguía de operaciones y seguridad BGP en RFC 7454, publicada en 2015, recomienda políticas para rutas recibidas y anunciadas en cada frontera, controles de prefijo de cliente, filtrado de rutas AS y límites máximos de prefijos.

Rechazo de descendentes y pares.Las redes que recibían las rutas de Verizon también tenían la oportunidad de rechazarlas. Dado que Verizon es una gran red de tránsito, muchos receptores otorgaban a sus anuncios una confianza sustancial. Algunas redes que utilizaban Validación de Origen de Ruta habrían rechazado las rutas más específicas de Cloudflare afectadas como inválidas según RPKI. Otras podrían usar heurísticas de fuga de rutas o políticas de pares. Sin embargo, pedir a cada red remota que detecte un error después de que un proveedor importante lo distribuya es menos eficiente que rechazarlo en la sesión del cliente original. La prevención más cercana a la violación de la política limita la propagación antes de que la convergencia global convierta un error de configuración en una interrupción distribuida.

Estas capas no eran lo suficientemente independientes. La optimización de DQE, la exportación de AS396531 y la importación de Verizon dependían todas de una configuración correcta de la política de enrutamiento. Si cada capa es manualmente permisiva o se construye a partir de registros de clientes incompletos, tres controles pueden fallar juntos. Por lo tanto, un programa de aseguramiento maduro prueba el resultado desde fuera del dominio administrativo. No acepta la revisión de configuración por sí sola como prueba de que una ruta permaneció local.

RPKI podría haber bloqueado estas rutas, pero no es la respuesta completa

Cloudflare había comenzado a firmar rutas y desplegar validación en 2018, como se describe en surelato de despliegue de RPKI. Una Autorización de Origen de Ruta, o ROA, establece qué sistema autónomo puede originar un prefijo y, opcionalmente, la longitud de prefijo más específica que puede anunciar. Cloudflare dice que sus rutas relevantes autorizaban AS13335 con una longitud máxima de /20. Los /21 filtrados conservaban AS13335 como su origen pero excedían la longitud máxima autorizada. Por lo tanto, eran inválidos según la Validación de Origen de Ruta.

La lógica está formalizada enRFC 6811. Una ruta recibida es válida si una carga útil ROA validada cubre el prefijo, el ASN de origen coincide y la longitud del prefijo de la ruta no excede el máximo de la ROA. Es inválida cuando existe una autorización que cubre pero ninguna coincide con todas las propiedades requeridas. Laexplicación de validación de origende RIPE NCC separa útilmente los estados válido, inválido y desconocido y enfatiza que los operadores de red aún deciden qué política aplicar a esos estados.

El acto de Cloudflare de crear ROAs fue necesario pero no suficiente. Una ROA es evidencia publicada, no un comando de aplicación remota. Verizon u otra red receptora tenía que recuperar datos RPKI validados, aplicar validación a la ruta del cliente y rechazar las inválidas. Cloudflare podía rechazar rutas inválidas que ingresaran a su propia red, pero eso no impedía que redes de terceros enviaran tráfico destinado a Cloudflare por una ruta seleccionada en otro lugar. La seguridad de enrutamiento tiene una estructura recíproca: un titular de dirección publica autorización, mientras que otros operadores la hacen efectiva.

Para este incidente, RPKI fue un control preventivo particularmente fuerte porque el optimizador cambió la longitud del prefijo. Sería incorrecto generalizar esa condición de éxito a cada fuga de rutas. Si AS396531 hubiera filtrado el /20 ordinario de Cloudflare preservando AS13335 al final de la ruta, la validación de origen podría considerar la ruta como válida. La ruta aún violaría la topología esperada de proveedor-cliente. La validación de origen RPKI responde quién puede originar un prefijo y con qué longitud. No prueba que cada relación de tránsito en la ruta AS esté autorizada.

Este límite no es una crítica a RPKI. Es la razón para desplegarlo con otros controles. Laguía SP 800-189 de NISTcombina la validación de origen RPKI y BGP con el filtrado de prefijos y prácticas más amplias de resiliencia interdominio. Trata las fugas de rutas, secuestros, desvíos de tráfico, denegación de servicio y degradación del rendimiento como riesgos operativos relacionados que requieren capas. El evento de junio de 2019 es una demostración inusualmente concreta: una capa podría haber rechazado exactamente los prefijos malos, mientras que el filtrado básico de clientes podría haber rechazado la ruta de autoridad inverosímil incluso sin criptografía.

También hay una lección de gobernanza enmaxLength. Una ROA demasiado permisiva puede hacer que rutas más específicas no autorizadas parezcan válidas; una ROA demasiado restrictiva u obsoleta puede causar que rutas legítimas sean rechazadas. La cobertura de ROA, la longitud máxima, la caducidad, la salud de claves y repositorios y los cambios de enrutamiento planificados necesitan control de cambios. Un panel que muestre que existen ROAs no es evidencia de que describan con precisión la intención de producción.

Controles de política de ruta después de 2019

El panorama de estándares y políticas continuó desarrollándose después de la interrupción. Los controles posteriores no deben describirse como si los operadores hubieran podido desplegar una versión final en junio de 2019, pero muestran cómo la industria ha tratado de codificar suposiciones que antes eran implícitas.

RFC 9234, publicada en 2022, introdujo los Roles BGP y el atributo Solo-a-Cliente, u OTC. Las redes vecinas pueden declarar si una relación es de proveedor, cliente, par, servidor de ruta o cliente de servidor de ruta. El acuerdo de rol y el manejo de OTC permiten a los enrutadores detectar algunos anuncios que cruzan un límite de relación en una dirección no permitida. En una versión simplificada de la ruta de 2019, una ruta aprendida de un proveedor y luego enviada a otro proveedor debería llevar evidencia inconsistente con una exportación solo a cliente. Los Roles BGP convierten parte del conocimiento de topología comercial de una convención de operador en un estado visible para el protocolo.

Peerlock ofrece otro enfoque centrado en la ruta. El artículo de 2020"Flexsealing BGP Against Route Leaks"estudió el mecanismo desplegado por operadores, incluyendo su capacidad para detener rutas en las que una gran red protegida aparece donde no debería. Peerlock existía antes del artículo y antes del evento de junio de 2019, pero el despliegue dependía del conocimiento y la configuración bilaterales. Es evidencia de que los filtros de ruta prácticos eran posibles, no prueba de que hubiera un control universal disponible.

La Autorización de Proveedor de Sistema Autónomo, o ASPA, tiene como objetivo permitir que un AS publique relaciones de proveedor verificables a través del sistema RPKI. Es prometedora porque muchas fugas de rutas son fallos de plausibilidad de ruta en lugar de fallos de origen. También exige un lenguaje cuidadoso: los estándares y el estado de despliegue de ASPA han evolucionado, y la cobertura parcial produce rutas desconocidas. Debe tratarse como una señal de validación adicional, no como evidencia retrospectiva de que los participantes de 2019 violaron un estándar criptográfico de ruta entonces obligatorio.

La detección también maduró. Cloudflare describió más tarde suservicio de detección de fugas de rutas Radar, que utiliza relaciones de enrutamiento y rutas observadas para señalar fugas probables. La supervisión reduce el tiempo para saber y el tiempo para coordinar, pero no evita que un enrutador acepte la ruta. Un incidente de dos horas aún puede causar daño global si la ruta de remediación es una cadena telefónica humana. La detección debe conectarse a una acción ensayada: identificar prefijos afectados, aplicar políticas defensivas donde sea seguro, contactar a operadores autorizados, publicar el estado del cliente, verificar retiros a través de colectores independientes y observar la recuperación del tráfico.

Por lo tanto, el modelo de control útil es acumulativo:

1. Publicar autoridad de ruta precisa a través de objetos IRR y ROAs.
2. Generar filtros de importación de clientes a partir de datos confiables y actualizarlos de forma segura.
3. Rechazar por defecto las rutas que carecen de una política explícita.
4. Hacer cumplir las expectativas de cono de cliente, ruta AS, longitud de prefijo y máximo de prefijos.
5. Rechazar anuncios inválidos según RPKI en cada ingreso externo relevante.
6. Agregar controles conscientes de la relación como Roles BGP, OTC, Peerlock y, a medida que madure, validación ASPA.
7. Observar la propagación desde puntos de observación externos independientes.
8. Mantener contactos de operaciones continuamente probados y autoridad de retirada de rutas.

Ningún elemento por sí solo sustituye a los demás. Su valor proviene de diferentes modos de fallo.

Asignación de responsabilidad sin inventar un veredicto de responsabilidad civil

El registro técnico público respalda el análisis de responsabilidad, pero no contiene una sentencia judicial, orden regulatoria o conjunto completo de contratos que asignen responsabilidad legal entre DQE, AS396531, Verizon, Noction, Cloudflare y los clientes afectados. No se localizó ningún informe público de causa raíz de Verizon en el registro utilizado para este artículo. Por lo tanto, la siguiente asignación es operativa: quién controlaba cada salvaguarda y quién podía reducir cada riesgo. No es una asignación porcentual de daños.

DQE Communications.DQE controlaba la red donde se generaron las rutas de optimización y la relación a través de la cual llegaron a AS396531. Sus deberes de mayor valor eran limitar el alcance de la ruta, probar la visibilidad externa, mantener una política de exportación correcta y detener los anuncios una vez contactados. Cloudflare atribuyó al personal de DQE haber ayudado a retirar las rutas. La cooperación rápida redujo la duración; no borra el fallo del control preventivo.

AS396531.La red multihomed era el puente entre proveedores. Su anuncio observable hacia Verizon hizo que pareciera proporcionar accesibilidad para rutas aprendidas a través de DQE. Una empresa sin tránsito debería exportar una lista blanca estrecha, no una tabla completa aprendida. El registro público no identifica al ingeniero, proveedor o cambio que eliminó o eludió el filtrado, por lo que la culpa individual sería especulativa. La responsabilidad organizativa se adhiere al diseño que permitió que una restauración de sesión expusiera rutas fuera de la autoridad de la empresa.

Verizon.La política de importación orientada al cliente de Verizon era el control no ejercido más consecuente. Una gran red de tránsito que acepta miles de rutas de un cliente debería verificar los prefijos autorizados, los orígenes y rutas esperados, y el volumen de prefijos. El archivo de rutas muestra que Verizon propagó la ruta. Cloudflare dice que los datos IRR y la validación RPKI relevantes podrían haberla rechazado e informa de dificultades para contactar a Verizon durante el evento. Sin los registros internos de Verizon, no se puede decir si un filtro estaba ausente, obsoleto, mal aplicado, eludido o falló de otra manera. Cualquiera de esas posibilidades apunta a deberes de aseguramiento y coordinación de incidentes proporcionales a la escala del proveedor.

Noction.Un optimizador de enrutamiento que puede crear rutas más específicas globalmente preferidas tiene un modo de fallo previsible de altas consecuencias si la contención falla. La responsabilidad del producto incluye valores predeterminados seguros, advertencias de riesgo conspicuas, validación de despliegue, etiquetado de rutas, pruebas de fugas externas, reversión y controles que hacen que el modo intrusivo sea difícil de habilitar sin límites verificados. La respuesta de Noction dice que probó la propagación durante el despliegue y que los filtros seguían siendo obligatorios. Esa afirmación plantea la siguiente pregunta de auditoría: ¿verificó el producto la contención de forma continua después de cambios de peering o sesión, o solo en la puesta en marcha? Una prueba única no puede probar la seguridad de un entorno de enrutamiento dinámico indefinidamente.

Cloudflare.Cloudflare no generó ni propagó las rutas no deseadas, y no podía configurar la sesión de cliente de Verizon. Sin embargo, había vendido a los clientes un servicio de disponibilidad y seguridad basado en enrutamiento global. Por lo tanto, su responsabilidad reside en los controles residuales: ROAs precisos, interconexión diversa, supervisión de rutas externas, diagnóstico rápido, contactos de pares accesibles, comunicación con clientes, opciones de mitigación y divulgación transparente. También tenía el deber de no exagerar lo que su arquitectura podía soportar. Anycast y una gran red global reducen muchos fallos pero no pueden vencer una ruta más específica globalmente aceptada sin ayuda de redes validadoras.

Otras redes.Los pares y descendentes que aceptaron las rutas de Verizon no estaban en igual posición para conocer la autorización de cliente de AS396531, pero podían desplegar validación RPKI y controles de ruta. Sus decisiones afectaron a sus propios usuarios y, en algunos casos, a la propagación adicional. El sistema es más seguro cuando las grandes redes de tránsito actúan correctamente, pero una red receptora sigue siendo responsable de las rutas que instala.

Esta asignación evita la declaración conveniente pero inútil de que BGP se basa en la confianza y, por lo tanto, nadie es responsable. La confianza se implementa a través de configuraciones, registros, contratos y prácticas operativas. Estos son controlables. La apertura del protocolo explica por qué un fallo puede propagarse; no excusa a un proveedor de filtrar las rutas de los clientes.

La responsabilidad empresarial de Cloudflare sobrevivió a la causa externa

Un desencadenante externo no elimina las obligaciones de un proveedor de nube con los clientes. Ladeclaración de registro Formulario S-1enmendada de Cloudflare de 2019 dijo que la fuga de rutas de junio causó una interrupción significativa de su tráfico y el de otros proveedores. Advirtió que las fugas de rutas podrían dañar la reputación y la confianza, describió compromisos de nivel de servicio que podrían dar lugar a créditos o reembolsos, y declaró que la fuga de rutas de junio y una interrupción separada de julio desencadenaron algunas de esas obligaciones. En ese momento, Cloudflare no esperaba que los incidentes tuvieran un efecto material en los resultados de las operaciones o la situación financiera.

Esa divulgación siguió a uncomentario del personal de la SECpidiendo a la empresa que abordara el impacto financiero razonablemente esperado de la fuga de rutas de junio a la luz de los compromisos de nivel de servicio. El intercambio es un ejemplo compacto de cómo la responsabilidad se mueve del centro de operaciones de red a los informes corporativos. Un incidente puede ser causado externamente, operativamente significativo, contractualmente compensable y financieramente inmaterial para el proveedor al mismo tiempo.

La presentación no revela el número de clientes afectados, créditos totales, reembolsos, transacciones perdidas o tiempo de inactividad a nivel de cliente. También discute la fuga de rutas de junio junto con la interrupción del cortafuegos de aplicaciones web del 2 de julio causada internamente por Cloudflare. Esos eventos no deben fusionarse. El incidente de junio prueba la dependencia del enrutamiento externo. El incidente de julio prueba los controles internos de cambio de software. Ambos afectaron la disponibilidad, pero los propietarios preventivos y la evidencia son diferentes.

Para los clientes, un crédito de servicio no equivale a un negocio restaurado. Un pequeño comerciante en línea puede perder pedidos, un servicio de comunicaciones puede perder sesiones y una empresa puede consumir horas de personal antes de que se calcule un crédito de suscripción mensual. Los remedios contractuales asignan una fracción de las tarifas directas del proveedor, no el costo social o de cliente completo del tiempo de inactividad.

Por lo tanto, los proveedores de nube deberían informar más que el tiempo de actividad contractual: accesibilidad por región y red, pérdida de tráfico, tiempo para detectar, tiempo para identificar, tiempo para comunicar y tiempo para la recuperación estable.

Lo que las juntas directivas deberían preguntar sobre el riesgo de peering y tránsito

El enrutamiento a menudo se trata como una preocupación especializada por debajo del nivel de supervisión de la junta directiva. El evento de junio de 2019 muestra por qué esa división es demasiado nítida. Una política de importación BGP en un proveedor importante cambió el acceso a muchos servicios en la nube, desencadenó obligaciones con los clientes, creó divulgación a inversores y expuso la concentración fuera de los contratos formales con proveedores de nube. La junta no necesita elegir sintaxis de enrutador. Sí necesita evidencia de que la gerencia sabe dónde la disponibilidad depende del comportamiento de otro sistema autónomo.

Un paquete útil para la junta comienza con la exposición, no con afirmaciones de cumplimiento:

El denominador importa en cada métrica. Decir que RPKI está desplegado en enrutadores centrales no revela si una sesión de borde no validada puede inyectar una ruta en la misma red. Decir que los filtros de clientes están automatizados no muestra si el registro de origen está completo, si persisten excepciones de emergencia o si una nueva sesión BGP heredó la política. Decir que los contactos están en una base de datos no prueba que alguien responda con autoridad a las 06:30 hora local.

Las pruebas deberían incluir casos negativos controlados. Un proveedor puede intentar anunciar un prefijo de laboratorio no autorizado, un prefijo más largo de lo que permite su ROA, un recuento de rutas excesivo y una ruta que viole la relación de cliente declarada. El resultado esperado debe observarse en la política receptora y en colectores independientes. Las pruebas necesitan salvaguardas para que no puedan convertirse ellas mismas en fugas, pero evitar todas las pruebas realistas deja el comportamiento de mayor riesgo sin probar.

Resiliencia del cliente sin consejos simplistas de múltiples proveedores

Los clientes a menudo escuchan que deberían evitar la dependencia comprando una segunda CDN, un segundo proveedor de DNS o una segunda nube. La diversidad puede ayudar, pero los fallos de enrutamiento no respetan las etiquetas de producto. Dos proveedores pueden compartir tránsito, puntos de intercambio, fibra, colectores de ruta o las mismas redes de acceso no validadoras. Una ruta más específica filtrada también puede atraer tráfico antes de que la lógica de conmutación por error de DNS o aplicación del cliente tenga oportunidad de ayudar.

El diseño correcto comienza con la ruta del servicio. ¿Qué proveedor es autoritativo para DNS? ¿Dónde se almacenan las claves TLS y las políticas de seguridad? ¿Puede un origen aceptar tráfico directo de forma segura? ¿Se puede desviar el tráfico sin crear un bypass de seguridad? ¿Qué tan rápido cambian las cachés DNS? ¿Los clientes retienen conexiones? ¿Tiene un proveedor secundario la configuración y capacidad actuales? ¿Puede la organización distinguir un fallo de enrutamiento ascendente de un fallo de origen antes de mover el tráfico?

Para algunos servicios, la entrega activa-activa a través de proveedores enrutados independientemente está justificada. Para otros, la complejidad, la política de seguridad inconsistente, el comportamiento de caché y la superficie de ataque añadida superan una ganancia de disponibilidad de dos horas. Una decisión defendible registra la criticidad, el tiempo de recuperación probado, las dependencias compartidas, el costo y el riesgo residual. No cuenta nombres de proveedores y llama al resultado resiliente.

Los clientes también pueden usar el apalancamiento de adquisiciones. Pueden pedir a un proveedor de nube o red cobertura de ROA, política ROV, controles de filtro de clientes, participación en MANRS, prácticas de contacto de incidentes, supervisión externa y resultados de pruebas anonimizados. Lasacciones de operador de red MANRSproporcionan un marco práctico: filtrado, anti-suplantación, coordinación y publicación de información que otros pueden validar. La membresía o conformidad es una señal, no prueba de operación impecable, pero las acciones traducen la seguridad de enrutamiento en preguntas que un comprador puede entender.

La pregunta contractual más importante a menudo no es el porcentaje de tiempo de actividad. Es qué evidencia y asistencia proporciona el proveedor cuando el tráfico no puede llegar a un servicio saludable debido al enrutamiento externo. La comunicación de estado rápida y específica ayuda a los clientes a evitar cambios destructivos en orígenes saludables. Los datos de ruta posteriores al incidente les ayudan a conciliar sus propias observaciones. Una cláusula de fuerza mayor o de terceros redactada de manera restrictiva puede limitar la compensación, pero no debe terminar con el deber operativo del proveedor de diagnosticar y comunicar.

De normas voluntarias a evidencia de gestión de riesgos

El evento de junio de 2019 ocurrió en un entorno de seguridad de enrutamiento en gran parte voluntario. Las mejores prácticas no eran desconocidas. Existían el filtrado de prefijos y rutas AS, datos IRR, controles de prefijos máximos, RPKI y registros de contacto de operadores. La adopción y el aseguramiento eran desiguales, particularmente cuando una red tenía que asumir el costo de despliegue mientras los beneficios se extendían por Internet.

Ese problema de acción colectiva atrajo más tarde una atención gubernamental más explícita. LaHoja de Ruta para Mejorar la Seguridad del Enrutamiento de Internetde 2024 de la Oficina del Director Cibernético Nacional de EE. UU. describe la incapacidad de BGP, en operación común, para validar la autoridad de origen, la integridad del mensaje, la información de ruta remota o los anuncios que violan las políticas comerciales vecinas. Pide una adopción más fuerte de la seguridad de origen de ruta, especialmente entre los principales proveedores y servicios contratados por el gobierno. La hoja de ruta es orientación política, no un hallazgo sobre los participantes de 2019.

Elaviso de Enrutamiento Seguro de Internetde 2024 de la Comisión Federal de Comunicaciones propuso planes de gestión de riesgos BGP e informes para proveedores de banda ancha y solicitó comentarios sobre medidas más allá de la validación de origen RPKI. Reconoció explícitamente que la seguridad de ruta requiere más trabajo. Una vez más, esto no crea responsabilidad retroactiva para junio de 2019. Ilustra un cambio de gobernanza de preguntar si un proveedor apoya RPKI en principio a pedir un plan mantenido, datos de cobertura, atestación y progreso.

La regulación tiene sus propios riesgos. Un objetivo porcentual para el registro de ROA puede recompensar autorizaciones amplias y permisivas. Un requisito de presentación puede convertirse en papeleo desconectado de la política del enrutador. La divulgación pública de configuraciones defensivas detalladas puede crear preocupaciones de seguridad. Por lo tanto, la supervisión efectiva debería centrarse en resultados y evidencia controlada: autorización precisa, cobertura de rechazo, política de cliente probada, gobernanza de excepciones, velocidad de detección, preparación de contacto y aprendizaje de incidentes.

El acceso de supervisión confidencial puede ser apropiado para detalles sensibles, mientras que la adopción agregada y las métricas de incidentes permanecen públicas.

El procomún de seguridad de rutas también cruza fronteras nacionales. La propagación de Verizon afectó a usuarios y servicios a nivel global; ingenieros de Cloudflare en varias regiones participaron en la respuesta; la autoridad de ruta se distribuye a través de registros regionales; y los destinatarios aplican su propia política. Una norma nacional puede mejorar la conducta de los proveedores bajo su jurisdicción, pero los estándares interoperables y las normas de los operadores son lo que hace que esa mejora viaje.

La evidencia que aún falta en el registro público

El análisis detallado de Cloudflare es inusualmente reproducible: identifica datos de RIPE NCC, proporciona comandos y muestra rutas observadas y marcas de tiempo. Esa transparencia respalda una alta confianza en la cronología de rutas. No responde a todas las preguntas de responsabilidad.

Los siguientes registros mejorarían materialmente el análisis si los operadores involucrados los divulgaran:

• La configuración del optimizador de DQE, la política de prefijos generados, los mapas de exportación, el manejo de comunidades y las pruebas de propagación externa antes y después del despliegue.
• La política BGP de AS396531 adjunta a las sesiones con DQE y Verizon, la línea de tiempo de caída y restablecimiento de sesión, los cambios de configuración, los recuentos de rutas y la razón por la cual las rutas aprendidas del proveedor eran elegibles para exportación.
• El registro de incorporación de clientes de Verizon, la fuente de IRR o lista de prefijos, la política de ruta AS, la configuración de prefijo máximo, el estado de validación RPKI, las alertas, la línea de tiempo de respuesta del operador y la explicación de la propagación global.
• La lista de verificación de despliegue de Noction, las salvaguardas de contención continua, el comportamiento de alerta y los cambios de producto realizados después del incidente.
• La primera marca de tiempo de detección interna de Cloudflare, la fuente de alerta, las decisiones de mitigación consideradas, la línea de tiempo de escalamiento de contacto con pares, el impacto en los clientes por red y región, y la verificación de acciones correctivas.
• Créditos de servicio cuantificados, reembolsos, carga de soporte y rotación de clientes atribuibles específicamente a la fuga de rutas de junio en lugar de la interrupción separada de julio.

Su ausencia no hace que el evento sea incognoscible. Los anuncios BGP públicos son evidencia de lo que las redes se dijeron entre sí. Las mediciones de tráfico son evidencia del impacto en el servicio. Las presentaciones ante la SEC son evidencia de divulgación corporativa y materialidad esperada. Los blogs de operadores son evidencia de explicaciones atribuidas. La disciplina es mantener esas clases de evidencia separadas.

También es importante no confundir un registro público faltante con un registro interno faltante. Verizon, DQE, AS396531 y Noction pueden haber realizado revisiones extensas que nunca se publicaron. Cloudflare puede tener telemetría detallada no incluida en sus publicaciones. La responsabilidad pública es más débil cuando la evidencia permanece privada, pero el artículo no puede inferir que no hubo aprendizaje.

Un estándar de responsabilidad duradero para la resiliencia de rutas

La interrupción de junio de 2019 se recuerda porque una red pequeña se convirtió en la ruta aparente hacia grandes partes de Internet. Su lección más profunda es que la escala no generó un escepticismo correspondiente. Un importante proveedor de tránsito recibió afirmaciones extraordinarias de un cliente y las distribuyó; muchas redes aceptaron el resultado; el tráfico siguió las reglas del protocolo hacia una ruta inverosímil; y la recuperación dependió de encontrar personas que pudieran retirar los anuncios.

El evento era prevenible con controles disponibles en ese momento. DQE podría haber confinado las rutas de optimización. AS396531 podría haber exportado solo prefijos autorizados. Verizon podría haber filtrado los anuncios de clientes con evidencia de registro, ruta, recuento de prefijos y RPKI. Las redes receptoras podrían haber rechazado las rutas más específicas de Cloudflare inválidas según RPKI. Una mejor supervisión y preparación de contacto podrían haber acortado el evento.

Los estándares posteriores hacen que algunas suposiciones de relación sean más fáciles de señalar, pero no convierten la disciplina operativa en una preocupación heredada opcional.

El papel de Cloudflare es más complicado que víctima o propietario. Era el destino cuya accesibilidad fue perjudicada por decisiones externas. Ya había publicado ROAs adecuadas para rechazar las rutas más específicas filtradas, operaba una red distribuida, detectó el evento, coordinó la retirada, explicó el registro de rutas y divulgó consecuencias contractuales. Aún debía a los clientes un estado claro, esfuerzo de recuperación, remedios financieros donde estuvieran contratados y un relato veraz del riesgo de enrutamiento residual.

Un proveedor no puede prometer que el resto de Internet validará sus rutas; puede prometer hacer posible la validación, monitorear lo que sucede y responder con evidencia.

Por lo tanto, el estándar de responsabilidad final no es cero fugas de rutas. Ninguna red global puede garantizar que cada sistema autónomo configurará correctamente cada sesión. El estándar es si cada parte redujo el riesgo bajo su control, probó esa reducción desde el exterior, limitó el radio de explosión de errores inevitables, respondió a través de una ruta de coordinación practicada y produjo suficiente evidencia para que los clientes y supervisores verifiquen la mejora.

Así es como se ve la resiliencia de red más allá del borde: no independencia de otras redes, lo cual Internet hace imposible, sino límites disciplinados sobre cuánta confianza no verificada puede consumir una sola ruta.