Subject: [I2nsf] AD Review follow-up on draft-ietf-i2nsf-nsf-monitoring-data-model-11

From: Roman Danyliw <[email-masked]>
Date: Sat, 6 Nov 2021 01:41:28 +0000

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 13 Nov 2021 17:36:08 +0900

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-masked]> 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.
>
> 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
> 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."
>
> 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?
>
> -- 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.  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"?
>
> -- 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.
>
> ** Section 13.  Thanks for the new language on the issues with read
> access.  I would recommend on being more expansive with the concerns.
>
> OLD
>
> 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."
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 17 Nov 2021 22:52:11 +0900

Hi Roman,
Patrick and I have addressed all your comments and submitted the revision of
the NSF Monitoring Interface YANG Data Model Draft as follows:

https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-12

I attach a revision letter to explain my responses to your comments.

Thanks.

Best Regards,
Paul

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 17 Nov 2021 20:41:06 +0000

Hi Paul!

Thanks to you and Patrick for these edits published in -12.  They address my remaining AD review feedback.  I’ve requested an IETF Last Call for this document.

Regards,
Roman

From: Mr. Jaehoon Paul Jeong <[email-masked]>
Sent: Wednesday, November 17, 2021 8:52 AM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; skku-iotlab-members <[email-masked]>; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [I2nsf] AD Review follow-up on draft-ietf-i2nsf-nsf-monitoring-data-model-11

Hi Roman,

Thanks.

Best Regards,
Paul

On Sat, Nov 6, 2021 at 10:41 AM Roman Danyliw <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

OLD

NEW

** Section 4.1

** Section 4.1

** Section 6.3.1.

** Section 6.3.4

OLD

NEW

OLD

NEW

Regards,
Roman

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf