[I2nsf] AD Review of draft-ietf-i2nsf-consumer-facing-interface-dm-23

[Roman Danyliw <[e-mail]>]

Hi!

I performed my AD review of draft-ietf-i2nsf-consumer-facing-interface-dm-23.  Thanks for the work on this information/data model.  Below is my feedback:

** Section 1.  Could a sentence or two here to explain what the Security Controller, the recipient of the Consumer-Facing Interface, does with this configuration information?

** Section 1.  Since the architecture and reference model of RFC8329 is being used, please provide bridging text to explain that "Security Controller" used in this document is equivalent to a "Network Operator Management System" (used in RFC8329).

** Section 1.
   Assuming that vendors also provide the
   front-end web applications to an I2NSF User, the Consumer-Facing
   Interface is required because the web applications developed by each
   vendor need to have a standard interface specifying the data types
   used when the I2NSF User and Security Controller communicate with
   each other using this interface.
...
The Consumer-Facing Interface would be built using a set of objects,
   with each object capturing a unique set of information from Security
   Administrator (i.e., I2NSF User [RFC8329])  

I'd like to clear up ambiguity on who is an "I2NSF User"?  Is it a "user" as in a human? Is it vendor provided tooling which converts user input into this standardized YANG module and sends it via the Consumer Interface to a controller?  Or is a "I2NSF User" both?

-- In this text there are references to "vendors ... provid[ing] the front-end web applications to an I2NSF User", implying that "I2NSF User" is a human, and the tooling to generate the YANG module is NOT part of the "I2NSF user"

-- This text also seems to equate a "Security Administrator", a human, to be being the "I2NSF User".

-- Section 3.1 of RFC8329 gives examples of "I2NSF Consumers" (not "I2NSF users") to be "video conference network management system", "enterprise network administrator and management systems", and "IoT management system" which seems to imply that it is both.  Figure 1 above this text seems to depict a flow between the I2NSF user directly to the Security Controller.  Therefore, unless a human is directly crafting YANG, there is likely some supporting technology that is considered the "I2NSF user". 

-- Section 6.1 of RFC8329 says "As a general principle, in the I2NSF environment, users directly interact with the I2NSF Controller."    

** Section 1.
   These policies can easily be
   translated by the Security Controller into low-level security
   policies.

I'm not sure it makes sense to characterize the policy translation as "easy".

** Section 3.  Editorial.
OLD
   A Policy object represents a mechanism to express a Security Policy
   by Security Administrator (i.e., I2NSF User) using Consumer-Facing
   Interface toward Security Controller; the policy would be enforced on
   an NSF.

NEW
A Policy object is a means to express a Security Policy set by a Security Administrator (i.e., I2NSF User) with the Consumer-Facing Interface.  It is sent to the Security Controller which converts it into an NSF-specific configuration via the NSF-facing interface for enforcement on the NSF.

** Section 3.  Editorial.
OLD
The resolution strategy is described in [I-D.ietf-i2nsf-capability-data-model] in detail.

NEW
The resolution strategy is described in Section 3.2 of [I-D.ietf-i2nsf-capability-data-model].

** Section 3.
            1) communication between two Endpoint Groups,
             2) for preventing communication with externally or
             internally identified threats, and 3) for implementing
             business requirement such as controlling access to internal
             or external resources for meeting regulatory compliance or
             business objectives.  An organization may restrict certain
             communication between a set of user and applications for
             example.  

-- What is an "endpoint group"?  It's explained later but not in this point in the document.  Please add a forward reference.

-- Per (3), isn't this entire interface about encoding "implementing business requirements"?

** Section 3.
            The threats may be from threat feeds obtained
             from external sources or dynamically identified by using
             specialty devices in the network.  

I didn't see a mechanism in the text for this dynamic identification.  The definitely of threat sources later in the document seems to reinforce the idea that this is externally sourced information.

** Section 3.
          Rule conflict analysis
          should be triggered by the monitoring service to perform an
          exhaustive detection of anomalies among the configuration
          rules installed into the security functions.

-- Does the "rule conflict analysis" happen on the Security Controller?

-- Please say more about the "monitoring service"

-- Please say more about "detecting anomalies".  Is this more than "rule conflict[s]"?

** Section 3.

A policy is a list of rules.

The text prior and Figure 2, just explained how a policy is much more than a rule.  Should it say, "A policy will contain a list of rules."

** Section 3.
   A Policy Rule may be related segmentation,
   threat mitigation or telemetry data collection from an NSF in the
   network, ...

This sentence doesn't parse but I don't understand it enough to provide an alternative.  

