Cloudflare, la fuga de ruta de junio de 2019 y la rendición de cuentas 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 se transmitieron a través del cliente AS396531 y fueron aceptadas por AS701 de Verizon. Verizon propagó entonces rutas que cubrían miles de redes. Debido a que los routers prefieren un prefijo de destino más específico, un tráfico sustancial 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 fallas de control, no una consigna de causa única. El generador de rutas no mantuvo sus rutas de optimización locales, un cliente multihomed exportó rutas aprendidas del proveedor a otro proveedor, y una importante red de tránsito 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 estaba inusualmente bien adaptada a la parte de Cloudflare de este evento porque las autorizaciones de origen de ruta de Cloudflare permitían que sus prefijos agregados solo hasta una longitud máxima declarada. Las rutas filtradas más específicas excedían esa longitud y, por lo tanto, eran inválidas. Eso no convierte a RPKI en una solución completa para filtraciones de rutas: las rutas con origen válido 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 monitorización y los contactos operativos accesibles siguen siendo necesarios.
• La rendición de cuentas 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 las rutas externas, coordinar rápidamente y divulgar el impacto en los clientes; los clientes deben planificar fallas de dependencia; y los consejos 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 de la industria.

Una interrupción de enrutamiento, no una falla de los servidores de Cloudflare

A las 10:34:25 UTC del 24 de junio de 2019, los recolectores públicos de BGP comenzaron a registrar rutas anormales 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 profundo 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 entonces la ruta a través de Verizon.

La ruta es importante porque la interrupción no comenzó con una falla 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 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 ocurrieron 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. 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 todos los servicios. ThousandEyes informó en suanálisis de ruta de redque los usuarios tenían dificultades para llegar a los servicios alojados en Cloudflare y a 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 rendición de cuentas. Una plataforma puede operar servidores saludables en muchos países y aun así ser inalcanzable si el plano de control de enrutamiento dirige el tráfico a otro lugar. Los clientes experimentan un resultado: tiempos de espera, errores y aplicaciones no disponibles. Sin embargo, la causa técnica determina qué controles podrían haber prevenido la pérdida y qué parte podría haberlos operado.

Elregistro de estadode Cloudflare para el evento describió primero problemas de rendimiento de red, luego identificó una posible filtración de ruta 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 anormales antes del primer aviso de estado. Esa diferencia no es una prueba de que Cloudflare ignorara un evento conocido durante 28 minutos. Es una pregunta de rendición de cuentas útil: ¿cuándo detectaron los sistemas automatizados el tráfico anormal, cuándo identificaron los ingenieros el enrutamiento externo como la causa y cuándo tuvo la empresa la 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 filtración de ruta puede crear una oportunidad de intercepción, pero el daño observado al servicio 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 una falla de disponibilidad e integridad del enrutamiento. No convierte una posible propiedad de seguridad de las filtraciones de ruta en una alegació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 gestionada centralmente. Cada sistema autónomo utiliza el Protocolo de Frontera de Puerta de Enlace, 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 4271da a los operadores una considerable libertad de política. Esa flexibilidad respalda el peering comercial, el tránsito pago, el multihoming, la ingeniería de tráfico y las preferencias locales. También significa que una ruta recibida de un vecino no va 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. Tal producto puede medir el rendimiento de la ruta e inyectar rutas más específicas para influir en qué enlace lleva el tráfico seleccionado. En el ejemplo que publicó Cloudflare, el anuncio normal de104.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ó. Una instrucción local se había convertido en una afirmació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 agravantes: generación dentro de la red de su cliente, filtración a través de un ASN descendente a 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 más que 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 informe posterior independiente y no publica la configuración precisa, el registro de cambios o la evidencia de prueba para el 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 versión dice que AS396531 había perdido filtros y exportó rutas aprendidas de DQE. Eso proporciona un desencadenante plausible de por qué la condición comenzó cuando lo hizo, pero el registro público disponible no incluye configuraciones de router o 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 AS; las versiones de los operadores identifican filtros faltantes o inadecuados; la secuencia exacta de cambios internos sigue siendo no pública.

Esta distinción previene tres errores comunes. Primero, DQE no debe describirse como el origen del espacio de direcciones de Cloudflare en el sentido BGP. La ruta AS observada todavía terminaba en AS13335 de Cloudflare. El optimizador de DQE creó y propagó una ruta más específica con el origen legítimo retenido. 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 una 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 routers seleccionaran una ruta AS más corta. La preferencia decisiva ocurrió antes. El reenvío de 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 interdominio sin clases, describe este comportamiento de coincidencia más larga y su relación con rutas agregadas y más específicas.

