Re: [I2nsf] AD Review of draft-ietf-i2nsf-nsf-facing-interface-dm-10

["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-nsf-facing-interface-dm-13

You can find my responses to your comments from page 16 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

On Fri, May 28, 2021 at 4:53 AM Roman Danyliw <[e-mail]> wrote:

> Hi!
>
>
>
> Thank you for all of the changes and effort into publishing -11 and -12 in
> response to AD review at [1].  Since the written response was formatted in
> a PDF document [2] to which I can’t easily respond inline, I’m top posting
> my response for readability.  If not explicitly mentioned here, please
> consider the previously mentioned feedback closed.
>
>
>
> Regards,
>
> Roman
>
>
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/i2nsf/_SLa7TxvJYvARlTfU_8CFAO1xYc/
>
> [2]
> https://mailarchive.ietf.org/arch/msg/i2nsf/9S7pr9rQwIDqp8_5Z6QmQQf7GXs/
>
>
>
> ===
>
>
>
> ** (Original text) Section 1.  Per "Security policy configuration for
> advanced network security functions can be defined in future.", what is
> this referencing?  Only a few sentences into the introduction the scope of
> the module isn't clear.  What makes it "advanced"?
>
>
>
> [Roman] -11 added the following text:
>
>
>
> Security policy
>
>    configuration for advanced network security functions is out of the
>
>    scope of this document, such as Intrusion Prevention System (IPS) and
>
>    anti-virus [I-D.ietf-i2nsf-capability-data-model].
>
>
>
> I’m still have difficulty understanding how these “advanced functions” are
> out of scope since there are references to them in this data model and the
> one in the [I-D.ietf-i2nsf-capability-data-model?  What is meant by out of
> scope?
>
>
>
>
>
> ** YANG.  identity target-device (and all derived from it) relies on
> draft-ietf-i2nsf-capability
>
>
>
> [PAUL] The above comment is reflected with the capability data model draft.
>
>
>
> [Roman]  My comment was not clear.  Let me try again, in what way does the
> target-device rely on the capability draft?
>
>
>
>
>
> ** YANG. identity iot.  Is iot intended to cover all operational
> technology (OT) devices?
>
>
>
> [Roman] Your response clarified that IoT is “internet of things” only.  No
> issue with that scope.  My question was whether there a reason that OT
> devices aren’t called out in the taxonomy?
>
>
>
>
>
> ** Section 3.4 and YANG. What is the difference between a per-packet vs.
> per-flow vs. advanced operation?
>
>
>
> [Roman] (Per -11) Thanks for altering the YANG model to call out packet,
> flow and advanced action separately.  The following text was added in -11
> to explain the distinction:
>
>
>
> Section 3.4. The action clause is defined as ingress action, egress
> action, or log action
>
> for packet action, flow action, and advanced action for additional
> inspection. The packet
>
> action is an action for an individual packet such as an IP datagram. The
> flow action is an
>
> action of a traffic flow such as the packets of a TCP session (e.g., an
> HTTP/HTTPS
>
> session). The advanced action is an action of an advanced action (e.g.,
> web filter and
>
> DDoS-attack mitigator) for either a packet or a traffic flow. The action
> clause can be
>
> extended according to specific vendor action features. The action clause
> is described in
>
> detail in [I-D.ietf-i2nsf-capability-data-model].
>
>
>
> The definition of a packet is clear to me.  The flow and advanced actions
> are not.
>
>
>
> -- Is a flow action restricted to looking at 5-tuple information + packet
> counts + byte counts like in Netflow v9?
>
>
>
> -- What makes something “advanced”?  I see no issues with this category
> not being clearly defined so there is future flexibility, but to take that
> approach, it needs to be distinct from the flow action.  Based on the
> descriptions of “content-security” and “control-attack-mitigation-control”,
> it seems like “advanced-actions” operate on either the payload or keep
> state across flows to make an assessment.
>
>
>
> -- The description of “advanced action” seems to be that the packets “need
> to be additionally inspected” above and beyond the packet and flow
> actions.  Is that suggesting a different kind of mutually exclusive
> inspection or just another kind of inspection different than done by packet
> or flow?
>
>
>
> -- In my previous feedback, I said “(identity content-security-controls)
> RFC8329 seems to only describe firewall, IDS and IPS (in section 9.1), but
> not the others. Firewall isn't mentioned. Where is the
>
> definition of the others?”, so you added the “firewall” entry to the model
> to be consistent with RFC8329.  Thanks for being responsive.  I now realize
> I want to revisit my comment in light of the new distinctions being created
> around packet and flow actions.  The “content-security-control” seems to
> indicate that “the NSF … [will] inspect the payload of the packet” which
> seems like an odd fit for “firewall” as my initial thinking would be to
> think of it as a packet or flow action?  Do you have a perspective?
>
>
>
>   identity firewall {
>
>     base content-security-control;
>
>     description
>
>       "Identity for firewall that monitors
>
>        incoming and outgoing network traffic
>
>        and permits or blocks data packets based
>
>        on a set of security rules.";
>
>   }
>
>
>
>
>
> ** YANG Model.
>
>   identity voip-volte {
>
>     base content-security-control;
>
>     description
>
>       "Identity for VoIP/VoLTE security service that
>
>        filters out the packets of malicious users
>
>        with a blacklist of malicious users in a database";
>
>   }
>
>
>
> Please s/blacklist/deny list/
>
>
>
> ** YANG Module.  The “ingress-action” and “egress action” used by
> “container packet-action” and “container flow-action” appear to be
> underspecified.
>
>
>
> (a) Ingress-action description = “Action: pass, drop, reject, alert, and
> mirror”
>
>
>
> (b) Egress-action description = "Egress action: pass, drop, reject, alert,
> mirror, invoke-signaling, tunnel-encapsulation, forwarding, and
> redirection."
>
>
>
> -- “identity reject” cites draft-ietf-i2nsf-capability-data-model-15  but
> that document has no reference to that identity.
>
>
>
> -- “identity {pass, drop, and mirror} cites
> draft-ietf-i2nsf-capability-data-model-15 which in turn just cites RFC8329
> which says:
>
>
>
> Section 7.2 = “o Actions performed on ingress packets, such as pass, drop,
> rate
>
>       limiting, and mirroring.”, and also
>
>
>
> Sections 7.3 to explain that the use of these action is different than
> draft-ietf-netmod-acl-model-15.
>
>
>
> -- (nit for draft-ietf-i2nsf-nsf-monitoring-data-model) “identity alert”
> cites draft-ietf-i2nsf-capability-data-model-15 which cites both RFC 8329
> and draft-ietf-i2nsf-nsf-monitoring-data-model-04.  However, RFC8329 does
> not contain the word “alert”.
>
>
>
> -- “identity {invoke-signaling, tunnel-encapsulation, forwarding, and
> redirection}” have no descriptions or references themselves; the parent
> “leaf egress-action” has a description of (b) which simply enumerates a
> list but contains no reference; leaving a reliance on the reference in
> “container packet-action” and “container flow-action” which has citations
> to RFC8329 and draft-ietf-i2nsf-capability-data-model-15
>
>
>
> RFC8329 contains exactly the following words in Section 7.2:
>
>
>
>    “o  Actions performed on egress packets, such as invoke signaling,
>
>       tunnel encapsulation, packet forwarding, and/or transformation.”
>
>
>
> draft-ietf-i2nsf-capability-data-model-15 has an  “identity
> {invoke-signaling, forwarding, and redirection}” which cites RFC8329.  It
> has no definition of “identity tunnel-encapsulation”.
>
>
>
> It seems like some reference in the I2NSF ecosystem needs to be produced
> to describe what these actions do.
>
>
>
> ** YANG Module.  “list user” and “list group”.  Editorial.  Per the
> changes in -11 to the number of elements and the clarification around
> packet and flow action, I would recommend being clear with the text:
>
>
>
> OLD
>
>
>
> description
>
>   "The user (or user group) information with which
>
>    network flow is associated: The user has many
>
>    attributes such as name, id, password, type,
>
>    authentication mode and so on.
>
>    id is often used in the security policy to
>
>    identify the user.
>
>    Besides, an NSF is aware of the IP address of the
>
>    user provided by a unified user management system
>
>    via network. Based on name-address association,
>
>    an NSF is able to enforce the security functions
>
>    over the given user (or user group)";
>
>
>
> NEW
>
>
>
> For “list user”:
>
>
>
> The user with which the network flow is associated identified by either a
> user id or name.  The user-to-IP address mapping is assumed to be provided
> by the unified user management system via network.
>
>
>
> For “list group”:
>
>
>
> The user group with which the network flow is associated identified by
> either a group id or group name.  The group-to-IP address and user-to-group
> mappings are assumed to be provided by the unified user management system
> via network.
>
>
>
>
>
> ** Section 7.  Thanks for adding the language about identity information
> per “container user and group”.  I recommend some editorial polish.
>
>
>
> OLD
>
>    In this YANG data module, note that the identity information of users
>
>    can be exchanged for security policy configuration based on a user's
>
>    information.  This implied that to improve the network security there
>
>    is a tradeoff between a user's information privacy and network
>
>    security.  For container users-conditions in this YANG data module,
>
>    the identity information of users can be exchanged between Security
>
>    Controller and an NSF for security policy configuration based on
>
>    users' information.  Thus, for this exchange of the identity
>
>    information of users, there is a proportional relationship between
>
>    the release level of a user's privacy information and the network
>
>    security strength of an NSF.
>
>
>
> NEW
>
>
>
> Policy rules identifying specified users and user groups can be specified
> with “rule/condition-clause-container/context-condition/users-condition”.
> As with other data in this YANG module, this user information is provided
> by the Security Controller to the NSFs and is protected via the transport
> and access control mechanisms described above.
>
>
>
> ** Section 6.  Per "For security requirements ... described in Appendix
> A", there is no Appendix A in this document.
>
>
>
> [Roman] Thanks for the edits.  It introduced a reference typo s/ described
> in Section Configuration Examples of
> [I-D.ietf-i2nsf-capability-data-model]/ described in Appendix A of
> [I-D.ietf-i2nsf-capability-data-model]/
>
>
>
>
>
> ** Idnits returned:
>
>
>
>   == Unused Reference: 'I-D.ietf-i2nsf-sdn-ipsec-flow-protection' is
> defined
>
>      on line 4572, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'RFC8335' is defined on line 4641, but no explicit
>
>      reference was found in the text
>
>
>
>
>
>
>
>
>
> *From:* Mr. Jaehoon Paul Jeong <[e-mail]>
> *Sent:* Tuesday, February 2, 2021 11:45 AM
> *To:* Roman Danyliw <[e-mail]>
> *Cc:* [e-mail]; Dr. Jinyong (Tim) Kim <[e-mail]>;
> Patrick Lingga <[e-mail]>; skku-iotlab-members <
> [e-mail]>; Mr. Jaehoon Paul Jeong <
> [e-mail]>
> *Subject:* Re: [I2nsf] AD Review of
> draft-ietf-i2nsf-nsf-facing-interface-dm-10
>
>
>
> Hi Roman,
>
> Tim, Patrick and I have revised the NSF-Facing Interface YANG Data Model
>
> according to your comments:
>
> https://tools.ietf.org/html/draft-ietf-i2nsf-nsf-facing-interface-dm-11
>
>
>
> I attach the revision letter to explain how I have reflected your comments
> on the revision.
>
>
>
> Thanks for your valuable comments and encouragement.
>
>
>
> Best Regards,
>
> Paul
>
>
>
>
>
> On Sat, Oct 31, 2020 at 11:47 AM Roman Danyliw <[e-mail]> wrote:
>
> Hi!
>
> I performed an AD review on draft-ietf-i2nsf-nsf-facing-interface-dm-10.
> Thanks for writing it.
>
> My feedback is as follows:
>
> [snip]
>
>