< draft-ietf-netconf-zerotouch-24.txt   draft-ietf-netconf-zerotouch-25.txt >
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track M. Abrahamsson Intended status: Standards Track M. Abrahamsson
Expires: March 9, 2019 T-Systems Expires: March 17, 2019 T-Systems
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
September 5, 2018 September 13, 2018
Zero Touch Provisioning for Networking Devices Zero Touch Provisioning for Networking Devices
draft-ietf-netconf-zerotouch-24 draft-ietf-netconf-zerotouch-25
Abstract Abstract
This draft presents a technique to securely provision a networking This draft presents a technique to securely provision a networking
device when it is booting in a factory-default state. Variations in device when it is booting in a factory-default state. Variations in
the solution enables it to be used on both public and private the solution enables it to be used on both public and private
networks. The provisioning steps are able to update the boot image, networks. The provisioning steps are able to update the boot image,
commit an initial configuration, and execute arbitrary scripts to commit an initial configuration, and execute arbitrary scripts to
address auxiliary needs. The updated device is subsequently able to address auxiliary needs. The updated device is subsequently able to
establish secure connections with other systems. For instance, a establish secure connections with other systems. For instance, a
skipping to change at page 1, line 49 skipping to change at page 1, line 49
o "TBD2" --> the assigned value for id-ct-zerotouchInformationJSON o "TBD2" --> the assigned value for id-ct-zerotouchInformationJSON
Artwork in this document contains shorthand references to drafts in Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements: progress. Please apply the following replacements:
o "XXXX" --> the assigned numerical RFC value for this draft o "XXXX" --> the assigned numerical RFC value for this draft
Artwork in this document contains placeholder values for the date of Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement: publication of this draft. Please apply the following replacement:
o "2018-09-05" --> the publication date of this draft o "2018-09-13" --> the publication date of this draft
The following one Appendix section is to be removed prior to The following one Appendix section is to be removed prior to
publication: publication:
o Appendix A. Change Log o Appendix A. Change Log
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 9, 2019. This Internet-Draft will expire on March 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 8
2. Types of Bootstrapping Information . . . . . . . . . . . . . 8 2. Types of Bootstrapping Information . . . . . . . . . . . . . 8
2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8 2.1. Redirect Information . . . . . . . . . . . . . . . . . . 8
2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9 2.2. Onboarding Information . . . . . . . . . . . . . . . . . 9
3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Zero Touch Information . . . . . . . . . . . . . . . . . 10 3.1. Zero Touch Information . . . . . . . . . . . . . . . . . 10
3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 11 3.2. Owner Certificate . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 4, line 17 skipping to change at page 4, line 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 62
11.2. Informative References . . . . . . . . . . . . . . . . . 64 11.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. The Zero Touch Device Data Model . . . . . . . . . . 66 Appendix A. The Zero Touch Device Data Model . . . . . . . . . . 66
A.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 66 A.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 66
A.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 66 A.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 66
A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 67 A.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 67
Appendix B. Promoting a Connection from Untrusted to Trusted . . 70 Appendix B. Promoting a Connection from Untrusted to Trusted . . 70
Appendix C. Workflow Overview . . . . . . . . . . . . . . . . . 72 Appendix C. Workflow Overview . . . . . . . . . . . . . . . . . 72
C.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 72 C.1. Enrollment and Ordering Devices . . . . . . . . . . . . . 72
C.2. Owner Stages the Network for Bootstrap . . . . . . . . . 74 C.2. Owner Stages the Network for Bootstrap . . . . . . . . . 74
C.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 77 C.3. Device Powers On . . . . . . . . . . . . . . . . . . . . 76
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 79 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 79
D.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 79 D.1. ID to 00 . . . . . . . . . . . . . . . . . . . . . . . . 79
D.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 79 D.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 79
D.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 80 D.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 79
D.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 80 D.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 80
D.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 80 D.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 80
D.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 80 D.6. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 80
D.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 81 D.7. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 81
D.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 81 D.8. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 81
D.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 81 D.9. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 81
D.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 81 D.10. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 81
D.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 81 D.11. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 81
D.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 82 D.12. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 82
D.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 82 D.13. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 82
D.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 83 D.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 82
D.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 83 D.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 83
D.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 83 D.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 83
D.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 84 D.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 83
D.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 84 D.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 84
D.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 85 D.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 84
D.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 85 D.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 85
D.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 85 D.21. 19 to 20 . . . . . . . . . . . . . . . . . . . . . . . . 85
D.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 86 D.22. 20 to 21 . . . . . . . . . . . . . . . . . . . . . . . . 86
D.23. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 86 D.23. 21 to 22 . . . . . . . . . . . . . . . . . . . . . . . . 86
D.24. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 87 D.24. 22 to 23 . . . . . . . . . . . . . . . . . . . . . . . . 86
D.25. 23 to 24 . . . . . . . . . . . . . . . . . . . . . . . . 87 D.25. 23 to 24 . . . . . . . . . . . . . . . . . . . . . . . . 87
D.26. 24 to 25 . . . . . . . . . . . . . . . . . . . . . . . . 87
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
1. Introduction 1. Introduction
A fundamental business requirement for any network operator is to A fundamental business requirement for any network operator is to
reduce costs where possible. For network operators, deploying reduce costs where possible. For network operators, deploying
devices to many locations can be a significant cost, as sending devices to many locations can be a significant cost, as sending
trained specialists to each site for installations is both cost trained specialists to each site for installations is both cost
prohibitive and does not scale. prohibitive and does not scale.
skipping to change at page 9, line 48 skipping to change at page 9, line 50
signed by the device's owner. In all other cases, the onboarding signed by the device's owner. In all other cases, the onboarding
information is untrusted. information is untrusted.
How devices process onboarding information is described in How devices process onboarding information is described in
Section 5.6. Section 5.6.
3. Artifacts 3. Artifacts
This document defines three artifacts that can be made available to This document defines three artifacts that can be made available to
devices while they are bootstrapping. Each source of bootstrapping devices while they are bootstrapping. Each source of bootstrapping
information specifies how it provides the artifacts defined in this data specifies how it provides the artifacts defined in this section
section (see Section 4). (see Section 4).
3.1. Zero Touch Information 3.1. Zero Touch Information
The zero touch information artifact encodes the essential The zero touch information artifact encodes the essential
bootstrapping data for the device. This artifact is used to encode bootstrapping data for the device. This artifact is used to encode
the redirect information and onboarding information types discussed the redirect information and onboarding information types discussed
in Section 2. in Section 2.
The zero touch information artifact is a CMS structure, as described The zero touch information artifact is a CMS structure, as described
in [RFC5652], encoded using ASN.1 distinguished encoding rules (DER), in [RFC5652], encoded using ASN.1 distinguished encoding rules (DER),
skipping to change at page 12, line 47 skipping to change at page 12, line 47
3.4. Artifact Encryption 3.4. Artifact Encryption
Each of the three artifacts MAY be individually encrypted. Each of the three artifacts MAY be individually encrypted.
Encryption may be important in some environments where the content is Encryption may be important in some environments where the content is
considered sensitive. considered sensitive.
Each of the three artifacts are encrypted in the same way, by the Each of the three artifacts are encrypted in the same way, by the
unencrypted form being encapsulated inside a CMS EnvelopedData type. unencrypted form being encapsulated inside a CMS EnvelopedData type.
As a consequence, both the zerotouch information and ownership As a consequence, both the zero touch information and ownership
voucher artifacts are signed and then encrypted, never encrypted and voucher artifacts are signed and then encrypted, never encrypted and
then signed. then signed.
This sequencing has the advantage of shrouding the signer's This sequencing has the advantage of shrouding the signer's
certificate, and ensuring that the owner knows the content being certificate, and ensuring that the owner knows the content being
signed. This sequencing further enables the owner to inspect an signed. This sequencing further enables the owner to inspect an
unencrypted voucher obtained from a manufacturer and then encrypt the unencrypted voucher obtained from a manufacturer and then encrypt the
voucher later themselves, perhaps while also stapling in current voucher later themselves, perhaps while also stapling in current
revocation objects, when ready to place the artifact in an unsafe revocation objects, when ready to place the artifact in an unsafe
location. location.
skipping to change at page 13, line 25 skipping to change at page 13, line 25
owner comes to posses the device's identity certificate for this owner comes to posses the device's identity certificate for this
purpose is outside the scope of this document. purpose is outside the scope of this document.
3.5. Artifact Groupings 3.5. Artifact Groupings
The previous sections discussed the bootstrapping artifacts, but only The previous sections discussed the bootstrapping artifacts, but only
certain groupings of these artifacts make sense to return in the certain groupings of these artifacts make sense to return in the
various bootstrapping situations described in this document. These various bootstrapping situations described in this document. These
groupings are: groupings are:
Unsigned Information: This grouping is useful for cases when Unsigned Data: This artifact grouping is useful for cases when
transport level security can be used to convey trust (e.g., transport level security can be used to convey trust (e.g.,
HTTPS), or when the information can be processed in a HTTPS), or when the zero touch information can be processed in
provisional manner (i.e. unsigned redirect information). a provisional manner (i.e. unsigned redirect information).
Signed Information, without revocations: This grouping is useful
when signed information is needed, because it is obtained from
an untrusted source, and it cannot be processed provisionally,
and yet either revocations are not needed or they can be
obtained dynamically.
Signed Information, with revocations: This grouping is useful
when signed information is needed, because it is obtained from
an untrusted source, and it cannot be processed provisionally,
and revocations are needed and cannot be obtained dynamically.
The artifacts associated with these groupings are described below: Signed Data, without revocations: This artifact grouping is
useful when signed data is needed (i.e., because the data is
obtained from an untrusted source and it cannot be processed
provisionally) and either revocations are not needed or the
revocations can be obtained dynamically.
Zero Touch Ownership Owner Signed Data, with revocations: This artifact grouping is useful
Grouping Information Voucher Certificate when signed data is needed (i.e., because the data is obtained
-------------------- ------------- ------------ ----------- from an untrusted source and it cannot be processed
Unsigned Information Yes, no sig No No provisionally), and revocations are needed, and the revocations
cannot be obtained dynamically.
Signed Information, Yes, with sig Yes, without Yes, without The presence of each artifact, and any distinguishing
without revocations revocations revocations characteristics, are identified for each artifact grouping in the
table below ("yes/no" regards if the artifact is present in the
artifact grouping):
Signed Information, Yes, with sig Yes, with Yes, with +---------------------+---------------+--------------+--------------+
with revocations revocations revocations | Artifact | Zero Touch | Ownership | Owner |
| Grouping | Information | Voucher | Certificate |
+=====================+===============+==============+==============+
| Unsigned Data | Yes, no sig | No | No |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, without | Yes, without |
| without revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
| Signed Data, | Yes, with sig | Yes, with | Yes, with |
| with revocations | | revocations | revocations |
+---------------------+---------------+--------------+--------------+
4. Sources of Bootstrapping Data 4. Sources of Bootstrapping Data
This section defines some sources for bootstrapping data that a This section defines some sources for bootstrapping data that a
device can access. The list of sources defined here is not meant to device can access. The list of sources defined here is not meant to
be exhaustive. It is left to future documents to define additional be exhaustive. It is left to future documents to define additional
sources for obtaining bootstrapping data. sources for obtaining bootstrapping data.
For each source of bootstrapping data defined in this section, For each source of bootstrapping data defined in this section,
details are given for how the three artifacts listed in Section 3 are details are given for how the three artifacts listed in Section 3 are
skipping to change at page 17, line 44 skipping to change at page 17, line 47
document, a bootstrap server is not only a source of data, but it can document, a bootstrap server is not only a source of data, but it can
also receive data from devices using the YANG-defined "report- also receive data from devices using the YANG-defined "report-
progress" RPC defined in the YANG module (Section 7.3). The "report- progress" RPC defined in the YANG module (Section 7.3). The "report-
progress" RPC enables visibility into the bootstrapping process progress" RPC enables visibility into the bootstrapping process
(e.g., warnings and errors), and provides potentially useful (e.g., warnings and errors), and provides potentially useful
information upon completion (e.g., the device's SSH host-keys). information upon completion (e.g., the device's SSH host-keys).
A bootstrap server may be a trusted or an untrusted source of A bootstrap server may be a trusted or an untrusted source of
bootstrapping data, depending on if the device learned about the bootstrapping data, depending on if the device learned about the
bootstrap server's trust anchor from a trusted source. When a bootstrap server's trust anchor from a trusted source. When a
bootstrap server is trusted, the information returned from it MAY be bootstrap server is trusted, the zero touch information returned from
signed. However, when the server is untrusted, in order for its it MAY be signed. When the bootstrap server is untrusted, the zero
information to be of any use to the device, the bootstrap information touch information either MUST be signed or MUST be information that
either MUST be signed or MUST be information that can be processed can be processed provisionally (e.g., unsigned redirect information).
provisionally (e.g., unsigned redirect information).
From an artifact perspective, since a bootstrap server presents data From an artifact perspective, since a bootstrap server presents data
conforming to a YANG data model, the bootstrapping artifacts need to conforming to a YANG data model, the bootstrapping artifacts need to
be mapped to YANG nodes. The three artifacts defined in Section 3 be mapped to YANG nodes. The three artifacts defined in Section 3
are mapped to "output" nodes of the "get-bootstrapping-data" RPC are mapped to "output" nodes of the "get-bootstrapping-data" RPC
defined in Section 7.3 below. defined in Section 7.3 below.
Artifact to Bootstrap Server Mapping: Artifact to Bootstrap Server Mapping:
Zero Touch Information: Mapped to the "zerotouch-information" Zero Touch Information: Mapped to the "zerotouch-information"
skipping to change at page 21, line 48 skipping to change at page 21, line 48
4. Otherwise the device MAY loop back through the list of 4. Otherwise the device MAY loop back through the list of
bootstrapping sources again and/or wait for manual provisioning. bootstrapping sources again and/or wait for manual provisioning.
5.3. Processing a Source of Bootstrapping Data 5.3. Processing a Source of Bootstrapping Data
This section describes a recursive algorithm that devices can use to, This section describes a recursive algorithm that devices can use to,
ultimately, obtain onboarding information. The algorithm is ultimately, obtain onboarding information. The algorithm is
recursive because sources of bootstrapping data may return redirect recursive because sources of bootstrapping data may return redirect
information, which causes the algorithm to run again, for the newly information, which causes the algorithm to run again, for the newly
discovered sources of bootstrapping information. An expression that discovered sources of bootstrapping data. An expression that
captures all possible successful sequences of bootstrapping captures all possible successful sequences of bootstrapping data is
information is zero or more redirect information responses, followed zero or more redirect information responses, followed by one
by one onboarding information response. onboarding information response.
An important aspect of the algorithm is knowing when data needs to be An important aspect of the algorithm is knowing when data needs to be
signed or not. The following figure provides a summary of options: signed or not. The following figure provides a summary of options:
Untrusted Source Trusted Source Untrusted Source Trusted Source
Kind of Bootstrapping Data Can Provide? Can Provide? Kind of Bootstrapping Data Can Provide? Can Provide?
Unsigned Redirect Info : Yes+ Yes Unsigned Redirect Info : Yes+ Yes
Signed Redirect Info : Yes Yes* Signed Redirect Info : Yes Yes*
Unsigned Onboarding Info : No Yes Unsigned Onboarding Info : No Yes
skipping to change at page 31, line 15 skipping to change at page 31, line 15
6.3. YANG Module 6.3. YANG Module
The zero touch information data model is defined by the YANG module The zero touch information data model is defined by the YANG module
presented in this section. presented in this section.
This module uses data types defined in [RFC5280], [RFC5652], This module uses data types defined in [RFC5280], [RFC5652],
[RFC6234], and [RFC6991], an extension statement from [RFC6234], and [RFC6991], an extension statement from
[I-D.ietf-netmod-yang-data-ext], and an encoding defined in [I-D.ietf-netmod-yang-data-ext], and an encoding defined in
[ITU.X690.2015]. [ITU.X690.2015].
<CODE BEGINS> file "ietf-zerotouch-information@2018-09-05.yang" <CODE BEGINS> file "ietf-zerotouch-information@2018-09-13.yang"
module ietf-zerotouch-information { module ietf-zerotouch-information {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-information"; namespace "urn:ietf:params:xml:ns:yang:ietf-zerotouch-information";
prefix zti; prefix zti;
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
} }
import ietf-inet-types { import ietf-inet-types {
skipping to change at page 32, line 15 skipping to change at page 32, line 15
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) Relating to IETF Documents (http://trustee.ietf.org/license-info)
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2018-09-05 { revision 2018-09-13 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Zero Touch Provisioning for Networking Devices"; "RFC XXXX: Zero Touch Provisioning for Networking Devices";
} }
// identities // identities
identity hash-algorithm { identity hash-algorithm {
description description
skipping to change at page 40, line 40 skipping to change at page 40, line 40
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Sat, 31 Oct 2015 17:02:40 GMT Date: Sat, 31 Oct 2015 17:02:40 GMT
Server: example-server Server: example-server
7.3. YANG Module 7.3. YANG Module
The bootstrap server's device-facing API is normatively defined by The bootstrap server's device-facing API is normatively defined by
the YANG module defined in this section. the YANG module defined in this section.
This module uses data types defined in [RFC4253], [RFC5652], This module uses data types defined in [RFC4253], [RFC5652],
[RFC5280], [RFC6960], and [RFC8366], and uses an encoding defined in [RFC5280], [RFC6960], and [RFC8366], uses an encoding defined in
[ITU.X690.2015]. [ITU.X690.2015], and makes a reference to [RFC6187].
<CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2018-09-05.yang" <CODE BEGINS> file "ietf-zerotouch-bootstrap-server@2018-09-13.yang"
module ietf-zerotouch-bootstrap-server { module ietf-zerotouch-bootstrap-server {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server"; "urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-server";
prefix ztbs; prefix ztbs;
organization organization
"IETF NETCONF (Network Configuration) Working Group"; "IETF NETCONF (Network Configuration) Working Group";
contact contact
skipping to change at page 41, line 32 skipping to change at page 41, line 32
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) Relating to IETF Documents (http://trustee.ietf.org/license-info)
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2018-09-05 { revision 2018-09-13 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Zero Touch Provisioning for Networking Devices"; "RFC XXXX: Zero Touch Provisioning for Networking Devices";
} }
// typedefs // typedefs
typedef cms { typedef cms {
type binary; type binary;
skipping to change at page 51, line 37 skipping to change at page 51, line 37
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code (143) | option-length | | option-code (143) | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . . .
. bootstrap-server-list (variable length) . . bootstrap-server-list (variable length) .
. . . .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o option-code: OPTION_V4_ZEROTOUCH_REDIRECT (143) o option-code: OPTION_V4_ZEROTOUCH_REDIRECT (143)
o option-length: The option length in octets o option-length: The option length in octets.
o bootstrap-server-list: A list of servers for the o bootstrap-server-list: A list of servers for the
client to attempt contacting, in order to obtain client to attempt contacting, in order to obtain
further bootstrapping data, in the format shown further bootstrapping data, in the format shown
in [common-field-encoding]. in [common-field-encoding].
DHCPv4 Client Behavior DHCPv4 Client Behavior
Clients MAY request the OPTION_V4_ZEROTOUCH_REDIRECT by including its Clients MAY request the OPTION_V4_ZEROTOUCH_REDIRECT by including its
option code in the Parameter Request List (55) in DHCP request option code in the Parameter Request List (55) in DHCP request
messages. messages.
skipping to change at page 52, line 38 skipping to change at page 52, line 38
The DHCPv6 Zero Touch Option is used to provision the client with one The DHCPv6 Zero Touch Option is used to provision the client with one
or more URIs for bootstrap servers that can be contacted to attempt or more URIs for bootstrap servers that can be contacted to attempt
further configuration. further configuration.
DHCPv6 Zero Touch Redirect Option DHCPv6 Zero Touch Redirect Option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code (136) | option-length | | option-code (136) | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. bootstrap-server-list (variable length) . . bootstrap-server-list (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: OPTION_V6_ZEROTOUCH_REDIRECT (136) o option-code: OPTION_V6_ZEROTOUCH_REDIRECT (136)
o option-length: The option length in octets o option-length: The option length in octets.
o bootstrap-server-list: A list of servers for the client to o bootstrap-server-list: A list of servers for the client to
attempt contacting, in order to obtain further bootstrapping attempt contacting, in order to obtain further bootstrapping
data, in the format shown in [common-field-encoding]. data, in the format shown in [common-field-encoding].
DHCPv6 Client Behavior DHCPv6 Client Behavior
Clients MAY request the OPTION_V6_ZEROTOUCH_REDIRECT option, as Clients MAY request the OPTION_V6_ZEROTOUCH_REDIRECT option, as
defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4,
18.1.5, and 22.7. As a convenience to the reader, we mention here 18.1.5, and 22.7. As a convenience to the reader, we mention here
that the client includes requested option codes in the Option Request that the client includes requested option codes in the Option Request
skipping to change at page 53, line 42 skipping to change at page 53, line 42
Both of the DHCPv4 and DHCPv6 options defined in this section encode Both of the DHCPv4 and DHCPv6 options defined in this section encode
a list of bootstrap server URIs. The "URI" structure is an option a list of bootstrap server URIs. The "URI" structure is an option
that can contain multiple URIs (see [RFC7227], Section 5.7). that can contain multiple URIs (see [RFC7227], Section 5.7).
bootstrap-server-list: bootstrap-server-list:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-length | URI | | uri-length | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
o uri-length: variable, in octets. o uri-length: 2 octets long, specifies the length of the URI data.
o URI: URI of zerotouch bootstrap server, using the HTTPS URI o URI: URI of zerotouch bootstrap server, using the HTTPS URI
scheme defined in Section 2.7.2 of RFC7230. URI MUST be in scheme defined in Section 2.7.2 of RFC7230. URI MUST be in
form "https://<ip-address-or-hostname>[:<port>]". form "https://<ip-address-or-hostname>[:<port>]".
9. Security Considerations 9. Security Considerations
9.1. Clock Sensitivity 9.1. Clock Sensitivity
The solution in this document relies on TLS certificates, owner The solution in this document relies on TLS certificates, owner
skipping to change at page 61, line 37 skipping to change at page 61, line 37
reference: RFC XXXX reference: RFC XXXX
name: ietf-zerotouch-bootstrap-server name: ietf-zerotouch-bootstrap-server
namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-\ namespace: urn:ietf:params:xml:ns:yang:ietf-zerotouch-bootstrap-\
server (note: '\' used for formatting reasons only) server (note: '\' used for formatting reasons only)
prefix: ztbs prefix: ztbs
reference: RFC XXXX reference: RFC XXXX
10.3. The SMI Security for S/MIME CMS Content Type Registry 10.3. The SMI Security for S/MIME CMS Content Type Registry
IANA is kindly requested to two entries in the "SMI Security for IANA is kindly requested to add two entries in the "SMI Security for
S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with S/MIME CMS Content Type" registry (1.2.840.113549.1.9.16.1), with
values as follows: values as follows:
Decimal Description References Decimal Description References
------- -------------------------------------- ---------- ------- -------------------------------------- ----------
TBD1 id-ct-zerotouchInformationXML [RFCXXXX] TBD1 id-ct-zerotouchInformationXML [RFCXXXX]
TBD2 id-ct-zerotouchInformationJSON [RFCXXXX] TBD2 id-ct-zerotouchInformationJSON [RFCXXXX]
id-ct-zerotouchInformationXML indicates that the "zerotouch- id-ct-zerotouchInformationXML indicates that the "zerotouch-
information" is encoded using XML. id-ct-zerotouchInformationJSON information" is encoded using XML. id-ct-zerotouchInformationJSON
skipping to change at page 64, line 49 skipping to change at page 64, line 49
[I-D.ietf-netconf-trust-anchors] [I-D.ietf-netconf-trust-anchors]
Watsen, K., "YANG Data Model for Global Trust Anchors", Watsen, K., "YANG Data Model for Global Trust Anchors",
draft-ietf-netconf-trust-anchors-00 (work in progress), draft-ietf-netconf-trust-anchors-00 (work in progress),
June 2018. June 2018.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
March 2011, <https://www.rfc-editor.org/info/rfc6187>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 68, line 36 skipping to change at page 68, line 36
contact contact
"Author: Bootstrap Admin <mailto:admin@example.com>"; "Author: Bootstrap Admin <mailto:admin@example.com>";
description description
"This module defines a data model to enable zerotouch "This module defines a data model to enable zerotouch
bootstrapping and discover what parameters are used. bootstrapping and discover what parameters are used.
This module assumes the use of an IDevID certificate, This module assumes the use of an IDevID certificate,
as opposed to any other client certificate, or the as opposed to any other client certificate, or the
use of an HTTP-based client authentication scheme."; use of an HTTP-based client authentication scheme.";
revision 2018-09-05 { revision 2018-09-13 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Zero Touch Provisioning for Networking Devices"; "RFC XXXX: Zero Touch Provisioning for Networking Devices";
} }
// features // features
feature bootstrap-servers { feature bootstrap-servers {
description description
skipping to change at page 76, line 8 skipping to change at page 76, line 8
numbers and (optionally) ownership vouchers, the owner might numbers and (optionally) ownership vouchers, the owner might
"activate" one or more modeled devices. That is, the owner tells "activate" one or more modeled devices. That is, the owner tells
the NMS to perform the steps necessary to prepare for when the the NMS to perform the steps necessary to prepare for when the
real-world devices power up and initiate the bootstrapping real-world devices power up and initiate the bootstrapping
process. Note that, in some deployments, this step might be process. Note that, in some deployments, this step might be
combined with the last step from the previous workflow. Here it combined with the last step from the previous workflow. Here it
is depicted that an NMS performs the steps, but they may be is depicted that an NMS performs the steps, but they may be
performed manually or through some other mechanism. performed manually or through some other mechanism.
2. If it is desired to use a deployment specific bootstrap server, 2. If it is desired to use a deployment specific bootstrap server,
it must be configured to provide the bootstrapping information it must be configured to provide the bootstrapping data for the
for the specific devices. Configuring the bootstrap server may specific devices. Configuring the bootstrap server may occur via
occur via a programmatic API not defined by this document. a programmatic API not defined by this document. Illustrated
Illustrated here as an external component, the bootstrap server here as an external component, the bootstrap server may be
may be implemented as an internal component of the NMS itself. implemented as an internal component of the NMS itself.
3. If it is desired to use a manufacturer hosted bootstrap server, 3. If it is desired to use a manufacturer hosted bootstrap server,
it must be configured to provide the bootstrapping information it must be configured to provide the bootstrapping data for the
for the specific devices. The configuration must be either specific devices. The configuration must be either redirect or
redirect or onboarding information. That is, either the onboarding information. That is, either the manufacturer hosted
manufacturer hosted bootstrap server will redirect the device to bootstrap server will redirect the device to another bootstrap
another bootstrap server, or provide the device with the server, or provide the device with the onboarding information
onboarding information itself. The types of bootstrapping itself. The types of bootstrapping data the manufacturer hosted
information the manufacturer hosted bootstrap server supports may bootstrap server supports may vary by implementation; some
vary by implementation; some implementations may only support implementations may only support redirect information, or only
redirect information, or only support onboarding information, or support onboarding information, or support both redirect and
support both redirect and onboarding information. Configuring onboarding information. Configuring the bootstrap server may
the bootstrap server may occur via a programmatic API not defined occur via a programmatic API not defined by this document.
by this document.
4. If it is desired to use a DNS server to supply bootstrapping 4. If it is desired to use a DNS server to supply bootstrapping
information, a DNS server needs to be configured. If multicast data, a DNS server needs to be configured. If multicast DNS-SD
DNS-SD is desired, then the server must reside on the local is desired, then the server must reside on the local network,
network, otherwise the DNS server may reside on a remote network. otherwise the DNS server may reside on a remote network. Please
Please see Section 4.2 for more information about how to see Section 4.2 for more information about how to configure DNS
configure DNS servers. Configuring the DNS server may occur via servers. Configuring the DNS server may occur via a programmatic
a programmatic API not defined by this document. API not defined by this document.
5. If it is desired to use a DHCP server to supply bootstrapping 5. If it is desired to use a DHCP server to supply bootstrapping
data, a DHCP server needs to be configured. The DHCP server may data, a DHCP server needs to be configured. The DHCP server may
be accessed directly or via a DHCP relay. Please see Section 4.3 be accessed directly or via a DHCP relay. Please see Section 4.3
for more information about how to configure DHCP servers. for more information about how to configure DHCP servers.
Configuring the DHCP server may occur via a programmatic API not Configuring the DHCP server may occur via a programmatic API not
defined by this document. defined by this document.
6. If it is desired to use a removable storage device (e.g., USB 6. If it is desired to use a removable storage device (e.g., USB
flash drive) to supply bootstrapping information, the information flash drive) to supply bootstrapping data, the data would need to
would need to be placed onto it. Please see Section 4.1 for more be placed onto it. Please see Section 4.1 for more information
information about how to configure a removable storage device. about how to configure a removable storage device.
C.3. Device Powers On C.3. Device Powers On
The following diagram illustrates the sequence of activities that The following diagram illustrates the sequence of activities that
occur when a device powers on. occur when a device powers on.
+----------+ +----------+
+-----------+ |Deployment| +-----------+ |Deployment|
| Source of | | Specific | | Source of | | Specific |
+------+ | Bootstrap | |Bootstrap | +---+ +------+ | Bootstrap | |Bootstrap | +---+
skipping to change at page 88, line 5 skipping to change at page 87, line 46
o Added recommendation for device to send warning if the initial o Added recommendation for device to send warning if the initial
config does not disable the bootstrapping process. config does not disable the bootstrapping process.
D.25. 23 to 24 D.25. 23 to 24
o Follow-ups from SecDir and Shepherd. o Follow-ups from SecDir and Shepherd.
o Added "boot-image-complete" enumeration. o Added "boot-image-complete" enumeration.
D.26. 24 to 25
o Removed remaining old "bootstrapping information" term usage.
o Fixed DHCP Option length definition.
o Added reference to RFC 6187.
Acknowledgements Acknowledgements
The authors would like to thank for following for lively discussions The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Michael Behringer, on list and in the halls (ordered by last name): Michael Behringer,
Dean Bogdanovic, Martin Bjorklund, Joe Clarke, Toerless Eckert, Dean Bogdanovic, Martin Bjorklund, Joe Clarke, Toerless Eckert,
Stephen Farrell, Stephen Hanna, Wes Hardaker, David Harrington, Radek Stephen Farrell, Stephen Hanna, Wes Hardaker, David Harrington, Radek
Krejci, David Mandelberg, Russ Mundy, Reinaldo Penno, Randy Presuhn, Krejci, David Mandelberg, Russ Mundy, Reinaldo Penno, Randy Presuhn,
Max Pritikin, Michael Richardson, Phil Shafer, Juergen Schoenwaelder. Max Pritikin, Michael Richardson, Phil Shafer, Juergen Schoenwaelder.
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for
 End of changes. 40 change blocks. 
85 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/