You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
||8 years ago|
|Makefile||8 years ago|
|README.txt||8 years ago|
|hide-eid.c||8 years ago|
|packet.c||8 years ago|
|packet.h||8 years ago|
|rloc-registry.json||8 years ago|
|rlocs.c||8 years ago|
|rlocs.h||8 years ago|
|util.c||8 years ago|
|util.h||8 years ago|
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.
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.
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
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.
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.
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 :)
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
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 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.