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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 20:36:46 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sfc-serviceid-header-12: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/

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

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

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 09:39:44 +0000

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:[email-masked]]
> Envoyé : mercredi 4 novembre 2020 05:37
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; Greg Mirsky <[email-masked]>;
> [email-masked]
> Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-
> 12: (with DISCUSS and 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. 

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

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

> SPI, since the SPI uniquely identifies the SFP?

[Med] Yes. 

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

> I think s/third parties/parties outside the administrative domain/
> may be more accurate.

[Med] Went with "parties outside the SFC-enabled domain".

> administrative domain where the NSH is used".

[Med] OK. 

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

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

> *deployment* of multiple instances.  Perhaps the intent is to say
> that the presence of multiple instances is requested?  (Or perhaps I

[Med] I let this one to Dirk :-)

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

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

> information that thos different (types of) identifiers identify the
> same subscriber or individual.  This can be used to correlate other

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

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

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

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

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 10:33:26 +0000

Re-, 

Focusing on the DISCUSS. 

Please see inline. 

Cheers,
Med

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

[Med] I made the following changes: 
* Reiterate the reco to use obfuscated as this may be missed in the "one" pointer to the Security section of 8300.
* Add a new text for the use of non-persistent identifiers as well as instructing SFs to remove the header early in the SFP. 
* Add new text to illustrate that the nature of SFs in a chain and a subscriber ID may be a privacy violation. 
* Add text to point to the NSH encryption when obfuscation is not sufficient.

The full text can be seen in: https://tinyurl.com/sfc-service-iesg.

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

[Med] Putting aside how the quota usage can be conveyed in a policy instead of a subscriber id, the issue Ben is that a per-subscriber policy is not only about a quota. There are bunch of SFs that are making use of the subscriber identifier (e.g., implicit identification to portal, control the number of devices of a subscriber accessing to a service). The identity of the subscriber is also needed for various reasons (legal data retention). 

As we designed the subscriber id without requiring any specific internal structure, innovation among the lines you are suggesting are not excluded.

With draft-ietf-sfc-serviceid-header, we do solve many many privacy issues that are encountered in current deployments with header enrichment practices (MISDN leaks, etc.). 

  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:
> 
> since it seems to say that NSH-aware intermediary nodes both "have
> to preserve" and "may strip" a Service Identifier Context Header.

[Med] The default behavior is to preserve the context header when present, but the node may strip it if it is instructed to do so. 

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

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 11:40:53 +0000

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: [email-masked] <[email-masked]> 
Sent: Mittwoch, 4. November 2020 10:40
To: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Greg Mirsky <[email-masked]>
Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS and COMMENT)

Hi Ben, 

Please see inline. 

Cheers,
Med

> De : Benjamin Kaduk via Datatracker [mailto:[email-masked]] Envoyé : 
> mercredi 4 novembre 2020 05:37 À : The IESG <[email-masked]> Cc : 
> [email-masked]; [email-masked]; 
> [email-masked] Objet : Benjamin Kaduk's Discuss on 
> draft-ietf-sfc-serviceid-header-

[...]

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

[Med] Yes. 

> actually parse how the (outer) parenthetical is supposed to apply, and 
> expect that my suggestion is going to change the meaning somehow.

[Med] OK. 