** Section 3.
 Event:    This field includes the information to determine whether
           the Rule Condition can be evaluated or not.  See details in
           Section 3.1.

What is the relationship between the Event and the rule Condition.  Section 3.1 seems to provide means to specify which system events and alarms are applicable, but it doesn't appear to have a dependency on the Condition and seems to be describing if the entire Rule should trigger.

** Section 3.

    This field contains all the checking conditions to apply
     to the objective traffic.  

Please restate to clarify "objective traffic" (vs. just traffic) and "checking conditions".

** Section 3.1

   The Rule could be activated based on a security event (i.e., system
   event and system alarm).  

This text states that that a "Rule _could_ be activated ...", suggesting that there is an alternative way to activate it.  Figure 4 doesn't seem to suggest that.  Should it read "The Rule is activated ..."?

** Section 3.2
   This object represents Conditions that Security Administrator wants
   to apply the checking on the traffic in order to determine whether
   the set of actions in the Rule can be executed or not.  The Condition
   Sub-model consists of three different types of containers each
   representing different cases, such as general firewall and DDoS-
   mitigation cases, and a case when the condition is based on the
   payload strings of packets.

-- The Condition model appears to have 8 different types of containers, not 3.

-- This sentence would benefit from editorial polish.  Consider:

NEW
The Condition object describes the network traffic pattern or fields that must be matched against the observed network traffic for the rule to trigger.  The fields used to express the required conditions to triggers the rule are organized around the class of NSFs expected to be able to observe or compute them. 

** Section 3.2
   Each containers have source and
   destination-target to represent the source and destination for each
   case.  

This statement seems only accurate for "container firewall".  For example "container ddos" and "anti-virus" (and a few others) doesn't seem have a source and destination.

** Section 3.2
   This field represents the general firewall case,
   where a security admin can set up firewall conditions using
   the information present in this field.  

What is a "general firewall case"?  Is this equivalent to saying that that the Security Administrator wants to describe network traffic with layer 3 or 4 header fields?  Currently, the text is restating the name of the container as the description.

** Section 3.2.  Per the ddos and anti-virus cases, please re-write this text to describe what each is doing.  Currently, the text is restating the name of the container.  Specifically, "This field represents the "condition for <name of container>, where a security amin can setup a <name of the container> condition using the information presented in this field."  Please also expand security admin.

** Section 3.  Per the payload case:
    This field contains the payload string information.
    This information is useful when security rule condition is
    based on the string contents of incoming or outgoing
    packets.

Recommend not using the term "string" since the data model says this is binary and many payloads are likely to be that too.

** Section 3.  Per the payload case:
   The name referring to the payload-groups defined
   and registered in the endpoint-groups.

This sentence doesn't parse.

** Section 3.  Per the voice case:
.  This information can be
   used to filter a caller id or receiver id in order to
   prevent any exploits (or attacks) of Voice over IP (VoIP)
   or Voice over Cellular Network (VoCN).  

No disagreement on the possibility describe here.  However, isn't filter only one of a number of actions that could be taken.  Why call out "filter" here?

** Section 3.  Per the context case:
   This field provide extra information for the
   condition for filtering the network traffic.  

Please re-phrase this as the sentence doesn't parse.

** Section 3.  Per the context case:
   This field contains the information obtained
   from threat-feeds (e.g., Palo-Alto, or RSA-netwitness).

--  Consider if you need to name the products as this might age the document in the future.  If so, please name them consistently.  "Palo-Alto" is a company, not a product, which doesn't hyphenate their name.  "RSA-netwitness" is "RSA Netwitness".

-- Additionally, why name these two vendors, instead of the three products/tools actually mentioned in the data model?

** Section 3. Per the context case:
       This information is useful when security rule condition is
       based on the existing threat reports gathered by other
       sources.

Shouldn't this read, "This field is used when the security ..."  

** Section 3.3.  Per Figure 6, it looks like specifying the both the primary and secondary action could be empty.  Is that intended?

** Section 4.
   The Policy Endpoint Group is a very important part of building User-
   Construct based policies.  

What are "User-Construct based policies" as opposed to just "policies"?

** Section 4.
   It is assumed that the information of Endpoint Groups (e.g., User-
   group, Device-group, and Location-group) such as the IP address(es)
   of each member in a group are stored in the I2NSF database available
   to the Security Controller,

-- What is an "I2NSF database"?  This is not an architectural entity described in RFC8329.

-- What does it mean the "information of Endpoint Groups such as xxx are stored in the I2NSF database ..."?  Isn't this information that is being sent by the I2NSF User to the Security Controller?

