Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH)
draft-ietf-sfc-serviceid-header-14

[Ballot comment]
This is just an observation, since we don't seem to have talked about it
the first time around, but this document seems to leave a lot of details
up to the deployment (or implementation?); I wonder how much thought
went into targeting Proposed Standard vs Informational.


Section 3

  per-subscriber policies.  The assessment whether a method for
  defining a subscriber identifier provides the required functionality
  and that it is compliant with SFs capabilities with the intended
  performance levels is deployment specific.

Some nits here; I propose

NEW:
The assessment of whether a method for defining a subscriber identifier
provides the required functionality and whether it is compatible with the
capabilities of the SFs to the intended performance level, is deployment
specific.

  if the NSH-aware SF is instructed to do so.  For example, an SF that
  expects a subscriber identifier generated from an internal IP address
  will discard Subscriber Identifier Context Headers conveying
  identifiers generated from Mobile Subscriber ISDN Number (MSISDN),
  International Mobile Subscriber Identity (IMSI), or malformed IP
  addresses.

It feels a bit odd for a PS document to talk about various types of
identifier like this when any type indicator would be part of the
internal site-specific structure of the opaque data.

Section 4

  The Performance Policy Identifier allows for the distributed
  enforcement of a per-service policy such as a service function path
  to only include specific SFs instances (e.g., SFs located within the
  same DC or those that are exposing the shortest delay from an SFF).

nit: there looks to be a grammar issue here; adding "requiring" before
"a service function path to only include" would probably fix it, but
there are many other options.

  The default behavior of intermediary NSH-aware nodes have to preserve
  such Context Headers (i.e., the information can be passed to next hop
  NSH-aware nodes), but local policy may require an intermediary NSH-
  aware node to strip one after processing it.

