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

[[e-mail]]

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

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : mardi 3 novembre 2020 03:08
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : The IESG <[e-mail]>; draft-ietf-sfc-serviceid-
> [e-mail]; [e-mail]; [e-mail]; Greg Mirsky
> <[e-mail]>
> Objet : Re: Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with DISCUSS)
> 
> Hi Med,
> 
> Thanks for helping out with the early start.
> 
> On Mon, Nov 02, 2020 at 07:50:36AM +0000,
> [e-mail] wrote:
> > 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].
> 
> 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

_________________________________________________________________________________________________________________________

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.