> 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)
Correct. If we don't start with the above assumptions, anything else will be too complicated to implement and deploy and therefore, corners will be cut, and insecurity will continue. > 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. Do you not want to solve man-in-the-middle attacks? Is this recommendation solely for providing data privacy? Dino > > 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 > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
