Subject: [lisp] Using LISP for Secure Hybrid Cloud Extension – Draft Submitted and Request for slot to present on IETF 89

From: "Santiago Freitas (safreita)" <[email-masked]>
Date: Wed, 12 Feb 2014 11:22:32 +0000

Hi LISP Working Group,

Today we have submitted a draft that covers using LISP for Secure Hybrid Cloud Extension.
The draft can be found at http://www.ietf.org/id/draft-freitas-bellagamba-lisp-hybrid-cloud-usecase-00.txt
We would like to request your comments on it.

Also, we would like request a small slot on the upcoming IETF 89 meeting to present an overview of the use case covered on the draft.

We look forward to your comments and for your feedback if we can have a small slot to present an overview of this draft on IETF 89.

Sincerely,
Patrice and Santiago

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 11:54:24 -0500

This draft seems to expect that IPSec tunnels will be set up by means 
outside of LISP.  That seems to contravene the premise of LISp that it 
can operate without needing permanent / pre-established tunnel state.

Should this be tied to the work Dino described at the last IETF meeting 
on using LISP to establish encryption for the LISP tunnel?

Yours,
Joel

On 2/12/14, 6:22 AM, Santiago Freitas (safreita) wrote:
> The draft can be found at
> http://www.ietf.org/id/draft-freitas-bellagamba-lisp-hybrid-cloud-usecase-00.txt
>
> Also, we would like request a small slot on the upcoming IETF 89 meeting
> to present an overview of the use case covered on the draft.
>
> We look forward to your comments and for your feedback if we can have a
> small slot to present an overview of this draft on IETF 89.
>
> Sincerely,
>
> Patrice and Santiago
>

---

From: Fabio Maino <[email-masked]>
Date: Wed, 12 Feb 2014 09:04:18 -0800

Hi Joel,
This describes how LISP is used today in combination with IPsec 
(typically GDOI is used to simplify key distribution).

I think Dino's work is more forward looking, with two main goals: (1) 
combine encryption with the LISP dataplane, for a more efficient 
encoding on the wire, (2) take advantage of the LISP mapping system (and 
possibly of some of the mechanisms in LISP-SEC) for key 
derivation/distribution

Fabio

On 2/12/14, 8:54 AM, Joel M. Halpern wrote:
> Should this be tied to the work Dino described at the last IETF 
> meeting on using LISP to establish encryption for the LISP tunnel?
>
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 12:12:33 -0500

that this describes an existing usage is clearly very important.

It seems that if the scale of the VPN is small enough that manually 
configured IPSec tunnels can be used, then LISP does not provide a lot 
of advantage.  If it is automated tunnels, there seems to be a need to 
coordinate the two systems.  What am I missing?

Thanks,
Joel

---

From: "Yves Hertoghs (yhertogh)" <[email-masked]>
Date: Wed, 12 Feb 2014 17:18:54 +0000

Joel,

The main advantages are:
* You can use the same subnet/prefix in both sites
* there is optimised ingress routing from remote LISP enabled sites
towards the right destination

Yves

On 12/02/14 18:12, "Joel M. Halpern" <[email-masked]> wrote:

>>>> Today we have submitted a draft that covers using LISP for Secure
>>>>Hybrid
>>>> Cloud Extension.
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 12:23:58 -0500

In the existing deployment, how does the LISP ITR know that the LISp 
traffic should use the IPSec tunnel.  I can imagine several possibilities:
1) All traffic to that destination from this source address uses the 
IPSec tunnel
2) All LISp encapsualted traffic to that ETR uses the IPSec Tunnel
3) There is some LISP attribute that provides the correlation.

It would seem that as a general mechanism this should probably be addressed.

I also think that the document should be more explicit about what the 
resulting message stack looks like.  (I have a guess, but readers should 
not have to guess.)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Feb 2014 12:26:14 -0500

