Re: [lisp] RFC 6830 - possible extension.

[Nick Thomas <[e-mail]>]

Hi Noel,

(I am subscribed to the list :) )

On 21/08/13 15:30, Noel Chiappa wrote:
>     > From: Nick <[e-mail]>
> 
>     >> The impetus for developing it was the Snowden PRISM/XKeyscore
>     >> disclosures - currently, a privacy-conscious ISP can't do much to
>     >> prevent traffic (especially headers) between themselves and another
>     >> privacy-conscious ISP from being snooped on.  Use of RLOCs instead of
>     >> EIDs in the outer IP header means that individual users share an
>     >> anonymity set which is the size of the number of users sharing that
>     >> RLOC. When both source and destination are obscured this way, it
>     >> becomes less "alice and bob are communicating", and more "someone in
>     >> chicago is talking to someone in toronto".
>  
> This sounds quite interesting (although the denizens of certain large
> buildings might be grinding their teeth).

Obviously, it's no magic bullet. It can make the less-intrusive
surveillance methods useless, but They(TM) can always get more
intrusive. Hopefully, the level beyond this - bug every access and
hosting ISP - is intrusive enough that it'll be slapped down, but you
never know.

> All, does this fit within our current charter? If not, something to keep in
> mind if/when we redo the charter.
> 
>     >> Obviously, preserving this anonymity requires the inner IP headers to
>     >> be encrypted
> 
> Wonder if it's worth doing the payload, too? Obviously, that would cost more
> computing, but...

hide-eid currently encrypts the first 512 bytes of the IP packet, or the
whole thing if it's less than that. I was very concerned about the
computational cost of encryption when I made that decision; it may not
actually matter.

Tonight, I'm going to try to get it to scale to gigabit on 4-8 x86_64
cores as-is. I'll see what difference 40 (IP+TCP header) vs 512 vs ~1500
bytes makes on throughput at that level.

Leaving the TCP headers in the clear would permit some correlation
attacks - source and destination port, etc. Encrypting the whole thing
is probably pointless if it's already SSL traffic.

In any real implementation, I'd guess the destination publishes a set of
schemes it's willing to accept with each key it advertises, and the
source tells the destination which scheme it used for each packet sent.
If a whole-packet and a just-protocol-headers scheme were both
advertised, the source *could* select the former for well-known ports
for cleartext services (80, 25) and the latter for well-known ports for
encrypted ones (443, etc). You know, if their hardware is up to it.

Some of the graphs on http://shader.kaist.edu/packetshader/ were very
encouraging, performance-wise :). I don't know how performance degrades
when you're switching between many different encryption contexts (~40K,
worst case?) instead of just the one, though. Nor am I familiar on how
specialised hardware cryptography engines would cope with that scenario.

Rather than me adding "proper L/ISP protocol semantics" to hide-eid, is
there a software implementation that I could work top of instead? "L/ISP
software" is not the most unambiguous search term in the world :)

/Nick