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

[Roman Danyliw <[e-mail]>]

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