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

From: [email-masked]
Date: Mon, 09 Mar 2015 16:56:42 -0700

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

        Title           : Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)
        Authors         : Kent Watsen
                          Joe Clarke
                          Mikael Abrahamsson
	Filename        : draft-ietf-netconf-zerotouch-02.txt
	Pages           : 31
	Date            : 2015-03-09

Abstract:
   This draft presents a technique for establishing a secure NETCONF
   connection between a newly deployed IP-based device, configured with
   just its factory default settings, and its rightful owner's network
   management system (NMS).

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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-zerotouch-02

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

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: Tue, 10 Mar 2015 00:18:18 +0000

Hey all,

If interested in zero touch, please take notice of this update!  Changes
include:

   o  Renamed Configuration Server to Bootstrap Server, a more
      representative name given the information devices download
      from it.

   o  Replaced the concept of a Configlet, by defining a southbound
      interface for the Bootstrap Server using YANG. This also nicely
      removes the need to support XMLSIG.

   o  Removed the IANA request for the boot-image and configuration
      media types, as the Bootstrap server's southbound interface

      has explicit resources for each, and then some.

Hoping to receive comments on list or in Dallas!

Cheers,
Kent

On 3/9/15, 7:56 PM, "[email-masked]" <[email-masked]>
wrote:

>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 10 Mar 2015 09:14:31 +0000

Kent,

Thanks for posting the draft.

First, one minor nit.

2.2 Point 6 s/This This/This/

Point 7. I am confused about "in addition to those the device knows of by
default". I thought Bootstrap servers are either learnt through DHCP (via
its BOOTP extensions) or explicitly configured. If you are referring to
configured Bootstrap servers, then I guess they are not "default".

Could the certificate be issued/signed by the owner of the device or does
it have to be signed/issued by the vendor only?

In container boot-image you talk about a signature leaf. It is the first
time you are talking about how the signature is being constructed. Could
you mention this up front in your document when you talk about Bootstrap
servers and how those images are being signed?

Section 4.2 NIt. s/Following are the actions performed by the device when
bootstrap off/Following are the actions performed by the device when
bootstraping off/

Step 5 in that section. The check is really for whether the boot image is
new/different from the one currently running. Can you update the text to
reflect that?

 5. Need to install boot image?  ------> Install and reboot

Section 5.2. Point 3. Login credentials. Can you clarify this sentence
"These credentials may be, for instance, a private key used for SSH or
TLS client authentication." Specifically, how are login credentials
established when doing TLS client authentication.

Section 5.3. s/NSM/NMS/

Thanks.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Mar 2015 00:08:06 +0000

Hi Mahesh,

Thank you for your review.  My replies to your comments are below.

[Mahesh] Point 7. I am confused about "in addition to those the device
knows of by default". I thought Bootstrap servers are either learnt
through DHCP (via its BOOTP extensions) or explicitly configured. If you
are referring to configured Bootstrap servers, then I guess they are not
"default".

[KENT] I guess it needs some word-smithing, as it is meant to be as you
say.  

[Mahesh] Could the certificate be issued/signed by the owner of the device
or does it have to be signed/issued by the vendor only?

[KENT] This is what this solution requires in order for the device to
authenticate that the configuration was prepared by its rightful owner.
To support an owner-signed certificate, the device would have to be
manufactured with an owner-specific trust-anchor (e.g., custom SKUs) - I
don't think we want to propose that here, do you?

[Mahesh] In container boot-image you talk about a signature leaf. It is
the first time you are talking about how the signature is being
constructed. Could you mention this up front in your document when you
talk about Bootstrap servers and how those images are
 being signed?

[Kent] good catch.  I'm aware that I left that undefined in my rush to get
it out the door.    It is a detail that can be filled-in in the next
update.

[Mahesh] Step 5 in that section. The check is really for whether the boot
image is new/different from the one currently running. Can you update the
text to reflect that?
 5. Need to install boot image?  ------> Install and reboot

[Kent] will do

[Mahesh] Section 5.2. Point 3. Login credentials. Can you clarify this
sentence "These credentials may be, for instance, a private key used for
SSH or TLS client authentication." Specifically, how are login credentials
established when doing TLS client authentication.

[Kent] the next line says "It is expected that a device is able to
authenticate the NMS's credentials by virtue of the configuration it
downloads from the Bootstrap Server." and appendix A.3. provides an
example bootstrap configuration , which sets the ssh-key for the admin
user account.  This is akin to placing your ssh public key into a remote
system's ~/.ssh/authorized_keys file - makes sense?

Thanks,
Kent