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

From: Edward Lopez <[email-masked]>
Date: Mon, 3 Mar 2014 18:13:10 +0000

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

---

From: Edward Lopez <[email-masked]>
Date: Tue, 4 Mar 2014 01:19:33 +0000

As I’ve previously noted, there was a significant lapse in time since I was able to last work on this draft for lisp-oe.  Even then, there was a significant difference between myself and Dino regarding the methodology of actually encrypting the packets, where lisp-oe using IPSec ESP, and lisp-crypto is evolving its own methodology.  While we will both constructively agree to disagree, Dino has asked me to remove his name from my draft, as to not misrepresent his position.

Both lisp-crypto and lisp-oe agree on the need to establish a key within a single packet exchange, which I do believe is the critical work.  It may be possible to join work on commonality within the key-exchange aspects of the drafts, while working separately on the actual LISP packet encryption scheme.

Attached is 'draft-lopez-lisp-oe-01’, which reflects this change.

Thanks!
Ed Lopez

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 5 Mar 2014 08:33:04 +0100

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Edward Lopez <[email-masked]>
Date: Wed, 5 Mar 2014 13:36:07 +0000

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-masked]<mailto:[email-masked]>> wrote:

--- Roger J ---

On Mon, Mar 3, 2014 at 7:13 PM, Edward Lopez <[email-masked]<mailto:[email-masked]>> wrote:

Thanks!

Ed Lopez

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

--

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