> things that would involve peeking inside that opacity (and possibly 
> some additional structure to identify the type).  (No specific action 

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

[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!

[Med] Added this NEW: 

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: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Nov 2020 14:39:38 -0800

Hi Med,

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

> [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? ;)

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

> "Some events are logged locally with notification alerts sent by NSH-aware nodes to a Control Element. These events SHOULD be rate limited. "

Thanks.

> [Med] Used to be cited in previous version. Fixed. 

Thanks for the updates!

-Ben

---

From: <[email-masked]>
Date: Fri, 6 Nov 2020 05:51:15 +0000

Hi Ben, 

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

I confirm. 

Will see if/how to tweak it better as you were confused.  

Thanks. 

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : jeudi 5 novembre 2020 23:40
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : The IESG <[email-masked]>; draft-ietf-sfc-serviceid-
> [email-masked]; [email-masked]; [email-masked]; Greg Mirsky
> <[email-masked]>
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
...
> >
> > >
> > > Section 4
> > >
> > >    instance selection, or policy selection at SFs.  Note that
> the
> > > use of
> > 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"?
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Nov 2020 12:15:30 -0800

Hi Med,

Thanks for another quick turnaround.
(Inline.)

> The full text can be seen in: https://tinyurl.com/sfc-service-iesg.

Thanks, this is improving.

Some notes:

   Aligned with Section 8.2.2 of [RFC8300], this identifier SHOULD be	
   obfuscated.	

Maybe

% While this document does not specify an internal structure for these
% identifiers, it also does not provide any cryptographic protection for
% them; any internal structure to the identifier values chosen will thus be
% visible on the wire.  Accordingly, in alignment with Section 8.2.2 of
% [RFC8300], identifier values SHOULD be obfsucated.

though I would be receptive to claims that this is hitting the reader over
the head too much or too redundant with the new security considerations
text.

   headers (e.g., IP addresses).  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 think the concerns are greater when combining the presence of specific
SFs with a given identifier, but there are considerations just from having
the unprotected identifier present on its own.  Typically we would cover
these baseline considerations for "having this information at all" first,
and then go on to talk about additional considerations in more complicated
scenarios.  (I can't quite tell if some of the following text is intended
to cover this "baseline" scenario or not.)

   headers for its operation.  As discussed in Section 8.2.2 of
   [RFC8300], subscriber-identifying information should be obfuscated
   and security features in the transport encapsulation protocol (such
   as IPsec) must be used.  A mechanism for encrypting sensitive NSH

AFAICT the "must be used" is referring to this chunk from 8300:

% Protecting NSH metadata information between SFC components can be
% done using transport encapsulation protocols with suitable
% security capabilities, along the lines discussed above.  If a
% security analysis deems these protections necessary, then security
% features in the transport encapsulation protocol (such as IPsec)
% MUST be used.

which is a conditional "MUST", and I'm not sure the text proposed here
catches that nuance.

> [Med] Putting aside how the quota usage can be conveyed in a policy instead of a subscriber id, the issue Ben is that a per-subscriber policy is not only about a quota. There are bunch of SFs that…

Of course it's not just for the quota, yes -- quota is just an easy example
that fits very nicely into my point (as opposed to some of the other
examples you list, which do not fit so well) :)
On the other hand, "apply resource quota" is the only listed example at
present, so there might be cause to add a few more examples to that list.

I recognize that in some cases the raw subscriber ID is the most effective
tool to use, but I am hoping that the document can also mentionn other
alternatives that can apply in other cases and are compatible with the
principle of least privilege.  We cannot tell people how to run their
networks, of course, but we can list some options and why/when they might
be advantageous.

> With draft-ietf-sfc-serviceid-header, we do solve many many privacy issues that are encountered in current deployments with header enrichment practices (MISDN leaks, etc.). 

(I did see
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-use-case-mobility-09#section-3.3
and was surprised at HTTP header field insertion still being viable in this
https-everywhere world!)

> [Med] The default behavior is to preserve the context header when present, but the node may strip it if it is instructed to do so. 

Ah, that should be an easy text change, then.

Thanks,

Ben

---

From: <[email-masked]>
Date: Mon, 9 Nov 2020 12:42:40 +0000

Hi Ben, 

Please see inline.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Benjamin Kaduk
> Envoyé : vendredi 6 novembre 2020 21:16
> Cc : [email-masked]; Greg Mirsky
> <[email-masked]>; [email-masked]; The IESG
> <[email-masked]>; [email-masked]
> Objet : Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-
> serviceid-header-12: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> Envoyé
> > > : mercredi 4 novembre 2020 05:37 À : The IESG <[email-masked]>
> Cc :
...
> > * Reiterate the reco to use obfuscated as this may be missed in
> the "one" pointer to the Security section of 8300.
> > * Add a new text for the use of non-persistent identifiers as well
> as instructing SFs to remove the header early in the SFP.
> > * Add new text to illustrate that the nature of SFs in a chain and
> a subscriber ID may be a privacy violation.
> % While this document does not specify an internal structure for
> these % identifiers, it also does not provide any cryptographic
> protection for % them; any internal structure to the identifier
> values chosen will thus be % visible on the wire.

[Med] s/the wire/the wire if no secure transport encapsulation is used.

  Accordingly, in
> alignment with Section 8.2.2 of % [RFC8300], identifier values
> SHOULD be obfsucated.
> 
> though I would be receptive to claims that this is hitting the
> reader over the head too much or too redundant with the new security
> considerations text.

[Med] It is indeed redundant but given the various comments I don't object to have it mentioned twice so that we (hopefully) avoid confusions.  

> I think the concerns are greater when combining the presence of
> specific SFs with a given identifier, but there are considerations
> just from having the unprotected identifier present on its own.
> Typically we would cover these baseline considerations for "having
> this information at all" first, and then go on to talk about
> additional considerations in more complicated scenarios.  (I can't
> quite tell if some of the following text is intended to cover this
> "baseline" scenario or not.)
> 

[Med] Updated and rearranged the text: https://tinyurl.com/sfc-service-iesg. I hope this is better.  

> % done using transport encapsulation protocols with suitable %
> security capabilities, along the lines discussed above.  If a %
> security analysis deems these protections necessary, then security %
> features in the transport encapsulation protocol (such as IPsec) %
> MUST be used.
> 
> which is a conditional "MUST", and I'm not sure the text proposed
> here catches that nuance.
> 

[Med] We can add: "if an operator deems cryptographic integrity protection needed, ".

> > [Med] Putting aside how the quota usage can be conveyed in a
> policy instead of a subscriber id, the issue Ben is that a per-
> subscriber policy is not only about a quota. There are bunch of SFs
> that are making use of the subscriber identifier (e.g., implicit
> identification to portal, control the number of devices of a
> subscriber accessing to a service). The identity of the subscriber
> is also needed for various reasons (legal data retention).
> 
> Of course it's not just for the quota, yes -- quota is just an easy
> example that fits very nicely into my point (as opposed to some of
> the other examples you list, which do not fit so well) :) On the
> other hand, "apply resource quota" is the only listed example at
> I recognize that in some cases the raw subscriber ID is the most
> effective tool to use, but I am hoping that the document can also
> mentionn other alternatives that can apply in other cases and are
> compatible with the principle of least privilege.  We cannot tell
> people how to run their networks, of course, but we can list some
> options and why/when they might be advantageous.