Supongamos que un router 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 aunque su ruta AS sea más larga o 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 eludió automáticamente el problema. 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 la falla de sitios o enlaces individuales. Pero los /21 filtrados eran más específicos que los anuncios ordinarios /20 de Cloudflare. El sistema de enrutamiento global podía 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 descartaron. Una filtración de ruta a veces puede entregar tráfico por una ruta ineficiente; aquí, la escala convirtió la ruta en un cuello de botella.

Lataxonomía de filtraciones de ruta RFC 7908del Grupo de Trabajo de Ingeniería de Internet define una filtración de ruta 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 del proveedor exportadas por una red multihomed hacia otro proveedor, que se asemeja al patrón clásico de giro en horquilla, y rutas más específicas internamente útiles 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 clientes legítimo, y Verizon aceptó esa apariencia.

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

La rendición de cuentas cambia a medida que un incidente se mueve desde la prevención hasta la detección y la recuperación. La siguiente línea de tiempo utiliza datos de ruta públicos 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 un consejo comienza su revisión a las 10:34, se centrará en alertas y llamadas. Si comienza cuando las rutas del optimizador fueron autorizadas para producción, puede examinar la seguridad del diseño, el alcance de la ruta, los valores predeterminados de cierre, 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 para detenerla. Tratar esas oportunidades como capas aclara la responsabilidad sin pretender que todas las partes tenían el mismo control.

Contención de la red optimizadora y originadora.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 todos los descendentes se comportaran correctamente. Las opciones incluían una política de exportación estrictamente definida, un contexto de enrutamiento dedicado, comunidades explícitas interpretadas por cada salida, comprobaciones automatizadas desde recolectores externos y un interruptor de corte 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ó, se preservó, se eliminó o nunca se adjuntó en este evento no se establece 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 simple de salida: anunciar solo sus propios prefijos autorizados y los prefijos de clientes explícitamente aprobados. Una denegación predeterminada es más fiable que intentar identificar cada ruta que no debe salir.RFC 8212, publicado en 2017, codificó el rechazo predeterminado de BGP externo cuando no se configura una política de importación o exportación explícita. 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 entrada de clientes 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 profundo de Cloudflare encontró que la información del registro de ruta 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. Laguía de operaciones y seguridad BGP de RFC 7454, publicada en 2015, recomienda políticas para rutas recibidas y anunciadas en cada frontera, controles de prefijos de clientes, filtrado de ruta AS y límites de prefijos máximos.

Rechazo descendente y de pares.Las redes que recibieron las rutas de Verizon también tuvieron la oportunidad de rechazarlas. Debido a que Verizon es una gran red de tránsito, muchos destinatarios dieron a sus anuncios una confianza sustancial. Algunas redes que utilizan la 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 filtración 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 distribuye es menos eficiente que rechazarlo en la sesión de cliente original. La prevención más cercana a la violación de 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 de una configuración correcta de la política de ruta. 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 solo la revisión de configuración como prueba de que una ruta permaneció local.

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

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, declara 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 retuvieron a AS13335 como su origen pero excedieron la longitud máxima autorizada. Por lo tanto, eran inválidos bajo 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 de 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 ejecución remota. Verizon u otra red receptora tenía que recuperar los datos RPKI validados, aplicar la validación a la ruta del cliente y rechazar las inválidas. Cloudflare podía rechazar las rutas inválidas que entraban en 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 del 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 filtración de ruta. 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-189de NIST combina RPKI y la validación de origen BGP con el filtrado de prefijos y prácticas más amplias de resiliencia entre dominios. Trata las filtraciones 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 hacer que rutas legítimas sean rechazadas. La cobertura de ROA, la longitud máxima, el vencimiento, la salud de la clave y el repositorio, y los cambios de enrutamiento planificados necesitan control de cambios. Un panel que muestra 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 pudieran haber desplegado una versión terminada en junio de 2019, pero muestran cómo la industria ha tratado de codificar suposiciones que antes eran implícitas.

RFC 9234, publicado en 2022, introdujo los Roles BGP y el atributo Only-to-Customer, u OTC. Las redes vecinas pueden declarar si una relación es de proveedor, cliente, par, servidor de rutas o cliente de servidor de rutas. El acuerdo de roles y el manejo de OTC permiten a los routers detectar algunos anuncios que cruzan un límite de relación en una dirección impermisible. 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 de clientes. Los Roles BGP convierten parte del conocimiento de la topología comercial de una convención de operador a un estado visible por 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, incluida su capacidad para detener rutas en las que aparece una gran red protegida 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 una prueba de que un control universal disponible en el mercado estaba 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 prometedor porque muchas filtraciones 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áfica entonces obligatorio.

