Arbitrary data transmission over the DFZ: How I'm storing my resume in your router's BGP table

Update 2/15/2021: It seems that this idea of adding 50 RFC 8092 BGP communities to a route doesn’t play nice with certain BGP implementations. As such, this project is no longer active.

(If you’re looking for my full resume, see https://natesales.net/resume.pdf)

I recently started my search for a summer internship to gain some hands on industry experience, hopefully in network software development. This also meant that it was time to get my resume together. Inspired by Louis Poinsignon’s traceroute resume, I decided to design my own creative way of distributing my resume. Presenting “Arbitrary data transmission over the DFZ: How I’m storing my resume in your router’s BGP table”. In other words, unofficially “draft-sales-binary-over-bgp-communities”.

So how does it work? At the core of the system is GoBGP paired with a serialization algorithm to store arbitrary data in the DFZ as RFC 8092 BGP Large Communities. My code builds into two binaries, a server with an embedded GoBGP daemon to announce the encoded resume route, and a client to read the route’s attributes from another router. The daemon encodes the resume from a file into RFC 8092 Large Communities before the BGP speaker announces the route into the DFZ. I could have patched in an additional MP-BGP extension and had nearly complete control over bytes on the wire, but I wanted my resume to be viewable by querying a router without modification of the router’s BGP code. I decided to use the IPv6 Unicast AFI/SAFI, given it’s widespread compatability with almost all BGP implementations and that I have enough IPv6 space to dedicate a /48 for the project.

My encoding algorithm first encodes the input bytes as base64 to ensure the data fits within the ASCII character set. Then, for each character in the resulting string, it is cast to an integer to find the ASCII code, and prefix-padded if necessary to result in a string of 3 digits. These are the concatenated into groups of 3 characters and a prefix of 1 is added to ensure the value doesn’t have a leading zero. The resulting strings are then converted to unsigned 32-bit integers and added in pairs to the 2 local data fields of a BGP large community. The RFC 8092 Global Administrator field of all communities is set to the announcing origin ASN (AS34553).

Each local data field as defined in RFC 8092 is an unsigned 32 bit integer, which works out to 6 characters stored per community. Unfortunately there is a limit to the amount of data that can be stored in BGP route attributes. With base64 overhead, the actual maximum storage space per route varies in order to stay within the allowed BGP UPDATE message size. I’m not storing my entire resume in the DFZ, but rather the first few sections with a link to the full PDF. All in all, it fits in about 50 BGP large communities. I chose to add base64 mainly in order to expand the usable character set for resume formatting, but the result is that other binary files could be sent over BGP Large Community encoding too.

To decode the data, a BGP table lookup is ran on a router and fed into a parser and decoder in order to split the community integers into slices of 3 characters, trim leading zeroes, cast to characters, concatenate, and decode as base64. Voila!

BGP Resume Communities

BGP Resume Markdown

The result is my resume can now be found in the DFZ — and if your router carries a full table — in your router’s BGP attribute memory. Kind of neat to think about, isn’t it?

(If you’re looking for my full resume, see https://natesales.net/resume.pdf)