CN1893391A - 一种支持网络层安全穿越网络地址转换的方法 - Google Patents

Abstract

本发明公开了一种支持网络层安全穿越网络地址转换的方法，应用于包括应用功能实体(AF)的分组业务网络中，当AF收到用户终端(UE)首次发送的注册请求后，为该UE指定用于UDP封装的端口号信息，将该端口号信息作为SA参数保存，并将该端口号信息发送给UE，UE向AF发送的经过IPSec保护后的IP报文进行UDP封装处理，AF利用UDP封装端口信息的目的端口号对UDP封装的IPSec报文进行识别，同时采用收到的报文的源端口号更新自身保存的用于UDP封装端口信息的源端口号；当AF有向UE发送的IP报文时，AF利用自身保存的用于UDP封装的端口信息对经过IPSec保护的IP报文进行UDP封装，UE采用自身保存的用于UDP封装的端口信息识别UDP封装的IPSec报文。本发明对现有IMS AKA的改动小，容易实现。

Description

一种支持网络层安全穿越网络地址转换的方法

技术领域

本发明涉及网络层安全技术领域，特别是一种支持网络层安全穿越地址转换的方法。

背景技术

在第三代移动通信系统(3GPP)IP多媒体子系统(IMS)R5/R6/R7的安全规范中，IMS认证的密钥协商(AKA)用于实现3GPP接入域中的网络与终端的双向认证，以及终端和网络之间安全密钥的分发、算法协商及其它安全联盟参数的协商。在IMS AKA的基础上，IMS网络接入域安全基于IPSec安全载荷封装(ESP)协议对终端和代理呼叫会话控制功能(P-CSCF)之间的信令流进行完整性和机密性保护。在固定下一代(NGN)网络中，会话控制层同样基于3GPP的IMS网络架构，IMS成为一个与接入网络无关的独立的网络会话控制层，IMS网络在固定NGN网络中的安全规范同样继承了3GPP中的定义，并在其基础上发展和完善，以解决一些固定网络中特有的问题。

在固定NGN网络中，由于IPv4地址的缺乏，网络中部署了大量的NAT设备，而IPSec协议穿越NAT存在问题，即由于经过NAT设备更改报文头中的IP地址/端口号，有可能导致接收端在收到IPSec报文进行安全检查失败而将报文丢弃，为此IETF针对IPSec穿越NAT问题制定了3个RFC：一个是RFC3715(IPsec-Network Address Translation(NAT)CompatibilityRequirements)，一个是RFC3947(Negotiation of NAT-Traversal in the IKE)，另一个是RFC3948(UDP Encapsulation of IPsec ESP Packets)。

上述RFC的基本思想是：IPSec协议通过UDP封装来完成NAT穿越，但其解决方案是针对IPSec的密钥交换协议(IKE)而制定完善的，而在IMS网络接入安全中，密钥协商协议是通过IMS AKA来完成的，因此有必要针对IMS AKA实现对IPSec穿越NAT的支持。

IMS网络安全模型将安全划分为接入域和网络域，下面介绍一下IMS网络接入域安全的核心-接入域AKA流程。图1所示为IMS AKA流程，由于本发明中主要关注UE和P-CSCF之间的协商，P-CSCF及网络侧其它实体I/S-CSCF、HSS之间的交互在本方案中不受影响，因此下面重点描述一下步骤101、110、111和119，其它步骤简单描述。

参考图1，AKA流程包括以下步骤：

步骤101：用户终端(User Equipment，UE)向代理呼叫会话控制功能实体(Proxy-Call Session Control Function，P-CSCF)发送注册报文Register。

步骤102：P-CSCF作为会话发起协议(Session Initial Protocol，SIP)代理服务器，将UE的注册报文Register转发给询问呼叫会话控制功能实体(Interrogaing-Call Session Control Function，I-CSCF)。

步骤103：I-CSCF与归属用户服务器(Home Subscribe Server，HSS)之间通过Cx-Selection-Info消息选择相应的服务呼叫会话控制功能实体(Service-Call Session Control Function，S-CSCF)，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。

步骤104：I-CSCF将UE的注册报文Register转发给步骤103中所确定S-CSCF。

步骤105：S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。

步骤106：S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。

步骤107：HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权向量，发送给S-CSCF。

步骤108：S-CSCF根据在步骤107中获得的鉴权向量以及UE的注册报文，判断出该用户需要进行鉴权，然后向I-CSCF发送4xx Auth_Challenge消息，表示需要进行鉴权，并携带有与鉴权相关的信息。其中4xx表示一类错误，xx代表从00～99的一个数字。

