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