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

[[e-mail]]

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