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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Roman,
Here is the revision of Registration Interface YANG Data Model:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-22

Patrick and I have addressed all your comments.
I attach the revision letter.

Thanks.

Best Regards,
Paul

On Thu, Oct 27, 2022 at 4:34 AM Roman Danyliw <[e-mail]> wrote:

> 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
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>