Subject: [lisp] draft-farinacci-lisp-crypto-01 - Call for WG Adoption

From: Luigi Iannone <[email-masked]>
Date: Thu, 4 Dec 2014 12:27:10 +0100

Hi All,

During the 91st IETF authors of the draft-farinacci-lisp-crypto-01
[https://tools.ietf.org/html/draft-farinacci-lisp-crypto-01] 
asked for WG adoption. Meeting participants expressed consensus on adoption.

This message begins the two weeks call for WG adoption to confirm the meeting outcome. 
The call ends on  December 19th 2014.

Please respond to the LISP mailing list with any statements of approval or disapproval.

Recall that:

- This is not WG Last Call. The document is not final, and the WG is expected to 
  modify the document’s content until there is WG consensus that the content is solid.  
  Therefore, please don’t oppose adoption just because you want to see changes to its content.

- If you have objections to adoption of the document, please state your reasons why, 
  and explain what it would take to address your concerns.

- If you have issues with the content, by all means raise those issues and we can 
  begin a dialog about how best to address them.

Luigi and Joel

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Dec 2014 14:02:55 +0000

I like that you're doing this work so am supportive. I think
it'd be good to try get some security folks to review before
folks get too far in implementations, but I'm not sure when
that'd be. But feel free to hassle me or Kathleen and we can
try get that done when you think it's the right time, i.e.
just before folks start coding or making hard to change design
decisions.

Thanks,
S.

PS: the above is based on the saag presentation Dino did and
a very quick scan of the document, I've not read it in detail
yet.

On 04/12/14 11:27, Luigi Iannone wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 Dec 2014 08:13:07 -0800

> I like that you're doing this work so am supportive. I think

Yes, we have included you guys from the get-go, per Joel's good suggestion. Your expertise was useful to make us understand where the state of the art in cryptography is.

> it'd be good to try get some security folks to review before

Brian Weis have been involved but we will also call on you guys. My plan is to get comments from Brian, wait for the two week period to end, so I can update the draft and change name to draft-ietf-lisp. And then, the first rev of the working group draft will reflect the solicitation of comments from you folks.

> try get that done when you think it's the right time, i.e.

Give us a few weeks and when Brian can get to commenting draft-farinacci-lisp-crypto-01.

> just before folks start coding or making hard to change design

Too late. ;-)  But then again, that is the only way to build a good draft.

> a very quick scan of the document, I've not read it in detail

Right, we are in sync.

Thanks for the support,
Dino

---

From: Fabio Maino <[email-masked]>
Date: Thu, 04 Dec 2014 11:08:44 -0800

I don't support adoption of this document.

The document is proposing an extension of the LISP header to support 
data plane security.  However, there has been quite a lot of discussion 
in various WGs, including LISP, about the need for a more flexible 
overlay encapsulation. Besides support for data plane security, the 
requirements include capability to support non IP payloads, and to 
support metadata for various applications including service chaining  
and policy tags.

I believe that rather than just adding incremental support for data 
plane security, the WG should  have a comprehensive look at how to 
extend the LISP header to address the requirements above. 
draft-lewis-lisp-gpe, that was presented to the WG a few times, tries to 
address all of those requirements.

Extending the semantic of the header to support data plane security, at 
least for HW implementations, comes at about the same cost of addressing 
all of the requirements above. I believe the same is true, to a lesser 
extent, even with SW implementations (at least those that deal with the 
encap in the kernel).

Thanks,
Fabio

---

From: Damien Saucez <[email-masked]>
Date: Thu, 4 Dec 2014 21:04:03 +0100

Hello,

I think that you are both (Dino and Fabio) right somehow.

I am happy to see work towards security and proposals to enable cryptography in
LISP.  So from that point of view I fully support Dino’s proposition.

I also agree with Fabio that the best to secure a system is to completely think
the system with security in mind.  So from that point of view incremental
changes in the protocol is not the ideal.  So I am strongly in favour of
proposing a generalised data-plane and a generalised control-plane for LISP.

The question is then to know how fast we want to have a solution. If we need it
fast, we may pay the price of patching the protocol. If we consider we have time,
then let’s go for a generalisation a-la GPE.

