51学通信

深度解析 3GPP TS 33.501：Annex M-P (IAB, URLLC, DNSICMP安全)

18分钟阅读

好的，我们继续深入解读3GPP TS 33.501规范。

深度解析 3GPP TS 33.501：Annex M-P (IAB, URLLC, DNS/ICMP安全)

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“Annex M: Security for Integrated Access and Backhaul (IAB)”、“Annex N: Security for URLLC services”和“Annex P: Security Aspects of DNS and ICMP”的核心章节，旨在为读者深入剖析5G在应对无线回传、超高可靠低时延以及基础互联网协议这三个维度的安全挑战时，所采用的独特而精妙的设计。

随着我们对3GPP TS 33.501规范的解读不断深入，我们越来越多地接触到其附录（Annex）中定义的、针对特定场景的安全增强。这些附录展现了5G安全体系强大的适应性和前瞻性，使其不仅能保护传统的移动宽带业务，更能为未来多样化的网络部署和业务需求提供坚实的安全保障。

今天，我们将深入解读规范的附录M、N、P。这三个附录，如同5G安全工具箱中的“三件特种装备”，分别为三个截然不同的技术场景提供了专属的安全解决方案：

  • 附录M (IAB安全)：当5G基站的“光纤”被剪断，需要用无线信号进行“自我接力”（无线回传）时，这条“空中的光纤”该如何保护？
  • 附录N (URLLC安全)：当5G被用于自动驾驶、远程手术等“零容忍”业务时，安全机制如何为数据的“冗余传输”保驾护航，实现极致的可靠性？
  • 附录P (DNS/ICMP安全)：当5G网络承载最基础的互联网“问路”（DNS）和“心跳检测”（ICMP）协议时，如何弥补这些传统协议在安全上的先天不足？

为了贯穿这些场景，我们将构建三个独立但同样精彩的故事。我们将看到，在偏远山区，一个IAB节点如何以无线的方式，将5G信号安全地传递到更深处；在城市的“无人驾驶示范区”，一辆自动驾驶汽车如何通过冗余的PDU会话，确保其控制指令永远不会因单点故障而丢失；以及信息安全专家“白帽”，将为我们揭示普通的DNS查询背后，可能隐藏的隐私泄露风险和5G的应对之策。

1. Annex M: IAB安全 - “空中光纤”的铠甲

**IAB（Integrated Access and Backhaul，集成接入与回传）**是5G的一项革命性技术。它允许一个gNB（称为IAB节点）不再依赖光纤连接到核心网，而是通过无线的、与普通UE相同的NR接口，连接到另一个有光纤连接的gNB（称为IAB donor）。这极大地降低了在偏远地区、临时大型活动等场景下部署5G的成本和难度。然而，这也带来了一个严峻的安全挑战：回传链路（Backhaul）暴露在了空中。

M.1 General This Annex provides the security procedures applied to NR IAB architecture… for supporting wireless backhauling of NR base stations.

附录M的核心任务，就是为这条“空中的光纤”——即IAB节点与IAB donor之间的无线回传链路——提供与物理光纤同等级别的强大安全保护。

1.1 IAB节点的双重身份与认证 (M.3.2)

IAB节点在网络中扮演着一个独特的“双重身份”：

  • 对IAB donor而言，它是一个“超级UE”（在规范中被称为IAB-UE）。
  • 对它所覆盖的普通UE而言，它又是一个标准的gNB-DU（分布式单元）。

The IAB-UE function shall behave as a UE, and shall reuse the UE procedures specified in this document for the primary authentication…

认证流程： IAB节点的认证，就是利用其“UE身份”来完成的。

  1. IAB-UE注册：当一个IAB节点上电时，其内置的IAB-UE功能模块，会像一个普通的UE一样，使用其专属的UICC（SIM卡/eSIM），通过IAB donor的无线信号，向核心网AMF发起主认证流程。
  2. 建立AS安全：认证成功后，IAB-UE与IAB donor之间会建立起标准的AS安全上下文，拥有K_gNB及其派生的RRC和UP密钥。这条安全的RRC/UP连接，就构成了IAB回传链路的基础。

1.2 F1接口的安全隧道 (M.3.3)

在IAB-UE成功“登录”网络后，其作为“gNB-DU”的身份开始发挥作用。它需要与IAB donor的CU部分建立一条F1接口，以传输其所覆盖的普通UE的信令和数据。这条F1接口的流量，就承载在刚刚建立的、受AS安全保护的无线回传链路上。

