Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Med,

Also inline (though not too much left to say)...

On Wed, Nov 04, 2020 at 09:39:44AM +0000, [e-mail] wrote:
> Hi Ben, 
> 
> Thanks for the detailed review. 
> 
> Starting with the "COMMENT" part. The DISCUSS will be in a separate message. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> > Envoyé : mercredi 4 novembre 2020 05:37
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; [e-mail];
> > [e-mail]; Greg Mirsky <[e-mail]>;
> > [e-mail]
> > Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-
> > 12: (with DISCUSS and COMMENT)
> 
> [...]
> 
> > --------------------------------------------------------------------
> > --
> > COMMENT:
> > --------------------------------------------------------------------
> > --
> > 
> > I am preparing a significant number of (hopefully) editorial
> > suggestions in a local copy of the XML source; I plan to send that
> > as a diff to the authors as a response to the ballot mail.
> > 
> 
> [Med] Thanks. Already fixed in the local copy. 
> 
> > Section 1
> > 
> >    This document does not make any assumption about the structure of
> >    subscriber or performance policy identifiers; each such
> > identifier is
> >    treated as an opaque value.  The semantics and validation of
> > these
> >    identifiers are policies local to an SFC-enabled domain.  This
> >    document focuses on the data plane behaviour.  Control plane
> >    considerations are out of the scope.
> > 
> > (Control plane considerations probably touch on the privacy
> > properties of the system as a whole, but I think I understand the
> > point being made
> > here.)
> 
> [Med] ACK.
> 
> > 
> > Section 3
> > 
> >    The classifier and NSH-aware SFs MAY inject or strip a Subscriber
> >    Identifier Context Header as a function of a local policy.  In
> > order
> >    to prevent interoperability issues, the type and format of the
> >    identifiers to be injected in a Subscriber Identifier Context
> > Header
> >    should be configured to nodes authorized to inject and consume
> > such
> >    headers.  [...]
> > 
> > I think this is more of a "needs to" rather than a "should".
> 
> [Med] "Should" is used to accommodate deployments where "default format" are mandated by design (or RFPs). 

So then it is "configured" as part of the design? ;)

> > 
> >              For example, a node can be instructed to insert such
> > data
> >    following a type/set scheme (e.g., node X should inject
> > subscriber ID
> >    type Y).  Other schemes may be envisaged.
> > 
> > Just to check my understanding, the fact that it was node X that
> > injected a given subscriber ID context header is determined from the
> > SPI, since the SPI uniquely identifies the SFP?
> 
> [Med] Yes. 
> 
> > 
> >    Failures to inject such headers should be logged locally while a
> >    notification alarm may be sent to a Control Element.  The details
> > of
> >    sending notification alarms (i.e., the parameters affecting the
> >    transmission of the notification alarms depend on the information
> > in
> >    the Context Header such as frequency, thresholds, and content of
> > the
> >    alarm (full header, timestamp, etc.)) should be configurable.
> > 
> > While this is purely an editorial remark (and I will be including a
> > proposal in my editorial diff), I did want to note that I can't
> > actually parse how the (outer) parenthetical is supposed to apply,
> > and expect that my suggestion is going to change the meaning
> > somehow.
> 
> [Med] Reading your proposed edit, I confirm that you got it well. 
> 
> > 
> >    This document adheres to the recommendations in [RFC8300] for
> >    handling the Context Headers at both ingress and egress SFC
> > boundary
> >    nodes (i.e., to strip such Context Headers).  Revealing any
> > personal
> >    and subscriber-related information to third parties is avoided by
> >    design to prevent privacy breaches in terms of user tracking.
> > 
> > I think s/third parties/parties outside the administrative domain/
> > may be more accurate.
> 
> [Med] Went with "parties outside the SFC-enabled domain".
> 
> > 
> > I would also end the last sentence after "design" and split the
> > remaining portion into a new sentence: "Accordingly, the scope for
> > privacy breaches and user tracking is limited to within the
> > administrative domain where the NSH is used".
> 
> [Med] OK. 
> 
> > 
> >    if the NSH-aware SF is instructed to do so.  For example, an SF
> > that
> >    expects an internal IP address as subscriber identifier will
> > discard
> >    Subscriber Identifier Context Headers conveying Mobile Subscriber
> >    ISDN Number (MSISDN), International Mobile Subscriber Identity
> >    (IMSI), or malformed IP addresses.
> > 
> > There's a little bit of cognitive dissonance here in that we say
> > that the content of the context header is opaque, yet are giving a
> > list of things that would involve peeking inside that opacity (and
> > possibly some additional structure to identify the type).  (No
> > specific action requested here, just making an observation.)
> 
> [Med] These examples make it easy to understand why we allow for more IDs in the same message. It is less evident with abstract examples. 
> 
> > 
> > Section 4
> > 
> >    instance selection, or policy selection at SFs.  Note that the
> > use of
> >    the Performance Policy Identifier is not helpful if the path
> >    computation is centralized and a strict SFP is presented as local
> >    policy to SF Forwarders (SFFs).
> > 
> > I'm not sure I understand why this is the case; wouldn't the
> > performance policy information still be useful for, e.g., not
> > dropping UHR packets when buffers are full, regardless of whether
> > the SFP is strict or not?
> 
> [Med] The text is about path computation and selection. 
> 
> We are not using for marking because otherwise we will have the "usual" comments why not using flow lable, dscp marking, etc. 

