RFC 8572
Secure Zero Touch Provisioning (SZTP)
11. References
11.1. Normative References
[ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/>. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>. [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>. [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>. [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, May 2018, <https://www.rfc-editor.org/info/rfc8366>. [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>. [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>. [Std-802.1AR] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR.11.2. Informative References
[NTS-NTP] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", Work in Progress, draft-ietf-ntp-using-nts-for- ntp-18, April 2019.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>. [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>. [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 (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>. [RFC7107] Housley, R., "Object Identifier Registry for the S/MIME Mail Security Working Group", RFC 7107, DOI 10.17487/RFC7107, January 2014, <https://www.rfc-editor.org/info/rfc7107>. [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, <https://www.rfc-editor.org/info/rfc7766>. [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home", RFC 8071, DOI 10.17487/RFC8071, February 2017, <https://www.rfc-editor.org/info/rfc8071>. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [YANG-CRYPTO-TYPES] Watsen, K. and H. Wang, "Common YANG Data Types for Cryptography", Work in Progress, draft-ietf-netconf- crypto-types-05, March 2019. [YANG-TRUST-ANCHORS] Watsen, K., "YANG Data Model for Global Trust Anchors", Work in Progress, draft-ietf-netconf-trust-anchors-03, March 2019.
Appendix A. Example Device Data Model
This section defines a non-normative data model that enables the configuration of SZTP bootstrapping and the discovery of what parameters are used by a device's bootstrapping logic.A.1. Data Model Overview
The following tree diagram provides an overview for the SZTP device data model. module: example-device-data-model +--rw sztp +--rw enabled? boolean +--ro idevid-certificate? ct:end-entity-cert-cms | {bootstrap-servers}? +--ro bootstrap-servers {bootstrap-servers}? | +--ro bootstrap-server* [address] | +--ro address inet:host | +--ro port? inet:port-number +--ro bootstrap-server-trust-anchors {bootstrap-servers}? | +--ro reference* ta:pinned-certificates-ref +--ro voucher-trust-anchors {signed-data}? +--ro reference* ta:pinned-certificates-ref In the above diagram, notice that there is only one configurable node: "enabled". The expectation is that this node would be set to "true" in the device's factory default configuration and that it would be either set to "false" or deleted when the SZTP bootstrapping is longer needed.
A.2. Example Usage
Following is an instance example for this data model. <sztp xmlns="https://example.com/sztp-device-data-model"> <enabled>true</enabled> <idevid-certificate>base64encodedvalue==</idevid-certificate> <bootstrap-servers> <bootstrap-server> <address>sztp1.example.com</address> <port>8443</port> </bootstrap-server> <bootstrap-server> <address>sztp2.example.com</address> <port>8443</port> </bootstrap-server> <bootstrap-server> <address>sztp3.example.com</address> <port>8443</port> </bootstrap-server> </bootstrap-servers> <bootstrap-server-trust-anchors> <reference>manufacturers-root-ca-certs</reference> </bootstrap-server-trust-anchors> <voucher-trust-anchors> <reference>manufacturers-root-ca-certs</reference> </voucher-trust-anchors> </sztp>A.3. YANG Module
The device model is defined by the YANG module defined in this section. This module references [Std-802.1AR] and uses data types defined in [RFC6991], [YANG-CRYPTO-TYPES], and [YANG-TRUST-ANCHORS]. module example-device-data-model { yang-version 1.1; namespace "https://example.com/sztp-device-data-model"; prefix sztp-ddm; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-crypto-types {
prefix ct;
revision-date 2019-03-09;
description
"ietf-crypto-types is defined in
draft-ietf-netconf-crypto-types";
reference
"draft-ietf-netconf-crypto-types-05:
Common YANG Data Types for Cryptography";
}
import ietf-trust-anchors {
prefix ta;
revision-date 2019-03-09;
description
"ietf-trust-anchors is defined in
draft-ietf-netconf-trust-anchors.";
reference
"draft-ietf-netconf-trust-anchors-03:
YANG Data Model for Global Trust Anchors";
}
organization
"Example Corporation";
contact
"Author: Bootstrap Admin <mailto:admin@example.com>";
description
"This module defines a data model to enable SZTP
bootstrapping and discover what parameters are used.
This module assumes the use of an IDevID certificate,
as opposed to any other client certificate, or the
use of an HTTP-based client authentication scheme.";
revision 2019-04-30 {
description
"Initial version";
reference
"RFC 8572: Secure Zero Touch Provisioning (SZTP)";
}
// features
feature bootstrap-servers {
description
"The device supports bootstrapping off bootstrap servers.";
}
feature signed-data {
description
"The device supports bootstrapping off signed data.";
}
// protocol accessible nodes
container sztp {
description
"Top-level container for the SZTP data model.";
leaf enabled {
type boolean;
default false;
description
"The 'enabled' leaf controls if SZTP bootstrapping is
enabled or disabled. The default is 'false' so that, when
not enabled, which is most of the time, no configuration
is needed.";
}
leaf idevid-certificate {
if-feature bootstrap-servers;
type ct:end-entity-cert-cms;
config false;
description
"This CMS structure contains the IEEE 802.1AR
IDevID certificate itself and all intermediate
certificates leading up to, and optionally including,
the manufacturer's well-known trust anchor certificate
for IDevID certificates. The well-known trust anchor
does not have to be a self-signed certificate.";
reference
"IEEE 802.1AR:
IEEE Standard for Local and metropolitan area
networks - Secure Device Identity";
}
container bootstrap-servers {
if-feature bootstrap-servers;
config false;
description
"List of bootstrap servers this device will attempt
to reach out to when bootstrapping.";
list bootstrap-server {
key "address";
description
"A bootstrap server entry.";
leaf address {
type inet:host;
mandatory true;
description
"The IP address or hostname of the bootstrap server the
device should redirect to.";
}
leaf port {
type inet:port-number;
default "443";
description
"The port number the bootstrap server listens on. If no
port is specified, the IANA-assigned port for 'https'
(443) is used.";
}
}
}
container bootstrap-server-trust-anchors {
if-feature bootstrap-servers;
config false;
description "Container for a list of trust anchor references.";
leaf-list reference {
type ta:pinned-certificates-ref;
description
"A reference to a list of pinned certificate authority (CA)
certificates that the device uses to validate bootstrap
servers with.";
}
}
container voucher-trust-anchors {
if-feature signed-data;
config false;
description "Container for a list of trust anchor references.";
leaf-list reference {
type ta:pinned-certificates-ref;
description
"A reference to a list of pinned certificate authority (CA)
certificates that the device uses to validate ownership
vouchers with.";
}
}
}
}
Appendix B. Promoting a Connection from Untrusted to Trusted
The following diagram illustrates a sequence of bootstrapping activities that promote an untrusted connection to a bootstrap server to a trusted connection to the same bootstrap server. This enables a device to limit the amount of information it might disclose to an adversary hosting an untrusted bootstrap server. +-----------+ |Deployment-| | Specific | +------+ | Bootstrap | |Device| | Server | +------+ +-----------+ | | | 1. "HTTPS" Request ("signed-data-preferred", nonce) | |------------------------------------------------------->| | 2. "HTTPS" Response (signed redirect information) | |<-------------------------------------------------------| | | | | | 3. HTTPS Request (os-name=xyz, os-version=123, etc.) | |------------------------------------------------------->| | 4. HTTPS Response (unsigned onboarding information | |<-------------------------------------------------------| | | The interactions in the above diagram are described below. 1. The device initiates an untrusted connection to a bootstrap server, as is indicated by putting "HTTPS" in double quotes above. It is still an HTTPS connection, but the device is unable to authenticate the bootstrap server's TLS certificate. Because the device is unable to trust the bootstrap server, it sends the "signed-data-preferred" input parameter, and optionally also the "nonce" input parameter, in the "get-bootstrapping-data" RPC. The "signed-data-preferred" parameter informs the bootstrap server that the device does not trust it and may be holding back some additional input parameters from the server (e.g., other input parameters, progress reports, etc.). The "nonce" input parameter enables the bootstrap server to dynamically obtain an ownership voucher from a Manufacturer Authorized Signing Authority (MASA), which may be important for devices that do not have a reliable clock.
2. The bootstrap server, seeing the "signed-data-preferred" input
parameter, knows that it can send either unsigned redirect
information or signed data of any type. But, in this case, the
bootstrap server has the ability to sign data and chooses to
respond with signed redirect information, not signed onboarding
information as might be expected, securely redirecting the device
back to it again. Not displayed but, if the "nonce" input
parameter was passed, the bootstrap server could dynamically
connect to a MASA and download a voucher having the nonce value
in it. Details regarding a protocol enabling this integration is
outside the scope of this document.
3. Upon validating the signed redirect information, the device
establishes a secure connection to the bootstrap server.
Unbeknownst to the device, it is the same bootstrap server it was
connected to previously, but because the device is able to
authenticate the bootstrap server this time, it sends its normal
"get-bootstrapping-data" request (i.e., with additional input
parameters) as well as its progress reports (not depicted).
4. This time, because the "signed-data-preferred" parameter was not
passed, having access to all of the device's input parameters,
the bootstrap server returns, in this example, unsigned
onboarding information to the device. Note also that, because
the bootstrap server is now trusted, the device will send
progress reports to the server.
Appendix C. Workflow Overview
The solution presented in this document is conceptualized to be
composed of the non-normative workflows described in this section.
Implementation details are expected to vary. Each diagram is
followed by a detailed description of the steps presented in the
diagram, with further explanation on how implementations may vary.
C.1. Enrollment and Ordering Devices
The following diagram illustrates key interactions that may occur
from when a prospective owner enrolls in a manufacturer's SZTP
program to when the manufacturer ships devices for an order placed by
the prospective owner.
+-----------+
+------------+ |Prospective| +---+
|Manufacturer| | Owner | |NMS|
+------------+ +-----------+ +---+
| | |
| | |
| 1. initiate enrollment | |
#<-----------------------------| |
# | |
# | |
# IDevID trust anchor | |
#-----------------------------># set IDevID trust anchor |
# #--------------------------->|
# | |
# bootstrap server | |
# account credentials | |
#-----------------------------># set credentials |
| #--------------------------->|
| | |
| | |
| 2. set owner certificate trust anchor |
|<----------------------------------------------------------|
| | |
| | |
| 3. place device order | |
|<-----------------------------# model devices |
| #--------------------------->|
| | |
| 4. ship devices and send | |
| device identifiers and | |
| ownership vouchers | |
|-----------------------------># set device identifiers |
| # and ownership vouchers |
| #--------------------------->|
| | |
Each numbered item below corresponds to a numbered item in the
diagram above.
1. A prospective owner of a manufacturer's devices initiates an
enrollment process with the manufacturer. This process includes
the following:
* Regardless of how the prospective owner intends to bootstrap
their devices, they will always obtain from the manufacturer
the trust anchor certificate for the IDevID certificates.
This certificate is installed on the prospective owner's NMS
so that the NMS can authenticate the IDevID certificates when
they are presented to subsequent steps.
* If the manufacturer hosts an Internet-based bootstrap server
(e.g., a redirect server) such as described in Section 4.4,
then credentials necessary to configure the bootstrap server
would be provided to the prospective owner. If the bootstrap
server is configurable through an API (outside the scope of
this document), then the credentials might be installed on the
prospective owner's NMS so that the NMS can subsequently
configure the manufacturer-hosted bootstrap server directly.
2. If the manufacturer's devices are able to validate signed data
(Section 5.4), and assuming that the prospective owner's NMS is
able to prepare and sign the bootstrapping data itself, the
prospective owner's NMS might set a trust anchor certificate onto
the manufacturer's bootstrap server, using the credentials
provided in the previous step. This certificate is the trust
anchor certificate that the prospective owner would like the
manufacturer to place into the ownership vouchers it generates,
thereby enabling devices to trust the owner's owner certificate.
How this trust anchor certificate is used to enable devices to
validate signed bootstrapping data is described in Section 5.4.
3. Some time later, the prospective owner places an order with the
manufacturer, perhaps with a special flag checked for SZTP
handling. At this time, or perhaps before placing the order, the
owner may model the devices in their NMS, creating virtual
objects for the devices with no real-world device associations.
For instance, the model can be used to simulate the device's
location in the network and the configuration it should have when
fully operational.
4. When the manufacturer fulfills the order, shipping the devices to
their intended locations, they may notify the owner of the
devices' serial numbers and shipping destinations, which the
owner may use to stage the network for when the devices power on.
Additionally, the manufacturer may send one or more ownership
vouchers, cryptographically assigning ownership of those devices
to the owner. The owner may set this information on their NMS,
perhaps binding specific modeled devices to the serial numbers
and ownership vouchers.
C.2. Owner Stages the Network for Bootstrap
The following diagram illustrates how an owner might stage the network for bootstrapping devices. +-----------+ +-------------+ |Deployment-| |Manufacturer-| +------+ +------+ | Specific | | Hosted | | Local| | Local| +---------+ +---+ | Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable| |NMS| | Server | | Server | |Server| |Server| | Storage | +---+ +-----------+ +-------------+ +------+ +------+ +---------+ | | | | | | 1. | | | | | | activate| | | | | | modeled | | | | | | device | | | | | | ------->| | | | | | | 2. (optional) | | | | | configure | | | | | bootstrap | | | | | server | | | | |------->| | | | | | | | | | | | 3. (optional) configure | | | | bootstrap server | | | | |--------------------->| | | | | | | | | | | | | | | | | 4. (optional) configure DNS server| | | |---------------------------------->| | | | | | | | | | | | | | | | 5. (optional) configure DHCP server | | |------------------------------------------->| | | | | | | | | | | | | | | 6. (optional) store bootstrapping artifacts on media | |----------------------------------------------------->| | | | | | | | | | | | | Each numbered item below corresponds to a numbered item in the diagram above. 1. Having previously modeled the devices, including setting their fully operational configurations and associating device serial numbers and (optionally) ownership vouchers, the owner might "activate" one or more modeled devices. That is, the owner tells
the NMS to perform the steps necessary to prepare for when the
real-world devices power up and initiate the bootstrapping
process. Note that, in some deployments, this step might be
combined with the last step from the previous workflow. Here, it
is depicted that an NMS performs the steps, but they may be
performed manually or through some other mechanism.
2. If it is desired to use a deployment-specific bootstrap server,
it must be configured to provide the bootstrapping data for the
specific devices. Configuring the bootstrap server may occur via
a programmatic API not defined by this document. Illustrated
here as an external component, the bootstrap server may be
implemented as an internal component of the NMS itself.
3. If it is desired to use a manufacturer-hosted bootstrap server,
it must be configured to provide the bootstrapping data for the
specific devices. The configuration must be either redirect or
onboarding information. That is, the manufacturer-hosted
bootstrap server will either redirect the device to another
bootstrap server or provide the device with the onboarding
information itself. The types of bootstrapping data the
manufacturer-hosted bootstrap server supports may vary by
implementation; some implementations may support only redirect
information or only onboarding information, while others may
support both redirect and onboarding information. Configuring
the bootstrap server may occur via a programmatic API not defined
by this document.
4. If it is desired to use a DNS server to supply bootstrapping
data, a DNS server needs to be configured. If multicast DNS is
desired, then the DNS server must reside on the local network;
otherwise, the DNS server may reside on a remote network. Please
see Section 4.2 for more information about how to configure DNS
servers. Configuring the DNS server may occur via a programmatic
API not defined by this document.
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
be accessed directly or via a DHCP relay. Please see Section 4.3
for more information about how to configure DHCP servers.
Configuring the DHCP server may occur via a programmatic API not
defined by this document.
6. If it is desired to use a removable storage device (e.g., a USB
flash drive) to supply bootstrapping data, the data would need to
be placed onto it. Please see Section 4.1 for more information
about how to configure a removable storage device.
C.3. Device Powers On
The following diagram illustrates the sequence of activities that occur when a device powers on. +-----------+ +-----------+ |Deployment-| | Source of | | Specific | +------+ | Bootstrap | | Bootstrap | +---+ |Device| | Data | | Server | |NMS| +------+ +-----------+ +-----------+ +---+ | | | | | | | | | 1. if SZTP bootstrap service | | | | is not enabled, then exit. | | | | | | | | 2. for each source supported, check | | | | for bootstrapping data. | | | |------------------------------------>| | | | | | | | 3. if onboarding information is | | | | found, initialize self and, only | | | | if source is a trusted bootstrap | | | | server, send progress reports. | | | |------------------------------------># | | | # webhook | | | #------------------------>| | | | | 4. else, if redirect information is found, for | | | each bootstrap server specified, check for data.| | |-+------------------------------------------------->| | | | | | | | if more redirect information is found, recurse | | | | (not depicted); else, if onboarding information | | | | is found, initialize self and post progress | | | | reports. | | | +-------------------------------------------------># | | # webhook | | #--------->| | | 5. retry sources and/or wait for manual provisioning. | The interactions in the above diagram are described below. 1. Upon power being applied, the device checks to see if SZTP bootstrapping is configured, such as must be the case when running its "factory default" configuration. If SZTP
bootstrapping is not configured, then the bootstrapping logic
exits and none of the following interactions occur.
2. For each source of bootstrapping data the device supports,
preferably in order of closeness to the device (e.g., removable
storage before Internet-based servers), the device checks to see
if there is any bootstrapping data for it there.
3. If onboarding information is found, the device initializes itself
accordingly (e.g., installing a boot image and committing an
initial configuration). If the source is a bootstrap server, and
the bootstrap server can be trusted (i.e., TLS-level
authentication), the device also sends progress reports to the
bootstrap server.
* The contents of the initial configuration should configure an
administrator account on the device (e.g., username, SSH
public key, etc.), should configure the device to either
listen for NETCONF or RESTCONF connections or initiate call
home connections [RFC8071], and should disable the SZTP
bootstrapping service (e.g., the "enabled" leaf in data model
presented in Appendix A).
* If the bootstrap server supports forwarding device progress
reports to external systems (e.g., via a webhook), a
"bootstrap-complete" progress report (Section 7.3) informs the
external system to know when it can, for instance, initiate a
connection to the device. To support this scenario further,
the "bootstrap-complete" progress report may also relay the
device's SSH host keys and/or TLS certificates, which the
external system can use to authenticate subsequent connections
to the device.
If the device successfully completes the bootstrapping process,
it exits the bootstrapping logic without considering any
additional sources of bootstrapping data.
4. Otherwise, if redirect information is found, the device iterates
through the list of specified bootstrap servers, checking to see
if the bootstrap server has bootstrapping data for the device.
If the bootstrap server returns more redirect information, then
the device processes it recursively. Otherwise, if the bootstrap
server returns onboarding information, the device processes it
following the description provided in (3) above.
5. After having tried all supported sources of bootstrapping data,
the device may retry again all the sources and/or provide
manageability interfaces for manual configuration (e.g., CLI,
HTTP, NETCONF, etc.). If manual configuration is allowed, and
such configuration is provided, the configuration should also
disable the SZTP bootstrapping service, as the need for
bootstrapping would no longer be present.
Acknowledgements
The authors would like to thank the following for lively discussions
on list and in the halls (ordered by last name): Michael Behringer,
Martin Bjorklund, Dean Bogdanovic, Joe Clarke, Dave Crocker, Toerless
Eckert, Stephen Farrell, Stephen Hanna, Wes Hardaker, David
Harrington, Benjamin Kaduk, Radek Krejci, Suresh Krishnan, Mirja
Kuehlewind, David Mandelberg, Alexey Melnikov, Russ Mundy, Reinaldo
Penno, Randy Presuhn, Max Pritikin, Michael Richardson, Adam Roach,
Juergen Schoenwaelder, and Phil Shafer.
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for
brainstorming the original solution during the IETF 87 meeting in
Berlin.
Authors' Addresses
Kent Watsen
Watsen Networks
Email: kent+ietf@watsen.net
Ian Farrer
Deutsche Telekom AG
Email: ian.farrer@telekom.de
Mikael Abrahamsson
T-Systems
Email: mikael.abrahamsson@t-systems.se