Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 10 Nov 2016 13:22:24 +0000

Dear SFC WG:

Given the recent discussion on the mailing list, updated text (with changes in RED) as follows:

NEW for section 3.4:
This specification does not make any assumption about the content placed in the mandatory context field of the NSH header, and does not describe the structure or meaning of the included metadata.

An SFC-aware SF MUST receive the data semantics first in order to process the data placed in the mandatory context field.  The data semantics include both the allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of this specification.

Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use of metadata but has not yet received the data semantics for the mandatory context field, it MUST NOT process the packet, it SHOULD log this error, and MUST apply rate limiting to any logging.

[dcalloc] and [broadalloc] provide sample examples to associate a meaning with the data conveyed in the mandatory context field.

NEW for end of section 3.5.1:
This specification does not make any assumption about TLVs that are mandatory-to-implement or those that are mandatory-to-process.  These considerations are deployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with their scoping (See Section 3.3.3 of [I-D.ietf-sfc-control-plane]).

Upon receipt of a packet that belong to a given SFP, if a mandatory-to-process TLV is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log this error.

If multiple mandatory-to-process TLVs are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these TLVs.  If no instructions are provided, the SFC-aware SF MUST process these TLVs in the order theyappear in the NSH packet.

If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet, it SHOULD log this error, and MUST apply rate limiting to any logging.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Jim Guichard <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 8, 2016 at 1:01 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

After much discussion on the list with regard to ticket #21 the following text has been proposed to help clarify metadata semantics and so forth. Please review and indicate support (or not) so that the chairs can determine consensus and update the ticket accordingly.

Thank you!

Jim & Joel

##########

NEW for section 3.4:
This specification does not make any assumption about the content placed in the mandatory context field of the NSH header, and does not describe the structure or meaning of the included metadata.

An SFC-aware SF MUST receive the data semantics first in order to process the data placed in the mandatory context field.  The data semantics include both the allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of this specification.

Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use of metadata but has not yet received the data semantics for the mandatory context field, it MUST NOT process the packet and MUST log this error.

[dcalloc] and [broadalloc] provide sample examples to associate a meaning with the data conveyed in the mandatory context field.

NEW for end of section 3.5.1:
This specification does not make any assumption about TLVs that are mandatory-to-implement or those that are mandatory-to-process.  These considerations are deployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with their scoping (See Section 3.3.3 of [I-D.ietf-sfc-control-plane]).

Upon receipt of a packet that belong to a given SFP, if a mandatory-to-process TLV is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log this error.

If multiple mandatory-to-process TLVs are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these TLVs.  If no instructions are provided, the SFC-aware SF MUST process these TLVs in the order theyappear in the NSH packet.

If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log this error.

---

From: <[email-masked]>
Date: Thu, 10 Nov 2016 13:28:10 +0000

Hi Jim,

I disagree with the change in RED for the reasons I clarified in a previous emails.

==

I do prefer the "MUST log .." wording because it is critical to detect when a mandatory piece is missing to deliver the service.

The proposed text is about SFC-aware SFs. If the attack vector is a DoS, it is likely that the border nodes/classifiers will be the first victims. Implementing measures to protect against DoS at the boundaries would be a first guard.

If the DoS is from within the SFC domain, despite this is a valid threat vector and misbehaving nodes may happen (software bugs, etc.), I thought the security model of NSH assumes that all involved nodes are trusted.
==

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : jeudi 10 novembre 2016 14:22
À : [email-masked]
Objet : Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 10 Nov 2016 13:28:14 +0000

Dear SFC WG:

Apologies, it was pointed out to me that I missed adding the text at a third location. Correct text as follows:

NEW for section 3.4:

Upon receipt of a packet that belong to a given SFP, if a mandatory-to-process TLV is missing in that packet, the SFC-aware SF MUST NOT process the packet, it SHOULD log this error, and MUST apply rate limiting to any logging.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Jim Guichard <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 10, 2016 at 8:22 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: Dave Dolson <[email-masked]>
Date: Thu, 10 Nov 2016 14:49:03 +0000

Jim,
I agree with this wording.
This allows the implementer to choose an approach that does not overwhelm the device when the system is configured improperly.

If it were “MUST”, I would expect more details about what exactly should be logged. Otherwise, how could one test compliance?

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, November 10, 2016 8:28 AM
To: [email-masked]
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: <[email-masked]>
Date: Thu, 10 Nov 2016 15:02:00 +0000

Hi Dave,

The implementation must definitely log the error: that is, there is a missing mandatory metadata for a chain. It does not need to add an entry per packet as was rightfully mentioned by Ron.

How to protect an implementation from misconfiguration is not specific to the logging feature, but it is a genetic concern IMHO.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : jeudi 10 novembre 2016 15:49
À : Jim Guichard (jguichar); [email-masked]
Objet : Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Jim,

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Thursday, November 10, 2016 8:28 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: Dave Dolson <[email-masked]>
Date: Thu, 10 Nov 2016 15:11:27 +0000

So you would say, “MUST log at least once per type of missing mandatory metadata” ?

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 10, 2016 10:02 AM
To: Dave Dolson; Jim Guichard (jguichar); [email-masked]
Subject: RE: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Hi Dave,

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : jeudi 10 novembre 2016 15:49
À : Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Jim,

-Dave

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: <[email-masked]>
Date: Thu, 10 Nov 2016 15:20:51 +0000

Re-,

I would say: “MUST log at least once per SFP for which a mandatory metadata is missing”.

Better?

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : jeudi 10 novembre 2016 16:11
À : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); [email-masked]
Objet : Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, November 10, 2016 10:02 AM
To: Dave Dolson; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Hi Dave,

Cheers,
Med

Jim,

-Dave

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 10 Nov 2016 15:22:53 +0000

Jim,

I'm fine with this, strikes the balance between guidance and implementation reality.

Paul

On Nov 10, 2016, at 8:28 AM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log this error.
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Nov 2016 17:09:22 +0000

In favor of Med’s text.  How about : MUST log at least once per the SPI for which a mandatory metadata is missing.

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, November 10, 2016 9:21 AM
To: Dave Dolson; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Re-,

Better?

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : jeudi 10 novembre 2016 16:11
À : BOUCADAIR Mohamed IMT/OLN; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Hi Dave,

Cheers,
Med

Jim,

-Dave

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: <[email-masked]>
Date: Tue, 22 Nov 2016 09:41:10 +0000

Hi Lucy,

Works for me. Thanks.

Cheers,
Med

De : Lucy yong [mailto:[email-masked]]
Envoyé : jeudi 10 novembre 2016 18:09
À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Jim Guichard (jguichar); [email-masked]
Objet : RE: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, November 10, 2016 9:21 AM
To: Dave Dolson; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Re-,

Better?

Cheers,
Med

Hi Dave,

Cheers,
Med

Jim,

-Dave

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

NEW for section 3.4:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4: