Hi Roman,
Thanks for your detailed and constructive comments and questions.
I will address yours on the revision.
Thanks.
Best Regards,
Paul
On Thu, Oct 27, 2022 at 12:34 PM Roman Danyliw <r...@cert.org> 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
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf
