Roger, Perfectly fair comments. I can only apologize by saying that security companies like Fortinet are highly protective of their intellectual property. As a product VP, any external submissions I make are internally subject to legal review. As this was my first draft submission, and my company’s first forays in IETF WG participation, I was blocked pending internal review. To satisfy both the IETF Note Well as well as my company’s internal policies, I was effectively gagged. I did not post to any WG during that time. This was my situation until I met with counsel back at HQ while attending the RSA conference last week.
I could have submitted the draft at that time, but as you noted, Dino’s draft was up for discussion, and I thought it best not to confuse the topic. However, prior to my going silent, there was a direction towards performing a single packet exchange for key material. I also admit that we had differences regarding my suggestion to use IPSec ESP as the mechanism for encrypting LISP packets. As my draft suggests, I still feel that while the use of mapping messages and the Security Type LCAF to perform a key material exchange is highly relevant to our efforts. However, the creation of yet another encryption mechanism should not be, in my opinion. IPSec is a very well established, both from a standards standpoint, as well as from access to available code and commercial implementation. There are also many options to support hardware acceleration of ESP. I’m generally suggesting that while the use of IKE as a key exchange is not useful to us for obviously reasons, the use of ESP will allow us to provide opportunistic encryption for LISP, with a fast path toward multi-vendor implementation. I admit there are negative aspects towards using ESP, most notably the increase in packet size and MTU calculation. My view is that this is an issue with any cryptographic system, particularly in the use of block cyphers such as AES. Some packet expansion is inevitable. I also discount arguments that we should not change the outer header encapsulation, as the use of an ESP header both obscures the fact that it is a LISP packet, as well as provides the basic for maintaining the integrity of the encrypted packet via cryptographic hashing. Again I apologize for the silence, and I hope you can accept my explanation. It was not my intention to be duplicitous, and I am as well disappointed that there are competitive drafts. I believe that there is still common ground on the LCAF-based key exchange, and would like to work together on that aspect. However, in my view, the use of ESP as the LISP packet encryption mechanism is the better path to sustained interoperable implementations. This is not intended to dissuade efforts towards lisp-crypto, but we may have to agree to disagree relative to the encryption mechanism Kind Regards Ed Lopez On Mar 5, 2014, at 2:33 AM, Roger Jørgensen <[email protected]<mailto:[email protected]>> wrote: Not sure where to start but here we go. In short - on the background of that draft, I think it's quite respect less what you have gone and done. That's how _I_ see it. On the technical part, IPSec is nothing new, but I'm not going to comment on that. Some months ago I contacted Dino and started to discuss how we could encrypt all traffic between xTR's without involving the users at all. Or there could be an option for the EID-space holder to tell the mapping system that he only would accept encrypted traffic, or only some encryptions. I thought we could get something done and that work are in Dino's draft. And that's where _I_ started. During my discussion with Dino he involved other people, including you. I understood there was some previous work in progress and we was discussing to merge all that into one draft that you should write together with Dino and me. Then you went silent for weeks, I got no spare time so Dino went and wrote it all himself, that's Dino's draft. And now you show up with a draft with your name on, Dino has asked his to be removed for obvious reason since we've worked on his draft for quite some time now. You could have told us some weeks/months ago that you were working on a draft on your own, that's the least _I_ would have expected. Any future comments/involving from my side will be on technical things. --- Roger J --- On Mon, Mar 3, 2014 at 7:13 PM, Edward Lopez <[email protected]<mailto:[email protected]>> wrote: First off, I apologize to all for my absence on the mailing list, particularly Dino. My company is relatively new to IETF WG participation, and there were some backend discussions I had to have back at corporate to ensure that I was both in compliance with the IETF Note Well, as well as my company's internal IP processes. This has been resolved, and I will be resuming active participation on the list. At the time, I was working with Dino on crypto solutions for LISP. Enclosed in my draft regarding opportunistic encryption for LISP. While there are significant similarities with regard to the goals of one exchange of key material, non-reliance on PKI, nor storing keys on the mapping system, I proposed the use of IPSec ESP in transport mode for the actual encryption of packets between xTRs, as opposed to developing support for encryption within the LISP protocol itself. I feel this has significant advantages toward ease of deployment and hardware acceleration, as well as support for multiple available encryption/hash algorithms. The use of the security type (11) LCAF is very similar, except I propose that the Key Algorithm field be used to support encryption/hash algorithm sets, rather than individual algorithms. In this way, we can use Key Count values to signify ITF preferences. Another significant different is that this draft makes use of the R-bit to signal when Keys should be revoked, and can be used locally by xTRs to signal expiry conditions such as lifetime, peer detection failure, etc. Thanks! Ed Lopez ________________________________ *** 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lisp -- Roger Jorgensen | ROJO9-RIPE [email protected]<mailto:[email protected]> | - IPv6 is The Key! http://www.jorgensen.no | [email protected]<mailto:[email protected]> *** 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
