[I2nsf] AD Review of draft-ietf-i2nsf-capability-data-model-16

[Roman Danyliw <[e-mail]>]

Hi!

I conducted a second AD review on -16 of draft-ietf-i2nsf-capability-data-model.  Thanks for the work to merge the text from the previous stand-alone information model document and the preliminary IESG feedback that came before the document was removed from the telechat. My feedback is below:

** Section 1.
   As the industry becomes more sophisticated and network devices (e.g.,
   Internet-of-Things (IoT) devices, autonomous vehicles, and
   smartphones using Voice over IP (VoIP) and Voice over LTE (VoLTE))
   require advanced security protection in various scenario, service
   providers have a lot of problems described in [RFC8192].  

There seems to be a slight change in framing between RFC8192 and this sentence.  RFC8192 discusses the problem as protecting infrastructures and networks, this text frames it as "devices".  This isn't necessarily a problem, I just wanted to ask if that drift was intentional.

** Section 1.  Editorial.

OLD
   Security Capabilities describe the functions that Network Security
   Functions (NSFs) are available to provide for security policy
   enforcement purposes.  

NEW
   Security Capabilities describe the functions that Network Security
   Functions (NSFs) can provide for security policy
   enforcement.  

** Section 1.  

Security Capabilities are independent of the
   actual security control mechanisms that will implement them.

Can you clarify the intent of this statement?  There is a distinction being made between a "security control mechanism" and a "policy" and the "NSF functionality" that I don't follow.

** Section 1.  Editorial.  The sentence beginning with "That is, it is not needed ..." seem repetitive to the text before and after it.  I recommend removing it.

** Section 1.  Per "Note that this YANG data model outlines ...", can you clarify what "outlines" means?

** Section 1.  In the paragraph beginning with "This document provides an information model ...", is there are reason that "NSF" and "Security devices" is being used interchangeably.  I thought architecturally, the unit of capability was a NSF.

** Section 1.  Per the bulleted list of starting with the text of "The 'ietf-i2nsf-capability' YANG module defined in this document ...", there is distinction made between "advanced network security functions" and "generic network security functions".  Where is the difference between those two explained? (There is another comment on this below and Eric Vynke also mentioned it in his initial ballot)

** Section 3.  I'm having trouble finding the information model (CapIM).  Section 4 has a data model.  Section 3.1. describes the properties of the information model.  Is the ECA text in Section 3.1 - 3.3 the CapIM?

** Section 3.  Per the paragraph starting with "Analogous considerations can be applied for channel protection protocols ...", this text seems rather broad in scope.  The data model appears to let you configure IPSec.

