Hi Roman, I sincerely appreciate your valuable comments on the I2NSF Monitoring Interface Data Model Draft. My Ph.D student Patrick and I are working for the revision of this draft. I will be able to post the revised draft by November 23, 2021.
I will post the revised drafts of NSF Capability and NSF-Facing Interface Data Models today. Thanks. Best Regards, Paul On Sat, Nov 6, 2021 at 10:41 AM Roman Danyliw <[email protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
