Re: [lisp] RFC 6830 - possible extension.

[Stephen Farrell <[e-mail]>]

Hi Nick, all,

Just FYI, we very recently created a new non-wg list [1]
partly for general discussion of techniques like this. So
far, that's mostly been about higher layer things (e.g.
mail) but this work seems entirely on-topic for that list
too.

I think it'd be useful for that new list to consider this
kind of thing, so I posted a pointer to this thread. Feel
free to join in over there too.

Cheers,
S.

[1] https://www.ietf.org/mailman/listinfo/perpass

On 08/20/2013 02:48 PM, Nick wrote:
> Hi again,
> 
> Thanks for responding - especially so positively :)
> 
>>> Hi Dino, et al.
>>>
>>> Apologies for emailing you all out of the blue; you're listed as authors
>>> on the L/ISP RFC, and I don't know if there's a more appropriate
>>> procedure for talking about it to you.
>>
>> Thanks for your comments Nick. The LISP WG mailing list is appropriate. It is
>> [e-mail]. But you can decide if you want to repost. You are
>> welcome to repost my reply as well.
> 
> OK, I'm primarily responding now to get my email and your response onto
> this mailing list
> 
>> I took the liberty to copy some others that are interested in this area.
>>
>>> Anyway, I recently started putting together a perceived improvement to
>>> how the internet works, as a personal project, and was pointed at
>>> RFC6830 partway through by a colleague; it turns out that the scheme I'd
>>> devised was essentially L/ISP, with one enhancement: the registry
>>> contains a public key for each RLOC, which is used in conjunction with
>>> (EC)DH to encrypt (and decrypt) the encapsulated IP+TCP headers.
>>
>> Yes, we have had many ideas in the past to make this work as well. If you have a 
>> look at the draft-ietf-lisp-lcaf document you'll see we have a Security Type address
>>  that can encode a key. That means the LISP mapping database system can be a sort of
>> lightweight PKI and the key exchange is done with the existing Map-Register and Map-Request
>> APIs we have as part of the control-plane design.
> 
> I had a look at the document, although I must admit that much of the
> passed me by for now. It's good to know I'm not the only person having
> these thoughts, though :).
> 
>>> I have a very noddy almost-L/ISP implementation at
>>> https://github.com/lupine/hide-eid which does this, more or less. 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.
>>
>> Yes, I am well aware a lot of activity picking up in this area. Source obfuscation seems to be trendy this year.  ;-)
>>
>>> 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".
>>> Obviously, preserving this anonymity requires the inner IP headers to be
>>> encrypted; public keys + ECDH to generate a shared secret, which is used
>>> for aes256gcm encryption of those headers, achieves this.
>>
>> Right, that is correct.
>>
>>> There are obvious performance and scalability issues, and it was my
>>> intention to explore those a bit more before bringing this work to your
>>
>> I think we can control the scalability at the control-plane using the mapping database. And we have some security experts
>> thinking about how to make either symmetric or asymmetric ciphers go faster.
>>
>>> attention; however, it turns out that the code linked to above can
>>> achieve unidirectional UDP throughput of 350Mbit/sec (unidrectional TCP
>>> of 180Mbit/sec or so) in a single-core VM, and is eminently
>>
>> What cipher did you use?
> 
> aes256gcm to encrypt + authenticate the traffic. The shared secret for
> that is sha256( ecdh( their-public, our-private ) ). Along with 128 bits
> of pseudorandom IV (transmitted in the packet along with the encrypted
> data).
> 
>>> parallelisable. I'm very confident that consumer-grade hardware can push
>>> this to gigabit, which is where it starts being useful for small ISPs.
>>> 10 and 40GigE are probably possible with currently-existing specialist
>>> hardware too, although I'm unlikely to get the kit to test it anytime
>>> soon!
>>>
>>> Anyway, to me the benefit of this kind of encryption as an optional
>>> feature in the L/ISP protocol is obvious, but I've been working on it
>>> fairly obsessively for some time now. I guess what I'm looking for right
>>> now is feedback on the enhancement; whether you think it's worthwhile in
>>> general, and worthy of a successor to RFC6830 in particular. The goals
>>> are, of course, blatantly political - and you may or may not agree with
>>> those goals - but, hey, it's a feature L/ISP can have that could drive
>>> its adoption in general.
>>
>> It is worth-while and I think it is time to write an Internet Draft. I have enclosed 
>> some slides that Fabio and I worked on a long time ago that needs to
>> be put into text in a draft. We would love to have you be part of
>> this.
>>
>>> I'll stop talking for now, but as I said, I'm very interested in
>>> feedback, and I'm happy to discuss it with you all as much as is needed
>>> for us to agree on whether it's overall a good idea, or a bad idea. I've
>>> tried to hold off on selling why I think it's a good idea, in favour of
>>> describing what it is, for now. I'm happy to do more of either if you're
>>> willing to listen.
>>
>> Let me know how much time you can dedicate to this.
> 
> I have perhaps a couple of evenings a week to dedicate to this kind of
> stuff; my original plan was to put together an implementation that can
> go to somewhere between gigabit and 10GigE, then try to push some form
> of that to internet-draft status, while getting my home and hosting ISPs
> to play around with it experimentally. I'm happy to contribute however
> you feel my time would be most effective, though; I'm reasonably
> ignorant of the processes and politics of RFCs and things.
> 
> Regards,
> 
> /Nick
> 
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
> 
>