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

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

Hi Roman,
If you are satisfied with this revision, could you put this Registration
Interface draft into the IESG telechat agenda?

Thanks.

Best Regards,
Paul

On Tue, Nov 8, 2022 at 5:47 PM Mr. Jaehoon Paul Jeong <
[e-mail]> wrote:

> 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
>>
>