Subject: Re: [lisp] RFC 6830 - possible extension.

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Aug 2013 10:30:58 -0400 (EDT)

> From: Nick <[email-masked]>

    >> 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).

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...

    > I'm reasonably ignorant of the processes and politics of RFCs and
    >  things.

That's OK, we have plenty of experts on that... :-)

     Noel

---

From: Nick Thomas <[email-masked]>
Date: Wed, 21 Aug 2013 16:59:44 +0100

Hi Noel,

(I am subscribed to the list :) )

> 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.

> Wonder if it's worth doing the payload, too? Obviously, that would cost more

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 24 Aug 2013 05:12:33 -0400

Using the LISP mapping system to pass keys for use in the data plane is 
beyond what is in our current charter.
Once we clear that blocking items, it would be reasonable to discuss this.

Personally, I find arguments other than the shared anonymity pool to be 
more persuasive as to the value of this.  So, again personally, I would 
suggest including other motivations when we get to the discussion of 
working on the topic.

Yours,
Joel

On 8/21/13 10:30 AM, Noel Chiappa wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>