Ah, it sounds like I was misunderstanding things originally.  Based you
your explanation here, it seems like the policy information is only
intended to be used in path computation/selection, but it needs to be
conveyed in the NSH because there is opportunity for reclassification along
the SFP (and, IIRC, cases where the SFP is not fully specified at
classification time and a local SFF makes a choice on a per-packet basis),
which would still need the policy information as input.
The particular local behaviors such as preferred processing for ULL or UHR
are controlled by the normal mechanisms for doing so, e.g., DSCP.  Is that
right?  So the quoted statement that I was confused by is in effect saying
that "if there is only ever one classification action and it fully
specifies all possible choices for the path of the packet, then these
context headers are not needed anymore"?

> > 
> >    performance, or proximity considerations.  For the particular
> > case of
> >    UHR services, the stand-by operation of back-up capacity or the
> >    deployment of multiple SF instances may be requested.
> > 
> > I'm not sure that I understand how a per-packet header would request
> > *deployment* of multiple instances.  Perhaps the intent is to say
> > that the presence of multiple instances is requested?  (Or perhaps I
> > misunderstand, of course.)
> 
> [Med] I let this one to Dirk :-)
> 
> > 
> >    In an environment characterised by frequent changes of link and
> > path
> >    behaviour, for example due to variable load or availability
> > caused by
> >    propagation conditions on a wireless link, the SFP may have to be
> >    adapted dynamically by on-the-move SFC path and SF instance
> >    selection.
> > 
> > (Is "on-the-move selection" a new term here?  I kind of thought we
> > had used a different term to describe this type of behavior in a
> > previous document, but couldn't find it quickly.)
> > 
> >    Multiple Performance Policy Identifier Context Headers MAY be
> > present
> >    in the NSH, each carrying an opaque value for a distinct policy
> > that
> >    need to be enforced for a flow.  Supplying conflicting policies
> > may
> >    complicate the SFP computation and SF instance location.
> >    Corresponding rules to detect conflicting policies may be
> > provided as
> >    a local policy to the NSH-aware nodes.  When such conflict is
> >    detected by an NSH-aware node, the default behavior of the node
> > is to
> >    discard the packet and send a notification alarm to a Control
> >    Element.
> > 
> > [It seems like we are providing guidance on the "default behavior"
> > of something that is entirely dependent on there being some local
> > policy, which is perhaps an unusual thing to do.  I don't object to
> > it, per se, though.]
> > 
> > Section 6
> > 
> > When we recommend logging on exception conditions, we typically also
> > include a note about the risk of DoS due to log spew.
> 
> [Med] Added this NEW: 
> 
> "Some events are logged locally with notification alerts sent by NSH-aware nodes to a Control Element. These events SHOULD be rate limited. "

Thanks.

> > 
> > With respect to privacy considerations, whenever we have multiple
> > Subscriber Identifier Context Headers present we are providing the
> > information that thos different (types of) identifiers identify the
> > same subscriber or individual.  This can be used to correlate other
> > observations and track that individual more effectively.
> 
> [Med] Fair point. Added this NEW text:
> 
> "The presence of multiple Subscriber Identifier Context Headers in the same NSH allows a misbehaving node from within the SFC-enabled domain to bind these identifiers to the same subscriber. This can be used to track  that subscriber more effectively."
> 
> > 
> > If one was able to spoof a performance policy identification context
> > header one would be in a position to steal (quality of) service,
> > which is related to the "service disruption" attack already
> > discussed in the text, but IMO distinct from it.
> 
> [Med] "disruption" is used from an operator standpoint: deliver the service to the appropriate subscriber and appropriate quality level. 
> 
> > 
> >    trusted ([RFC8300]).  Means to check that only authorized nodes
> > are
> >    solicited when a packet is crossing an SFC-enabled domain are out
> > of
> >    scope of this document.
> > 
> > I'm not entirely sure that I understand what "solicited" is being
> > used for, here.  Is it something to do with the source/destination
> > (ouside the SFC domain) of the packet, or the nodes on the path
> > within the SFC domain, or something else?
> 
> 
> [Med] We meant that nodes that are "visited"/"invoked" as the packet progresses in the SFP within a domain.
> 
> > 
> > Section 8.2
> > 
> > [RFC8459] seems to be unused.
> > 
> 
> [Med] Used to be cited in previous version. Fixed. 

Thanks for the updates!

-Ben