Hola, me llamo Alexander Azimov. En Yandex, estoy desarrollando varios sistemas de monitoreo, así como arquitectura de red de transporte. Pero hoy hablaremos de BGP.
Hace una semana, Yandex incluyó ROV (Validación de origen de ruta) en los cruces con todos los socios pares, así como con puntos de intercambio de tráfico. Sobre por qué se hizo esto y cómo afectará la interacción con los operadores de telecomunicaciones, lea a continuación.
BGP y qué tiene de malo
Probablemente sepa que BGP fue concebido como un protocolo de enrutamiento entre dominios. Sin embargo, durante el viaje, el número de casos de usuarios logró crecer: hoy BGP, gracias a numerosas extensiones, se ha convertido en un bus de mensajes, cubriendo tareas desde la VPN del operador hasta la SD-WAN de moda, e incluso encontró uso como transporte para el controlador tipo SDN, que se convierte vector de distancia BGP en algo similar al protocolo de estado de enlaces.
¿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 el formato TLV (tipo-longitud-valor). Sí, el protocolo no está solo en esto, pero dado que no hay nada que lo reemplace en las uniones entre los operadores de telecomunicaciones, siempre es más rentable adjuntarle un elemento funcional más que admitir un protocolo de enrutamiento adicional.
¿Qué le pasa a él? En resumen, el protocolo carece de 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 una red de Rostelecom, MTS o Yandex, ¡por favor!
Filtro IRRDB: lo mejor de lo peor
Surge la pregunta: ¿por qué Internet sigue funcionando en una situación así? Sí, funciona la mayor parte del tiempo, pero explota periódicamente, haciendo que segmentos nacionales enteros sean inaccesibles. A pesar del hecho de que la actividad de piratería en BGP también está creciendo, la mayoría de las anomalías aún ocurren debido a errores. Un ejemplo de este año es el
error de un pequeño operador en Bielorrusia, que durante media hora hizo que una parte importante de Internet fuera inaccesible para los usuarios de MegaFon. Otro ejemplo: el
optimizador BGP enfurecido rompió una de las redes CDN más grandes del mundo.
Fig. 2. Intercepción de tráfico Cloudflare
Pero aún así, ¿por qué ocurren tales anomalías cada seis meses, y no todos los días? Porque los operadores de telecomunicaciones utilizan bases de datos de información de enrutamiento externas para verificar lo que obtienen sus vecinos de BGP. Hay muchas bases de datos de este tipo, algunas de ellas están gestionadas por registradores (RIPE, APNIC, ARIN, AFRINIC), algunas son jugadores independientes (el más famoso - RADB), y también hay un conjunto completo de registradores propiedad de grandes empresas (Level3, NTT, etc.). Gracias a estas bases de datos, el enrutamiento entre dominios mantiene la relativa estabilidad de su trabajo.
Sin embargo, hay matices. La información de ruta se verifica en función de los objetos ROUTE-OBJECTS y AS-SET. Y si el primero implica autorización en la parte IRRDB, entonces la autorización está ausente como una clase para la segunda clase. Es decir, cualquiera puede agregar a cualquiera a sus conjuntos y, por lo tanto, evitar los filtros de los proveedores superiores. Además, no se garantiza la singularidad de los nombres AS-SET entre diferentes bases IRR, lo que puede conducir a efectos sorprendentes con una pérdida repentina de conectividad en el operador de telecomunicaciones, que por su parte no cambió nada.
Un problema adicional es el modelo de uso AS-SET. Hay dos puntos:
- Cuando un operador tiene un nuevo cliente, lo agrega a su AS-SET, pero casi nunca lo elimina;
- Los filtros mismos se configuran solo en las uniones con los clientes.
Como resultado, el formato moderno de los filtros BGP está degradando gradualmente los filtros en las interfaces con los clientes y a priori la confianza en lo que proviene de los socios de igual a igual y los proveedores de tránsito IP.
¿Qué está reemplazando los filtros de prefijo basados en AS-SET? Lo más interesante es que a corto plazo, nada. Pero existen mecanismos adicionales que complementan la operación de los filtros basados en IRRDB y, en primer lugar, por supuesto, RPKI.
RPKI
Simplificado, puede imaginar la arquitectura RPKI como una base de datos distribuida cuyos registros pueden verificarse criptográficamente. En el caso de ROA (Route Object Authorization), el propietario del espacio de direcciones es el firmante, y el registro en sí es un triple (prefijo, asn, max_length). De hecho, esta entrada postula lo siguiente: el propietario del espacio de direcciones $ prefix permitió que el AS con el número $ asn anunciara prefijos con una longitud de no más de $ max_length. Y los enrutadores, que usan el caché RPKI, pueden verificar el cumplimiento de un par de
altavoces con prefijo primero sobre la marcha .
Figura 3. Arquitectura RPKI
Los objetos ROA se han estandarizado durante mucho tiempo, pero hasta hace poco, de hecho, solo permanecían en el papel de la revista IETF. En mi opinión, la razón de esto suena aterradora: un mal marketing. Después de que se completó la estandarización, se argumentó como un incentivo que los ROA protegen contra el secuestro de BGP, y eso no era cierto. Los atacantes pueden evitar fácilmente los filtros ROA insertando el número de altavoz correcto al comienzo de la ruta. Y tan pronto como llegó esta conciencia, el siguiente paso lógico fue el rechazo del uso de ROA. Y realmente, ¿por qué necesitamos tecnología si no funciona?
¿Por qué es hora de cambiar de opinión? Porque esta no es toda la verdad. El ROA no protege contra la actividad de pirateo en BGP, pero
protege contra el secuestro accidental del tráfico , por ejemplo, de fugas estáticas en BGP, que se está volviendo más común. Además, a diferencia de los filtros basados en IRR, el ROV puede usarse no solo en interfaces con clientes, sino también en interfaces con pares y proveedores superiores. Es decir, con la introducción de RPKI, BGP gradualmente deja una confianza a priori.
Ahora, los jugadores clave están introduciendo gradualmente la verificación de ruta basada en ROA: los IX europeos más grandes ya están descartando rutas incorrectas, entre los operadores de Nivel 1 vale la pena destacar AT&T, que activó los filtros en los cruces con sus socios pares. Además, los proveedores de contenido más grandes son adecuados para el shell. Y docenas de operadores de tránsito de tamaño mediano ya lo han implementado en silencio, sin decírselo a nadie. ¿Por qué todos estos operadores implementan 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 de Rusia en incluir el ROV en el límite de su red.
¿Qué pasará después?
Ahora hemos incluido la verificación de la información de enrutamiento en los cruces con puntos de intercambio de tráfico y de punto a punto privado. En un futuro próximo, la verificación también se incluirá con los proveedores de tráfico ascendente.
¿Qué cambia esto para ti? Si desea aumentar la seguridad del enrutamiento del tráfico entre su red y Yandex, le recomendamos:
- Firmar su espacio de direcciones en el portal RIPE es fácil, en promedio, demora entre 5 y 10 minutos. Esto protegerá nuestra conectividad en caso de que alguien secuestra involuntariamente su espacio de direcciones (y esto sucederá tarde o temprano);
- Poner uno de los cachés RPKI de código abierto ( validador maduro , enrutador ) y habilitar la verificación de ruta en el límite de la red llevará más tiempo, pero no causará dificultades técnicas, nuevamente.
Yandex también admite el desarrollo de un sistema de filtrado basado en el nuevo objeto RPKI:
ASPA (Autorización de proveedor de sistema autónomo). Los filtros basados en objetos ASPA y ROA no solo pueden reemplazar AS-SET "con fugas", sino que también pueden cerrar los ataques MiTM con BGP.
Hablaré en detalle sobre ASPA en un mes en la conferencia Next Hop. También habrá colegas de Netflix, Facebook, Dropbox, Juniper, Mellanox y Yandex. Si está interesado en la pila de red y su desarrollo en el futuro, venga, el
registro está abierto .