Subject: [Netconf] few comments on zerotouch-13

From: Andy Bierman <[email-masked]>
Date: Mon, 8 May 2017 11:45:18 -0700

Hi,

I am trying to understand the zerotouch draft.

I find it to be very implementation-specific, and not suited for
modular servers.

The container bootstrap-information only supports a monolithic server image.
It is assumed the entire configuration (modules, features, deviations, etc)
is irrelevant because it is hard-coded into the monolithic boot image.

What if a server is modular and the YANG modules, revisions, features, and
deviations
come from a bootstrap library config instead of hard-wired into a static
image?
This does not seem to be supported at all.

All the generic script stuff seems very implementation-specific as well.
I don't see the standards value of supporting pre and port bootstrap scripts
using an opaque scripting language.  Why isn't this just part of the
opaque bootstrap sequence? Why is it configurable?

Extra must-stmt:

 leaf owner-certificate {
      type pkcs7;
      must "../zerotouch-information" {

The zerotouch-information leaf is mandatory true so the must-stmt is not
needed.

Action notification:
What is the protocol interaction model for this action?
Who invokes it?  Why are the NETCONF error-tag status values ignored and
hard-coded
status values like 'parsing-error' and 'post-script-error' used?
It looks like config is being passed in container ssh-host-keys and
container trust-anchors.

Is the 'device-list' normal config=false data that is present on the server?
And only accessible via a normal NETCONF or RESTCONF session, after the
device
has booted OK?

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 May 2017 23:00:28 +0000

Hi Andy,

> I find it to be very implementation-specific, and not suited for

What do you mean by modular servers?  I can tell you that it has been implemented on a Juniper device that is internally a composition of virtual machines and containers.  For this device, the "software image" contains also the software for the other components as well.  If this isn't suitable, then the pre-configuration script can be used to cover other cases.

> The container bootstrap-information only supports a monolithic server image.

True, but see above comment.  Putting software images to the side momentarily, how is this modular server managed, does it have a single NC/RC interface?

> is irrelevant because it is hard-coded into the monolithic boot image.

I'm not 100% sure what this means, but I don't think it's true.

> What if a server is modular and the YANG modules, revisions, features, and deviations
> come from a bootstrap library config instead of hard-wired into a static image?

In the world of *zero* touch, I think that it is very safe to say that devices in their factory default setting have a known/static initial state.  Certainly, the server can install some add-on packages that grow the number of modules it supports.  Juniper does this also.  The pre-configuration script is well suited to installing such add-on packages, that is, just before the device attempts to commit the configuration, which may attempt to configure these add-on packages.

> All the generic script stuff seems very implementation-specific as well.

How is "generic" implementation-specific?  ;)    Of course, if the device can't support executing scripts, then it's options are limited.  For what it's worth, we didn't have scripts at first, but one operator interaction caused us to add the post-configuration script and another operator-interaction caused us to add the pre-configuration script.  This just goes to show that the scripts are useful, but not needed in all use cases.

> opaque bootstrap sequence? Why is it configurable?

What is "opaque bootstrap sequence"?  How else would the device obtain these scripts?  Why aren't the scripts part of the initial configuration? - because the scripts are only executed during the zerotouch bootstrapping process, they have no general value in the ongoing management of the device.

> The zerotouch-information leaf is mandatory true so the must-stmt is not needed.

Right you are.  There used to be an optional field called "signature" that this must expression used to depend on, but the signature was rolled into the new zerotouch-information pkcs7 artifact, and I didn't catch this when moving things around.

> Who invokes it?  Why are the NETCONF error-tag status values ignored and hard-coded
> It looks like config is being passed in container ssh-host-keys and container trust-anchors.

This action emulates the device sending RC notifications, which it can't do here because the device is the RC-client (the bootstrap server is the RC-server).  So this action is used to workaround this (note: RPCs have been used to deliver notifications by many other protocols).  This action is invoked only by the device (recall, ietf-zerotouch-bootstrap-server only defines a device-facing RC API, only devices are ever expected to use it).

I don't believe that any error-tags are ignored or hard-coded, in particular, if the device's invocation of the action causes an error on the bootstrap server, I'd expect a standard RC error to be returned.  That said, I think you're referring to the "notification type" enumeration, which has values like 'parsing-error' and 'post-script-error'.  What's wrong with these?

Yes, the special notification "bootstrap-complete" can pass the device's SSH host key and/or TLS server certificate.  How the bootstrap server consumes these values depends on implementation.  In some cases, I've seen the bootstrap server save these values and, in other cases, I've seen the bootstrap server pass these values to an NMS so that it can save the values.  In either case, the ability for the device to pass these values is critical from a security perspective in some scenarios.

> Is the 'device-list' normal config=false data that is present on the server?

Again, this module only defines a "southbound" API from the bootstrap server to devices.  Surely one can imagine the bootstrap server also having a "northbound" API whereby it can be configured and thus affect what data is visible to devices, but that API is out of scope for this I-D.  Makes sense?

> And only accessible via a normal NETCONF or RESTCONF session, after the device
> has booted OK?

I'm not sure what this means.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 May 2017 10:49:17 -0700

Hi,

I guess I will wait to see an open-source implementation to see how this
draft works.

Andy

On Tue, May 9, 2017 at 4:00 PM, Kent Watsen <[email-masked]> wrote:

> What do you mean by modular servers?  I can tell you that it has been
> implemented on a Juniper device that is internally a composition of virtual
> machines and containers.  For this device, the "software image" contains
> also the software for the other components as well.  If this isn't
> suitable, then the pre-configuration script can be used to cover other
> cases.
>
>
>
>
>
> True, but see above comment.  Putting software images to the side
> momentarily, how is this modular server managed, does it have a single
> NC/RC interface?
>
>
>
>
>
> In the world of *zero* touch, I think that it is very safe to say that
> devices in their factory default setting have a known/static initial
> state.  Certainly, the server can install some add-on packages that grow
> the number of modules it supports.  Juniper does this also.  The
> pre-configuration script is well suited to installing such add-on packages,
> that is, just before the device attempts to commit the configuration, which
> may attempt to configure these add-on packages.
>
>
>
>
>
> How is "generic" implementation-specific?  ;)    Of course, if the device
> can't support executing scripts, then it's options are limited.  For what
> it's worth, we didn't have scripts at first, but one operator interaction
> caused us to add the post-configuration script and another
> operator-interaction caused us to add the pre-configuration script.  This
> just goes to show that the scripts are useful, but not needed in all use
> cases.
>
>
>
>
>
> What is "opaque bootstrap sequence"?  How else would the device obtain
> these scripts?  Why aren't the scripts part of the initial configuration? -
> because the scripts are only executed during the zerotouch bootstrapping
> process, they have no general value in the ongoing management of the device.
>
>
>
>
>
> > Extra must-stmt:
>
> >
>
> > leaf owner-certificate {
>
> >      type pkcs7;
>
> Right you are.  There used to be an optional field called "signature" that
> this must expression used to depend on, but the signature was rolled into
> the new zerotouch-information pkcs7 artifact, and I didn't catch this when
> moving things around.
>
>
>
>
>
> > Action notification:
>
> This action emulates the device sending RC notifications, which it can't
> do here because the device is the RC-client (the bootstrap server is the
> RC-server).  So this action is used to workaround this (note: RPCs have
> been used to deliver notifications by many other protocols).  This action
> is invoked only by the device (recall, ietf-zerotouch-bootstrap-server
> only defines a device-facing RC API, only devices are ever expected to use
> it).
>
>
>
> I don't believe that any error-tags are ignored or hard-coded, in
> particular, if the device's invocation of the action causes an error on the
> bootstrap server, I'd expect a standard RC error to be returned.  That
> said, I think you're referring to the "notification type" enumeration,
> which has values like 'parsing-error' and 'post-script-error'.  What's
> wrong with these?
>
>
>
> Yes, the special notification "bootstrap-complete" can pass the device's
> SSH host key and/or TLS server certificate.  How the bootstrap server
> consumes these values depends on implementation.  In some cases, I've seen
> the bootstrap server save these values and, in other cases, I've seen the
> bootstrap server pass these values to an NMS so that it can save the
> values.  In either case, the ability for the device to pass these values is
> critical from a security perspective in some scenarios.
>
>
>
>
>
> Again, this module only defines a "southbound" API from the bootstrap
> server to devices.  Surely one can imagine the bootstrap server also having
> a "northbound" API whereby it can be configured and thus affect what data
> is visible to devices, but that API is out of scope for this I-D.  Makes
> sense?
>
>
>
>
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 10 May 2017 19:51:41 +0000

> I guess I will wait to see an open-source implementation to see how this draft works.

An odd response.  Did I not answer your questions?

Kent

On Tue, May 9, 2017 at 4:00 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 May 2017 13:04:36 -0700

> An odd response.  Did I not answer your questions?

I don't see any mention of the "notification" action in sec. 7.
There are no examples of actual messages in sec. 7

Andy

---

From: Kent Watsen <[email-masked]>
Date: Thu, 11 May 2017 19:29:30 +0000

Hi Andy,

> I don't see any mention of the "notification" action in sec. 7.
Please see Section 7.3, step #3.

> There are no examples of actual messages in sec. 7
Examples are in Sections 9.2 and 10.2.

Kent