




摘 要:隨著網絡技術的迅速發展,組播作為一種高效的數據傳輸方式,正在得到越來越廣泛的應用,人們對其安全性的重視程度也越來越高。IPsec作為一種擁有很高實用性和可靠性的協議,越來越受企業和個人用戶的歡迎。文章首先介紹了IPsec對等部署方案、無GCKS的組播密鑰管理結構和對端網關發現機制,然后基于對端網關發現機制提出了一種適用于IPsec對等部署方案的對端組播IPsec發現機制,最后討論了發現報文在實網中的路由問題并提出了解決方案。
關鍵詞:IPsec;對等部署;網關發現;組播IPsec發現
中圖分類號:TN915.04 文獻標識碼:A 文章編號:2096-4706(2024)15-0006-04
End-to-End Multicast IPsec Discovery Mechanism for Peer-to-Peer Deployment Scheme Based on IPsec
GAO Yangyang, YI Heng, ZHOU Huaming
(The 30th Institute of CETC, Chengdu 610041, China)
Abstract: With the development of network technology, multicast, as an efficient data transmission method, is being used more and more widely, and people are paying more and more attention to its security. IPsec, as a protocol with high practicality and reliability, is becoming more and more popular among enterprises and individual users. This paper first introduces the IPsec peer-to-peer deployment scheme, the multicast key management structure without GCKS, and the end-to-end gateway discovery mechanism. Then, based on the end-to-end gateway discovery mechanism, it proposes an end-to-end multicast IPsec discovery mechanism suitable for the IPsec peer-to-peer deployment scheme. Finally, it discusses the routing problem of discovery packets in the real network and proposes a solution.
Keywords: IPsec; peer-to-peer deployment; gateway discovery; multicast IPsec discovery
0 引 言
隨著互聯網的普及和信息安全的重要性日益凸顯,越來越多的組織和個人開始關注網絡安全的問題。在數據傳輸過程中,用戶都希望能夠確保數據的安全性。為了實現這一目標,眾多的加密技術被應用于網絡通信中。作為保障網絡通信安全的重要技術之一,IPsec(Internet Protocol Security)在企業和個人用戶中越來越受歡迎。它擁有很高的實用性和可靠性,是一種用于確保網絡數據傳輸安全的協議,通過加密和認證技術,保障數據的機密性、完整性和可用性[1-2]。
在實際應用中,根據不同的需求,IPsec可以選擇不同的部署方案,包括單機部署、網關部署以及對等部署。其中對等部署是一種適應于多個節點之間通信的部署方案。在這種方案下,多個節點(可能是計算機、服務器、路由器或其他網絡設備)之間建立IPsec連接,用于保護彼此之間的通信。對等部署方案有以下幾個優點:1)靈活性和可擴展性。通過在每個節點上部署IPsec,可以根據實際需要動態調整網絡的拓撲和通信路徑。2)成本效益。對等部署充分利用了網絡設備的資源,每臺設備都負責自己的IPsec配置和管理,不需要額外的設備來充當網關,節省了硬件資源和成本。3)互通性強。對等模式可以連接不同廠商的設備,提高更大的互通性。這對于跨越不同的網絡或組織進行安全通信非常重要。
針對一對多或者多對多的應用場景,IETF提出了IP組播通信模型,并且為了使IPsec的安全特性能適用于組播,IETF制定了IPsec安全組播管理協議GDOI[3]。RFC4046中定義的組密鑰管理結構包括:組播發送方IPsec VPN、組播接收方IPsec VPN、組控制器和密鑰服務器(Group Controller and Key Server, GCKS)。GCKS負責密鑰的生成、分配以及更新[4]。該架構要求網絡中所有IPsec VPN支持GDOI協議并且在現有的網絡中部署GCKS比較困難。
為了解決現有網絡中部署GCKS遇到的困難,組播源IPsec替代GCKS角色的組播加密方案被提出。該方案中組播密鑰管理結構由2種實體組成:組播發送方IPsec VPN、組播接收方IPsec VPN。方案實現的基本思路為:階段1組播發送方IPsec VPN與組播接收方IPsec VPN產生階段2協議交互的保護密鑰。階段2利用階段1產生的保護密鑰在組播接收方IPsec建立為特定的組播組建立密鑰更新SA和(或)數據安全SA[5-6]。
1 對端網關發現機制
因特網安全關聯密鑰管理協議(Internet Security Association Key Management Protocol, ISAKMP)、因特網密鑰交換協議[7](Internet Key Exchange, IKE)定義了兩個安全網關之間如何協商安全聯盟 (Security Association, SA),但是它們都沒有關于發起者網關如何找到對端網關的描述。這也就導致了傳統的IPsec隧道建立必須預先知道對端網關的IP地址。這種方法很大程度上限制了隧道建立的靈活性。于是FreeS/WAN 項目提出了一種在VPN 連接時動態認證對方的方法——機會加密(Opportunistic Encryption, OE)。
OE是用DNS服務器代替CA,雙方把自己的公鑰放在DNS服務器上,連接的時候進行反向DNS查詢(依靠IP地址查找域名信息,獲取對端安全網關的地址和公鑰信息)實現密鑰交換并建立加密通道,公鑰的合法性靠DNS服務器來保證。相對于證書/CA的方法,OE較簡單且更容易實現。為了保證安全,DNS實際操作時使用DNSSEC。之后,Cisco提出了一種隧道自動建立機制——隧道端點發現[8](Tunnel Endpoint Discover, TED),它基于標準路由協議。通過它可以實現IPsec安全網關的動態發現。
TED機制使用固有的路由協議來發現需要保護的通信的對端網關。發現遠端網關的具體步驟如下:圖1為一個安全網關保護的網絡拓撲圖。圖中有A、B、C三個節點,三個安全網關SG_A、SG_B、SG_C。
1)A發送一個數據包到B。當IP數據包路由到SG_A時,SG_A上的IPsec策略指出到B的數據包需要進行加密處理,但是沒有和此相關的SA。
2)SG_A發送TED探測報文,報文的源地址為SG_A,目的地址為B。
3)TED探測報文被SG_B所截獲。SG_B根據報文的源和目的地址進行SPD查找,從而確定該源地址和目的地址間的通信是否需要受到保護。同時發現B是受自己保護的。于是,SG_B發送一個TED響應報文。
4)當SG_A收到TED響應后,它讀取響應報文中的載荷,從而得到對端IKE實體(SG_B)的IP地址。
2 對端組播IPsec發現機制
OE和TED兩種發現機制共同點:一是都只適用于單播,二是發現的對象為網關部署方案中的網關,兩種機制都未對組播進行說明。在無GCKS的組播加密方案中,本文基于對端網關發現機制提出了一種適用于對等部署方案的對端組播IPsec發現機制——組播末端發現(Multicast Endpoint Discovery, MED)。
2.1 MED的基本原理
如圖2所示為MED報文交互流程,具體的步驟如下。
首先,組播源IPsec(Ipsec_send)獲取MED發現報文的目的地址(即業務組播地址mul_ip),方法有以下兩種:1)通過組播業務數據包獲取,具體方法為:組播源(mul_send)發送組播地址為mul_ip的數據包,該報文經過網絡設備路由到Ipsec_send后,Ipsec_send根據業務數據包信息查詢相應的IPsec安全策略。如果安全策略指出該業務需進行加密處理,那么Ipsec_send可根據組播業務數據包獲取其中的mul_ip。2)通過Ipsec_send上配置的安全策略獲取,具體方法為:Ipsec_send遍歷IPsec安全策略中需要對組播業務進行加密處理的安全策略,獲取策略中的組播地址mul_ip。
然后,Ipsec_send根據獲取到的組播地址mul_ip構造MED發現報文,該報文為IKE消息。消息報文格式如圖3所示為UDP報文。其中,以太網頭中源MAC地址設置為Ipsec_send的MAC地址,目的MAC地址設置為mul_ip對應的組播MAC地址。以太網類型根據Ipsec_send部署環境而定(例如:部署在Trunk環境時以太網類型為0x8100-VLAN協議;部署在一般二、三層環境時以太網類型為0x0800-IP協議)。IP頭中的源IP地址設置為Ipsec_send的IP地址,目的IP地址設置為mul_ip,協議設置為17(UDP協議),源端口號和目的端口號設為500,載荷部分包含Ipsec_send的IP信息。
當出現用戶主機通過IGMP加入組播組時,MED發現報文可經過路由設備路由到組播接收IPsec(Ipsec_recv)。由于組播為廣播業務,Ipsec_recv收到MED發現報文說明保護的節點中有節點想要收到該組播業務,故該通信需要受到保護。于是Ipsec_recv發送一個MED響應報文。響應報文的格式和請求報文格式類似,不同的是響應報文為單播報文,以太網頭中源MAC地址設置為Ipsec_recv的MAC地址,目的MAC地址設置為外網網關MAC地址(如果是二層環境目的地址設置為Ipsec_send的MAC地址)。以太網類型根據Ipsec_recv部署環境而定(例如:部署在Trunk環境時以太網類型為0x8100-VLAN協議;部署在一般二、三層環境時以太網類型為0x0800-IP協議)。IP頭中的源地址設置為Ipsec_recv的地址,目的地址設置為Ipsec_send的地址,協議設置為17(UDP協議),源端口號和目的端口號設為500。響應報文構造完成后發出,經過路由設備到達Ipsec_send時被截獲,Ipsec_send收到應答報文后,獲取載荷中的載荷信息(對端組播IPsec地址)。
MED發現報文交互流程完成后可實現以下功能:
1)對端組播IPsec發現。Ipsec_send收到應答報文,獲取報文中的地址載荷,從而得到Ipsec_recv的地址。之后,Ipsec_send和Ipsec_recv可以進行正常IKE通信,建立用來保護建立密鑰更新SA和數據安全SA過程中協議交互的SA,以及密鑰更新SA和數據安全SA。如果Ipsec_send和Ipsec_recv均未配置組播業務相對應的IPsec安全策略,但缺省情況下對組播業務進行加密處理時,還可以通過IPsec SA協商過程中添加載荷來自動建立組播IPsec安全策略。
2)檢測對端組播IPsec的動態加入、動態替換、動態撤離。Ipsec_send定時發送MED發現報文,當網絡中有新的組成員出現(用戶主機通過發送IGMP報告通知路由器要加入某組播組G)時,發現報文通過路由設備可以轉發到Ipsec_recv。
如果Ipsec_recv在線,經過MED發現報文的交互,Ipsec_send可以獲取到它的相關信息。Ipsec_send查看自己的成員列表,如果無該成員信息,證明該Ipsec_recv為新加入成員,則將其添加到成員列表中。如果Ipsec_send的成員列表中存在Ipsec_recv信息,但已有信息與應答報文中的信息不一致,說明該成員發生過替換。Ipsec_send更新成員列表中成員信息。考慮到前向安全,Ipsec_send檢測到有成員動態加入或動態替換的情況時發起密鑰更新,同時將更新后的密鑰發送給當前所有Ipsec_recv。
如果某Ipsec_recv不在線,那么Ipsec_send在發送n次MED發現報文后未收到它的MED應答報文,則認為該Ipsec_recv動態撤離。考慮到后向安全,Ipsec_send發起密鑰更新,同時將更新后的密鑰發送給當前所有Ipsec_recv。
2.2 發現報文的路由問題
PIM-DM(密集模式)假設網絡中的所有主機都對接收組播流量感興趣。當路由器接收到組播流量并通過RPF檢查后,它將復制并向其所有PIM鄰居發送流量。因此,它默認向所有下游接口轉發組播流量。然如果沒有接收者的分支,PIM密集模式通過主動報告或超時機制發起剪枝[9]。之后讓新加入的組成員快速得到組播報文是通過嫁接機制實現的。葉子路由器通過IGMP報文獲取與其相連的用戶網段上組播組G有新的組成員加入。隨后葉子路由器會向上游發送Graft報文,請求上游路由器恢復相應出接口轉發,將其添加在(S,G)表項下游接口列表中,之后組播組G的組播會被路由設備轉發到新的組成員。
PIM-SM網絡中ASM(Any-Source Multicast)模型,當用戶主機通過IGMP報告加入某組播組G時,組成員端DR向RP發送Join報文,在通向RP的路徑上逐跳創建(*,G)表項,生成一棵以RP為根的RPT[9]。組播源將組播報文發送給路由設備(源端DR)。路由設備收到后將其封裝在Register報文中發送給RP。RP接收到Register報文,將其解封裝,建立(S,G)表項,并將組播數據沿RPT發送到達組成員[10]。
PIM-SM網絡中SSM(Any-Source Multicast)模型,用戶主機通過IGMPv3報告告知路由器要接收從哪些源地址發往組播組的數據。組成員端DR收到用戶主機的IGMPv3報告后,直接向組播源端的DR路由設備發送Join報文。Join報文逐跳向上傳輸,在源與組成員之間建立SPT,無須維護RP、構建RPT、注冊組播源。
如圖4所示,組播接收IPsec部署在葉子路由器內側。由上述組播轉發機制可知:PIM-DM網絡和PIM-SM網絡中ASM(Any-Source Multicast)模型環境下,組播成員Host通過IGMP加入某組播組G時,組播源IPsec發出的MED發現報文可以通過路由設備轉發到組播接收IPsec。PIM-SM網絡中SSM(Any-Source Multicast)模型下,組播成員Host僅向葉子路由器R3發送IGMPv3報告(G,INCLUDE,(S)),告知路由器只接收源地址S發往組播組G的數據,故源地址為S1的MED發現報文無法被組播接收IPsec接收到。
如圖5所示,組播接收IPsec部署在葉子路由器和中間路由器之間。由上述轉發機制可知:PIM-DM網絡和PIM-SM網絡中ASM(Any-Source Multicast)模型環境下,組播成員Host通過IGMP加入某組播組G時,組播源IPsec發出的MED發現報文可以通過路由設備轉發到組播接收IPsec。PIM-SM網絡中SSM(Any-Source Multicast)模型下,組播接收Host僅向葉子路由器R3發送IGMPv3報告(G,INCLUDE,(S)),告知路由器只接收源地址S發往組播組G的數據,故源地址為S1的MED發現報文無法被組播接收IPsec接收。
綜上所述:MED發現報文在PIM-SM網絡中SSM(Any-Source Multicast)模型下存在路由問題。
2.3 解決方案
方法一:由組播成員Host向葉子路由器R3發送IGMPv3報告(G,INCLUDE,(S1)),告知路由器要接收來自源地址S1發往組播組G的組播數據。這樣,MED發現報文就會被路由設備轉發到組播接收Host,從而能被組播接收IPsec攔截完成MED報文交互流程。
方法二:組播接收IPsec定時發送IGMPv3報告(G,INCLUDE,(S1))。如圖4所示,組播接收IPsec部署在葉子路由器內側。組播接收IPsec定時向R3發送IGMPv3報告(G,INCLUDE,(S1)),告知路由器要接收來自源地址S1發往組播組G的組播數據。如圖5所示,組播接收IPsec部署在葉子路由器和中間路由器之間。首先,配置路由器R2的port1端口使能IGMPv3功能;其次組播接收IPsec定時向R2發送IGMPv3報告(G,INCLUDE,(S1)),告知路由器要接收來自源地址S1發往組播組G的組播數據。然后配置R2、R3地址或優先級使R2選舉為DR。原因是:組播接收IPsec部署在中間路由器R2和葉子路由器R3之間的級聯網段上,R2和R3都啟用PIM協議,為了爭取在該網段中唯一的組播報文轉發權,R2和R3之間就需要通過交互Hello報文進行DR競選。競選時,首先比較Hello報文中攜帶的DR優先級,優先級大的獲勝;如果優先級相同或者一方的Hello報文中未攜帶優先級,那么IP地址大的獲勝。如果R3競選為DR,由上述PIM-SM網絡中SSM模型下組播轉發機制可知,組播接收IPsec通過IGMPv3加入組播組,指定從S1接收信息,組成員端DR(路由器R3)無法了解到組播接收IPsec的需求,從而無法向源端DR發送Join報文,導致MED發現報文路由出現問題。
3 結 論
本文基于無GCKS的組播加密方案,針對IPsec對等部署模式提出了一種對端組播IPsec發現機制,該機制不僅能發現對端組播IPsec,動態建立IPsec隧道,還能實時檢測對端組播IPsec的動態加入、動態更換、動態撤離。
參考文獻:
[1] 郭慧.IPSec的NAT穿越技術應用 [J].自動化應用,2024,65(10):282-284.
[2] 王格.基于網絡仿真平臺的GRE over IPsec VPN設計與實現 [J].信息記錄材料,2024,25(1):169-171.
[3] 姜鵬博,王綱領,康彬,等.基于GDOI的特定源組播加密方案 [J].通信技術,2021,54(7):1726-1733.
[4] 李旭陽.軟件定義網絡組播安全機制的設計與實現 [D].北京:北京交通大學,2020.
[5] 張坤銀.基于IPSec技術的可變情報板信息發布安全加密系統 [J].中國交通信息化,2023(6):126-129.
[6] 黃懷霖,常安,何玨,等.基于IPSec的網絡數據安全傳輸模型設計 [J].電子設計工程,2023,31(13):137-140+145.
[7] 楊文祺.基于IKE的IPSec技術在軟件定義切片網絡中的安全應用 [D].武漢:華中科技大學,2019.
[8] FLUHRER S. Tunnel Endpoint Discovery [M].Cisco Systems,2001.
[9] 紀偉瀟.SDN組播路由跳變防御方法研究與系統實現 [D].北京:北京郵電大學,2023.
[10] 張成,吳明曦,劉小娟,等.基于VxWorks的PIM-SM協議的改進設計 [J].通信技術,2023,56(12):1383-1389.
作者簡介:高洋洋(1989—),男,漢族,河南許昌人,工程師,碩士,研究方向:網絡安全;易恒(1990—),男,漢族,四川成都人,工程師,碩士,研究方向:網絡安全;周華明(1989—),男,漢族,四川綿陽人,助理工程師,學士,研究方向:網絡安全。