You are here
Zero-Touch Provisioning for uCPE – Part 4
In parts 1, 2 and 3 of this blog series, we discussed the issues of security and licensing as they relate to ZTP. In this last installment, we will review RAD’s ZTP solution over public networks. While reviewing it, we will be able to see, step by step, how it addresses security and licensing.
To DHCP or not to DHCP?
When a network device boots up for the first time, the first step is to have it connected to its network management system (NMS), usually residing in the service provider’s (SP) network operations center (or NOC). Once the device’s management is established, all life-cycle operations, as well as the service itself, can be performed. This step is usually referred to as “call-home”. As already discussed at the beginning of part 1, zero-touch is a system that allows a network device, upon its first boot, to call home. In order to do that, the network device needs to receive some basic information, such as: The IP address of the NMS, means of connectivity to the NOC and any relevant information that is needed to secure the connection.
When a network device boots for the first time, it will usually look for a “nearby” DHCP server to get its IP address, as well as other IP-related settings such as its IP subnet, default gateway and DNS settings. Through this DHCP server, the device could also potentially receive the required call-home information. However, in order for that to happen the DHCP server must be controlled by the SP itself, so that the relevant call-home information could be installed on it in advance. Indeed, if the device is located within the SP’s VPN and the DHCP server is owned and controlled by the SP, this would be trivial. On first boot, the device connects to the DHCP server to receive its IP as well as its call-home settings. This is usually done via a standard DHCP option that redirects the device to another TFTP server, from which it can obtain the call-home information that was planted there in advance. This procedure is sometime also referred to as on-net ZTP.
It is the cases where the device is not located within the cozy boundaries of the SP’s VPN (e.g., when it’s connected to the internet) that require special attention. Now, the local DHCP server is out of the SP’s control (e.g., when it belongs to the internet service provider), so the call-home information must be provided to the device in a different way. This use case is also referred to as off-net ZTP and will be the focus of our discussion here.
A step-by-step description of off-net ZTP using RAD’s uCPE
Before the device can be sent for installation at a remote location, it must be “staged”. The staging process usually includes the installation of the device’s software (e.g., the uCPE operation system) on the bare-metal hardware as well as any other software images that would be needed later, such as VNF images (see Step 1A figure below).
Step 1A: Device staging – bare-metal vCPE-OS installation
During the staging process, we will also give the device its default first-boot configuration. In other words, we will instruct it exactly what to do when it boots for the first time (e.g., obtain IP settings from a local DHCP server, get a bootstrap (BS) server’s IP address based on preconfigured URL, etc.). Additionally, security certificates, if needed, will also be installed at this stage.
The staging process can take place either by the device’s vendor as part of the manufacturing process, or by the SP itself in its staging facility. Once completed, the device will include all the required entities that would allow it to successfully perform off-net ZTP (see Step 1B in the figure below). It can be then stored in the SP’s warehouse until shipment.
Step 1B: Device staging - installation of secured entities and minimal staging configuration
For installation, a technician would just need to plug the device to power, physically connect it to the network (via a network cable or a SIM card for LTE connectivity) and report to the SP’s NOC that a device with a given UUID was successfully installed on location.
Step 2: The technician installs the device @ customer premises
Once a device is shipped for installation at a customer location, the SP starts building the ZTP artefact for this device. The ZTP artefact is a file that comprises all the information the device needs in order to call home. The ZTP artefact is prepared in advance by the ZTP configuration server at the NOC and, once the technician reports the successful installation and provides the relevant device UUID, it is finalized and placed within the bootstrap server in a location reserved only for this device. The bootstrap server is basically a storage server that hosts a device’s ZTP artefacts, having a public IP address that can be accessed from anywhere using plain internet access.
Step 3: Backstage ZTP preparation at the NOC
At this stage, all the “board pieces” are set for the main event. Once the device boots for the first time, it would connect to the local DHCP server and obtain a public IP address, as well as its IP and DNS settings. This will allow the device to have internet IP connectivity. Next, a DNS query for the BS server’s IP address is performed and once obtained, the secure TLS connection to the BS server, based on X.509 certificates, can be set. Once securely connected, the device can download the ZTP artefact from the BS server and reboot. After reset, the device will now have its call-home configuration in place.
At this point, the device’s software has still not received its license. Hence, an automatic grace period is usually provided by the OS, to allow all device operations until a connection to the NOC is established.
Step 4: The device connects to the Bootstrap server
Based on the call-home configuration, the device forms the secure VPN connection to the SP’s NOC (again, based on X.509 certificates) and connects to its NMS. At this point, the device will also receive its permanent license, if needed.
Step 5: The device opens a secure VPN connection to the NOC
This last step also brings this blog series to its end. Throughout its four chapters, I was trying to make the reader aware of the various challenges and complexities involved in off-net ZTP of uCPEs. While the information provided primarily reflects RAD’s experience, the general guidelines are considered common practice for many uCPE and uCPE OS vendors.
About RAD's Blog
We’ll be blogging on a wide range of hot topics affecting service providers and critical infrastructure network operators. Our resident experts will be discussing vCPE, Cyber Security, 5G, Industrial IoT and much, much more.