51学通信

深度解析 3GPP TS 33.210：第5章 (Part 1) IPsec与IKEv2的“筑城秘笈”

20分钟阅读

好的，我们继续进行系列的下一篇深度解读。

深度解析 3GPP TS 33.210：第5章 (Part 1) IPsec与IKEv2的“筑城秘笈”

本文技术原理深度参考了3GPP TS 33.210 V18.1.0 (2024-06) Release 18规范中，关于“第5章 Key management and distribution architecture for NDS/IP”的核心章节，旨在为读者提供一份关于如何在5G核心网中，精确、标准化地构建和管理IPsec安全隧道的“施工手册”。

引言：从蓝图到“钢筋混凝土”

“陈工，通过学习前四章，我已经理解了建造5G‘隐形长城’的宏伟蓝图，”年轻的工程师小李在一次技术研讨会上说，“我们要在运营商网络边界部署‘边防要塞’SEG，并在它们之间建立安全的‘地下隧道’。但蓝图终究是蓝图，我们到底该用什么牌号的‘钢筋’？什么标号的‘混凝土’？又该如何进行‘施工’，才能确保这条隧道坚不可摧？”

资深架构师陈默赞许地看着他：“小李，你问到了最关键的工程问题。一份优秀的建筑设计，不仅要有宏大的构想，更要有精确到每一根钢筋直径的‘施工详图’。TS 33.210的第5章，就是我们这座‘隐形长城’的终极施工秘笈。”

“在这一章里，3GPP的专家们化身为最严谨的‘结构工程师’和‘材料学家’。他们从IETF定义的IPsec和IKEv2这两大‘原材料库’中，精挑细选，为我们规定了必须使用的‘高强度钢筋’（加密算法）、‘特种混凝土’（认证算法），并给出了一套标准化的‘施工流程’（协议交互剖析）。这套‘秘笈’的核心，就是Profiling（裁剪与定制）——在开放标准之上，做最严格的减法和最关键的加法。”

“今天，我们就来打开这份‘秘笈’，学习如何将抽象的安全概念，转化为一行行具体的、可执行的配置参数。我们将看到，3GPP是如何通过对算法、模式和流程的精雕细琢，来确保全球所有运营商的‘边防要塞’都能讲同一种‘安全语言’，建造出同一种‘金刚不坏之身’的。”

1. 隧道的“通行规则”：Security Associations (SAs) (5.2)

在IPsec的世界里，一切安全服务都围绕着SA (Security Association, 安全关联)展开。一个SA，可以理解为两个网络实体之间，为特定数据流建立的一条单向的、逻辑上的安全通道。它是一份详细的“通行规则合同”。

5.2.0 General

…The concept of a Security Association is central to IPsec and IKEv2.

IPsec Security associations are uniquely defined by the following parameters:

  • A Security Parameter Index (SPI);
  • An IP Destination Address…
  • A security protocol identifier (this will always be the ESP protocol in NDS/IP).

1.1 深度解析：SA的三要素

陈默解释道：“一个SA就像是一把通往加密世界的‘钥匙’。网络设备在收到一个加密包时，需要知道该用哪把钥匙去解密。而SA的三要素，就是这把‘钥匙’的唯一身份标识。”

  • SPI (安全参数索引): 一个32位的数字，是SA最主要的标识符。它被封装在ESP头中。当SEG收到一个ESP包时，它会查看SPI值，然后去自己的“钥匙库”（SAD）中寻找对应的“钥匙”（SA）。

  • 目的IP地址: 指的是这个安全隧道的终点，即对端SEG的IP地址。

  • 安全协议: 在NDS/IP的场景下，这个值永远是ESP。

这三者共同构成了一个SA的唯一索引，确保了SEG能够从成千上万条隧道中，准确无误地为每一个数据包找到正确的处理规则。

1.2 “规则库”与“钥匙库”：SPD与SAD

为了管理这些复杂的“通行规则”，每个SEG内部都维护着两个核心的数据库：

5.2.1 Security Policy Database (SPD)

The SPD is a policy instrument to decide which security services are to be offered and in what fashion.

SPD（安全策略数据库） 是SEG的“决策大脑”。它包含了一系列的策略规则，告诉SEG在处理一个普通IP包时，应该采取什么行动。

  • PROTECT (保护): 这个包需要被IPsec保护。SPD会指明应该使用哪个SA。如果还没有合适的SA，就会触发IKEv2去协商建立一个新的SA。

  • BYPASS (放行): 这个包是安全的，无需IPsec保护，可以直接放行（例如，一些网络管理流量）。

  • DISCARD (丢弃): 这个包是非法的或不符合策略的，应该被直接丢弃。

5.2.2 Security Association Database (SAD)

The SAD contains parameters that are associated with the active security associations.

SAD（安全关联数据库） 则是SEG的“钥匙库”。它存储了所有当前激活的SA的详细信息，包括：

  • 加密算法与密钥。

  • 完整性校验算法与密钥。

  • 序列号计数器（用于抗重放）。

  • SA的生命周期。

