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

[[e-mail]]

Hi Ben and Med,
I completely agree with Meds reply and just add my clarification as suggested inline.
Thanks!
Thanks and
Kind regards
Dirk

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Mittwoch, 4. November 2020 10:40
To: Benjamin Kaduk <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Greg Mirsky <[e-mail]>
Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS and COMMENT)

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). 

> 
>              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. 

> 
>    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 :-)

[Dirk] Quite right: The intent is to give an example how a policy with high reliability requirements can be enforced - e.g. by choosing a SFP along SFs which are (already) deployed in multiple redundant instances - so your proposal should fit:

s/ deployment of multiple SF instances/ presence of SFs deployed in multiple instances/

Thanks!
> 
>    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. "

> 
> 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. 


_________________________________________________________________________________________________________________________

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.