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 >> [email protected]. 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 > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