步骤109：I-CSCF将所述4xx Auth_Challenge消息发送给P-CSCF。

步骤110：P-CSCF将所述4xx Auth_Challenge消息发送给UE。

步骤111：UE接收到所述4xx Auth_Challenge消息后，重新向P-CSCF发送新的注册报文Register，并且该Register携带有认证参数。

步骤112：P-CSCF将UE的注册报文Register发送给I-CSCF。

步骤113：I-CSCF接收到所述注册报文Register后，与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询用户注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该用户注册报文的S-CSCF。

步骤114：I-CSCF将注册报文Register转发给步骤113确定的S-CSCF。

步骤115：S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF。

步骤116：S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。

步骤117：S-CSCF根据所述用户的签约数据信息和UE注册报文Register中的认证参数，进行鉴权。如果鉴权成功，S-CSCF向I-CSCF发送2xxAuth_OK消息，表示注册成功，其中2xx表示成功相应的消息，xx为00～99的一个数字。如果鉴权失败，则S-CSCF向I-CSCF发送表示鉴权失败的消息。

步骤118：如果鉴权成功，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。如果鉴权失败，则I-CSCF将上述表示鉴权失败的消息发送给P-CSCF。

步骤119：如果鉴权失败，P-CSCF将上述2xx Auth_OK消息发送给UE。如果鉴权失败，则P-CSCF将上述表示鉴权失败的消息发送给UE。

另外，参见图2所示，目前还有一种实现方案，在该方案中，SIP Server相当于上述P-CSCF，具体步骤如下：SIP Client A通过NAT gatway向SIPServer A发送注册请求报文，其中含有SIP Client A的域名。SIP Server A收到客户端的第一个注册请求报文后，比较该报文中报文头的源IP地址和该报文中报文负载中携带的Contact地址是否一致，如果两者不一致，则判断出客户端和SIP Server之间存在NAT设备，SIP Server A向HSS-A发送Forward sip client-A@server-A；HSS收到后，产生AKA quintuplets，并向SIPServer A返回CK、IK、RAND、AUTN，SIP Server A向SIP Client A返回RAND、AUTN；然后，客户端向SIP Server发起一个UDP封装的Ping报文，用于在中间的NAT设备上创建UDP端口的映射，同时SIP Server也需要保存到达的Ping报文的UDP端口号，后续客户端和SIP Server之间将通过上述UDP端口号对IPSec ESP报文进行UDP封装后穿越NAT设备而进行安全的通信。

在上述方案具有如下缺点：

(1)在步骤7和9中，报文没有经过IPSec ESP保护，和现有的IMS AKA流程不符，同时存在一定的安全隐患，在步骤7中，SIP Server需要通过对终端发过来的报文进行认证来判断在步骤1和6中发送的报文中的安全参数是否被篡改过，如果被篡改，则整个IMS AKA过程将终止，但现在由于步骤7没有经过保护，SIP Server无法做出判断。

(2)由于报文9没有进行保护，则报文可能被篡改，即终端收到的认证结果信息可能是错误的。

(3)上述流程中通过增加一个UDP封装的Ping报文来实现在NAT设备上UDP端口号的映射，由于Ping是基于ICMP的一个纯粹IP层的功能实现，其与应用层没有关系，此时需要在IP层和应用层之间的接口，而该接口不符合常规。

(4)此外，SIP Server A随时都有可能收到从其它设备或终端发过来的基于ICMP的Ping报文，SIP Server，相当于P-CSCF，无法判断哪一个Ping报文是用于实现UDP封装功能的，或判断出错，即导致将收到的UDP端口号和终端关联错误，使得SIP Server既无法向终端发送UDP封装的IPSecESP报文，也无法用来鉴别该一个UDP报文是UDP封装的IPSec ESP报文。

发明内容

有鉴于此，本发明的目的是提供一种IPsec穿越NAT的方法，使其能支持IPSec ESP协议穿越NAT设备。

本发明提供的一种IPsec穿越NAT的方法是这样实现的：

A.当AF实体收到用户终端发送的用户注册请求的IP报文后，比较该IP报文头中的源IP地址和报文负载中携带的用户的IP地址是否一致，如果不一致，则确定用户终端与AF中间有NAT设备，并向核心网发送用户注册请求的IP报文；

