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

[Roman Danyliw <[e-mail]>]

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]<mailto:[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]