La detección también maduró. Cloudflare describió más tarde suservicio de detección de filtraciones de rutas Radar, que utiliza relaciones de enrutamiento y rutas observadas para señalar posibles filtraciones. La monitorización reduce el tiempo para saber y el tiempo para coordinar, pero no evita que un router acepte la ruta. Un incidente de dos horas aún puede imponer daños globales si la ruta de remediación es una cadena telefónica humana. La detección tiene que conectarse a una acción ensayada: identificar los prefijos afectados, aplicar una política defensiva cuando sea seguro, contactar a los operadores autorizados, publicar el estado del cliente, verificar los retiros en recolectores independientes y observar la recuperación del tráfico.

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

1. Publicar una autoridad de ruta precisa a través de objetos de IRR y ROAs.
2. Generar filtros de importación de clientes a partir de datos fiables y actualizarlos de forma segura.
3. Rechazar por defecto las rutas que carecen de una política explícita.
4. Aplicar las expectativas de cono de cliente, ruta AS, longitud de prefijo y máximo de prefijos.
5. Rechazar los anuncios inválidos de RPKI en cada entrada externa relevante.
6. Añadir controles sensibles a la relación, como Roles BGP, OTC, Peerlock y, a medida que madure, la validación ASPA.
7. Observar la propagación desde puntos de vista externos independientes.
8. Mantener contactos operativos probados continuamente y autoridad para retirar rutas.

Ningún elemento individual sustituye al resto. Su valor proviene de diferentes modos de fallo.

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

El registro técnico público respalda el análisis de responsabilidad, pero no contiene una sentencia judicial, orden de un regulador o un conjunto completo de contratos que asignen la 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 qué salvaguarda y quién podrí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 restringir 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 la ayuda para retirar las rutas. La cooperación rápida redujo la duración; no elimina la falla del control preventivo.

AS396531.La red multihomed fue el puente entre proveedores. Su anuncio observable hacia Verizon hizo que pareciera proporcionar accesibilidad para rutas aprendidas a través de DQE. Una empresa no tránsito debería exportar una lista de permitidos 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 especulación. La responsabilidad organizacional se atribuye 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 fue el control no ejercido más consecuente. Una gran red de tránsito 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 de IRR relevantes y la validación RPKI podrían haberlo rechazado e informa 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 de alta consecuencia previsible 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 fuga externas, reversión y controles que dificultan 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: ¿el producto verificó continuamente la contención 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 pudo configurar la sesión de cliente de Verizon. Sin embargo, había vendido a los clientes un servicio de disponibilidad y seguridad basado en el enrutamiento global. Por lo tanto, su responsabilidad se sitúa en los controles residuales: ROAs precisas, interconexión diversa, monitorización externa de rutas, diagnóstico rápido, contactos de pares accesibles, comunicación con el cliente, opciones de mitigación y divulgación transparente. También tenía el deber de no reclamar en exceso lo que su arquitectura podía soportar. Anycast y una gran red global reducen muchas fallas pero no pueden derrotar una ruta más específica aceptada globalmente sin ayuda de redes validadoras.

Otras redes.Los pares y descendentes que aceptaron las rutas de Verizon no estaban igualmente posicionados para conocer la autorización de cliente de AS396531, pero podían desplegar la validación RPKI y los 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, sin embargo, 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. Esos son controlables. La apertura del protocolo explica por qué una falla puede propagarse; no excusa a un proveedor de filtrar las rutas de los clientes.

La responsabilidad comercial 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 filtración de ruta de junio causó una interrupción significativa en su tráfico y en el de otros proveedores. Advertía que las filtraciones de rutas podrían dañar la reputación y la confianza, describía compromisos de nivel de servicio que podrían dar lugar a créditos o reembolsos, y declaraba que la filtración de ruta 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 filtración de ruta de junio a la luz de los compromisos de nivel de servicio. El intercambio es un ejemplo compacto de cómo la responsabilidad pasa del centro de operaciones de red a la información corporativa. 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 filtración de ruta 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 cambios 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 total o del cliente 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 una recuperación estable.