** Section 3.  Editorial. s/[RFC8329] , /[RFC8329], / (i.e., remove the extra space between the reference and the comma.

** Section 3.1. Editorial.  s/-po This document/This document/

** Section 3.1. Editorial. s/resepectively/ respectively/ (multiple places)

** Section 3.1.  A few of these requirements are generically written, and I wondering if it needs to be so in the I2NSF context.  For example:

-- For the Advertisement requirement, is this "dedicated, well-known" interface anything but the registration interface?

-- For the Execution requirement, is this "monitoring" capability more than the monitoring module"?

** Section 3.1.  Per the requirement for automation and scalability, no I2NSF document I can find provides guidance on how to realize this design.  As there a normative MUSTs/SHOULDs here, the bounds of these need more details.

-- Are these implementation details out of scope for I2NSF?

-- How much "scale up/down or scale in/out" is needed?

** Section 3.1.

Furthermore, when an unknown threat (e.g., zero-day exploits and
   unknown malware) is reported by an NSF, new capabilities may be
   created, and/or existing capabilities may be updated (e.g., by
   updating its signature and algorithm).  This results in enhancing the
   existing NSFs (and/or creating new NSFs) to address the new threats.
   New capabilities may be sent to and stored in a centralized
   repository, or stored separately in a vendor's local repository.  In
   either case, a standard interface facilitates this update process.

I understand the general update mechanism of security tools with new signatures of algorithms described here, but cannot link it to the abstract nature of the capability model described in this document.  The granularity of the capability model  appears to be "has ips capability" not "has ips capability to mitigate exploit-X".

** Section 3.1.  Per "definitions of all I2NSF policy-related terms are also defined in [RFC8329]", the only defines in RFC8329 on ECA is in Section 7.0.  The definitions in this section appears to be a super-set of those.  Is this reference needed?

** Section 3.1.  The definitions of the ECA elements in this section don't entirely agree with the definitions in Section 7 of RFC8329.  For example, for action, is it flow or packet+flow specific?
-- Here: "An action is used to control and monitor aspects of flow-based NSFs"

-- RFC8329: "defines the type of operations that may be performed on this packet or flow"

** Section 3.2.  I don't follow the intent of this section.  It defines the concept of a "matched policy rule" and terms like "Ac" and "Ec" which aren't used anywhere else in the document.  The title suggested (to me) that there would be some guidance on how to match rules, but there is no guidance there beyond what's already stated in Section 3.1.  I would recommend removing it.

** Section 3.2.  Recommend removing the sentence "To precisely describe ..." as it could be read a redefinition of the ECA terms.  

** Section 3.2. Editorial.  s/the properties to characterize/the properties that characterize/

** Section 3.3.  R1 and R2 are presented to show rules that don't conflict.  Based on their descriptions their action clause affecting the same object in different ways isn't clear because I don't know what "conduct anti-malware investigation" entails.  Please also expand "FW" to be firewall.

** Section 3.3.  I appreciate that R1 - R4 are high level rules that that will get translated into more specific guidance and are intended to demonstrate the parts of ECA.  However, I'm having difficulty matching those rules with the capabilities of the YANG module described in this document.  In particular, R3 and R4 don't appear to be security related unless there is something assumed by virtue of being "GoldService" or "BronzeServer".  What capabilities expressed in the YANG module would one use to encode these rules?

** Section 3.3.

   Conflicts theoretically compromise the correct functioning of devices
   (as happened for routers several year ago).  However, NSFs have been
   designed to cope with these issues.  Since conflicts are originated
   by simultaneously matching rules, an additional process decides the
   action to be applied, e.g., among the ones which the matching rule
   would have enforced.  This process is described by means of a
   resolution strategy for conflicts.


-- Per "(as happened for routers several years ago)", can this event be referenced or explained

-- This text appears to be making assumptions about the internal implementation of NSF (i.e., "conflicts are originated by simultaneously matching rules").  Is that a safe assumption? Should this matching strategy be more clearly stated an underlying requirement of the NSFs that I2NSF can handle

** Section 3.3.

   On the other hand, it may happen that, if an event is caught, none of
   the policy rules matches the event.  

How can an event be caught if there is no event clause in any rule to match it?  The subsequent logic about a firewall doesn't follow for me because the default rule still is a rule.

** Section 3.3.  As noted for Section 3.2, this section introduces RSc and Dc, but this notation is used elsewhere in the document.  Why is this needed?

** Section 4.  Editorial. s/is used for the Security Controller/is used by the Security Controller/

** Section 4 notes that the primary use of this YANG model is for the DMs to populate (via the registration interface) the capabilities of various NSFs.  Given that scope, it is a bit striking that the narrative describing Figure 1 primarily discusses only the byproduct of the database on the controller created by the YANG module in this document.

** Section 5.1.  Is it possible define generic-nsf and advanced-nsf capabilities with a more principled definition.  Perhaps that the generic-nsf operates on layer 3 and 4 headers only; and the advanced in application layer or those requiring cross flow state?

** Yang module.  "This can be used for an extension point ..." is used in a few places.  Can the proposed approach for making extensions be further explained?

** YANG module.  There is a notation being used in the reference section which is not clear to me.  It is of the form: "RFC XXX: <title of RFC - <text>".  For example, in leaf-list default action-capabilities, the reference reads "RFC 8329: Framework for Interface to Network Security Functions - Ingress and egress actions."  What part of RFC8329 am I supposed to be reading.  There is not Section with the title "Ingress and egress" and that exact phrase appears only in Section 9.2 which doesn't appear germane.  It would be much clearer if the references were of the form "RFC XXX: <title of RFC - <Section #>" instead.

** Identity application-layer-filter.  The references seem to suggest that this is HTTP only.  Is the intent for generic capability or for an HTTP-only focus?

** Identity baseline-learning, signature-set, ips-exception-signature.  RFC8329 makes no reference to these types of capabilities.  What are these?

** leaf-list anti-virus-capability, anti-ddos-capability, url-capability, voip-volte-capability.  All of these refer to RFC8329 but I can't find the reference Section in that document which describes these capabilities

** Section 8.  I appreciate the inclusion of this new section in response to the original IESG telechat.  I don't follow how it informs awareness on privacy issues - no insight is being provide on how the trade-off is being made and even what privacy issues are arising beyond simply stating there are some.  I would suggest reframing this section to emphasize that this module is intended to describe the capabilities of a diverse set of network security function already in common use in enterprise security operations. The specificity of the privacy issues can be addressed with reference as is already done with further fidelity as noted in the next comment in Section 9.  Ben Kaduk made a few comments on privacy language in his initial ballot too.

** Section 9.  Thanks for using the YANG Security Considerations template (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) as a starting point.  Please include the other elements of the template:

-- Discuss the readable nodes noting the consequences from the perspective of the attacker (e.g., reading nodes will reveal the specific configuration of security controls to an attacker (a) craft an attack path that avoids observation or mitigations; may revealing topology information to inform additional targets or enable lateral movement; enabling the construction of an attack path that avoids observation or mitigations; or (c) provide an indication that the operator has discovered the attack).  The scope of this is likely the entire data model.

-- Discuss the specifics of which readable nodes might be considered privacy sensitive

** References

-- RFC8805 should be a normative reference

-- Can the shepherd write-up please be updated to reflect that there are several downrefs.  From idnits:

  ** Downref: Normative reference to an Informational RFC: RFC 6691

  ** Downref: Normative reference to an Informational RFC: RFC 8192

  ** Downref: Normative reference to an Informational RFC: RFC 8329

  ** and also RFC8805 as noted above

-- Per "Unused Reference: 'RFC2119' is defined on line 2884, but no explicit      reference was found in the text", this means that the boiler plate such as:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Is not present but the text is still citing RFC2119.  Please add the above text to Section 2 since I believe that the "MUSTs" and "SHOULDs" present in the document are in fact intended to be normative?

Regards,
Roman