Re: [netmod] system configuration/datastore and the keystore/truststore drafts

[Andy Bierman <[e-mail]>]

On Sun, Mar 26, 2023 at 7:04 PM Jan Lindblad <[e-mail]> 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) <
> rwilton=[e-mail]> 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 <[e-mail]>
> Sent: 26 March 2023 13:24
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://constructor.university/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>