Please align the wording here with the (quite well done) version in
the previous section (e.g., s/have to preserve/is to preserve/).

  Nodes that are involved in an SFC-enabled domain are assumed to be
  trusted (Section 1.1 of [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.

Sorry for repeating this from my earlier comments, but I would suggest
to s/solicited/traversed/ here.

                                                                If
  encryption is not enabled, the use of non persistent identifiers as
  well as the removal of the Subscriber Identifier Context Headers from
  the NSH by the last SF making use of such headers soften this issue
  (see "data minimization" discussed in Section 3 of [RFC8165]).

I would double-check the location of the "if encryption is not enabled"
clause, here -- use of encryption would be a different partial
mitigation, but the indicated concerns could still apply in an encrypted
setting, just in a different way (depending on which nodes had access to
the decrypted results, etc.).

  If no secure transport encapsulation is enabled, the use of trivial
  subscriber identifier structures together with the presence of
  specific SFs in a service function chain may reveal sensitive
  information to every on-path device (but also to teams managing these
  devices).  [...]

I would suggest promoting the parenthetical to a full clause (offset by
a comma) and to s/but/and/; the consideration seems of similar import to
the exposure to devices.

[Ballot discuss]
There is no framework or guidance to reason about or mitigate the security and privacy risks of embedding sensitive, user identifying information into the network.  The document does fairly note that the other SFC headers also don’t have protection mechanisms either, but they do not enable use identification or tracking.

During response to IESG ballots prior to mine, two related points were made:

** Using draft-ietf-sfc-nsh-integrity-00 to mitigate risks – this might help, but the maturity of this document would suggest that additional discussion is required before it could be evaluated as a solution.

** surveillance as a use case (lawful intercept as an SFC [2]) – reinforces why a privacy framework is needed (RFC6973 and 8165 are helpful references here)

[1] https://mailarchive.ietf.org/arch/msg/sfc/24Q52inJTpacY1HOlCHU8VTUkIw/

[2] https://mailarchive.ietf.org/arch/msg/sfc/Knc9goUyEjiMLWHmf0K-NbHTpC8/

[Ballot comment]
I support Benjamin's DISCUSS.

The privacy properties of the mechanism specified in this document do not comport with the recommendations in RFC 8165 or RFC 6973. The document makes no normative recommendations to minimize the identifiability or linkability of the information in the context header. It specifies no normative transport or object encryption, which RFC 8300 conditionally requires (as does RFC 8371 for similar identifiers). (Furthermore, although this documents says the context header should only be used within an administrative domain, RFC 8300 allows for NSH to be used across administrative boundaries if I understand correctly.) The document does not suggest best practices for minimizing the persistence or uniqueness of the identifiers conveyed when circumstances allow it. As Ben noted, many functions performed by SFs don't need to be aware of actual subscriber identifiers that have some other purpose in the network (IP address, mobile network identifiers, etc.).

For other protocols that convey unique subscriber identifiers, even protocols that are not end-to-end like DHCP, the IETF has specified detailed guidance to minimize the privacy impact of exposing these identifiers. See, e.g., RFC 7844 and RFC 8064/7721. That level of analysis and guidance is what I would expect for this specification. I suspect that is an unpopular view, though, so I'm abstaining.

[Ballot comment]
Considering the concerns of the other ADs, I think it would be helpful to clarify "subscriber identifier".  I may be wrong in my interpretation but I didn't assume this as being used to identify an individual subscriber but as a context label for a group of users. Both for the obvious privacy reasons and scaling, a mapping context label. Wording to clarify and as Ben noted, guidance on encrypting this value (obvious to an operator but may not be so obvious to software implementers). Even for a group context label, depending on the information, there are different levels of security which are applied.

[Ballot comment]
Considering the concerns of the other ADs, I think it would be helpful to clarify "subscriber identifier".  I may be wrong in my interpretation but I didn't assume this as being used to identify an individual subscriber but as a context label for a group of users. Both for the obvious privacy reasons and scaling, a mapping context label. Some wording to clarify and as Ben noted, guidance on encrypting this value (obvious to an operator but may not be so obvious to software implementers). Even for a group context label, depending on the information, there are different levels of security which are applied.

[Ballot discuss]
This looks like a significant problem. If I have missed anything in any reference this might be very simple to resolve. However, based on this document and looking at RFC 8300 I think this document is lacking in discussion of the packet size impact of using both dynamic size headers, as well as there are no limits to how many are added. Thus, there are significant risk for this header to increase the packet size so much that it doesn't fit the underlying layer. And as Section 5 in RFC8300 identifies there are no general solution provided in NSH. Thus, I really think this issues needs some discussion. Even if the actual result of this is a requirement on the control plane, the issue exists in the data plane and thus warrants discussion in this document.

[Ballot comment]
(preliminary position)
I support Ben Kaduk’s DISCUSS position.

As noted in his position, there is no framework to reason about or mitigate the risk of embedding sensitive subscriber information into the network.  The document does fairly note that the other SFC headers also don’t have protection mechanisms either, but they do not carry such sensitive information.

Certainly there might be possibility with draft-ietf-sfc-nsh-integrity-00, but that is nascent.

[Ballot comment]
Thank you for this document.

A few minor comments/questions:

3.  Subscriber Identification NSH Variable-Length Context Header

  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.
 
This paragraph doesn't appear to be specific to "Subscriber Identification NSH Variable-Length Context Header", yet appears under section 3.  Perhaps this paragraph would be better at the end of the introduction, may be continuing on from "This document assumes the NSH is used exclusively within a single administrative domain."?

3.  Subscriber Identification NSH Variable-Length Context Header

      When multiple subscriber
      identifier Context Headers are present and an SF is instructed to
      strip the Subscriber Identifier Context Header, that SF MUST remove
      all Subscriber Identifier Context Headers.

Is a local policy allowed to remove a single subscriber identifier Context Header?  This text implies that it must always be the case that if one is being removed, they are always all removed.  Is that the intention?  E.g., I was wondering whether the intent here is to explain that their might be multiple context headers in a packet, and hence if a node is instructed to generically remove the subscriber identifier then it better ensure that it removes all subscriber identifier context headers and not just the first one that it finds.

A few nits:

"As such, means to allow" => "As such, methods to allow"
"out of the scope of this" => "outside the scope of this" or "out of scope for this"
"an additional internal structures" => "additional internal structures"
"decide unambiguously whether" => "specify whether"

[Ballot comment]
Thank you for this document.

A few minor comments/questions:

3.  Subscriber Identification NSH Variable-Length Context Header

  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.
 
This paragraph doesn't appear to be specific to "Subscriber Identification NSH Variable-Length Context Header", yet appears under section 3.  Perhaps this paragraph would be better at the end of the introduction, may be continuing on from "This document assumes the NSH is used exclusively within a single administrative domain."?

3.  Subscriber Identification NSH Variable-Length Context Header

      When multiple subscriber
      identifier Context Headers are present and an SF is instructed to
      strip the Subscriber Identifier Context Header, that SF MUST remove
      all Subscriber Identifier Context Headers.

Is a local policy allowed to remove a single subscriber identifier Context Header?  This text implies that it must always be the case that if one is being removed, they are always all removed.  Is that the intention?  E.g., I was wondering whether the intent here is to explain that their might be multiple context headers in a packet, and hence if a node is instructed to generically remove the subscriber identifier then it better ensure that it removes all subscriber identifier context headers and not just the first one that it finds.

A few nits:

"As such, means to allow" => "As such, methods to allow"
"out of the scope of this" => "outside the scope of this" or "out of scope for this"
"an additional internal structures" => "additional internal structures"
"decide unambiguously whether" => "specify whether"

[Ballot comment]
Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENT points and I would appreciate it if the authors answered to my points that were closed to be a DISCUSS.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 1 --
Please clarify the following text as NAT only applies to IPv4 and as there is no private addresses in IPv6
"  Typically,
  because of the widespread use of private addressing in those
  networks, if SFs to be invoked are located after a NAT function, the
  identification based on the internal IP address is not possible once
  the NAT has been crossed. "

-- Section 3 --
While I am not familiar with NSH RFC 8300 and the concept of updating the NSH context, the following text makes me wonder:
"  The classifier and NSH-aware SFs MAY inject or strip a Subscriber
  Identifier Context Header as a function of a local policy."
 
It appears to me that a SF would actually increase/decrease the size of NSH which could lead to two issues:
1) the actual MTU is decreased on the path *after* encapsulation
2) if ICMP is generated back to the source of the NSH header, then will the source recognize the NSH packet inside the ICMP message as it is different ?

