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

From: <[email-masked]>
Date: Mon, 2 Nov 2020 07:50:36 +0000

Hi Ben, 

This is a fair and a good point. 

FYI, we raised this point to the WG (see Slide 7 of https://www.ietf.org/proceedings/104/slides/slides-104-sfc-sfc-chair-slides-01). Because the issue is ** not specific ** to this spec, the WG decided to define a solution that will apply to any TLV carrying sensitive data (including encryption): draft-ietf-sfc-nsh-integrity.

What about making this change: 

OLD:
   A misbehaving node within from the SFC-enabled domain may alter the
   content of Subscriber Identifier and Performance Policy Context
   Headers which may lead to service disruption.  Such attack is not
   unique to the Context Headers defined in this document; measures
   discussed in [RFC8300] are to be followed.

NEW:
   A misbehaving node within from the SFC-enabled domain may alter the
   content of Subscriber Identifier and Performance Policy Context
   Headers which may lead to service disruption.  Such attack is not
   unique to the Context Headers defined in this document; measures
   discussed in [RFC8300] are to be followed. A mechanism for SFC integrity
   is specified in [I-D.ietf-sfc-nsh-integrity].

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Envoyé : samedi 31 octobre 2020 02:56
> À : 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)
> 
> 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:
> --------------------------------------------------------------------
> --
> 
> 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).
> 
> 
> 
> 

_________________________________________________________________________________________________________________________

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: Mon, 2 Nov 2020 18:07:43 -0800

Hi Med,

Thanks for helping out with the early start.

>    is specified in [I-D.ietf-sfc-nsh-integrity].

I may well have to properly read the document to comment confidently, but I
think this change is not along the axis I am most concerned about right
now.  (It is a find change to make, just not the change I was looking for
here.)  Specifically, it is talking about "how can I protect this
information?" rather than "why might I need to protect this information?".
I think that the statement in 8300 is saying that we ("would", at the time
of 8300, but now "will") need to consider how (e.g.) the per-packet
subscriber information would traverse through the SFP, what nodes would now
have access to it (at a per-packet level) that did not previously, whether
there are network links (yes, even within the trusted domain) that would
now have access to the additional metadata, if there is other cleartext
data or metadata in the payload that is now easily associated with the
subscriber for social-engineering/blackmail/etc. attacks, etc.  In short,
the considerations that someone would have to think about in order to
decide whether nsh-integrity will be needed for their deployment.

Thanks,

Ben

---

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

Hi Ben, 

While waiting for your full review, I drafted the following text: 

   Both Subscriber Identifier and Performance Policy Context Headers
   carry opaque data.  The structure of the identifiers conveyed in
   these Context Headers is communicated only to entitled NSH-aware
   nodes.  Nevertheless, some structures may be easily inferred from the
   headers (e.g., use of IP addresses).  The use of trivial subscriber
   identifier structures together with the presence of specific SFs in a
   service function chain (e.g., lawful intercept SF) reveal sensitive
   information to every on-path device (but also to teams managing these
   devices).  Such disclosure is a violation in many jurisdictions
   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.  A
   mechanism for encrypting sensitive NSH data is specified in
   [I-D.ietf-sfc-nsh-integrity].  This mechanism can be considered by
   network operators when enhanced SF-to-SF security protection of NSH
   metadata is required.

Will tweak it further. 

Cheers,
Med

> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mardi 3 novembre 2020 03:08
> À : 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)
> 
> Hi Med,
> 
> > FYI, we raised this point to the WG (see Slide 7 of
> https://www.ietf.org/proceedings/104/slides/slides-104-sfc-sfc-
> chair-slides-01). Because the issue is ** not specific ** to this
> spec, the WG decided to define a solution that will apply to any TLV
> carrying sensitive data (including encryption): draft-ietf-sfc-nsh-
> integrity.
> >
> I may well have to properly read the document to comment
> confidently, but I think this change is not along the axis I am most
> concerned about right now.  (It is a find change to make, just not
> the change I was looking for
> I think that the statement in 8300 is saying that we ("would", at
> the time of 8300, but now "will") need to consider how (e.g.) the
> per-packet subscriber information would traverse through the SFP,
> what nodes would now have access to it (at a per-packet level) that
> did not previously, whether there are network links (yes, even
> within the trusted domain) that would now have access to the
> additional metadata, if there is other cleartext data or metadata in
> the payload that is now easily associated with the subscriber for
> social-engineering/blackmail/etc. attacks, etc.  In short, the
> considerations that someone would have to think about in order to