Subject: Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Mar 2022 02:58:34 -0700

Hi Yuehua,

My apologies for not replying until now.  I think I saw the updated
versions of the draft and did not notice that there were still some active
topics in the email thread (not reflected in the draft yet).

On Fri, Dec 03, 2021 at 05:30:53PM +0800, [email-masked] wrote:
> Dear Ben,
> Thank you. please see the commet resolution inline with Yuehua>>
> 
> To Martin,  I really appreciate if you could provide comments to Yuehua-2 and Yuehau-6. 
> 
> Best Regards,
> Yuehua Wei
> ZTE Corporation
> ------------------原始邮件------------------
> 发件人：BenjaminKadukviaDatatracker
> 收件人：The IESG;
> 抄送人：[email-masked];[email-masked];[email-masked];[email-masked];
> 日 期 ：2021年11月30日 02:59
> 主 题 ：[sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-sfc-nsh-tlv-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (1) RFC 8300 is pretty clear that "Metadata privacy and security
> considerations are a matter for the documents that define metadata
> format."  Some of the metadata context headers defined in this document
> clearly have privacy considerations that need to be documented (e.g.,
> policy ID and source/destination group serve to concretely identify
> flows that are related in some way), though some may not have much that
> needs documenting (e.g., the forwarding context metadata seems to just
> be extracting out information that is already present in the packet
> being wrapped).  Regardless, we need to have some discussion of the
> privacy and security considerations of the new metadata context headers,
> even if that is just "no new considerations" for some of them.
> 
> Yuehua-1>>Thank you, I update the section to ver10 per you, Stig and John's comments.  please take a look and provide further comments

Unfortunately, I don't think that even the text in the -13 is providing
what is needed here.  (It is good text to have, but is generic to attacks
on context headers in general, and authentication of context headers in
general.)  My expectation is that for each of the seven context headers
that this document defines, we take a careful look at them in turn and
document any privacy and/or security considerations that apply to the
information carried in that specific context header.  (In some cases we may
also have to consider the encoding used, in addition to the information
content, but I do not remember that being relevant here.)  This could, for
example, take the form of a table or list that covers each context header
in turn.  (If, after having done the work, it ends up being a list of
mostly "no special considerations", we might consider formatting it
differently, but we definitely need to do the analysis on each context
header in turn.)

> (2) I think we need to discuss the Flow ID context header further.  Is
> it intended to just be a container to hold a flow identifier already
> present in the contained packet (such as the IPv6 Flow Label or MPLS
> Entropy Label that are called out), or can it also be used to apply a
> new flow identifier at the SFC layer?
> 
> The named examples of a flow ID are both 20 bits long; if that is an
> exhaustive listing, shouldn't we update the figure accordingly (to
> include Length=3, four leading bits of padding, and a trailing byte of
> padding)?  If that is not an exhaustive listing and longer flow
> identifiers are expected, how do we know what length of flow identifier
> is being conveyed?
> 
> Yuehua-2>>You raised a good question. I prefer to add Context Type (CT) to distinguish different flow IDs. I'd appreciate your advice.

An explicit Context Type to indicate the specific Flow ID used seems like
it will be very helpful for extensibility.  That would also allow each
context type to specify how long in bits the useful Flow ID value is, since
the NSH metadata framing only gives a length in bytes.  If there was no
in-band context type, a recipient would have to rely on out-of-band
configuration to know how much padding is present, which is not very
interoperable.

> (3) If we are to allow for specifying the "logical grouping of source and/or
> destination objects" in §4.6 (emphasis on "and/or"), but the context
> header always conveys both a source group and dest group field, do we
> need to reserve a dedicated value for "no group information specified"?
> 
> Yuehua-3>>Very good observation. Shall we state that if there is   "no group information specified" for the source or dest field, the field MUST be sent as zero and ignored on receipt

Yes, please!

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1
> 
> This document does not address metadata usage, updating/chaining of
> metadata, or other SFP functions.  Those topics are described in
> [RFC8300].
> 
> I'm not entirely sure what is meant by "chaining of metadata" (unless
> it's just a synonym for "updating of metadata"?), and having reviewed
> all 18 instances of "chain" and 88 instances of "metadata" in RFC 8300,
> I am not sure which part you're intending to refer to by it.  Could you
> please point to a more specific part of RFC 8300 (at least in this email
> thread for now, not necessarily in a document update)?
> 
> Yuehua-4>> RFC8300 doesn't use “chain”to discribe multiple metadata.
> it mentions "If multiple mandatory-to-process Context Headers are required for a   given SFP" and "If multiple instances of the same metadata are included in an NSH   packet" in RFC8300 section 2.5.1
> Further comments are welcome

Mostly my comment here is that I don't know what you mean by "chaining of
metadata".  If it's just that there might be interdependencies or relations
between two pieces of metadata in the same packet, we could clarify the
text in one way; if it's relating to updating (modifying) a given piece of
metadata along the path of the packet, we would do something else; etc.

> 
> Section 4.1
> 
> I suggest putting a context (forgive the pun) indicator in the figure
> legends, e.g., "Figure 4: Forwarding Context - 2 (QinQ)".  The
> information is already available elsewhere, but having it in the caption
> helps focus the reader on the important/relevant part of the figure.
> 
> Yuehua-5>> Accepted, will update to ver10

Thanks!

-Ben

