Una fuga de ruta importante ha afectado a grandes sectores de Internet, incluido Cloudflare
Que paso
El 24 de junio, a las 10:30 UTC, Internet colapsó: una pequeña empresa en el norte de Pensilvania vertió una corriente de tráfico desde muchas rutas que pasaban por un gran proveedor Verizon (AS701); con el mismo éxito, el navegador podría enviar una corriente de automóviles desde una carretera de varios carriles a una calle estrecha . Como resultado, muchos sitios web en Cloudflare y muchos otros proveedores tienen problemas de acceso. Esto no debería haber sucedido en absoluto, porque Verizon no debería haber enviado estas rutas a toda Internet. Para saber cómo sucedió, sigue leyendo.
Ya escribimos sobre tales incidentes antes, ocurren de vez en cuando, pero esta vez sentimos las consecuencias en todo el mundo. El problema fue exacerbado por el optimizador BGP de Noction . Tiene una función que divide los prefijos IP recibidos en otros más pequeños y específicos. Por ejemplo, nuestra ruta IPv4 104.20.0.0/20 se dividió en 104.20.0.0/21 y 104.20.8.0/21. Como si la señal de Pennsylvania hubiera sido reemplazada por otras dos: Pittsburgh, PA y Philadelphia, PA. Al dividir grandes bloques de IP en pequeños, la red gestiona el tráfico dentro de sí misma, pero esta separación no debería haber estado disponible públicamente. De lo contrario, surgen tales problemas.
Para explicar lo que sucedió después, primero recordemos cómo funciona Internet. En esencia, Internet es una red que consiste en redes llamadas sistemas autónomos. Cada sistema autónomo tiene su propio identificador único. Todas las redes están conectadas entre sí mediante el Border Gateway Protocol (BGP). BGP conecta estas redes y forma la estructura de Internet en la que pasa el tráfico, por ejemplo, de su proveedor de Internet a un sitio web popular en otra parte del mundo.
A través de BGP, las redes intercambian información sobre rutas, a saber: cómo llegar a ellas desde cualquier lugar. Estas rutas pueden ser específicas (como una ciudad específica en el mapa) o generales (como un área). Y luego sucedieron problemas.
Un proveedor de servicios de Internet en Pensilvania ( AS33154 - DQE Communications) utilizó BGP Optimizer en su red, lo que significa que había muchas rutas específicas en su red. Las rutas específicas tienen prioridad sobre las generales (en el mismo navegador, por ejemplo, la ruta al Palacio de Buckingham será más específica que la ruta a Londres).
DQE proporcionó estas rutas específicas a su cliente ( AS396531 - Allegheny Technologies Inc), y desde allí llegaron al proveedor de tránsito ( AS701 - Verizon), que transportaba estas rutas "óptimas" por Internet. Parecen óptimos porque tienen más detalles y detalles.
Y no se suponía que todo esto fuera más allá de Verizon. Aunque existen formas efectivas de protección contra tales fallas, la falta de filtros de Verizon ha llevado a un colapso que afecta a muchos servicios como Amazon, Linode y Cloudflare .
Como resultado, Verizon, Allegheny y DQE golpearon a un grupo de usuarios que intentaban acceder a estos servicios a través de su red. No fueron diseñados para un tráfico tan poderoso, lo que provocó interrupciones. E incluso si hubiera suficientes recursos, DQE, Allegheny y Verizon no deberían haberles dicho a todos sobre la ruta ideal para Cloudflare, Amazon, Linode, etc.
Proceso de fuga de BGP con BGP Optimizer.
En los peores momentos del fracaso, observamos una pérdida de aproximadamente el 15% del tráfico global.
Niveles de tráfico de Cloudflare durante un incidente.
¿Cómo se puede prevenir una fuga?
Hay varias formas
Para una sesión BGP, puede establecer un límite estricto para los prefijos aceptados, y si el número de prefijos excede el umbral, el enrutador finalizará la sesión. Si Verizon tuviera tal límite en los prefijos, no habría pasado nada. Para un proveedor como Verizon, instalarlo sería inútil. ¿Por qué no había límites? Tengo una versión: negligencia y pereza.
Otra forma de prevenir tales fugas es usar el filtro IRR. IRR (Internet Routing Registry) es una base de datos distribuida de rutas de Internet a las que las redes agregan entradas. Otros operadores de red usan estas entradas IRR para crear listas de prefijos específicos para sesiones BGP con otras redes. Si se usaran filtros IRR, ninguna de estas redes aceptaría rutas específicas erróneas. Increíblemente, Verizon no tuvo este filtrado en absoluto en las sesiones de BGP con Allegheny Technologies, aunque el filtrado IRR se ha utilizado (y bien documentado) durante más de 24 años. Los filtros IRR no le costarían nada a Verizon y no limitarían su servicio de ninguna manera. Y de nuevo: negligencia y pereza.
El año pasado, implementamos y desplegamos la plataforma RPKI, que simplemente evita tales fugas. Establece filtros de acuerdo con la red de origen y el tamaño del prefijo. Cloudflare anuncia prefijos con un tamaño máximo de 20. RPKI indica que no se pueden aceptar prefijos más específicos, independientemente de la ruta. Para que este mecanismo funcione, BGP Origin Validation debe estar habilitado en la red. Muchos proveedores, por ejemplo, AT&T ya utilizan con éxito RPKI en su red.
Si Verizon usara RPKI, verían que las rutas propuestas no son válidas y el enrutador las rechazará automáticamente.
¡Cloudflare aconseja a todos los operadores de red que implementen RPKI ahora mismo!
Prevención de fugas de ruta utilizando IRR, RPKI y límites de prefijo.
Todas estas recomendaciones están bien descritas en MANRS ( Normas mutuamente acordadas para la seguridad del enrutamiento ).
¿Cómo resolver el problema?
El equipo de la red Cloudflare contactó a las redes afectadas AS33154 (DQE Communications) y AS701 (Verizon). No fue fácil, tal vez porque cuando todo comenzó, era una madrugada en la costa este de los Estados Unidos.
Captura de pantalla de una carta a Verizon.
Uno de nuestros ingenieros de red se contactó rápidamente con DQE Communications y, después de un breve retraso, nos conectamos con el que podía resolver el problema. Con nuestro soporte telefónico, DQE pudo dejar de enviar rutas "optimizadas" a Allegheny Technologies Inc. Les estamos agradecidos por su ayuda. Todo se estabilizó y volvió a la normalidad.
Captura de pantalla de los intentos de contactar a DQE y los Servicios de soporte de Verizon
Desafortunadamente, a pesar de todos nuestros intentos de contactar a Verizon por teléfono y correo electrónico, en el momento de la redacción (han pasado más de 8 horas desde el incidente), nadie nos respondió y no sabemos si están haciendo algo. .
Nosotros en Cloudflare no querríamos repetir esto, pero desafortunadamente, se está haciendo muy poco para esto. Es hora de que la industria tome medidas más efectivas para garantizar la seguridad del enrutamiento, por ejemplo, con sistemas como RPKI. Esperamos que los principales proveedores sigan Cloudflare, Amazon y AT&T y comiencen a verificar las rutas . Esto es especialmente cierto para ti, Verizon. Todavía estamos esperando una respuesta.
Y aunque no pudimos influir en lo que sucedió, nos disculpamos por la interrupción del servicio. Nos preocupamos por nuestros clientes, y los ingenieros de EE. UU., Reino Unido, Australia y Singapur nos contactaron unos minutos después de descubrir el problema.
Otros artículos etiquetados con BGP .