Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-23.txt

[Kent Watsen <[e-mail]>]

Hi David,


> Thanks again for addressing all my -22 review comments. 

No problem.  The document is better for it!


> Section 5.6: "Hinder[ing] the ability for the device to continue the 
> bootstrapping sequence" was only part of why I asked about the error 
> cases. The other part is that I think there's a security risk in leaving 
> bootstrapping enabled after the device is partially/mostly configured, 
> since bootstrapping opens the possibility for various parties to change 
> the configuration. Is there a reason not to require devices to fully 
> rollback the configuration if there's an error after it's applied?

Why do you think the document allows this?  The beginning of s5.6 says:

   Some state MAY be retained from the bootstrapping process (e.g., updated boot
   image, logs, remnants from a script, etc.), however, the retained state MUST 
   NOT hinder the ability for the device to continue the bootstrapping sequence
   (i.e., process onboarding information from another bootstrap server).

Are you thinking that the MAY needs to be a MUST NOT?  This text (s5.6) used to
be much more explicit but need to undo the  configuration (I think I sent you 
that version), but others felt that it  was too proscriptive and, as the 
Implementation Notes section (at the very end of 5.6) says, the device may have
other ways to reset itself (e.g., relaunch a VM).  Thoughts?


> (nit) Section 9.8: "For best security, it is RECOMMENDED that owners 
> only provide signed data, for use with any source of bootstrapping 
> data". Using signed data all the time is fine, but I don't think 
> unencrypted signed data provides any additional security when using a 
> trusted bootstrap server, since that server can always remove the 
> signature and serve the same data unsigned.


Changed to:

     For best security, it is RECOMMENDED that owners only provide
     bootstrapping data that has been signed, using a private key that
     is not accessible to a network of questionable integrity, and
     encrypted, using the device's public key from its secure device
     identity certificate.



(nit) Section 9.11: "potential cause problems" should be "potential to 
cause problems".


Fixed.


Kent // author