Hi Roman, Our authors will revise the NSF-Facing Interface Data Model Draft according to your comments.
Thanks for your detailed and kind comments. Best Regards, Paul On Fri, May 28, 2021 at 4:53 AM Roman Danyliw <[email protected]> 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 <[email protected]> > *Sent:* Tuesday, February 2, 2021 11:45 AM > *To:* Roman Danyliw <[email protected]> > *Cc:* [email protected]; Dr. Jinyong (Tim) Kim <[email protected]>; > Patrick Lingga <[email protected]>; skku-iotlab-members < > [email protected]>; Mr. Jaehoon Paul Jeong < > [email protected]> > *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 <[email protected]> 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] > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
