Notes - Secure ZTP
Issues with Classic ZTP
Classic ZTP works well in a secured environment (for example, a data center) but lacks authentication mechanisms to prevent malicious deployment of code/config.
The only security mechanisms that classic ZTP contains are:
Whitelist device serial numbers on the DHCP server
Use HTTPS encryption when downloading artifacts
Secure ZTP improves upon this by creating a secure workflow that is RFC-based (8572). SZTP is meant for deploying routers in the access network, particularly for 5G deployments.
Secure ZTP Workflow
During manufacturing, the router has Cisco certs and a SUDI (secure unique device ID) cert burned into the hardware TAm (Trust Anchor module). The TAm is tamper-proof and implements a hardware-based trust system.
The ZTP server must be setup with a few items:
The config, scripts, software images etc. to be pushed to the routers. These are called artifacts.
The cert of the owner (customer) which will be used to sign the artifacts
The ownership voucher
This is obtained through Cisco and signed by Cisco. This includes the device’s serial number and the owner cert, which allows the router to use a chain of trust to validate the individual artifacts. (Since the router can validate the Cisco cert due to the pre-loaded certs in TAm during manufactoring).
Bootstrapping data
This is YANG modeled data which contains:
Conveyed information, which has either redirect information to another server, or onboarding information (image, configuration, and script names and paths to download them)
Owner cert
Ownership voucher
The router can be configured to only use secure-mode for ZTP. It seems that routers can come from the factory with this flag set so that they won’t boot into classic ZTP mode. If not, you can set this with an exec CLI command.
The router begins by running a DHCP client on its mgmt interface for v4 and v6, and then the data plane interfaces if that fails. With SZTP, the router ignores the normal bootfile options returned by the DHCP server. It only uses option 143 or option 136 (DHCPv6) which is a SZTP Redirect option. This redirects the router to the ZTP server.
The router then sends an HTTPS request to the ZTP server using the URL specified in option 143/136. This contains the device’s client certificate (SUDI). The ZTP server validates the router based on the SUDI.
The ZTP server sends the bootstrapping data to the router. The router verificates the ownership voucher by using its preconfigured Cisco trust anchor. It then uses this to validate the owner cert. It then downloads the image and other artifacts and validates these using the owner cert.
The router provisioning begins. The boot image is installed, a pre-config script is executed, the initial config is commited, and then a post-config script is executed. The router can report its status to the ZTP server (which is typically Crosswork) and Crosswork can automatically add the router to the device inventory.
Diagrams
This slide is from the Cisco Live CCIE-SP prep presentation. This shows the differences between classic and secure ZTP:
This is a diagram of the workflow for SZTP:
Further Reading
Last updated
