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 < jaehoon.p...@gmail.com> 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 <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
