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

[[e-mail]]

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.

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

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

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