Olá, meu nome é Alexander Azimov. Na Yandex, estou desenvolvendo vários sistemas de monitoramento, bem como arquitetura de rede de transporte. Mas hoje vamos falar sobre o BGP.
Há uma semana, a Yandex incluía ROV (Validação de Origem de Rota) nos cruzamentos com todos os parceiros, assim como pontos de troca de tráfego. Sobre por que isso foi feito e como isso afetará a interação com as operadoras de telecomunicações, leia abaixo.
BGP e o que há de errado com isso
Você provavelmente sabe que o BGP foi concebido como um protocolo de roteamento entre domínios. No entanto, durante a jornada, o número de casos de usuários conseguiu crescer: hoje, o BGP, graças a inúmeras extensões, se transformou em um barramento de mensagens, cobrindo tarefas da VPN da operadora à agora na moda SD-WAN, e chegou a ser usado como transporte para o controlador tipo SDN, que transforma vetor de distância BGP em algo semelhante ao protocolo sate links.
Por que o BGP recebeu (e continua recebendo) tantos usos? Há dois motivos principais:
- O BGP é o único protocolo que funciona entre sistemas autônomos (SA);
- O BGP suporta atributos no formato TLV (tipo-comprimento-valor). Sim, o protocolo não está sozinho nisso, mas como não há nada para substituí-lo nas articulações entre as operadoras de telecomunicações, é sempre mais lucrativo anexar mais um elemento funcional a ele do que oferecer suporte a um protocolo de roteamento adicional.
O que há de errado com ele? Em resumo, o protocolo não possui mecanismos internos para verificar a correção das informações recebidas. Ou seja, o BGP é um protocolo de confiança a priori: se você quer dizer ao mundo que agora possui uma rede de Rostelecom, MTS ou Yandex, por favor!
Filtro IRRDB - O melhor dos piores
Surge a pergunta - por que a Internet ainda está trabalhando em tal situação? Sim, funciona na maioria das vezes, mas explode periodicamente, tornando inacessíveis segmentos nacionais inteiros. Apesar do fato de que a atividade de hackers no BGP também está crescendo, a maioria das anomalias ainda ocorre devido a erros. Um exemplo deste ano é o
erro de uma pequena operadora na Bielorrússia, que por meia hora tornou uma parte significativa da Internet inacessível para os usuários do MegaFon. Outro exemplo - o
otimizador enfurecido do BGP quebrou uma das maiores redes de CDN do mundo.
Fig. 2. Interceptação de tráfego Cloudflare
Mas, ainda assim, por que essas anomalias ocorrem a cada seis meses, e não todos os dias? Porque as operadoras de telecomunicações usam bancos de dados externos de informações de roteamento para verificar o que seus vizinhos obtêm do BGP. Existem muitos desses bancos de dados, alguns deles são gerenciados por registradores (RIPE, APNIC, ARIN, AFRINIC), outros são players independentes (os mais famosos - RADB), e também existe um conjunto inteiro de registradores de propriedade de grandes empresas (Level3, NTT etc.). Graças a esses bancos de dados, o roteamento entre domínios mantém a relativa estabilidade de seu trabalho.
No entanto, existem nuances. As informações da rota são verificadas com base nos objetos ROUTE-OBJECTS e AS-SET. E se o primeiro implica autorização na parte do IRRDB, a autorização está ausente como uma classe para a segunda classe. Ou seja, qualquer pessoa pode adicionar alguém a seus conjuntos e, assim, ignorar os filtros de fornecedores superiores. Além disso, a exclusividade da nomeação AS-SET entre diferentes bases de IRR não é garantida, o que pode levar a efeitos surpreendentes com uma súbita perda de conectividade no operador de telecomunicações, que por sua vez não mudou nada.
Um problema adicional é o modelo de uso AS-SET. Existem dois pontos:
- Quando um operador tem um novo cliente, ele o adiciona ao seu AS-SET, mas quase nunca o remove;
- Os próprios filtros são configurados apenas em junções com os clientes.
Como resultado, o formato moderno dos filtros BGP está gradualmente degradando os filtros nas interfaces com os clientes e a priori confia no que vem dos parceiros ponto a ponto e provedores de trânsito IP.
O que está substituindo os filtros de prefixo com base no AS-SET? O mais interessante é que, a curto prazo - nada. Mas existem mecanismos adicionais que complementam a operação de filtros baseados no IRRDB e, antes de tudo, é claro, o RPKI.
RPKI
Simplificado, você pode imaginar a arquitetura RPKI como um banco de dados distribuído cujos registros podem ser criptograficamente verificados. No caso de ROA (Autorização de Objeto de Rota), o proprietário do espaço de endereço é o assinante e o próprio registro é um triplo (prefixo, asn, max_length). De fato, essa entrada postula o seguinte - o proprietário do prefixo $ do espaço de endereço permitiu que o AS com o número $ asn anunciasse prefixos com um comprimento não superior a $ max_length. E os roteadores, usando o cache RPKI, podem verificar a conformidade com um par de
alto-falantes com prefixo em movimento .
Figura 3. Arquitetura RPKI
Os objetos ROA são padronizados há muito tempo, mas até recentemente, de fato, permaneciam apenas no papel da revista IETF. Na minha opinião, o motivo disso parece assustador - mau marketing. Após a padronização, foi argumentado como um incentivo que os ROAs protegem contra o seqüestro de BGP - e isso não era verdade. Os invasores podem ignorar facilmente os filtros ROA inserindo o número correto do alto-falante no início do caminho. E assim que essa conscientização surgiu, o próximo passo lógico foi a rejeição do uso do ROA. E realmente, por que precisamos de tecnologia se ela não funciona?
Por que é hora de mudar de idéia? Porque essa não é toda a verdade. O ROA não protege contra atividades de hackers no BGP, mas
protege contra o seqüestro acidental de tráfego , por exemplo, contra vazamentos estáticos no BGP, o que está se tornando mais comum. Além disso, diferentemente dos filtros baseados na TIR, o ROV pode ser usado não apenas nas interfaces com os clientes, mas também nas interfaces com colegas e fornecedores superiores. Ou seja, com a introdução do RPKI, o BGP deixa gradualmente confiança a priori.
Agora, a verificação de rotas baseada em ROA está sendo introduzida gradualmente pelos principais atores: os maiores IXs europeus já descartam rotas incorretas; entre as operadoras de Nível 1, vale destacar a AT&T, que ativou filtros nos cruzamentos com seus parceiros parceiros. Além disso, os maiores provedores de conteúdo são adequados para o shell. E dezenas de operadores de transporte de porte médio já o implementaram silenciosamente, sem contar a ninguém. Por que todos esses operadores estão implementando o RPKI? A resposta é simples: para proteger o tráfego de saída dos erros de outras pessoas. É por isso que a Yandex é uma das primeiras na Federação Russa a incluir o ROV na fronteira de sua rede.
O que acontecerá depois?
Agora incluímos a verificação de informações de roteamento nos cruzamentos com pontos de troca de tráfego e ponto a ponto privados. Em um futuro próximo, a verificação também será incluída com os provedores de tráfego upstream.
O que isso muda para você? Se você deseja aumentar a segurança do roteamento de tráfego entre sua rede e o Yandex, recomendamos:
- É fácil assinar seu espaço de endereço no portal RIPE , em média, leva de 5 a 10 minutos. Isso protegerá nossa conectividade no caso de alguém involuntariamente invadir seu espaço de endereço (e isso acontecerá mais cedo ou mais tarde);
- Colocar um dos caches RPKI de código aberto ( validador maduro , rotinador ) e ativar a verificação de rota no limite da rede levará mais tempo, mas não causará dificuldades técnicas novamente.
O Yandex também suporta o desenvolvimento de um sistema de filtragem baseado no novo objeto RPKI -
ASPA (Autonomous System Provider Authorization). Os filtros baseados em objetos ASPA e ROA podem não apenas substituir AS-SETs "com vazamento", mas também fechar ataques MiTM usando BGP.
Falarei em detalhes sobre a ASPA em um mês na conferência Next Hop. Também haverá colegas da Netflix, Facebook, Dropbox, Juniper, Mellanox e Yandex. Se você estiver interessado na pilha de rede e seu desenvolvimento no futuro, venha, o
registro está aberto .