Subject: Re: [Netconf] review of draft-ietf-netconf-zerotouch-00

From: Kent Watsen <[email-masked]>
Date: Wed, 22 Oct 2014 03:32:49 +0000

A late response, but I've been focused on call-home and server-model...and
there were very few comments on zero-touch.  Anyway, here goes!

Kent

>o  sec. 1.4
>
>         Vendors are the de facto Configuration Signer
>         for the devices it manufactures, but may delegate that role to
>         external Configuration Signers.
>
>  What eactly do you mean with "de facto Configuration Signer" in this
>  case?

"de facto " == preordained root of trust.  The vendor itself is the
ultimate root of trust for the devices it manufactures.  Is there a better
way to say this?

>o  sec. 1.4
>
>  Also mention boot images in your list and in the diagram.

Ah yes, boot-images came in late and I missed adding them here.

Fixed in my local copy.

>o  sec. 2
>
>     This section describes the service
>     interface a Configuration Server must implement as well as what's
>     needed for transport security.
>
>  s/must/MUST/ ?

Unclear to me, but if you're calling it out now, I'll make the change to
be safe.

>o  sec 2.1
>
>  The term IDevID is used for the first time here.  It would probably
>  be a good idea to mention this term in a Terminology section.

Can I add a ", which is described in Section 4.2." instead?

This draft doesn't have a terminology section as of yet...
  - actually, I don't any of my drafts do

>o  sec 2.3
>
>   Therefore, it is RECOMMENDED for
>   Configuration Servers to support transport-level encryption.
>
>  Doesn't this contradict section 2.1 which says that https MUST be
>  supported?
>
>  Maybe you mean that it is RECOMMENDED that _devices_ use
>  transport-level encryption?

Yes, or even more specifically, that only "https" URIs are used (no "http")

Fixed.

>o  sec 2.4
>
>    An expiration policy is needed to limit how long a Configuration
>    Server needs to retain a configuration and, in turn, how many
>    configurations it might need to retain at a given time.
>
>  I do not understand this sentence.  Why is the expiration policy
>  needed?  What does the number of configs it retains has to do with
>  anything?

To your point, it's not germane to the focus of the draft, but I did
receive a comment from someone who was concerned that the Configuration
Server would have to hold onto all Configlets (and boot-images) for
perpetuity.

Rather than remove the section from the draft, can we provide the above
context so as to clarify why it's mentioned?

>o  sec 3.
>
>  Terminology:  "Configuration Signer" vs. "Configlet Signer".

Fixed this and all other instances of "Configlet Signer"  (now they all
say "Configuration Signer")

>o  sec 4.2
>
>  The picture says "IDevID entity".  What is this entity?

The line is intended to be expanded to read "IDevID entity *certificate*
and associated intermediate certificates". I'm trying to economize space
so it'll fit within the 72-column limit.

Or is your question more generally what is an IDevID, as defined in the
subsequent paragraph?

>o  sec 4.2
>
>   Devices supporting ZeroTouch MUST be pre-provisioned with one or more
>   URIs for Internet-based Configuration Servers.
>
> Why is this a MUST?  (or why "one or more"?).  It seems to me that
> the DHCP option could be used instead of manual pre-provisioning.
>
> Do you expect these config server URIs to be part of the normal
> config?  See more below.

The DHCP option is only effective for the "locally administered network"
use case (see section 1.3).  When the network is administered remotely,
the DHCP option is very unlikely to be set and therefore the device will
have no resource but to fallback to trying URIs.  Makes sense?

Instead of "one or more" I could put "at least one" - is it better?

>o  sec 4.2
>
>    confidentially and not available outside the DevID module
>
>  What is "DevID module"?

This sentence is based on Section 6.2.5 (Storage) of the 802.1AR spec,
which that sentence references just before the section you clipped out.
It refers to the cryptographic boundary defined by the specification.

Two options:
1. Call out more specifically section 6.2.5
2. Replace the term "IDevID module" with simple text meaning the same thing

>o  sec 4.3
>
>  The test is: [if running config != factory default, boot normally]
>
>  So if the user has done any local configuration, e.g. configured the
>  Configuration Servers, it means that zerotouch won't be used?

Correct.  At that point the device has been *configured* and thus
zero-touch is disabled.

>o  sec 4.3
>
>  I think that the picture and text could use some numbering of the
>  steps to make it easier to follow, i.e., number ot match the text
>  with the diagram.