I think taht using the same subnet/prefix simply amounts to having /32 
routes in the edge devices.  Also, there are other known mechanisms 
(L2VPN extension) which achieve that goal.
Having said that, it is a useful goal and one LISP helps with.

I do not see why the routing is any more optimal than any of the other 
tunnel management mechanisms.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Feb 2014 22:32:00 -0800

> This draft seems to expect that IPSec tunnels will be set up by means outside of LISP.  That seems to contravene the premise of LISp that it can operate without needing permanent / pre-established tunnel state.
> 
> Should this be tied to the work Dino described at the last IETF meeting on using LISP to establish encryption for the LISP tunnel?

FYI, my draft on data-plane crypto is coming.

Dino

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Feb 2014 22:33:49 -0800

> Hi Joel,
> This describes how LISP is used today in combination with IPsec (typically GDOI is used to simplify key distribution).

So this is an existing best practice use-case document Fabio?

> I think Dino's work is more forward looking, with two main goals: (1) combine encryption with the LISP dataplane, for a more efficient encoding on the wire, (2) take advantage of the LISP mapping system (and possibly of some of the mechanisms in LISP-SEC) for key derivation/distribution

The goal of my work is to provide data-plane confidentiality and it was suggested by the SAAG that we don't need to use a third party PKI, be it traditional or using the mapping database. So I have a design that takes their recommendations.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Feb 2014 09:12:52 -0500

Viewed as a use case draft, what is there is probably reasonable.  I 
would be inclined to include some indications of the open questions in 
addressing the use case, but that is not mandatory.

Yours,
Joel

On 2/13/14, 4:30 AM, Patrice Bellagamba (pbellaga) wrote:
> Hi Joel, you are right, in this case LISP mobility is used instead of L2
> technics, and there is advantages to this.
> We have seen multiple customers that are not confident with L2 extension,
> especially because it does extend the broadcast domain.
> Here in addition the L3 device that perform LISP xTR in the cloud is
> providing default gateway locally, allowing not to trombone toward the
> enterprise to have intra-cloud routing.
>
> LISP respond to the need 'Route when you can, Bridge when you must'
>
> Thanks, Patrice
>
> On 2/12/14 6:26 PM, "Joel M. Halpern" <[email-masked]> wrote:
>
>>>>>>> http://www.ietf.org/id/draft-freitas-bellagamba-lisp-hybrid-cloud-use
>>>>>>> ca
>>>>>>> se-00.txt
>>>>>>>
>>>>>>>
>>>>>>> We look forward to your comments and for your feedback if we can
>>>>>>> have
>>>>>>> a

---

From: "Patrice Bellagamba (pbellaga)" <[email-masked]>
Date: Thu, 13 Feb 2014 09:26:09 +0000

Hi Joel, thanks to review the draft.

Regarding the IPSec, this is just a transport to encrypt the LISP flow.
We did not described the multiple possibilities to perform the encryption,
but may be we should have.
The main idea, is to have a LISP tunnel between PxTR on Enterprise DC and
xTR on Cloud that allows IP mobility without any iTR on enterprise remote
sites, means no path optimization.
LISP is providing here a great advantage as it allows for subnet extension
on the cloud without the usage of any L2 technic.
.
Now, how we do encrypt this tunnel is of multiple ways.
1) As there is no scale requirement, and as the Enterprise may want to
also have plain routing to the Cloud, one option, which is the only one we
have relied on, is to establish an IPSEC tunnel between the Cloud and the
Enterprise DC, enabling a routing protocol over it and letting it allows
RLOCs to connect over IPSEC.
2) We can also, instead of creating an IPSEC tunnel, just encrypt the LISP
tunnel itself, in transport mode.
3) we can use GDOI to provide the LISP tunnel crypto, but in the case of
Cloud where no scale in term of number of sites is required that may be
optional.

As it is a use case draft, we tried to descibe one option, if you think we
should dig other option, then we will do it for next version.

Patrice

---

