Hola, mi nombre es Alexander Azimov. En Yandex desarrollo varios sistemas de monitoreo, así como arquitectura de redes de transporte. Pero hoy hablaremos del protocolo BGP.
Hace una semana, Yandex habilitó ROV (Validación de origen de ruta) en las interfaces con todos los socios de peering, así como en los puntos de intercambio de tráfico. Lea a continuación por qué se hizo esto y cómo afectará la interacción con los operadores de telecomunicaciones.
BGP y lo que tiene de malo
Probablemente sepa que BGP fue diseñado como un protocolo de enrutamiento entre dominios. Sin embargo, en el camino, el número de casos de uso logró crecer: hoy BGP, gracias a numerosas extensiones, se ha convertido en un bus de mensajes, que cubre tareas desde el operador VPN hasta la ahora de moda SD-WAN, e incluso ha encontrado aplicación como un transporte para un controlador tipo SDN, convirtiendo el vector de distancia BGP en algo similar al protocolo satelital de enlaces.
La figura. 1.
¿Por qué BGP ha recibido (y continúa recibiendo) tantos usos? Hay dos razones principales:
- BGP es el único protocolo que funciona entre sistemas autónomos (AS);
- BGP admite atributos en formato TLV (tipo-longitud-valor). Sí, el protocolo no está solo en esto, pero como no hay nada que lo reemplace en los cruces entre operadores de telecomunicaciones, siempre resulta más rentable adjuntarle otro elemento funcional que admitir un protocolo de enrutamiento adicional.
¿Lo que está mal con él? En resumen, el protocolo no tiene mecanismos integrados para verificar la exactitud de la información recibida. Es decir, BGP es un protocolo de confianza a priori: si quiere decirle al mundo que ahora posee la red de Rostelecom, MTS o Yandex, ¡por favor!
Filtro basado en IRRDB: lo mejor de lo peor
Surge la pregunta: ¿por qué Internet sigue funcionando en tal situación? Sí, funciona la mayor parte del tiempo, pero al mismo tiempo explota periódicamente, haciendo inaccesibles segmentos nacionales enteros. Aunque la actividad de los piratas informáticos en BGP también está aumentando, la mayoría de las anomalías todavía son causadas por errores. El ejemplo de este año es en Bielorrusia, lo que hizo que una parte importante de Internet fuera inaccesible para los usuarios de MegaFon durante media hora. Otro ejemplo - rompió una de las redes CDN más grandes del mundo.
Arroz. 2. Intercepción del tráfico de Cloudflare
Pero aún así, ¿por qué estas anomalías ocurren una vez cada seis meses y no todos los días? Porque los operadores utilizan bases de datos externas de información de enrutamiento para verificar lo que reciben de los vecinos BGP. Existen muchas bases de datos de este tipo, algunas de ellas están administradas por registradores (RIPE, APNIC, ARIN, AFRINIC), otras son actores independientes (la más famosa es RADB) y también hay un conjunto completo de registradores propiedad de grandes empresas (Level3 , NTT, etc.). Es gracias a estas bases de datos que el enrutamiento entre dominios mantiene la relativa estabilidad de su funcionamiento.
Sin embargo, hay matices. La información de ruta se verifica en función de los objetos ROUTE-OBJECTS y AS-SET. Y si la primera implica autorización para parte de la IRRDB, entonces para la segunda clase no hay autorización como clase. Es decir, cualquiera puede agregar a cualquier persona a sus conjuntos y así evitar los filtros de los proveedores anteriores. Además, la unicidad de la denominación AS-SET entre diferentes bases TIR no está garantizada, lo que puede tener efectos sorprendentes con una pérdida repentina de conectividad para el operador de telecomunicaciones, que, por su parte, no cambió nada.
Un desafío adicional es el patrón de uso de AS-SET. Hay dos puntos aquí:
- Cuando un operador consigue un nuevo cliente, lo agrega a su AS-SET, pero casi nunca lo elimina;
- Los filtros en sí se configuran solo en las interfaces con los clientes.
Como resultado, el formato moderno de los filtros BGP consiste en una degradación gradual de los filtros en las interfaces con los clientes y una confianza a priori en lo que proviene de los socios peering y de los proveedores de tránsito IP.
¿En qué consiste la sustitución de filtros de prefijo basados en AS-SET? Lo más interesante es que a corto plazo nada. Pero están surgiendo mecanismos adicionales que complementan el trabajo de los filtros basados en IRRDB y, en primer lugar, este es, por supuesto, RPKI.
RPKI
De manera simplificada, la arquitectura RPKI puede considerarse como una base de datos distribuida cuyos registros pueden verificarse criptográficamente. En el caso de ROA (Autorización de objeto de ruta), el firmante es el propietario del espacio de direcciones y el registro en sí es un triple (prefijo, asn, longitud máxima). Esencialmente, esta entrada postula lo siguiente: el propietario del espacio de direcciones $prefix ha autorizado al número AS $asn a anunciar prefijos con una longitud no mayor que $max_length. Y los enrutadores, que utilizan el caché RPKI, pueden verificar el cumplimiento del par. prefijo - primer orador en camino.
Figura 3. Arquitectura RPKI
Los objetos ROA se han estandarizado desde hace bastante tiempo, pero hasta hace poco sólo permanecían en papel en la revista IETF. En mi opinión, la razón de esto suena aterradora: un mal marketing. Una vez completada la estandarización, el incentivo fue que ROA protegía contra el secuestro de BGP, lo cual no era cierto. Los atacantes pueden eludir fácilmente los filtros basados en ROA insertando el número de AC correcto al comienzo de la ruta. Y tan pronto como nos dimos cuenta, el siguiente paso lógico fue abandonar el uso de ROA. Y realmente, ¿para qué necesitamos tecnología si no funciona?
¿Por qué es hora de cambiar de opinión? Porque esta no es toda la verdad. ROA no protege contra la actividad de los piratas informáticos en BGP, pero protege contra secuestros accidentales de tráfico, por ejemplo, por fugas estáticas en BGP, que son cada vez más comunes. Además, a diferencia de los filtros basados en TIR, el ROV se puede utilizar no sólo en las interfaces con los clientes, sino también en las interfaces con pares y proveedores ascendentes. Es decir, junto con la introducción de RPKI, la confianza a priori está desapareciendo gradualmente de BGP.
Ahora los actores clave están implementando gradualmente la verificación de rutas basada en ROA: el IX más grande de Europa ya está descartando rutas incorrectas; entre los operadores de nivel 1, cabe destacar a AT&T, que ha habilitado filtros en las interfaces con sus socios peering. Los mayores proveedores de contenidos también se están acercando al proyecto. Y decenas de operadores de transporte de tamaño medio ya lo han implementado discretamente, sin decírselo a nadie. ¿Por qué todos estos operadores están implementando RPKI? La respuesta es simple: proteger su tráfico saliente de los errores de otras personas. Es por eso que Yandex es uno de los primeros en la Federación Rusa en incluir ROV en el borde de su red.
¿Qué pasará después?
Ahora hemos habilitado la verificación de información de enrutamiento en las interfaces con puntos de intercambio de tráfico y emparejamientos privados. En un futuro próximo, la verificación también se habilitará con los proveedores de tráfico ascendente.
¿Qué diferencia hace esto para ti? Si desea aumentar la seguridad del enrutamiento del tráfico entre su red y Yandex, le recomendamos:
- Firma tu espacio de direcciones - es sencillo, tarda entre 5 y 10 minutos en promedio. Esto protegerá nuestra conectividad en caso de que alguien, sin saberlo, robe su espacio de direcciones (y esto definitivamente sucederá tarde o temprano);
- Instale uno de los cachés RPKI de código abierto (, ) y habilite la verificación de rutas en el borde de la red; esto llevará más tiempo, pero nuevamente, no causará ninguna dificultad técnica.
Yandex también apoya el desarrollo de un sistema de filtrado basado en el nuevo objeto RPKI: (Autorización del Proveedor del Sistema Autónomo). Los filtros basados en objetos ASPA y ROA no sólo pueden reemplazar los AS-SET "con fugas", sino que también solucionan los problemas de los ataques MiTM utilizando BGP.
Hablaré en detalle sobre ASPA dentro de un mes en la conferencia Next Hop. Allí también hablarán colegas de Netflix, Facebook, Dropbox, Juniper, Mellanox y Yandex. Si está interesado en la pila de red y su desarrollo en el futuro, venga .
Fuente: habr.com