專利名稱：一種支持網(wǎng)絡(luò)層安全穿越網(wǎng)絡(luò)地址轉(zhuǎn)換的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)層安全技術(shù)領(lǐng)域，特別是一種支持網(wǎng)絡(luò)層安全穿越地址轉(zhuǎn)換的方法。
背景技術(shù)：
在第三代移動通信系統(tǒng)(3GPP)IP多媒體子系統(tǒng)(IMS)R5/R6/R7的安全規(guī)范中，IMS認(rèn)證的密鑰協(xié)商(AKA)用于實現(xiàn)3GPP接入域中的網(wǎng)絡(luò)與終端的雙向認(rèn)證，以及終端和網(wǎng)絡(luò)之間安全密鑰的分發(fā)、算法協(xié)商及其它安全聯(lián)盟參數(shù)的協(xié)商。在IMS AKA的基礎(chǔ)上，IMS網(wǎng)絡(luò)接入域安全基于IPSec安全載荷封裝(ESP)協(xié)議對終端和代理呼叫會話控制功能(P-CSCF)之間的信令流進(jìn)行完整性和機密性保護(hù)。在固定下一代(NGN)網(wǎng)絡(luò)中，會話控制層同樣基于3GPP的IMS網(wǎng)絡(luò)架構(gòu)，IMS成為一個與接入網(wǎng)絡(luò)無關(guān)的獨立的網(wǎng)絡(luò)會話控制層，IMS網(wǎng)絡(luò)在固定NGN網(wǎng)絡(luò)中的安全規(guī)范同樣繼承了3GPP中的定義，并在其基礎(chǔ)上發(fā)展和完善，以解決一些固定網(wǎng)絡(luò)中特有的問題。
在固定NGN網(wǎng)絡(luò)中，由于IPv4地址的缺乏，網(wǎng)絡(luò)中部署了大量的NAT設(shè)備，而IPSec協(xié)議穿越NAT存在問題，即由于經(jīng)過NAT設(shè)備更改報文頭中的IP地址/端口號，有可能導(dǎo)致接收端在收到IPSec報文進(jìn)行安全檢查失敗而將報文丟棄，為此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協(xié)議通過UDP封裝來完成NAT穿越，但其解決方案是針對IPSec的密鑰交換協(xié)議(IKE)而制定完善的，而在IMS網(wǎng)絡(luò)接入安全中，密鑰協(xié)商協(xié)議是通過IMS AKA來完成的，因此有必要針對IMS AKA實現(xiàn)對IPSec穿越NAT的支持。
IMS網(wǎng)絡(luò)安全模型將安全劃分為接入域和網(wǎng)絡(luò)域，下面介紹一下IMS網(wǎng)絡(luò)接入域安全的核心-接入域AKA流程。圖1所示為IMS AKA流程，由于本發(fā)明中主要關(guān)注UE和P-CSCF之間的協(xié)商，P-CSCF及網(wǎng)絡(luò)側(cè)其它實體I/S-CSCF、HSS之間的交互在本方案中不受影響，因此下面重點描述一下步驟101、110、111和119，其它步驟簡單描述。
參考圖1，AKA流程包括以下步驟步驟101用戶終端(User Equipment，UE)向代理呼叫會話控制功能實體(Proxy-Call Session Control Function，P-CSCF)發(fā)送注冊報文Register。
步驟102P-CSCF作為會話發(fā)起協(xié)議(Session Initial Protocol，SIP)代理服務(wù)器，將UE的注冊報文Register轉(zhuǎn)發(fā)給詢問呼叫會話控制功能實體(Interrogaing-Call Session Control Function，I-CSCF)。
步驟103I-CSCF與歸屬用戶服務(wù)器(Home Subscribe Server，HSS)之間通過Cx-Selection-Info消息選擇相應(yīng)的服務(wù)呼叫會話控制功能實體(Service-Call Session Control Function，S-CSCF)，即I-CSCF向HSS發(fā)出請求，查找HSS中的用戶屬性來確定由哪個S-CSCF處理該注冊報文。
步驟104I-CSCF將UE的注冊報文Register轉(zhuǎn)發(fā)給步驟103中所確定S-CSCF。
步驟105S-CSCF與HSS之間通過Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS該用戶后續(xù)的處理在本S-CSCF進(jìn)行。
步驟106S-CSCF向HSS發(fā)送AV-Req消息，請求該用戶的鑒權(quán)向量。
步驟107HSS向S-CSCF發(fā)送AV-Req-Resp消息，將該用戶的鑒權(quán)向量，發(fā)送給S-CSCF。
步驟108S-CSCF根據(jù)在步驟107中獲得的鑒權(quán)向量以及UE的注冊報文，判斷出該用戶需要進(jìn)行鑒權(quán)，然后向I-CSCF發(fā)送4xx Auth_Challenge消息，表示需要進(jìn)行鑒權(quán)，并攜帶有與鑒權(quán)相關(guān)的信息。其中4xx表示一類錯誤，xx代表從00～99的一個數(shù)字。
步驟109I-CSCF將所述4xx Auth_Challenge消息發(fā)送給P-CSCF。
步驟110P-CSCF將所述4xx Auth_Challenge消息發(fā)送給UE。
步驟111UE接收到所述4xx Auth_Challenge消息后，重新向P-CSCF發(fā)送新的注冊報文Register，并且該Register攜帶有認(rèn)證參數(shù)。
步驟112P-CSCF將UE的注冊報文Register發(fā)送給I-CSCF。
步驟113I-CSCF接收到所述注冊報文Register后，與HSS之間通過Cx-Query確定該UE注冊報文給哪個S-CSCF處理，即I-CSCF向HSS查詢用戶注冊報文給哪個S-CSCF處理，HSS根據(jù)保存的S-CSCF指示信息告知I-CSCF處理該用戶注冊報文的S-CSCF。
步驟114I-CSCF將注冊報文Register轉(zhuǎn)發(fā)給步驟113確定的S-CSCF。
步驟115S-CSCF與HSS之間通過Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS該用戶后續(xù)的處理在本S-CSCF。
步驟116S-CSCF與HSS通過Cx-Pull消息獲取用戶的簽約數(shù)據(jù)信息。
步驟117S-CSCF根據(jù)所述用戶的簽約數(shù)據(jù)信息和UE注冊報文Register中的認(rèn)證參數(shù)，進(jìn)行鑒權(quán)。如果鑒權(quán)成功，S-CSCF向I-CSCF發(fā)送2xxAuth_OK消息，表示注冊成功，其中2xx表示成功相應(yīng)的消息，xx為00～99的一個數(shù)字。如果鑒權(quán)失敗，則S-CSCF向I-CSCF發(fā)送表示鑒權(quán)失敗的消息。
步驟118如果鑒權(quán)成功，I-CSCF將上述2xx Auth_OK消息發(fā)送給P-CSCF。如果鑒權(quán)失敗，則I-CSCF將上述表示鑒權(quán)失敗的消息發(fā)送給P-CSCF。
步驟119如果鑒權(quán)失敗，P-CSCF將上述2xx Auth_OK消息發(fā)送給UE。如果鑒權(quán)失敗，則P-CSCF將上述表示鑒權(quán)失敗的消息發(fā)送給UE。
另外，參見圖2所示，目前還有一種實現(xiàn)方案，在該方案中，SIP Server相當(dāng)于上述P-CSCF，具體步驟如下SIP Client A通過NAT gatway向SIPServer A發(fā)送注冊請求報文，其中含有SIP Client A的域名。SIP Server A收到客戶端的第一個注冊請求報文后，比較該報文中報文頭的源IP地址和該報文中報文負(fù)載中攜帶的Contact地址是否一致，如果兩者不一致，則判斷出客戶端和SIP Server之間存在NAT設(shè)備，SIP Server A向HSS-A發(fā)送Forward sip client-A@server-A；HSS收到后，產(chǎn)生AKA quintuplets，并向SIPServer A返回CK、IK、RAND、AUTN，SIP Server A向SIP Client A返回RAND、AUTN；然后，客戶端向SIP Server發(fā)起一個UDP封裝的Ping報文，用于在中間的NAT設(shè)備上創(chuàng)建UDP端口的映射，同時SIP Server也需要保存到達(dá)的Ping報文的UDP端口號，后續(xù)客戶端和SIP Server之間將通過上述UDP端口號對IPSec ESP報文進(jìn)行UDP封裝后穿越NAT設(shè)備而進(jìn)行安全的通信。
在上述方案具有如下缺點(1)在步驟7和9中，報文沒有經(jīng)過IPSec ESP保護(hù)，和現(xiàn)有的IMS AKA流程不符，同時存在一定的安全隱患，在步驟7中，SIP Server需要通過對終端發(fā)過來的報文進(jìn)行認(rèn)證來判斷在步驟1和6中發(fā)送的報文中的安全參數(shù)是否被篡改過，如果被篡改，則整個IMS AKA過程將終止，但現(xiàn)在由于步驟7沒有經(jīng)過保護(hù)，SIP Server無法做出判斷。
(2)由于報文9沒有進(jìn)行保護(hù)，則報文可能被篡改，即終端收到的認(rèn)證結(jié)果信息可能是錯誤的。
(3)上述流程中通過增加一個UDP封裝的Ping報文來實現(xiàn)在NAT設(shè)備上UDP端口號的映射，由于Ping是基于ICMP的一個純粹IP層的功能實現(xiàn)，其與應(yīng)用層沒有關(guān)系，此時需要在IP層和應(yīng)用層之間的接口，而該接口不符合常規(guī)。
(4)此外，SIP Server A隨時都有可能收到從其它設(shè)備或終端發(fā)過來的基于ICMP的Ping報文，SIP Server，相當(dāng)于P-CSCF，無法判斷哪一個Ping報文是用于實現(xiàn)UDP封裝功能的，或判斷出錯，即導(dǎo)致將收到的UDP端口號和終端關(guān)聯(lián)錯誤，使得SIP Server既無法向終端發(fā)送UDP封裝的IPSecESP報文，也無法用來鑒別該一個UDP報文是UDP封裝的IPSec ESP報文。
本發(fā)明提供的一種IPsec穿越NAT的方法是這樣實現(xiàn)的A.當(dāng)AF實體收到用戶終端發(fā)送的用戶注冊請求的IP報文后，比較該IP報文頭中的源IP地址和報文負(fù)載中攜帶的用戶的IP地址是否一致，如果不一致，則確定用戶終端與AF中間有NAT設(shè)備，并向核心網(wǎng)發(fā)送用戶注冊請求的IP報文；B.當(dāng)AF實體收到核心網(wǎng)針對該用戶終端返回的鑒權(quán)響應(yīng)后，為該用戶終端指定用于用戶數(shù)據(jù)包協(xié)議UDP封裝的端口信息，并將向該用戶終端發(fā)送的鑒權(quán)響應(yīng)的IP報文的安全聯(lián)盟設(shè)置參數(shù)Security-setup頭域中增加所述用于UDP封裝的端口信息，所述端口信息包括源端口號和目的端口號；C.用戶終端收到AF實體發(fā)送的鑒權(quán)響應(yīng)的IP報文后，判斷該IP報文的Security-setup頭域中的用于UDP封裝的端口號信息是否有效，如果有效，則執(zhí)行步驟D；D.用戶終端將向所述AF實體發(fā)送的重注冊請求的IP報文進(jìn)行IPSec ESP保護(hù)，并利用收到AF發(fā)送的IP報文的Security-setup頭域中所述用于UDP封裝端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給AF，且用戶終端將AF實體發(fā)送的鑒權(quán)響應(yīng)的IP報文中所述用于UDP封裝的端口信息保存；E.AF收到用戶終端發(fā)送的重注冊請求的IP報文后，將該IP報文中的目的端口號和為該用戶終端指定的用于UDP封裝端口信息中的目的端口號進(jìn)行比較，如果一致，將該IP報文按照UDP解包后交給IPSec協(xié)議棧處理，并且保存該IP報文中的源端口號，更新自身保存的用戶UDP封裝端口信息中的源端口號；F.當(dāng)AF實體收到核心網(wǎng)針對該用戶終端返回的鑒權(quán)響應(yīng)后，AF實體將向用戶終端發(fā)送的鑒權(quán)響應(yīng)的IP報文進(jìn)行IPSec ESP保護(hù)并利用所述更新過的用于UDP封裝端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給該用戶終端；G.該用戶終端收到AF返回的鑒權(quán)響應(yīng)的IP報文后，將該IP報文的地址/端口與自身保存的用于UDP封裝的端口信息進(jìn)行比較，判斷出該報文是否是UDP封裝的IPSec報文，如果是，則將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理。
步驟G中判斷出該報文是否是UDP封裝的IPSec報文步驟包括將該IP報文中的源端號與自身保存的用于UDP封裝的目的端口號進(jìn)行比較，如果一致，則該報文是UDP封裝的IPSec報文，否則，該報文不是UDP封裝的IPSec報文。
步驟G中判斷出該報文是否是UDP封裝的IPSec報文步驟包括步驟G中在將該IP報文中的源端號與自身保存的用于UDP封裝的目的端口號進(jìn)行比較，以及將該IP報文中目的端口號和自身保存的用于UDP封裝的源端口號進(jìn)行比較，如果都一致，則該報文是UDP封裝的IPSec報文，否則，該報文不是UDP封裝的IPSec報文。
步驟G中判斷出該報文是否是UDP封裝的IPSec報文步驟包括將該IP報文中目的端口號和自身保存的用于UDP封裝的源端口號進(jìn)行比較，如果一致，則該報文是UDP封裝的IPSec報文，否則，該報文不是UDP封裝的IPSec報文。5、根據(jù)權(quán)利要求1所述的方法，其特征在于，當(dāng)用戶終端有向AF發(fā)送的IP報文時，用戶終端將向所述AF實體發(fā)送的IP報文進(jìn)行IPSec ESP保護(hù)后，利用收到的AF發(fā)送的IP報文的Security-setup頭域中自身保存的用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給AF；AF收到用戶終端發(fā)送的IP報文后，將該IP報文中的目的端口號和為該用戶終端指定的用于UDP封裝端口信息中的目的端口號進(jìn)行比較，如果一致，將該IP報文按照UDP解包后交給IPSec協(xié)議棧處理，并用該報文中的源端口號更新自身保存的用于UDP封裝端口信息中的源端口號。
步驟B中進(jìn)一步包括將該為該用戶終端指定的用于UDP封裝的端口信息保存，則在步驟G之后進(jìn)一步包括當(dāng)AF實體中有向該用戶終端發(fā)送的IP報文時，AF實體將該IP報文進(jìn)行IPSec ESP保護(hù)并利用所述用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給該用戶終端；該用戶終端收到來自AF的IP報文后，將該IP報文中的源端口號與自身保存的用于UDP封裝端口信息中目的端口號進(jìn)行比較，并且將該IP報文中目的端口號和自身保存用于UDP封裝端口信息中的源端口號進(jìn)行比較，如果都一致，則說明該報文是UDP封裝的IPSec報文，將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理。
步驟B中進(jìn)一步包括AF實體保存為該用戶終端指定的所述用于UDP封裝的端口信息，則步驟E中所述為該用戶終端指定的用于UDP封裝端口信息中的目的端口號是從自身保存的為該用戶終端指定的所述UDP封裝的端口信息中獲得；當(dāng)AF收到用戶終端發(fā)過來的UDP封裝的IPSec報文后，用該報文中的源端口號更新自身保存的用于UDP封裝的端口信息中的源端口號。
8、根據(jù)權(quán)利要求1所述的方法，其特征在于，所述AF實體為P-CSCF。
9、根據(jù)權(quán)利要求1所述的方法，其特征在于，所述報文負(fù)載中攜帶的用戶的IP地址/端口信息為該IP報文中的Contact地址或Via頭域中記錄的用戶域名地址。
10、根據(jù)權(quán)利要求1所述的方法，其特征在于，在步驟G之后進(jìn)一步包括用戶終端/AF定期向AF/用戶終端發(fā)送NAT?；顖笪?，所述NAT設(shè)備根據(jù)該保活報文更新自身的NAT表項。
為所有用戶終端指定的用于UDP封裝端口信息中的目的端口號相同。
在步驟D包括用戶終端在向AF發(fā)送的重注冊請求的IP報文中攜帶AF下發(fā)的用于UDP封裝的端口信息，則步驟E中進(jìn)一步包括AF收到用戶終端發(fā)送的重注冊請求的IP報文后，判斷自身下發(fā)給該用戶終端的用于UDP封裝的端口信息與重注冊請求的IP報文中攜帶的用于UDP封裝的端口信息是否一致，如果一致，則認(rèn)為下發(fā)給用戶終端的響應(yīng)的IP報文沒有被篡改，否則，認(rèn)為下發(fā)給用戶終端的響應(yīng)的IP報文被篡改。
通過上述方案可以看出，當(dāng)AF收到用戶終端首次發(fā)送的注冊請求后，為該用戶終端指定一個用于UDP封裝的端口號信息，將該端口號信息作為SA參數(shù)保存，并將該端口號信息發(fā)送給用戶終端，用戶終端收到該端口號信息后，也將該端口號信息作為SA參數(shù)保存，并且在向AF發(fā)送的IP報文進(jìn)行IPSec保護(hù)以及UDP封裝處理，AF利用UDP封裝端口號的目的端口號進(jìn)行UDP封裝的IPSec報文的識別；當(dāng)AF有向UE發(fā)送的IP報文時，AF同樣利用為該用戶終端指定一個用于UDP封裝的端口號信息對該IP報文進(jìn)行IPSec保護(hù)以及UDP封裝處理，UE采用目的端口號、源端口號識別UDP封裝的IPSec報文。并且所述為所有用戶終端指定的用于UDP封裝端口號信息可以相同。
本發(fā)明通過對IMS AKA的流程和參數(shù)進(jìn)行適當(dāng)?shù)臄U展，實現(xiàn)目前NGN網(wǎng)絡(luò)安全規(guī)范中非常關(guān)注的IPSec穿越NAT，對現(xiàn)有IMS AKA的改動小，方案的擴展也很自然，容易實現(xiàn)。
圖1為現(xiàn)有技術(shù)中IMS AKA流程示意圖；圖2為目前一種實現(xiàn)及IPSec NAT穿越的流程示意圖；圖3為實現(xiàn)本發(fā)明的具體實施例示意圖；圖4為UE和P-CSCF之間進(jìn)行UDP封裝時的端口變換過程示意圖；圖5為實現(xiàn)本發(fā)明方法的流程示意圖。
具體實施例方式
本發(fā)明的核心思想是當(dāng)AF收到用戶終端首次發(fā)送的注冊請求后，為該用戶終端指定一個用于UDP封裝的端口號信息，將該端口號信息保存，并將該端口號信息發(fā)送給用戶終端，用戶終端收到該端口號信息后，也將該端口號信息保存，并且在向AF發(fā)送的IP報文進(jìn)行IPSec保護(hù)以及UDP封裝處理，AF利用UDP封裝端口號的目的端口號進(jìn)行UDP封裝的IPSec報文的識別；當(dāng)AF有向UE發(fā)送的IP報文時，AF同樣利用為該用戶終端指定一個用于UDP封裝的端口號信息對該IP報文進(jìn)行IPSec保護(hù)以及UDP封裝處理，UE采用目的端口號、源端口號識別UDP封裝的IPSec報文。并且所述為所有用戶終端指定的用于UDP封裝端口號信息可以相同。并且，上述用戶終端和AF中可以將用于UDP封裝的端口號信息作為自身的安全聯(lián)盟(SA)參數(shù)保存，也可以將其直接保存的用戶終端和AF中。
參見圖3所示，實現(xiàn)本發(fā)明的方法包括以下步驟步驟301當(dāng)AF實體收到UE發(fā)送的用戶注冊請求的IP報文后，比較該IP報文頭中的源IP地址和報文負(fù)載中攜帶的用戶的IP地址是否一致，如果不一致，則確定UE與AF中間有NAT設(shè)備，并向核心網(wǎng)發(fā)送用戶注冊請求的IP報文。所述報文負(fù)載中攜帶的用戶的IP地址/端口信息為該IP報文中的Contact地址或Via頭域中記錄的用戶域名地址。這里，所述AF實體可以為P-CSCF。
步驟302當(dāng)AF實體收到核心網(wǎng)針對該UE返回的鑒權(quán)響應(yīng)后，為該UE指定一個用于用戶數(shù)據(jù)包協(xié)議UDP封裝的端口號，將該端口號作為SA的參數(shù)保存，并將向該UE發(fā)送的鑒權(quán)響應(yīng)的IP報文的Security-setup頭域中增加所述用于UDP封裝的端口號信息，所述端口號信息包括源端口號和目的端口號。
步驟303UE收到AF實體發(fā)送的鑒權(quán)響應(yīng)的IP報文后，判斷該IP報文的Security-setup頭域中的用于UDP封裝的端口信息是否有效，如果有，則執(zhí)行步驟D，否則，按照正常的AKA流程處理。這里，Security-setup頭域中用于UDP封裝的端口信息參數(shù)中為空或零即為無效，否則為有效。
步驟304UE將向所述AF實體發(fā)送的重注冊請求的IP報文進(jìn)行IPSecESP保護(hù)，并利用收到AF發(fā)送的IP報文的Security-setup頭域中所述用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給AF，并且，用戶終端將AF實體發(fā)送的鑒權(quán)響應(yīng)的IP報文中所述用于UDP封裝的端口信息作為SA參數(shù)保存。
步驟305AF收到UE發(fā)送的重注冊請求的IP報文后，將該IP報文中的目的端口號和為該UE指定的用于UDP封裝端口信息中的目的端口號進(jìn)行比較，如果一致，將該IP報文按照UDP解包后交給IPSec協(xié)議棧處理，并且保存該IP報文中的源端口，用該IP報文的源端口號更新SA中UDP封裝參數(shù)中的源端口，執(zhí)行步驟306，如果不一致，則說明該報文不是UDP封裝的IPSec報文，按照正常的UDP報文處理。
在步驟302中AF實體保存了為該用戶終端指定的所述用于UDP封裝的端口信息，那么步驟305中所述為該UE指定的用于UDP封裝端口信息中的目的端口號可以從自身保存的為該用戶終端指定的所述用于UDP封裝的端口信息中獲得。
步驟306當(dāng)AF實體收到核心網(wǎng)針對該UE返回的鑒權(quán)響應(yīng)后，AF實體將向UE發(fā)送的鑒權(quán)響應(yīng)的IP報文進(jìn)行IPSec ESP保護(hù)并利用步驟305中更新過的SA參數(shù)中用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給該UE。
步驟307該UE收到AF返回的鑒權(quán)響應(yīng)的IP報文后，將該IP報文中的源端號/目的端口號和自身保存的SA參數(shù)用于UDP封裝的端口信息中的目的端口號/源端口號進(jìn)行比較，如果一致，則將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理。
此后，當(dāng)該UE有向AF發(fā)送的IP報文時，用戶終端將向所述AF實體發(fā)送的IP報文進(jìn)行IPSec ESP保護(hù)，并利用收到AF發(fā)送的IP報文的Security-setup頭域中所述用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給AF；AF收到用戶終端發(fā)送的IP報文后，將該IP報文中的目的端口號和為該用戶終端指定的用于UDP封裝的端口信息中的目的端口號進(jìn)行比較，如果一致，將該IP報文按照UDP解包后交給IPSec協(xié)議棧處理。
當(dāng)然，當(dāng)AF實體中有向該用戶終端發(fā)送的IP報文時，AF實體將該IP報文進(jìn)行IPSec ESP保護(hù)，并利用所述用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給該用戶終端；該用戶終端收到來自AF的IP報文后，將該IP報文中的源端號/目的端口號和自身保存的SA參數(shù)中用于UDP封裝的目的端口號/源端口號進(jìn)行比較，如果一致，則將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理。
如果在步驟304中，用戶終端在向AF發(fā)送的重注冊請求的IP報文中攜帶AF下發(fā)的用于UDP封裝的端口信息，則AF收到用戶終端發(fā)送的重注冊請求的IP報文后，判斷自身下發(fā)給該用戶終端的用于UDP封裝的端口信息與重注冊請求的IP報文中攜帶的用于UDP封裝的端口信息是否一致，如果一致，則認(rèn)為下發(fā)給用戶終端的響應(yīng)的IP報文沒有被篡改，否則，認(rèn)為下發(fā)給用戶終端的響應(yīng)的IP報文被篡改。參見圖4所示，本發(fā)明的方法包括以下步驟步驟401UE(User Equipment，UE)向代理呼叫會話控制功能實體(Proxy-Call Session Control Function，P-CSCF)發(fā)送用戶注冊請求報文(Register)。
步驟402P-CSCF收到該注冊請求報文后，判斷中間是否有NAT設(shè)備，如果有，則記錄該UE與P-CSCF之間存在NAT設(shè)備，執(zhí)行步驟403；如果沒有，則按正常的IMS AKA處理，跳出本流程。
步驟403P-CSCF將UE的注冊報文Register轉(zhuǎn)發(fā)給I-CSCF。
步驟404I-CSCF與HSS之間通過Cx-Selection-Info消息選擇相應(yīng)的S-CSCF，即I-CSCF向HSS發(fā)出請求，查找HSS中的用戶屬性來確定由哪個S-CSCF處理該注冊報文。
步驟405I-CSCF將UE的注冊報文Register轉(zhuǎn)發(fā)給步驟403中所確定S-CSCF。
步驟406S-CSCF與HSS之間通過Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS該用戶后續(xù)的處理在本S-CSCF進(jìn)行。
步驟407S-CSCF向HSS發(fā)送AV-Req消息，請求該用戶的鑒權(quán)向量。
步驟408HSS向S-CSCF發(fā)送AV-Req-Resp消息，將該用戶的鑒權(quán)向量，發(fā)送給S-CSCF。
步驟409S-CSCF根據(jù)在步驟407中獲得的鑒權(quán)向量以及UE的注冊報文，判斷出該用戶需要進(jìn)行鑒權(quán)，然后向I-CSCF發(fā)送4xx Auth_Challenge消息，表示需要進(jìn)行鑒權(quán)，并攜帶有與鑒權(quán)相關(guān)的信息。其中4xx表示一類錯誤，xx代表從00～99的一個數(shù)字。
步驟410I-CSCF將所述4xx Auth_Challenge消息發(fā)送給P-CSCF。
步驟411P-CSCF收到4xx Auth_Challenge消息后，根據(jù)自身保存的記錄，確定目的用戶終端與自身之間是否存在NAT設(shè)備，如果存在，則P-CSCF為該用戶終端指定一個進(jìn)行IPSec NAT穿越時用于UDP封裝的端口信息，包括源端口號P_s和目的端口號P_d，并通過4xx響應(yīng)報文將用于UDP封裝的端口信息返回給終端，這里，UDP封裝的端口信息置于4xx響應(yīng)報文的Security-setup頭域，如果目的用戶終端與自身之間不存在NAT設(shè)備，則可以將4xx響應(yīng)報文的Security-setup頭域設(shè)置為空、或零。
同時，P-CSCF將用于UDP封裝的端口信息作為SA的參數(shù)保存，即需要擴展SA參數(shù)，對P-CSCF來說，上述P_s為用于UDP封裝的目的端口號，P_d為用于UDP封裝的源端口號。
步驟412P-CSCF向UE發(fā)送4xx響應(yīng)報文。
步驟413UE收到來自P-CSCF的4xx響應(yīng)報文后，判斷該響應(yīng)報文中的Security-setup頭域中是否有UDP封裝的端口信息，如果有，則表明UE和P-CSCF中間有NAT設(shè)備存在，該UE將UDP端口的信息作為SA的參數(shù)保存，并生成重注冊請求報文，該報文中的Security-setup的頭域中的參數(shù)為P-CSCF返回的UDP封裝的端口信息，并將該重注冊請求報文進(jìn)行IPSec ESP保護(hù)后，再利用收到的P-CSCF發(fā)送過來的UDP端口進(jìn)行UDP封裝。
步驟414UE將經(jīng)過UDP封裝后的重注冊請求報文發(fā)送給P-CSCF。
步驟415P-CSCF收到UE的重注冊報文后，將IP報文中的目的端口號和步驟411中指定的UDP封裝的端口信息中的目的端口號進(jìn)行比較，如果一致，則確定該報文是UDP封裝的IPSec ESP報文，然后P-CSCF將該報文按UDP解包后交給IPSec協(xié)議棧處理，同時保存該IP報文中的源端口號，以用于向UE返回報文時進(jìn)行UDP封裝的目的端口號，并用該IP報文的源端口號更新SA中用于UDP封裝的端口信息中的源端口號，否則，按正常的IP報文進(jìn)行處理。
步驟416P-CSCF將UE的注冊報文Register發(fā)送給I-CSCF。
步驟417I-CSCF接收到所述注冊報文Register后，與HSS之間通過Cx-Query確定該UE注冊報文給哪個S-CSCF處理，即I-CSCF向HSS查詢用戶注冊報文給哪個S-CSCF處理，HSS根據(jù)保存的S-CSCF指示信息告知I-CSCF處理該用戶注冊報文的S-CSCF。
步驟418I-CSCF將注冊報文Register轉(zhuǎn)發(fā)給步驟413確定的S-CSCF。
步驟419S-CSCF與HSS之間通過Cx-Put消息，更新HSS上的S-CSCF指示信息，告知HSS該用戶后續(xù)的處理在本S-CSCF。
步驟420S-CSCF與HSS通過Cx-Pull消息獲取用戶的簽約數(shù)據(jù)信息。
步驟421S-CSCF根據(jù)所述用戶的簽約數(shù)據(jù)信息和UE注冊報文Register中的認(rèn)證參數(shù)，進(jìn)行鑒權(quán)。如果鑒權(quán)成功，S-CSCF向I-CSCF發(fā)送2xxAuth_OK消息，表示注冊成功，其中2xx表示成功相應(yīng)的消息，xx為00～99的一個數(shù)字。如果鑒權(quán)失敗，則S-CSCF向I-CSCF發(fā)送表示鑒權(quán)失敗的消息。
步驟422如果鑒權(quán)成功，I-CSCF將上述2xx Auth_OK消息發(fā)送給P-CSCF。如果鑒權(quán)失敗，則I-CSCF將上述表示鑒權(quán)失敗的消息發(fā)送給P-CSCF。
步驟423～424如果鑒權(quán)成功，P-CSCF將上述2xx Auth_OK消息采用IPSec ESP對報文進(jìn)行保護(hù)后，采用更新過的SA參數(shù)中指定的用于UDP封裝的端口進(jìn)行UDP封裝后發(fā)送給UE。如果鑒權(quán)失敗，P-CSCF可以對收到的鑒權(quán)失敗的消息采用IPSec ESP對報文進(jìn)行保護(hù)、利用步驟411中指定的用于UDP封裝端口信息進(jìn)行UDP封裝后發(fā)送給UE，也可以不進(jìn)行任何處理，結(jié)束本流程。
步驟425UE收到P-CSCF返回的報文后，將報文中的源端號/目的端口號和自身保存的SA參數(shù)中用于UDP封裝的端口信息中的端口號/源端口號進(jìn)行比較，即將報文中的源端口號和自身保存的SA參數(shù)中的用于UDP封裝的端口信息中的目的端口號進(jìn)行比較，將報文中的目的端口號和自身保存的SA參數(shù)中的用于UDP封裝的端口信息中的源端口號進(jìn)行比較，如果一致，則認(rèn)為該報文是經(jīng)過UDP封裝后的IPSec ESP報文，將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理，否則，按正常的IPSec協(xié)議處理。
步驟426此后，UE和P-CSCF之間的交互報文按步驟413和423中描述的處理方式進(jìn)行處理，同時后續(xù)UE或P-CSCF需要不斷發(fā)送NAT表項的?；顖笪?，該功能在SIP信令穿越NAT功能時也需要實現(xiàn)，兩者實現(xiàn)的方式是一致的，在此不再作進(jìn)一步描述。
從上述實施例中可以看出，在步驟413中UE將報文經(jīng)過UDP封裝后發(fā)給P-CSCF，由于源端口號經(jīng)過NAT后已可能被轉(zhuǎn)換為其它不為P-CSCF所知的端口，故只用目的端口號來進(jìn)行匹配，這種方式符合P-CSCF作為服務(wù)器端的特點，如可以對所有客戶端給定一個知名端口，標(biāo)識目的端口號為該端口的報文為UDP封裝的IPSec ESP報文。對于UE設(shè)備來說，由于只與P-CSCF有信令通道，而不會和其它設(shè)備有信令通道，則可以采用源端口和目的端口一起，或者是源端口號來進(jìn)行匹配，判斷該報文是否為UDP封裝的IPSec ESP報文，符合UE作為客戶端的特點。
參見圖5所示，UE和P-CSCF之間進(jìn)行UDP封裝時的端口變換過程如下
步驟501由于P-CSCF向UE發(fā)送的IP報文中端口號為指定的UDP封裝端口號，即(P_s，P_d)，因此UE向P-CSCF發(fā)送的經(jīng)過UDP封裝后的IP報文中的地址為(P_s，P_d)。
步驟502IP報文中的UDP端口號已經(jīng)經(jīng)過NAT轉(zhuǎn)換，變?yōu)镻_s’，NAT設(shè)備中記錄了NAT表項，故此后P-CSCF利用目的端口號P_d來識別UDP封裝報文，同時記下P_s’用于向UE發(fā)送報文的目的端口號。
步驟503當(dāng)該IP報文經(jīng)過NAT后，IP報文的源端口又轉(zhuǎn)換為P_s，故終端可以通過(P_s，P_d)，或者通過源端口號(P_s)來識別該報文是否是UDP封裝的IPSec ESP報文。
權(quán)利要求
1.一種支持網(wǎng)絡(luò)層安全穿越網(wǎng)絡(luò)地址轉(zhuǎn)換的方法，應(yīng)用于包括應(yīng)用功能AF實體的分組業(yè)務(wù)網(wǎng)絡(luò)中，其特征在于，該方法包括以下步驟A.當(dāng)AF實體收到用戶終端發(fā)送的用戶注冊請求的IP報文后，比較該IP報文頭中的源IP地址和報文負(fù)載中攜帶的用戶的IP地址是否一致，如果不一致，則確定用戶終端與AF中間有NAT設(shè)備，并向核心網(wǎng)發(fā)送用戶注冊請求的IP報文；B.當(dāng)AF實體收到核心網(wǎng)針對該用戶終端返回的鑒權(quán)響應(yīng)后，為該用戶終端指定用于用戶數(shù)據(jù)包協(xié)議UDP封裝的端口信息，并將向該用戶終端發(fā)送的鑒權(quán)響應(yīng)的IP報文的安全聯(lián)盟設(shè)置參數(shù)Security-setup頭域中增加所述用于UDP封裝的端口信息，所述端口信息包括源端口號和目的端口號；C.用戶終端收到AF實體發(fā)送的鑒權(quán)響應(yīng)的IP報文后，判斷該IP報文的Security-setup頭域中的用于UDP封裝的端口號信息是否有效，如果有效，則執(zhí)行步驟D；D.用戶終端將向所述AF實體發(fā)送的重注冊請求的IP報文進(jìn)行IPSec ESP保護(hù)，并利用收到AF發(fā)送的IP報文的Security-setup頭域中所述用于UDP封裝端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給AF，且用戶終端將AF實體發(fā)送的鑒權(quán)響應(yīng)的IP報文中所述用于UDP封裝的端口信息保存；E.AF收到用戶終端發(fā)送的重注冊請求的IP報文后，將該IP報文中的目的端口號和為該用戶終端指定的用于UDP封裝端口信息中的目的端口號進(jìn)行比較，如果一致，將該IP報文按照UDP解包后交給IPSec協(xié)議棧處理，并且保存該IP報文中的源端口號，更新自身保存的用戶UDP封裝端口信息中的源端口號；F.當(dāng)AF實體收到核心網(wǎng)針對該用戶終端返回的鑒權(quán)響應(yīng)后，AF實體將向用戶終端發(fā)送的鑒權(quán)響應(yīng)的IP報文進(jìn)行IPSec ESP保護(hù)并利用所述更新過的用于UDP封裝端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給該用戶終端；G.該用戶終端收到AF返回的鑒權(quán)響應(yīng)的IP報文后，將該IP報文的地址/端口與自身保存的用于UDP封裝的端口信息進(jìn)行比較，判斷出該報文是否是UDP封裝的IPSec報文，如果是，則將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟G中判斷出該報文是否是UDP封裝的IPSec報文步驟包括將該IP報文中的源端號與自身保存的用于UDP封裝的目的端口號進(jìn)行比較，如果一致，則該報文是UDP封裝的IPSec報文，否則，該報文不是UDP封裝的IPSec報文。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟G中判斷出該報文是否是UDP封裝的IPSec報文步驟包括步驟G中在將該IP報文中的源端號與自身保存的用于UDP封裝的目的端口號進(jìn)行比較，以及將該IP報文中目的端口號和自身保存的用于UDP封裝的源端口號進(jìn)行比較，如果都一致，則該報文是UDP封裝的IPSec報文，否則，該報文不是UDP封裝的IPSec報文。
4.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟G中判斷出該報文是否是UDP封裝的IPSec報文步驟包括將該IP報文中目的端口號和自身保存的用于UDP封裝的源端口號進(jìn)行比較，如果一致，則該報文是UDP封裝的IPSec報文，否則，該報文不是UDP封裝的IPSec報文。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，當(dāng)用戶終端有向AF發(fā)送的IP報文時，用戶終端將向所述AF實體發(fā)送的IP報文進(jìn)行IPSec ESP保護(hù)后，利用收到的AF發(fā)送的IP報文的Security-setup頭域中自身保存的用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給AF；AF收到用戶終端發(fā)送的IP報文后，將該IP報文中的目的端口號和為該用戶終端指定的用于UDP封裝端口信息中的目的端口號進(jìn)行比較，如果一致，將該IP報文按照UDP解包后交給IPSec協(xié)議棧處理，并用該報文中的源端口號更新自身保存的用于UDP封裝端口信息中的源端口號。
6.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中進(jìn)一步包括將該為該用戶終端指定的用于UDP封裝的端口信息保存，則在步驟G之后進(jìn)一步包括當(dāng)AF實體中有向該用戶終端發(fā)送的IP報文時，AF實體將該IP報文進(jìn)行IPSec ESP保護(hù)并利用所述用于UDP封裝的端口信息對該IP報文進(jìn)行UDP封裝后發(fā)送給該用戶終端；該用戶終端收到來自AF的IP報文后，將該IP報文中的源端口號與自身保存的用于UDP封裝端口信息中目的端口號進(jìn)行比較，并且將該IP報文中目的端口號和自身保存用于UDP封裝端口信息中的源端口號進(jìn)行比較，如果都一致，則說明該報文是UDP封裝的IPSec報文，將報文經(jīng)過UDP解包后，交給IPSec協(xié)議棧處理。
7.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中進(jìn)一步包括AF實體保存為該用戶終端指定的所述用于UDP封裝的端口信息，則步驟E中所述為該用戶終端指定的用于UDP封裝端口信息中的目的端口號是從自身保存的為該用戶終端指定的所述UDP封裝的端口信息中獲得；當(dāng)AF收到用戶終端發(fā)過來的UDP封裝的IPSec報文后，用該報文中的源端口號更新自身保存的用于UDP封裝的端口信息中的源端口號。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述AF實體為P-CSCF。
9.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述報文負(fù)載中攜帶的用戶的IP地址/端口信息為該IP報文中的Contact地址或Via頭域中記錄的用戶域名地址。
10.根據(jù)權(quán)利要求1所述的方法，其特征在于，在步驟G之后進(jìn)一步包括用戶終端/AF定期向AF/用戶終端發(fā)送NAT?；顖笪?，所述NAT設(shè)備根據(jù)該保活報文更新自身的NAT表項。
11.根據(jù)權(quán)利要求1所述的方法，其特征在于，為所有用戶終端指定的用于UDP封裝端口信息中的目的端口號相同。
12.根據(jù)權(quán)利要求1所述的方法，其特征在于，在步驟D包括用戶終端在向AF發(fā)送的重注冊請求的IP報文中攜帶AF下發(fā)的用于UDP封裝的端口信息，則步驟E中進(jìn)一步包括AF收到用戶終端發(fā)送的重注冊請求的IP報文后，判斷自身下發(fā)給該用戶終端的用于UDP封裝的端口信息與重注冊請求的IP報文中攜帶的用于UDP封裝的端口信息是否一致，如果一致，則認(rèn)為下發(fā)給用戶終端的響應(yīng)的IP報文沒有被篡改，否則，認(rèn)為下發(fā)給用戶終端的響應(yīng)的IP報文被篡改。
全文摘要
本發(fā)明公開了一種支持網(wǎng)絡(luò)層安全穿越網(wǎng)絡(luò)地址轉(zhuǎn)換的方法，應(yīng)用于包括應(yīng)用功能實體(AF)的分組業(yè)務(wù)網(wǎng)絡(luò)中，當(dāng)AF收到用戶終端(UE)首次發(fā)送的注冊請求后，為該UE指定用于UDP封裝的端口號信息，將該端口號信息作為SA參數(shù)保存，并將該端口號信息發(fā)送給UE，UE向AF發(fā)送的經(jīng)過IPSec保護(hù)后的IP報文進(jìn)行UDP封裝處理，AF利用UDP封裝端口信息的目的端口號對UDP封裝的IPSec報文進(jìn)行識別，同時采用收到的報文的源端口號更新自身保存的用于UDP封裝端口信息的源端口號；當(dāng)AF有向UE發(fā)送的IP報文時，AF利用自身保存的用于UDP封裝的端口信息對經(jīng)過IPSec保護(hù)的IP報文進(jìn)行UDP封裝，UE采用自身保存的用于UDP封裝的端口信息識別UDP封裝的IPSec報文。本發(fā)明對現(xiàn)有IMS AKA的改動小，容易實現(xiàn)。
文檔編號H04L12/66GK1893391SQ200510081580
公開日2007年1月10日 申請日期2005年7月5日 優(yōu)先權(quán)日2005年7月5日
發(fā)明者嚴(yán)軍 申請人:華為技術(shù)有限公司