Subject: [sfc] NSH Security

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Sep 2017 18:53:52 -0400

One of the Area Directors has suggested that
https://tools.ietf.org/html/draft-mglt-sfc-security-environment-req-02
may be necessary for completion of the NSH work.
While this is not a formal call for adoption, I would like to hear from 
working group members whether they consider that document ready for WG 
adoption.

Thank you,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 19 Sep 2017 01:38:32 +0000

Hi, Joel,

> On Sep 18, 2017, at 6:53 PM, Joel M. Halpern <[email-masked]> wrote:
> 

A small clarification, a bit of an important nuance: I read that a Security AD wrote “I’d like to see” (a Security document published before). I did not necessary read that “may be necessary for completion of the NSH work”.

In any case, my $0.02 say that sfc-security-environment document is important *after* NSH, because it also needs Control Plane and Management Plane for it to make sense as a meta-document, not a micro-document.

> While this is not a formal call for adoption, I would like to hear from working group members whether they consider that document ready for WG adoption.

I still believe this is important work and in real good starting shape.

This is even when there is no explicit deliverable in the SFC contract / charter.

I strongly believe it should not be a pre-req / Normative reference to NSH. It is an SFC-scoped doc.

The sequentiality of the deliverables approved by the IESG is very clear on the charter:

1. Problem Statement: This document will provide a summary of the
…
2. Architecture: This document will provide a description of the SFC
…
3. Generic SFC Encapsulation: This document will describe a single
…

Thanks,

Carlos.

> 
> Thank you,
> Joel
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Sep 2017 08:57:15 -0400

Hi,

I believe this document is important and I am volunteering to move it
forward with the WG.

Yours,
Daniel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 19 Sep 2017 17:55:08 +0000

Carlos, Joel,

> On Sep 18, 2017, at 9:38 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
> Hi, Joel,
> 

PQ> I agree, a security environment draft is orthogonal to the protocol draft — as is has been the case with most (all?) existing protocol standards.  As long as the protocol can be “secured” then the draft is complete.

> In any case, my $0.02 say that sfc-security-environment document is important *after* NSH, because it also needs Control Plane and Management Plane for it to make sense as a meta-document, not a mi…

PQ> Correct, the security environment draft would be more of an informational draft, offering _possible_ guidance, and must address topics that aren’t in NSH (ands should not be)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Sep 2017 14:08:12 -0400

That is my preference.  I am trying to find out how Alia reads 
Kathleen's note in this regard.

Yours,
Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 20 Sep 2017 09:22:15 -0400

Joel et al,

There are some inconsistencies
between draft-mglt-sfc-security-environment-req-02
and draft-ietf-sfc-nsh-21, probably because the former hasn’t been tracking
the updates to the latter. In particular, the former refers to revision -01
of the latter, and there are references to things that no longer exist,
such as the SFP ID. Which means that the NSH encapsulation no longer
satisfies REQ24. As another point, the NSH spec explicitly relies on its
external transport for authentication and integrity (see the last paragraph
of section 7.1), and we should discuss whether this satisfies the various
authentication and integrity requirements in the security draft (and
whether totally relying on the transport layer is sufficient for the NSH
encapsulation). There are probably other inconsistencies as well that I
missed on a first reading. So if we do wish to adopt  the security draft,
we should ask whether it first needs a general update to better match the
current NSH draft. Of course, this would need to happen in any case.

Cheers,
Andy

On Tue, Sep 19, 2017 at 2:08 PM, Joel M. Halpern <[email-masked]>
wrote:

> That is my preference.  I am trying to find out how Alia reads Kathleen's
> note in this regard.
>
> Yours,
> Joel
>
>
>>> A small clarification, a bit of an important nuance: I read that a
>>> Security AD wrote “I’d like to see” (a Security document published before).
>>> I did not necessary read that “may be necessary for completion of the NSH
>>> work”.
>>>
>>>
>> PQ> I agree, a security environment draft is orthogonal to the protocol
>> draft — as is has been the case with most (all?) existing protocol
>> standards.  As long as the protocol can be “secured” then the draft is
>> complete.
>>
>>
>> In any case, my $0.02 say that sfc-security-environment document is
>>> important *after* NSH, because it also needs Control Plane and Management
>>> Plane for it to make sense as a meta-document, not a micro-document.
>>>
>>>
>> PQ> Correct, the security environment draft would be more of an
>> informational draft, offering _possible_ guidance, and must address topics
>> that aren’t in NSH (ands should not be)
>>
>>
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 20 Sep 2017 15:08:36 +0000

Andy,

You raise (at least) a couple of good points.

draft-mglt-sfc-security-environment-req would have to first be updated to catch up to twenty revisions of NSH.

However, it is important to highlight that draft-mglt-sfc-security-environment-req progress is orthogonal to that of draft-ietf-sfc-nsh.

Abstract

   This document provides environment security requirements for the SFC
   architecture.  Environment security requirements are independent of
   the protocols used for SFC - such as NSH for example.

/* This says that:
 1. This is an SFC-level broadly-scoped document, and
 2. draft-mglt-sfc-security-environment-req is independent of NSH
 */

   As a result,
   the requirements provided in this document are intended to provide
   good security practices so SFC can be securely deployed and operated.
   These security requirements are designated as environment security
   requirements as opposed to the protocol security requirements.

/* This points to NSH having protocol security definitions, and
This document being data + control + management + operation focused */

Thanks,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Sep 20, 2017, at 9:22 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Joel et al,

There are some inconsistencies between draft-mglt-sfc-security-environment-req-02 and draft-ietf-sfc-nsh-21, probably because the former hasn’t been tracking the updates to the latter. In particular, the former refers to revision -01 of the latter, and there are references to things that no longer exist, such as the SFP ID. Which means that the NSH encapsulation no longer satisfies REQ24. As another point, the NSH spec explicitly relies on its external transport for authentication and integrity (see the last paragraph of section 7.1), and we should discuss whether this satisfies the various authentication and integrity requirements in the security draft (and whether totally relying on the transport layer is sufficient for the NSH encapsulation). There are probably other inconsistencies as well that I missed on a first reading. So if we do wish to adopt  the security draft, we should ask whether it first needs a general update to better match the current NSH draft. Of course, this would need to happen in any case.

Cheers,
Andy

On Tue, Sep 19, 2017 at 2:08 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
That is my preference.  I am trying to find out how Alia reads Kathleen's note in this regard.

Yours,
Joel

On Sep 18, 2017, at 9:38 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Joel,

On Sep 18, 2017, at 6:53 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: <[email-masked]>
Date: Thu, 21 Sep 2017 06:34:35 +0000

Hi Joel, all, 

I would have a different answer if this question was raised when this draft was first submitted (that is, two years ago). 

But now given the energy that was put recently on the NSH specification to enhance it, I don't think draft-mglt-sfc-security-environment-req is needed for the completion of the NSH document. 

The NSH spec is clear about it applicability (single administrative domain), including calling out measures to prevent leaking privacy and security issues related to manipulating metadata.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
> Envoyé : mardi 19 septembre 2017 00:54
> À : [email-masked]
> Objet : [sfc] NSH Security
>