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
