BGP é a cola da Internet. Para o protocolo, que foi desenhado em dois guardanapos em 1989, é simultaneamente surpreendente e terrível que ele lide com quase todas as interações entre os ISPs, sendo uma parte fundamental da Internet.

O BGP tem uma má reputação principalmente devido à natureza confiável dos links entre pares por padrão e à difícil tarefa de verificar a legitimidade das rotas. É por isso que em todos os lugares que ouvimos sobre hacks BGP de vários graus de gravidade: da alteração do roteamento de todo o YouTube para o AWS Route 53 .

Mas, para entender a natureza desses hacks, você precisa entender a topologia da Internet. Vamos começar com um roteador solitário:



Um único roteador é de pouca utilidade se não puder rotear nada. Portanto, conectaremos outro roteador a ele no nível físico (pode ser qualquer coisa: de Ethernet de cobre e fibra óptica subaquática a links Wi-Fi 802.11).

Então, dois roteadores conectados (no nosso caso, vermelho e azul) devem entender que podem rotear o tráfego um para o outro. Afinal, o objetivo dos roteadores é rotear o tráfego de um destino para outro.

Como mencionado acima, uma maneira comum de fazer isso entre os ISPs é instalar o BGP nos dois lados e deixá-los "anunciar" um ao outro que eles podem rotear o tráfego:



Mas não é muito útil se eles conversarem apenas um com o outro, de repente os roteadores vermelho e azul não estão diretamente conectados? Quanto mais roteadores nos conectarmos, mais complexa será a topologia de roteamento. Isso é possível porque cada par BGP compartilha tabelas de roteamento com os outros pares aos quais está conectado:



Como os roteadores trocam informações entre si depende da política de configuração, e isso geralmente depende das condições do mundo real para os nós vizinhos. Existem várias configurações para clientes, contratos de troca de tráfego e provedores superiores.

Por esse motivo, os roteadores exigem um conjunto de instruções programadas para filtrar o que eles não desejam dar ou receber de outros nós. Mas, de tempos em tempos, os invasores obtêm acesso a um roteador conectado a outro roteador que não possui esses filtros. Corrigir isso no nível do software é incrivelmente difícil , porque requer alterações nos roteadores de cada provedor. Tentativas anteriores não são generalizadas .

O BGP tem uma maneira de codificar informações usando uma rota chamada comunidade. É definido no RFC1997 (infelizmente, escrito em 1996, perdeu um pouco). A comunidade pode ser anexada a uma declaração de rota e consiste em um número de 32 bits. Na prática, esse valor é dividido em dois números de 16 bits (um para o ASN e outro para o sinal associado a / para este ASN):



Eles são usados ​​para transmitir informações adicionais sobre a rota, por exemplo, onde o provedor seguiu esta rota:



Isso é útil em termos de filtragem. Por exemplo, se você tiver muitos provedores e tentar não deixar tráfego fora do país, poderá usar a comunidade apropriada para direcionar o tráfego por essas rotas.

Isso me fez pensar. O que mais posso sinalizar através da comunidade? E até onde você pode ir?

Após alguns testes, verificou-se que cada rede de nível 1 apaga a comunidade, exceto o antigo nível 3 , que permite a transferência da comunidade do roteador de origem para o cliente. Isso também significa que um roteador pode enviar informações a outros, mesmo sem uma conexão direta.

Batalha no mar

Sabendo da existência de um canal de comunicação indireta via BGP, eu queria usar isso de alguma forma para estabelecer algumas comunicações não tradicionais. Eu escolhi a "batalha naval" como o meio, porque este jogo requer a transmissão de uma quantidade mínima de informações (coordenadas X e Y, bem como informações sobre o último tiro: acertado ou errado).

Dois jogos no BGP foram criadas duas comunidades.



O jogo inteiro se encaixa em dois números de 16 bits, permitindo um jogo confiável em duas comunidades.

Como o combate naval é um jogo para dois, convidei o AS203729 para jogar. Ele está conectado ao BGP em Nova York e minha instalação funciona em Londres.

Ao planejar o jogo, assumimos que, devido à frequência da atualização das rotas, poderíamos diminuir o tráfego de BGP . Como estamos sentados no tráfego real de produção, concordamos em definir um cronômetro de 30 segundos para cada movimentação, pois o amortecimento causará falhas nos servidores de produção.

Outro tráfego também passava pelos roteadores de jogos, então eu tive que manter o daemon de roteamento on-line e era impossível usar o daemon BGP especial. Para contornar essa limitação, o binário do jogo gerou e recarregou a configuração do BIRD usando o soquete de controle do daemon para pesquisar mudanças na rota.

Com essas configurações, em 16 de maio de 2018, o AS206924 e o AS203729 provavelmente jogaram o primeiro jogo de tabuleiro da história que foi realizado exclusivamente no BGP.



O jogo correu bem, com exceção de uma pausa de 45 minutos devido ao amortecimento acima. Isso aconteceu do meu lado e fez o Nível 3 aplicar a rota menos ideal para o meu tráfego por 45 minutos. Para evitar uma recorrência da situação, decidimos mudar para um período de 90 segundos entre as jogadas.

Apesar disso, o último golpe na frota do meu amigo AS203729 foi dado no movimento 68. O que me torna o primeiro vencedor de um jogo de tabuleiro realizado usando um protocolo de roteamento público na Internet.

Isso era lógico? Provavelmente não. Foi divertido? Puxa, sim.

O código fonte foi publicado nos dois lados, embora eu não proponha repetir esse experimento.

Até a próxima!