B.当AF实体收到核心网针对该用户终端返回的鉴权响应后，为该用户终端指定用于用户数据包协议UDP封装的端口信息，并将向该用户终端发送的鉴权响应的IP报文的安全联盟设置参数Security-setup头域中增加所述用于UDP封装的端口信息，所述端口信息包括源端口号和目的端口号；

C.用户终端收到AF实体发送的鉴权响应的IP报文后，判断该IP报文的Security-setup头域中的用于UDP封装的端口号信息是否有效，如果有效，则执行步骤D；

D.用户终端将向所述AF实体发送的重注册请求的IP报文进行IPSec ESP保护，并利用收到AF发送的IP报文的Security-setup头域中所述用于UDP封装端口信息对该IP报文进行UDP封装后发送给AF，且用户终端将AF实体发送的鉴权响应的IP报文中所述用于UDP封装的端口信息保存；

E.AF收到用户终端发送的重注册请求的IP报文后，将该IP报文中的目的端口号和为该用户终端指定的用于UDP封装端口信息中的目的端口号进行比较，如果一致，将该IP报文按照UDP解包后交给IPSec协议栈处理，并且保存该IP报文中的源端口号，更新自身保存的用户UDP封装端口信息中的源端口号；

F.当AF实体收到核心网针对该用户终端返回的鉴权响应后，AF实体将向用户终端发送的鉴权响应的IP报文进行IPSec ESP保护并利用所述更新过的用于UDP封装端口信息对该IP报文进行UDP封装后发送给该用户终端；

G.该用户终端收到AF返回的鉴权响应的IP报文后，将该IP报文的地址/端口与自身保存的用于UDP封装的端口信息进行比较，判断出该报文是否是UDP封装的IPSec报文，如果是，则将报文经过UDP解包后，交给IPSec协议栈处理。

步骤G中判断出该报文是否是UDP封装的IPSec报文步骤包括：

将该IP报文中的源端号与自身保存的用于UDP封装的目的端口号进行比较，如果一致，则该报文是UDP封装的IPSec报文，否则，该报文不是UDP封装的IPSec报文。

步骤G中判断出该报文是否是UDP封装的IPSec报文步骤包括：

步骤G中在将该IP报文中的源端号与自身保存的用于UDP封装的目的端口号进行比较，以及将该IP报文中目的端口号和自身保存的用于UDP封装的源端口号进行比较，如果都一致，则该报文是UDP封装的IPSec报文，否则，该报文不是UDP封装的IPSec报文。

步骤G中判断出该报文是否是UDP封装的IPSec报文步骤包括：将该IP报文中目的端口号和自身保存的用于UDP封装的源端口号进行比较，如果一致，则该报文是UDP封装的IPSec报文，否则，该报文不是UDP封装的IPSec报文。5、根据权利要求1所述的方法，其特征在于，当用户终端有向AF发送的IP报文时，用户终端将向所述AF实体发送的IP报文进行IPSec ESP保护后，利用收到的AF发送的IP报文的Security-setup头域中自身保存的用于UDP封装的端口信息对该IP报文进行UDP封装后发送给AF；

AF收到用户终端发送的IP报文后，将该IP报文中的目的端口号和为该用户终端指定的用于UDP封装端口信息中的目的端口号进行比较，如果一致，将该IP报文按照UDP解包后交给IPSec协议栈处理，并用该报文中的源端口号更新自身保存的用于UDP封装端口信息中的源端口号。

步骤B中进一步包括将该为该用户终端指定的用于UDP封装的端口信息保存，

则在步骤G之后进一步包括：

当AF实体中有向该用户终端发送的IP报文时，AF实体将该IP报文进行IPSec ESP保护并利用所述用于UDP封装的端口信息对该IP报文进行UDP封装后发送给该用户终端；

该用户终端收到来自AF的IP报文后，将该IP报文中的源端口号与自身保存的用于UDP封装端口信息中目的端口号进行比较，并且将该IP报文中目的端口号和自身保存用于UDP封装端口信息中的源端口号进行比较，如果都一致，则说明该报文是UDP封装的IPSec报文，将报文经过UDP解包后，交给IPSec协议栈处理。

步骤B中进一步包括：AF实体保存为该用户终端指定的所述用于UDP封装的端口信息，

则步骤E中所述为该用户终端指定的用于UDP封装端口信息中的目的端口号是从自身保存的为该用户终端指定的所述UDP封装的端口信息中获得；当AF收到用户终端发过来的UDP封装的IPSec报文后，用该报文中的源端口号更新自身保存的用于UDP封装的端口信息中的源端口号。

