[I2nsf] AD review of draft-ietf-i2nsf-registration-interface-dm-21

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-i2nsf-registration-interface-dm-21.  More feedback is split into a two section: general comments on the document followed by specific section by section comments.

==[ General Comments
I appreciate that this document is intended to specify the registration interface of the I2NSF architecture.  Typically, when the primary intent of a document is to specify a YANG module most operational and architectural considerations can be covered elsewhere.  In my assessment, I2NSF is a special case.  This is a niche YANG module for a specific architecture. To ensure that it can be implemented in a secure and interoperable way, additional details need to be specified beyond what is in RFC8329.  Practically, there are no other documents in which to convey this information.  Additionally, what makes this document different than the other four YANG module documents is that it appears to be specifying interactions across administrative domains.  This suggests that even greater care needs to be taken with the Security, Operational, and Privacy Considerations.  To that end, few high-level comments:

** Architectural considerations.  

-- Who initiates the registration and update process?  Is this Security Controller or DMS initiated, or is it expected to be possible for either to do it?  My confusion originates from Section 3 saying the DMS “uses [the] Registration Interface to provide NSFs developed by the NSF vendor to Security Controller”, but Section 4 saying that “DMS registers NSFs and their capabilities with Security Controller via the registration interface” and Section 4.1 repeats “This submodel is used by DMS to register an NSF with Security Controller.”  Please be consistent and explicit.

-- In NETCONF/RESTCONF parlance, who is expected to be the client and server?

-- I don’t see it in the YANG module definition, but the text phrases things as if the DMS is serving the NSF to the Security Controller.  For example:

(a) Section 3. “Developer's Management System (DMS) in I2NSF framework is typically run by an NSF vendor, and uses Registration Interface to provide NSFs developed by the NSF vendor to Security Controller.”

(b) Section 3. “the I2NSF Registration Interface can be used as a standard interface for the DMSs to provide NSFs capability information to the Security Controller.”

(c) Section 3. “Security Controller needs to request DMS for additional NSF(s) that can provide the required security capabilities via Registration Interface.”

The text in (b) is clear in saying that the registration interface provide NSF capability information to the Security Controller.  (a) and (c) seem to suggest that the NSF itself is being shared through the interface.

-- I was under the impression that the DMS was providing “NSF capability information” so I was surprised to see instances of what appeared to be local provisioning information.  For example:
 
(a) Section 4.1.1.1 “The registration interface can control the usages and limitations of the created instance and make the appropriate request according to the status.)”

(b) Section 4.1.2.  The “NSF Access Information” (or grouping nsf-access-info per the YANG module) appears to specify the IP address of an NSF

(c) YANG.  rpc nsf-capability-query has the DMS returning nsf-access-info which is an IP address of an nsf.

Why would the DMS be privy to what appears to be local configuration information.  Does the DMS have a role in provisioning the NSF?  Is there any information about the Security Controller’s configuration stored on the DMS (beyond authorization or authentication information)?

** Operational considerations

-- What guides the cadence and workflow associated with the Security Controller getting updates on the NSFs?

-- How does the Security Controller discover the DMS?

** Security Considerations

-- Thanks for the YANG object level analysis.  Please also provide high-level analysis about the supply-chain risk presented by this architecture which has the Security Controller relying on a DMS.  What would be the impact to I2NSF if the DMS was not available?  If the DMS was compromised?  What does the DMS learn about the Security Controller’s configuration (and by proxy about the security architecture of the domain in which it is fielded) through this interface?

-- I recognize the boiler plate YANG security template on language on citing that TLS/SSH and that NETCONF/RESTCONF can restrict access, but this is generic.  Given the described architecture (which entails exchanging information that could affect security configurations across administrative domains) there needs to be more specific guidance on the trust and authentication/authorization models between the Security Controller and DMS.

** What does the YANG module for an “update” operation look like?  Registration is covered in Section 5.1.2.1 and Querying is in Section 5.1.2.2.
 