[Ballot discuss]
Retaining my original Discuss position (without the "early warning"
note), as it is the one that was supported by Martin D and Alvaro:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
This document defines (among other things) a mechanism for carrying
subscriber information in an NSH.  RFC 8300 (NSH) notes both that:

                                            Metadata privacy and
  security considerations are a matter for the documents that define
  metadata format.

and that:

      One useful element of providing privacy protection for sensitive
      metadata is described under the "SFC Encapsulation" area of the
      Security Considerations of [RFC7665].  Operators can and should
      use indirect identification for metadata deemed to be sensitive
      (such as personally identifying information), significantly
      mitigating the risk of a privacy violation.  In particular,
      subscriber-identifying information should be handled carefully,
      and, in general, SHOULD be obfuscated.

On the other hand, this document in its security considerations claims
that:

  Data plane SFC-related security considerations, including privacy,
  are discussed in [RFC7665] and [RFC8300].

and does not seem to incorporate any discussion of the privacy and
security considerations of the subscriber information metadata carried
by the new format it conveys.  Yes, it does note that all nodes with
access to the information are part of the same trusted domain, but I do
not think that is sufficient, especially given that personally
identifiable information is often subject to strict compliance regimes.

In short, 8300 and this document are referring to each other for privacy
considerations, and the actual privacy considerations do not seem to be
documented in either place.