8、根据权利要求1所述的方法，其特征在于，所述AF实体为P-CSCF。

9、根据权利要求1所述的方法，其特征在于，所述报文负载中携带的用户的IP地址/端口信息为该IP报文中的Contact地址或Via头域中记录的用户域名地址。

10、根据权利要求1所述的方法，其特征在于，在步骤G之后进一步包括：

用户终端/AF定期向AF/用户终端发送NAT保活报文，所述NAT设备根据该保活报文更新自身的NAT表项。

为所有用户终端指定的用于UDP封装端口信息中的目的端口号相同。

在步骤D包括：用户终端在向AF发送的重注册请求的IP报文中携带AF下发的用于UDP封装的端口信息，则步骤E中进一步包括：

AF收到用户终端发送的重注册请求的IP报文后，判断自身下发给该用户终端的用于UDP封装的端口信息与重注册请求的IP报文中携带的用于UDP封装的端口信息是否一致，如果一致，则认为下发给用户终端的响应的IP报文没有被篡改，否则，认为下发给用户终端的响应的IP报文被篡改。

通过上述方案可以看出，当AF收到用户终端首次发送的注册请求后，为该用户终端指定一个用于UDP封装的端口号信息，将该端口号信息作为SA参数保存，并将该端口号信息发送给用户终端，用户终端收到该端口号信息后，也将该端口号信息作为SA参数保存，并且在向AF发送的IP报文进行IPSec保护以及UDP封装处理，AF利用UDP封装端口号的目的端口号进行UDP封装的IPSec报文的识别；当AF有向UE发送的IP报文时，AF同样利用为该用户终端指定一个用于UDP封装的端口号信息对该IP报文进行IPSec保护以及UDP封装处理，UE采用目的端口号、源端口号识别UDP封装的IPSec报文。并且所述为所有用户终端指定的用于UDP封装端口号信息可以相同。

本发明通过对IMS AKA的流程和参数进行适当的扩展，实现目前NGN网络安全规范中非常关注的IPSec穿越NAT，对现有IMS AKA的改动小，方案的扩展也很自然，容易实现。

附图说明

图1为现有技术中IMS AKA流程示意图；

图2为目前一种实现及IPSec NAT穿越的流程示意图；

图3为实现本发明的具体实施例示意图；

图4为UE和P-CSCF之间进行UDP封装时的端口变换过程示意图；

图5为实现本发明方法的流程示意图。

具体实施方式

本发明的核心思想是：当AF收到用户终端首次发送的注册请求后，为该用户终端指定一个用于UDP封装的端口号信息，将该端口号信息保存，并将该端口号信息发送给用户终端，用户终端收到该端口号信息后，也将该端口号信息保存，并且在向AF发送的IP报文进行IPSec保护以及UDP封装处理，AF利用UDP封装端口号的目的端口号进行UDP封装的IPSec报文的识别；当AF有向UE发送的IP报文时，AF同样利用为该用户终端指定一个用于UDP封装的端口号信息对该IP报文进行IPSec保护以及UDP封装处理，UE采用目的端口号、源端口号识别UDP封装的IPSec报文。并且所述为所有用户终端指定的用于UDP封装端口号信息可以相同。并且，上述用户终端和AF中可以将用于UDP封装的端口号信息作为自身的安全联盟(SA)参数保存，也可以将其直接保存的用户终端和AF中。

参见图3所示，实现本发明的方法包括以下步骤：

步骤301：当AF实体收到UE发送的用户注册请求的IP报文后，比较该IP报文头中的源IP地址和报文负载中携带的用户的IP地址是否一致，如果不一致，则确定UE与AF中间有NAT设备，并向核心网发送用户注册请求的IP报文。所述报文负载中携带的用户的IP地址/端口信息为该IP报文中的Contact地址或Via头域中记录的用户域名地址。这里，所述AF实体可以为P-CSCF。

步骤302：当AF实体收到核心网针对该UE返回的鉴权响应后，为该UE指定一个用于用户数据包协议UDP封装的端口号，将该端口号作为SA的参数保存，并将向该UE发送的鉴权响应的IP报文的Security-setup头域中增加所述用于UDP封装的端口号信息，所述端口号信息包括源端口号和目的端口号。

