Subject: [sfc] Roman Danyliw's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Thu, 05 Nov 2020 05:54:47 -0800

Roman Danyliw 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:
----------------------------------------------------------------------

There is no framework or guidance to reason about or mitigate the security and
privacy risks of embedding sensitive, user identifying information into the
network.  The document does fairly note that the other SFC headers also don’t
have protection mechanisms either, but they do not enable use identification or
tracking.

During response to IESG ballots prior to mine, two related points were made:

** Using draft-ietf-sfc-nsh-integrity-00 to mitigate risks – this might help,
but the maturity of this document would suggest that additional discussion is
required before it could be evaluated as a solution.

** surveillance as a use case (lawful intercept as an SFC [2]) – reinforces why
a privacy framework is needed (RFC6973 and 8165 are helpful references here)

[1] https://mailarchive.ietf.org/arch/msg/sfc/24Q52inJTpacY1HOlCHU8VTUkIw/

[2] https://mailarchive.ietf.org/arch/msg/sfc/Knc9goUyEjiMLWHmf0K-NbHTpC8/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ben Kaduk’s DISCUSS position.

---

From: <[email-masked]>
Date: Wed, 11 Nov 2020 09:43:41 +0000

Hi Roman, 

Thank you for raising the point. 

I suspect that many of these concerns are because we are referring to RFC8300 rather than repeating them in this spec. I hope this is now better with the modifications agreed with Ben.

I also made the following change to address one specific point mentioned in your review: 

OLD: 
   Data plane SFC-related security considerations, including privacy,
   are discussed in [RFC7665] and [RFC8300].
NEW:
   Data plane SFC-related security considerations, including privacy,
   are discussed in Section 6 [RFC7665] and Section 8 of [RFC8300].  In
   particular, Section 8.2.2 of [RFC8300] states that attached metadata
   (i.e., Context Headers) should be limited to that necessary for
   correct operation of the SFP.  That section indicates that metadata
   considerations that operators can take into account when using NSH
   are discussed in [RFC8165].

The full set of changes can be tracked at: https://tinyurl.com/sfc-service-iesg 

Please let us know if we missed considerations that you think are worth to be recorded. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 5 novembre 2020 14:55
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; Greg Mirsky <[email-masked]>;
> [email-masked]
> Objet : Roman Danyliw's Discuss on draft-ietf-sfc-serviceid-header-
> 12: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> There is no framework or guidance to reason about or mitigate the
> security and privacy risks of embedding sensitive, user identifying
> information into the network.  The document does fairly note that
> the other SFC headers also don’t have protection mechanisms either,
> but they do not enable use identification or tracking.
> 
> ** Using draft-ietf-sfc-nsh-integrity-00 to mitigate risks – this
> might help, but the maturity of this document would suggest that
> additional discussion is required before it could be evaluated as a
> solution.
> 
> ** surveillance as a use case (lawful intercept as an SFC [2]) –
> reinforces why a privacy framework is needed (RFC6973 and 8165 are
> helpful references here)
> 
> [1]
> https://mailarchive.ietf.org/arch/msg/sfc/24Q52inJTpacY1HOlCHU8VTUkI
> w/
> 

_________________________________________________________________________________________________________________________

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.