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

[Benjamin Kaduk <[e-mail]>]

Hi Martin,

In short: yes.
I only just now got a chance to look over what 8979 says specifically.  Key
points relevant for us include:

- many of these carry opaque data (from the NSH perspective) but some
  structure within the opaque data will be easy to infer for many of the
  cases.  8979 goes on to recommend indirect and non-persistent
  identifiers, which doesn't quite directly apply to all of what we cover
  here.  It might be part of our advice, though.

- I think we should also say something about how the presence of multiple
  TLVs in the same NSH allows for inferences to be made that bind those
  pieces of information together.  The 8979 text is pretty specific to
  tracking the subscriber specifically, and so we'd need to add a lot of
  our own new text, but we could talk about things like binding the flow ID
  or source/destination groups to the tenant or ingress network
  information.  Since both flow ID and source/destination group information
  would likely appear in non-NSH locations, being able to bind the
  different pieces of information together would provide advantage to the
  attacker in non-NSH protocol layers.

- the paragraph that starts "If no secure transport encapsulation is
  enabled" seems to transfer pretty well to this situation and should be a
  good starting point for us as well.

-Ben

On Thu, Dec 02, 2021 at 01:30:57PM +0100, Martin Vigoureux wrote:
> Hi Ben,
> 
> thank you for your review.
> Top posting since I'm only replying to point 1: do you think borrowing 
> text/ideas from rfc8979 could help here?
> 
> Thank you
> 
> -m
> 
> Le 2021-11-29 à 19:59, Benjamin Kaduk via Datatracker a écrit :
> > 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.
> > 
> > (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?
> > 
> > (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"?
> > 
> > 
> > ----------------------------------------------------------------------
> > 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)?
> > 
> > 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.
> > 
> > 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).
> > 
> > Section 8.2
> > 
> > URLs for [GROUPBASEDPOLICY] and [GROUPPOLICY] would be helpful.
> > 
> > 
> > 
> >