BGP est la colle d'Internet. Pour le protocole, qui a été dessiné sur deux serviettes en 1989, il est à la fois surprenant et terrible qu'il gère presque toutes les interactions entre les FAI, étant un élément fondamental d'Internet.

BGP a une mauvaise réputation principalement en raison de la nature confiante des liens entre pairs par défaut et de la tâche difficile de vérifier la légitimité des routes. C'est pourquoi partout nous entendons parler de piratages BGP de divers degrés de gravité: du changement du routage de tous les YouTube à AWS Route 53 .

Mais pour comprendre la nature de ces hacks, vous devez comprendre la topologie d'Internet. Commençons par un routeur isolé:



Un seul routeur est peu utile s'il ne peut rien acheminer. Par conséquent, nous allons lui connecter un autre routeur au niveau physique (cela peut être n'importe quoi: du cuivre Ethernet et de la fibre optique sous-marine aux liaisons Wi-Fi 802.11).

Ensuite, deux routeurs connectés (dans notre cas rouge et bleu) doivent comprendre qu'ils peuvent acheminer le trafic l'un pour l'autre. Après tout, le point des routeurs est d'acheminer le trafic d'une destination à une autre.

Comme mentionné ci-dessus, une façon courante de le faire entre les FAI est d'installer BGP des deux côtés et de les laisser «s'annoncer» qu'ils peuvent acheminer le trafic:



Mais ce n'est pas très utile s'ils parlent uniquement entre eux, du coup les routeurs rouge et bleu ne sont pas directement connectés? Plus nous connectons de routeurs, plus la topologie de routage que nous formons est complexe. Cela est possible car chaque homologue BGP partage des tables de routage avec les autres homologues auxquels il est connecté:



La façon dont les routeurs échangent des informations entre eux dépend de la politique de configuration, et cela dépend généralement des conditions réelles pour les nœuds voisins. Il existe différents paramètres pour les clients, les accords d'échange de trafic et les fournisseurs supérieurs.

Pour cette raison, les routeurs nécessitent un ensemble d'instructions programmées pour filtrer ce qu'ils ne veulent pas donner ou prendre d'autres nœuds. Mais de temps en temps, les attaquants ont accès à un routeur qui est connecté à un autre routeur qui n'a pas de tels filtres. Corriger cela au niveau du logiciel est incroyablement difficile , car cela nécessite des changements dans les routeurs de chaque fournisseur. Les tentatives précédentes ne sont pas répandues .

BGP a un moyen de coder les informations en utilisant un itinéraire appelé communauté. Elle est définie dans la RFC1997 (malheureusement, écrite en 1996, ratée un peu). La communauté peut être attachée à une déclaration de route et elle se compose d'un nombre de 32 bits. En pratique, cette valeur est divisée en deux nombres de 16 bits (un pour l'ASN et un pour le signal associé à / pour cet ASN):



Ils sont utilisés pour transmettre des informations supplémentaires sur l'itinéraire, par exemple, où le fournisseur a emprunté cet itinéraire:



Ceci est utile en termes de filtrage. Par exemple, si vous avez de nombreux fournisseurs et que vous essayez de ne pas laisser sortir le trafic à l'extérieur du pays, vous pouvez utiliser la communauté appropriée pour diriger le trafic le long de ces itinéraires.

Ça m'a fait réfléchir. Que puis-je signaler d'autre à la communauté? Et jusqu'où pouvez-vous aller?

Après quelques tests, il s'est avéré que chaque réseau de niveau 1 efface la communauté, à l'exception de l' ancien niveau 3 , qui permet le transfert de la communauté du routeur source au client. Cela signifie également qu'un routeur peut envoyer des informations à d'autres, même sans connexion directe.

Bataille navale

Connaissant l'existence d'un canal de communication indirect via BGP, je voulais en quelque sorte l'utiliser pour établir des communications non traditionnelles. J'ai choisi «bataille navale» comme médium, car ce jeu nécessite la transmission d'un minimum d'informations (coordonnées X et Y, ainsi que des informations sur le dernier coup: touché ou manqué).

Deux jeux sur BGP deux communautés ont été créés.



L'ensemble du jeu tient dans deux nombres de 16 bits, permettant un jeu fiable à travers deux communautés.

Le combat naval étant un jeu à deux, j'ai invité AS203729 à jouer. Il est connecté à BGP à New York et mon installation fonctionne à Londres.

Lors de la planification du jeu, nous avons supposé qu'en raison de la fréquence de mise à jour des itinéraires, nous pouvions amortir le trafic BGP . Étant donné que nous sommes tous deux assis sur un trafic de production réel, nous avons convenu de définir un temporisateur de 30 secondes pour chaque mouvement, car l'amortissement entraînera des pannes sur les serveurs de production.

Le reste du trafic passait également par les routeurs du jeu, j'ai donc dû garder le démon de routage en ligne et il était impossible d'utiliser le démon BGP spécial. Pour contourner cette limitation, le binaire du jeu a généré et rechargé la configuration BIRD à l'aide du socket de contrôle du démon pour interroger les changements de route.

Avec ces paramètres, le 16 mai 2018, AS206924 et AS203729 ont probablement joué le premier jeu de société de l'histoire qui a été mené uniquement sur BGP.



Le jeu s'est bien déroulé, à l'exception d'une pause de 45 minutes en raison de l'amortissement ci-dessus. Cela s'est produit de mon côté et a fait que le niveau 3 applique l'itinéraire le moins optimal pour mon trafic pendant 45 minutes. Pour éviter une récurrence de la situation, nous avons décidé de passer à une période de 90 secondes entre les mouvements.

Malgré cela, le dernier coup porté à la flotte de mon ami AS203729 a été infligé au coup 68. Ce qui fait de moi le premier gagnant d'un jeu de société réalisé à l'aide d'un protocole de routage Internet public.

C'était logique? Probablement pas. C'était amusant? Mon Dieu, oui.

Le code source a été publié des deux côtés, bien que je ne propose pas de répéter cette expérience.

Jusqu'à la prochaine fois!