步骤303：UE收到AF实体发送的鉴权响应的IP报文后，判断该IP报文的Security-setup头域中的用于UDP封装的端口信息是否有效，如果有，则执行步骤D，否则，按照正常的AKA流程处理。这里，Security-setup头域中用于UDP封装的端口信息参数中为空或零即为无效，否则为有效。

步骤304：UE将向所述AF实体发送的重注册请求的IP报文进行IPSecESP保护，并利用收到AF发送的IP报文的Security-setup头域中所述用于UDP封装的端口信息对该IP报文进行UDP封装后发送给AF，并且，用户终端将AF实体发送的鉴权响应的IP报文中所述用于UDP封装的端口信息作为SA参数保存。

步骤305：AF收到UE发送的重注册请求的IP报文后，将该IP报文中的目的端口号和为该UE指定的用于UDP封装端口信息中的目的端口号进行比较，如果一致，将该IP报文按照UDP解包后交给IPSec协议栈处理，并且保存该IP报文中的源端口，用该IP报文的源端口号更新SA中UDP封装参数中的源端口，执行步骤306，如果不一致，则说明该报文不是UDP封装的IPSec报文，按照正常的UDP报文处理。

在步骤302中AF实体保存了为该用户终端指定的所述用于UDP封装的端口信息，那么步骤305中所述为该UE指定的用于UDP封装端口信息中的目的端口号可以从自身保存的为该用户终端指定的所述用于UDP封装的端口信息中获得。

步骤306：当AF实体收到核心网针对该UE返回的鉴权响应后，AF实体将向UE发送的鉴权响应的IP报文进行IPSec ESP保护并利用步骤305中更新过的SA参数中用于UDP封装的端口信息对该IP报文进行UDP封装后发送给该UE。

步骤307：该UE收到AF返回的鉴权响应的IP报文后，将该IP报文中的源端号/目的端口号和自身保存的SA参数用于UDP封装的端口信息中的目的端口号/源端口号进行比较，如果一致，则将报文经过UDP解包后，交给IPSec协议栈处理。

此后，当该UE有向AF发送的IP报文时，用户终端将向所述AF实体发送的IP报文进行IPSec ESP保护，并利用收到AF发送的IP报文的Security-setup头域中所述用于UDP封装的端口信息对该IP报文进行UDP封装后发送给AF；AF收到用户终端发送的IP报文后，将该IP报文中的目的端口号和为该用户终端指定的用于UDP封装的端口信息中的目的端口号进行比较，如果一致，将该IP报文按照UDP解包后交给IPSec协议栈处理。

当然，当AF实体中有向该用户终端发送的IP报文时，AF实体将该IP报文进行IPSec ESP保护，并利用所述用于UDP封装的端口信息对该IP报文进行UDP封装后发送给该用户终端；该用户终端收到来自AF的IP报文后，将该IP报文中的源端号/目的端口号和自身保存的SA参数中用于UDP封装的目的端口号/源端口号进行比较，如果一致，则将报文经过UDP解包后，交给IPSec协议栈处理。

如果在步骤304中，用户终端在向AF发送的重注册请求的IP报文中携带AF下发的用于UDP封装的端口信息，则AF收到用户终端发送的重注册请求的IP报文后，判断自身下发给该用户终端的用于UDP封装的端口信息与重注册请求的IP报文中携带的用于UDP封装的端口信息是否一致，如果一致，则认为下发给用户终端的响应的IP报文没有被篡改，否则，认为下发给用户终端的响应的IP报文被篡改。参见图4所示，本发明的方法包括以下步骤：

步骤401：UE(User Equipment，UE)向代理呼叫会话控制功能实体(Proxy-Call Session Control Function，P-CSCF)发送用户注册请求报文(Register)。

步骤402：P-CSCF收到该注册请求报文后，判断中间是否有NAT设备，如果有，则记录该UE与P-CSCF之间存在NAT设备，执行步骤403；如果没有，则按正常的IMS AKA处理，跳出本流程。

步骤403：P-CSCF将UE的注册报文Register转发给I-CSCF。

步骤404：I-CSCF与HSS之间通过Cx-Selection-Info消息选择相应的S-CSCF，即I-CSCF向HSS发出请求，查找HSS中的用户属性来确定由哪个S-CSCF处理该注册报文。

步骤405：I-CSCF将UE的注册报文Register转发给步骤403中所确定S-CSCF。

步骤406：S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF进行。

步骤407：S-CSCF向HSS发送AV-Req消息，请求该用户的鉴权向量。

