I2NSF NSF Monitoring Interface YANG Data Model
draft-ietf-i2nsf-nsf-monitoring-data-model-20

[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?

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?

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.

Ben's original DISCUSS points were addressed. My comments were also addressed in -18

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.

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).

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?"

Thanks for addressing my discuss and comments.