分享一种VoP网络安全问题的解决方案

　　尽管许多宽带 VPN 运行于隧道模式，PacketCable 安全规范却规定了传输模式的安全性。这为电子监控（也称作法律执行通信协助法，即 CALEA）的安全性提出了新的挑战。此外， PacketCable 电子监控规范定义了从线缆调制解调器终端系统 （CMTS） 开始的安全模型，但许多 VPN 都始于 PC 或 IP 电话，其通过 CMTS 和/或媒体网关 （MG） 连接至多媒体终端适配器/线缆调制解调器 （MTA/CM） 以及隧道。只有这些具体的终端设备知道密钥及相关参数。另一个要考虑的问题则是安全 RTP （SRTP），它提供语音的端至端加密。不仅加密/解密是一个挑战，在某些情况下截取消息也困难。具体而言，其实例之一就是在 NAT 存在时尝试加密/解密。
　　CALEA 安全挑战
　　安全服务的目标在于保障隐私、数据包完整性、认证与不可否认性。以下我们给出这四项的简单定义：
　　隐私：数据包不能被截取。
　　数据包完整性：数据包未被修改。
　　认证：参与通信者是他/她指定的人
　　不可否认性：发送与接收的消息不可否认。
　　在本文中，数据包可为数据、语音、信号、视频、影像或任何其它格式。 CALEA 是电子监控的另一说法，指执法人员接入通信通道进行信息截取（而不是修改）。但是，CALEA 的目的似乎与安全性目标相冲突，但是，我们确实有截取 VoP 数据包的执法需求。在 VoP 上支持 CALEA 对反恐斗争非常有意义，因为许多恐怖活动都在因特网上发生。美国通信工业协会 （TIA） 力推因特网上的 CALEA，目前还在为 PSTN 与分组网络上的 CALEA 制定标准。此外，美国联邦通信委员会 （FCC） 希望对分组网络的 CALEA 支持加以管理。
　　从后勤角度看，分组网络（特别是因特网）是否应接受 FCC 电信规则管理尚有争论。从技术角度说，还有许多问题尚待解决。
　　安全机制
　　安全机制始于在两个端点间建立安全关联 （SA）。建立 SA 要求分两步走：第一步是进行两个端点的认证；第二步是交换加密与解密的密钥。SA 建立后，两个端点都用密钥进行加密与解密。
　　在两个端点之间，数据路径上还有许多其它设备要考虑到。如果路径中至少有一个设备与 SA 建立相关，则 SA 处于传输模式。中间设备称作安全网关 （SG），SG 具有从两个端点进行数据包加密与解密的密钥，而两个端点不能进行数据包的加密与解密。因此，在传输模式中，SG 可提供截取盒子 （box） 所需的密钥，以支持 CALEA。
　　如果路径中没有其它设备参与 SA 建立，则 SA 运行于隧道模式。在这种情况下，只有这两个端点具有加密与解密的密钥。这时，执法人员仍可截取数据包，但他们没有密钥就无法进行数据包解密。因此，隧道模式网络不采取新方法就无法支持 CALEA。
　　呼叫信号发送与 CALEA
　　在 VoP 网络中，信号数据包采用与媒体路径不同的路径。信号数据包在端点与呼叫服务器 （CS） 或代理服务器 （PS） 之间传输，而媒体数据包则在两个端点间传输。端点与 CS 或 PS 之间通常有一个 SA，两个端点间通常也有一个 SA。每个 SA 都彼此独立。端点与 CS 之间的 SA 可对所有呼叫建立一次，也可对每次呼叫分别建立。但是，端点与 PS 之间的 SA 则必须在两个端点间每次呼叫的 SA 之前建立。为了防止干扰信号，SA 必须具有有限的时限，通常为几秒钟至几分钟。如果时限过期，则 SA 将断开。因此，SA 必须在时限过期前重新建立或更新。
　　在信号数据包内，媒体路径在会话描述协议 （SDP） 等不同的协议中指定。媒体路径由多个参数决定，如应用端口、RTP/RTCP 端口以及 IP 端口。如果执法人员不能进行信号发送路径与媒体描述协议的解密与解释，则执法人员就不知道两个端点间选择了哪条路径，因此也就无法进行媒体数据包的截取与解释。
　　NAT 与 CALEA
　　网络地址转换 （NAT） 用于设备中将一系列专用 IP 地址映射到一个或更多公用 IP 地址中。对 SIP、SNTP、FTP 等不同应用，每个应用中必须实施专用算法 （ALG） 以支持 NAT。
　　当端点进行数据包（其在报头与媒体描述字段如 SDP 中带有专用 IP 地址）加密时，NAT 器件必须有进行数据包解密的密钥以及修改报头与媒体描述字段中地址字段所需的密钥，否则它就必须关闭 NAT 功能，并向每个设备分配公用 IP 地址。如果端点不愿向 NAT 器件提供密钥，则 NAT 器件可实施与 CALEA 截取盒 （intercept box） 获得相同密钥的安全与 CALEA 机制。但是，NAT 器件与执法人员不同，它不能获得授权合法进行数据包截取与解释。
　　执法人员必须具有密钥，并得到带有 ALG 的 NAT 的支持，这样应用才能截取来自目标设备的数据包。这里的挑战在于如何知道应将哪个专用 IP 地址映射到给定公用 IP 地址。此外，截取盒必须从 NAT 器件得到此信息。
　　不同的安全与加密协议
　　可用的安全协议有很多种。举例来说，有 IPSec、SSH、SRTP 等。在每个安全协议中可能采用不同的加密/解密协议。不管是数据加密标准 （DES）、三重数据加密标准 （3DES），还是高级加密标准 （AES），IPSec 可与任何加密协议共同使用。每个加密协议中还可使用不同的密钥大小。加密协议、密钥大小以及其它参数在 SA 建立时协商制定。CALEA 截取盒必须能够支持各种安全协议、加密方法及其相关参数（如密钥大小）。
　　软硬件加密的比较
　　加密要占用大量的处理时间。为提高效率，某些设备用硬件进行加密/解密。由于硬件加密只是针对一种加密协议，因此 CALEA 截取盒很难为多种安全与加密协议提供硬件加密。当目标设备可能用硬件进行加密/解密时，CALEA 截取盒必须配备快速处理器进行加密。
　　安全机制与CALEA
　　“PacketCable 安全规范”PKT-SP-SEC-I109-030728 与“PacketCable 电子监控规范”PKT-SP-ESP-I102-030815 仅指定了传输模式的安全模型。这两个规范没有提到如何处理隧道模式的情况。
　　“PacketCable 电子监控规范”显示，安全传输模式由 CMTS 执行，而不是由 PC 或 IP 电话 （IPP）等端点执行。但是，目前 VoP 市场上的安全性大多数实施于端点上，且其中大部分为隧道模式，因此 PacketCable 必须处理这种安全架构。
　　前面各部分中列出的 CALEA 面临的其它安全问题同样也是 PacketCable 的问题。
　　解决方案：为了解决 CALEA 的安全问题，CALEA 截取盒必须在 SA 建立的初期截取发自目标设备的数据包，以获得所需的密钥以及其它安全参数。在哪里进行截取取决于以下诸多因素：NAT、动态主机配置协议 （DHCP）、VPN/安全端点等。
　　如果 VPN/安全端点为 PC 或 IPP，则端点如何获得 IP 地址非常重要。如果端点 IP 地址通过动态主机配置协议 （DHCP） 获得，则不存在 NAT，截取可在任何设备中进行。但是，来自相同设备的数据包可能选择不同的路由，因此，我们最好在数据包选择另一路径前（通常是从 CMTS 到因特网）截取数据包。
　　有 NAT 时，最好的截取处就是 NAT 功能所在的地方。正如“PacketCable 电子监控规范”定义的一样，这常常是 MTA，而不是 CMTS。但是，NAT 也可能在 CMTS 上。NAT 单元将专用 IP 地址映射到公用 IP 地址上，反之亦然，因此数据包应在执行 NAT 之前在 LAN 站点上截取。否则，截取盒就要在相同公用 IP 地址的混合消息流中进行数据包过滤。此外，NAT 单元带有应用算法 （ALG），可处理专用的转换功能。例如，最初传送进来的 SIP 呼叫只有公用 IP 地址。NAT 单元如何知道应该映射到哪个专用 IP 地址呢？它必须运行 SIP ALG，其以 SIP 消息中的用户 ID（如alice@wonderlane.com）或报头中的 CallerID 来查找 Alice 的专用 IP 地址。请注意，Alice 必须已经以她专用的 IP 地址及其姓名和/或 CallerID 在 NAT 器件上注册。
　　一旦 CALEA 截取盒能够截取目标设备的数据包，则其应设法获得 SA建立消息。如果安全机制不是基于标准协议之上，则执法人员解释安全消息以及随后进行 SA 消息与媒体数据包的解密就会面临很大的困难。如果安全消息基于标准协议之上，则 CALEA 截取盒应该可从 SA 建立消息计算出密钥、密钥大小以及加密方法。
　　美国 TIA 发布了一系列 PSTN 中 CALEA 的消息格式。由于因特网的架构、协议集、消息格式与呼叫流程 （call flow） 完全不同，因此 TIA 必须发布因特网 CALEA 传输的全新系列规范。PacketCable 规范可作为子集，事实上 TIA 也提到了这些情况。但是，PacketCable 安全规范与 PacketCable 电子监控的修改必须满足许多 VoP 安全要求。此外，尽管原理相同，非基于线缆的 VoP 安全解决方案应在 PacketCable 规范外另行规定。
　　结论
　　VoP 网络中的 CALEA 面临许多新的安全挑战，主要挑战就是如何截取发自或发往目标设备的数据包以及如何进行数据包的解释与加密/解密。本文提出了一些 VoP 网络安全问题的解决方案，但还有一些 VoP 厂商、服务提供商与执法人员面临的难题未能解决。解决这些问题将推动业界实现下一步发展。