[Med] What about?

OLD:
   This subscriber identifier can be used by service
   functions to enforce per-subscriber policies (e.g., apply resource
   quota).

NEW:
   The Subscriber Identifier Context Header is used by service functions
   to enforce per-subscriber policies (e.g., resource quota, customized
   filtering profile, accounting).  To that aim, network operators may
   rely on identifiers that are generated from those used in legacy
   deployments (e.g., Section 3.3 of[I-D.ietf-sfc-use-case-mobility]).
   Alternatively, network operators may use identifiers that are
   associated with customized policy profiles that are preconfigured on
   SFs using an out of band mechanism.  Such mechanism can be used to
   rotate the identifiers allowing thus for better unlinkability
   (Section 3.2 of [RFC6973]).  Such alternative methods may be
   suboptimal (e.g., scalability issues induced by maintaining and
   processing finer granular profiles) or inadequate to provide some
   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.
...

> > >    Context Headers (i.e., the information can be passed to next
> hop
> > > NSH-
> > >    aware nodes), but local policy may require an intermediary
> NSH-
> > > aware
> > [Med] The default behavior is to preserve the context header when
> present, but the node may strip it if it is instructed to do so.
> 

[Med] Updated to: 

   The default behavior of intermediary NSH-aware nodes is 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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Nov 2020 14:25:55 -0800

Hi Med,

A few notes on the new security considerations

   sources within an SFC-enabled domain (e.g., line identifier).  As w
   The structure of the identifiers conveyed in these Context Headers is

I'm not sure if the "As w" is spurious or was supposed to have more after
it.

   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).  Such disclosure can be a violation in many jurisdictions

(maybe "be a violation of legal requirements"?)

   because such information should be available to very few network
   operator personnel.  Furthermore, 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 Headers unless the SF
   actually uses the content of these headers for its operation.  [...]

It's not clear to me that "don't log it" would actually help all the way if
it's "having the information available on the node at all is a legal
violation" that is problem.  If it's only "operator access" that's the
problem, then the question of what kind of network capture/visibility
processes are available and to which operator personnel, which is probably
more detail than we want to get into at this point, so I'm not entirely
sure what the best option is.  (I'm also not entirely sure if this
mechanism would be fit for purpose at all if the legal requirements
prohibits "available at all on the node", but maybe that's not actually a
relevant requirement.)

More inline.

> [Med] Updated and rearranged the text: https://tinyurl.com/sfc-service-iesg. I hope this is better.  

I think it flows better, thanks.

> [Med] We can add: "if an operator deems cryptographic integrity protection needed, ".

+1

>    performance levels is deployment specific.

Very nice!

>    Header after processing it.

+1

Thanks again for the updates,

Ben

---

From: <[email-masked]>
Date: Tue, 10 Nov 2020 05:51:05 +0000

Hi Ben, 

Thank you for checking. Fixed the nit. 

Focusing on this last one: 

> It's not clear to me that "don't log it" would actually help all the
> way if it's "having the information available on the node at all is
> a legal violation" that is problem.  If it's only "operator access"
> that's the problem

[Med] Yes.  

, then the question of what kind of network
> capture/visibility processes are available and to which operator
> personnel, which is probably more detail than we want to get into at
> this point

[Med] Agree. The key message here for operators is to carefully check the access levels and avoid that some of the access rules are bypassed. 

, so I'm not entirely sure what the best option is.  (I'm
> also not entirely sure if this mechanism would be fit for purpose at
> all if the legal requirements prohibits "available at all on the
> node", but maybe that's not actually a relevant requirement.)
> 
[Med] The requirement is to control who can access the information, not the availability on a given node.  

Cheers,
Med