Yes, a lot of feedback on this diagram being difficult to follow.  Your
suggestion is the best I've heard yet, so I'll try it.   Won't be easy,
though, as I've already at the 72-column limit...

Added https://github.com/netconf-wg/zero-touch/issues/1   (since I'm not
doing it right now)

>o  sec 4.3
>
>  You introduce the term GUID w/o explanation.

True, I refer to it as UID earlier.

Fixed.

>o  sec 4.3
>
>   However, since the Configlet configured
>   the device to "call home," upon entering its normal operating mode,
>   the device immediately begins trying to establish a call home
>   connection, as specified by the Configlet.
>
>s/However, since the Configlet configured/
>  However, if the Configlet configured/ ?
>
>It seems to me this process can be used w/o call home as well.

Yes, since we changed the Configlet payload to anyxml, there is nothing
left saying that the Configlet has to result in a call-home connection,
though that is the entire point of the draft.   Nonetheless, I'll update
the text to be more accommodating...

>o  sec 5.1
>
>  You have the list of expected device identifiers in immutable
>  storage - that seems to indicate that it not possible to ever add a
>  new device!

I think you mean section 5.2.  Nonetheless, to your point, the diagram is
trying to express storage attributes from the perspective of an entity
outside the module (the NMS in this case).   An outsider cannot write the
immutable storage and  cannot read or write secure storage.   Anyway,
that's what I meant by this diagram and also the one in section 4.2.  Is
it OK?

>o  sec 6.1.
>
>  s/preconfigure/configure/ ?

Fair enough.  Though it needs to be done prior to the commencement of
ZeroTouch, I agree that it doesn't need to be hinted at here this way.

>o  sec 6.2
>
>  Should this step also be in the diagram in 1.4?

Added!

>o  sec 7.1.
>
>  The second paragraph should probably be removed.

This was a hold-over from when the Configlet did assert call-home config.

Instead of deleting the paragraph, I instead now have:

   The Configlet data-model, defined by the YANG module in Section 7.5,
   contains information for the device to ensure that it's safe for it
   to load the configlet (target-requirements) along with a payload, the
   configuration the device is to merge into its running datastore.

   In order for the device to call-home, the configuration contained
   within the Configlet MUST at least configure a local user account and
   configure the connection information for the NMS the device is to
   call home to.  This configuration MAY use IETF-defined modules "ietf-
   system" in [RFC7317] and "ietf-netconf-server" in
   [NETCONF-SERVER-MODEL].

Better?

>o  sec 7.2
>
>  The term "unique-identifier" is pretty generic.  Should it simply be
>  "device-identifier" instead?
>
>  Also, here you are using "DevID".  Did you mean "IDevID"?  If not,
>  you need to explain the difference.

True, but "unique-identifier" or "UID" is used throughout the draft, and
both the text and the YANG module state exactly what it needs to be.

As for DevID vs IDevID. The IEEE spec defines the general DevID, which is
then refined into IDevID ('I' for "Initial") and LDevID ('L' for "Local").
 So, it's not overstepping too far.  Still, for ZeroTouch, I think we're
only ever interested in the IDevID and so I'll s/ DevID/ IDevID/g  (3
substitutions)

>o  sec 7.2
>
>         If the device finds that it is
>         not running the correct version of software, it can pull the
>         correct version from the Configuration Server.
>
>  "can pull" - section 4.3 had "MUST".

Good catch, this is fixed.

>o  sec 7.5
>
>  You define a "container configlet".  With YANG version 1, I think it
>  is better to follow the restconf example and define a grouping with
>  this container:
> 
>     grouping configlet {
>       container configlet { ... }
>     }
>
>  and explain that the grouping is not intended to be used.
>
>  (side note: maybe we should have an explicit statement for this in
>  YANG 1.1; it seems we have the need for it, since we use this hack
>  already in several places)

This dovetails into Andy's comments captured in the IETF90 minutes:

    "This creates a top-level mandatory node, it should be presence
container."

To be honest, I still don't get what the issue is.   We never expect a
NETCONF server to advertise this YANG module, so there should be no
concern for anyone thinking this is actually configuration.    Here, I'm
only using YANG to describe a file format, in which this top-level
container is very much needed.   I mentioned before that I could instead
use XSD to describe this XML file-format  (no JSON!).   I only picked YANG
initially because I very much was trying to reference the ietf-system and
ietf-netconf-server modules, but now that is no longer the case, I'm
beginning to think XSD is more appropriate. What do you think?

Added https://github.com/netconf-wg/zero-touch/issues/2

