lupine/hide-eid
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

First pass at fragmenting

Browse Source
This commit is contained in:
Nick Thomas
2013-08-09 03:11:15 +01:00
parent 1acaa03799
commit cfd1b2f957
11 changed files with 405 additions and 359 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
pass-1/README.txt
View File

@@ -14,31 +14,34 @@ 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.
hide-eid
========
This program acts as an xTR (wraps and unwraps 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.
When it receives an already-wrapped packet, it tries to decrypt and reassemble it,
and forward it on. It needs the private key for that, and if it doesn't have it,
or other problems occur, the packet is dropped.
We also handle ICMP and fragmentation, in case the packet we receive is too big,
according to the schemes in RFC6380. We keep track of the discovered path MTU for
each of the other xTRs by parsing incoming ICMP messages.
For wrapped packets that are too large to fit down the discovered path, if the DF
bit is set in the unwrapped packet, we return an ICMP packet informing the source
of this. Otherwise, we fragment the nuwrapped packet according to standard IP
rules, encrypt the two IP packets that result, and let the destination EID be
responsible for reassembling it. This removes a responsibility from hide-eid
at the destination, which won't have to keep track of encrypted fragments.
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
=========
@@ -68,11 +71,10 @@ 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.
The constructed blob currently consists of 16 bytes of PRNG data used as the IV,
the encrypted data (using the symmetric aes256gcm authenticating cipher) and 16
bytes of generated tag data.