步骤408：HSS向S-CSCF发送AV-Req-Resp消息，将该用户的鉴权向量，发送给S-CSCF。

步骤409：S-CSCF根据在步骤407中获得的鉴权向量以及UE的注册报文，判断出该用户需要进行鉴权，然后向I-CSCF发送4xx Auth_Challenge消息，表示需要进行鉴权，并携带有与鉴权相关的信息。其中4xx表示一类错误，xx代表从00～99的一个数字。

步骤410：I-CSCF将所述4xx Auth_Challenge消息发送给P-CSCF。

步骤411：P-CSCF收到4xx Auth_Challenge消息后，根据自身保存的记录，确定目的用户终端与自身之间是否存在NAT设备，如果存在，则P-CSCF为该用户终端指定一个进行IPSec NAT穿越时用于UDP封装的端口信息，包括源端口号P_s和目的端口号P_d，并通过4xx响应报文将用于UDP封装的端口信息返回给终端，这里，UDP封装的端口信息置于4xx响应报文的Security-setup头域，如果目的用户终端与自身之间不存在NAT设备，则可以将4xx响应报文的Security-setup头域设置为空、或零。

同时，P-CSCF将用于UDP封装的端口信息作为SA的参数保存，即需要扩展SA参数，对P-CSCF来说，上述P_s为用于UDP封装的目的端口号，P_d为用于UDP封装的源端口号。

步骤412：P-CSCF向UE发送4xx响应报文。

步骤413：UE收到来自P-CSCF的4xx响应报文后，判断该响应报文中的Security-setup头域中是否有UDP封装的端口信息，如果有，则表明UE和P-CSCF中间有NAT设备存在，该UE将UDP端口的信息作为SA的参数保存，并生成重注册请求报文，该报文中的Security-setup的头域中的参数为P-CSCF返回的UDP封装的端口信息，并将该重注册请求报文进行IPSec ESP保护后，再利用收到的P-CSCF发送过来的UDP端口进行UDP封装。

步骤414：UE将经过UDP封装后的重注册请求报文发送给P-CSCF。

步骤415：P-CSCF收到UE的重注册报文后，将IP报文中的目的端口号和步骤411中指定的UDP封装的端口信息中的目的端口号进行比较，如果一致，则确定该报文是UDP封装的IPSec ESP报文，然后P-CSCF将该报文按UDP解包后交给IPSec协议栈处理，同时保存该IP报文中的源端口号，以用于向UE返回报文时进行UDP封装的目的端口号，并用该IP报文的源端口号更新SA中用于UDP封装的端口信息中的源端口号，否则，按正常的IP报文进行处理。

步骤416：P-CSCF将UE的注册报文Register发送给I-CSCF。

步骤417：I-CSCF接收到所述注册报文Register后，与HSS之间通过Cx-Query确定该UE注册报文给哪个S-CSCF处理，即I-CSCF向HSS查询用户注册报文给哪个S-CSCF处理，HSS根据保存的S-CSCF指示信息告知I-CSCF处理该用户注册报文的S-CSCF。

步骤418：I-CSCF将注册报文Register转发给步骤413确定的S-CSCF。

步骤419：S-CSCF与HSS之间通过Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS该用户后续的处理在本S-CSCF。

步骤420：S-CSCF与HSS通过Cx-Pull消息获取用户的签约数据信息。

步骤421：S-CSCF根据所述用户的签约数据信息和UE注册报文Register中的认证参数，进行鉴权。如果鉴权成功，S-CSCF向I-CSCF发送2xxAuth_OK消息，表示注册成功，其中2xx表示成功相应的消息，xx为00～99的一个数字。如果鉴权失败，则S-CSCF向I-CSCF发送表示鉴权失败的消息。

步骤422：如果鉴权成功，I-CSCF将上述2xx Auth_OK消息发送给P-CSCF。如果鉴权失败，则I-CSCF将上述表示鉴权失败的消息发送给P-CSCF。

步骤423～424：如果鉴权成功，P-CSCF将上述2xx Auth_OK消息采用IPSec ESP对报文进行保护后，采用更新过的SA参数中指定的用于UDP封装的端口进行UDP封装后发送给UE。如果鉴权失败，P-CSCF可以对收到的鉴权失败的消息采用IPSec ESP对报文进行保护、利用步骤411中指定的用于UDP封装端口信息进行UDP封装后发送给UE，也可以不进行任何处理，结束本流程。

