本次系列文将重点介绍uCPE的零接触配置(zero-touch provisioning ,ZTP)，包括安全性（第1部分和第2部分）和许可（第3部分）这两个主要挑战。
uCPE时代的NOC自动化
零接触配置一直是电信服务提供商关注的主要运营问题之一。当网络中安装的任何新设备能够奇迹般地找到“回家”的路并连接到服务提供商的网络操作中心(NOC)时，就可以大大简化操作。
SD-WAN解决方案的使用日益增加，电信设备远远超出了服务提供商VPN的传统界限。如今，越来越多带有SD-WAN功能的通用CPE（uCPE）设备安装在远程存在点（PoP）位置，仅通过公共网络（即Internet）将设备连接到服务提供商的NOC。
就安全性而言，通过公共网络进行通信是完全不同的概念。传统的ZTP解决方案可以依靠SP的VPN来保护它们免受外界的威胁，而现在，设备本身就是外部的一部分，必须保护自己免受外部侵害。此外，设备与NOC之间的信息传输必须确保完全安全。
uCPE是一个相对较新的电信“生物”。uCPE设备通常是商用（COTS）硬件的一部分，也被称为白盒或WB(通常基于一些多核x86或ARM处理器)，运行一个基于linux的操作系统。与传统的电信设备（硬件和软件均由同一厂商提供）不同，uCPE允许SP从一个厂商处购买硬件，从另一厂商处购买软件（即uCPE OS）。因此，服务提供商可以摆脱厂商锁定，能够更多地减少成本。然而，这也带来了新的运营挑战。uCPE操作系统的每个实例都必须获得许可，然后才能使其完全发挥作用。
安全挑战
如上所述，对于具有连接到公共网络（通过宽带或LTE连接）的WAN接口的uCPE设备，存在两个主要的安全挑战：
首先，要确保没有恶意的一方可以渗透设备，破坏其功能或植入恶意软件。因此，任何连接到Internet的设备（包括家中的PC）都必须遵循一些规则。此类做法包括（但绝不限于）访问控制列表或ACL的使用，以及基本防火墙功能，以提供一定程度的保护，免受拒绝使用/服务或DoS攻击。如今，这种保护已成为标准程序，不仅仅与ZTP有关。所以这不是本文讨论的重点。
第二个挑战是确保通过公开的WAN接口上与设备之间的所有入站和出站通信都受到严格保护。这要求在设备与其需要连接的相关ZTP/NOC网络资源之间使用安全的通信隧道。此类隧道通常将包括使用身份验证、加密（或隐私）和完整性保护。
加密比较简单明了。我们总是假设这些隧道上传输的信息可以被恶意窃听者截获。毕竟，这是一个公共网络，拥有足够技能的人也许可以做到这一点。因此，通过对这些隧道上传输的所有信息进行加密，可以确保信息不被拦截。
另一方面，身份验证和完整性不太直观，这两个术语有时会混淆。
身份验证与完整性
身份验证通常发生在对话的初始阶段（在本文中指建立安全隧道阶段）。这就像我们每个人在打电话给某人时无意中所做的事情。一旦对方接听电话并开始通话，我们的大脑就会期望某些语音特征是同伴的典型特征（当然，假设我们知道它们）。如果我们听不到期望的熟悉声音，我们会疑惑并开始各种提问，并且绝对不会公开敏感信息。
常见的例子是当我们在网络上登录银行帐户时。在获取敏感信息之前，我们必须提供个人用户名和密码。基于这些，银行才可以确保我们确实是本人。然而大多数人都没有意识到这一点，我们在向银行进行身份验证的同时，我们的互联网浏览器也在使用一种非常重要的工具（称为安全证书）对银行网站进行身份验证。这样做是为了防止我们的http会话被重定向到一些恶意网站，假装我们的银行，以窃取我们的身份。
在初始身份验证阶段成功完成之后，通常将完整性与加密一起用于实际发送/接收的数据。加密数据只能阻止第三方看到它，但这还不够。它不能阻止“中间的人”通过遍历信息的方式进行攻击。实际上，如果不执行连接完整性措施，可能会释放各种已知的中间人攻击。使用适当的完整性机制可确保呼叫中的每个端点都能检测到任何内容操作。
已知的安全通信隧道（如ipsec和ssl/tls）都包含上述三种安全机制，除非用户另有要求。加密和完整性基于对称密钥（即发送和接收数据的双方必使用相同的密钥对明文进行加密和解密运算），这些密钥在初始身份验证阶段完成后生成并与调用双方交换。因此，不需要对此类密钥进行先验设置。
为了证明自己的身份，用户需要提供一些只有自己知道的秘密例如密码，某种ID或用户专有的，例如指纹。一些通用的硬件，完全相同的有成千上万个，并没有什么独特之处（通常，设备MAC地址或制造商序列号本身不会被视为足够安全的身份，因为在许多情况下，它们很容易伪造）。而且，当它被发送到远程PoP进行安装时，也没有唯一的安装置。因此，第一次建立安全通信时使用密码或密钥（例如psk）是不适用的。这就是安全证书派上用场的地方。