工作流程: 当一个数据包从内部网络到达SEG时，SEG首先查询SPD。SPD根据包的源/目的IP、端口等信息，匹配到一条策略。如果策略是PROTECT，SPD会提供一个指向SAD中某个SA的指针。SEG再根据SAD中的具体参数，对数据包进行加密和封装，然后发送出去。

2. “钢筋混凝土”的选材标准：Profiling of IPsec (5.3)

第5.3节是33.210的第一个技术核心，它详细规定了IPsec ESP协议的“材料”和“施工”标准。

2.1 协议与模式的选择

5.3.1 Support of ESP: When NDS/IP is applied, the ESP security protocol shall be used.

5.3.2 Support of tunnel mode: …For NDS/IP inter-domain communication, security gateways shall be used and consequently only tunnel mode … is applicable for this case.

  • 深度解析:

    规范做出了两个强制性的选择：

    1. 必须使用ESP: 放弃了只提供认证不提供加密的AH协议。

    2. 域间必须使用隧道模式: 隧道模式将整个原始IP包（包括原始IP头）都进行了封装和保护，能更好地隐藏内部网络拓扑，是跨运营商互联的唯一选择。

2.2 算法的“强制菜单”与“推荐菜单”

5.3.3 Support of ESP encryption transforms: Only the ESP encryption algorithms … mentioned in RFC 8221 shall be used. Algorithms marked with “MUST” shall be supported.

5.3.4 Support of ESP authentication transforms: …Algorithms marked with “MUST” shall be supported. AES-GMAC with AES-128 shall be supported.

  • 深度解析:

    规范直接引用了IETF的权威文档RFC 8221（现已被更新的版本替代，但原理不变），为加密和认证算法开出了一份“菜单”。

    • 强制支持 (MUST): 菜单上的这些算法，是所有厂商的SEG设备都必须实现的。这保证了即使两家运营商使用不同厂商的设备，也总能找到一个共同支持的、足够安全的算法来建立连接。例如，AES-128-GCM (带128位密钥的AES-GCM认证加密算法) 就是一个典型的MUST项。

    • 推荐使用 (SHOULD): 菜单上还有一些更强壮的算法（如AES-256-GCM），规范推荐使用，以获得更高的安全性。

    • 禁止使用: 规范明确禁止了NULL认证算法（除非使用了认证加密算法），杜绝了“裸奔”的数据传输。

2.3 构造IV的“军规”

5.3.5 Requirements on the construction of the IV

…The IV shall be chosen at random, and shall be unpredictable… It is explicitly not allowed to construct the IV from the encrypted data of the preceding encryption process.

  • 深度解析:

    IV (Initialization Vector, 初始化向量) 是加密过程中的一个重要参数。如果IV是可预测的，即使加密算法本身很强大，也可能遭受攻击。规范在这里以军令的口吻，强调了IV的随机性和不可预测性，并明确禁止了一些过去曾被使用但存在安全隐患的IV构造方法。这体现了3GPP对密码学细节的严谨态度。

3. “密钥协商”的舞蹈编排：Profiling of IKEv2 (5.4)

IKEv2是为IPsec SA自动、安全地协商密钥的“外交官”。第5.4节则为这位“外交官”的谈判流程和语言，制定了严格的“外交礼仪”。

5.4.2 Profiling of IKEv2

The Internet Key Exchange protocol IKEv2 shall be supported for negotiation of IPsec SAs. The following additional requirements apply.

3.1 谈判的各个阶段

IKEv2的协商过程主要分为两个阶段：

  1. IKE_SA_INIT Exchange: 第一阶段，双方交换基本信息，进行Diffie-Hellman密钥交换，生成一个基础的、加密的通道（IKE SA）。

  2. IKE_AUTH Exchange: 第二阶段，在这个加密通道内，双方进行身份认证，并协商创建第一个具体的IPsec隧道（Child SA）。

后续还可以通过CREATE_CHILD_SA exchange创建更多的IPsec隧道。

3.2 算法的“强制舞步”

与IPsec类似，规范为IKEv2协商的每个环节，都规定了必须支持的算法。

For IKE_SA_INIT exchange:

Following algorithms shall be supported:

  • Confidentiality: AES-GCM with a 16 octet ICV with 128-bit key length;
  • Pseudo-random function: PRF_HMAC_SHA2_256;
  • Diffie-Hellman group 19 (256-bit random ECP group);

  • 深度解析:

    这份列表，就是IKEv2第一阶段谈判时，双方必须都会跳的“华尔兹舞步”。它规定了加密、伪随机函数（用于生成密钥材料）和DH密钥交换组。通过强制要求支持一个共同的、安全的算法集，确保了任何两个遵循规范的SEG都能成功地完成第一阶段的“开场舞”。

3.3 身份的核验与维护