步骤425：UE收到P-CSCF返回的报文后，将报文中的源端号/目的端口号和自身保存的SA参数中用于UDP封装的端口信息中的端口号/源端口号进行比较，即将报文中的源端口号和自身保存的SA参数中的用于UDP封装的端口信息中的目的端口号进行比较，将报文中的目的端口号和自身保存的SA参数中的用于UDP封装的端口信息中的源端口号进行比较，如果一致，则认为该报文是经过UDP封装后的IPSec ESP报文，将报文经过UDP解包后，交给IPSec协议栈处理，否则，按正常的IPSec协议处理。

步骤426：此后，UE和P-CSCF之间的交互报文按步骤413和423中描述的处理方式进行处理，同时后续UE或P-CSCF需要不断发送NAT表项的保活报文，该功能在SIP信令穿越NAT功能时也需要实现，两者实现的方式是一致的，在此不再作进一步描述。

从上述实施例中可以看出，在步骤413中UE将报文经过UDP封装后发给P-CSCF，由于源端口号经过NAT后已可能被转换为其它不为P-CSCF所知的端口，故只用目的端口号来进行匹配，这种方式符合P-CSCF作为服务器端的特点，如可以对所有客户端给定一个知名端口，标识目的端口号为该端口的报文为UDP封装的IPSec ESP报文。对于UE设备来说，由于只与P-CSCF有信令通道，而不会和其它设备有信令通道，则可以采用源端口和目的端口一起，或者是源端口号来进行匹配，判断该报文是否为UDP封装的IPSec ESP报文，符合UE作为客户端的特点。

参见图5所示，UE和P-CSCF之间进行UDP封装时的端口变换过程如下：

步骤501：由于P-CSCF向UE发送的IP报文中端口号为指定的UDP封装端口号，即(P_s，P_d)，因此UE向P-CSCF发送的经过UDP封装后的IP报文中的地址为(P_s，P_d)。

步骤502：IP报文中的UDP端口号已经经过NAT转换，变为P_s’，NAT设备中记录了NAT表项，故此后P-CSCF利用目的端口号P_d来识别UDP封装报文，同时记下P_s’用于向UE发送报文的目的端口号。

步骤503：当该IP报文经过NAT后，IP报文的源端口又转换为P_s，故终端可以通过(P_s，P_d)，或者通过源端口号(P_s)来识别该报文是否是UDP封装的IPSec ESP报文。

Claims (12)

1、一种支持网络层安全穿越网络地址转换的方法，应用于包括应用功能AF实体的分组业务网络中，其特征在于，该方法包括以下步骤：

A.当AF实体收到用户终端发送的用户注册请求的IP报文后，比较该IP报文头中的源IP地址和报文负载中携带的用户的IP地址是否一致，如果不一致，则确定用户终端与AF中间有NAT设备，并向核心网发送用户注册请求的IP报文；

B.当AF实体收到核心网针对该用户终端返回的鉴权响应后，为该用户终端指定用于用户数据包协议UDP封装的端口信息，并将向该用户终端发送的鉴权响应的IP报文的安全联盟设置参数Security-setup头域中增加所述用于UDP封装的端口信息，所述端口信息包括源端口号和目的端口号；

C.用户终端收到AF实体发送的鉴权响应的IP报文后，判断该IP报文的Security-setup头域中的用于UDP封装的端口号信息是否有效，如果有效，则执行步骤D；

D.用户终端将向所述AF实体发送的重注册请求的IP报文进行IPSec ESP保护，并利用收到AF发送的IP报文的Security-setup头域中所述用于UDP封装端口信息对该IP报文进行UDP封装后发送给AF，且用户终端将AF实体发送的鉴权响应的IP报文中所述用于UDP封装的端口信息保存；

E.AF收到用户终端发送的重注册请求的IP报文后，将该IP报文中的目的端口号和为该用户终端指定的用于UDP封装端口信息中的目的端口号进行比较，如果一致，将该IP报文按照UDP解包后交给IPSec协议栈处理，并且保存该IP报文中的源端口号，更新自身保存的用户UDP封装端口信息中的源端口号；

F.当AF实体收到核心网针对该用户终端返回的鉴权响应后，AF实体将向用户终端发送的鉴权响应的IP报文进行IPSec ESP保护并利用所述更新过的用于UDP封装端口信息对该IP报文进行UDP封装后发送给该用户终端；