M.3.3.2 Security mechanisms for the F1 interface F1 security for IAB is established using the security mechanisms for the F1 interface as specified in clause 9.8.2 of the present document… In addition… the IKEv2 Pre-shared Secret Key (PSK) authentication shall be supported.

F1接口的“双重保护”： 为了实现最高级别的安全，规范要求在已经加密的无线回传链路上，再为F1接口叠加一层IPsec隧道保护。

  • IKEv2认证：建立这条IPsec隧道的认证方式非常独特。它不再使用证书，而是使用一种基于**动态预共享密钥（PSK）**的方式。
  • K_IAB的派生：这个PSK，被称为K_IAB，是由IAB-UE和IAB-donor-CU，基于它们共享的、在Phase-1建立的AS安全上下文密钥**K_gNB**，结合双方的IP地址等参数，通过KDF派生出来的。

场景代入： 在偏远山区，运营商部署了一个IAB节点来扩大覆盖。

  1. IAB节点的“UE模块”开机，通过主基站（IAB donor）的信号，使用自己的eSIM卡，向核心网完成了5G AKA认证。它与主基站之间建立了一条受K_gNB保护的安全无线连接。
  2. 接着，IAB节点的“基站模块”（gNB-DU）需要和主基站的CU部分建立F1接口。
  3. 它们双方都使用刚刚生成的K_gNB，派生出了一个新密钥K_IAB。
  4. 它们以K_IAB作为预共享密钥，通过IKEv2协商，在这条已经加密的无线链路上，又建立了一条专用于F1接口的IPsec隧道。
  5. 当一个登山者的手机连接到这个IAB节点时，他的所有数据，都将经过两次加密：第一次是在他手机和IAB节点之间的空口加密；第二次是在IAB节点和主基站之间的F1-IPsec隧道加密和无线回传链路加密。

这套“认证为UE，工作为gNB”以及“链路加密+隧道加密”的“双保险”机制，确保了IAB网络在提供灵活部署的同时，其安全性不亚于传统的光纤回传网络。

2. Annex N: URLLC安全 - 为“零中断”业务的双重保障

URLLC（超可靠低时延通信）是5G的“杀手级”应用场景之一。为了实现99.999%甚至更高的可靠性，URLLC的一个关键技术是冗余传输——将一份数据同时通过两条独立的路径发送，只要有一条路径成功到达，通信就不会中断。

附录N的核心任务，就是为这种“双路径”冗余传输，提供匹配的安全机制。

N.2.1 Redundant user plane paths based on dual connectivity The UP security policy from the SMF(s) for the two PDU sessions used for redundant data transmission shall have the same setting for encryption and for integrity protection.

核心思想：安全策略同步，密钥体系独立 URLLC的冗余传输可以基于双连接（Dual Connectivity）或双PDU会话来实现。附录N主要关注基于双连接的场景。

  • 场景：UE为了一个URLLC业务，同时与主节点（MN）和辅节点（SN）建立了连接，一份数据会被复制并通过两条路径同时发送。
  • 安全策略同步：规范强制要求，为这两条冗余路径提供服务的SMF，必须下发完全相同的UP安全策略（例如，都要求加密和完整性保护）。这确保了两条路径具有同等级别的安全防护。
  • 密钥体系独立：两条路径的安全实现，完全遵循6.10节双连接安全的规定。即，UE-MN路径使用基于K_gNB的密钥，而UE-SN路径使用基于K_SN的密钥。这两套密钥是相互独立的。

场景代入： 一辆自动驾驶汽车（UE）正在“无人驾驶示范区”行驶。为了确保其控制指令的绝对可靠，它与网络建立了两条冗余的PDU会话，分别通过宏基站（MN）和路边的微基站（SN）进行传输。

  1. SMF策略：负责该业务的SMF，为这两条PDU会话都配置了{Confidentiality=Required, Integrity=Required}的UP安全策略。
  2. 双连接建立：MN和SN分别与UE建立了安全上下文，拥有了独立的K_gNB和K_SN。
  3. 冗余传输：中央控制器发送一条“向左转”的指令。UPF会将这个数据包复制两份，分别通过MN和SN的路径发往汽车。
  4. 独立保护：发往MN的包，在gNB-MN处，使用基于K_gNB的密钥进行加密和完整性保护；发往SN的包，在gNB-SN处，使用基于K_SN的密钥进行加密和完整性保护。
  5. UE接收：汽车的UE会收到两个来自不同基站的、加密方式略有不同的数据包。它会分别用K_gNB和K_SN派生的密钥进行解密和验证，然后将第一个成功到达的、验证通过的指令交给上层的控制系统执行。

