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

[Benjamin Kaduk <[e-mail]>]

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


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