Hi Roman, We authors will address your comments in the revision. Thanks for your detailed and kind comments.
Best Regards, Paul On Fri, Aug 6, 2021 at 2:09 AM Roman Danyliw <[email protected]> wrote: > 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 > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
