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