首页 › ims › VoNR IMS注册全链信令与IPSec鉴权拆解

VoNR IMS注册全链信令与IPSec鉴权拆解

在5G独立组网（SA）下，语音业务通过VoNR（Voice over NR）承载于IMS网络之上，而一切语音/视频/补充业务的前提是终端完成IMS注册。与EPS时代VoLTE一脉相承，IMS注册本质上是一次带鉴权的SIP信令交互：它在Gm接口上完成"网络对UE"与"UE对网络"的双向认证，并在此基础上协商出IPSec安全联盟（SA）保护后续所有SIP信令。本文依据3GPP TS 24.229、TS 33.203、TS 23.228，结合5G特有的P-CSCF发现机制，逐消息、逐IE拆解VoNR终端IMS注册的完整信令链路，并给出抓包识别与排错实战。

一、为什么IMS注册是VoNR的"第零步"

5G网络为VoNR专门建立一条IMS PDU会话（DNN通常为ims，5QI=5的SIP信令承载）。但PDU会话建立只解决了UE与UPF之间的IP连通性，UE要拨打/接听VoNR电话，还必须向IMS域登记自己的公有用户标识（IMPU）与默认公有身份，并协商出信令保护能力。IMS注册承担三件事：

鉴权：基于ISIM卡共享密钥K，通过IMS-AKA完成双向认证；
路由登记：把"哪个IMPU当前挂在哪个Contact（UE IP+端口）"登记到S-CSCF，使后续来话INVITE能找到UE；
安全协商：在UE与P-CSCF之间建立IPSec ESP SA，保护Gm接口所有SIP信令的机密性与完整性。

只有这三步全部成功，UE才能发起INVITE主叫、接收REGISTER状态事件、并被网络视为"IMS可达"。

二、5G下的P-CSCF发现机制

UE要发REGISTER，首先得知道P-CSCF的地址。5G提供了与4G不同的发现路径，主要依托IMS PDU会话建立过程：

flowchart TD
    A["UE: 发起IMS PDU会话建立<br/>(DNN=ims, ePCO请求P-CSCF)"] --> B["AMF→SMF<br/>Nsm PDUSession_CreateSMContext"]
    B --> C["SMF解析ePCO<br/>PDU Session Establishment Accept"]
    C --> D{"P-CSCF地址来源"}
    D -->|"本地配置/DNS解析"| E["SMF通过5G PCO/ePCO<br/>下发P-CSCF地址列表给UE"]
    D -->|"SMF直接分配"| E
    E --> F["UE: SIP承载建立<br/>向P-CSCF IP发起TCP/TLS"]

具体而言（详见TS 23.502 4.3.2、TS 24.501 PCO/ePCO、TS 23.228 5.2.1a）：

PCO/ePCO携带：UE在PDU会话建立请求的扩展协议配置选项（ePCO）中携带"P-CSCF地址请求"标识；SMF在PDU会话建立接受消息中通过ePCO返回一个或多个P-CSCF的FQDN或IPv4/IPv6地址。
DHCP方式：UE也可在获得IP后通过DHCPv4/DHCPv6的P-CSCF选项获取地址。
DNS解析：若只拿到FQDN，UE通过DNS解析得到P-CSCF IP。
LBO场景：漫游时可选本地P-CSCF（LBO_P-CSCF_Address）。

设计意图：把P-CSCF发现与IMS PDU会话绑定，使SMF这一会话管理者掌握"哪条PDU会话承载了IMS信令"，便于后续EPS Fallback、N3IWF、ATSSS等场景对语音会话做差异化调度。

三、IMS注册完整信令时序图

