Re: [I2nsf] AD review follow-up on draft-ietf-i2nsf-registration-interface-dm-22

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

Hi Roman,
The revision for Registration Interface is done by Patrick and me:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-registration-interface-dm-23

I attach the revision letter.

If you are satisfied with this revision, please move it forward.

Thanks.

Best Regards,
Paul


On Thu, Jan 12, 2023 at 1:25 AM Roman Danyliw <[e-mail]> wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>