Is backward compatibly an absolute requirement?

Damien Saucez 

On 04 Dec 2014, at 20:08, Fabio Maino <[email-masked]> wrote:

> The document is proposing an extension of the LISP header to support data plane security.  However, there has been quite a lot of discussion in various WGs, including LISP, about the need for a more flexible overlay encapsulation. Besides support for data plane security, the requirements include capability to support non IP payloads, and to support metadata for various applications including service chaining  and policy tags.
> 
> I believe that rather than just adding incremental support for data plane security, the WG should  have a comprehensive look at how to extend the LISP header to address the requirements above. draft-lewis-lisp-gpe, that was presented to the WG a few times, tries to address all of those requirements.
> 
> Extending the semantic of the header to support data plane security, at least for HW implementations, comes at about the same cost of addressing all of the requirements above. I believe the same is true, to a lesser extent, even with SW implementations (at least those that deal with the encap in the kernel).
> 
> Thanks,
> Fabio
> 
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 Dec 2014 13:30:43 -0800

Do you support the control-plane mechanisms in the draft?

The advantage of having more bits for encryption is that we can have more data-plane keys. With the current lisp-crypto proposal, we only have 3 keys-ids.

But I would use caution here, because the state of the art in data-plane encapsulations is all over the place. And while generalization is nice, it often isn't practical. And what results in the marketplace is a subset of options being delivered in a general design that brings you back to the same result of having a specific format that would need to change later.

Dino

> On Dec 4, 2014, at 11:08 AM, Fabio Maino <[email-masked]> wrote:
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Dec 2014 21:54:29 +0000

On 04/12/14 16:13, Dino Farinacci wrote:
> Yes, we have included you guys from the get-go, per Joel's good
> suggestion. Your expertise was useful to make us understand where the
> state of the art in cryptography is.
> 
> Brian Weis have been involved but we will also call on you guys. My
> plan is to get comments from Brian, wait for the two week period to
> end, so I can update the draft and change name to draft-ietf-lisp.
> And then, the first rev of the working group draft will reflect the
> solicitation of comments from you folks.
> 
>> folks get too far in implementations, but I'm not sure when that'd
>> be. But feel free to hassle me or Kathleen and we can try get that
>> done when you think it's the right time, i.e.
> 

Sorry not sure what you mean by "too late"? If you mean you've
written early code, that's great. If you mean that it's too
late to get any significant changes compared to this -01 then
that'd not be at all ok.

