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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 30 Oct 2020 18:55:35 -0700

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).