Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
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 ) – reinforces why a privacy framework is needed (RFC6973 and 8165 are helpful references here)  https://mailarchive.ietf.org/arch/msg/sfc/24Q52inJTpacY1HOlCHU8VTUkIw/  https://mailarchive.ietf.org/arch/msg/sfc/Knc9goUyEjiMLWHmf0K-NbHTpC8/
I support Ben Kaduk’s DISCUSS position.
Retaining my original Discuss position (without the "early warning" note), as it is the one that was supported by Martin D and Alvaro: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 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). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% To record some additional synthesis of the above (original) remark with my more thorough reading of the document: we are defining containers specifically to contain subscriber and performance policy identifiers/information. While the specific contents are out of scope for this document, we still are obligated to describe the general classes of issues that can arise due to conveying those types of information within a SFC domain. We should also give guidance on how to populate the contents of these context headers in a secure and privacy-supporting manner, including the use of indirect identification and obfuscation/encryption. Futhermore (and this part is not a discuss point but may lead to me switching my position to Abstain once the discusses are resolved), I have some misgivings about including subscriber identification information at all, and would prefer if it could instead be translated into the relevant policy information element(s) needed by the SFP in question before being applied to the NSH. For example, rather than saying "this packet is from user X" we could say "this packet is part of quota bucket ABC (with bucket size Z) for time period Y" to enforce per-user quota. While in this case the identifier would still ultimately lead back to an individual, the identifier would be rotated periodically, and it is possible to achieve some level of de-linkability as records age out (depending on how the "ABC" is generated, of course). I do recognize that even for non-quota use cases where a user is part of multiple distinct policy groups, the combination of those groups might still identify only a small anonymity set, but the overall privacy properties of such a design seem superior than consistent use of a persistent identifier or identifiers, in aggregate. I have an additional Discuss point after doing a more thorough review of the document -- I think there's a (minor) internal inconsistency within Section 3: Intermediary NSH-aware nodes have to preserve Subscriber Identifier Context Headers (i.e., the information can be passed to next hop NSH- aware nodes), but local policy may require an intermediary NSH-aware node to strip a Subscriber Identifier Context Header after processing it. since it seems to say that NSH-aware intermediary nodes both "have to preserve" and "may strip" a Service Identifier Context Header. Similar language is used to describe the Performance Policy Identifier Context Header, in Section 4, which would presumably receive a similar modification to the Subscriber Identifier case.
Considering the concerns of the other ADs, I think it would be helpful to clarify "subscriber identifier". I may be wrong in my interpretation but I didn't assume this as being used to identify an individual subscriber but as a context label for a group of users. Both for the obvious privacy reasons and scaling, a mapping context label. Wording to clarify and as Ben noted, guidance on encrypting this value (obvious to an operator but may not be so obvious to software implementers). Even for a group context label, depending on the information, there are different levels of security which are applied.
I support Ben's DISCUSS.
[[ questions ]] [ section 1 ] * Is section 3 of 8300 really the right reference for MTU considerations? 8300 section 5, perhaps? Or 7665 section 5.6? [[ nits ]] [ section 6 ] * s/within from/within/
I support Ben's DISCUSS position.
I found this to be hard to read, despite its short length. I hope my comments below can help with that. — Abstract — This document defines Subscriber and Performance Policy Identifiers Network Service Header Variable-Length Context Headers to inform That string of capitalized words really is indecipherable. I think that’s because it’s talking about three separate things (Identifiers, Network Service Headers, and Context Headers) with nothing to separate them. Can you reword the sentence to fix that? Maybe, “This document defines Subscriber and Performance Policy Identifiers that can be put into variable-length Context Headers within the Network Service Header to inform...”? — Section 1 — NAT functionality can reside in a distinct node which for 3GPP network can be the Packet Data Network (PDN) Gateway (PGW) as specified in [TS23401] in case of 4G or the User Plane Function (UPF) facing the external Data Network (DN) [TS23501] in case of 5G, respectively. That’s a long sentence with at least one grammatical error, and it’s hard to read. May I suggest splitting it?: NEW NAT functionality can reside in a distinct node. For a 4G 3GPP network, that node can be the Packet Data Network (PDN) Gateway (PGW) as specified in [TS23401]. For a 5G 3GPP network it can be the User Plane Function (UPF) facing the external Data Network (DN) [TS23501]. END This approach avoids to require additional internal structures of the Context Headers You can’t “avoid to require”. You can say that the approach “avoids the requirement of additional...”, or, better, simply “avoids additional...”. — Section 3 — In order to prevent interoperability issues, the type the identifiers carried in the Subscriber Identifier Context Headers and their format to be injected in such header should be configured to nodes authorized to inject and consume such headers. I can’t parse that sentence, and I can’t suggest a fix because I have no idea what it’s trying to say. I don’t know whether the issue is grammar or difficult wording. Can you please fix it? Local policies may require running additional validation checks on the content of these Context Headers (e.g., accept only some lengths, types) and the behavior to adopt at NSH-aware SFs. You lose me here at “and the behavior”: I don’t see how it’s supposed to connect to the rest of the sentence. Are you trying to say that: 1. Local policies may require running validation checks, and 2. Local policies may define the behavior to adopt ? Or is it something else? However, this specification does not require nor preclude such NSH-aware SFs may be instructed to ignore the Context Header This also doesn’t parse. I think you can fix this by adding “that” after “preclude“. — Section 4 — Dedicated service-specific performance identifiers are defined to differentiate between services requiring specific treatment to exhibit a performance characterized by, e.g., ultra-low latency (ULL) or ultra-high reliability (UHR). Another sentence I can’t make sense of. Can you please re-word it? adapted dynamically by on-the move SFC path and SF instance Nit: you need one more hyphen, “on-the-move”. Multiple Performance Policy Identifier Context Headers MAY be present in the NSH; each carrying an opaque value Nit: change the semicolon to a comma. o Performance Policy Identifier: Represents an opaque value pointing to specific performance policy to be enforced. The structure and semantic of this field is deployment-specific. Nit: “semantics” as a noun is always used in plural form. — Section 6 — Access to subscriber data usually requires specific access privilege levels. To avoid bypassing this guard, it is not advised that an SF maintaining logs for operational reasons to also log the content of Subscriber and Performance Policy Context Headers received in NSH packets if the SF does not use the content of that header for its operation. The second sentence has some grammatical errors and is hard to read, partly because of a chain of negatives (avoid bypassing, not advised, does not use). Please reword this to say things more directly. Maybe something like this?: NEW 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 Header received in an NSH packet unless the SF actually uses the content of that particular header for its operation. END (And can you also eliminate “received in an NSH packet” from that sentence? I think so.)
[I also suport Ben's DISCUSS.]
Thank you for the work put into this document. Please find below a couple of non-blocking COMMENT points and I would appreciate it if the authors answered to my points that were closed to be a DISCUSS. I hope that this helps to improve the document, Regards, -éric -- Section 1 -- Please clarify the following text as NAT only applies to IPv4 and as there is no private addresses in IPv6 " Typically, because of the widespread use of private addressing in those networks, if SFs to be invoked are located after a NAT function, the identification based on the internal IP address is not possible once the NAT has been crossed. " -- Section 3 -- While I am not familiar with NSH RFC 8300 and the concept of updating the NSH context, the following text makes me wonder: " The classifier and NSH-aware SFs MAY inject or strip a Subscriber Identifier Context Header as a function of a local policy." It appears to me that a SF would actually increase/decrease the size of NSH which could lead to two issues: 1) the actual MTU is decreased on the path *after* encapsulation 2) if ICMP is generated back to the source of the NSH header, then will the source recognize the NSH packet inside the ICMP message as it is different ?
Thanks for addressing my issue.
I support Benjamin's DISCUSS. The privacy properties of the mechanism specified in this document do not comport with the recommendations in RFC 8165 or RFC 6973. The document makes no normative recommendations to minimize the identifiability or linkability of the information in the context header. It specifies no normative transport or object encryption, which RFC 8300 conditionally requires (as does RFC 8371 for similar identifiers). (Furthermore, although this documents says the context header should only be used within an administrative domain, RFC 8300 allows for NSH to be used across administrative boundaries if I understand correctly.) The document does not suggest best practices for minimizing the persistence or uniqueness of the identifiers conveyed when circumstances allow it. As Ben noted, many functions performed by SFs don't need to be aware of actual subscriber identifiers that have some other purpose in the network (IP address, mobile network identifiers, etc.). For other protocols that convey unique subscriber identifiers, even protocols that are not end-to-end like DHCP, the IETF has specified detailed guidance to minimize the privacy impact of exposing these identifiers. See, e.g., RFC 7844 and RFC 8064/7721. That level of analysis and guidance is what I would expect for this specification. I suspect that is an unpopular view, though, so I'm abstaining.