The Secure ZTP feature is enabled by default, and it cannot be disabled. The feature coexists with the classic ZTP. Based on the response that comes from the DHCP server, either ZTP or Secure ZTP is enabled. Option 67 triggers ZTP, and Option 143 or 136 triggers Secure ZTP. To use Secure ZTP, users must get an ownership voucher from a Cisco Manufacturer Authorized Signing Authority (MASA) server. Secure ZTP supports only Python scripts. Note Secure ZTP Workflow This section describes the Secure ZTP workflow: 1. When a device that supports the Secure ZTP boots up and does not find the startup configuration, it enters the ZTP mode, and triggers the Plug-n-Play (PnP) agent. 2.
The PnP agent locates a DHCP server, obtains an IP address from the server, and checks the response for Options 143 (DHCPv4) or 136 (DHCPv6). If either of these options is available, Secure ZTP is started. The DHCP server must already be configured. Note 3. The device starts a recursive algorithm of iterating over the bootstrapping servers, trying to get valid bootstrapping data. The algorithm is recursive because a bootstrapping server can return redirect data, in which case, new bootstrapping servers are added to the top of the list.
The algorithm stops when either the bootstrapping data is received and successfully applied, or when the list of servers is exhausted after not receiving any bootstrapping data. A bootstrapping server is a RESTCONF server, and the data transport protocol is HTTPS. Note 4. The server validates and provisions the device. The device presents its Cisco Secure Unique Device Identifier (SUDI) certificate to the bootstrapping server during TLS handshake. The device can accept the server certificate either by verifying it against a server-trust anchor that the device learned previously, or without verification. 5.
The device requests bootstrapping data from the server through a RESTCONF POST request by using the ietf-sztp-bootstrap-server:get-bootstrapping-data RPC. The bootstrapping server can provide either redirect or onboarding data in the response message. The onboarding information that is received from the bootstrapping server will be signed data. 6. The device checks the headers of the CMS structures that contain the bootstrapping artifacts to decide whether decrypting is required, and the format (JSON or XML) of the data used. If required, decryption is performed by using the device’s private SUDI key. Zero-Touch Provisioning Secure ZTP Workflow Zero-Touch Provisioning 4