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