Additionally, I did not see any indication of how the
subscriber-identifying information ought to be obfuscated (or an
explanation of why it is okay to violate the SHOULD from 8300).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

To record some additional synthesis of the above (original) remark with
my more thorough reading of the document: we are defining containers
specifically to contain subscriber and performance policy
identifiers/information.  While the specific contents are out of scope
for this document, we still are obligated to describe the general
classes of issues that can arise due to conveying those types of
information within a SFC domain.  We should also give guidance on how to
populate the contents of these context headers in a secure and
privacy-supporting manner, including the use of indirect identification
and obfuscation/encryption.

Futhermore (and this part is not a discuss point but may lead to me
switching my position to Abstain once the discusses are resolved), I
have some misgivings about including subscriber identification
information at all, and would prefer if it could instead be translated
into the relevant policy information element(s) needed by the SFP in
question before being applied to the NSH.  For example, rather than
saying "this packet is from user X" we could say "this packet is part of
quota bucket ABC (with bucket size Z) for time period Y" to enforce
per-user quota.  While in this case the identifier would still
ultimately lead back to an individual, the identifier would be rotated
periodically, and it is possible to achieve some level of de-linkability
as records age out (depending on how the "ABC" is generated, of course).
I do recognize that even for non-quota use cases where a user is part of
multiple distinct policy groups, the combination of those groups might
still identify only a small anonymity set, but the overall privacy
properties of such a design seem superior than consistent use of a
persistent identifier or identifiers, in aggregate.

I have an additional Discuss point after doing a more thorough review of
the document -- I think there's a (minor) internal inconsistency within
Section 3:

  Intermediary NSH-aware nodes have to preserve Subscriber Identifier
  Context Headers (i.e., the information can be passed to next hop NSH-
  aware nodes), but local policy may require an intermediary NSH-aware
  node to strip a Subscriber Identifier Context Header after processing
  it.

since it seems to say that NSH-aware intermediary nodes both "have to
preserve" and "may strip" a Service Identifier Context Header.
Similar language is used to describe the Performance Policy Identifier
Context Header, in Section 4, which would presumably receive a similar
modification to the Subscriber Identifier case.

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

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

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

            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?

  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.

  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.

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

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

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?

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

  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.

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.

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.

  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?

Section 8.2

[RFC8459] seems to be unused.

[Ballot discuss]
Retaining my original Discuss position (without the "early warning"
note), as it is the one that was supported by Martin D and Alvaro:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
This document defines (among other things) a mechanism for carrying
subscriber information in an NSH.  RFC 8300 (NSH) notes both that:

                                            Metadata privacy and
  security considerations are a matter for the documents that define
  metadata format.

and that:

      One useful element of providing privacy protection for sensitive
      metadata is described under the "SFC Encapsulation" area of the
      Security Considerations of [RFC7665].  Operators can and should
      use indirect identification for metadata deemed to be sensitive
      (such as personally identifying information), significantly
      mitigating the risk of a privacy violation.  In particular,
      subscriber-identifying information should be handled carefully,
      and, in general, SHOULD be obfuscated.

On the other hand, this document in its security considerations claims
that:

  Data plane SFC-related security considerations, including privacy,
  are discussed in [RFC7665] and [RFC8300].

and does not seem to incorporate any discussion of the privacy and
security considerations of the subscriber information metadata carried
by the new format it conveys.  Yes, it does note that all nodes with
access to the information are part of the same trusted domain, but I do
not think that is sufficient, especially given that personally
identifiable information is often subject to strict compliance regimes.

In short, 8300 and this document are referring to each other for privacy
considerations, and the actual privacy considerations do not seem to be
documented in either place.

Additionally, I did not see any indication of how the
subscriber-identifying information ought to be obfuscated (or an
explanation of why it is okay to violate the SHOULD from 8300).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

