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 y más específicas generadas dentro de la red de DQE Communications pasaron a través del cliente AS396531 y fueron aceptadas por AS701 de Verizon. Verizon propagó luego rutas que cubrían miles de redes. Debido a que los enrutadores prefieren un prefijo de destino más específico, una cantidad sustancial de tráfico siguió las rutas filtradas hacia enlaces que no estaban dimensionados para transportarlo; 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 locales sus rutas de optimización, un cliente con múltiples conexiones exportó rutas aprendidas de un proveedor a otro, y una red de tránsito importante aceptó y difundió rutas que no se ajustaban a la autoridad de enrutamiento esperada para ese 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) fue inusualmente adecuada para la parte de Cloudflare en este incidente 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: rutas válidas en origen pueden aún violar relaciones comerciales, por lo que el filtrado de clientes, los límites de prefijos, los Roles BGP, los controles de ruta, la monitorizació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 para fallos de dependencia; y los consejos de administración y reguladores deben exigir una garantía de seguridad de enrutamiento medida, en lugar de una declaración genérica de que se siguen las mejores prácticas del sector.

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 BGP públicos comenzaron a registrar rutas anómalas y 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 aprendieron luego la ruta a través de Verizon.

La ruta es importante porque la interrupción no comenzó con un centro de datos de Cloudflare fallido o un despliegue de aplicación. Las máquinas de Cloudflare continuaron anunciando sus rutas agregadas habituales. El sistema de enrutamiento global simplemente aprendió rutas alternativas para fragmentos más pequeños del mismo espacio de direcciones. Esos fragmentos más pequeños ganaron la decisión de reenvío en muchas redes y dirigieron 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 contemporánea del incidentepor parte de Cloudflare informó que aproximadamente el 15 % de su tráfico global se perdió en el peor momento. Se trata de una medición de la empresa, no de un porcentaje de interrupción universal auditado independientemente. Describe el tráfico de Cloudflare, no el 15 % de todo Internet. Sin embargo, observaciones independientes respaldan el mecanismo general y el impacto en múltiples servicios. ThousandEyes informó en suanálisis de rutas de redque los usuarios tuvieron dificultades para acceder a servicios frontados por Cloudflare y algunos servicios de AWS durante aproximadamente dos horas, mientras que larevisión del incidentede Catchpoint registró problemas de rendimiento en 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 tener servidores en buen estado en muchos países y aún así ser inalcanzable si el plano de control de enrutamiento dirige el tráfico a otro lugar. Los clientes experimentan un único 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 de Cloudflare para el eventodescribió primero 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 monitorización después de la corrección a las 12:42 UTC. El archivo BGP muestra rutas anómalas antes del primer aviso de estado. Esa diferencia no prueba que Cloudflare ignorara un evento conocido durante 28 minutos. Es una pregunta útil de responsabilidad: ¿cuándo detectaron los sistemas automatizados el tráfico anómalo, cuándo identificaron los ingenieros el enrutamiento externo como la 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 al 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 el tráfico fue leído.

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 de despacho centralizado. Cada sistema autónomo utiliza el Protocolo de Puerta de Enlace de Borde (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 permite el peering comercial, el tránsito pagado, el multihoming, la ingeniería de tráfico y las 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 las rutas 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. Los dos /21 cubren el mismo rango de direcciones que el /20, pero cada uno 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ó más allá. Una instrucción local se había convertido en una reclamación global.

La propiarespuesta al incidente del 26 de juniode Noction reconoció que su plataforma generó las rutas más específicas y describió tres condiciones que se combinaron: 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 y no un defecto inherente, y enfatizó el filtrado del proveedor. Esa respuesta es relevante porque confirma el papel del optimizador, aunque discute una versión unilateral. No es una autopsia independiente y no publica la configuración precisa, el registro de cambios ni las pruebas de despliegue de DQE.

Elanálisis de enrutamiento separadode 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 los filtros y exportó rutas aprendidas de DQE. Esto proporciona un desencadenante plausible de 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 limitada: la ruta observable demuestra 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 evita tres errores comunes. Primero, no se debe describir a DQE como el origen del espacio de direcciones de Cloudflare en el sentido BGP. La ruta AS observada 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ó a 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 derrotaron a la distancia y al anycast

Para un no especialista, el evento puede sonar como si los enrutadores hubieran seleccionado una ruta AS más corta. La preferencia decisiva ocurrió antes. El reenvío en Internet utiliza la coincidencia de prefijo más largo: se selecciona una ruta que cubre el bloque de destino más específico sobre una ruta que cubre un bloque más amplio.RFC 4632, la especificación de enrutamiento entre dominios sin clases, 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 que104.20.0.0/20de Cloudflare es alcanzable a través de un proveedor normal y también aprende104.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 pudo sortear el problema automáticamente. Anycast permite que muchas ubicaciones de Cloudflare anuncien los mismos prefijos, dejando que BGP seleccione 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 habituales de Cloudflare. El sistema de enrutamiento global podía preferir el /21 antes de comparar qué ubicación anycast de Cloudflare estaba más cerca. 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 ni la 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.

La taxonomía de fugas de rutasRFC 7908del IETF 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 estuvieron destinadas a la propagación global. La etiqueta importa menos que el invariante violado: un cliente de Verizon parecía 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 pasa de la prevención a la detección y recuperación. La siguiente cronología utiliza datos de rutas públicos y declaraciones de operadores atribuidas; no rellena lagunas con acciones internas supuestas.

El período más trascendental comenzó antes del primer registro horario. Si un consejo de administración comienza su revisión a las 10:34, se centrará en las alertas y las llamadas. Si comienza cuando las rutas del optimizador se autorizaron para producción, puede examinar la seguridad del diseño, el alcance de las rutas, 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 hubo 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 a decisiones locales necesitaban una barrera de exportación que no dependiera de que cada descendente se comportara correctamente. Las opciones incluían una política de exportación de alcance limitado, un contexto de enrutamiento dedicado, comunidades explícitas interpretadas por cada salida, verificaciones automatizadas desde colectores externos y un interruptor de parada vinculado a la propagación inesperada. 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 usó, preservó, 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 a menos que operara intencionadamente como tránsito. Una red de hoja o empresarial puede aplicar una regla simple de salida: anunciar solo sus propios prefijos autorizados y los prefijos de clientes explícitamente aprobados. Una denegación por defecto es más fiable que tratar de identificar cada ruta que no debe salir.RFC 8212, publicada en 2017, codificó el rechazo por defecto 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 detención de mayor influencia. 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. Por lo tanto, un filtro de prefijo y ruta AS específico del cliente podría haber rechazado los anuncios. La guía de operación y seguridad BGP enRFC 7454, publicada en 2015, recomienda políticas para las rutas recibidas y anunciadas en cada frontera, controles de prefijos de cliente, filtrado de ruta AS y límites máximos de prefijos.

Rechazo descendente y de 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 otorgaron una confianza sustancial a sus anuncios. Algunas redes que utilizaban Validación de Origen de Ruta habrían rechazado las rutas más específicas de Cloudflare afectadas por ser RPKI-inválidas. 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 original del cliente. 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 rutas. Si cada capa es permisiva manualmente 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 (ROA) indica 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 a 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álidas bajo la Validación de Origen de Ruta.

La lógica está formalizada enRFC 6811. Una ruta recibida es válida si una carga 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 de cobertura 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 la validación a la ruta del cliente y rechazar las inválidas. Cloudflare podía rechazar rutas inválidas que entraran en su propia red, pero eso no impedía que redes de terceros enviaran tráfico con destino a Cloudflare por una ruta seleccionada en otro lugar. La seguridad del enrutamiento tiene una estructura recíproca: el titular de la dirección publica la 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 erróneo generalizar esa condición de éxito a todas las fugas 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 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. La guíaSP 800-189del NIST combina RPKI y validación de origen BGP con filtrado de prefijos y prácticas más amplias de resiliencia entre dominios. Trata las fugas de rutas, los secuestros, los desvíos de tráfico, la denegación de servicio y la 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 los prefijos malos exactos, 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 o desactualizada puede provocar el rechazo de rutas legítimas. La cobertura de ROAs, la longitud máxima, la caducidad, la salud de las claves y los 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íticas 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 pudieran haber desplegado 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 (OTC). Las redes vecinas pueden declarar si una relación es proveedor, cliente, par, servidor de rutas o cliente de servidor de rutas. El acuerdo de roles 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 la topología comercial de una convención del 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 los operadores, incluida su capacidad para detener rutas en las que una red grande 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 de conocimiento y configuración bilaterales. Es evidencia de que los filtros de ruta prácticos eran posibles, no prueba de que existiera un control universal listo para usar.

La Autorización de Proveedor de Sistema Autónomo (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 de ruta criptográfico 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 posibles fugas. La monitorización reduce el tiempo para saber y el tiempo para coordinar, pero no impide que un enrutador acepte la ruta. Un incidente de dos horas aún puede causar un daño global si la ruta de remediación es una cadena telefónica humana. La detección debe conectarse a acciones ensayadas: identificar los prefijos afectados, aplicar políticas defensivas donde sea seguro, contactar a los operadores autorizados, publicar el estado del cliente, verificar las retiradas en colectores independientes y observar la recuperación del tráfico.

El modelo de control útil es, por lo tanto, acumulativo:

1. Publicar la 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. Aplicar expectativas de cono de cliente, ruta AS, longitud de prefijo y prefijo máximo.
5. Rechazar anuncios RPKI no válidos 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 probados continuamente 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.

Asignando responsabilidad sin inventar un veredicto de responsabilidad legal

El registro técnico público respalda el análisis de responsabilidad, pero no contiene un fallo judicial, una orden reguladora o un 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. La siguiente asignación es, por lo tanto, operativa: quién controlaba qué salvaguarda y quién podía reducir qué 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 las rutas, 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 la ayuda para 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 los proveedores. Su anuncio observable hacia Verizon hizo que pareciera ofrecer alcanzabilidad para las rutas aprendidas a través de DQE. Una empresa no de tránsito debería exportar una lista blanca limitada, 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 especulación. La responsabilidad organizativa recae en el 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 de cara al cliente de Verizon fue el control no ejercido más trascendental. Una red de tránsito grande que acepta miles de rutas de un cliente debe 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 relevantes y la validación RPKI 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, desactualizado, 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 preferidas globalmente 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 visibles, validación de despliegue, etiquetado de rutas, pruebas de fuga externas, reversión y controles que dificulten habilitar el modo intrusivo 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 continuamente la contención después de cambios de peering o de sesión, o solo en la puesta en marcha? Una prueba única no puede demostrar la seguridad de un entorno de enrutamiento dinámico indefinidamente.

Cloudflare.Cloudflare ni 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 construido sobre el enrutamiento global. Por lo tanto, su responsabilidad reside en los controles residuales: ROAs precisas, interconexión diversa, monitorización de rutas externas, diagnóstico rápido, contactos de pares accesibles, comunicación con los 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 derrotar una ruta más específica aceptada globalmente sin la ayuda de redes que validen.

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. Todo eso es controlable. La apertura del protocolo explica por qué un fallo puede propagarse; no exime 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 sus clientes. Ladeclaración de registro enmendadade Cloudflare de 2019 (Formulario S-1) dijo que la fuga de rutas de junio causó una interrupción significativa en su tráfico y en el de otros proveedores. Advirtió que las fugas de rutas podrían dañar la reputación y la confianza, describió los compromisos de nivel de servicio que podrían dar lugar a créditos o reembolsos, y afirmó que la fuga de rutas de junio y una interrupción separada de julio activaron 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 condición financiera.

Esa divulgación siguió a uncomentario del personal de la SECque pedía 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 traslada del centro de operaciones de red a los informes corporativos. Un incidente puede ser causado externamente, operativamente significativo, compensable contractualmente y financieramente irrelevante para el proveedor al mismo tiempo.

La declaración no revela el número de clientes afectados, los créditos totales, los reembolsos, las transacciones perdidas o el tiempo de inactividad a nivel de cliente. También discute la fuga de rutas de junio junto con la interrupción del firewall 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 responsables 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 coste social o para el cliente completo del tiempo de inactividad. Por lo tanto, los proveedores de nube deberían informar más que el tiempo de actividad contractual: alcanzabilidad por región y red, pérdida de tráfico, tiempo de detección, tiempo de identificación, tiempo de comunicación y tiempo hasta la recuperación estable.

Lo que los consejos de administración deberían preguntar sobre el riesgo de peering y tránsito

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

Un paquete útil para el consejo comienza con la exposición, no con reclamaciones 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 deben 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 excesivo de rutas y una ruta que viole la relación de cliente declarada. El resultado esperado debe observarse en la política receptora y en los colectores independientes. Las pruebas necesitan salvaguardas para que no se conviertan 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 rutas 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 de la 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? ¿Con qué rapidez cambian las cachés DNS? ¿Los clientes mantienen las 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 activo-activo a través de proveedores enrutados de forma independiente está justificada. Para otros, la complejidad, la política de seguridad inconsistente, el comportamiento de la 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 los nombres de los proveedores y llama al resultado resiliente.

Los clientes también pueden usar la influencia de compra. Pueden preguntar a un proveedor de nube o red sobre la cobertura ROA, la política ROV, los controles de filtrado de clientes, la participación en MANRS, las prácticas de contacto para incidentes, la monitorización externa y los resultados de pruebas anonimizados. Lasacciones del 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 una prueba de operación impecable, pero las acciones traducen la seguridad del 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. Una 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 forma restrictiva puede limitar la compensación, pero no debe poner fin a la obligación operativa 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 medida voluntario. Las mejores prácticas no eran desconocidas. Existían el filtrado de prefijos y rutas AS, los datos IRR, los controles de prefijos máximos, RPKI y los 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 Nacional Cibernético de EE. UU. describe la incapacidad de BGP, en su 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 una guía política, no una conclusión 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 la 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 admite 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, una supervisión efectiva debe centrarse en los resultados y la evidencia controlada: autorización precisa, cobertura de rechazo, política de cliente probada, gobernanza de excepciones, velocidad de detección, preparación de contactos y aprendizaje de incidentes. El acceso de supervisión confidencial puede ser apropiado para detalles sensibles, mientras que las métricas de adopción agregada e incidentes permanecen públicas.

El bien común de la seguridad de enrutamiento también cruza las 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 receptores 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 y marcas de tiempo observadas. Esa transparencia respalda una alta confianza en la cronología de la ruta. No responde a todas las preguntas de responsabilidad.

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

• Configuración del optimizador de DQE, política de prefijos generados, mapas de exportación, manejo de comunidades y pruebas de propagación externa antes y después del despliegue.
• Política BGP de AS396531 adjunta a las sesiones con DQE y Verizon, cronología de caída y levantamiento de sesión, cambios de configuración, recuentos de rutas y la razón por la cual las rutas aprendidas del proveedor eran elegibles para exportación.
• Registro de incorporación de clientes de Verizon, fuente de IRR o lista de prefijos, política de ruta AS, configuración de prefijo máximo, estado de validación RPKI, alertas, cronología de respuesta del operador y explicación de la propagación global.
• Lista de verificación de despliegue de Noction, salvaguardas de contención continua, comportamiento de alertas y cambios en el producto realizados después del incidente.
• Primera marca de tiempo de detección interna de Cloudflare, fuente de alerta, decisiones de mitigación consideradas, cronología de escalamiento de contactos con pares, impacto en clientes por red y región, y verificación de acciones correctivas.
• Créditos de servicio cuantificados, reembolsos, carga de soporte y pérdida 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 la divulgación corporativa y la materialidad esperada. Los blogs de los 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 exhaustivas 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 ocurrió ningún 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 creó un escepticismo correspondiente. Un proveedor de tránsito importante 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 a 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 monitorización y preparación de contactos podrían haber acortado el evento. Los estándares posteriores facilitan la señalización de algunas suposiciones de relación, 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 alcanzabilidad 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ó las consecuencias contractuales. Aún debía a los clientes un estado claro, esfuerzo de recuperación, remedios financieros donde se contrataron y un relato veraz del riesgo residual de enrutamiento. Un proveedor no puede prometer que el resto de Internet validará sus rutas; puede prometer hacer posible la validación, monitorizar lo que sucede y responder con evidencia.

El estándar de responsabilidad final, por lo tanto, 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 dentro de 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 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, que Internet hace imposible, sino límites disciplinados sobre cuánta confianza no verificada puede consumir una sola ruta.