hide-eid/pass-1/README.txt

Pass 1
======

This pass consists of proof-of-concept code. The intent is to implement it as 
quickly as possible, then refine it until we have code that scales to the level
of "small ISP" - say, 1Gbit/sec - without a  ridiculous investment in hardware. 


rloc-registry.json
==================
The "registry" is a JSON file, with the canonical version administered
centrally. It maps IP ranges to RLOCs, and stores the public key to use with
each RLOC. Both wrapper and unwrapper need a copy of this file to work. We also
include a tiny library for reading it. 


wrapper
=======
This component only wraps packets. It reads the contents of the rloc-registry,
outputs a bgpfeeder file that will redirect eid ranges to it, if honoured, opens
a tun device, and waits for packets to be sent to it. Upon receiving a packet,
it encrypts the start - including IP, TCP, UDP, etc headers, prepends a new IP
header that will route it to the destination RLOC, and outputs the new packet.

If it doesn't recognise an EID, or can't encrypt the packet, it is dropped.

unwrapper
=========
The unwrapper is in operation to the wrapper, but is also given a list of RLOCs
that is has private keys for. When a packet comes in, it tries to decrypt the
encrypted portion, reassemble the original packet and forward it on. If it
doesn't have the private key, or other problems arise, the packet is dropped.

hide-eid
========
Most people will be more interested in hide-eid, which operates as a combined
wrapper and unwrapper. Like those programs, it opens a tun device, but it can
recognise whether a packet forwarded to it has been wrapped or not, and perform
the opposite operation before forwarding the packet on. This makes it useful
if you want to both receive and send traffic with a minimum of fuss - which is
most people, I guess.

bgpfeeder
=========
This is a simple program that implements the BGP protocol. It's already written,
and works. we use BGP to redirect traffic from the ISP core routers to the
wrapping / unwrapping boxes because they already speak it. We use bgpfeeder
because it already exists :)


wrapper/unwrapper protocol
==========================

When we say "wrapper encrypts", "unwrapper decrypts" or "wrapped packet",
there's an implicit protocol there. This is, more or less, it.

First, the IP header the wrapper constructs sets the Protocol field to 99. We
don't have an assigned number yet. This should be fine.

The payload of this IP packet is the encrypted + unencrypted (if any) portion
of the packet, prepended by 16 bits that are interpreted as the encrypted
payload length.

The wrapper encrypts either the IP header, or the entire IP packet (depending on
setting). It takes the encrypted blob, plus the part of the packet (if any)
that has been left out of the encryped part, adds 2 to the length, and sets that
number as the wrapping IP header's payload length. It then writes the length of
the encrypted portion of the total payload as the first 2 bytes of the payload,
followed by the constructed blob. 

The unwrapper receives the packet, reads the IP header, then reads the next two
bytes. It takes the first n bytes of the remainder of the payload and decrypts
it, then prepends that to the remaining bytes. What it ends up with should be a
valid IP packet. It then alters the packet's TTL according to the wrapping
packet's TTL field, and forwards it for further routing.