Re: [lisp] A Stab At Opportunistic Encryption for LISP

[Edward Lopez <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lisp




--

Roger Jorgensen           | ROJO9-RIPE
[e-mail]<mailto:[e-mail]>          | - IPv6 is The Key!
http://www.jorgensen.no   | [e-mail]<mailto:[e-mail]>



***  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. ***