Hi Roman, Thanks for your 2nd detailed review on RI. Patrick and I will work for the revision with your comments.
Thanks. Best Regards, Paul 2023년 1월 11일 (수) 오전 11:25, Roman Danyliw <r...@cert.org>님이 작성: > Hi > > I performed an AD review on draft-ietf-i2nsf-registration-interface-dm-21 ( > https://mailarchive.ietf.org/arch/msg/i2nsf/82QQzd1J6A8xqlyv5ZBRn4_xZCs/). > The authors produced at -22 in response. Thank you! > > To make it easier to track the remaining issues, I've created this new > thread. The following is feedback on -22: > > ** Architectural considerations #1 (Flows between the Security Controller > and DMS) > > Thanks for the new text in -22 to clarify that the Security Controller is > the NETCONF/RESTCONF server and the DMS is the client. With this > understanding I have a few more questions centered around the three > objectives described in Section 3. > > (a) Section 3. “Registering NSFs with the I2NSF framework” > > -- How does the DMS know that it’s supposed to connect to the Security > Controller? For -21: > > [-21] How does the Security Controller discover the DMS? > => [PAUL] This information should be known when an agreement for > subscribing to the > security service is approved between the I2NSF User and the vendor. The > vendor should > provide the DMS information to the Security Controller for such > connection. The method of > exchanging this information is out of the scope of this document. > > Can these out-of-scope assumptions please be documented. > > -- How is the credentialling provisioned so that the DMS can log-in to the > Security Controller? > > (b) Section 3. “Asking DMS about some required capabilities”. > Additionally, Section 5.1.2.2 notes that “In this case, Security Controller > makes a description of the required capabilities using this module and then > queries DMS about which NSF(s) can provide these capabilities.” > > -- If the Security Controller is the NETCONF/RESTCONF server and the DMS > is the client, what is the mechanism by which questions are posed to the > DMS? Does the Security Controller use the RPC mechanism defined in Section > 5.1.2.2 (with the DMS operating a registration server interface)? > > -- If the Security Controller use using the RPC mechanism, is the > following newly added text in Section 1 entirely accurate: > > Section 1. “Note that in either NETCONF [RFC6241] or RESTCONF [RFC8040] > parlance through the I2NSF Registration Interface, the Security Controller > is the server, and the DMS is the client because the Security Controller > and DMS run the server and client for either NETCONF or RESTCONF, > respectively.” > > -- If the DMS is running a Registration Interface already to satisfy > responses to the RPC mechanism, why can’t this same mechanism be used to > satisfying the “Registering NSFs with the I2NSF Framework” step? It would > simplify the architecture. > > ** Architectural Considerations 2 (scope of the DMS) > > Per -21: > > Per the local provisioning information. > > (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)? > > -21 response: > => [PAUL] The DMS is the system developed by the vendor that provides and > deploys the > NSF. The NSF information is unknown to the Security Controller until it is > registered by > the DMS. Hence, the DMS knows the local configuration information and > informs the > Security Controller of the information. > > Thanks for this explanation and the addition of name and password into > nsf-access-info. I still have some confusion on the architecture and > semantics of these fields, and the implications they may have for the > security and operational considerations of I2NSF registration interface. > In re-read RFC8329 and the model here, I feel that we need either tighter > scoping or at least more explanation on the role of the DMS. > > -- Looking at nsf-specification and nsf-access-info, it appears that two > classes of information are being shared. The former describes a capability > of the NSF, and the latter is a provisioning information. Is there an > assumption that the DMS is both providing the software for and the NSF > _and_ also operating the NSF used by the Security Controller? This seems > to be the case in your response. My scan of RFC8329 and the descriptive > text of the DMS here does not explicitly say that. Are self-hosted or > third party-hosting options of an NSF precluded by this architecture? > > -- If the DMS “provides and deploys the NSF” how is the orchestration of > the NSFs expected to occur. When the DMS returns the nsf-access-info of an > NSF, does that mean it is ready to be fielded in production by the Security > Controller? Let’s say that a Security Controller no longer needs an NSF, > how does it turn it off? > > ** Section 5.1.2.1. and 5.2 nsf-access-information. > > Thanks for the edits here from -21. > +--rw name? string > +--rw password? ianach:crypt-hash > > leaf username { > type string; > description > "The user name string identifying the credentials for the > authentication."; > } > leaf password { > type ianach:crypt-hash; > description > "The password for the username for the authentication. > Any plain-text password must be converted to a hashed value > as soon as possible"; > } > > I wanted to discuss the degree of flexibility warranted here. > > -- I asked about this credentialing information in my -21 feedback. The > above fields were added. I want to make sure that the WG wants to have > this credential management in-scope. It would also be possible to say that > this is handled out of band, pre-negotiated with every DMS. > > If credential management will be in scope, these would be other matters to > consider: > > -- If SSH is used, should a list of authorized-keys also be supported? > > -- Should there be flexibility for this information to be entirely omitted > and these credentials to be provisioned out-of-band, in addition, to an > in-band mechanism specified in the module? > > -- If this mechanism is used to give the Security Controller the password > for the first time, doesn’t “plaintext” ($0$) have to be used? If the DMS > provided a hashed password, it isn’t clear what the Controller would do > with it. > > -- Should there be guidance stating that password resets and associated > credentials changes? > > ** Section 7. Remind the reader of the risks of externally operated NSFs > already documented in Section of RFC8329. > > ** Section 7. Editorial. Please do not use the word “illegally” in the > text here to describe the attacker behavior. > > Thanks, > Roman > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: paulje...@skku.edu, jaehoon.p...@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
