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

From: [email-masked]
Date: Mon, 20 Aug 2018 10:20:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration WG of the IETF.

        Title           : Zero Touch Provisioning for Networking Devices
        Authors         : Kent Watsen
                          Mikael Abrahamsson
                          Ian Farrer
	Filename        : draft-ietf-netconf-zerotouch-23.txt
	Pages           : 87
	Date            : 2018-08-20

Abstract:
   This draft presents a technique to securely provision a networking
   device when it is booting in a factory-default state.  Variations in
   the solution enables it to be used on both public and private
   networks.  The provisioning steps are able to update the boot image,
   commit an initial configuration, and execute arbitrary scripts to
   address auxiliary needs.  The updated device is subsequently able to
   establish secure connections with other systems.  For instance, a
   device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040)
   connections with deployment-specific network management systems.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-23
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-zerotouch-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-23

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Aug 2018 17:28:23 +0000

All,

This update addresses the issues I raised over the course of the 
last couple weeks.  Please review and provide comments.

 - Andy, it's not specific in some ways, and yet specific in others.

 - Martin, I created an "Implementation Notes" section.

 - David (SecDir), please review the final diffs, especially 
   Section 5.6 and the Security Considerations sections.

 - Mahesh (Shepherd), let's give the WG at least a week to 
   review before pressing the button to publish it to the IESG.

Thanks,
Kent

===== original message =====

Abstract:

The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetconf-2Dzerotouch_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2UxXuTOrRIwqY5KeQFa-UsLNNhjY8ucSI09-gqmCkoI&s=ZN34jylWdiYshyDY0U03sNAez1BLE6do097NTHbOq_Y&e=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D23&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2UxXuTOrRIwqY5KeQFa-UsLNNhjY8ucSI09-gqmCkoI&s=qpRyKDmimUFa8CwHS3gpr0s4mI2VIpjiMBUL7PaqY8s&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetconf-2Dzerotouch-2D23&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2UxXuTOrRIwqY5KeQFa-UsLNNhjY8ucSI09-gqmCkoI&s=x0FGfhTf4hmbqRIXAgEqG1XJadCGXa4TFJh4UipvOKg&e=

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetconf-2Dzerotouch-2D23&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2UxXuTOrRIwqY5KeQFa-UsLNNhjY8ucSI09-gqmCkoI&s=p9_0mbhtuas_-0rXnxG3ahyEmbqIqGm-sb0x-QMpFD4&e=

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2UxXuTOrRIwqY5KeQFa-UsLNNhjY8ucSI09-gqmCkoI&s=vvu4mqjqq_gVoZTzUp17Ho_G9R0gyITDBL1ePW6Y5U8&e=

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=2UxXuTOrRIwqY5KeQFa-UsLNNhjY8ucSI09-gqmCkoI&s=WVxGo03FpNU0wfJwGh5jzY6uQETL8buqPNMPL68zj3o&e=

---

From: David Mandelberg <[email-masked]>
Date: Sat, 25 Aug 2018 20:10:41 -0400

Hi,

Thanks again for addressing all my -22 review comments. Here are a few 
more for -23:

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?

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

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

-- 
https://david.mandelberg.org/

---

From: Kent Watsen <[email-masked]>
Date: Mon, 27 Aug 2018 17:22:09 +0000

Hi David,

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

No problem.  The document is better for it!

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

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

Fixed.

Kent // author

---

From: David Mandelberg <[email-masked]>
Date: Tue, 28 Aug 2018 20:51:57 -0400

> other ways to reset itself (e.g., relaunch a VM).  Thoughts?

I think it's fine if boot images and logs are retained, and allowing for 
variation in how the device resets itself makes sense. I think the MUST 
NOT covers only half of what shouldn't be retained though. What do you 
think of this? (Feel free to change my wording, especially if you can 
think of something less vague than "behave as if".)

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), and MUST NOT enable the device to behave as 
if it were successfully configured.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 29 Aug 2018 16:33:59 +0000

Hi David,

> "Some state MAY be retained from the bootstrapping process (e.g., updated 
> if it were successfully configured."

Hmmm, how about we say that the remnants must be "inactive" like this?

   """
   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 be active in any way (e.g., no new configuration or running
   of software), and MUST NOT hinder the ability for the device to continue
   the bootstrapping sequence (i.e., process onboarding information from 
   another bootstrap server).
   """

Kent

---

From: David Mandelberg <[email-masked]>
Date: Wed, 29 Aug 2018 20:40:06 -0400

>     another bootstrap server).

I like that more than what I wrote!