Browse Source

Markdown != asciidoc

main
Nick Thomas 8 years ago
parent
commit
cb1e2ea882
  1. 106
      README.md

106
README.md

@ -9,29 +9,31 @@ Overview
As the Location/Identity Separation Protocol people have noted, IPv4 and IPv6
both use IP addresses (Endpoint IDs, in the lingo) to make routing decisions.
Focusing on this from the point of view of routing table efficiency / features,
they note that this is sub-optimal, and that intermediate routers do not need
the EID to make routing decisions, if an alternative (routing locater, or RLOC)
is present in the packet.
they note that this is sub-optimal. Intermediate routers do not need the EID to
make routing decisions if an alternative (routing locater, or RLOC) is present
in the packet. More information about this idea can be found in RFC 6830,
[here](http://tools.ietf.org/html/rfc6830).
What seems to have gone unnoticed is that there are privacy implications here.
As recent PRISM, XKeyscore and other disclosures have shown, these intermediates
are complicit in, or at least vulnerable to, attacks by national security
agencies, who take advantage of the visibility of these EIDs to construct
comprehensive logs of who is talking to who; even if the content of the
communication is encrypted, the simple fact that an individual has communicated
something somewhere may be enough for these agencies to justify taking futher
action against them.
Recent PRISM, XKeyscore and other disclosures have shown that intermediaries
can be complicit in, or at least vulnerable to, attacks by national security
agencies, among others, who take advantage of the visibility of these EIDs to
construct logs of who is talking to whom. Even if the content of the message
is encrypted, the simple fact that an individual has communicated something
to an identifiable destination may be enough for these agencies to justify
taking further action against them - targeted surveillance, for instance.
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 around 40Gbps (for small to medium ISPs).
the ability to scale to traffic levels of around 40Gbps (for small to medium
ISPs), in mind.
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
who share the same RLOC. In this scheme, I assume that this is an access ISP, on
one end of the path; and a hosting ISP, on the other end. This provides typical
anonymity sets of between a few hundred to a few million individuals.
If the source and destination EIDs are not sent in the clear, and the payload
is encrypted, then the only identifiying information intermediaries have is
the source and destination RLOCs. For a HTTPS session between an individual and
a website, this could be a few tens of thousands of internet subscribers on the
one side, and a few thousand servers running websites on the other other.
To remove these EIDs, we need to start by creating an EID-to-RLOC map. A first
pass for this is an /etc/hosts equivalent; a second pass could be a DNS node
@ -57,7 +59,8 @@ the same as if the packet had never been wrapped. This is a large advantage of
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.
encapsulated packet, and send that decrypted packet on to its final hop. Return
traffic undergoes the same treatment, of course.
Usage
@ -72,49 +75,50 @@ 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..
maintained by this project, for now - 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 ECC private keys, and their public components, in PEM format:
$ openssl ecparam -genkey -out rloc1.private.pem -name secp160r2
$ openssl ec -in rloc1.private.pem -pubout -out rloc1.public.pem
$ openssl ecparam -genkey -out rloc2.private.pem -name secp160r2
$ openssl ec -in rloc2.private.pem -pubout -out rloc2.public.pem
$ openssl ecparam -genkey -out rloc1.private.pem -name secp160r2
$ openssl ec -in rloc1.private.pem -pubout -out rloc1.public.pem
$ openssl ecparam -genkey -out rloc2.private.pem -name secp160r2
$ openssl ec -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:
add 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"}
{ "family":"ipv4", "network":"10.0.0.0", "netmask":8, "rloc":"1.2.3.4"}
(IPv6 support isn't in yet)
IPv6 support isn't in yet. Once it is, IPv4-in-IPv6 and vice-versa mappings will
be permitted.
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.
it's not the private key! Also, remember to add all the EID mappings and RLOCs
you want, 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
$ 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,
One of those TODOs is bgp/etc 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
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
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.
@ -136,15 +140,15 @@ L/ISP router (badly), and implementing cryptography for the encapsulated IP
packets, for the sake of experimenting. Crypto is hard, and experimentation is
key (ha ha).
Current scheme:
~~~~~~~~~~~~~~~
### Current scheme
This seems less stupid.
* EC public keys in central repository
* Each participant knows only their private key
* Generate ECDH secret for each peer using their public + your private key
* pseudo-random 128-bit IV per-packet, put at the start of encrypted data
* Use as256 symmetric encryption with sha256( ecdh ) to encrypt / decrypt
* EC public keys in central repository
* Each participant knows only their private key
* Generate ECDH secret for each peer using their public + your private key
* pseudo-random 128-bit IV per-packet, put at the start of encrypted data
* Use as256gcm symmetric encryption with sha256( ecdh ) to encrypt / decrypt
Main point is that routers don't need to communicate with each other to
negotiate a shared key - they can independently derive the same asymmetric key
@ -158,8 +162,8 @@ Which curve should we be using? No clue. What size of key should we be using?
No clue. Is this kind of shared key appropriate when we're passing considerable
traffic? No clue.
Scheme 0:
~~~~~~~~~
### Scheme 0
This was stupid.
* RSA public keys in central repository
@ -258,8 +262,8 @@ answer to both of those questions is yes. I wish it were otherwise.
Author
------
Name : Nick Thomas
Handle : lupine
Web : lupine.me.uk
Comms : nick@lupine.me.uk
Name : Nick Thomas
Handle : lupine
Web : lupine.me.uk
Comms : nick@lupine.me.uk
Loading…
Cancel
Save