==[ Section-by-section feedback

The following are more detailed section specific feedback.

** Abstract.  Typo. s/for Registration Interface/for the Registration Interface/

** Section 1.  s/security controller/Security Controller/.  Additionally, as noted for the draft-ietf-i2nsf-consumer-facing-interface-dm, since RFC8329 doesn’t mentioned Security Controller and uses Network Management Operator System instead.  Please note their relationship.

** Section 3.

   In this case, DMS
      uses Registration Interface to update the capability of the NSF,
      and this update SHOULD be reflected in the catalog of NSFs.

If an update is going to occur, shouldn’t it be mandatory that the catalog is modified?

** Section 3.  Typo. s/from an I2NSF user, Security Controller/from an I2NSF user, the Security Controller/

** Section 4.  The operations summarized in bullets (1) and (2), appear to repeat the objectives 1 and 2 in Section 3?  Is there a reason to do that twice?

** Section 4.1.
 The NSF Name contains a unique name of this NSF with the
   specified set of capabilities.

-- Unique within the scope of all NSF’s published by the DMS?
-- I note that draft-ietf-i2nsf-capability-data-model provides no guidance beyond "The name of Network Security Function (NSF)", and on a registration operation is uses that definition.  As an side, on the rpc query response, there is normative language in the YANG module.

** Section 4.1.1.1. Should this “NSF Specification” include other dimensions like memory or disk?  These are exposed alarms in the monitoring-data-model.

** Section 4.1.1.1.

   This information represents the processing capability of an NSF.

This sentence summarized the “NSF Specification” as “processing capability”.  However the descriptive text notes that this sub-model element covers both “processing” and “bandwidth”.

** Section 4.1.1.1.
   Assuming that the current workload status of each NSF is being
   collected through NSF monitoring
   [I-D.ietf-i2nsf-nsf-monitoring-data-model], this capability
   information of the NSF can be used to determine whether the NSF is in
   congestion by comparing it with the current workload of the NSF.

Is this guidance only intended to cover “bandwidth”?  I ask because I don’t see a way to align the “% CPU load” metrics in the monitoring-data-model with the processing-average and processing-peak fields whose units are GHz.

** Section 4.1.1.1.

These two information can be
   used for the NSF's instance request.

-- What is an instance request?
-- Editorial.  "These two information" doesn't parse.

** Section 4.1.2.  NSF Access Information.  See earlier comments on not understanding why this information is in the model.  Setting that aside, and just thinking of this container as what is necessary to connect to an NSF over NETCONF/RESTCONF.  

-- Isn’t there also the possibility of various credentials being needed to make a connection?  Are they not represented for a reason?

-- Why are domain names not supported?

** YANG.  container processing

I believe this is intended to express the processing capability of the NSF.

-- Could the difference between “processing-average” and “processing-peak” be explained.  Is the latter expressing a concept like “Intel Turbo Boost”?

-- Could the kind of decision support this is driving be better explained.  I ask because I’m not sure that GHz is the right unit.  Comparing clock speed absent a lot of other factors doesn’t seem meaningful.  Off the top of my head (and I’m not proposing this), something like BogoMips or a benchmark seems more applicable.

-- How would some of these figures be relevant in a virtualized environment?

** YANG.  container bandwidth. Outbound/inbound-average and -peak field.

“The network bandwidth available to the NSF”

-- Is this measuring the capacity of the NICs, throughput to inspect/groom/filter a particular network load or the bandwidth of the links provisioned to the NSF?

-- If this is the provisioned bandwidth, please see my comments inquiring about the role of the DMS with provisioning information.
-- If this is measuring capacity, then “bandwidth” doesn’t seem like the right metric (maybe throughput)?  What would “peak” throughput mean?

** Section 7.  Please do not specifying normative behavior for the attacker (i.e., “The attacker MAY …”, say “The attacker may”).

** Section 7.

nsf-registration: The attacker MAY try to gather some sensitive
      information of a registered NSF by sniffing this.

Sniffing implies on-path inspection.  Is the intent different here?  Shouldn’t the use of TLS or SSH preclude that?  The subtext here is a controlling read-access to the DMS server (I think). Can the threat please be clarified?

** Section 7.  For the “readable node analysis”, the following assessment is used for the nsf-specification and nsf-capability-info:

The attacker MAY gather the {specification / capability information}
      information of any target NSF and misuse the information for
      subsequent attacks.

I would expect that knowing that a particular NSF is fielded by a controller is of interest to the attacker as described.  Is this architecture, is the information tied to the specific and capability information generic across all instances of that NSF for that vendor’s deployment base?

** Section 7.

   *  nsf-capability-query: The attacker MAY exploit this RPC operation
      to deteriorate the availability of the DMS and/or gather the
      information of some interested NSFs from the DMS.

If the DMS is a vendor, wouldn’t the product capabilities be public in some cases?  Would that be worth clarifying?

** Appendix A.  Step 5.

   5.  The NSF can have processing power and bandwidth.

Could this please be made more descriptive.

Regards,
Roman