On Sun, Mar 26, 2023 at 7:04 PM Jan Lindblad <[email protected]> wrote:
> 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. > > No customer would ever let us take away this tenet, no matter what RFC comes out. There are corner cases where a server is executing with a <running> datastore that does not pass all YANG constraints and all description-stmt semantics. For example, there are data models with top-level mandatory NP-containers. Loading the empty YANG module causes the datastore validation to fail. Our server has a mode where it will start with a bad <running> datastore and allow an operator to fix the config. No edit-config to running or commit will succeed unless all validation passes (that is specified in 6241). There are lots of complex implementation-specific ways to get the server datastores loaded at runtime. Code runs and then <running> is setup somehow. The idea that <running> must be totally empty unless a client has set the data seems to be an NMDA thing. IMO it is not a good idea to make NMDA even more complicated to handle minor corner-cases. 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 > > Andy > > > > > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
