Rob, Jürgen, Kent, WG, I am strongly opposed to giving up the idea that running must always be valid. This is one of the landmark properties that has made NETCONF the most useful management interface for network automation ever. For anyone not up to that, we already have SNMP and there is also a wide assortment of REST-based APIs out there.
I'm slightly appalled :-) that dropping this tenet is even discussed. In particular, I find it strange that such a small stone in one shoe would make us consider abandoning the whole trip. I'm no crypto expert and know little about how TPM modules work, but I was under the impression that part of the beauty with TPMs was that you would *not* copy keys around in the rest of the system. Instead you'd just refer to the keys in the TPM. This is similar to how you'd typically refer to hardware in slots. So if we treat TPM keys like they were hardware, we are back to our usual discussion about how to treat validity of running with respect to hardware. Either servers reject references in running to pieces of hardware that happens to be missing at this point in time (which may make it hard to install backups taken earlier, if the hardware setup has changed since), or servers accept references to pieces of hardware that are currently missing, and just mark them as operationally down. No need to change any RFCs to go with either of these approaches, I believe, and certainly not break fundamentals. Does this make sense, or is there a crypto angle here that I am missing? Best Regards, /jan > On 27 Mar 2023, at 02:01, Rob Wilton (rwilton) > <[email protected]> wrote: > > Hi Jürgen, Kent, > > If we can take that interpretation (and I agree I think that was the spirit > of how I thought that NMDA works, particularly for templating and inactive > configuration). > > However, my concern comes from the MUST in this paragraph of RFC 8342 (and > RFC 7950 also states that <running> must always be valid): > > 5.1.3. The Running Configuration Datastore (<running>) > > The running configuration datastore (<running>) is a configuration > datastore that holds the current configuration of the device. It MAY > include configuration that requires further transformation before it > can be applied, e.g., inactive configuration, or template-mechanism- > oriented configuration that needs further expansion. However, > <running> MUST always be a valid configuration data tree, as defined > in Section 8.1 of [RFC7950]. > > And the current version of the system datastore draft > (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/), 5.1. > Conceptual Model of Datastores, has text like: > > All above three types of system configurations will appear in > <system>. Clients MAY reference nodes defined in <system>, override > values of configurations defined in <system>, and configure > descendant nodes of system-defined nodes, by copying or writing > intended configurations into the target configuration datastore > (e.g., <running>). > > Servers MUST enforce that configuration references in <running> are > resolved within the <running> datastore and ensure that <running> > contains any referenced system configuration. Clients MUST either > explicitly copy system-defined nodes into <running> or use the > "resolve-system" parameter. The server MUST enforce that the > referenced system nodes configured into <running> by the client is > consistent with <system>. Note that <system> aware clients know how > to discover what nodes exist in <system>. How clients unaware of the > <system> datastore can find appropriate configurations is beyond the > scope of this document. > > But, if the WG agrees that for NMDA, the actual validation happens on > <intended> and not <running> then I understand that to mean that <running> on > its own may not be valid, and it is only "implicitly valid" after doing the > processing between <running> and <intended> and <intended> must always be > valid. > > Further, I think that this means that there isn't any requirement (from a > validation correctness point of view) to require system configuration to be > copied into <running>. Of course, there may be other reasons why a client > may want system configuration to be copied into <running>, e.g., so that it > can be returned in a get request of <running>. > > If the WG agrees that this is the right direction then I think that it would > be helpful for the system configuration datastore to perhaps update (or > clarify) section 5.1.3 of RFC 8342, and perhaps provide an updated diagram > with how the system datastore fits into the picture. I think that there > would be further updates required to the system configuration datastore draft > to clarify the expected behaviour, and we should also think carefully about > the text and perhaps examples in the truststore/keystore drafts (since they > currently state that the keys/certificates must be copied into <running>, and > I think that we are saying with NMDA that this is not required). > > Thanks, > Rob > > >> -----Original Message----- >> From: Jürgen Schönwälder <[email protected]> >> Sent: 26 March 2023 13:24 >> To: Rob Wilton (rwilton) <[email protected]> >> Cc: [email protected] >> Subject: Re: [netmod] system configuration/datastore and the >> keystore/truststore drafts >> >> Rob, >> >> my reading of Figure 2 of RFC 8342 is that validation happens on >> intended and not on running. I assume the system config is folded in >> between running and intended. This seems to be inline with the >> approach taken by the system config draft. This, of course, leaves is >> open what actually happens if keys are removed and cause a subsequent >> validation error. Ideally, such a transaction key removal transaction >> should fail, but whether this will be enforced if the transaction >> takes place outside the configuration management system may be a bit >> wishful thinking. >> >> /js >> >> On Sun, Mar 26, 2023 at 04:28:46PM +0000, Rob Wilton (rwilton) wrote: >>> Hi, >>> >>> I'm in the process of AD reviewing Kent's keystore and truststore drafts in >> NETCONF. >>> >>> In both of these drafts, there is a desire to be able to use keys or >> certificates that are managed on the device, potentially as part of a TPM, >> and yet be able to reference those keys/certificates from the device >> configuration. There is also some reference to how this configuration may >> work with the system datastore. >>> >>> https://www.ietf.org/archive/id/draft-ietf-netconf-keystore-27.html#name- >> support-for-built-in-keys gives an example. >>> >>> Looking at the current version of the system datastore, >> https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/01/, my >> understanding is that this draft reinforces the requirement that <running> is >> always valid. Hence any data nodes in the <system> datastore, that are >> referenced from the configuration in the <running> datastore, MUST also be >> copied into <running>, so that it validates. Unreferenced descendant >> configuration (that won't stop <running> from validating) can be left in >> system, which is then merged with <running>, and validated as part of >> <intended>. >>> >>> This is the approach that the keystore/truststore explains. However, there >> is separately the issue that the build in keys and certificates may be >> updated >> via an out of band process, such that the current keys/certificates are >> stored >> on the device, and a stale copy of the keys/certificates ends up in the >> running configuration. The keystore/truststore draft mitigates this by >> stating >> that if the key/certificate config differs between <running> and <system>, >> then the values in <running> are ignored and the values in <system> take >> priority. However, my understanding is that this behaviour is the reverse of >> what we normally expect when merging configuration in the <running> and >> <system> datastores, where configuration in <running> overrides >> configuration in <system>. Ultimately, I think that this means that we would >> need special handling for key/truststore configuration rather than just >> following the normal behaviour. >>> >>> Hence, I wonder whether we are making this more complex than >> necessary. Rather than requiring that <running> is always independently >> valid from <intended>, then would it not be simpler to allow <running> to >> have invalid configuration but always require that whenever <running> is >> changed then <intended> is updated and must always be valid. This would >> allow <running> to reference configuration in <system> without requiring it >> to be copied into <running>. >>> >>> I still think that we should allow the configuration to be copied into >> <running> for clients that also want <running> to be validate independently >> from <intended>, but otherwise, the requirement of copying keys are >> certificates into running doesn't seem ideal. >>> >>> Any thoughts? >>> >>> Regards, >>> Rob >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Jürgen Schönwälder Constructor University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <https://constructor.university/> > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
