Re: [Netconf] few comments on zerotouch-13

[Andy Bierman <[e-mail]>]

On Wed, May 10, 2017 at 12:51 PM, Kent Watsen <[e-mail]> wrote:

>
>
>
>
> > 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?
>
>
>

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




> > Andy
>
>
>
> Kent
>
>
>

Andy


>
>
>
>
> On Tue, May 9, 2017 at 4:00 PM, Kent Watsen <[e-mail]> wrote:
>
> Hi Andy,
>
>
>
> > I am trying to understand the zerotouch draft.
>
> >
>
> > I find it to be very implementation-specific, and not suited for
>
> > modular servers.
>
>
>
> 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?
>
>
>
>
>
> > It is assumed the entire configuration (modules, features, deviations,
> etc)
>
> > 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?
>
> > This does not seem to be supported at all.
>
>
>
> 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.
>
>
>
>
>
> > 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?
>
>
>
> 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;
>
> >      must "../zerotouch-information" {
>
> >
>
> > 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.
>
>
>
>
>
> > 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.
>
>
>
> 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
>
>
>
>
>