From c77557b6ee5ab6f3b3747866dac2955e6f829a9c Mon Sep 17 00:00:00 2001 From: Nick Thomas Date: Tue, 6 Aug 2013 23:16:28 +0100 Subject: [PATCH] Some doc / example updates --- README.md | 93 +++++++++++++++++++++++++++++++++++---- pass-1/README.txt | 41 ++++++++++------- pass-1/rloc-registry.json | 14 +++--- 3 files changed, 116 insertions(+), 32 deletions(-) diff --git a/README.md b/README.md index 7c6a554..96ad41d 100644 --- a/README.md +++ b/README.md @@ -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 .private.pem + host2$ ./hide-eid rloc-registry.json eid0 eid0 .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 dev eid0 + host2$ ip route add 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 dev eid0 + host2$ ip addr add 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 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 diff --git a/pass-1/README.txt b/pass-1/README.txt index 10cbc1e..ad6eaef 100644 --- a/pass-1/README.txt +++ b/pass-1/README.txt @@ -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. + + diff --git a/pass-1/rloc-registry.json b/pass-1/rloc-registry.json index a53b563..3073ad9 100644 --- a/pass-1/rloc-registry.json +++ b/pass-1/rloc-registry.json @@ -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-----" + } -} \ No newline at end of file +}