> Section 4.3
> 
> It might be interesting to say something about when the SPI itself
> suffices to identify the ingress node vs. when this metadata context
> header is needed.
> 
> Node ID: Represents an opaque value of the ingress network node
> ID.  The structure and semantics of this field are deployment
> specific.  For example, Node ID may be a 4 bytes IPv4 address Node
> ID, or a 16 bytes IPv6 address Node ID, or a 6 bytes MAC address,
> or 8 bytes MAC address (EUI-64), etc,.
> 
> There seems to be some dissonance between saying this field is "an
> opaque value" and also saying that it might be an IP or MAC address.  In
> the vein of Francesca's Discuss point, I don't think we can have
> interoperability if the NSH implementation is expected to process this
> as IP/MAC address information (as opposed to just an opaque identifier).
> 
> Yuehua-6>> it has relation to 
> 
> Section 8.2
> 
> URLs for [GROUPBASEDPOLICY] and [GROUPPOLICY] would be helpful.
> Yuehua-7>> Accepted, will fix the problem to ver10
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 28 Mar 2022 16:04:42 +0000

Thank you Ben for this discussion — please see inline.

On Mar 21, 2022, at 5:58 AM, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Yuehua,

On Fri, Dec 03, 2021 at 05:30:53PM +0800, [email-masked]<mailto:[email-masked]> wrote:
Dear Ben,
Thank you. please see the commet resolution inline with Yuehua>>

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------
抄送人：[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;

This is a good point indeed. First, we can always make more explicit the advice and requirements from rfc8300, and also rfc7665. The context is the SFC-Enabled domain (S4.4 of rfc7665).

Looking at the seven context headers, as you highlight, policy ID and source/destination group serve are the most relevant for this discussion. In those two,  the information elements are opaque values, which is inline with S8.2.2 of rfc8300 (NSH metadata heading, fifth paragraph).

Is perhaps expanding and clearly writing down text aligned with these two paragraphs inline with your expectations?

Thanks!

Carlos.

Yes, please!

Section 1

Section 4.1

Thanks!

-Ben

Section 4.3

Section 8.2

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

---

From: <[email-masked]>
Date: Tue, 29 Mar 2022 06:44:29 +0000

Hi Carlos, all,

(restricting the discussion to the list)

Ben has stepped down as AD. I guess the DISCUSS will be inherited by Paul.

To fix this DISCUSS, I reiterate the proposal I made at: https://mailarchive.ietf.org/arch/msg/sfc/Fe5k0jVmYpoo7-8gZQ7Xu2nbxqA/

==
The POLICY_ID and Tenant ID are likely to trigger similar discussion (at least by the IESG) as what is documented for Performance Policy Identification and Subscriber ID in draft-ietf-sfc-serviceid-header. The authors may grab whatever text recorded there, as appropriate.
==

The experience we had with other documents is that pointing to the discussion in 8300 is not sufficient. I suggest we leverage the text in RFC8979, either by copy-paste the relevant text or just adding a statement that similar considerations apply for the TLV draft.

Thank you.

Cheers,
Med

De : sfc <[email-masked]> De la part de Carlos Pignataro (cpignata)
Envoyé : lundi 28 mars 2022 18:05
À : Benjamin Kaduk <[email-masked]>
Cc : [email-masked]; Greg Mirsky <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; Martin Vigoureux <[email-masked]>
Objet : Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)

Hi Yuehua,

Dear Ben,

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------

Thanks!

Carlos.

Yes, please!

Section 1

Section 4.1

Thanks!

-Ben

Section 4.3

Section 8.2

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 30 Mar 2022 17:49:38 +0000

Thank you Med! Useful insight.

Which specific paragraphs or approaches from RFC 8979 do you think will be most useful?

I can see the last paragraph of the Intro for example, and para 4-5 of the Security Considerations?

Thanks!

Carlos.

On Mar 29, 2022, at 2:44 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Carlos, all,

To fix this DISCUSS, I reiterate the proposal I made at:https://mailarchive.ietf.org/arch/msg/sfc/Fe5k0jVmYpoo7-8gZQ7Xu2nbxqA/

==

Thank you.

Cheers,
Med

De : sfc <[email-masked]<mailto:[email-masked]>> De la part de Carlos Pignataro (cpignata)
Envoyé : lundi 28 mars 2022 18:05
À : Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Martin Vigoureux <[email-masked]<mailto:[email-masked]>>
Objet : Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)

Hi Yuehua,

Dear Ben,

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------

Thanks!

Carlos.

Yes, please!

Section 1

Section 4.1

Thanks!

-Ben

Section 4.3

Section 8.2

---

From: <[email-masked]>
Date: Thu, 31 Mar 2022 05:56:13 +0000

Hi Carlos,

I would add the first three paras in addition to para 4.

In reference to para 5, please note that the current spec does not call explicitly if multiple instances are allowed. As such the following behavior from 8300 will be followed:

   If multiple instances of the same metadata are included in an NSH
   packet, but the definition of that Context Header does not allow for
   it, the SFC-aware SF MUST process the first instance and ignore
   subsequent instances.  The SFC-aware SF MAY log or increase a counter
   for this event.

If you want to avoid the default behavior and allow for multiple instances for tenant ID for example, some text is needed in the core text. Then, add para 5 under sec cons.

Also, I would add para 7 (more relevant for tenant ID) and 8.

Cheers,
Med

De : Carlos Pignataro (cpignata) <[email-masked]>
Envoyé : mercredi 30 mars 2022 19:50
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)

Thanks!

Carlos.

Hi Carlos, all,

==

Thank you.

Cheers,
Med

Hi Yuehua,

Dear Ben,

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------

Thanks!

Carlos.

Yes, please!

Section 1

Section 4.1

Thanks!

-Ben

Section 4.3

Section 8.2

Thank you.