Hi Linda, Thank you for the reference to RFC 8329 (especially Section 4, which I definitely did not look at previously). To be clear, I agree with what is in the framework document and that we do not want to duplicate its content in every data model. That said, the main privacy consideration that I wanted to raise is that (at least some of) the NSFs themselves have access to the users' private data -- no matter what mechanisms we put in place to encrypt/anonymize that data inside and at the boundary of the i2nsf protocols, the NSFs themselves have to be trusted to behave properly. I don't think that aspect is covered in Sections 4 or 11 of RFC 8329, so it may be appropriate to mention here.
Thanks, Ben On Thu, Sep 24, 2020 at 03:54:18PM +0000, Linda Dunbar wrote: > Ben, > > Thank you very much for the detailed comments. > > As a co-chair, I just want to address your comments on "“not see any > discussion of privacy considerations”. The draft authors will address your > detailed comments & suggestions on the document. > > There are suite of Data Models from I2NSF WG. All of them are branch out from > the I2NSF Framework RFC8329. The Security and privacy description from RFC > 8329 are applicable to all of them. RFC8329 states that > The mechanisms adopted within the > solution space must include proper secure communication channels that > are carefully specified for carrying the controlling and monitoring > information between the NSFs and their management entity or entities. > > The Section 4 of RFC 8329 specifies the Threats Associated with Externally > Provided NSFs. > > Therefore, the WG doesn’t think it is necessary to repeat in every Data Model > draft of the Security and Privacy described in the I2NSF framework RFC8329. > > Best Regards, > > Linda Dunbar > > > -----Original Message----- > From: Benjamin Kaduk via Datatracker <nore...@ietf.org> > Sent: Wednesday, September 23, 2020 12:12 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-i2nsf-capability-data-mo...@ietf.org; i2nsf-cha...@ietf.org; > i2nsf@ietf.org; Linda Dunbar <dunbar...@gmail.com>; dunbar...@gmail.com > Subject: Benjamin Kaduk's Discuss on > draft-ietf-i2nsf-capability-data-model-12: (with DISCUSS and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-i2nsf-capability-data-model-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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690&sdata=OTiRrNUfyiF7dDqYT1AESS%2BGTVzK5llDxbjVSAuyCe4%3D&reserved=0 > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-i2nsf-capability-data-model%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7be707e9f5094fca13b208d85f7f3f28%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637364347438090690&sdata=KHOzeKOWEBpJot8ZMMvWEh8t45eXvwoBKKPFpq29xVU%3D&reserved=0 > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > There are many elements of the YANG module whose semantics seem > underspecified to me. I noted quite a few in the COMMENT section, and I hope > that those aspects of my comments are clear (as it would be substantial > effort to partition the comments and move the questions of unclear semantics > into the discuss section), but I am happy to assist in the classification if > needed. > > I think that the data nodes of this module as written are probably not > reflecting the intent -- it seems that the only elements of the 'nsf' > list are the string nsf-name; there is no "uses nsf-capabilities" stanza to > bring in the grouping that contains all the interesting parts. > Specifically, I do not see how the tree diagram reflects the current module. > > I'm surprised to not see any discussion of privacy considerations -- some of > the features that we define capability indicators for are highly sensitive > and/or privileged operations (e.g., listening to VoIP/VoLTE audio to identify > individuals, web filtering) that inherently require access to individuals' > private data. Not only should we note that private information is made > accessible in this manner, but we should also reiterate that the > nodes/entities given access to this data need to be tightly secured and > monitored, to prevent leakage or other unauthorized disclosure of private > data. > > I also think we need to mention that authentication and proper authorization > will be needed to register as an NSF providing these capabilities. > > The examples do not seem to conform to the current module structure (e.g., > exact-fourth-layer-port-num and range-fourth-layer-port-num). > > I worry a little bit that even the structure of the tree risks "imposing > functional requirements or constraints" upon NSF developers (in the words of > the framework). How would, for example, SCTP capabilities be indicated, let > alone QUIC? (With an augmentation, clearly, but is that undue burden?) > While the classification into ingress/egress/log is natural, it also may be > found limiting; consider, for example, a setup involving port mirroring -- is > that an ingress action or egress? If traffic is dropped as part of a > different ingress filtering capability, does it still get sent to the port > mirror? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It's a little weird to have the data model be up for review when the > information model is still in AD Evaluation, but probably not catastrophic. > > Section 1 > > As the industry becomes more sophisticated and network devices (e.g., > Internet of Things, Self-driving vehicles, and smartphone using Voice > over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a > > nit: missing verb for "network devices". > > registration interface [RFC8329]. With the capabilities of those > security devices maintained centrally, those security devices can be > > nit: I'd probably say that it's the knowledge of those capabilities or a > database of those capabilities that is maintained centrally. > > o Definition for condition capabilities of generic network security > functions. > > o Definition for condition capabilities of advanced network security > functions. > > [I'm not yet sure at this point that I understand the need for distinguishing > between generic and advanced network security functions ... won't the > boundary between those categories evolve over time?] > > Section 3 > > Framework. As shown in this figure, an NSF Developer's Management > System can register NSFs and the capabilities that the network > security device can support. To register NSFs in this way, the > > nit: s/device/devices/ > > That is, this Registration Interface uses the YANG module described > in this document to describe the capability of a network security > function that is registered with the Security Controller. With the > > nit: "capabilities" plural probably makes more sense in this context. > > capabilities of those network security devices maintained centrally, > > [similar comment about "maintained centrally" as above] > > Note that the NSF-Facing Interface [RFC8329] is used to configure the > security policy rules of the generic network security functions, and > The configuration of advanced security functions over the NSF-Facing > > nit: lowercase 'l' in "the". > > o If a network administrator wants to block malicious users for IPv6 > traffic, he sends a security policy rule to block the users to the > Network Operator Management System using the I2NSF User (i.e., web > application). > > I'm not entirely sure why only the IPv6 traffic of a malicious user would be > blocked. > > Also, nit/edtiorial-level, "using the I2NSF Consumer-Facing Interface" > would read more naturally to me than "using the I2NSF User". > > Section 4.1 > > The NSF capabilities in the tree include time capabilities, event > capabilities, condition capabilities, action capabilities, resolution > strategy capabilities, and default action capabilities. Those > > In Section 1 we had a similar list that used "general capabilities" > compared to "time capabilities" here. Is this distinction intentional? > (Given that the tree diagram and actual module use the "time" variant, it's > not entirely clear what the "general" variant would be...) > > repeated time like day, week, or month. See Section 3.4.6 > (Capability Algebra) in [I-D.ietf-i2nsf-capability] for more > information about the time-based condition (e.g., time period) in the > capability algebra. > > Following the reference, it seems to just use time-based condition as an > example of an arbitrary condition -- I don't see any specific discussion that > mentions considerations specific to time-based conditions. > > event and system alarm. See Section 3.1 (Design Principles and ECA > Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more > information about the event in the ECA policy model. > > (side note) I followed the reference and was surprised that I couldn't find > any specific indication that an Event of '{}' evaluates to true (at least, I > assume it does). > > advanced network security functions. The condition capabilities of > generic network security functions are defined as IPv4 capability, > IPv6 capability, TCP capability, UDP capability, and ICMP capability. > The condition capabilities of advanced network security functions are > defined as anti-virus capability, anti-DDoS capability, Intrusion > Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE > capability. See Section 3.1 (Design Principles and ECA Policy Model > > At this point in the document I don't understand why VoIP and VoLTE are fit > to group together into a single capability. Is the condition clause just > looking at a phone number and not other aspects of the call? > > the ingress and egress actions. In addition, see Section 9.1 (Flow- > Based NSF Capability Characterization) for more information about > logging at NSFs. > > [this is section 9.1 of [I-D.ietf-i2nsf-capability] still, though the > additional discussion on logging is fairly minimal.] > > Section 5 > > In general there seems to be a lot of content in "reference" stanzas that to > my non-expert eye would have been more appropriate in the "description" > stanza. > > identity event { > description > "Base identity for I2NSF policy events."; > > I note that draft-ietf-i2nsf-capability uses the phrase "I2NSF Event", "I2NSF > Policy", and "I2NSF Policy Rule" but not "I2NSF policy event", which makes me > suspect that this is an editorial error. > (draft-ietf-i2nsf-nsf-monitoring-data-model doesn't use "I2NSF policy event", > either.) > > identity hardware-alarm { > base system-alarm-capability; > description > "Identity for hardware alarm"; > > How do I decide when to use hardware-alarm vs, e.g., memory-alarm or > cpu-alarm? > > identity condition { > description > "Base identity for policy conditions"; > } > > Similarly to for events, draft-ietf-i2nsf-capability seems to only use "I2NSF > Condition", not "I2NSF policy condition". In this case, the use of "policy" > does not feel as out of place to me as it did for events, though. > > identity context-capability { > [...] > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - The operating context of an NSF."; > } > > I don't see the "the operating context of an NSF" in the referenced draft, > and in fact "context" is not used as a technical term at all. > (Similarly for "identity access-control-list"'s "The context of an NSF".) > > identity application-layer-filter { > base context-capability; > description > "Identity for application-layer-filter condition capability"; > > This seems likely to be highly dependent on what exactly the application > layer is! I'm not sure that such a generic capability will be useful in > practice. > > identity user { > [...] > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - A user in an application of a policy rule > to be applied by an NSF. > RFC 8519: YANG Data Model for Network Access Control Lists > (ACLs) - An access control for a user (e.g., the > corresponding IP address) in an NSF."; > > I'm fairly concerned about implying that it's safe and effective to use an IP > address to identify a user. While this works often enough that we have > stringent privacy considerations regarding storage/conveyance of IP addresses > in logs, in the context of automated network (security) functions the risk of > collatoral damage seems quite large. > > identity group { > [...] > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - A group (i.e., a set of users) in an > application of a policy rule to be applied by an NSF. > RFC 8519: YANG Data Model for Network Access Control Lists > (ACLs) - An access control for a group (e.g., the > corresponding IP address) in an NSF."; > > An IP address can identify a group, too? > > identity geography { > base context-capability; > description > "Identity for geography condition capability"; > reference > "draft-ietf-i2nsf-capability-05: Information Model of NSFs > Capabilities - A group (i.e., a set of users) in an > application of a policy rule to be applied by an NSF. > > I'm not sure what's going on here -- why are groups relevant for geography? > > RFC 8519: YANG Data Model for Network Access Control Lists > (ACLs) - An access control for a geographical location > i.e., geolocation (e.g., the corresponding IP address) in > an NSF. > > RFC 8519 doesn't itself talk about geographic location. > > RFC 8805: A Format for Self-Published IP Geolocation Feeds > - An IP address with geolocation information."; > > I question the utility of self-published geolocation information for the > application of (security) policy -- my understanding is that this reference > was intended to avoid (among other things) the issue where the IETF meeting > network gets geolocated to the location of the previous IETF meeting for the > first couple days of the week, which is a convenience/performance > application, not a security one. > > identity ipv4-capability { > base condition; > description > "Identity for IPv4 condition capability"; > > This identity is used as a base identity for other capabilities; is it > intended to also be used as a standalone capability? If not, I suggest > including "base" in the description. If so, please clarify what the > semantics are. > > identity ipv4-id { > base ipv4-capability; > description > "Identity for identification condition capability"; > > (side note) I'd suggest making some mention of "fragment" or "fragmentation" > here, in light of RFC 6864. > > identity ipv6-capability { > base condition; > description > "Identity for IPv6 condition capabilities"; > > [same as for ipv4-capability] > > identity exact-ipv6-flow-label { > [...] > reference > "RFC 8200: Internet Protocol, Version 6 (IPv6) > Specification - Flow Label"; > > RFC 6437 seems relevant as well. > (Similarly for range-ipv6-flow-label.) > > identity tcp-capability { > base condition; > description > "Identity for TCP condition capabilities"; > > [same as for ipv4-capability] > > identity exact-tcp-seq-num { > base tcp-capability; > description > "Identity for exact-match TCP sequence number condition > capability"; > > It's not entirely clear to me why there is need to match on the TCP sequence > number, which per RFC 6528 should be effectively random from the vantage of a > stateless NSF device. > > identity exact-tcp-ack-num { > base tcp-capability; > description > "Identity for exact-match TCP acknowledgement number condition > capability"; > > Likewise, the ack number should be effectively random to a stateless NSF. > > identity udp-capability { > base condition; > description > "Identity for UDP condition capabilities"; > > [same as for ipv4-capability] > > identity icmp-capability { > base condition; > description > "Identity for ICMP condition capability"; > > [ditto] > > identity icmpv6-capability { > base condition; > description > "Identity for ICMPv6 condition capability"; > > [ditto] > > identity url-capability { > base condition; > description > "Identity for URL condition capability"; > > [ditto] > > identity pre-defined { > base url-capability; > description > "Identity for URL pre-defined condition capability"; > } > > identity user-defined { > base url-capability; > description > "Identity for URL user-defined condition capability"; > } > > With such sparse description and no reference, I have no idea what > functionality this is supposed to indicate. > > identity log-action-capability { > description > "Identity for log-action capability"; > > [same as for ipv4-capability] > > identity rule-log { > base log-action-capability; > description > "Identity for rule log log-action capability"; > } > > identity session-log { > base log-action-capability; > description > "Identity for session log log-action capability"; > } > > [same as for pre-defined/user-defined] > > identity egress-action-capability { > description > "Base identity for egress-action capability"; > > Why does egress-action-capability get described as a "base identity" but > ingress-action-capability and default-action-capability do not? > > identity tunnel-encapsulation { > base egress-action-capability; > description > "Identity for tunnel encapsulation action capability"; > > Given that there is more than one tunneling technology available (within the > IETF, even!), it's not really clear that this capability will be useful. If > a node that only does IPsec wants to talk to a node that only does VXLAN, > there's not going to be much tunneling going on. > > identity voip-volte-capability { > [...] > reference > "RFC 3261: SIP: Session Initiation Protocol > RFC 8329: Framework for Interface to Network Security > Functions - Advanced NSF VoIP/VoLTE security service > capability"; > > RFC 8329 doesn't talk about "voice" or "VoLTE" at all. > > identity exception-application { > [...] > reference > "RFC 8329: Framework for Interface to Network Security > Functions - Advanced NSF Anti-Virus Exception Application > capability"; > > RFC 8329 doesn't talk about "Anti-Virus Exception" at all (and it's not a > term I've encountered previously, so with no other reference I have no idea > what it's supposed to mean). > (Similarly for exception-signature.) > > identity voice-id { > base voip-volte-capability; > description > "Identity for advanced NSF VoIP/VoLTE Voice-ID capability. > This can be used for an extension point for VoIP/VoLTE > Voice-ID as an advanced NSF."; > > It sounds like this "voice-ID" is doing voiceprint analysis to identify > humans, which would have rather significant implications for the privacy > considerations of the system. > > reference > "RFC 3261: SIP: Session Initiation Protocol > RFC 8329: Framework for Interface to Network Security > Functions - Advanced NSF VoIP/VoLTE Security Service > capability"; > > [still no voice/VoLTE in 8329; I'm probably not going to catch all of these] > > container generic-nsf-capabilities { > description > "Conditions capabilities. > If a network security function has the condition > capabilities, the network security function > supports rule execution according to conditions of > IPv4, IPv6, TCP, UDP, ICMP, ICMPv6, and payload."; > > nit: the "and" implies that an NSF has to support all of those if any > condition capability is present, which I don't think is the intent. > > description > "Default action capabilities. > A default action is used to execute I2NSF policy rules > when no rule matches a packet. The default action is > defined as pass, drop, alert, or mirror."; > > Does "alert" setill let the packet pass, or drop it? > > Section 7 > > "ietf-i2nsf-capability" is not a data node; it's the module name. (That > said, I don't really disagree with the assessment that all the nodes in the > module are sensitive, for the listed reasons.) > > Also, I believe it's conventionally assumed that nodes sensitive for write > are also sensitive for read, and don't need to be listed again. > > Section 8.1 > > RFCs 3444 and 8431 do not seem to be referenced anywhere in the document. > > RFCs 3849 and 5737 may not need to be normative (we use the reserved > addresses for documentation but the reader doesn't need to rely on that per > se). > > Appendix A.3 > > The figure lists only "user-defined" as an advanced capability but the prose > claims http and https inspection. > > Appendix A.5 > > We don't seem to use the address of the NSF anywhere, so there doesn't seem > to be need to state what its address is assumed to be. (This would also > render the RFC 5737 and RFC 3849 references unused.) > > > > _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