sequenceDiagram
    autonumber
    participant UE
    participant PCSCF as P-CSCF
    participant ICSCF as I-CSCF
    participant SCSCF as S-CSCF
    participant HSS as HSS/UDM

    Note over UE,PCSCF: 阶段0：未受保护REGISTER（触发鉴权与安全协商）
    UE->>PCSCF: REGISTER (IMPU,IMPI,Contact,+sip.instance,<br/>Security-Client, Require:sec-agree)
    PCSCF->>PCSCF: 记录路径，准备Security-Server参数
    PCSCF->>ICSCF: REGISTER (转发)
    ICSCF->>HSS: Cx-UAR (User-Authorization-Request)
    HSS-->>ICSCF: Cx-MAA (返回所需S-CSCF能力集)
    ICSCF->>SCSCF: REGISTER (按能力选择S-CSCF)
    SCSCF->>HSS: Cx-SAR (Server-Assignment-Request)
    HSS-->>SCSCF: Cx-SAA (用户签约+鉴权向量)
    Note over SCSCF: 取出一个IMS-AKA向量(RAND,AUTN,XRES,CK,IK)
    SCSCF-->>ICSCF: 401 Unauthorized<br/>(WWW-Authenticate: nonce=base64(RAND,AUTN,...), algorithm=AKAv1-MD5)
    ICSCF-->>PCSCF: 401 (+Security-Server: alg,SPI,port_pc,port_ps)
    PCSCF-->>UE: 401 Unauthorized (含Security-Server)

    Note over UE,PCSCF: 阶段1：UE计算鉴权响应并建立IPSec SA
    UE->>UE: ISIM验证AUTN(网络合法性),<br/>计算RES, 派生CK/IK
    UE->>UE: 建立两对IPSec ESP SA (用CK/IK)
    UE->>PCSCF: REGISTER (受保护端口,<br/>Authorization: response=RES,<br/>Security-Client: alg,SPI_uc,SPI_us,port_uc,port_us)
    PCSCF->>ICSCF: REGISTER (验证SA后转发)
    ICSCF->>SCSCF: REGISTER
    SCSCF->>SCSCF: 校验RES==XRES → 鉴权通过
    SCSCF->>HSS: Cx-SAR (注册登记)
    HSS-->>SCSCF: Cx-SAA
    SCSCF-->>PCSCF: 200 OK (Service-Route, P-Associated-URI)
    PCSCF-->>UE: 200 OK

    Note over UE,PCSCF: 阶段2：注册事件订阅
    UE->>PCSCF: SUBSCRIBE (Event:reg)
    PCSCF-->>UE: 200 OK
    UE-->>UE: 状态: Registered

四、逐消息与关键IE解析

4.1 初始REGISTER（未保护）

IE/头域	作用说明
`Request-URI`	家乡域域名（来自ISIM的IMPI域名部分），用于路由
`From`/`To`	公有标识IMPU（如`sip:[email protected]`）
`Authorization`	首次仅含`username=IMPI`，无`response`，声明鉴权算法
`Security-Client`	UE支持的机制（`ipsec-3gpp`）、加密/完整性算法、`SPI_C`/`SPI_S`、`port_uc`/`port_us`
`Require: sec-agree`	强制对端先做安全协商（RFC 3329）
`Contact`	UE的IP+端口，含`+sip.instance`（GRUU基础）
`P-Access-Network-Info`	UE填接入类型（如`3GPP-NR-TDD`）；P-CSCF可改写为`utran-cell-id-3gpp`

设计意图：第一条REGISTER明文发送但必须携带Security-Client与Require:sec-agree，让P-CSCF在回复401时一并下发Security-Server，使鉴权挑战与安全协商"一次往返"完成，避免额外的密钥协商握手。

4.2 I-CSCF查询与S-CSCF选择（Cx接口）

I-CSCF收到REGISTER后，并不直接鉴权，而是通过Diameter Cx接口（TS 29.228/29.229）问HSS：

UAR（User-Authorization-Request）→ MAA：确认用户是否被授权注册，返回所需S-CSCF能力集；
I-CSCF依据能力集选择一台S-CSCF（或HSS指定）转发REGISTER；
SAR（Server-Assignment-Request）→ SAA：S-CSCF向HSS登记"我已成为该用户的归属S-CSCF"，并拉取用户签约数据与鉴权向量组（AV）。

每个AV包含(RAND, AUTN, XRES, CK, IK)。这是IMS-AKA的核心五元组，与5G主认证AKA同源思想：HSS与ISIM共享密钥K，网络用RAND挑战，UE回RES。

4.3 401挑战消息

S-CSCF取出一个AV，把RAND与AUTN封装进nonce，通过401 Unauthorized回送。P-CSCF在转发前注入自身的安全参数：

SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="ims.mnc.mcc.3gppnetwork.org",
   nonce="base64(RAND||AUTN||server-specific||MAC)",
   algorithm=AKAv1-MD5, qop="auth", opaque="..."
Security-Server: ipsec-3gpp;
   alg=hmac-sha-1-96/hmac-md5-96;
   ealg=aes-cbc/null;
   spi-c=0x12345678; spi-s=0x87654321;
   port_pc=5100; port_ps=6100

WWW-Authenticate/Security-Server参数	含义
`nonce`	携带RAND/AUTN的挑战值（RFC 3310 AKA Digest）
`algorithm=AKAv1-MD5`	指示用AKA派生Digest参数
`spi-c` / `spi-s`	P-CSCF选择的SPI，用于索引两套ESP SA
`port_pc` / `port_ps`	P-CSCF的客户端口/服务器端口（受保护端口）
`alg` / `ealg`	完整性算法/加密算法

