Ola, chámome Alexander Azimov. En Yandex, desenvolvo varios sistemas de monitorización, así como arquitectura de rede de transporte. Pero hoxe falaremos do protocolo BGP.
Hai unha semana, Yandex habilitou a ROV (Validación da orixe da ruta) nas interfaces con todos os socios de interconexión, así como nos puntos de intercambio de tráfico. Lea a continuación sobre por que se fixo isto e como afectará a interacción cos operadores de telecomunicacións.
BGP e o que hai de malo
Probablemente saibas que BGP foi deseñado como un protocolo de enrutamento entre dominios. Non obstante, ao longo do camiño, o número de casos de uso logrou crecer: hoxe en día, BGP, grazas a numerosas extensións, converteuse nun bus de mensaxes, que abarca tarefas desde a VPN do operador ata a agora de moda SD-WAN, e mesmo atopou aplicación como un transporte para un controlador tipo SDN, convertendo o vector de distancia BGP en algo similar ao protocolo links sat.
Fig. 1.
Por que BGP recibiu (e segue recibindo) tantos usos? Hai dúas razóns principais:
- BGP é o único protocolo que funciona entre sistemas autónomos (AS);
- BGP admite atributos en formato TLV (tipo-longitud-valor). Si, o protocolo non está só nisto, pero como non hai nada que o substitúa nos cruces entre operadores de telecomunicacións, sempre resulta máis rendible engadirlle outro elemento funcional que soportar un protocolo de enrutamento adicional.
Que lle pasa? En definitiva, o protocolo non conta con mecanismos incorporados para comprobar a corrección da información recibida. É dicir, BGP é un protocolo de confianza a priori: se queres dicirlle ao mundo que agora tes a rede de Rostelecom, MTS ou Yandex, por favor.
Filtro baseado en IRRDB: o mellor do peor
Xorde a pregunta: por que Internet aínda funciona en tal situación? Si, funciona a maior parte do tempo, pero ao mesmo tempo explota periódicamente, facendo inaccesibles segmentos nacionais enteiros. Aínda que a actividade dos piratas informáticos en BGP tamén está en aumento, a maioría das anomalías aínda son causadas por erros. O exemplo deste ano é en Bielorrusia, que fixo que unha parte importante de Internet fose inaccesible para os usuarios de MegaFon durante media hora. Outro exemplo - rompeu unha das redes CDN máis grandes do mundo.
Arroz. 2. Interceptación de tráfico Cloudflare
Pero aínda así, por que ocorren tales anomalías unha vez cada seis meses, e non todos os días? Porque os operadores usan bases de datos externas de información de enrutamento para verificar o que reciben dos veciños de BGP. Hai moitas bases de datos deste tipo, algunhas delas xestionadas por rexistradores (RIPE, APNIC, ARIN, AFRINIC), algunhas son xogadores independentes (o máis famoso é RADB) e tamén hai todo un conxunto de rexistradores propiedade de grandes empresas (Level3). , NTT, etc.). É grazas a estas bases de datos que o enrutamento entre dominios mantén a relativa estabilidade do seu funcionamento.
Non obstante, hai matices. A información de enrutamento compróbase en función dos obxectos ROUTE-OBJECTS e AS-SET. E se o primeiro implica autorización para parte do IRRDB, entón para a segunda clase non hai autorización como clase. É dicir, calquera pode engadir a calquera aos seus conxuntos e, así, evitar os filtros dos provedores anteriores. Ademais, non está garantida a singularidade da denominación AS-SET entre diferentes bases IRR, o que pode levar a efectos sorprendentes cunha súbita perda de conectividade para o operador de telecomunicacións, que, pola súa banda, non cambiou nada.
Un reto adicional é o patrón de uso de AS-SET. Aquí hai dous puntos:
- Cando un operador recibe un cliente novo, engádeo ao seu AS-SET, pero case nunca o elimina;
- Os propios filtros configúranse só nas interfaces cos clientes.
Como resultado, o formato moderno dos filtros BGP consiste na degradación gradual dos filtros nas interfaces cos clientes e a confianza a priori no que provén dos socios de peering e dos provedores de tránsito IP.
Que é substituír os filtros de prefixos baseados en AS-SET? O máis interesante é que a curto prazo - nada. Pero están xurdindo mecanismos adicionais que complementan o traballo dos filtros baseados en IRRDB e, en primeiro lugar, isto é, por suposto, RPKI.
RPKI
De forma simplificada, a arquitectura RPKI pódese pensar como unha base de datos distribuída cuxos rexistros poden ser verificados criptográficamente. No caso de ROA (Route Object Authorization), o asinante é o propietario do espazo de enderezos e o propio rexistro é un triplo (prefixo, asn, max_length). Esencialmente, esta entrada postula o seguinte: o propietario do espazo de enderezo $prefixo autorizou o número AS $asn para anunciar prefixos cunha lonxitude non superior a $max_length. E os enrutadores, que utilizan a caché RPKI, poden comprobar o cumprimento do par prefixo - primeiro falante no camiño.
Figura 3. Arquitectura RPKI
Os obxectos ROA estiveron estandarizados durante bastante tempo, pero ata hai pouco en realidade permanecían só en papel na revista IETF. Na miña opinión, o motivo disto parece asustado: un mal marketing. Despois de completar a estandarización, o incentivo foi que ROA protexese contra o secuestro de BGP, o que non era certo. Os atacantes poden evitar os filtros baseados en ROA inserindo o número de CA correcto ao comezo da ruta. E tan pronto como chegou esta constatación, o seguinte paso lóxico foi abandonar o uso de ROA. E realmente, por que necesitamos tecnoloxía se non funciona?
Por que é hora de cambiar de opinión? Porque esta non é toda a verdade. O ROA non protexe contra a actividade dos piratas informáticos en BGP, pero protexe contra secuestros accidentais de tráfico, por exemplo de fugas estáticas en BGP, que é cada vez máis común. Ademais, a diferenza dos filtros baseados en IRR, o ROV pódese usar non só nas interfaces cos clientes, senón tamén nas interfaces con pares e provedores upstream. É dicir, xunto coa introdución do RPKI, a confianza a priori está a desaparecer paulatinamente do BGP.
Agora, a comprobación de rutas baseada no ROA está sendo implementada aos poucos por parte dos principais actores: o IX europeo máis grande xa está a descartar rutas incorrectas; entre os operadores de nivel 1, cabe destacar AT&T, que habilitou filtros nas interfaces cos seus socios de peering. Os maiores provedores de contidos tamén se achegan ao proxecto. E ducias de medianos operadores de tránsito xa o implementaron en silencio, sen dicirllo a ninguén. Por que todos estes operadores están a implementar RPKI? A resposta é sinxela: protexer o teu tráfico saínte dos erros doutras persoas. É por iso que Yandex é un dos primeiros da Federación Rusa en incluír o ROV ao bordo da súa rede.
Que pasará despois?
Agora activamos a comprobación da información de enrutamento nas interfaces con puntos de intercambio de tráfico e peerings privados. Nun futuro próximo, a verificación tamén se activará cos provedores de tráfico ascendente.
Que diferenza fai isto para ti? Se queres aumentar a seguridade do enrutamento do tráfico entre a túa rede e Yandex, recomendámosche:
- Asina o teu espazo de enderezo - é sinxelo, leva 5-10 minutos de media. Isto protexerá a nosa conectividade no caso de que alguén roube o teu espazo de enderezo sen querer (e isto ocorrerá máis tarde ou máis cedo);
- Instale unha das cachés RPKI de código aberto (, ) e habilite a comprobación de rutas na fronteira da rede; isto levará máis tempo, pero, de novo, non causará dificultades técnicas.
Yandex tamén admite o desenvolvemento dun sistema de filtrado baseado no novo obxecto RPKI: (Autorización de provedor do sistema autónomo). Os filtros baseados en obxectos ASPA e ROA non só poden substituír os AS-SET con fugas, senón que tamén poden pechar os problemas dos ataques MiTM mediante BGP.
Falarei en detalle sobre ASPA nun mes na conferencia Next Hop. Tamén falarán alí compañeiros de Netflix, Facebook, Dropbox, Juniper, Mellanox e Yandex. Se estás interesado na pila de rede e no seu desenvolvemento no futuro, ven .
Fonte: www.habr.com