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

Some doc / example updates

Browse Source
This commit is contained in:
Nick Thomas
2013-08-06 23:16:28 +01:00
parent 0dff4409ce
commit c77557b6ee
3 changed files with 116 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
pass-1/README.txt
View File

@@ -6,32 +6,39 @@ 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
=============
The "registry" is a plain file, with the canonical version administered
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
=======
The wrapper operates by taking the entire contents of the RLOC registry on
startup, along with information about which RLOC(s) it is in, and which IP it is
running on. It then drops a bgpfeeder-suitable file on disc that will redirect
all the EIDs in the rloc registry to its IP address, and waits for packets.
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.
Every time a packet comes in, wrapper reads it, then constructs and emits a
corresponding wrapped packet.
Don't bother implementing RLOC pools for ICMP yet.
If it doesn't recognise an EID, or can't encrypt the packet, it is dropped.
unwrapper
=========
This component is fed a private key, and told which RLOC(s) to listen on. It
dumps a bgpfeeder-compatible file to disc directing those RLOCs to it, then
waits for wrapped packets to come to it. As it receives them, it decrypts them
with the private key, then constructs the unwrapped equivalent and forwards it.
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
=========
@@ -47,7 +54,7 @@ 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 253. We
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
@@ -67,3 +74,5 @@ 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.

14
pass-1/rloc-registry.json
View File

@@ -24,8 +24,8 @@ q14pHlpN3xepxwHZtCJTyU7kHaWKvImFZRY6dg0dRkvWl2bO6xJsYYXTaYHre+Sx
ivtEZcM7VPEZlQyBlwTYYHmnllBlnXMJpx20p26Sy4iPX6hzn9sT3UQHE6NAlfON
He5Cw+4ma5DA2jQvvIBfYA1ipVfGKD8LyrPrxuD9qErYpPBP23EdJwT0ZL+jKjyT
t39smrDydkWUQWYPiiUKKM0CAwEAAQ==
-----END PUBLIC KEY-----
",
-----END PUBLIC KEY-----",
"172.16.12.2":
"-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvYljSQd/jHZtSTc6Z2E1
@@ -40,8 +40,8 @@ PhN1So0n3XwsnAUWvm33ujTtvAGTuUwBKsG8nIb3iwr7Vh8O617yuOl7ab68Dxym
fJZZE5wzjzYbNxup8E9VSfHKSCUHptg9cB/1kF5HoshZCZwA62eAtQgaamr64NrT
Uuyz1Ng3KTiD1cObXeirB88yyYd1W21deRfGaGZlWpJTAMjy/bXjR6ZAA+xTXllO
QFqgpMLJRNxWj7UUOWm3xjECAwEAAQ==
-----END PUBLIC KEY-----
",
-----END PUBLIC KEY-----",
"fc00::2":
"-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnQhQ9S190q/+t0/QqplD
@@ -72,9 +72,9 @@ DSDQ5nNOo4hmySZnrEWq+t4BJjJ1wu7eAJpsCVXkyRZUtNt6c98VaAuJQv7FHW/O
75XaEHewVAAGTmQEjI/cTY72bHkbtE3vpi0aK8Wc7K4g7slUld0HUsh8xszIhdxu
8Y+yuP72oOpicPK8LCDyI28V0HCz44bo1TDrDUC0YZ1fDr8Pk2A+jrlt4/yMcgkn
PBcctUqN/b2cIfCA8UDAMZ0CAwEAAQ==
-----END PUBLIC KEY-----
"
-----END PUBLIC KEY-----"
}
}
}