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

From: Martin Bjorklund <[email-masked]>
Date: Wed, 12 Nov 2014 13:19:17 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> 
> 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!

-01 takes care of most of my issues, thanks!  See below for some
remaining questions.

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

No, the question was really what you mean with "IDevID entity".  Maybe
it would be better to replace 

  "IDevID entity & associated intermediate certificate(s)"

with simply "IDevID".  The text below expands on what the IDevID
contains.

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

So a vendor can never build a device that is supposed to be used only
in the "locally administered network", i.e., rely on DHCP?

This MUST can never really be verified - one way for a device to
comply with this MUST is to put a dummy URI there that doesn't resolve
to anything useful.  So why do we have this as a MUST?

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

In general I like documents that have clear terminology, and
specifically a list of the terms they import, and the new terms they
define.  It minimizes the risk of confusion.

In this particular case, the term "DevID Module" is defined in
802.1AR (note, not IDevID Module which -01 uses).  As an alternative
to a terminology section, maybe you can just write

   "outside the DevID module (as defined in [...])"

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

Hmm, maybe it is just me, but if I see the term "immutable" I think it
means that the info cannot be changed at all.  What you are really
saying is that the list of trusted certs and uids should be
protected.

BTW, s/<nsm>/<nms>/ in the figure,

and s/This certificates/These certificates/ in the text.

Also, you have:

   In order to authenticate the device, the NMS MUST possess the X.509
   certificate for the trust anchor leading to the device's entity
   certificate.

what is the "device's entity certificate"?   (I couldn't find this
term in the IEEE spec; I assume you mean the IDevID cert).

> >o  sec 7.2
> >
> >  The term "unique-identifier" is pretty generic.  Should it simply be
> >  "device-identifier" instead?
> 
> 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.

The doc currently has "unique identifier", "unique device identifier"
and "device unique identifier".  I think the unqualified "unique
identifier" should be avoided, and that the XML element in the
Configlet should use be named "unique-device-identifier".

BTW, remove section 7.2 - the YANG model is gone.

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

Maybe, or a set of versions.

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

The question is if it is necessary for this spec to say MUST be exact
match.  I think we should leave this to vendors to define.

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

The text is:

   However, it is possible to substitute a Configlet created for a
   device with a different Configlet created for the same device.
   Generally, unless imposed by the Configuration Signers, there is no
   limit to the number of Configlets that may be generated for a given
   device.  This could be resolved, in part, by placing a timestamp into
   the Configlet and ensuring devices do not load Configlets older than
   some amount, but this requires the devices have an accurate clock
   when validating a Configlet and for Configuration Signers to not sign
   a Configlet when another Configlet is still active.

So are you saying that any vendor can reolve this by placing a
timestamp in the Configlet?  I don't think so.  I think you mean that
this could have been resolved by placing a timestamp..., but since
this would require devices to have accurate clocks, this solution was
rejected.

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

No, I think this just shows how little I know about XML
Signatures... Particularly, can the <Signature> element be placed
anywhere in the XML document?  Are all Transforms supported?  Are all
DigestMethods supported?  Etc.  If the answer is that this obvious
from the XML Signature spec, then that is fine.

/martin