Re: [netconf] ietf crypto types - permanently hidden

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: Martin Bjorklund <[e-mail]>
> Sent: 07 May 2019 13:19
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
> "Rob Wilton (rwilton)" <[e-mail]> wrote:
> > Hi Kent,
> >
> > The problem that I have with <generate-key> generating configuration
> > directly in <running> is that <running> on the device is now different
> > from what the management system thinks should be in <running> on the
> > device.
> >
> > I.e. it breaks the architectural simplicity that it is only the client
> > that controls what goes into in <running>, e.g. perhaps that can be
> > summarized by this flow:
> >
> > "Update client's desired    ->   "Push to
> > config"                         <running>"
> >           ^                        |
> >           |                        \/
> > "Client notified of         <-   "Apply config,
> > changes in <operational>"       <operational> updated"
> >
> >
> > However, I would not be opposed to allowing <generate-key> create
> > configuration that is persisted separately from <running> and injected
> > into <intended> (e.g. merged with <running>)
> 
> But this isn't really allowed by the architecture in 8342, imo.  If this
> would have been the case, we'd have another box with config going into
> "intended".  8342 allows "configuration transformations" between running
> and intended.

I'm not sure.  The definition of a configuration transformation is quite broad:
   o  configuration transformation: The addition, modification, or
      removal of configuration between the <running> and <intended>
      datastores.  Examples of configuration transformations include the
      removal of inactive configuration and the configuration produced
      through the expansion of templates.

In the NMDA discussions, we considered the idea of a template on the device that injects configuration into intended, and this case doesn't seem miles away from there.

However, I'm not sure that now is the right time for a discussion for what transformations between <running> and <intended> are allowed.  If we can agree on a solution that doesn't require it, and doesn't update <running>, then I would probably be OK with that as well.

> 
> > , hence allowing leaf-refs
> > in config validation to work as expected.  I think that this would
> > allow device reboot to work as expected.
> >
> > If the clients would like to see the keys in the configuration then
> > they can monitor <operational> (or <intended>), and then add the keys,
> > either in raw form, or encrypted in some way.  But I still think that
> > it is architecturally cleaner if it is always the client that updates
> > the <running> configuration and never the device.
> 
> I agree.  I think it would be worthwile to explore the "non-action-based"
> solution that Rob proposed.  Is there anything in that solution that
> doesn't work?
> 
> 
> /martin

Thanks,
Rob

> 
> 
> 
> >
> > Thanks,
> > Rob
> >
> >
> >
> > From: netconf <[e-mail]> On Behalf Of Kent Watsen
> > Sent: 03 May 2019 17:24
> > To: [e-mail]
> > Subject: Re: [netconf] ietf crypto types - permanently hidden
> >
> > I had an idea last night that might inch us closer to a solution.
> >
> > Essentially, the generate/install-key operations always populate
> > <operational>, even for keys that are not-hidden, but then a follow-up
> > operation (something like <copy-config>) replicates the not-hidden key
> > in <operational> to <running>.  Two options:
> >
> > 1) A regular-access admin executes the actions to generate the key,
> > get a CSR, configure a resulting signed certificate, etc. and then, as
> > a second step later in time, a special-access admin replicates the key
> > to <running> (perhaps using standard <get-confg> and <edit-config>),
> > so that it can be included in a standard backup and restored to *any*
> > device (since this key is "not-hidden", it isn't encrypted with a
> > device-specific key and hence can be migrated).
> >
> > 2) A regular-access admin executes the actions to generate the key,
> > get a CSR, configure a resulting signed certificate, etc. and then, as
> > a second step (ideally immediately after), the regular-access admin
> > executes a command like <copy-config>, but rather than copying the
> > entire datastore, it just copies a subtree.
> >
> > Neither option seems great.  #1 is unappealing being it necessitates
> > coordination between clients.  #2 is unappealing because defining a
> > generic operation for this special case seems too much.
> >
> > IMO, allowing <generate-key> to create the configuration directly is
> > the only client-friendly answer.
> >
> >
> > Kent // contributor
> >