Benjamin Kaduk has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-25: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The overall structure of this data model seems useful and well described. I also think that the identified "core" set of capabilities to include in this YANG module is a good starting set that will have broad applicability (while still allowing extensibility as needed via standard YANG mechanisms). However, I'd like to have a discussion about whether the individual capabilities are identified and described with sufficient precision so that actual implementations will have identical expctations of semantics and thereby achieve interoperability. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with more precision, but I may be working under flawed assumptions of the usage scenario. Consider the resolution strategies as an example. "First Matching" and "Last Matching" are pretty straightforward, but where can I find a precise specification of "Prioritized Matching Rule with Errors" or "Prioritized Matching Rule with No Errors"? I don't think I can find one in this document, and I don't see any references given that would settle the question either. Similarly, if an NSF indicates the "routing-header" capability, what specifically does that mean? IPv6 routing headers are managed in an IANA registry and this registry is seeing some recent activity, with SRH being registered in 2020 and two CRH variants given temporary registrations in 2021. Is it required to support all defined routing headers in order to claim this capability? Is that all headers defined at the time of this writing, or at the time the claim is being made, or some other definition of "all"? Is it required to support deprecated routing header types like source route ("RH0") and Nimrod? If it suffices to only support any single routing header type, then this is no longer an unambiguous description of the feature. As a couple more examples that I called out in my COMMENT section below, support for HTTP will likely vary across major version of HTTP, and the "transformation" capability for egress action seems under-defined as well -- would a NSF claim this capability if it can perform a single type of transformation? What happens if the user wanted a different type of transformation? It is probably most prudent to have a general discussion about what level of detail/precision we are expecting to include in this document, and only then go and modify the corresponding parts of the document to be compatible with that expectation. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for expanding the security and privacy considerations sections in response to my earlier review; it's much improved. It seems to me that knowing the capabilities of a given NSF is necessary but not sufficient in order to plan out a successful deployment that utilizes those capabilities. In particular, knowledge of where the NSF lies in the (physical or virtual) network topology, or the ability to adjust the topology as needed (as might be done in SDN or with a service-function chaning architecture) is also necessary in order to know which flows could actually be processed by a given NSF. While the specifics of the interaction with network topology are probably out of scope for a data model for NSF capabilities, it still seems like we should mention that there is a need to make this integration, which would ideally be accompanied by a reference to a document that meets that need. Right now the word "topology" appears in this document only once, in the security considerations section (as part of a statement that does not seem to be supported by the rest of the document, no less). Section 1 * Definition for resolution strategy capabilities of network security functions. I didn't see discussion of the need for resolution strategies in the framework (maybe I missed it), so we might want to have a bit of exposition on how the need for it arises due to the other elements of the framework and deployment reality. Some of that content is already present down in §3.2, but there doesn't seem to be an introductory remark that this is extending past what the framework envisioned. Section 3.1 * Automation: The system MUST have the ability to auto-discover, auto-negotiate, and auto-update its security capabilities (i.e., without human intervention). These features are especially useful I assume that "auto-update" here is in the sense of "keep the central database of NSF capabilities current" rather than "go fetch and apply software patches". If my assumption is correct, then we might refer to its "capability registration", admittedly at the cost of the alliterative "auto-"s. of capabilities that other I2NSF Components can use. These capabilities MUST have their access control restricted by a policy; this is out of scope for this document. [...] Is the mechanics of the access control, the policy about which components are granted which access, or both, what is out of scope? The set of capabilities provided by a given set of NSFs unambiguously defines the security services offered by the set of NSFs used. [...] This is probably more of a soapbox rant than an actionable comment, but "unambiguously defines" is a very high bar. If there is any kind of vendor differentiation or quality-of-implementation differences, there may be attributes not captured by the set of capabilities that still affect the security services on offer. Technically, the "Policy Rule" is really a container that aggregates the above three clauses, as well as metadata, which describe the characteristics and behaviors of a capability (or an NSF). Almost nit-like, but up here since it actually affects meaning: if the thing that describes the characteristics and behaviors of a capability/NSF is the metadata, then remove the comma after "metadata". Aggregating metadata enables a business logic to be used to prescribe a behavior. For example, suppose a particular ECA Policy Rule contains three actions (A1, A2, and A3, in that order). Action A2 has a priority of 10; actions A1 and A3 have no priority specified. This is the first time we've mentioned "priority"; it is not a good way to introduce the topic. In fact, this paragraph is the only place that the word "priority" appears in the document (though "prioritized" does appear in §5.1 and in the YANG model ... with no further description of how to fulfil them). Also, is the concept of being able to aggregate multiple pieces of metadata the importent point here, or just the ability to associate metadata with a policy at all? I might rephrase slightly to use "associate" in that case. Section 3.2 There is no conflict between the two policy rules R1 and R2, since the actions are different. [...] I don't think the actions just being "different" is enough to meet the definition. Is the intent to say that they act on different *objects*, or that somehow they act on the same object "in the same way"? * Resolution Strategies: They can be used to specify how to resolve conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF; I'm kind of curious how a conflict would arise between the actions of "the same policy rule". Isn't that just a badly written rule? (There is similar text in §5, if any change is made here.) Section 4 Controller. As described in [RFC8192], with the usage of Registration Interface and the YANG module in this document, the NSFs manufactured by multiple vendors can be managed together by the Security Controller in a centralized way and be updated dynamically by each vendor as the NSF has software or hardware updates. As above, please clarify what is being updated in the scenario being referred to (i.e., software on the device vs the registration information at the security controller). v I2NSF +-----------------+------------+ Registration +-------------+ | Network Operator Mgmt System | Interface | Developer's | | (i.e., Security Controller) |<------------->| Mgmt System | +-----------------+------------+ +-------------+ ^ New NSF | Cap = {FW, WF} I2NSF | E = {} NSF-Facing Interface | C = {IPv4, IPv6} | A = {Allow, Deny} I still think it would be useful to have some prose indicating that the "E = {}" means that the event boolean will always evaluate to true. Section 6 identity system-event { [...] identity system-alarm { [...] identity time { [...] identity device-type { [...] identity geographic-location { [...] identity directional { All of these identities are used as base identities for other identities. Are any of them intended to also be used directly as their own identifier? If not, then I think the description should use the phrase "base identity". identity device-type { description "Identity for device type condition capability. The capability for matching the destination device type."; Why is the destination device given the unqualified name "device-type"? Why would the source device type not also be of interest? identity fragment-flags { base ipv4; description "Identity for IPv4 fragment flags condition capability"; I'm not aware of "fragment flags" being a common jargon to refer to the 'flags' field of the IPv4 header. identity routing-header { base ipv6; description "Identity for IPv6 routing header condition capability"; The semantics of this identity (and several adjacent ones, really) seem rather under-defined. Does this mean that my NSF can recognize that there is a RH present? Or is the NSF expected to do some further parsing on it? Which types of RH would the NSF be required to be able to parse if it indicates this capability? What if new RH types are allocated in the future? identity sctp { base transport-protocol; description "Identity for SCTP condition capabilities"; [...] identity dccp { base transport-protocol; description "Identity for DCCP condition capabilities"; The TCP and UTP identities said they were "base identity" for the respective condition capabilities. Why are SCTP and DCCP different in this regard? identity options { base tcp; description "Identity for TCP options condition capability"; Similarly to the routing-header, what am I signifying if I claim this capability? TCP options are maintained in an IANA registry, so attempting to claim support for all options is an open-ended task. identity length { base tcp; base udp; description "Identity for matching TCP or UDP length condition capability. Why is SCTP (DATA) chunk length not applicable here? (I don't actually know if DCCP has something analogous.) identity http { base application-protocol; description "The identity for Hypertext Transfer Protocol."; reference "RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"; This seems highly problematic. HTTP/1.x, HTTP/2, and HTTP/3 are completely different protocols and a device that can parse one should not be expected to be able to parse any of the others. Trying to conglomerate support for "http" conditions in this manner seems doomed to result in failure. identity pop3 { base application-protocol; description "The identity for Post Office Protocol 3. This includes POP3 over TLS"; [...] identity imap { base application-protocol; description "The identity for Internet Message Access Protocol. This includes IMAP over TLS"; Why are pop3 and imap different from http, which gets distinct identities for http-not-s and https? identity transformation { base egress-action; description "Identity for transformation action capability"; Keeping with the theme, "transformation" is a very generic capability. In some cases the nature of the transformations that are or are not possible will be very important to the user, but in this model an NSF has to either claim the "transformation" capability or not claim it, leaving no room for the subtleties that will be very important for actual deployments. identity fmr { base resolution-strategy; description "Identity for First Matching Rule (FMR) resolution strategy capability"; [...] identity lmr { base resolution-strategy; description "Identity for Last Matching Rule (LMR) resolution strategy capability"; [...] identity pmr { base resolution-strategy; description "Identity for Prioritized Matching Rule (PMR) resolution strategy capability"; [...] identity pmre { base resolution-strategy; description "Identity for Prioritized Matching Rule with Errors (PMRE) resolution strategy capability"; [...] identity pmrn { base resolution-strategy; description "Identity for Prioritized Matching Rule with No Errors (PMRN) resolution strategy capability"; Where are the details of these resolution strategies specified? "first match" and "last match" are perhaps self-explanatory, but I am confident that just relying on the string "Prioritized Matching Rule with No Errors (PMRN)" with no reference or further explanation will result in divergent implementation. Section 9 * list nsf: The leak of this node to an attacker could reveal the specific configuration of security controls to an attacker. An attacker can craft an attack path that avoids observation or mitigations; one may reveal topology information to inform additional targets or enable lateral movement; one enables the construction of an attack path that avoids observation or mitigations; one provides an indication that the operator has discovered the attack. I don't understand what the "one" in the different clauses here refers to. Is it supposed to be "one node" in the YANG tree? But I don't remember seeing specific nodes that provide these abilities if read access is obtained by an attacker; could we name the specific nodes if that's the case? Also, separately, I don't think any of the nodes in *this* module provide topology information. My understanding is that topolgoy information would have to come from a different source (likely a separate YANG module implemented by the same system) and could be combined with the information from this model in order to perform the indicated attacks. Some of the capability indicators (i.e., identities) defined in this document are highly sensitive and/or privileged operations that inherently require access to individuals' private data. These are subtrees and data nodes that are considered privacy sensitive: [...] I think that url-filtering-capability should also be listed here. Perhaps NEW: % * url-filtering-capability: URLs themselves often contain sensitive % information [CAPABILITY-URLS], and access to URLs typically comes % hand-in-hand with access to request and response content, which is % also often sensitive. % % [CAPABILITY-URLS]: https://www.w3.org/2001/tag/doc/capability-urls/ Section 10.2 I'm not sure what methodology was used to classify references as normative vs informative. E.g., RFC 6691 is cited in the same way that RFC 7323 is, but RFC 7323 is classified as normative and RFC 6691 is classified as informative. For reference, per https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ , the classification should be made solely on how the reference is used in the document, with no dependence on the status or source of the referred-to document. For concreteness, I suggest that the classification of RFCs 2818 and 6691, and [I-D.ietf-i2nsf-nsf-facing-interface-dm] and [I-D.ietf-i2nsf-registration-interface-dm] be revisited. [OODMP] "https://www.oodesign.com/mediator-pattern.html";. [OODOP] "https://www.oodesign.com/mediator-pattern.html";. [OODSRP] "https://www.oodesign.com/mediator-pattern.html";. I think the latter two were intended to point to https://www.oodesign.com/observer-pattern.html and https://www.oodesign.com/single-responsibility-principle.html respectively. NITS Section 2 This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA). The meaning of the symbols in tree Please reference RFC 8342 for NMDA. Section 3 This CapIM includes enabling a security controller in an I2NSF framework [RFC8329] to properly identify and manage NSFs, and allow NSFs to properly declare their functionality through a Developer's Management System (DMS) [RFC8329], so that they can be used in the correct way. I think there's a word or two missing between "includes" and "enabling" (perhaps "mechanisms for" or "provision for"?) -- the information model itself does not include an element "enabling a controller to ...", rather, the existince of the model (and other things build on it) enables the controller to do these things. Alternately, drop "includes" and go with "this CapIM enables [...]". Section 3.1 * Advertisement: Registration Interface [I-D.ietf-i2nsf-registration-interface-dm] MUST be used to "The Registration Interface" * Execution: NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and NSF Monitoring Likewise here, add "The". set of Message Exchange Patterns [Hohpe]. Registration Interface [I-D.ietf-i2nsf-registration-interface-dm] can register the "The" here as well. capabilities of NSFs with the security controller from the request of Developer's Management System providing NSFs and the corresponding security capabilities. Also, this interface can Something seems awry here but I can't pick out the intended meaning so as to suggest a fix. Is the idea that the Developer's Management System instigates a request and as a result of that request the list of relevant NSFs and their respective security capabilities become available at the security controller? If so, a comma before "providing" would help, as would some more description like "providing a list of available ... at the security controller". whether it needs to invoke scaling or not. NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model] can observe "The NSF Monitoring Interface" or stored separately in a vendor's local repository. In either case, Registration Interface can facilitate this update process to "the Registration Interface" Developer's Management System to let the security controller update its repository for NSFs and their security capabilities. I think we want s/to Developer's Management System to let/so the Developer's Management System can let/ Section 4 * If a network administrator wants to block IPv4 or IPv6 packets from malicious users, the network administrator sends a security policy rule to block the users to the Network Operator Management System (i.e., Security Controller) using the I2NSF Consumer-Facing Interface. The ordering of the clauses seems wrong here. I think we want to say that the network admin sends a security policy rule to the security controller, and that rule says to block the users in question. So we might consider NEW: % If a network administrator wants to block IPv4 or IPv6 packets % from malicious users, the network administrator sends a security policy % rule to the Network Operator Management System (i.e., Security Controller) % using the I2NSF Consumer-Facing Interface, directing the system to block % the users in question. Section 5.1 The context capabilities provide extra information for the condition. The given context conditions are application filter, target, user condition, and geographic location. The application filter capability is capability in matching the packet based on the application protocol, such as HTTP, HTTPS, FTP, etc. The device type capability is capability in matching the type of the destination devices, such as PC, IoT, Network Infrastructure devices, etc. The user condition is capability in matching the users of the network by mapping each user ID to an IP address. Users can be combined into one group. The geographic location capability is capability in matching the geographical location of a source or destination of a packet. A couple points. The construction of "the <X> capability is capability in <Y>" is not grammatical; it would be better as something like "the <X> capability is the capability for" (other variants are possible that change the conjugation of the following verb) (multiple instances). The sentence about "users can be combined into one group" is potentially confusing. Is there only ever one group possible? If there can be multiple concurrent groupings defined, then something like "users can be combined into groups" would be more accurate. In addition, see Section 9.1 (Flow-Based NSF Capability Characterization) in [RFC8329] and Section 7.5 (NSF Logs) in [I-D.ietf-i2nsf-nsf-monitoring-data-model] for more information about logging at NSFs. s/7.5/6.5/ (at least as of the -12 of the referenced draft) Section 6 identity system-event { base event; description "Identity for system event. System event (called alert) is I suggest adding "sometimes" or "also" at the start of the parenthetical. description "Identity for CPU alarm. CPU is the Central Processing Unit that executes basic operations of the system. A cpu-alarm is emitted when the CPU usage is exceeding the threshold."; [...] description "Identity for disk alarm. Disk is the hardware to store information for a long period, i.e., Hard Disk and Solid-State Drive. A disk-alarm is emitted when the disk usage is exceeding the threshold."; s/the threshold/a threshold/. There is no one single definite threshold that always applies; the threshold in question is either going to be independently configurable or will vary across systems/implementations. identity voip-volte-phone { base device-type; description "Identity for voip-volte-phone"; I think we want "VOIP or VoLTE phone"; there isn't really a single combined VOIP/VoLTE phone as a concept (even if modern premium smartphones do offer seamless wifi/LTE calling). Section 9 * list nsf: An attacker could alter the security capabilities associated with an NSF by disabling or enabling the functionality of the security capabilities of the NSF. I'd suggest NEW: % * list nsf: An attacker could alter the security capabilities % associated with an NSF in the database maintained by the security % controller. Such changes could result in security functionality % going unused due to the controller not having a record of it, and % could also result in falsely claiming security capabilities that the % controller would then attempt to use but would not actually be % provided. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
