Hoy presentamos la API y los datos de filtraciones de ruta de Cloudflare Radar para que cualquiera pueda obtener información sobre las filtraciones de rutas a través de Internet. Hemos creado un sistema integral que incluye datos de fuentes públicas y la visión de Internet de Cloudflare obtenida de nuestra red global masiva. El sistema proporciona ahora datos de filtraciones de ruta en las páginas ASN de Cloudflare Radar y a través de la API.
Esta publicación del blog tiene dos partes. En primer lugar, analizaremos el protocolo de puerta de enlace de frontera (BGP) y las filtraciones de ruta y, a continuación, los detalles de nuestro sistema de detección de filtración de rutas y cómo complementa a Cloudflare Radar.
Sobre BGP y las filtraciones de ruta
El enrutamiento entre dominios, es decir, el intercambio de información de accesibilidad entre redes, es fundamental para el bienestar y el rendimiento de Internet. El protocolo de enlace de puerta de frontera (BGP) es el protocolo de enrutamiento de facto que intercambia información de enrutamiento entre organizaciones y redes. En esencia, BGP asume que la información que se intercambia es auténtica y fiable, lo que lamentablemente ya no es una suposición válida en la red de Internet actual. En muchos casos, las redes pueden cometer errores o mentir de forma intencionada sobre la información de accesibilidad y propagarla al resto de Internet. Estos incidentes pueden causar interrupciones significativas de las operaciones normales de Internet. Un tipo de incidente disruptivo de este tipo son las filtraciones de ruta.
Consideramos las filtraciones de ruta como la propagación de anuncios de enrutamiento más allá de su alcance previsto (RFC7908). Las filtraciones de ruta pueden causar una interrupción significativa que afecta a millones de usuarios de Internet, como hemos visto en muchos incidentes destacados en el pasado. Por ejemplo, en junio de 2019, una configuración incorrecta en una pequeña red de Pensilvania, EE. UU. (AS396531 - Allegheny Technologies Inc) filtró accidentalmente un prefijo de Cloudflare a Verizon, que procedió a propagar la ruta configurada de manera errónea al resto de sus pares y clientes. Como resultado, el tráfico de una gran parte de Internet pasaba por los enlaces de una red pequeña, cuya capacidad era limitada. La congestión resultante provocó que se perdiera la mayor parte del tráfico de Cloudflare hacia y desde el rango de IP afectado.
Un incidente similar en noviembre de 2018 provocó que los servicios de Google no estuvieran disponibles de manera generalizada cuando un proveedor de servicios de Internet (ISP) nigeriano (AS37282 - Mainone) filtró accidentalmente una gran cantidad de prefijos de IP de Google a sus pares y proveedores, violando el principio valley-free.
Estos incidentes ilustran no solo que las filtraciones de ruta pueden tener un gran impacto, sino también los efectos multiplicadores que las configuraciones erróneas en redes regionales pequeñas pueden tener en Internet a nivel mundial.
A pesar de la importancia de detectar y rectificar las filtraciones de rutas con rapidez, a menudo se detectan solo cuando los usuarios comienzan a informar sobre los efectos perceptibles de las filtraciones. El desafío de detectar y prevenir filtraciones de rutas surge del hecho de que las relaciones comerciales de los sistemas autónomos (AS) y las políticas de enrutamiento de BGP, por lo general, no se revelan y la red afectada a menudo está alejada de la raíz de la filtración de ruta.
En los últimos años se han propuesto soluciones para evitar la propagación de rutas filtradas. Dichas propuestas incluyen RFC9234324 y ASPA, que amplía el BGP para anotar sesiones con el tipo de relación entre las dos redes AS conectadas para permitir la detención y la prevención de filtraciones de ruta.
Una propuesta alternativa para implementar una señalización similar de roles BGP es mediante el uso de Comunidades BGP, un atributo transitivo utilizado para codificar metadatos en anuncios BGP. Si bien estas líneas son prometedoras a largo plazo, aún se encuentran en etapas muy preliminares y no se espera que se adopten pronto a gran escala.
En Cloudflare, hemos desarrollado un sistema para detectar eventos de filtraciones de ruta automáticamente y enviar notificaciones a varios canales para conseguir visibilidad. A medida que continuamos con nuestros esfuerzos para proporcionar información más relevante al público, nos complace anunciar hoy la API de datos abiertos para nuestros resultados de detección de filtraciones de ruta y la integración de los resultados en las páginas de Cloudflare Radar.
Definición y tipos de filtración de rutas
Antes de pasar a ver cómo diseñamos nuestros sistemas, primero haremos una breve introducción sobre qué es una filtración de ruta y por qué es importante detectarla.
Nos referimos al documento IETF RFC7908 publicado "Problem Definition and Classification of BGP Route Leaks" (Definición de problemas y clasificación de filtraciones de rutas BGP) para definir las filtraciones de rutas.
> Una filtración de ruta es la propagación de anuncios de enrutamiento que van más allá de su alcance previsto.
El alcance previsto a menudo se define concretamente como políticas de enrutamiento entre dominios basadas en las relaciones comerciales entre los sistemas autónomos (ASes). Estas relaciones comerciales se clasifican en términos generales en cuatro categorías: clientes, proveedores de tránsito, pares y familiares, aunque es posible que haya disposiciones más complejas.
En una relación cliente-proveedor, el AS del cliente tiene un acuerdo con otra red para pasar su tráfico a la tabla de enrutamiento global. En una relación entre pares, dos AS acuerdan intercambiar tráfico bilateral de forma gratuita, pero solo entre sus propias IP y las IP de sus clientes. Finalmente, los AS que pertenecen a la misma entidad administrativa se consideran familia y su intercambio de tráfico suele no tener restricciones. La imagen siguiente ilustra cómo los tres tipos principales de relaciones se traducen en políticas de exportación.
Al categorizar los tipos de relaciones de nivel AS y sus implicaciones en la propagación de rutas BGP, podemos definir varias fases de anuncios de origen de prefijo durante la propagación:
Ascendente: todos los segmentos de ruta durante esta fase son de cliente a proveedor
Emparejamiento: un segmento de ruta entre pares
Descendente: todos los segmentos de ruta durante esta fase son de proveedor a cliente
Una ruta AS que sigue el principio de enrutamiento valley-free tendrá las fases ascendente, emparejamiento y descendente, que son opcionales, pero que tienen que seguir ese orden. Este es un ejemplo de una ruta AS que se ajusta al enrutamiento valley-free.
En RFC7908, "Problem Definition and Classification of BGP Route Leaks", los autores definen seis tipos de filtraciones de ruta y nos referimos a estas definiciones en el diseño de nuestro sistema. A continuación, puede ver las ilustraciones de cada uno de los tipos de filtraciones de ruta.
Tipo 1: curva cerrada con prefijo completo
> Un AS de host múltiple aprende una ruta de un ISP ascendente y simplemente la propaga a otro ISP ascendente (el giro prácticamente se parece a una curva cerrada). No se modifican ni el prefijo ni la ruta AS en la actualización.
Una ruta AS que contiene un segmento de proveedor-cliente y cliente-proveedor se considera una filtración de tipo 1. El siguiente ejemplo: AS4 → AS5 → AS6 forma una filtración de tipo 1.
El tipo 1 es el tipo de filtración de ruta más reconocido y tiene un gran impacto. En muchos casos, una ruta de cliente es preferible a una ruta de pares o proveedor. En este ejemplo, es probable que AS6 prefiera enviar tráfico a través de AS5 en lugar de sus otras rutas de pares o proveedores, lo que hace que AS5 se convierta de forma involuntaria en un proveedor de tránsito. Esto puede afectar significativamente el rendimiento del tráfico relacionado con el prefijo filtrado o provocar interrupciones si el AS filtrado no está preparado para gestionar una gran afluencia de tráfico.
En junio de 2015, Telekom Malaysia (AS4788), un ISP regional, filtró más de 170 000 rutas que aprendió de sus proveedores y pares a su otro proveedor Level3 (AS3549, ahora Lumen). Level3 aceptó las rutas y las siguió propagando a sus redes descendentes, lo que a su vez provocó importantes problemas de red a nivel mundial.
Tipo 2: filtración lateral ISP-ISP-ISP
La filtración de tipo 2 se define como la propagación de rutas obtenidas entre pares, creando dos o más segmentos de ruta entre pares consecutivos.
Este es un ejemplo: AS3 → AS4 → AS5 forma una filtración de tipo 2.
En un ejemplo de este tipo de filtraciones intervienen más de tres redes muy grandes que aparecen en secuencia. Las redes muy grandes (como Verizon y Lumen) no compran tránsito unas de otras y tener más de tres redes en la ruta en secuencia a menudo es una indicación de una filtración de ruta.
Sin embargo, en el mundo real, no es inusual ver varias redes entre pares pequeñas que intercambian rutas y que transmiten entre sí. Existen razones comerciales legítimas para tener este tipo de ruta de red. Nos preocupa menos este tipo de filtración de ruta en comparación con el tipo 1.
Tipo 3 y 4: rutas de proveedor-par; rutas de par-proveedor
Estos dos tipos implican la propagación de rutas desde un proveedor o un par, no a un cliente, sino a otro par o proveedor. A continuación, puede ver las ilustraciones de los dos tipos de filtraciones:
Como en el ejemplo mencionado anteriormente, un ISP nigeriano que se empareja con Google filtró accidentalmente su ruta a su proveedor AS4809 y, por lo tanto, generó una filtración de ruta tipo 4. Debido a que las rutas a través de clientes generalmente se prefieren a otras, el proveedor más grande (AS4809) redirigió su tráfico a Google a través de su cliente; es decir, el ASN que se filtró, sobrecargó al pequeño ISP e interrumpió Google durante más de una hora.
Resumen de la filtración de ruta
Hasta ahora, hemos analizado los cuatro tipos de filtraciones de rutas definidas en RFC7908. El denominador común de los cuatro tipos de filtraciones de ruta es que todos están definidos mediante relaciones AS, es decir, pares, clientes y proveedores. Resumimos los tipos de filtraciones al clasificar la propagación de la ruta AS en función de dónde se aprenden las rutas y hacia dónde se propagan. Los resultados se muestran en la siguiente tabla.
Rutas desde el /propagadas al
| Routes from / propagates to | To provider | To peer | To customer |
|---|---|---|---|
| From provider | Type 1 | Type 3 | Normal |
| From peer | Type 4 | Type 2 | Normal |
| From customer | Normal | Normal | Normal |
Proveedor
Par
Cliente
Proveedor
Tipo 1
Tipo 3
Normal
Par
Tipo 4
Tipo 2
Normal
Cliente
Normal
Normal
Normal
Podemos resumir toda la tabla en una sola regla: las rutas obtenidas de un AS que no es cliente solo se pueden propagar a los clientes.
Nota: las filtraciones de ruta de tipo 5 y tipo 6 se definen como nuevos orígenes de prefijos y anuncios de prefijos privados. El tipo 5 está más estrechamente relacionado con los secuestros de prefijos, a los que planeamos expandir nuestro sistema en el futuro. Por su parte, las filtraciones de tipo 6 no entran en el ámbito de este informe. Los lectores interesados pueden consultar las secciones 3.5 y 3.6 de RFC7908 para más información.
El sistema de filtración de ruta de Cloudflare Radar
Ahora que sabemos qué es una filtración de ruta, hablemos sobre cómo diseñamos nuestro sistema de detección de filtración de ruta.
Desde un nivel muy alto, dividimos nuestro sistema en tres elementos distintos:
Módulo de recopilación de datos sin procesar: responsable de recolectar datos BGP de varias fuentes y proporcionar un flujo de mensajes BGP a los consumidores intermedios.
Módulo de detección de filtraciones: responsable de comprobar si una ruta de nivel AS determinada es una filtración de ruta y de calcular el nivel de confianza de la evaluación, añadiendo y proporcionando toda la evidencia externa necesaria para un análisis más detallado del evento.
Módulo de almacenamiento y notificaciones: responsable de otorgar acceso a los eventos de filtración de ruta detectados y enviar notificaciones a las partes que correspondan. Esto también podría incluir la creación de un panel de control para facilitar el acceso y la búsqueda de eventos históricos y proporcionar la interfaz de usuario para el análisis de alto nivel del evento.
Módulo de recopilación de datos
Hay tres tipos de entrada de datos que tenemos en cuenta:
Histórico: archivos de almacenamiento BGP de un intervalo de tiempo en el pasado.a.Archivos BGP: RouteViews y RIPE RIS.
Tiempo semirreal: archivos de almacenamiento BGP tan pronto como estén disponibles, con un retraso de 10-30 minutos.a. Archivos RouteViews y RIPE RIS con agente de datos que comprueba periódicamente los archivos nuevos (p. ej., BGPKIT Broker)
Tiempo real: fuentes de datos auténticos en tiempo real.a. RIPE RIS Liveb. Fuentes BGP internas de Cloudflare
En esta versión, usamos la fuente de datos en tiempo semirreal para el sistema de detección, es decir, los archivos de actualizaciones BGP de RouteViews y RIPE RIS. Para completar los datos, procesamos los datos de todos los recopiladores públicos de estos dos proyectos (un total de 63 recopiladores y más de 2400 pares recopiladores) e implementamos una proceso que es capaz de gestionar el procesamiento de datos BGP conforme están disponibles los archivos de datos.
Para la indexación y el procesamiento de archivos de datos, implementamos una instancia local de BGPKIT con la función Kafka habilitada para el tránsito de mensajes y una canalización de procesamiento de datos MRT basada en Rust SDK BGPKIT Parser. El módulo de recopilación de datos procesa archivos MRT y convierte los resultados en un flujo de mensajes BGP a más de 2000 millones de mensajes BGP por día (aproximadamente 30 000 mensajes por segundo).
Detección de filtración de ruta
El módulo de detección de filtraciones de ruta funciona a nivel de anuncios BGP individuales. El componente de detección investiga un mensaje BGP cada vez y calcula la probabilidad de que un mensaje BGP dado sea el resultado de un evento de filtración de ruta.
Basamos nuestro algoritmo de detección principalmente en el modelo valley-free, que creemos que puede capturar la mayoría de los incidentes de filtración de ruta notables. Como se mencionó anteriormente, la clave para tener un número bajo de falsos positivos para detectar filtraciones en la ruta con el modelo valley-free es tener relaciones de nivel de AS precisas. Aunque no todos los AS publican esos tipos de relaciones, se han dedicado más de dos décadas de investigación a la inferencia de los tipos de relaciones, utilizando datos de BGP observados públicamente.
Si bien se ha demostrado que los algoritmos de inferencia de relaciones de última generación son muy precisos, incluso un pequeño margen de error puede generar imprecisiones en la detección de filtraciones de ruta. Para mitigarlo, sintetizamos varias fuentes de datos para inferir las relaciones a nivel de AS, incluidos los datos de relación del AS de CAIDA/UCSD y nuestro conjunto de datos de relación del AS creado internamente. Con base en las dos relaciones del nivel AS, creamos un conjunto de datos mucho más granular en los niveles por prefijo y por pares. El conjunto de datos mejorado nos permite responder preguntas como cuál es la relación entre AS1 y AS2 con respecto al prefijo P observado por el colector X. Esto elimina gran parte de la ambigüedad en los casos en que las redes tienen varias relaciones diferentes basadas en prefijos y ubicaciones geográficas y, por ende, nos ayuda a reducir el número de falsos positivos en el sistema. Además de los conjuntos de datos de relaciones AS, también aplicamos el conjunto de datos AS Hegemony de IHR IIJ para reducir aún más los falsos positivos.
Almacenamiento y presentación de filtraciones de ruta
Después de procesar cada mensaje BGP, almacenamos las entradas de filtraciones de ruta generadas en una base de datos para almacenamiento y exploración a largo plazo. También añadimos anuncios de BGP de filtraciones de ruta individuales y agrupamos las filtraciones relevantes del mismo ASN de filtración dentro de un periodo corto en eventos de filtración de rutas. Los eventos de filtración de ruta estarán disponibles para diferentes aplicaciones posteriores, como interfaces de usuario web, una API o alertas.
Filtraciones de ruta en Cloudflare Radar
En Cloudflare, nuestra misión es ayudar a mejorar Internet y eso incluye compartir nuestros esfuerzos para supervisar y proteger el enrutamiento de Internet. Hoy, lanzamos la versión beta pública de nuestro sistema de detección de filtraciones de ruta.
A partir de hoy, los usuarios que visiten las páginas del ASN de Cloudflare Radar encontrarán la lista de filtraciones de rutas que afectan a ese AS. Consideramos que un AS se ve afectado cuando el AS de la filtración está a un salto de este en cualquier dirección, antes o después.
Se puede acceder directamente a la página del ASN de Cloudflare Radar a través de https://radar.cloudflare.com/as{ASN}. Por ejemplo, puede ir a https://radar.cloudflare.com/as174 para ver la página de información general de Cogent AS174. Las páginas del ASN muestran ahora una tarjeta dedicada para filtraciones de ruta detectadas que son relevantes para el ASN actual dentro del rango de tiempo seleccionado.
Los usuarios también pueden empezar a usar nuestra API de datos públicos para buscar eventos de filtraciones de ruta con respecto a un ASN determinado. Nuestra API admite el filtrado de resultados de filtraciones de ruta por rangos de tiempo y AS involucrados. Esta es una captura de pantalla de la página de documentación de la API de eventos de filtración de ruta en el sitio de documentos de la API que hemos actualizado recientemente.
Próximamente: seguridad del enrutamiento
Estamos trabajando en más funciones de la detección de las filtraciones de ruta, tales como una página de vista global, notificaciones de filtraciones de ruta, API más avanzadas, scripts de automatización personalizados y conjuntos de datos de archivos históricos que se incluirán en Cloudflare Radar con el tiempo. Tus comentarios y sugerencias también son muy importantes para que podamos seguir mejorando nuestros resultados de detección y ofrecer mejores datos al público.
Además, continuaremos trabajando en otros temas importantes acerca de la seguridad del enrutamiento de Internet, incluida la detección de secuestros de BGP a nivel mundial (sin limitarse a las redes de nuestros clientes), monitoreo de validación de RPKI, herramientas y diseños de arquitectura de código abierto y puerta de enlace web de seguridad de enrutamiento centralizado. Nuestro objetivo es proporcionar los mejores datos y herramientas para enrutar la seguridad a las comunidades a fin de mejorar Internet entre todos para que sea una red más segura.
Mientras tanto, hemos abierto una sala Radar en nuestro Discord Server para desarrolladores. No dudes en unirte y habla con nosotros. Nuestro equipo está deseando recibir comentarios y responder cualquier duda.
Visita Cloudflare Radar si desea más información sobre Internet. Puede seguirnos en Twitter para conocer las últimas novedades de Radar.