And to be clear, by "significant change," I don't mean changing
from say DH to RSA key transport which'd be a bad plan, but more
like whether integer or ECDH ought be first up, whether to wait
on CFRG for new curves, maybe ways of encoding crypto parameters
etc. Those kinds of change ought be possible at this point IMO
(if the WG have rough consensus for 'em of course.)

S.

> 
>> Thanks, S.
>> 
>> PS: the above is based on the saag presentation Dino did and a very
>> quick scan of the document, I've not read it in detail yet.
> 
> Right, we are in sync.
> 
> Thanks for the support, Dino
> 
>> 
>>> This message begins the two weeks call for WG adoption to confirm
>>> the meeting outcome. The call ends on  December 19th 2014.
>>> 
>>> - This is not WG Last Call. The document is not final, and the WG
>>> is expected to modify the document’s content until there is WG
>>> consensus that the content is solid. Therefore, please don’t
>>> oppose adoption just because you want to see changes to its
>>> content.
>>> 
>>> - If you have objections to adoption of the document, please
>>> state your reasons why, and explain what it would take to address
>>> your concerns.
>>> 
>>> - If you have issues with the content, by all means raise those
>>> issues and we can begin a dialog about how best to address them.
>>> 
>>> 
>>> Luigi and Joel
>>> 
>>> _______________________________________________ lisp mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>>> 
>> 
>> _______________________________________________ lisp mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
> 
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 4 Dec 2014 16:33:23 -0800

> written early code, that's great. If you mean that it's too

That's what I mean.

> late to get any significant changes compared to this -01 then

No, we are still experimenting and proving.

> (if the WG have rough consensus for 'em of course.)

Agree and expect that to happen.

Thanks,
Dino

---

From: Fabio Maino <[email-masked]>
Date: Fri, 05 Dec 2014 08:26:30 -0800

Hi Dino,
I have no problems with the control plane part. An encap with 
multiprotocol support would allow to do IPsec encap before LISP encap, 
and could be used with the unauthenticated DH mechanism that you propose.

I do really think that the LISP WG should not miss the encap debate, and 
drive the transition to a format that lends itself to the various use 
cases that are being envisioned (and that IMO should become the main 
focus of the WG asap). There's quite a broad support behind VXLAN-GPE, 
and LISP-GPE is an opportunity for LISP to capitalize on that support 
and maintain some backward compatibility with the current LISP encap and 
features.

Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 5 Dec 2014 09:36:38 -0800

> Hi Dino,
> I have no problems with the control plane part. An encap with multiprotocol support would allow to do IPsec encap before LISP encap, and could be used with the unauthenticated DH mechanism that you propose.

Well draft-farinacci-lisp-crypto-01 with LISP-SEC can give you an authenticated DH mechanism as well.

> I do really think that the LISP WG should not miss the encap debate, and drive the transition to a format that 

Well I think we should monitor it but also not get distracted by it. 

The LISP WG has a control-plane that others may use. We should create laser focus on control-plane features and scale. The latter being most important.

> lends itself to the various use cases that are being envisioned (and that IMO should become the main focus of the WG asap). There's quite a broad support behind VXLAN-GPE, and LISP-GPE is an opportunity for LISP to 

There is broad support among other data center encapsulations as well. The point is being focused mostly on data center and not holistically.

> capitalize on that support and maintain some backward compatibility with the current LISP encap and features.

The marketplace is confused about overlays right now in the data center. It is the vendors that are confusing matters by having (1) so many data-planes that can't interoperate in a multi-vendor network, and (2) coupled with separate and vertical control-planes that also don't interoperate with each other.

The risk is that operators may give up on overlays because the vendor community is all over the place. Or simply just roll their own with properitary SDN controller solutions.

Dino

---

From: Fabio Maino <[email-masked]>
Date: Fri, 05 Dec 2014 13:45:28 -0800

> Well draft-farinacci-lisp-crypto-01 with LISP-SEC can give you an authenticated DH mechanism as well.

yes, but the DH mechanism itself is unauthenticated.

> The LISP WG has a control-plane that others may use. We should create laser focus on control-plane features and scale. The latter being most important.

agree: focus on CP scale and flexibility, as LISP may play a role in 
interconnecting the different controlling domains you mention below.

> The marketplace is confused about overlays right now in the data center. It is the vendors that are confusing matters by having (1) so many data-planes that can't interoperate in a multi-vendor net…

That's where LISP (and GPE IMO) can play a role: we have already seen 
vendors (unfortunately) proposing the use of VXLAN outside of the DC. 
The capability that people would like to see on top of VXLAN (or other 
overlays) for the DC are not very different from what would be needed 
outside of the DC. LISP is possibly one of the largest deployed overlay 
outside of DC today: this group should drive the extension of the encap 
(as well as of the control plane, if needed) to address various LISP use 
cases.

I think that's why many of us have kept bringing use cases to the 
attention of the WG, and would like to see the group focusing on that now.

> The risk is that operators may give up on overlays because the vendor community is all over the place. Or simply just roll their own with properitary SDN controller solutions.

In my experience when customers see the benefit of overlays (LISP in my 
case) they tend jump on it... but you know this way better than me :-) 
It's our responsibility as a WG to clear up the confusion about 
encapsulations.

Fabio

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 05 Dec 2014 22:08:32 +0000

On 05/12/14 21:45, Fabio Maino wrote:
>>> multiprotocol support would allow to do IPsec encap before LISP
>>> encap, and could be used with the unauthenticated DH mechanism that
>>> you propose.

There is no problem in figuring out a way to bind a DH and
an authentication exchange. That's been done many times in
different protocols.

S.

---

From: Fabio Maino <[email-masked]>
Date: Fri, 05 Dec 2014 14:52:42 -0800

> an authentication exchange. That's been done many times in

Absolutely, and LISP-SEC is indeed one of the way to do it.

Fabio

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 5 Dec 2014 16:21:12 -0800

And since the key material is in an RLOC-record which is covered by LISP-sec authentication, we are covered. 

Dino

> On Dec 5, 2014, at 2:52 PM, Fabio Maino <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 5 Dec 2014 19:06:47 -0800

> extension of the encap (as well as of the control plane, if needed) to address various LISP use cases.

I do like to see a list of requirements that requires changes to LISP encapsulation. 

LISP-GPE adds no new functionality. NSH can be done without packet encapsulation from any overlay protocol. 

> In my experience when customers see the benefit of overlays (LISP in my case) they tend jump on it... but you know this way better than me :-) It's our responsibility as a WG to clear up the confusion about encapsulations.

