Your Network's Edge®
Blog Post
You are here
Zero-Touch Provisioning for uCPE – Part 1
Mar 04, 2019
In this blog series, we will focus on zero-touch provisioning (ZTP) for uCPEs over a public network. In particular, we will discuss the two main challenges of security (parts 1 and 2) and licensing (part 3). Part 4 of this blog will explore RAD’s uCPE ZTP solution in detail. A device MAC address or manufacturer serial number are usually not considered, on their own, a secured-enough identity, as in many cases they can be forged quite easily.
Automating the NOC in the era of uCPE
Zero-touch provisioning has always been one of the key operational concerns for telecom service providers. It greatly simplifies operations when any new device that is being installed in the network, can miraculously find its way “home” and connect to the service provider’s network operations center or NOC, from which it can be further managed.
The increasing use of SD-WAN solutions has pushed the telecom devices far beyond the traditional boundaries of the service provider VPNs. More and more universal CPE (uCPE) devices, on-boarded with an SD-WAN function, are installed today at remote point of presence (PoP) locations with only the public network (i.e. internet) connecting the device to the service provider’s NOC.
Communicating over a public network is a completely different ball game as far as security is concerned. Whereas traditional ZTP solutions could rely on the SP’s VPN to protect them from the dangerous world outside, now the device itself is part of that world and must protect itself from it. Furthermore, the transport of information between the device and the NOC must be completely secured.
uCPE is a relatively new telecom “creature”. A uCPE device is usually some commercially of the shelf (COTS) piece of hardware, also referred to as a White Box or WB (typically based on some multi-core x86 or ARM processor) that runs a Linux-based OS. Unlike traditional telecom equipment, for which both hardware and software were provided by the same vendor, uCPE allows SPs to purchase the hardware from one vendor and the software (i.e. the uCPE OS) from another. As a result, service providers enjoy lower vendor dependency and better economies of scale. However, these great merits introduce a new operational challenge in the form of software licensing. Each instance of this uCPE OS must be licensed before the uCPE can be made fully functional.
The security challenges
As already mentioned above, there are two main security challenges for a uCPE device that has a WAN interface connected to the public network (via Broadband or LTE connections):
The first, is to make sure that no malicious party can penetrate the device, disrupt its functionality or implant malware within it. Thus, any device that is connected to the internet (including your PC at home) must follow some hardening best practices. Such best practices include (but are in no way limited to) the use of Access Control Lists or ACL and also basic firewall capabilities to allow some level of protection from Denial Of Use/Service or DoS attacks. Such protection is pretty much a standard procedure today and is not only related to ZTP. It will not be our focus here.
The second challenge is to make sure that all inbound and outbound communications to/from the device, over the exposed WAN interface, is tightly secured. This basically mandates the use of secured communication tunnels between the device and the relevant ZTP/NOC network resources it needs to connect with. Such tunnels will usually include the use of Authentication, Encryption (or Privacy) and Integrity protection.
The use of encryption is straightforward and well understood. We always assume that the information running on these tunnels can be intercepted by a malicious eavesdropper. After all, this is a public network and someone with enough skills might be able to do that. Hence, by encrypting all the information running on these tunnels we can make sure it will be meaningless to the interceptor.
Authentication and integrity, on the other hand, are less intuitive and the two terms are sometimes being confused.
Authentication vs. integrity
Authentication is usually the initial phase of the conversation (or, in our case, the establishment of a secure tunnel). This is exactly what each of us is doing, unintentionally, when we call someone. As soon as the other party answers the call and starts talking, our brain will expect certain speech characteristics that are typical of our peer (assuming we know them, of course). If we will not hear the expected familiar voice, we will start asking questions and definitely will not agree to disclose sensitive information.
Another very common example is when we log into our bank account on the web. Before we get access to sensitive information we must provide our personal username and password. Based on these, the bank can make sure we really are who we say we are. Most of us are not aware of that, but at the same time we authenticate ourselves to the bank, our internet browser is also authenticating the bank website using a very important tool called security certificates. This is done to prevent our http session from being redirected to some malicious website, pretending to be our bank, in order to steal our identity. More on certificates later on.
Integrity is usually employed together with encryption on the actual sent/received data, after the initial authentication phase was completed successfully. Encrypting the data only prevents a third-party from seeing it, but it is not enough. It does not prevent a “man in the middle” from attacking by manipulating the traversing information in a manner that is harmful to the naïve peer. As a matter of fact, there are various known man-in-the-middle attacks that could be unleashed if connection integrity measures are not enforced. Using proper integrity mechanisms ensures that each end-point on the call is able to detect any content manipulation.
All known secure communication tunnels, such as IPsec and SSL/TLS incorporate the three security mechanisms described above, unless otherwise requested by the user. Encryption and integrity are based on symmetric keys[1] that are generated and exchanged with both sides of the call after the initial authentication phase is completed. Hence, no a-priori provisioning for such keys is required. Authentication, on the other hand, it trickier in that regard.
In order to prove my identity, I need to either provide some secret that only I know (e.g. a password), some artifact that only I have (e.g. an ID of some sort) or something that “I am” (i.e., something that is intrinsically and exclusively mine, such as my fingerprint). A generic piece of hardware that is completely identical to the many thousand others that were manufactured before and will be manufactured after, does not normally have distinctive features[2]. Moreover, when it is sent for installation at a remote PoP, it still does not yet have any unique configuration installed. Hence, the use of passwords or secret keys (e.g. PSKs) for the very first secure communication establishment is not applicable. This is where security certificates come in handy.
Check out our next blog post for more on security certificates.
[1] Meaning that, the same encryption key and integrity key – usually different symmetric keys – are used by both end-points for encryption/decryption as well as for data integrity checks.
[2] A device MAC address or manufacturer serial number are usually not considered, on their own, a secured-enough identity, as in many cases they can be forged quite easily.
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.