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
> lisp@ietf.org. 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