From: "Patrice Bellagamba (pbellaga)" <[email-masked]>
Date: Thu, 13 Feb 2014 09:30:42 +0000

Thanks, Patrice

---

From: "Santiago Freitas (safreita)" <[email-masked]>
Date: Mon, 17 Feb 2014 09:38:48 +0000

Hi Joel and Dino, thanks for your review and comments.

Yes, the goal of this draft is to be an existing use-case document, describing how LISP can be used today to enable a Hybrid Cloud extension. To validate the use case and what we described on the draft we have it running in our lab. 

For a version 01 of the draft, I tried to capture the open questions and comments from the feedback provided. 
Below is what I captured, did I miss anything ? Any other points you suggest we include ?

1) Do we need to better capture on the draft the advantages of using LISP mobility instead of Layer 2 extension ? The points Patrice Bellagamba mentioned on his email; 
2) Explicitly document the resulting packet format;
3) More clearly say where the IPsec tunnel is. That is, document that IPsec encapsulate and protect the LISP encapsulated packet on this use case;
4) Since this will certainly be in a multi-tenancy environment, discuss how private IPv4 addresses will be handled and where NAT devices will be deployed. Mention how IPsec or LISP will handle NAT-traversal.

Sorry if this was answered on another email, but I can't find if we received a few minutes to present this use case on the meeting in London. Can you please advise ?

Thanks, Santiago

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: 13 February 2014 14:13
To: Patrice Bellagamba (pbellaga); Yves Hertoghs (yhertogh); Fabio Maino (fmaino); Santiago Freitas (safreita); [email-masked]
Cc: [email-masked]
Subject: Re: Using LISP for Secure Hybrid Cloud Extension  Draft Submitted and Request for slot to present on IETF 89

Viewed as a use case draft, what is there is probably reasonable.  I would be inclined to include some indications of the open questions in addressing the use case, but that is not mandatory.

Yours,
Joel

On 2/13/14, 4:30 AM, Patrice Bellagamba (pbellaga) wrote:
> Hi Joel, you are right, in this case LISP mobility is used instead of 
> L2 technics, and there is advantages to this.
> We have seen multiple customers that are not confident with L2 
> extension, especially because it does extend the broadcast domain.
>> I think taht using the same subnet/prefix simply amounts to having 
>> /32 routes in the edge devices.  Also, there are other known 
>> mechanisms (L2VPN extension) which achieve that goal.
>> I do not see why the routing is any more optimal than any of the 
>> other tunnel management mechanisms.
>>
>> Yours,
>> Joel
>>
>>>> configured IPSec tunnels can be used, then LISP does not provide a 
>>>> lot of advantage.  If it is automated tunnels, there seems to be a 
>>>> need to coordinate the two systems.  What am I missing?
>>>>
>>>> Thanks,
>>>> Joel
>>>>
>>>>> I think Dino's work is more forward looking, with two main goals: 
>>>>> (1) combine encryption with the LISP dataplane, for a more 
>>>>> efficient encoding on the wire, (2) take advantage of the LISP 
>>>>> mapping system (and possibly of some of the mechanisms in 
>>>>> LISP-SEC) for key derivation/distribution
>>>>>
>>>>> Fabio
>>>>>
>>>>>
>>>>>> This draft seems to expect that IPSec tunnels will be set up by 
>>>>>> means outside of LISP.  That seems to contravene the premise of 
>>>>>> LISp that it can operate without needing permanent / 
>>>>>> pre-established tunnel state.
>>>>>>
>>>>>>> Also, we would like request a small slot on the upcoming IETF 89 
>>>>>>> meeting to present an overview of the use case covered on the 
>>>>>>> draft.
>>>>>>>
>>>>>>> have a small slot to present an overview of this draft on IETF 
>>>>>>> 89.
>>>>>>>
>>>>>>> Sincerely,
>>>>>>>
>>>>>>> Patrice and Santiago
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>