Olá, meu nome é Alexander Azimov. Na Yandex desenvolvo diversos sistemas de monitoramento, bem como arquitetura de redes de transporte. Mas hoje falaremos sobre o protocolo BGP.
Há uma semana, Yandex habilitou ROV (Route Origin Validation) nas interfaces com todos os parceiros peering, bem como pontos de troca de tráfego. Leia abaixo por que isso foi feito e como isso afetará a interação com as operadoras de telecomunicações.
BGP e o que há de errado com ele
Você provavelmente sabe que o BGP foi projetado como um protocolo de roteamento entre domínios. No entanto, ao longo do caminho, o número de casos de uso conseguiu crescer: hoje, o BGP, graças a inúmeras extensões, se transformou em um barramento de mensagens, cobrindo tarefas desde a operadora VPN até o agora na moda SD-WAN, e até encontrou aplicação como um transporte para um controlador do tipo SDN, transformando o vetor de distância BGP em algo semelhante ao protocolo links sat.
Fig. 1.
Por que o BGP recebeu (e continua recebendo) tantos usos? Há duas razões principais:
- BGP é o único protocolo que funciona entre sistemas autônomos (AS);
- O BGP oferece suporte a atributos no formato TLV (tipo-comprimento-valor). Sim, o protocolo não está sozinho nisso, mas como não há nada que o substitua nas junções entre operadoras de telecomunicações, acaba sempre sendo mais lucrativo anexar-lhe outro elemento funcional do que suportar um protocolo de roteamento adicional.
O que há de errado com ele? Em suma, o protocolo não possui mecanismos integrados para verificar a veracidade das informações recebidas. Ou seja, o BGP é um protocolo de confiança a priori: se você quer dizer ao mundo que agora possui a rede Rostelecom, MTS ou Yandex, por favor!
Filtro baseado em IRRDB – o melhor dos piores
Surge a pergunta: por que a Internet ainda funciona em tal situação? Sim, funciona na maior parte do tempo, mas ao mesmo tempo explode periodicamente, tornando inacessíveis segmentos nacionais inteiros. Embora a atividade de hackers no BGP também esteja aumentando, a maioria das anomalias ainda é causada por bugs. O exemplo deste ano é na Bielo-Rússia, o que tornou uma parte significativa da Internet inacessível aos usuários do MegaFon por meia hora. Outro exemplo - quebrou uma das maiores redes CDN do mundo.
Arroz. 2. Interceptação de tráfego Cloudflare
Mas ainda assim, por que tais anomalias ocorrem uma vez a cada seis meses e não todos os dias? Porque as operadoras usam bancos de dados externos de informações de roteamento para verificar o que recebem dos vizinhos do BGP. Existem muitos desses bancos de dados, alguns deles são gerenciados por registradores (RIPE, APNIC, ARIN, AFRINIC), alguns são players independentes (o mais famoso é o RADB), e há também todo um conjunto de registradores pertencentes a grandes empresas (Level3 , NTT, etc.). É graças a essas bases de dados que o roteamento entre domínios mantém a relativa estabilidade de seu funcionamento.
No entanto, existem nuances. As informações de rota são verificadas com base nos objetos ROUTE-OBJECTS e AS-SET. E se a primeira implica autorização para parte do IRRDB, então para a segunda classe não há autorização como classe. Ou seja, qualquer pessoa pode adicionar qualquer pessoa aos seus conjuntos e, assim, contornar os filtros dos provedores upstream. Além disso, não é garantida a unicidade da nomenclatura AS-SET entre diferentes bases de TIR, o que pode levar a efeitos surpreendentes com uma perda repentina de conectividade para a operadora de telecomunicações, que, por sua vez, não mudou nada.
Um desafio adicional é o padrão de uso do AS-SET. Existem dois pontos aqui:
- Quando uma operadora consegue um novo cliente, ela o adiciona ao seu AS-SET, mas quase nunca o remove;
- Os próprios filtros são configurados apenas nas interfaces com os clientes.
Como resultado, o formato moderno dos filtros BGP consiste na degradação gradual dos filtros nas interfaces com os clientes e na confiança a priori no que vem dos parceiros de peering e dos provedores de trânsito IP.
O que está substituindo os filtros de prefixo baseados em AS-SET? O mais interessante é que no curto prazo não há nada. Mas estão surgindo mecanismos adicionais que complementam o trabalho dos filtros baseados em IRRDB e, em primeiro lugar, trata-se, obviamente, do RPKI.
RPKI
De forma simplificada, a arquitetura RPKI pode ser pensada como um banco de dados distribuído cujos registros podem ser verificados criptograficamente. No caso de ROA (Route Object Authorization), o signatário é o proprietário do espaço de endereço e o registro em si é um triplo (prefixo, asn, max_length). Essencialmente, esta entrada postula o seguinte: o proprietário do espaço de endereço $prefix autorizou o número AS $asn a anunciar prefixos com comprimento não superior a $max_length. E os roteadores, usando o cache RPKI, são capazes de verificar a conformidade do par prefixo - primeiro orador a caminho.
Figura 3. Arquitetura RPKI
Os objetos ROA foram padronizados há muito tempo, mas até recentemente eles permaneciam apenas no papel na revista IETF. Na minha opinião, a razão para isso parece assustadora – marketing ruim. Depois que a padronização foi concluída, o incentivo foi que o ROA protegesse contra o sequestro de BGP – o que não era verdade. Os invasores podem facilmente ignorar os filtros baseados em ROA inserindo o número AC correto no início do caminho. E assim que essa constatação veio, o próximo passo lógico foi abandonar o uso do ROA. E realmente, por que precisamos de tecnologia se ela não funciona?
Por que é hora de mudar de ideia? Porque esta não é toda a verdade. O ROA não protege contra atividades de hackers no BGP, mas protege contra sequestros acidentais de tráfego, por exemplo, devido a vazamentos estáticos no BGP, que estão se tornando mais comuns. Além disso, diferentemente dos filtros baseados em IRR, o ROV pode ser usado não apenas nas interfaces com clientes, mas também nas interfaces com pares e provedores upstream. Ou seja, junto com a introdução do RPKI, a confiança a priori está desaparecendo gradativamente do BGP.
Agora a verificação de rotas baseada em ROA está sendo gradualmente implementada pelos principais players: o maior IX europeu já está descartando rotas incorretas; entre os operadores Tier-1, vale destacar a AT&T, que habilitou filtros nas interfaces com seus parceiros peering. Os maiores provedores de conteúdo também estão abordando o projeto. E dezenas de operadores de trânsito de médio porte já o implementaram discretamente, sem contar a ninguém sobre isso. Por que todas essas operadoras estão implementando o RPKI? A resposta é simples: proteger o tráfego de saída dos erros de outras pessoas. É por isso que Yandex é um dos primeiros na Federação Russa a incluir ROV na borda de sua rede.
O que vai acontecer a seguir?
Agora habilitamos a verificação de informações de roteamento nas interfaces com pontos de troca de tráfego e peerings privados. Num futuro próximo, a verificação também será habilitada com provedores de tráfego upstream.
Que diferença isso faz para você? Se você deseja aumentar a segurança do roteamento de tráfego entre sua rede e Yandex, recomendamos:
- Assine seu espaço de endereço - é simples, leva em média de 5 a 10 minutos. Isso protegerá nossa conectividade no caso de alguém roubar involuntariamente seu espaço de endereço (e isso certamente acontecerá mais cedo ou mais tarde);
- Instale um dos caches RPKI de código aberto (, ) e ativar a verificação de rota na fronteira da rede - isso levará mais tempo, mas, novamente, não causará dificuldades técnicas.
Yandex também apoia o desenvolvimento de um sistema de filtragem baseado no novo objeto RPKI - (Autorização de Provedor de Sistema Autônomo). Filtros baseados em objetos ASPA e ROA podem não apenas substituir AS-SETs “vazados”, mas também resolver os problemas de ataques MiTM usando BGP.
Falarei detalhadamente sobre a ASPA daqui a um mês na conferência Next Hop. Colegas da Netflix, Facebook, Dropbox, Juniper, Mellanox e Yandex também falarão lá. Se você está interessado na pilha de redes e em seu desenvolvimento no futuro, venha .
Fonte: habr.com