BGP is internet glue. For the protocol that was drawn on two napkins in 1989, it’s both amazing and terrible at the same time that it handles almost all the interactions between ISPs, being a fundamental part of the Internet.

BGP has a bad reputation, mainly because of the trustworthy nature of the links between peers by default and the difficult task of verifying the legitimacy of routes. That is why we hear about BGP hacks of varying severity everywhere: from changing the routing of all YouTube to AWS Route 53 .

But to understand the nature of these hacks, you should understand the topology of the Internet. Let's start with a single router:



One router is of little use if it cannot route anything. Therefore, we will connect another router on the physical layer to it (this can be anything: from copper Ethernet and underwater optical fiber to 802.11 Wi-Fi links).

Then, the two connected routers (in our case, red and blue) must understand that they can route traffic to each other. In the end, the meaning of routers is the direction of traffic from one destination to another.

As mentioned above, the generally accepted way to do this between ISPs is to set up BGP on both sides and allow them to “declare” to each other that they can route traffic:



But not very useful if they only talk to each other, suddenly the red and blue routers are not directly connected? The more routers we connect, the more complex routing topology we form. This is possible because each BGP node shares its routing tables with other nodes to which it is connected:



How routers communicate with each other depends on the configuration policy, and it usually depends on the real world conditions for the neighboring nodes. There are various settings for customers, traffic agreements and upstream providers.

Because of this, routers need a set of pre-programmed instructions to filter out what they don’t want to give or take from other nodes. But from time to time, attackers gain access to a router that is connected to another router that does not have such filters. It is incredibly difficult to fix this at the software level, because it requires changes from the routers of each provider. Previous attempts are not widespread .

BGP has a way to encode information using a route called community. It is defined in RFC1997 (unfortunately, written in 1996, a bit overshot). A community can be attached to a route advertisement and it consists of a 32-bit number. In practice, this value is divided into two 16-bit numbers (one for the ASN and one for the signal associated with / for this ASN):



They are used to transmit additional information about the route, for example, where the provider took this route:



This is useful in terms of filtering. For example, if you have many providers and you are trying not to let traffic out of the country, you can use the appropriate community to direct traffic along these routes.

It made me think. What else can you signal through the community? And how far can you go?

After some testing, it turned out that each Tier-1 network erases the community, except the former Level 3 , which allows the transfer of the community from the source router to the client. It also means that one router can send information to others without even having a direct connection.

Sea battle

Knowing about the presence of an indirect communication channel via BGP, I wanted to somehow use this to establish some kind of non-traditional communications. I chose “battleship” as the medium, since this game requires the transfer of a minimum amount of information (X and Y coordinates, as well as information on the last shot: hit or missed).

Two BGP games were created by two communities.



The whole game fits in two 16-bit numbers, allowing you to play reliably through two communities.

Since sea battle is a game for two, I invited to play AS203729 . He is connected to BGP in New York, and my installation is in London.

When planning the game, we assumed that due to the frequency of updating the routes we could cause BGP traffic damping . Since we both sit on real production traffic, we agreed to set a 30-second timer for each turn, because due to damping failures will occur on the working servers.

Other traffic passed through the game routers, so I had to keep the usual routing daemon online and it was impossible to use a special BGP daemon. To circumvent this limitation, the game's binary generated and reloaded the BIRD configuration, using the daemon control socket to poll for route changes.

With these settings, on May 16, 2018, AS206924 and AS203729 probably played the first board game in history, which was conducted purely by BGP.



The game went smoothly, except for a 45-minute pause due to the aforementioned damping. This happened on my side and made Level 3 use a less optimal route for my traffic for 45 minutes. In order to prevent a repetition of the situation, we decided to switch to a 90-second period between turns.

Despite this, the final blow to the fleet of my friend AS203729 was dealt on the 68th move. What makes me the first winner of a board game conducted via a public Internet routing protocol.

Was it logical? Probably not. Was it fun? Damn it, yes.

The source code on both sides is published , although I do not propose to repeat this experiment.

Until next time!