关键点：P-CSCF会在401中修改后续SIP的"受保护端口"，因此UE建立SA后必须改用新的port_uc→port_ps收发信令，这就是抓包时常常看到的"注册后端口突变"现象。

4.4 UE侧IMS-AKA计算与密钥派生

UE（实际是ISIM）执行与主认证类似的运算：

flowchart TD
    K["ISIM共享密钥 K"] --> AKA["AKA算法"]
    RAND["接收RAND"] --> AKA
    AUTN["接收AUTN"] --> AUTNCHK{验证AUTN<br/>网络是否合法}
    AUTN --> AUTNCHK
    AKA --> RES["RES (鉴权响应)"]
    AKA --> CK["CK (加密密钥)"]
    AKA --> IK["IK (完整性密钥)"]
    CK --> KDF["IPSec SA 密钥派生"]
    IK --> KDF
    KDF --> SA1["SA: UE→P-CSCF (SPI_C, 加密+完整性)"]
    KDF --> SA2["SA: P-CSCF→UE (SPI_S, 加密+完整性)"]

ISIM验证AUTN中的MAC与序号SQN，确认"网络是真网络"（UE对网络鉴权），随后用共享K计算RES供回送，CK/IK用于在UE与P-CSCF间直接静态配置两套ESP SA（无需IKE握手，密钥来自AKA，符合TS 33.203）。其中IK用于ESP完整性、CK用于ESP加密（经典profile；新profile支持HMAC-SHA-256、AES-GCM等增强算法）。

4.5 受保护REGISTER与200 OK

UE建立SA后，沿受保护端口重发REGISTER：

Authorization: response=<计算出的Digest，内含RES>；
仍带Security-Client（更新后的SPI/端口）；
经IPSec ESP加密+完整性保护送达P-CSCF。

S-CSCF校验RES==XRES，通过后向HSS登记注册（SAR），并回送200 OK，关键头域包括：

Service-Route：UE后续发INVITE时必须携带的路由信息（service-route至S-CSCF）；
P-Associated-URI：该用户所有已注册的IMPU列表；
Path：P-CSCF登记的反向路由（用于来话INVITE回到P-CSCF）。

随后UE通常SUBSCRIBE自身reg事件包（RFC 3680），订阅注册状态变化（如网络侧强制去注册、re-registration）。至此UE进入Registered状态，可发起/接收VoNR呼叫。

五、注册状态转换图

stateDiagram-v2
    [*] --> NotRegistered
    NotRegistered --> Registering: 发送未保护REGISTER
    Registering --> Registering: 收到401,建立SA,重发受保护REGISTER
    Registering --> Registered: 收到200 OK
    Registered --> ReRegistering: 注册定时器到期/网络要求re-auth
    ReRegistering --> Registered: 200 OK
    Registered --> NotRegistered: 网络去注册/超时/SA失效
    Registering --> NotRegistered: 多次失败

六、IPSec SA建立细节（Gm接口安全）

IMS的IPSec采用ESP传输模式（transport mode），由ipsec-3gpp机制标识，与一般VPN的隧道模式不同。两对单向SA分别承载UE↔P-CSCF两个方向的SIP信令：

项目	UE→P-CSCF SA	P-CSCF→UE SA
SPI来源	UE选择（Security-Client的`SPI_C`）	P-CSCF选择（Security-Server的`spi-c`/`spi-s`）
密钥	由CK/IK派生	由CK/IK派生
源/目的端口	`port_uc` → `port_ps`	`port_pc` → `port_us`
加密算法	e.g. AES-CBC（null可选）	同左
完整性算法	e.g. HMAC-SHA-1-96	同左

常见混淆：port_uc（UE客户端口）是UE发请求时用的源端口；port_us（UE服务器口）是UE收请求时用的目的端口。抓包中"注册成功后所有SIP换到5100/6100之类的新端口"正是SA生效的直接证据。

七、抓包识别要点

Gm接口无GTP封装：IMS SIP在IMS PDU会话上以纯TCP/UDP承载，Wireshark按SIP解码即可，不要在N3 GTP层找。
IPSec ESP夹层：注册成功后，UE↔P-CSCF间的SIP会被ESP（协议号50）封装，Wireshark需配置SA（输入CK/IK/算法）才能解出内层SIP——这是排查VoNR注册"看不到REGISTER内容"的高频原因。
识别三段式：明文REGISTER → 401（含Security-Server）→ ESP保护的REGISTER，是健康IMS注册的标志。
5G侧关联：先有DNN=ims的PDU会话建立（5QI=5），ePCO里能看到P-CSCF请求；再看SIP注册，二者时序必须衔接。

