Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

> I agree that asymmetric encryption may be more desirable in theory, but in practice symmetric encryption supports much higher performance loads

But with asymmetric we can use a two packet exchange (the Map-Request and Map-Reply), store the public key only in the mapping database (no other components necessary), allow an ITR to send Map-Requests to the map-resolver where Map-Replies are sent from an ETR connected to another map-server (the map-resolver is not the map-server for the ETR).

Yes, it is slow, but that is the cost for the best security.

Dino

> 
> Ed Lopez - Fortinet
> VP, Carrier Solutions
> 1090 Kifer Road
> Sunnyvale, CA 94086
> +1 703 220 0988
> 
> Sent from my iPhone ... Sorry for any auto-correct errors
> 
> On Sep 8, 2013, at 2:30 PM, "Michiel Blokzijl (mblokzij)" <mblokzij@cisco.com> wrote:
> 
>> I think it would actually be quite interesting to use "standard" public key encryption, rather than symmetric encryption in LISP. This would reduce the need for negotiations, not require pairs of ITRs and ETRs to share the same map server, etc. Admittedly it might not be practical for other reasons.. (may need to store lots of large keys, might be too slow, etc)
>> 
>> Here's one way to do it:
>> You could easily attaching a PGP key id to the RLOCs in the mapping record returned in map-replies. When an ITR receives a map-reply, the ITR could grab the public key from one of the well-known keyservers, and use that public key for encrypting traffic to that ETR.
>> 
>> Best regards,
>> 
>> Michiel
>> 
>> On 8 Sep 2013, at 16:04, Edward Lopez <elopez@fortinet.com>
>> wrote:
>> 
>>> Key generation/management/distribution would be the real difficulty.  It would be desirable to use symmetric encryption (Ex. AES256) to encrypt LISP payloads.  Therefore, we use certs & asymmetric encryption (some form of ECC) at the time of xTR registration to provide a method to distribute keys to authenticated site members.
>>> 
>>> Another consideration is to encrypt just the EID header, and have EIDs use IPSec (thus LISP would in effect encrypt the outer IPSec ESP header).  Someone in the RLOC space would then require two keys to decrypt the message fully, and the encryption load would be distributed between EIDs and xTRs
>>> 
>>> Ed Lopez
>>> 
>>> Sent from my iPhone ... Sorry for any auto-correct errors
>>> 
>>> On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" <jnc@mercury.lcs.mit.edu> wrote:
>>> 
>>>>> From: Marc Binderberger <marc@sniff.de>
>>>> 
>>>>> Lisp is separating Identity from Location but this doesn't mean the
>>>>> RLOC can not be used to identify you. In case of static setups this is
>>>>> obvious, take the RLOC, go to the ISP, get the (physical) address and
>>>>> name.
>>>> 
>>>> Err, that would get the address and name of the ITR, not the actual source
>>>> host.
>>>> 
>>>> Depending on all sorts of factors, that plus the encrypted packet _might_ get
>>>> them the identity of the actual originator (not, for example, if the ITR has
>>>> discarded the key used to encrypt the packet by the time the subpoena
>>>> arrives...)
>>>> 
>>>> Noel
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> ***  Please note that this message and any attachments may contain confidential 
>>> and proprietary material and information and are intended only for the use of 
>>> the intended recipient(s). If you are not the intended recipient, you are hereby 
>>> notified that any review, use, disclosure, dissemination, distribution or copying 
>>> of this message and any attachments is strictly prohibited. If you have received 
>>> this email in error, please immediately notify the sender and destroy this e-mail 
>>> and any attachments and all copies, whether electronic or printed.
>>> Please also note that any views, opinions, conclusions or commitments expressed 
>>> in this message are those of the individual sender and do not necessarily reflect 
>>> the views of Fortinet, Inc., its affiliates, and emails are not binding on 
>>> Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
>>> a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
> 
> ***  Please note that this message and any attachments may contain confidential 
> and proprietary material and information and are intended only for the use of 
> the intended recipient(s). If you are not the intended recipient, you are hereby 
> notified that any review, use, disclosure, dissemination, distribution or copying 
> of this message and any attachments is strictly prohibited. If you have received 
> this email in error, please immediately notify the sender and destroy this e-mail 
> and any attachments and all copies, whether electronic or printed.
> Please also note that any views, opinions, conclusions or commitments expressed 
> in this message are those of the individual sender and do not necessarily reflect 
> the views of Fortinet, Inc., its affiliates, and emails are not binding on 
> Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
> a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp