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

[Benjamin Kaduk <[e-mail]>]

Hi Med,

Thanks for another quick turnaround.
(Inline.)

On Wed, Nov 04, 2020 at 10:33:26AM +0000, [e-mail] wrote:
> Re-, 
> 
> Focusing on the DISCUSS. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> > Envoyé : mercredi 4 novembre 2020 05:37
> > À : The IESG <[e-mail]>
> > Cc : [e-mail]; [e-mail];
> > [e-mail]; Greg Mirsky <[e-mail]>;
> > [e-mail]
> > Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-
> > 12: (with DISCUSS and COMMENT)
> > 
> > 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.
> 
> [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.

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.
 		

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

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

(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!)

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

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