For IKE_AUTH exchange:

  • Authentication method 2 - Shared Key Message Integrity Code shall be supported;
  • Re-keying of IPsec SAs and IKE SAs shall be supported as specified in RFC 7296.

  • 深度解析:

    • 认证方法: 规范要求支持基于预共享密钥的认证方式（尽管证书方式在实践中更常用，并在其他规范中有补充）。

    • 重协商密钥 (Re-keying): 为了防止密钥因长时间使用而泄露，规范强制要求支持IKE SA和IPsec SA的周期性重协商。这意味着“地下隧道”的“门锁”会定期更换。

    • 重认证 (Reauthentication): 规范还要求支持更彻底的身份重认证，即不仅更换密钥，还要重新验证一次对方的身份。这就像是“边防卫兵”定期更换口令，并重新查验一次对方的证件。

结论：标准化是安全的基石

通过对第5章的深入学习，小李终于明白了3GPP是如何将抽象的安全需求，转化为具体的、可互操作的工程实践的。

“陈工，我懂了。第5章的核心就是**‘求同存异，底线强制’。”小林总结道，“它通过Profiling的方式，从庞杂的IETF标准中，为我们划定了一个安全的、可互通的‘最小集’**。所有厂商都必须在这个‘最小集’的框架内进行开发，这就保证了我们无论采购谁家的设备，都能把它无缝地对接到我们的‘隐形长城’体系中。”

  1. 统一的“蓝图语言” (SA, SPD, SAD): 定义了IPsec工作的基本模型和组件。

  2. 统一的“建筑材料” (IPsec Profiling): 规定了必须使用的协议、模式和密码学算法，确保了“墙体”的坚固性。

  3. 统一的“施工与维护流程” (IKEv2 Profiling): 规定了密钥协商、更新和重认证的标准化流程，确保了“长城”能够被安全、动态地管理和维护。

正是这套“筑城秘笈”，确保了5G核心网这座全球化的“微服务之城”，其地下的信令脉络，能够抵御来自开放IP世界的种种威胁，坚如磐石。

FAQ 环节

Q1：为什么规范强制域间使用隧道模式，而不是传输模式？

A1：主要出于安全和网络拓扑隐藏的考虑。隧道模式会对整个原始IP包（包括原始的、内部的IP地址）进行加密和封装。这意味着，当数据包在运营商之间的公共互联网上传输时，中间的路由器只能看到外部的、SEG的IP地址，而无法知道数据包真正的源和目的NE（如某个具体的AMF或SMF）的内部地址。这极大地增强了网络拓扑的保密性，缩小了攻击面。而传输模式只保护IP载荷，会暴露内部的IP地址。

Q2：IKEv2协商过程本身是安全的吗？

A2：是的。IKEv2的设计考虑了多种攻击场景。其IKE_SA_INIT阶段使用Diffie-Hellman (DH) 密钥交换算法，使得通信双方可以在一个不安全的信道上，协商出一个共享的会话密钥，而窃听者即使截获了所有的交换信息，也无法计算出这个密钥。后续的所有交互（包括身份认证和IPsec SA的协商）都在这个由DH密钥保护的加密通道（IKE SA）内进行，从而保证了整个过程的安全性。

Q3：什么是完美前向保密 (PFS, Perfect Forward Secrecy)？规范中是如何体现的？

A3：PFS是一种重要的安全特性，它确保即使一个长期的密钥（如SEG的私钥）在未来某个时刻泄露，也不会影响到过去所有会话的机密性。规范在5.4.2节的CREATE_CHILD_SA exchange中体现了这一点：“A DH key exchange should be used…and the session keys should be changed frequently.” 这意味着，在创建新的IPsec SA（Child SA）时，推荐重新进行一次DH交换，从而为每个IPsec SA都生成一个独立的、与主IKE SA密钥无关的会话密钥。这样，即使主密钥泄露，也只能破解当前的IKE SA，而无法解密过去那些已经使用独立会话密钥加密的数据。

Q4：为什么规范中很多算法都推荐使用带GCM的模式，如AES-GCM？

A4：GCM (Galois/Counter Mode) 是一种认证加密（AEAD - Authenticated Encryption with Associated Data）模式。传统的IPsec需要分别使用一种加密算法（如AES-CBC）来保证保密性，和一种认证算法（如HMAC-SHA256）来保证完整性。而AES-GCM一次操作就能同时提供保密性和完整性保护，效率更高，且在实现上更不容易出错。它已经成为现代密码学的首选工作模式，因此3GPP在规范中大力推荐和强制要求支持它。

Q5：这些复杂的IPsec和IKEv2配置，都需要网络工程师手动完成吗？

A5：在初始部署和策略定义阶段，是的，网络工程师需要根据运营商的安全策略和漫游协议，在SEG上配置好SPD策略以及IKEv2的认证凭据（如预共享密钥或证书）。但是，一旦配置完成，SA的建立、密钥的协商、更新和删除，都是由IKEv2协议自动完成的，无需人工干预。这正是IKEv2作为“动态密钥管理协议”的巨大优势，它将网络工程师从繁琐、易错的手动密钥管理工作中解放了出来。

关系图谱