To record some additional synthesis of the above (original) remark with
my more thorough reading of the document: we are defining containers
specifically to contain subscriber and performance policy
identifiers/information.  While the specific contents are out of scope
for this document, we still are obligated to describe the general
classes of issues that can arise due to conveying those types of
information within a SFC domain.  We should also give guidance on how to
populate the contents of these context headers in a secure and
privacy-supporting manner, including the use of indirect identification
and obfuscation/encryption.

Futhermore (and this part is not a discuss point but may lead to me
switching my position to Abstain once the discusses are resolved), I
have some misgivings about including subscriber identification
information at all, and would prefer if it could instead be translated
into the relevant policy information element(s) needed by the SFP in
question before being applied to the NSH.  For example, rather than
saying "this packet is from user X" we could say "this packet is part of
quota bucket ABC (with bucket size Z) for time period Y" to enforce
per-user quota.  While in this case the identifier would still
ultimately lead back to an individual, the identifier would be rotated
periodically, and it is possible to achieve some level of de-linkability
as records age out (depending on how the "ABC" is generated, of course).
I do recognize that even for non-quota use cases where a user is part of
multiple distinct policy groups, the combination of those groups might
still identify only a small anonymity set, but the overall privacy
properties of such a design seem superior than consistent use of a
persistent identifier or identifiers, in aggregate.

I have an additional Discuss point after doing a more thorough review of
the document -- I think there's a (minor) internal inconsistency within
Section 3:

  Intermediary NSH-aware nodes have to preserve Subscriber Identifier
  Context Headers (i.e., the information can be passed to next hop NSH-
  aware nodes), but local policy may require an intermediary NSH-aware
  node to strip a Subscriber Identifier Context Header after processing
  it.

since it seems to say that NSH-aware intermediary nodes both "have to
preserve" and "may strip" a Service Identifier Context Header.
Similar language is used to describe the Performance Policy Identifier
Context Header, in Section 4, which would presumably receive a similar
modification to the Subscriber Identifier case.

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

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

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

            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?

  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.

  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.

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

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

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?

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

  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.

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.

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.

  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?

Section 8.2

[RFC8459] seems to be unused.

[Ballot comment]
[[ questions ]]

[ section 1 ]

* Is section 3 of 8300 really the right reference for MTU considerations?

  8300 section 5, perhaps?  Or 7665 section 5.6?


[[ nits ]]

[ section 6 ]

* s/within from/within/

[Ballot discuss]
This is an "early warning" discuss ballot, entered before I have done a full review of the document.
As such, it is possible that the stated concern may in fact be a non-issue after closer examination,
but the potential import of the concern seems to make it worth starting the discussion sooner
rather than later.

This document defines (among other things) a mechanism for carrying subscriber information in
an NSH.  RFC 8300 (NSH) notes both that:

                                            Metadata privacy and
  security considerations are a matter for the documents that define
  metadata format.

and that:

      One useful element of providing privacy protection for sensitive
      metadata is described under the "SFC Encapsulation" area of the
      Security Considerations of [RFC7665].  Operators can and should
      use indirect identification for metadata deemed to be sensitive
      (such as personally identifying information), significantly
      mitigating the risk of a privacy violation.  In particular,
      subscriber-identifying information should be handled carefully,
      and, in general, SHOULD be obfuscated.

On the other hand, this document in its security considerations claims that:

  Data plane SFC-related security considerations, including privacy,
  are discussed in [RFC7665] and [RFC8300].

and does not seem to incorporate any discussion of the privacy and security
considerations of the subscriber information metadata carried by the new
format it conveys.  Yes, it does note that all nodes with access to the information
are part of the same trusted domain, but I do not think that is sufficient,
especially given that personally identifiable information is often subject to
strict compliance regimes.

In short, 8300 and this document are referring to each other for privacy considerations,
and the actual privacy considerations do not seem to be documented in either place.

Additionally, I did not see any indication of how the subscriber-identifying information
ought to be obfuscated (or an explanation of why it is okay to violate the SHOULD from
8300).

