Markdown != asciidoc
Nick Thomas
parent
e577c7efb8
commit
cb1e2ea882
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…
Reference in New Issue