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

93
README.md
View File

@@ -26,7 +26,7 @@ action against them.
Since the EID is not needed by these intermediaries, it makes sense to stop
giving it to them as quickly as is possible. These tools aim to implement a
simple scheme that achieves this goal, with speed / ease of implementation, and
the ability to scale to traffic levels of ~40Gbps (for small to medium ISPs).
the ability to scale to traffic levels of around 40Gbps (for small to medium ISPs).
Removing knowledge of the EID from them means that any affected traffic enjoys
the status of being in an anonymity set that is as large as the number of people
@@ -60,6 +60,73 @@ the scheme over onion routing, such as tor; no significant latency is added.
When received by the destination ISP, it can use its private key to decrypt the
encapsulated packet, and send that decrypted packet on to its final hop.
Usage
-----
Pass 1 now exists, in a rudimentary form. Here's how to put together a couple of
hide-eid endpoints that can talk to each other.
First, you need two machines - one is the source, the other the destination. Both
should have an IPv4 address routed to them that is not claimed on the machines
themselves. These will be your RLOCs. They should be globally routeable! Public
IPs, in other words.
On each machine, you'll also need a range of IPs. These will be your EIDs. They
need to be globally unique only within the context of the EID-to-RLOC registry
maintained by this project - they can even be RFC1918 space, as long as there
are no overlaps within this registry. Remember, EIDs aren't used to make routing
decisions across the Internet..
Generate some RSA private keys, and their public components, in PEM format:
$ openssl genrsa -out rloc1.private.pem 4096
$ openssl rsa -in rloc1.private.pem -pubout -out rloc1.public.pem
$ openssl genrsa -out rloc2.private.pem 4096
$ openssl rsa -in rloc2.private.pem -pubout -out rloc2.public.pem
Add entries to the rloc-registry.json file to reflect your mappings. You need to
put an entry (a JSON object) to the "eid_rloc_map" array, like this:
{ "family":"ipv4", "network":"10.0.0.0", "netmask":8, "rloc":"1.2.3.4"}
(IPv6 support isn't in yet)
You also need to add an rloc:pubkey mapping to the "keys" object. Make sure
it's not the private key! Also, remember to add all the EID mappings and RLOCs,
not just one.
Then, on each machine:
$ cd pass-1
$ make all
host1$ ./hide-eid rloc-registry.json eid0 eid0 <rloc1> <rloc1>.private.pem
host2$ ./hide-eid rloc-registry.json eid0 eid0 <rloc2> <rloc2>.private.pem
You'll notice quite a lot of uninteresting output; it's wordy for all the wrong
reasons at the moment. Of particular note are a wide range of TODOs.
One of those TODOs is bgp support for route injection. Since it's not done yet,
you need to add the routes yourself:
host1$ ip route add <eid-range-for-rloc-2> dev eid0
host2$ ip route add <eid-range-for-rloc-1> dev eid0
Also, make sure that an EID from each range is routable on the respective machines.
For testing, I just did:
host1$ ip addr add <eid-ip-for-rloc-1> dev eid0
host2$ ip addr add <eid-ip-for-rloc-2> dev eid0
The short version is that traffic to and from those EIDs must go into the TUN
device controlled by hide-eid for it to do the magic.
At this point, you should be able to ping <eid-ip-for-rloc-2> from host1, and
vice-versa, and get an ICMP echo reply back. You can also run TCP or UDP
servers on one of the IPs, and connect to them from the other IP. If you run
wireshark or tcpdump on an intermediate machine (or just one of the hosts, if
you focus on the egress/ingress traffic) you'll see obscure IP packets with
just the RLOC addresses as source and destination, with no visible UDP/TCP
headers.
Limitations
-----------
@@ -82,12 +149,23 @@ scale is going to be a challenge. Hopefully not impossible - but if it's too
expensive, uptake will be low or zero. If it's too unreliable, uptake will be
low or zero.
First result: rtt increased from 37ms to 80ms. There are four cryptographic
operations in each trip - encrypt outgoing packet, decrypt outgoing packet,
encrypt return packet, decrypt return packet. This is on a laptop and VM with
no hardware crypto support of any kind, of course. but it's also with nothing
else to do at all.
For access<->hosting, that kind of latency increase is bad, but bearable. For
hosting<->hosting, it's completely unacceptable.
Not all of it may be crypto-related - worth implementing a no-op branch that
just encapsulates, and checking the difference.
May break ICMP and other responses from intermediate ISPs. Path MTU discovery
breaks, for instance, with a naive implementation of this scheme, as does
ICMP tracerouting (this can be fixed, especially in IPv6 - see _ICMP_).
Selling points
--------------
Uptake can be low (but not zero) and significant benefits are still seen. Even
@@ -142,11 +220,8 @@ answer to both of those questions is yes. I wish it were otherwise.
Author
------
Name : Nick Thomas
Handle : lupine
Web : lupine.me.uk
SMTP / XMPP / etc : nick@lupine.me.uk
Name : Nick Thomas
Handle : lupine
Web : lupine.me.uk
Comms : nick@lupine.me.uk

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-----"
}
}
}