[Ballot comment]
I found this to be hard to read, despite its short length.  I hope my comments below can help with that.

— Abstract —

  This document defines Subscriber and Performance Policy Identifiers
  Network Service Header Variable-Length Context Headers to inform

That string of capitalized words really is indecipherable.  I think that’s because it’s talking about three separate things (Identifiers, Network Service Headers, and Context Headers) with nothing to separate them.  Can you reword the sentence to fix that?

Maybe, “This document defines Subscriber and Performance Policy Identifiers that can be put into variable-length Context Headers within the Network Service Header to inform...”?

— Section 1 —

  NAT functionality can reside in a distinct
  node which for 3GPP network can be the Packet Data Network (PDN)
  Gateway (PGW) as specified in [TS23401] in case of 4G or the User
  Plane Function (UPF) facing the external Data Network (DN) [TS23501]
  in case of 5G, respectively.

That’s a long sentence with at least one grammatical error, and it’s hard to read.  May I suggest splitting it?:

NEW
  NAT functionality can reside in a distinct node.  For a 4G 3GPP
  network, that node can be the Packet Data Network (PDN)
  Gateway (PGW) as specified in [TS23401].  For a 5G 3GPP
  network it can be the User Plane Function (UPF) facing the
  external Data Network (DN) [TS23501].
END

  This approach avoids
  to require additional internal structures of the Context Headers

You can’t “avoid to require”.  You can say that the approach “avoids the requirement of additional...”, or, better, simply “avoids additional...”.

— Section 3 —

  In order
  to prevent interoperability issues, the type the identifiers carried
  in the Subscriber Identifier Context Headers and their format to be
  injected in such header should be configured to nodes authorized to
  inject and consume such headers.

I can’t parse that sentence, and I can’t suggest a fix because I have no idea what it’s trying to say.  I don’t know whether the issue is grammar or difficult wording.  Can you please fix it?

  Local policies may require running additional validation checks on
  the content of these Context Headers (e.g., accept only some lengths,
  types) and the behavior to adopt at NSH-aware SFs.

You lose me here at “and the behavior”: I don’t see how it’s supposed to connect to the rest of the sentence.  Are you trying to say that:
1. Local policies may require running validation checks, and
2. Local policies may define the behavior to adopt ?

Or is it something else?

  However, this specification does not require nor preclude
  such NSH-aware SFs may be instructed to ignore the Context Header

This also doesn’t parse.  I think you can fix this by adding “that” after “preclude“.

— Section 4 —

  Dedicated service-specific performance identifiers are defined to
  differentiate between services requiring specific treatment to
  exhibit a performance characterized by, e.g., ultra-low latency (ULL)
  or ultra-high reliability (UHR).

Another sentence I can’t make sense of.  Can you please re-word it?

  adapted dynamically by on-the move SFC path and SF instance

Nit: you need one more hyphen, “on-the-move”.

  Multiple Performance Policy Identifier Context Headers MAY be present
  in the NSH; each carrying an opaque value

Nit: change the semicolon to a comma.

  o  Performance Policy Identifier: Represents an opaque value pointing
      to specific performance policy to be enforced.  The structure and
      semantic of this field is deployment-specific.

Nit: “semantics” as a noun is always used in plural form.

— Section 6 —

  Access to subscriber data usually requires specific access privilege
  levels.  To avoid bypassing this guard, it is not advised that an SF
  maintaining logs for operational reasons to also log the content of
  Subscriber and Performance Policy Context Headers received in NSH
  packets if the SF does not use the content of that header for its
  operation.

The second sentence has some grammatical errors and is hard to read, partly because of a chain of negatives (avoid bypassing, not advised, does not use).  Please reword this to say things more directly.  Maybe something like this?:

NEW
  Access to subscriber data usually requires specific access privilege
  levels.  To maintain that protection, an SF keeping operational logs
  should not log the content of a Subscriber and Performance Policy
  Context Header received in an NSH packet unless the SF actually
  uses the content of that particular header for its operation.
