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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Roman,
Here are the revision letter and revised draft reflecting your comments.

https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-capability-data-model-17

You can find my responses to your comments from page 38 in the revision
letter.

Patrick and I worked together for this revision.

Please let me know whether this version satisfies your comments or not.

Thanks.

Best Regards,
Paul Jeong


On Fri, Aug 6, 2021 at 2:09 AM Roman Danyliw <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>