Re: [sfc] Alissa Cooper's Abstain on draft-ietf-sfc-serviceid-header-12: (with COMMENT)

[[e-mail]]

Hi Deborah,

I fully agree with your observation. This is why:

·         We designed it as an opaque identifier and avoided to associate any visible structure with it.

·         The structure to parse the identifier is communicated via the control plane to entitled nodes to manipulated the metadata.

·         We inherited the security and privacy considerations from RFC8300. We don't relax or nullify them.

As you can read in https://github.com/boucadair/draft-ietf-sfc-serviceid/blob/master/draft-ietf-sfc-serviceid-header-12.txt, I updated the text to re-insist on the considerations from 8300:

   o  Subscriber Identifier: Carries an opaque local identifier that is
      assigned to a subscriber by a network operator.

      For example, this identifier can be generated from some of the
      information that is already conveyed in the original packets from
      a host (e.g., internal IP address) or other information that is
      collected from various sources within an SFC-enabled domain (e.g.,
      line identifier).  The use of indirect and non-persistent
      identification is RECOMMENDED.

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

We used "subscriber identifier" as this is an input to provide per-subscriber policy in many of the SFs in the network. We would use a more generic term and thus scope but that would put additional constraints on the control plane and SFs, but worse wouldn't be addressing a need. FWIW, current practices are discussed here: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-use-case-mobility-09#section-3.3.

Rather than pointing to RFC8300 as we initially did, we added NEW text to further insist on the following:

·         Obfuscation is recommended

·         Secure transport must be used

·         SF-to-SF encryption can be used to avoid compromised SFFs.

Thank you.

Cheers,
Med

De : sfc [mailto:[e-mail]] De la part de BRUNGARD, DEBORAH A
Envoyé : jeudi 5 novembre 2020 13:44
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; Alissa Cooper <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; Greg Mirsky <[e-mail]>; [e-mail]; [e-mail]
Objet : Re: [sfc] Alissa Cooper's Abstain on draft-ietf-sfc-serviceid-header-12: (with COMMENT)

Hi Med,

On my ballot, I had entered a comment, I was also confused by this naming "subscriber" as it does raise many privacy concerns (as other ADs are commenting). Whenever this language is used, a complex level of treatment is required as all operators are very aware - in transit or persistent. And usually at higher level application exchange protocols.

Below you say it is "opaque" - can you clarify? I was thinking this was more an operator defined/user data field. Why the need to be so specific to say this is identifying a specific subscriber? Why not make it more general - and a more general applicability?

Thanks,
Deborah

________________________________
From: iesg <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, November 5, 2020 1:43:03 AM
To: Alissa Cooper <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Alissa Cooper's Abstain on draft-ietf-sfc-serviceid-header-12: (with COMMENT)

Hi Alissa,

Please inline.

Cheers,
Med

> -----Message d'origine-----
> De : Alissa Cooper via Datatracker [mailto:[e-mail]]
> Envoyé : jeudi 5 novembre 2020 02:48
> À : The IESG <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; Greg Mirsky <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>
> Objet : Alissa Cooper's Abstain on draft-ietf-sfc-serviceid-header-
> 12: (with COMMENT)
>
> Alissa Cooper has entered the following ballot position for
> draft-ietf-sfc-serviceid-header-12: Abstain
>
> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-__;!!BhdT!xUOrSRpYpPQk-xvq9txxnLO-mVcWtETmRzBMvpDGGAlz9RJLROETfuOoFLu1s8c$<https://urldefense.com/v3/__https:/www.ietf.org/iesg/statement/discuss-__;!!BhdT!xUOrSRpYpPQk-xvq9txxnLO-mVcWtETmRzBMvpDGGAlz9RJLROETfuOoFLu1s8c$>
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/__;!!BhdT!xUOrSRpYpPQk-xvq9txxnLO-mVcWtETmRzBMvpDGGAlz9RJLROETfuOo1TWqp5o$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/__;!!BhdT!xUOrSRpYpPQk-xvq9txxnLO-mVcWtETmRzBMvpDGGAlz9RJLROETfuOo1TWqp5o$>
>
>
>
> --------------------------------------------------------------------
> --
> 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.

[Med] We do have normative language, but indirectly through the reference to RFC8300.

     "subscriber-identifying information ... SHOULD be obfuscated."

As suggested by Ben, we added a note to explicitly remind that behaviour. We don't use the normative language again as this is not a new reco but a reminder:

   "As
   discussed in Section 8.2.2 of [RFC8300], subscriber-identifying
   information should be obfuscated."

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

[Med] Hmm ... RFC 8300, Section 1.1 says explicitly the following:

   "The intended scope of the NSH is for use within a single provider's
   operational domain.  This deployment scope is deliberately
   constrained, as explained also in [RFC7665], and limited to a single
   network administrative domain."

 The document does not suggest best practices
> for minimizing the persistence or uniqueness of the identifiers
> conveyed when circumstances allow it.

[Med] No sure about the uniqueness part, but for the persistence, we added this NEW text:

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

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

[Med] Those will just see opaque data. Also, the data will be striped as soon as it is not needed by downstream SFs.

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

[Med] I'm very familiar with the examples you cited, but they are all involving multiple administrative domains or are visible on the Internet. Our identifiers are opaque and can't be leaked by design.

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

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.