>o  sec 7.5, leaf unique-identifier
>
>  This means that it is not possible to have a single configlet for
>  all devices of a certain type.  Is this necessary?

Correct, and I wish it weren't the case, but without this there is an easy
substitution attack whereby a nefarious individual obtains a Configlet for
an authorized device and yet loads it into an authorized device.   The
only way to remove this constraint is to assert that only HTTPS (not HTTP)
is used and that the device authenticates the HTTPS server's certificate.
But doing this would complicate use of the ZeroTouch DHCP option, as then
the locally-deployed HTTPS server would have to have a certificate signed
by a CA known to the device (e.g., VeriSign, RSA, Thwart, etc.), but it
might be difficult for vendors to know-of or even keep-up with this
changing list.  This is why HTTP (without the 'S') is supported at all, to
simplify use in internal networks.

>o  sec 7.5, leaf software-version
>
>             "The device MUST must be running this version of software.
>              The value for this field is device-specific, but it MUST
>              be an exact match (e.g., 14.1R2.5)";
>
>  Why is this MUST be exact match?  It seems inflexible to me.  Since
>  the field is vendor specific anyway, why not let the match
>  algorithm be vendor specific as well?
>
>  Also, should this really be mandatory?

This is a tough question.

On one hand, we have cases where the Configlet is using vendor-specific
data-models (not ietf-system and ietf-netconf-server), and hence is
specific to a software release...or at least generated using a specific
revision of the vendor-specific module.   It *might* work with other
versions, we only know for sure that it will work on the specific version.
If the NETCONF server is namespace-aware, it likely results in it only
supporting exact matches.   Of course, SDO-defined modules are used, there
is a greater likelihood that more than one version can support it.

Then there is the case of expectations, the NMS very likely requires the
device to be running a very specific software version, as it is what has
been qualified for production.   If the device doesn't so up with an exact
match, the NMS will have to first push the correct image to the device.
Yes, it could be done, but why should NMSs have to do this if the network
infrastructure can do it for them?

Thoughts?

>o  sec 8.2
>
>  Remove the text about how a timestamp *could* be used?

But this is the Security Considerations section and clock-based attacks
are not uncommon.  What is your suggestion?

>o  signing / encrypting configlets
>
>  I think you need to specify somewhere how the signature is inserted
>  into the configlet XML document.  Currently the only hint the reader
>  get is from an example...
>
>  Same for encryption, and in this case the example is also tbd.

Did you see sections 7.3 (Signature) and 7.4 (Encryption)?

Are you looking for something like a tutorial that starts with an unsigned
Configlet and then signs it with a key and then shows the resulting signed
Configlet?

I agree that the encryption example needs to be filled in.

Added https://github.com/netconf-wg/zero-touch/issues/3

>o  sec A.1
>
>  This comment is related to the netconf-server data model.
>
>  In this example teh configlet pushes a config with host keys,
>  referred to by file name.   How does the device get these keys?

This was discussed in yesterday's virtual meeting  - now there will be
config=false lists of the server's SSH host-keys and TLS certificates, so
that this can then become an instance-identifier.

>Editorial:
>----------
>
>o  sec. 1.4
>
>OLD:
>
>         The device
>         is preconfigured with a secure device identity, for
>         Configuration Servers URIs, and certificates for Configuration
>         Signers and Configuration Servers it trusts by default.
>
>NEW:
>
>         The device
>         is preconfigured with a secure device identity,
>         Configuration Servers URIs, and certificates for Configuration
>         Signers and Configuration Servers it trusts by default.

Fixed.

>o  sec 2
>
>  s/The unique identifies/The unique identifier/

Had gotten this one already, but thanks anyway

>o  sec 2.2
>
>OLD:
>
>   The Configuration server SHOULD to provide some user-facing interface
>   to enable to the end-user to provide a Configlet and, optionally, an
>   bootimage file.
>
>NEW:
>
>   The Configuration server SHOULD provide some user-facing interface
>   to enable the end-user to provide a Configlet and, optionally, a
>   bootimage file.

Egads, how did that one get past the editor?  ;)

>o  sec 3.4
>
>s/may prefer a this role be/may prefer that this role be/

Fixed.

>o  sec 4.3
>
>   s/MAY also try both the raw/MAY also try the raw/

Fixed.

>o  sec 5.1
>
>s/either a SSH/either SSH/

Fixed.

>o  sec 7.5, leaf configuration
>
>OLD:
>              support both the following standard data-models:
>
>NEW:
>
>              support the following standard data-models:

Fixed.