G.该用户终端收到AF返回的鉴权响应的IP报文后，将该IP报文的地址/端口与自身保存的用于UDP封装的端口信息进行比较，判断出该报文是否是UDP封装的IPSec报文，如果是，则将报文经过UDP解包后，交给IPSec协议栈处理。

2、根据权利要求1所述的方法，其特征在于，步骤G中判断出该报文是否是UDP封装的IPSec报文步骤包括：

将该IP报文中的源端号与自身保存的用于UDP封装的目的端口号进行比较，如果一致，则该报文是UDP封装的IPSec报文，否则，该报文不是UDP封装的IPSec报文。

3、根据权利要求1所述的方法，其特征在于，步骤G中判断出该报文是否是UDP封装的IPSec报文步骤包括：

步骤G中在将该IP报文中的源端号与自身保存的用于UDP封装的目的端口号进行比较，以及将该IP报文中目的端口号和自身保存的用于UDP封装的源端口号进行比较，如果都一致，则该报文是UDP封装的IPSec报文，否则，该报文不是UDP封装的IPSec报文。

4、根据权利要求1所述的方法，其特征在于，步骤G中判断出该报文是否是UDP封装的IPSec报文步骤包括：将该IP报文中目的端口号和自身保存的用于UDP封装的源端口号进行比较，如果一致，则该报文是UDP封装的IPSec报文，否则，该报文不是UDP封装的IPSec报文。

5、根据权利要求1所述的方法，其特征在于，当用户终端有向AF发送的IP报文时，用户终端将向所述AF实体发送的IP报文进行IPSec ESP保护后，利用收到的AF发送的IP报文的Security-setup头域中自身保存的用于UDP封装的端口信息对该IP报文进行UDP封装后发送给AF；

AF收到用户终端发送的IP报文后，将该IP报文中的目的端口号和为该用户终端指定的用于UDP封装端口信息中的目的端口号进行比较，如果一致，将该IP报文按照UDP解包后交给IPSec协议栈处理，并用该报文中的源端口号更新自身保存的用于UDP封装端口信息中的源端口号。

6、根据权利要求1所述的方法，其特征在于，步骤B中进一步包括将该为该用户终端指定的用于UDP封装的端口信息保存，

则在步骤G之后进一步包括：

当AF实体中有向该用户终端发送的IP报文时，AF实体将该IP报文进行IPSec ESP保护并利用所述用于UDP封装的端口信息对该IP报文进行UDP封装后发送给该用户终端；

该用户终端收到来自AF的IP报文后，将该IP报文中的源端口号与自身保存的用于UDP封装端口信息中目的端口号进行比较，并且将该IP报文中目的端口号和自身保存用于UDP封装端口信息中的源端口号进行比较，如果都一致，则说明该报文是UDP封装的IPSec报文，将报文经过UDP解包后，交给IPSec协议栈处理。

7、根据权利要求1所述的方法，其特征在于，步骤B中进一步包括：AF实体保存为该用户终端指定的所述用于UDP封装的端口信息，

则步骤E中所述为该用户终端指定的用于UDP封装端口信息中的目的端口号是从自身保存的为该用户终端指定的所述UDP封装的端口信息中获得；当AF收到用户终端发过来的UDP封装的IPSec报文后，用该报文中的源端口号更新自身保存的用于UDP封装的端口信息中的源端口号。

8、根据权利要求1所述的方法，其特征在于，所述AF实体为P-CSCF。

9、根据权利要求1所述的方法，其特征在于，所述报文负载中携带的用户的IP地址/端口信息为该IP报文中的Contact地址或Via头域中记录的用户域名地址。

10、根据权利要求1所述的方法，其特征在于，在步骤G之后进一步包括：

用户终端/AF定期向AF/用户终端发送NAT保活报文，所述NAT设备根据该保活报文更新自身的NAT表项。

11、根据权利要求1所述的方法，其特征在于，为所有用户终端指定的用于UDP封装端口信息中的目的端口号相同。

12、根据权利要求1所述的方法，其特征在于，在步骤D包括：用户终端在向AF发送的重注册请求的IP报文中携带AF下发的用于UDP封装的端口信息，则步骤E中进一步包括：

AF收到用户终端发送的重注册请求的IP报文后，判断自身下发给该用户终端的用于UDP封装的端口信息与重注册请求的IP报文中携带的用于UDP封装的端口信息是否一致，如果一致，则认为下发给用户终端的响应的IP报文没有被篡改，否则，认为下发给用户终端的响应的IP报文被篡改。

Images