八、常见故障点与排错

401循环/认证失败：检查ISIM是否正确写入、K是否与HSS一致、AUTN序号SQN失步（HSS侧需重新同步）。表现为S-CSCF持续校验RES失败。
SA建立后REGISTER丢包：Security-Server/Security-Client的端口、SPI、算法协商不一致，UE发往port_ps但P-CSCF未在该端口监听；或ESP算法（如SHA-256增强算法）两侧不支持。
注册成功但来话不通：Service-Route/Path未正确登记，或P-CSCF未把Path写入S-CSCF，导致入呼INVITE找不到UE——查P-CSCF的Path处理。
5G侧问题：IMS PDU会话未建立或被QoS flow抢占，ePCO未返回P-CSCF地址，UE无法发出REGISTER。
重注册SA更换：每次re-registration会重新协商SA，旧SA过期前端口/SPI切换不当会导致短暂信令中断。

十、IPSec方案与TLS方案对比

对比项	ipsec-3gpp（ESP传输模式）	TLS
适用范围	默认蜂窝接入IMS	IPSec不可用时/特定接入
密钥来源	IMS-AKA的CK/IK	TLS握手（证书+预共享）
保护对象	IP层所有SIP	TCP之上的SIP
实现复杂度	需UE内核ESP支持，端口管理复杂	仅应用层，实现简单
端口特征	受保护端口突变	5060/5061，端口稳定

常见问题

Q1：IMS-AKA与5G主认证AKA是什么关系？ A：两者机制同源（共享K、RAND/AUTN挑战、派生密钥），但作用域不同：5G主认证（TS 33.501）保护的是UE与5G核心网之间的NAS/RRC，派生K_amf等接入层密钥；IMS-AKA（TS 33.203）是在IMS域独立的一次鉴权，密钥K来自ISIM（可与USIM的5G主密钥相同或不同），派生的CK/IK只用于UE与P-CSCF间的IPSec SA。可以说5G主认证让UE进入5G网络，IMS-AKA让UE进入IMS域，二者前后衔接。

Q2：为什么注册成功后SIP消息会"换端口"？ A：因为IPSec SA建立后，UE与P-CSCF约定了受保护的port_uc/port_us/port_pc/port_ps。后续所有SIP（INVITE、SUBSCRIBE等）都在ESP隧道内经这些端口收发，与注册前的明文端口不同。这是安全机制生效的正常表现，不是异常。

Q3：抓包看到401但没有Security-Server，是什么问题？ A：说明安全协商未启动。通常因为UE首条REGISTER未带Require:sec-agree或Security-Client，或网络只配置了TLS而非IPSec。若终端依赖IPSec而网络无此响应，将无法建立SA，注册失败。

Q4：re-registration时需要重新鉴权吗？ A：不一定。周期性重注册通常复用既有SA，但当HSS侧鉴权向量用尽或网络要求re-auth时，会再次下发401触发完整IMS-AKA。re-auth时SA会刷新（新CK/IK派生新SA），需平滑切换以避免信令中断。

Q5：VoNR的IMS注册和VoLTE有本质区别吗？ A：注册信令流程基本一致（仍是REGISTER/401/REGISTER/200OK + IPSec SA）。区别主要在底层承载：VoLTE用EPS的IMS PDN承载+PCO发现P-CSCF；VoNR用5G IMS PDU会话+ePCO发现P-CSCF，且可与5G QoS（5QI=5信令、5QI=1语音）深度联动。上层SIP/IMS-AKA机制是复用的。

参考来源

3GPP TS 24.229 V18.x — IP Multimedia Call Control Protocol based on SIP and SDP — Section 5.1.1.2 初始注册、5.1.1.3 重注册、P-CSCF发现与安全协商
3GPP TS 33.203 V18.x — Access security for IP-based services — IMS-AKA、IPSec ESP SA（SPI/端口/算法）、Sec-Mechanism ipsec-3gpp
3GPP TS 23.228 V18.x — IMS architecture (Stage 2) — 注册架构、Cx接口交互、S-CSCF选择
ShareTechnote — IMS REGISTER with Authentication and IPSec — 注册鉴权与IPSec信令实例解读
RFC 3310 — HTTP Digest using AKA / RFC 3329 — Security Mechanism Agreement for SIP — AKA Digest与sec-agree头域定义

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入