Playing battleships over bgp – fringopost inert gas definition chemistry


BGP normally gets a bad rep, mainly because of its default trusting nature of peers, and the hard task of verifying a routes legitimacy. This is why we hear about BGP hijackings of varying severity from the whole of youtube to a section of all AWS Route 53 requests.

However it’s not much use if they can only talk to each other, and what if red and blue are not directly connected? The more routers we connect to, and those other routers connect to, we form a topology of routing information. This is possible because BGP shares routing information with its other peers it’s connected to:

How routers share information between each other is dependent on the configuration policy, and that is normally dictated by the real world relationship two routers have in common. Different setups exist for customers, traffic exchange agreements, or upstream providers.

Because of this, routers should have sets of instructions programmed into them to filter out things they are not expecting to give or to take from another peer. However from time to time someone with malicious intentions obtains access to a router that is connected to a router that does not have these filters. Fixing this programatically is incredibly hard because it would require every ISP to change how their routers work, and previous attempts to fix this have proven to not be widely adopted.

BGP also has a way to encode information with a route called communities. Defined in RFC1997 (sadly written in 1996, so. close.) a community can be attached to a route announcement, and consists of a 32bit number. That in practice is split into two 16 bit numbers (one for a ASN and one for a signal related to/for that ASN):

After some testing, it appears that every tier 1 network strips communities except former Level 3 who carry communties from origin router to customer router. This also means that a router could send information to other routers without ever actually talking directly to each other. Battleships

Knowing that I could do “indirect communication” over BGP now, I wanted to somehow use this to conduct some non conventional communication. I picked Battleships as a medium to test this in, since the communication required to play a battleship game is tiny (X and Y coordinates and if the last shot was a hit or a miss)

While planning out the game, we foresaw we could trigger BGP Route Flap Damping while playing the game due to the frequency we would both be updating our routes. Since we were both supporting real production traffic through the prefixes we were using to play the game, we agreed to a 30 second cooldown timer on every move we made, since triggering route flap damping would cause prefixes to be blackholed, and thus cause an outage for either of us.

As we were running other traffic through these routers, we had to keep our normal routing demon online rather than a custom BGP demon. To work around this the battleship game binary live generated and reloaded BIRD configuration and used the demons control socket to poll for route changes.

The game went smoothly, apart from a 45 minute period where no moves were exchanged due to causing the previously mentioned route flap damping to activate. This happened on my side and caused Level 3 to have a less optimal route for my traffic in the 45 minute period. To mitigate this from happening again later on the game, we decided to move to a 90 second cooldown period on every move.