END

(And can you also eliminate “received in an NSH packet” from that sentence?  I think so.)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sfc-serviceid-header-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the NSH IETF-Assigned Optional Variable-Length Metadata Types registry on the Network Service Header (NSH) Parameters registry page located at:

https://www.iana.org/assignments/nsh/

two, new metadata types are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: Subscriber Identifier
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Performance Policy Identifier
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-23):

From: The IESG
To: IETF-Announce
CC: gregimirsky@gmail.com, Greg Mirsky , draft-ietf-sfc-serviceid-header@ietf.org, sfc@ietf.org, martin.vigoureux@nokia.com, sfc-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Service Function Chaining: Subscriber and Performance Policy Identification Variable-Length Network Service Header (NSH) Context Headers) to Proposed Standard


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Service Function Chaining: Subscriber
and Performance Policy
  Identification Variable-Length Network Service Header (NSH) Context
  Headers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines Subscriber and Performance Policy Identifiers
  Network Service Header Variable-Length Context Headers to inform
  Service Functions about subscriber- and service-related information
  for the sake of policy enforcement and appropriate service function
  chaining operations.  The structure of each Context Header, their use
  and processing by NSH-aware nodes are described.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7665: Service Function Chaining (SFC) Architecture (Informational - IETF stream)

Technical Summary

  This document defines Subscriber and Performance Policy Identifiers
  Network Service Header Variable-Length Context Headers to inform
  Service Functions about subscriber- and service-related information
  for the sake of policy enforcement and appropriate service function
  chaining operations.  The structure of each context header is
  defined; their use and processing instructions by SFC-aware nodes are
  explained.

Working Group Summary

The draft was first submitted in September 2015, has been reviewed by a reasonable
number of people in the SFC working group, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters
and no objections from the working group.

No IPR disclosures have been filed that reference this document at any time. All authors
have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality

The current version of the draft is clear, seems to have resolved all the
issues, and has the consensus of the working group.

Personnel

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Martin Vigoureux

Technical Summary

  This document defines Subscriber and Performance Policy Identifiers
  Network Service Header Variable-Length Context Headers to inform
  Service Functions about subscriber- and service-related information
  for the sake of policy enforcement and appropriate service function
  chaining operations.  The structure of each context header is
  defined; their use and processing instructions by SFC-aware nodes are
  explained.

Working Group Summary

The draft was first submitted in September 2015, has been reviewed by a reasonable
number of people in the SFC working group, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters
and no objections from the working group.

No IPR disclosures have been filed that reference this document at any time. All authors
have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality

The current version of the draft is clear, seems to have resolved all the
issues, and has the consensus of the working group.

Personnel

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Martin Vigoureux

Technical Summary

  This document defines Subscriber and Performance Policy Identifiers
  Network Service Header Variable-Length Context Headers to inform
  Service Functions about subscriber- and service-related information
  for the sake of policy enforcement and appropriate service function
  chaining operations.  The structure of each context header is
  defined; their use and processing instructions by SFC-aware nodes are
  explained.

Working Group Summary

The draft was first submitted in September 2015, has been reviewed by a reasonable
number of people in the SFC working group, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters
and no objections from the working group.

The working group is solidly behind this document.

Document Quality

The current version of the draft is clear, seems to have resolved all the
issues, and has the consensus of the working group.

Personnel

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Martin Vigoureux

This starts the working group last call for this document.  It has been discussed on the email list.  We need to see responses.  If you see issues with publishing this document as an RFC, please speak up now.  And please be clear about what your concerns are.  At the same time, if you think that publishing this as an RFC is a good thing for the working group, please speak up.

As a note for those who may be concerned about the relationship to the TLV draft, the chairs have noticed that problem, and we believe we have gotten that document unstuck.

Given the propensity for people to disappear at this time of year, I am giving the document a 4 week last call.

Thank you for your time and attention,
Joel (& Jim)