Hi Noel, (I am subscribed to the list :) )
On 21/08/13 15:30, Noel Chiappa wrote: > > From: Nick <[email protected]> > > >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
