Securing zero touch for uCPE deployments

Service providers are working to replace customer premises equipment (CPE) appliances with software running on a standard platform referred to as universal CPE (uCPE). They also want to minimize the steps required for setting up uCPE, both in the supply chain and at the customer site. In an ideal situation, the deployed uCPE would not require user intervention, and there would be no need for a technician on site. This is what we refer to as zero touch.

 But the real world is not that simple, and there are some open questions about how to achieve zero touch on uCPE while maintaining both service and network security:

• How can we minimize the number of manual steps required?
• What steps are reasonable for a non-technical end user to take?
• How can we simplify the supply chain to allow direct shipments to the end user site, without needing per-site staging?
• Can the customer provider the uCPE equipment, i.e. bring your own hardware (BYOH)?

I was discussing these questions at a recent conference. Some of my discussion partners glibly asserted that it was already possible to provide a zero touch model that met the needs of operators. When I started asking questions, it became clear that they had not considered all of the variables. Let’s look at some of those variables for uCPE deployments.

Multiple access models

The first complicating factor is the network access model. Operators need secure zero touch solutions that can work in a wide variety of network situations:

• Wired and wireless. The advent of 5G raises the importance of wireless access, which introduces a new set of security considerations. Besides, wireless connectivity in any given area may be spotty, which emphasizes the importance of resilience and retries in any zero touch algorithm.
• Private line / Carrier Ethernet (CE), Direct Internet Access (DIA) and public internet. Consumer-grade broadband is becoming very good and very fast. It is an important factor in reaching all locations, but it is not secure.
• Layer 2 / CE and Layer 3 / DIA, internet. Layer 2 and Layer 3 access networks have their own strengths and weaknesses. Any access strategy must account for both.
• Operator-supplied and bring your own hardware (BYOH). An operator-supplied box can be considered secure, but operators will have to apply scans and configuration to secure user-supplied devices.
• Appliance and universal CPE (uCPE). Appliances have the advantage of minimizing attack surface but at the cost of service flexibility and innovation.
• Access ports – labeled and unlabeled. Normally the ports on an appliance are distinctly colored and labeled as WAN, LAN, VPN. They may not be labeled as such on a white box server, especially in a BYOH deployment. There may be a need to auto-discover and auto-verify port selection and wiring.

Multiple authentication models

The next question is how to authenticate the uCPE device. Consider the case of a uCPE server that is shipped directly to a customer. How do we know it got to the right place? What if it is stolen and connected to the network by a third party? Do we have to incur the cost of an on-site technician?

Operators need solutions that can work in a variety of authentication models, with varying tradeoffs between cost, security and activation steps. The possibilities include the following:

• Technician-installed. This approach has extra cost but is the lowest risk regarding security and mistakes.
• Self-serve. While lowering cost, this approach also raises the cost of manual steps.
• Authentication code. An emailed code entered at the customer site is a simple path to ensuring the right device was delivered to the right location. Its entry does add a step to the process.
• USB stick. The operator could send a USB stick instead of a code. This removes the complexity of attaching a laptop to the uCPE device, at the expense of generating and shipping a physical key.
• Smartphone app. The complexity of entering a key or inserting a USB stick could be replaced by installing an app and logging in to it and then allowing the app to access the uCPE device.
• Geolocation. Many uCPE devices will have LTE or 5G access, and as a result, will have location services. Using that location is a good way to ensure the device is at the correct location, at the cost of having to have a radio interface installed. In addition, location is based on GPS, which may not always be available inside a building.
• Specified attachment circuit (CE or MPLS). For devices with private wireline access, the location of the end of the access circuit is known and is considered to be secure.
• Time-based window for connection. The operator opens a specific time window for uCPE access. This window would be based on the confirmed delivery of the uCPE to the customer. Once the window was closed, there would be no attachment allowed, at least until the customer called to confirm possession of the device and request a new window.
• Device-specified (Ethernet MAC, serial number or X.509 certificate). These approaches verify the identity of the uCPE device. They don’t verify that the device is at the correct location.

Of course, some of these options are orthogonal, and they could be combined for increased security.

We need a framework

Based on the previous examples, we can see that there is no one-size-fits-all solution. What we need instead is a framework or architecture. Ideally, it would include the following:

• Standards and best practices
• Protocols and APIs
• Solutions for authentication and encryption
• Support for open source and commercial solutions

We at ADVA are tackling this problem to support our service provider customers. We also see progress from groups like the ETSI ZSM ISG and the IETF. Together we can define the tools needed to achieve secure and efficient deployment of uCPE.