Well adding new encapsulation to the mix doesn't clear up confusion. It adds to it. 

Dino

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 8 Dec 2014 11:29:05 +0100

> Please respond to the LISP mailing list with any statements of approval or disapproval.

I support the adoption of this document as a WG item.

-- 

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

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 10 Dec 2014 10:33:01 -0800

Hello Dino,

you mentioned in another email

> The LISP WG has a control-plane that others may use. We should create laser 
focus on
> control-plane features and scale. The latter being most important.

I like the ideas in your crypto draft but the data header aspect ... could 
you change this to a set of requirements your draft has for the data header 
and drop the explicit header layout instead?

This would give the draft the focus on the control plane and we keep the 
details of the data header open.

Thanks & Regards,
Marc

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 10 Dec 2014 10:33:01 -0800

> details of the data header open.

Well I think that would create an incomplete draft. How about I keep it in and indicate there are other ways to pass a key-id with other encapsulation formats?

Thanks for your comments,
Dino

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 14 Dec 2014 15:06:52 +0100

Hi All,

It is nice that the crypto document has raised some comments, however, as I mentioned in the first mail, the document is not final and the WG is expected to work on it, which may include the discussion about the header format.

Yet, we are not chartered to modify the LISP header. If you want that work to happen let’s make progress on what we have committed to finish.

Beside the crypto document there is a call for adoption for the impact document and a WG last call for the EID block management guidelines.

Both of those documents received little or no comments on the mailing list!!!

If you want to move forward and work on other things please help the WG make progress.

There is a week until the calls are over.

Silence is not consensus!

ciao

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Dec 2014 15:21:53 -0800

> Beside the crypto document there is a call for adoption for the impact document and a WG last call for the EID block management guidelines.

I just went through draft-saucez-lisp-impact-07.txt. Section 3 has some really good research and is explained well to understand the conclusion of the research. I applaud the authors for that.

A comment or request for a reference, since you are talking about multicast replication engineering here you may want to add lisp-te as a reference here:

>    Even though it is its main goal, LISP is more than just a scalability
>    solution, it is also a tool to provide both incoming and outgoing
>    traffic engineering [S11], can be used as an IPv6 transition at the
>    routing level, and for inter-domain multicast [RFC6831],
>    [I-D.coras-lisp-re]. 

You should also add to this:

> [I-D.coras-lisp-re] and [CDM12] propose a technique to construct xTR
>    based inter-domain multicast distribution trees.

That there are signaling approaches like you indicated in RFC6831 as well as using LISP to signal in a reference to lisp-mr-signalling as well as using a signal-free approach as in lisp-signal-free-multicast. Those references would prove useful to readers.

Other than that, this is a really well written document and ready for next step IMO.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Tue, 16 Dec 2014 09:58:28 +0100

Thank you, we will had this to the new version. Florin is already on the beef :)

Damien Saucez

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 22 Dec 2014 16:15:03 +0100

Hi All,

the two weeks WG Adoption Call is now over for draft-farinacci-lisp-crypto-01.

From the exchange on the mailing list we gather that there is consensus on the crypto mechanism itself, but more work is needed on the header encoding.

Hence, the document is adopted as WG item, but authors are encouraged to contact who raised concerns about the header encoding so to work together at a viable solution.

Thanks all for the work done.

Luigi 

> On 04 Dec 2014, at 12:27, Luigi Iannone <[email-masked]> wrote:
> 
> Hi All,
>