81 lines
3.3 KiB
Plaintext
81 lines
3.3 KiB
Plaintext
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
|
|
|