Secure Zero Touch Provisioning
To see which platforms support Secure Zero Touch Provisioning (SZTP), go to Feature Explorer. In the Explore Features section of the Feature Explorer page, select All Features. In the Features Grouped by Feature Family box, select Secure ZTP. You can also type the name of the feature in the Search for Features edit box. See the Release History Table at the end of this topic for more details of how ZTP support has expanded.
Overview
The phone-home client (PHC) process supports Secure Zero Touch Provisioning (SZTP).
You can use RFC-8572-based SZTP to bootstrap remotely located network devices that are in a factory-default state. SZTP enables mutual authentication between the bootstrap server and the network device before provisioning the remote network device.
To enable mutual authentication, you need a unique digital voucher and DevID (Digital Device ID or Cryptographic Digital Identity) programmed network device. The DevID is embedded inside the Trusted Platform Module (TPM) 2.0 chip on the network device. Juniper Networks issues a digital voucher to customers for each eligible network device.
We support SZTP on management and WAN interfaces.
DHCP-based legacy ZTP is disabled. We do not support DHCP-based legacy ZTP on hardware that supports SZTP.
SZTP is compliant with RFC 8572 and requires the following infrastructure to ensure the identity and authenticity of your network devices:
Trusted Platform Module (TPM) 2.0
Digital Device IDs (DevIDs)
DevID Certificates
X.509 Pinned Domain Certificates (PDCs)
Owner Certificates
DevID Trust Anchors
Vouchers
For information on how to generate vouchers, see Generate Voucher Certificate.
To onboard your Juniper devices with Secure ZTP, see Secure ZTP Quick Start Guide.
Benefits
You can provision a remote network device without manual intervention.
You can provision a network device securely from a central location, which prevents unauthorized entities from taking control of your network device.
Your redirect and bootstrap servers verify the authenticity of your network device based on the DevID that's programmed in the network device's TPM.
Your network device verifies the authenticity of your redirect servers and bootstrap servers, and bootstrap information, based on the devices' vouchers.
Use Case
For network devices that are shipped from the factory, you can make the network devices operational both securely and remotely without manually touching the network device. The network device needs to be able to use the Dynamic Host Configuration Protocol (DHCP) to obtain network connectivity information and connect to a remote bootstrap server.
SZTP Requirements
To deploy SZTP in your network, you need to perform the following tasks:
Deploy your DHCP and DNS servers.
Configure DHCP V4 option 143 or DHCP V6 option 136 on your DHCP server, so the DHCP server can advertise the names of your redirect and bootstrap servers.
Deploy your redirect and bootstrap servers.
Acquire DevID trust anchors from Juniper Networks.
Generate owner certificates for one network device or a group of network devices.
Generate pinned domain certificates (PDCs) for each network domain.
Acquire vouchers from Juniper Networks.
Generate redirect and bootstrap information for each network device.
Use the redirect and bootstrap information that the redirect and bootstrap servers provide to provision your network devices.
After you deploy SZTP in your network, and then deploy a new network device, the network device bootstraps automatically.
SZTP Infrastructure Components
- Trusted Platform Module (TPM) 2.0
- DevIDs
- DevID Certificates
- X.509 Pinned Domain Certificates (PDCs)
- Owner Certificates
- DevID Trust Anchors
- Voucher Certificates
Trusted Platform Module (TPM) 2.0
The TPM is a microchip that provides security-related functions. During the manufacturing process, Juniper Networks programs the TPM with a digital device ID (DevID) and an asymmetric keypair (public key and private key). The TPM locks the private key of the asymmetric pair in a tamper-proof location.
DevIDs
The DevID corresponds to the private key and protects the private key. Applications that require signing or encryption use the DevID private key.
Applications running on your network device use the DevID private key in the network device's TPM to prove the identity of the network device to a remote verifier.
DevID Certificates
Juniper Networks generates a DevID certificate (X.509 certificate) for the public key that corresponds to the DevID of the private key. The DevID certificate contains the serial number of the network device for which the DevID was created. DevID certificate is generated conforming to the IEEE 802.1AR standard.
X.509 Pinned Domain Certificates (PDCs)
Create an X.509 pinned domain certificate (PDC) for every network domain. The PDC can be either a root CA certificate or an intermediate CA certificate. Convert the PDC from distinguished encoding rules (DER) to base 64 encoding. Make sure that the PDC is a certificate authority (CA) and conforms to X.509.
Owner Certificates
The owner certificate verifies the vendor that bought or owns the network device. Generate an asymmetric key pair (public key and private key) for each network device or group of network devices. The key pair needs to use either Rivest-Shamir-Adleman (RSA) or elliptic curve cryptography (ECC). Keep the private key protected in a secure location. The Pinned Domain Certificate (PDC) should be the CA for the owner certificate.
DevID Trust Anchors
Juniper Networks provides DevID trust anchors. Install the DevID trust anchors in redirect and bootstrap servers to verify the DevID certificate that the device or client presents while it establishes a TLS session.
Voucher Certificates
To receive voucher certificates, enter the PDC and the network device's serial number in the Juniper Agile Licensing (JAL) Portal. Once you receive the voucher certificates, include them as part of the bootstrap information on your bootstrap server. The bootstrap server provides the voucher certificates to your network devices. Your network devices then use the bootstrap information to verify the trust anchors that your redirect server provides.
For step-by-step instructions on how to receive vouchers, see Generate Voucher Certificate.
DevID Workflow
When an application requires signing or encryption that uses the DevID, the application requests a TLS session with the bootstrap server.
- The bootstrap server sends a TLS response to the network device asking the network device to do the following:
- Provide its DevID certificate
- Prove that it has a private key
The network device signs the session data with the DevID of the private key.
The network device sends the digital signature and the DevID certificate to the bootstrap server.
- The bootstrap server uses the DevID certificate to verify the digital signature.
The bootstrap server uses the DevID trust anchor that Juniper Networks provides to verify the DevID certificate.
Onboarding Information
In order for a network device to bootstrap itself and establish secure connections with other systems, you need to provide onboarding information. Onboarding information is data that a network device uses to bootstrap itself and connect with other systems. When a network device sends this data, the data needs to be encoded in a format that conforms to RFC 8572.
- Boot Image Information
- Download URI
- Image Verification
- Configuration Handling
- Pre-configuration Scripts
- Post-configuration Scripts
Boot Image Information
Boot image information includes the name of the OS and the OS version. We recommend that you specify "Junos" as the OS version. Make sure that you specify the correct OS version to prevent the network device from continuously downloading and installing software.
Download URI
The download URI provides the location of the boot image.
Image Verification
The image verification field includes the hash algorithm that you use to generate a secure hash for the software image and the digest value of the software image. SZTP supports SHA256. Encode the digest value as a hexadecimal string.
Configuration Handling
SZTP can either merge or replace a configuration. Create the configuration in XML and encode the configuration to Base 64 format. The configuration needs to in Base 64 format so that bootstrap server can include it in its bootstrap information.
Pre-configuration Scripts
SZTP supports Bourne shell scripts and Python scripts. The Bourne shell script interpreter path is #!/bin/sh, and the Python interpreter path is #!/usr/bin/python.
If the script is a Bourne script, SZTP checks the end value of the script. If the script exits with nonzero value, the SZTP process restarts. If the script is a Python script, SZTP doesn't check the end value of the script. The output of a script could have errors even if the script ran successfully.
Here's an example of the onboarding information in XML:
=============================
<onboarding-information>
<boot-image>
<os-name>Junos</os-name>
<os-version>22.2R1</os-version>
<download-uri>https://example.com/path/to/image/file,https://example-1.com/path/to/image/file</download-uri>
<image-verification>
<hash-algorithm> </hash-algorithm>
<hash-value>ba:ec:cf:a5:67:82:b4:10:77:c6:67:a6:22:ab:7d:50:04:a7:8b:8f:0e:db:02:8b:f4:75:55:fb:c1:13:b2:33</hash-value>
</image-verification>
</boot-image>
<configuration-handling>merge</configuration-handling>
<pre-upgrade-script>base64encodedvalue</pre-upgrade-script>
<configuration>base64encodedvalue</configuration>
<post-configuration-script>base64encodedvalue</post-configuration-script>
</onboarding-information>
=========================================
Post-configuration Scripts
The pre-configuration script requirements also apply to post-configuration scripts. If any post-configuration script fails, your device rolls back to the configuration it was running before the pre-configuration script was executed. The SZTP process restarts.
DHCP V4 Option 143
Configure DHCP V4 option 143 on your DHCP server before it can provide any IP addresses to the DHCP client.
If you use an MX-Series device as a DHCP server, enable DHCP V4 Option 143.
Here is a sample configuration:
access {
address-assignment {
pool p1 {
family inet {
network 192.168.2.0/24;
range r1 {
low 192.168.2.2;
high 192.168.2.254;
}
dhcp-attributes {
maximum-lease-time 2419200;
server-identifier 192.168.2.1;
router {
192.168.2.1;
}
}
option 143 hex-string 001368747470733a2f2f6578616d706c652e636f6d;
}
}
}
DHCP V6 Option 135
Here is a sample configuration:
access {
address-assignment {
neighbor-discovery-router-advertisement p2;
pool p2 {
family inet6 {
prefix 2001:db8:::/64;
range r1 {
low 2001:db8:::200/128;
high 2001:db8:::299/128;
}
dhcp-attributes {
dns-server {
2001:db8:::8888;
}
}
option 135 hex-string 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574;
}
}
}
Converting Hexadecimal Format to ASCII Text Format
This hexadecimal text string in the DHCP V6 Option 135, for example, is equal to 26 bytes in ASCII text format. In hexadecimal format, 26 is represented as 001a. Each hexadecimal number is equal to one byte, and each byte is equal to a combination of ASCII characters.
To convert the 001a68747470733a2f2f6d782d7068732d736572766572362e6e6574 hexadecimal string to ASCII characters, you need to map the hexadecimal letters and numbers to ASCII letters, numbers, and symbols.
In this example, we're mapping the URL used for DHCP Option 135. You can use the same process for the URL used in DHCP Option 143.
Here's an example URL that shows the mapping beween hexadecimal format and ASCII format. You can see that each hexadecimal number is mapped to letters and symbols in ASCII format:
68(h) 74(t) 74(t) 70(p) 73(s) 3A(:) 2F(/) 2F(/) 61(a) 62(b) 2D(-) 63(c) 64(d) 65(e) 2D(-) 73(s) 65(e) 72(r) 76(v) 65(e) 72(r) 36(.) 2E (n)6E 65(e) 74(t)
The final URL is https://ab-cde-server.net.
Use a hexadecimal to ASCII converter and vice versa to make sure your results are correct.
SZTP Workflow
If your device isn't already in a factory-default state, issue one of the following commands to bring your device into a factory-default state.
On network devices running Junos OS, issue the
request vmhost zeroizecommand.For network devices running Junos OS Evolved, issue the
request system zeroizecommand.
When a device boots up in a factory-default state, the following events occur.
The DHCP client sends a request to the DHCP server to obtain the name, IP address, or host name of either the bootstrap server or customer redirect server.
Configure either DHCP option 143 for V4 or DHCP option 135 for V6. The DHCP client requests the IP address for each bootstrap or redirect server until the device completes bootstrapping.
The DHCP server sends the server host name of either a bootstrap or a customer redirect server to the DHCP client.
The phone-home client (PHC) on your device sends a bootstrap request to the server it learned from the DHCP option. If you've provided multiple servers in the DHCP option, the device tries to bootstrap with each server sequentially.
The device tries to bootstrap with any bootstrap, customer redirect, or DNS server that the PHC learns through the DHCP option. The device attempts to bootstrap to a server in round-robin fashion until the device bootstraps successfully.
The bootstrap server responds with signed onboarding information along with the owner certificate and ownership voucher.
- The PHC uses the information in the owner certificate and ownership voucher to verify the signed onboarding information.
The PHC extracts image and configuration information.
If the device is running a different image, the device downloads the image, uses the new image to upgrade, and then reboots with the new image.
Post reboot, the entire SZTP sequence repeats, except that device doesn't reboot because it already has the required image.
The PHC commits the configuration.
(Optional) The PHC runs post-configuration scripts.
The PHC sends a bootstrap complete message to the PHS.
The device cleans up the PHC-related configurations and resources.
The PHC terminates.
Script Type |
Interpreter Path |
Platform Support |
|---|---|---|
Shell script |
|
All network devices |
Python script |
|
Network devices running Junos OS with Enhanced Automation Network devices running Junos OS Evolved |
SZTP for Network Devices with Dual Routing Engines
Before you upgrade the software on the backup Routing Engine on a network device that run Junos OS software, enable the secure-ztp provision-backup-re statement at the [edit system] hierarchy on the primary Routing Engine
On network devices that run Junos OS software, enable the provision-backup-re statement at the [edit system] hierarchy on the primary Routing Engine, so it can bootstrap the backup Routing Engine.
On network devices that run Junos OS Evolved software, enable the auto-sw-sync statement at the [edit system] hierarchy, so that the primary Routing Engine ensures the same image version is on the backup Routing Engine through either an upgrade or downgrade.
On Junos OS-based systems with dual Routing Engines, the primary Routing Engine downloads the image even if the primary Routing Engine is already running the required image version. The device downloads the image so that the primary Routing Engine is ready to upgrade the backup Routing Engine, if needed.
On Junos OS Evolved-based systems, the primary Routing Engine always keeps a copy of the image it is running.
If you haven't enabled the synchronize statement at the [edit system] hierarchy or Graceful Restart Engine Switchover (GRES) on the primary Routing Engine, the primary Routing Engine doesn't synchronize the configuration and state to the backup Routing Engine. In this situation, the primary Routing Engine verifies the authenticity of the backup Routing Engine before it synchronizes any data with the backup Routing Engine.
Before the primary Routing Engine provisions the backup Routing Engine, the primary Routing Engine verifies the authenticity of the backup Routing Engine. The primary Routing Engine checks the DevID of the backup Routing Engine to make sure that the backup Routing Engine is a Juniper-authorized Routing Engine.
The primary Routing Engine doesn't check whether the backup Routing Engine is authorized to receive information from the primary Routing Engine. Also, the backup Routing Engine doesn't verify authenticity or authorization of the primary Routing Engine.
The primary Routing Engine provisions the backup Routing Engine in the following situations:
When the primary Routing Engine has bootstrapped using SZTP.
When the backup Routing Engine is present when the primary Routing Engine is bootstrapping or inserted during the SZTP process.
When the backup Routing Engine reboots or is replaced.
Once the primary Routing Engine verifies the backup Routing Engine's authenticity and meets the requirements for provisioning, the primary Routing Engine checks the version of software that is running on the backup Routing Engine. If the backup Routing Engine's software version is different from the primary Routing Engine's software version, the primary Routing Engine upgrades the backup Routing Engine to the same software version that the primary Routing Engine is running.
When both Routing Engines are running the same software, the primary Routing Engine synchronizes its configuration with the backup Routing Engine.