I2NSF NSF Monitoring Interface YANG Data Model
Note: This ballot was opened for revision 13 and is now closed.
Comment (2022-02-08 for -14) Sent
[S6.1.5; comment] * Possibly this set of "interface-state"s is sufficient for security monitoring, but I'm wondering if any of the additional "oper-status" states from RFC 8343 would be of interest (maybe, maybe not). [S8; comment] * Anywhere an inet:ip-address-no-zone is used I'm curious as to whether or not an optional associated interface might want to also be present. For example, in the case of "i2nsf-traffic-flows" there is no ingress nor egress interface. It's possible that with knowledge of the routing at the time the information was captured the ingress/egress interfaces could be reconstructed but that might also prove difficult unless that information is separately retained. This applies to the uses as well where the interface in question might want to be noted, either because it could change in the future or perhaps because an attack arrives via an unexpected interface. [S8; question] * Are all three "leaf language" definitions necessary, or can this be something shared, defined only once somewhere else?
(was Discuss) No Objection
Comment (2022-04-13 for -16) Sent
Thank you for the work on this document. Many thanks to Valery Smyslov for his review: https://mailarchive.ietf.org/arch/msg/art/2XuRUuQaI8ZrVSyuWQn1SHi5dEY/, and to the authors for addressing his comments. Thank you for addressing my DISCUSS points. I have checked about the Web Attack Alarm and heard no objections on this use from the HTTPBIS wg: https://mailarchive.ietf.org/arch/msg/httpbisa/H2bsyIoGo9JKNUlsCrrwA_rnp08/. DISCUSS point kept for record below. Also please note that the YANG validation fails on the datatracker. Francesca ----- Section 6.3.4. FP: It is not clear to me why these specific header fields (and these fields only) are selected to be part of the information about Web Attack Alarm - req-user-agent, cookies. I agree with Ben's DISCUSS point 1. (reported below) and would even add to that that more motivation around which header fields are included and why, would help. I'd also like to know if the HTTPBIS working group has been involved in the discussion, and if not, if they could be to give their expert opinion. Ben's DISCUSS: (1) I'm not sure I understand the motivation for recommending (in §6.3.4) that the HTTP Cookie header field be included in a notification about a Web Attack Event. In general, the cookie field can contain very sensitive information, including credentials, and it is very risky to be sending the cookies around outside of their primary protocol context. Perhaps, if we are fully confident that the NSF has correctly identified an attack, it might be useful to send the cookies around, but I think there are still some scenarios (e.g., a compromised end-user browser) where the cookies in an attack request are still confidential information that should not be disclosed. Could we say more about why it is recommended to always include the cookies or weaken the recommendation?
Comment (2022-02-14 for -14) Sent
Reading this right after draft-ietf-i2nsf-nsf-facing-interface-dm-21, I'm struck that there are many things defined as possible filter criteria (e.g. TCP header fields) but are not worth recording as statistics. Does this all fall under the "policy hit counter?"
Comment (2022-02-17 for -15) Sent
The shepherd writeup indicates that there is an IPR declaration, but does not characterize the discussion about it that occurred (if any). Please update the writeup to state, or at least let the IESG know by replying to this, what the outcome of this was. I suggest breaking Section 11 into subsections, one for each IANA action being requested.
(was Discuss) No Objection
Comment (2022-04-19 for -18) Sent
Ben's original DISCUSS points were addressed. My comments were also addressed in -18
(was Discuss) No Objection
Comment (2022-03-22 for -16) Sent
Thanks for addressing my discuss and comments.
Comment (2022-02-16 for -15) Sent
Thanks for working on this specification. Thanks to Kyle Rose for TSVART review and agree with him that I also haven't find any transport related issues, hence the NO objection ballot. However, I regret that QUIC is not included in the models as transport protocol. I am curious to know why doesn't "i2nsf-nsf-event" sub leaf "i2nsf-nsf-detection-voip-vocn" have a "action*" where rest of the events have actions? I am also interested to know Eric V's discuss on reusing existing YANG models.
(was Discuss) No Objection
Comment (2022-03-25 for -16) Sent
Thank you for the work put into this document. I really like the approach of binding an information model to a data model even if the information model looks more like a data dictionary. Thank you also for addressing my previous DISCUSS points as well as many of my COMMENT points. I sincerely believe that the changes have improved the document. ! Please note that there is a warning about the syntax of the YANG module ! Please also check the Internet directorate review by Donald Eastlake (thank you BTW) at: https://datatracker.ietf.org/doc/review-ietf-i2nsf-nsf-monitoring-data-model-14-intdir-telechat-eastlake-2022-02-07/ NB: as you may notice, I have not followed Donald's recommendation to raise a DISCUSS on one point, but Donald and I will appreciate an answer of the authors. Special thanks to Linda Dunbar for the shepherd's write-up (even if dated one year ago) including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: While I trust the OPS AD for a final say, I am really surprised that the data model does not re-use existing YANG modules (e.g., RFC 8632 and <https://yangcatalog.org/yang-search/yang_tree/ietf-alarms@2019-09-11>). # Previous DISCUSS (just kept for archiving) ## Section 6.2.4 About exporting the "traffic flows", a justification of not using IPFIX is required IMHO. Also missing the MAC address field as not all flows are IPv4 or IPv6 (LLDP, IS-IS, ARP, ...). ## Section 6.3.2 Why is the geo-location not implied by the IP address ? Or rather, how can it be derived if not based on the IP address ? Hence, why duplicating the information which is always bad for data consistency? # COMMENTS ## Abstract Unsure what a "YANG data diagram" is... Is it a well-known wording for YANG experts or is it "YANG tree diagram"? ## Section 4.1 Suggestion to use "I2NSF gauge" rather than "I2NSF counter" to represent processor temperature. ## Section 6.2.1 The use of "port" is unqualified and therefore ambiguous: is it a layer-4 port ? or an interface port ? Even if the reader may guess the former, let's remove the ambiguity. ## Section 6.2.3 Is there a definition of "sessions" ? I.e., is it a data plane TCP/UDP "connection" or a configuration plane connection ? ## Section 6.2.4 Here also, a qualification of the "port" is welcome. On which interval are the rates computed ? Since the beginning of the flow ? Last minute ? or ? s/arrival-speed/arrival-throughput/ ? Note: the above comments are also applicable in other places in the document. ## Section 6.3.1 Even if most (if not all) DoS are actually DDOS, would a section title of "DoS" be more generic ? ## Section 6.3.2 Should this section be renamed in "malware" ? As the 'virus' event can also be detected locally, is the IP flow information required or even available? Or are NSF never implemented on host for local host security ? What is the "host" here ? In which case is the "host" neither the source nor the destination IP ? Is there a reason why the geo-location is not included in other events ? (see also my DISCUSS point above as geo-location is probably derived from the IP addresses). ## Section 6.4.2 Does the "traffic" include only the data plane or also control/management plane ? Does it count the layer-2 framing ? s/disk-left/disk-space-left/ ? ## Section 6.5.1 Some explanations linking "deep packet inspection" to apparently local user actions will be welcome. For most readers, DPI is for transit traffic not for local actions. ## Section 6.6.1 Are the "drops" caused by policy ? or by hardware/resource error ? As mentioned above, the "peak" and "average" should be qualified by the measurement period. ## Section 8 s/identity ssl-flood/identity tls-flood/ Is there a reason to have a limited set of application protocol ? I.e., why including FTP and not NTP ? Or why defining any at all .. (except perhaps HTTP/HTTPS). For many operators, having separate counters for IPv4/IPv6/non-IP will be useful. # NITS ## Section 1 s/denial of service attacks (DoS)/denial of service (DoS) attacks/ ? ## Section 6.2.3 s/The number of session table exceeded the threshold/The number of sessions exceeded the table threshold/ ? ## Section 8 For "log-action", there is a mix of "action is block" and "action is discarded" (i.e., different tenses).
Benjamin Kaduk Former IESG member
Discuss [Treat as non-blocking comment] (2022-02-15 for -15) Sent
(1) I'm not sure I understand the motivation for recommending (in §6.3.4) that the HTTP Cookie header field be included in a notification about a Web Attack Event. In general, the cookie field can contain very sensitive information, including credentials, and it is very risky to be sending the cookies around outside of their primary protocol context. Perhaps, if we are fully confident that the NSF has correctly identified an attack, it might be useful to send the cookies around, but I think there are still some scenarios (e.g., a compromised end-user browser) where the cookies in an attack request are still confidential information that should not be disclosed. Could we say more about why it is recommended to always include the cookies or weaken the recommendation? (2) I'm not sure I understand the relationship between the different pieces of information listed in the information model (§6.7.1) for firewall counters. My understanding is that typically a firewall will function as if it were a "bump in the wire" on a particular wire, processing all traffic into and out of a given part of the network (at least on a particular interface), and that the internal network might contain multiple machines that reside on multiple network prefixes. So when we have the information model that looks to be the counters reported by a firewall security function, I don't know how to interpret fields like "Source IP address" and "Destination port", which are typically tied to a particular flow or machine, whereas the firewall covers many different flows and potentially many machines as well. Is the intent to report on firewall behavior on a per-flow granularity, akin to what IPFIX does? That seems likely to produce a very high volume of log information and it's not clear how useful it would be to the NSF data collector. The YANG data model uses a list with the policy name as the list key, indicating that perhaps the intent is to show what a given firewall policy has done, but (a) that should be made clear from the description in the information model, and (b) it still doesn't help relate the different 4-tuple components to each other. (3) The information model gives a list of DPI action types that's prefaced with "e.g.", indicating that it is giving examples only and is not comprehensive, but the dpi-type YANG typedef is modeled as an enumeration that does not allow extensibility for future values not listed here. This seems like an internal inconsistency that needs to be rectified, whether by claiming to be a comprehensive list or by switching the YANG to use extensible identities to represent the DPI action types. (4) Please confirm that we have achieved the intended level of consistency between the information model and the YANG data model, in light of the remarks in my COMMENT section around Sections 6.3.2 through 6.3.5, 6.4.3, and 6.5.1.
Alvaro Retana Former IESG member
No Objection (for -15) Not sent
Martin Vigoureux Former IESG member
No Objection (for -15) Not sent