Lo que los consejos deben 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 simplista. 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ó divulgaciones para inversores y expuso la concentración fuera de los contratos formales de proveedores de nube. El consejo no necesita elegir la sintaxis del router. Necesita evidencia de que la gerencia sabe dónde la disponibilidad depende del comportamiento de otro sistema autónomo.

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

El denominador importa en cada métrica. Decir que RPKI está desplegado en los routers 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 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 los recolectores independientes. Las pruebas necesitan salvaguardas para que no se conviertan en filtraciones, pero evitar todas las pruebas realistas deja el comportamiento de mayor riesgo sin probar.

Resiliencia del cliente sin consejos simplistas de múltiples proveedores

A menudo los clientes escuchan que deben evitar la dependencia comprando una segunda CDN, un segundo proveedor de DNS o una segunda nube. La diversidad puede ayudar, pero las fallas de enrutamiento no respetan las etiquetas de los productos. Dos proveedores pueden compartir tránsito, puntos de intercambio, fibra, recolectores 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 aplicación del cliente tenga la oportunidad de ayudar.

El diseño correcto comienza con la ruta de servicio. ¿Qué proveedor es autoritativo para el 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 cambiar el tráfico sin crear una omisión de seguridad? ¿Qué tan rápido cambian los cachés de DNS? ¿Los clientes retienen las conexiones? ¿Tiene el proveedor secundario la configuración y capacidad actuales? ¿Puede la organización distinguir una falla de enrutamiento ascendente de una falla de origen antes de mover el tráfico?

Para algunos servicios, la entrega activa-activa a través de proveedores enrutados de forma independiente 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 de ROV, controles de filtrado de clientes, participación en MANRS, prácticas de contacto de incidentes, monitorización externa y resultados de pruebas anonimizados. Lasacciones de operadores de red de 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 funcionamiento 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. 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 reconciliar sus propias observaciones. Una cláusula de fuerza mayor o de terceros redactada de forma restrictiva puede limitar la compensación, pero no debería poner fin al 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 medida voluntario. Las mejores prácticas no eran desconocidas. El filtrado de prefijos y AS, los datos de IRR, los controles de prefijos máximos, RPKI y los registros de contacto de operadores existían. La adopción y el aseguramiento eran desiguales, particularmente cuando una red tenía que soportar el costo del despliegue mientras los beneficios se extendían por Internet.

Ese problema de acción colectiva atrajo posteriormente una atención gubernamental más explícita. LaHoja de Ruta para Mejorar la Seguridad del Enrutamiento en Internetde la Oficina del Director Nacional de Ciberseguridad de EE. UU. de 2024 describe la incapacidad de BGP, en la 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 del origen de ruta, especialmente entre los principales proveedores y los 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 la Comisión Federal de Comunicaciones de 2024 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. Nuevamente, esto no crea responsabilidad retroactiva para junio de 2019. Ilustra un cambio de gobernanza de preguntar si un proveedor admite RPKI en principio a exigir 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 router. 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 clientes probada, gobernanza de excepciones, velocidad de detección, preparación de contactos y aprendizaje de incidentes.

El acceso supervisor confidencial puede ser apropiado para detalles sensibles, mientras que las métricas agregadas de adopción e 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 mundial; los 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 regla nacional puede mejorar la conducta de los proveedores bajo su jurisdicción, pero los estándares interoperables y las normas de operadores son lo que hace que esa mejora viaje.

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

El análisis profundo 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 rendición de cuentas.

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

• 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 de DQE y Verizon, la línea de tiempo de caída y subida 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, el entorno de prefijos máximos, 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 escalada de contacto de pares, el impacto en el cliente 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 atribuible específicamente a la filtración de ruta 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 unas a otras. 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 separadas esas clases de evidencia.

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 rendición de cuentas pública es más débil cuando la evidencia permanece privada, pero el artículo no puede inferir que no ocurrió aprendizaje.

Un estándar de rendición de cuentas duradero para la resiliencia de rutas

La interrupción de junio de 2019 se recuerda porque una pequeña red 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 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 los 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. Un mejor monitoreo y preparación de contactos podría 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 el de víctima o propietario. Era el destino cuya accesibilidad fue dañada 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ó el retiro, explicó el registro de ruta y divulgó las consecuencias contractuales. Aún debía a los clientes un estado claro, el esfuerzo de recuperación, los remedios financieros cuando 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 final de rendición de cuentas no es cero filtraciones de rutas. Ninguna red global puede garantizar que cada sistema autónomo configurará cada sesión correctamente. 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 ensayada y produjo suficiente evidencia para que los clientes y supervisores verifiquen la mejora.

Eso es lo que parece 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.