-- What is the interrelationship between user-group and the url-list?  The former lists IP addresses and the latter is list of URLs.  Are those IP address hosting those URLs?  From the examples in Section 8, it looks like there is no relationship between them, but that isn't stated here.

** Section 4.1.  Can a "User Group" please be defined.  The definition of "This object represents a User-Group" just repeats the name.  The description of the field names suggests they are an address range for a "user in the user group".  Where does the user information come from?  From the example in Section 8, it appears that this field groups is a means to label an IP address block.

** Section 4.3.
  This object represents a location group based on either tag or other
  information.  

What is the "tag" reference here?

** Section 4.3.  Geo-ip-ipv4 and Geo-ip-ipv6 are citing RFC8805.  My understanding of that specification is that it provides a way to bind a geographic name to an IP address.  I don't see anything in the Location object that ties a human readable geographic label to an IP address.  Is the related geography in the Name field?

** Section 4.4.
   url:      This field represents the new URL added by a user to the
             URL database.

-- What is user is being referenced here?  

-- What is a "URL database"?

** Section 5.  Even with the detailed descriptions in Section 5.1. and 5.2, it isn't clear what the relationship is between the information in the thread-feed and the payload-content objections.  Does the thread-feed describe the malicious activity and the payload-content is a capture of what it looks like on the wire?

** Section 5.
OLD
   The threat prevention plays an important part in the overall security
   posture by reducing the attack surfaces.  This information could come
   from various threat feeds (i.e., sources for obtaining the threat
   information).

NEW
The Threat Prevention model describes information obtained from threat feeds (i.e., sources for obtaining the threat
   information).

** Section 5.1.

Description:  This is the description of the threat feed.  The
             description should have the clear indication of the
             security attack such as attack type (e.g., APT) and file
             types used (e.g., executable malware).

Editorial.  I found the naming convention a bit confusing.  In my experience, a thread feed is sometimes a list of indicators of compromise (IOC) tied to a particular threat (e.g., one feed for a list of domains names or file hashes tied to a given threat actors).  Other times, it is a series of "objects" (IOCs, descriptions, rules) which are a collection of malicious activity, not necessarily related, which capture one publisher's aggregated view of what threat to watch for.  This description seems to assume it is only the former.  This would be worth explaining.

** Section 5.1 and Yang threat-prevention/description.  The description needs further specification.
Information model says:
   Description:  This is the description of the threat feed.  The
             description should have the clear indication of the
             security attack such as attack type (e.g., APT) and file
             types used (e.g., executable malware).

Yang says:
           leaf description {
             type string;
             description
               "This represents the descriptions of a threat-feed.  The
                description should include information, such as type,
                threat, method, and file type.  Structured Threat
                Information Expression (STIX) can be used for
                the description of a threat.";
             reference
               "STIX: Structured Threat Information Expression for the
                description of a threat.";
           }

-- It isn't clear how this field (description) can be a "clear indication" without providing a structured format for each of the required fields.  While STIX is mentioned, it doesn't appear to be required.

-- If STIX is preferred or suggested, please be clear on which STIX objects should be used.  Is it STIX XML or JSON?

-- Please provide a reference to STIX

-- Is the intent to represent an XML blob in the string data type here?  Is it up to the implementer to recognize free form text vs. JSON vs. XML?

** Section 5.1.

Signatures: This field contains the threat signatures of malicious
             programs or activities provided by the threat-feed.  The
             examples of signature types are "YARA", "SURICATA", and
             "SNORT" [YARA][SURICATA][SNORT].  

I'm confused by this description as I can't find where in this field the "threat signatures of malicious programs" is represented.  This field appears to be conveying an enumerated type.

** Section 5.1.
             "Signatures" should be
             kept carefully in a secure manner.  The secure keeping of
             "Signatures" can be performed by Defense in Depth (DID)
             [DID] or Distributed Ledger Technology (DLT) such as
             Blockchain [Bitcoin].  The details of keeping "Signatures"
             securely are out of scope in this document.

-- Per the caution of keeping signature in a "secure manner"?  What additional security properties or controls is that suggesting beyond everything else in the data model?  Put in another way, what's special here?

-- What does it mean to say that "signature can be performed ..."  Given that this is out of scope, I recommend just dropping the sentence.

** Section 5.1.

   With the
   obtained threat signatures, the I2NSF User can deliver them to the
   Security Controller.  

How are these signatures being delivered to the controller? Is it with this Yang module?

