Hi!
Thanks for all of the work and significant edits on draft versions -09 to -11.
To make thing easier to track, I'm starting a new thread on this -11 version of
the document to comment on any outstanding issues from my original AD review
(https://mailarchive.ietf.org/arch/msg/i2nsf/iNN0bkhm69GuhxnDXGQuPMK5EMs/).
Unless otherwise noted below, please consider previously feedback as resolved.
** Section 4.1. Editorial. A typo in the new text.
OLD
A system entity (e.g., NSF) first retains I2NSF monitoring data
inside its own system before emitting the information another I2NSF
NEW
A system entity (e.g., NSF) first retains I2NSF monitoring data
inside its own system before emitting the information to another I2NSF
** Section 4.1
For the utilization of the storage space for accumulated NSF
monitoring data, all of the information MUST provide the general
information (e.g., timestamp) for purging existing records, which is
discussed in Section 5.
I'm having difficulty understanding the guidance. What is the relationship
between the "general information" and the processes to purge existing records?
Is the guidance that "Accumulated NSF monitoring data MUST provide the general
meta-data described in Section 5"? If so, does that make sense for events,
records, and counters? It seems difficulty for counters.
** Section 4.1
This document provides a YANG data model in
Section 9 for the important I2NSF monitoring information that should
be retained. All of the information in the data model is considered
important and should be kept permanently as the information might be
useful in many circumstances in the future. The allowed cases for
removing some monitoring information include the following:
* When the system storage is full to create a fresh record
[RFC4949], the oldest record can be removed.
* The administrator deletes existing records manually after
analyzing the information in them.
I appreciate this text attempting to be responsive to my comment about
retention, but I think that it is both too prescriptive - the importance of the
data could be context dependent (not just on the kind of data, but where it is
deployed, say in a test lab) and keeping it permanently relative to those uses
cases doesn't consider the wide array of possible log retention policies. I
think it would be simpler to remain silent on the topic beyond "Local policy
and configuration will dictate the policies and procedures to review, archive
or purge the collected monitoring data."
** Section 6.1.2. Grammar. s/size of CPU used/CPU utilization/
** Section 6.3.1.
Note that rule-name is used to match a detected NSF event with a
policy rule in [I-D.ietf-i2nsf-nsf-facing-interface-dm], and also
that there is no rule-name in a system event.
What does the "... and also that there is no rule-name in a system event" mean?
Is this saying that this field is needed because the rule-name might not be
present in the contents of the system event?
** Section 6.3.2, 6.3.3, 6.3.4 and 6.3.5
-- Per "src-location", this text should likely read 'The geographic location
(e.g., country and city) of the src-ip field
-- Per "dst-location", this text should likely read 'The geographic location
(e.g., country and city) of the dst-ip field
** Section 6.3.2. s/of the packet/of the flow/ as it seems very unlikely a
virus is going to be trigged by a single packet (and network work based
inspection is going to analyze the entire stream/flow).
** Section 6.3.2. Typo. s/hided/hidden/
** Section 6.3.2. The YANG module has "leaf os" in i2nsf-nsf-detection-virus.
Is that something that should be reflected here in the information model?
** Section 6.3.4
-- Is there a reason why all of the fields start with "req-*" or "response-*",
except "request-method"? Wouldn't the pattern be for it to be called
"req-method"?
-- Is req-uri the "Request-URI" per Section 5.1.2 of RFC2616?
-- Since "uri-category" was removed from the YANG module, should it still be
listed here?
-- Recommend being more precise with the field names as follows:
OLD
* request-method: The method of requirement. For instance, "PUT"
and "GET" in HTTP.
* req-uri: Requested URI.
* response-code: The HTTP Response code.
* req-user-agent: The HTTP request user agent header field.
* req-cookies: The HTTP Cookie previously sent by the server with
Set-Cookie.
* req-host: The domain name of the requested host.
NEW
* request-method: HTTP method of the request. For instance, "PUT"
and "GET" in HTTP.
* req-uri: Requested URI.
* response-code: The HTTP response status code.
* req-user-agent: The HTTP User-Agent header field of the request.
* req-cookies: The HTTP Set-Cookie header field of the response
* req-host: The HTTP Host header field of the request.
-- Where a precise HTTP field name exists, it should be reflected in the YANG
description. For example, for leaf req-user-agent, the description should be
s/The request user agent/The User-Agent field of the request/ (or something
similar)
** Section 6.4.1.
-- Given the changes made to the YANG names, shouldn't "login-mode" be renamed
to "login-role"?
-- Editorial. s/Specifies the administrator logs in mode/Specifies the
privilege level of the user account/
** Section 13. Thanks for the new language on the issues with read access. I
would recommend on being more expansive with the concerns.
OLD
All of the readable data nodes in this YANG module may be considered
vulnerable in some network environments. Some data also may contain
private information that is highly sensitive to the user, such as the
IP address of a user in the container "i2nsf-system-user-activity-
log" and the container "i2nsf-system-detection-event".
NEW
All of the readable data nodes in this YANG module may be considered sensitive
in some network environments. These data nodes represent information
consistent with the logging commonly performed in network and security
operations. They may reveal the specific configuration of a network;
vulnerabilities in specific systems; and the deployed security controls and
their relative efficacy in detecting or mitigating an attack. To an attacker,
this information could inform how to (further) compromise the network, evade
detection, or confirm whether they have been observed by the network operator.
Additionally, many of the data nodes in this YANG module such as containers
"i2nsf-system-user-activity-log", "i2nsf-system-detection-event", and
"i2nsf-nsf-detection-voip-volte" are privacy sensitive. They may describe
specific or aggregate user activity to include associating user names with
specific IP addresses; or users with specific network usage.
** Section 13. Per the YANG security considerations template
(https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines), is there a
reason why not to use NACM? Specifically:
"The Network Configuration Access Control Model (NACM) [RFC8341] provides the
means to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol operations
and content."
The current text mentions the need to control read access, but the above
provides a tangible means to do so.
Regards,
Roman
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
