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