** Section 5.1.
   Note that signature-set in I2NSF Capability
   [I-D.ietf-i2nsf-capability-data-model] is the setting of signatures,
   which means the configuration of signatures for Intrusion Prevention
   System (IPS).  On the other hand, signature-type in Consumer-Facing
   Interface is the type of signatures (e.g., YARA signatures, SNORT
   signatures, and Suricata signatures).

-- Can the text "setting of the signatures" be rephrased, as I don't understand what it means.

-- From this text it isn't clear what link is being drawn between the capability model and this data model.  

** Section 5.2.

   This object represents a custom list created for the purpose of
   defining an exception to threat feeds.  

Can you please clarify, what is an "exception to the threat list"? Is that something that is on the thread list but should be ignored?

** Section 5.2
This represents the description of how the payload
             content is related to a security attack.

Is the referenced "security attack" the one described it the name field?  Does this imply additional requirements for the semantics of the name field?

** Section 5.2.
   Content:  This contains the payload contents, which are involed in a
             security attack, such as strings.

-- Typo. s/involed/involved/

-- What are "strings" in the context of the payload contents?  Do you mean "strings" as in those dumped from a malware file?  Readable text extracted from a session stream?

** Section 6.  Thanks for explaining the role of NACM.  Is this guidance specific to the I2NSF interface or a generic example of using NACM?  Ask because, I didn't see anything specific to I2NSF here.  Was there a WG push to include this non-I2NSF guidance? Section 11 already says that NACM can be used.

** Section 6.
   Then, the
   user can simply use an account of root or admin user for the access
   control for the module of the I2NSF Consumer-Facing Interface 

What is the origin of these users names?

** Section 7.  Typo. s/provide the YANG data model of I2NSF/provide the YANG data model of the I2NSF/

** Section 7.
   The transformation of the
   information model is performed so that this YANG data model can
   facilitate the efficient delivery of the control or management
   messages.

This statement doesn't seem right.  Per RFC3444 cited in Section 1, informational models "are protocol neutral".  That is, they are not capable of being interoperable without translation into a data mode.  It isn't about "efficient delivery".  I recommend removing this sentence.

** Section 7.
   With the YANG data model of I2NSF Consumer-Facing Interface, this
   document suggests use cases

Are there use cases or examples?  This is a bit pedantic, but to me this data model suggests a lot more use cases than are described in Section 8. 

** YANG.  identity rate-limit.  I appreciate that this identity is in other I2NSF models.  How does the Security Controller know what is the associate rate-limit threshold is?

** YANG.  identity signature-type.  The references for signature-yara, signature-snort and signature-suricata are all of the form "<tool name>: <tool name> signatures are explained".  There are not references.

** YANG.  identity threat-feed-type.  How is this used in this YANG module?

** YANG.  identity device-type.
         Note that the device type of either a source
          or destination can be known with the help of DHCP
          Fingerprinting and the interaction between an NSF and a DHCP
          server.

This behavior seems out of scope for this module as it is prescribing NSF behavior.

** Both of these comments are related to similar questions posed in the information model:
-- YANG.  grouping user-group.  How is the alignment to users done?  The model appears to represent only a label (name) to describe an IP address range, with the possibility of MAC addresses.

-- YANG.  grouping device-group.  Does the ip-address represent the services hosted on the application port, or the outbound connection the ip-address-info will be making?

** YANG.  Per the fields under "rules":

-- Does the rule name need to be unique?

-- Would there be a desire to version at the per rule basis (e.g., Snort/Suricata's "rev:" rule option)?

** YANG.  container range-port-number.
-- what are the semantics of both the start-port-number  and end-pot-number being empty?

-- If the start-port-number is set, but the end-port-number is not, does this assume "[start-port-number,65555]?  Same question situation for a set end-port-number, but not start-port-number?

** YANG.  container ddos.
-- leaf flow-rate-threshold.  The associated unit of time is not specified.  Is it flows/per second?

-- RFC9244 is an entire YANG module on conveying DoS telemetry.  Are there any additional metrics worth adding here?  Is there a way to reuse this feature rich module?

** YANG.  container anti-virus.  This container not adequately specified.

                 "The type or name of the files to be excluded by the
                  antivirus. This can be used to keep the known
                  harmless files.
                  If the value starts with a regular expression (e.g.,
                  '*.exe'), the antivirus should interpret it as a
                  file pattern/type to be excluded.
                  If the value does not start with a dot (e.g.,
                  'example.exe'), the antivirus should interpret it as
                  a file name/path to be excluded.";

-- If regular expressions are permitted, please cite which flavor regex -- POSIX?  PCRE?

-- "*.exe" is not a valid regular expression (in POSIX/PCRE) to evaluate a filename that ends with a string ".exe".  

-- Per the guidance, "if the value doesn't start with a dot (e.g., example.exe)", the cited example in the parenthesis doesn't appear to be demonstrating what the text is describing.  Also the format described in the line above, "*.exe" also doesn't begin with a dot.

-- The text mentions that paths can also be included?  Is that restricted to a local filesystem.  What are the expected path separators?  Can protocol schemes be uses (e.g., smb://myfiles/*.exe)

** YANG.  container anti-virus.  Specifying malicious files to block by hash names seems common.  Did the WG consider it?

** YANG. leaf-list source-id, destination-id, user-agent.  What information is this representing?  The text says "The security policy rule according to a <insert field name>."  

** YANG.  device-type/device
                   "The device attribute that can identify a device,
                    including the device type (i.e., router, switch,
                    pc, ios, or android) and the device's owner as
                    well.";

-- The list of device examples doesn't seem consistent with the defined ones defined for "base device-type" (i.e., computer, mobile-phone, etc).  For example, there is not distinction made for mobile operating systems (IOS or Android).  Likewise, there is only network-infrastructure-device (not, router, switch)

-- How does this field capture the device owner?

** YANG.  url-group.

Is there a reason that the "leaf-list url" can't be of type "uri" instead of "string"?

** YANG.  list payload-content

-- Typo. s/Desecribe/Describe/

-- How should multiple instances of the "content" field be interpreted? Does every instance of "content" need to be somewhere in the session stream, regardless of order, or does order matter?

-- From where in the packet or stream is this payload considered?  Is it everything after the transport layer header?

** Section 8.1.  Per Figure 19:
-- The descriptive text says this example is showing the registration of new end-points, but the <name> says "security_policy_for_blocking_sns".  Where is the blocking behavior specified?

-- The values of the <url> are supposed to be URLs.  What is specified here is not a valid URL (there is not scheme)

-- What is the relationship is being expressed between the ip addresses in <user-group> and those in <device-group>?  

-- What is the relationship among the IP addresses in <user-group>, <device-group> and the <url-group>?

Same questions for Figure 20.  Thanks for providing both an IPv4 and IPv6 example.

** Section 8.3.  Typo. s/coming from from/coming from/

** Section 8.3. Typo. s/seucurity/security/

** Section 8.3.
      The Source is "malicious-id".  This can be a single ID or a list
       of IDs, depending on how the ID are stored in the database.  

How would the "malicious-id" be registered?  Would that be an IP address via a <user-group>?

** Section 8.4.
   The destination is set as "web_server01".  

This destination is not reflected in Figure 23.

** Section 8.4.  Typo. s/nsfs/NSFs/

** Section 8.4.  Typo. s/secuiy/security/

** Section 8.4.

   4.  The Source is all sources which send abnormal amount of packets.

How would this 1000/pps would be calculated relative to "all sources which send abnormal traffic"?  I'm keying on the way in which a distinction would be made that traffic is abnormal.

-- is there a per source IP counter to measure 1000/pps rate?

-- is there 1000/pps rate set for the destination and traffic is dropped after regardless of the number of sources?

What normative text should be referenced to explain how these rates are computed?

** Section 11.  Editorial.

OLD
Writing to almost any element of this YANG
      module would directly impact on the configuration of NSFs
NEW
Writing to almost any element of this YANG
      module would directly impact the configuration of the NSFs implementing the security policy.

** Section 11.  Per "Writing to almost any element of this YANG module would ... impact the configuration of NSFs, e.g., ...  rendering useless trained statistics or artificial intelligence models", consider something weaker such as s/rendering useless.../reducing the efficacy of statistics or artificial models built on historical data./

** Idnits output said:

==[ annotated snip from idnits ]==
  ** Obsolete normative reference: RFC  793 (Obsoleted by RFC 9293)

[Roman] Action: replace RFC793 with RFC9293.

  ** Downref: Normative reference to an Informational RFC: RFC 8329

[Roman] Action: RFC8329 doesn't need to be normative.

  ** Downref: Normative reference to an Informational RFC: RFC 8805

[Roman] Action: Check my comments on how RFC8805.  If this draft stays, it will be called out in IETF LC (and no action for the authors).

  == Outdated reference: draft-ietf-tcpm-rfc793bis has been published as RFC
     9293

[Roman] Action: replace with RFC9293.

  -- Possible downref: Normative reference to a draft: ref.
     'I-D.ietf-tcpm-rfc793bis'
 
[Roman] Action: replace with RFC9293.
==[ end snip ]==