这个“策略统一、密钥独立”的机制，确保了URLLC业务在享受冗余传输带来的极致可靠性的同时，其安全性不会因为路径的增加而产生短板，且任何一条路径的密钥泄露都不会影响另一条路径的安全。

3. Annex P: DNS/ICMP安全 - 弥补互联网基础协议的“短板”

DNS（域名系统）和ICMP（互联网控制报文协议）是IP网络能够工作的最基础协议。然而，这些诞生于互联网早期的协议，在设计之初几乎没有考虑安全性。附录P（信息性）为5G网络如何缓解这些协议的内生安全风险，提供了重要的指导建议。

P.2 Security aspects of DNS It is recommended that the UE and DNS server(s) support DNS over (D)TLS as specified in RFC 7858 and RFC 8310.

DNS安全：推荐使用DoT/DoH

  • 风险：传统的DNS查询是明文的。这意味着，任何在网络路径上的窃听者（包括Wi-Fi提供商、ISP等），都可以知道你访问了哪些网站，这会严重泄露用户的上网隐私。此外，DNS查询也容易被篡改，导致DNS污染或“钓鱼”攻击。
  • 5G的建议：规范强烈推荐UE和网络侧的DNS服务器，支持DNS over TLS (DoT)或DNS over HTTPS (DoH)。这些技术将DNS查询封装在加密的TLS隧道中，从而实现了：
    • 机密性：防止第三方窃听你的域名解析请求。
    • 完整性：防止DNS响应被篡改。

P.3 Security aspects of ICMP To mitigate such attacks, it is recommended that the use of ICMP is restricted in the UE and the UPF…

ICMP安全：限制使用，严格过滤

  • 风险：ICMP（例如，我们常用的ping命令）可以被用于网络探测、DDoS放大攻击等恶意活动。
  • 5G的建议：
    • 默认禁用：UE和UPF应默认限制或禁止对ICMP报文的响应。
    • 严格过滤：在必须使用ICMP的场景下，应在UPF上部署严格的IP过滤器，只允许特定类型、特定大小的ICMP报文通过。

场景代入： 信息安全专家“白帽”坐在咖啡馆，试图分析周围用户的上网行为。

  • 对于未使用DoT/DoH的用户：他可以通过监听Wi-Fi流量，清晰地看到该用户正在访问www.example.com。
  • 对于使用了DoT/DoH的5G用户“安安”：安安的手机在进行DNS查询时，会与运营商提供的、支持DoT的DNS服务器建立一条TLS加密隧道。白帽即使捕获了流量，也只能看到一堆发往某个特定IP地址（DNS服务器地址）的、无法解密的TLS报文，完全无法得知安安正在访问哪个网站。

附录P的意义在于，它提醒我们，5G的安全不仅在于其自身的信令和数据保护，还包括对其承载的、更上层的互联网协议的安全增强。通过推广DoT/DoH和限制ICMP，5G网络能够为其用户提供一个更安全、更私密的互联网访问环境。

4. 总结

本章我们深入解读了附录M、N、P，看到了5G安全体系如何为三种截然不同的技术挑战，提供量身定制的解决方案。

  • IAB安全 (M)：通过“UE身份认证 + F1-IPsec隧道”的双层安全模型，为无线回传这种灵活的部署方式，提供了不亚于物理光纤的健壮安全性。
  • URLLC安全 (N)：通过“统一安全策略 + 独立密钥体系”的设计，确保了冗余传输的两条路径在安全等级上“齐头并进”，同时又在密钥上“相互隔离”，为极致可靠业务提供了双重安全保障。
  • DNS/ICMP安全 (P)：通过推荐使用DoT/DoH和限制ICMP，展现了5G作为下一代网络基础设施，致力于提升整体互联网环境安全的责任与担当。

这三个附录，如同三块精确的“拼图”，进一步完善了5G安全的宏伟蓝图，使其不仅在核心场景下坚不可摧，在各种新兴的、特殊的应用场景中，同样能游刃有余，提供与之相匹配的安全守护。

关系图谱