定義

IPSec是Internet工程任務(wù)組（IETF）制定的一個(gè)開放的網(wǎng)絡(luò)層安全框架協(xié)議。它并不是一個(gè)單獨(dú)的協(xié)議，而是一系列為IP網(wǎng)絡(luò)提供安全性的協(xié)議和服務(wù)的集合。IPSec主要包括安全協(xié)議AH（Authentication Header）和ESP（Encapsulating Security Payload），密鑰管理交換協(xié)議IKE（Internet Key Exchange）以及用于網(wǎng)絡(luò)認(rèn)證及加密的一些算法等。

目的

在IPv4協(xié)議誕生之時(shí)，Internet網(wǎng)絡(luò)的規(guī)模還非常小，Internet網(wǎng)絡(luò)的安全完全可以通過物理隔離的方式來保證。另一方面，所有人都未預(yù)料到以后Internet網(wǎng)絡(luò)會(huì)爆炸式的增長(zhǎng)，所以在設(shè)計(jì)和開發(fā)IPv4協(xié)議時(shí)，沒有考慮IPv4協(xié)議的安全保護(hù)手段。

由于IP報(bào)文本身并不集成任何安全特性，惡意用戶很容易便可偽造IP報(bào)文的地址、修改報(bào)文內(nèi)容、重播以前的IP數(shù)據(jù)包以及在傳輸途中攔截并查看數(shù)據(jù)包的內(nèi)容。因此，傳統(tǒng)IP層協(xié)議不能擔(dān)保收到的IP數(shù)據(jù)包的安全。在應(yīng)用層保證網(wǎng)絡(luò)安全的方法只對(duì)特定的應(yīng)用有效，不夠通用。人們迫切需要能夠在IP層提供安全服務(wù)的協(xié)議，這樣可以使TCP/IP高層的所有協(xié)議受益。IPSec（Internet Protocol Security）正是用來解決IP層安全性問題的技術(shù)。

IPSec主要通過加密與驗(yàn)證等方式，為IP數(shù)據(jù)包提供安全服務(wù)。IPSec可以提供的安全服務(wù)包括：

• 數(shù)據(jù)加密通過數(shù)據(jù)加密提供數(shù)據(jù)私密性。
• 數(shù)據(jù)源驗(yàn)證通過對(duì)發(fā)送數(shù)據(jù)的源進(jìn)行身份驗(yàn)證，保證數(shù)據(jù)來自真實(shí)的發(fā)送者。
• 防止數(shù)據(jù)重放通過在接收方拒絕重復(fù)的數(shù)據(jù)包防止惡意用戶通過重復(fù)發(fā)送捕獲到的數(shù)據(jù)包進(jìn)行攻擊。

受益

IPSec具有以下優(yōu)點(diǎn)：

• 所有使用IP協(xié)議進(jìn)行協(xié)議報(bào)文傳輸?shù)膽?yīng)用系統(tǒng)和服務(wù)都可以使用IPsec，而不必對(duì)這些應(yīng)用系統(tǒng)和服務(wù)本身做任何修改。
• 對(duì)協(xié)議報(bào)文的加密是以數(shù)據(jù)包為單位的，而不是以整個(gè)數(shù)據(jù)流為單位，這不僅靈活而且有助于進(jìn)一步提高協(xié)議報(bào)文的安全性，可以有效防范網(wǎng)絡(luò)攻擊。

運(yùn)營(yíng)商場(chǎng)景

 

點(diǎn)到點(diǎn)VPN（Site-to-Site VPN）

IPSec可以為任何基于IP的通信提供安全保護(hù)，既可以保護(hù)傳統(tǒng)的固定網(wǎng)絡(luò)，也可以保護(hù)LTE等移動(dòng)網(wǎng)絡(luò)。

點(diǎn)到點(diǎn)VPN也稱網(wǎng)關(guān)到網(wǎng)關(guān)VPN（Gateway to Gateway VPN），可以保證兩個(gè)網(wǎng)關(guān)之間IP流量的安全性。典型組網(wǎng)如圖1所示。圖1 點(diǎn)到點(diǎn)VPN組網(wǎng)

 

點(diǎn)到點(diǎn)VPN部署非常靈活，而且當(dāng)兩個(gè)IPSec網(wǎng)關(guān)之間存在NAT設(shè)備時(shí)，支持IPSec NAT穿越。

企業(yè)場(chǎng)景

 

企業(yè)場(chǎng)景里IPSec主要用于公司之間通過IPSec VPN網(wǎng)絡(luò)互連，典型應(yīng)用是點(diǎn)到點(diǎn)VPN。企業(yè)場(chǎng)景里IPSec的組網(wǎng)更加靈活多樣。

點(diǎn)到點(diǎn)VPN（Site-to-Site VPN）

點(diǎn)到點(diǎn)VPN主要用于公司總部與分支機(jī)構(gòu)之間建立IPSec隧道，從而實(shí)現(xiàn)局域網(wǎng)之間互通。典型組網(wǎng)如圖1所示。圖1 點(diǎn)到點(diǎn)VPN組網(wǎng)

 

點(diǎn)到多點(diǎn)VPN（Hub-Spoke VPN）

實(shí)際組網(wǎng)中最常見的是公司總部與多個(gè)分支機(jī)構(gòu)通過點(diǎn)到多點(diǎn)IPSec VPN互通，典型組網(wǎng)如圖2所示。圖2 Hub-Spoke VPN組網(wǎng)

 

在這種組網(wǎng)中，用戶可以根據(jù)實(shí)際需求配置IPSec。

此時(shí)網(wǎng)絡(luò)內(nèi)數(shù)據(jù)流量可能存在如下兩種情況：

• 各分支機(jī)構(gòu)之間不需要通信只有總部和分支之間部署IPSec VPN，也只有總部和分支之間存在業(yè)務(wù)流量。如圖3所示。圖3 Hub-Spoke VPN組網(wǎng)應(yīng)用一
• 各分支機(jī)構(gòu)之間需要通信分支機(jī)構(gòu)之間通過總部進(jìn)行通信，如圖4所示。圖4 Hub-Spoke VPN組網(wǎng)應(yīng)用二

分支機(jī)構(gòu)用戶上網(wǎng)控制

在點(diǎn)到點(diǎn)或點(diǎn)到多點(diǎn)VPN中，分支機(jī)構(gòu)用戶上網(wǎng)可以通過兩種方式來實(shí)現(xiàn)。

• 分支機(jī)構(gòu)用戶通過總部接入Internet為進(jìn)行統(tǒng)一管理和監(jiān)控，分支機(jī)構(gòu)用戶不允許通過自身的網(wǎng)關(guān)接入Internet，只能通過VPN接入到總部，然后通過總部訪問Internet。分支訪問Internet的流量一般需要在總部做NAT才能到公網(wǎng)。如圖5所示。圖5 分支機(jī)構(gòu)用戶通過總部接入Internet
• 分支機(jī)構(gòu)用戶自行接入Internet對(duì)分支機(jī)構(gòu)的上網(wǎng)流量不做控制，如圖6所示。圖6 分支機(jī)構(gòu)用戶自行接入Internet

安全協(xié)議

 

IPSec通過AH（Authentication Header，驗(yàn)證頭）和ESP（Encapsulating Security Payload，封裝安全載荷）兩個(gè)安全協(xié)議實(shí)現(xiàn)IP報(bào)文的封裝/解封裝。

• AH是報(bào)文頭驗(yàn)證協(xié)議，主要提供數(shù)據(jù)源驗(yàn)證、數(shù)據(jù)完整性驗(yàn)證和防報(bào)文重放功能，不提供加密功能。
• ESP是封裝安全載荷協(xié)議，主要提供加密、數(shù)據(jù)源驗(yàn)證、數(shù)據(jù)完整性驗(yàn)證和防報(bào)文重放功能。

雖然AH協(xié)議和ESP協(xié)議都可以提供數(shù)據(jù)源驗(yàn)證和數(shù)據(jù)完整性校驗(yàn)服務(wù)，但是兩者不能互相取代。兩者之間的差別在于驗(yàn)證報(bào)文的范圍不同，驗(yàn)證范圍請(qǐng)參見封裝模式。

AH和ESP協(xié)議的簡(jiǎn)單比較如表1所示。

 

從上表中可以看出兩個(gè)協(xié)議各有優(yōu)缺點(diǎn)，AH協(xié)議不提供數(shù)據(jù)加密功能，ESP的驗(yàn)證范圍不包括IP頭，其安全性不如AH，故在安全性要求較高的場(chǎng)景中可以考慮聯(lián)合使用AH協(xié)議和ESP協(xié)議。AH協(xié)議和ESP協(xié)議聯(lián)合使用時(shí)，需要先使用ESP，這是因?yàn)锳H對(duì)整個(gè)IP數(shù)據(jù)報(bào)文進(jìn)行認(rèn)證，如果先使用AH再使用ESP，ESP的頭和尾會(huì)改變數(shù)據(jù)報(bào)文的長(zhǎng)度，而且ESP的填充字段也會(huì)改變數(shù)據(jù)報(bào)文的長(zhǎng)度，造成AH認(rèn)證失敗。

封裝模式

 

目前NE支持隧道模式。

隧道模式

隧道模式的報(bào)文格式如圖1所示。在隧道模式下，原始IP數(shù)據(jù)報(bào)文被封裝成一個(gè)新的IP數(shù)據(jù)報(bào)文，并在舊IP報(bào)文頭（圖1中的IP Header）和新IP報(bào)文頭（圖1中的New IP Header）之間插入一個(gè)IPSec報(bào)文頭（AH或ESP），原IP地址被當(dāng)作有效載荷的一部分受到IPSec的安全保護(hù)。圖1 隧道模式的報(bào)文格式

 

隧道模式隱藏了原始IP報(bào)文頭信息，因此主要應(yīng)用于兩臺(tái)VPN網(wǎng)關(guān)之間或一臺(tái)主機(jī)與一臺(tái)VPN網(wǎng)關(guān)之間的通信。

隧道模式下，AH協(xié)議的完整性驗(yàn)證范圍為包括新增IP頭在內(nèi)的整個(gè)IP報(bào)文。ESP協(xié)議驗(yàn)證報(bào)文的完整性檢查部分包括ESP頭、原IP頭、傳輸層協(xié)議頭、數(shù)據(jù)和ESP尾，但不包括新IP頭，因此ESP協(xié)議無法保證新IP頭的安全。ESP的加密部分包括傳輸層協(xié)議頭、數(shù)據(jù)和ESP尾。

當(dāng)安全協(xié)議同時(shí)采用AH和ESP時(shí)，AH和ESP協(xié)議必須采用相同的封裝模式。

加密算法

 

加密是一種將數(shù)據(jù)從明文轉(zhuǎn)換成無法讀懂的密文的過程，接收方只有在擁有正確的密鑰的情況下才能對(duì)密文進(jìn)行解密，從而保證了數(shù)據(jù)的私密性。

IPSec VPN工作過程中涉及數(shù)據(jù)加密（IP報(bào)文加密）和協(xié)議消息加密（ISAKMP消息加密）兩種情況。

數(shù)據(jù)加密

ESP能夠?qū)P報(bào)文內(nèi)容進(jìn)行加密保護(hù)，以防止IP報(bào)文內(nèi)容在傳輸過程中被窺探。IPSec采用對(duì)稱加密算法對(duì)數(shù)據(jù)進(jìn)行加密和解密。對(duì)稱加密算法是指數(shù)據(jù)發(fā)送方和接收方使用相同的密鑰進(jìn)行加密、解密。

采用對(duì)稱加密算法進(jìn)行數(shù)據(jù)加密和解密的過程如圖1所示。圖1 加密和解密的過程

 

用于加密的對(duì)稱密鑰可以手工配置，也可以通過DH算法生成并在兩端設(shè)備共享。有關(guān)DH算法具體能夠生成哪些密鑰及密鑰的作用請(qǐng)參見IKEv1 Phase-1 Negotiation。

一般來說IPSec使用以下加密算法：

• DES（Data Encryption Standard）：使用64bit的密鑰對(duì)一個(gè)64bit的明文塊進(jìn)行加密。
• 3DES（Triple Data Encryption Standard）：使用三個(gè)64bit的DES密鑰（共192bit密鑰）對(duì)明文形式的IP報(bào)文進(jìn)行加密。
• AES-CBC-128（Advanced Encryption Standard Cipher Block Chaining 128）：使用128bit加密算法對(duì)IP報(bào)文進(jìn)行加密。
• AES-CBC-192（Advanced Encryption Standard Cipher Block Chaining 192）：使用192bit加密算法對(duì)IP報(bào)文進(jìn)行加密。
• AES-CBC-256（Advanced Encryption Standard Cipher Block Chaining 256）：使用256bit加密算法對(duì)IP報(bào)文進(jìn)行加密。

3DES比DES安全得多，但是其加密速度慢于DES。AES比3DES更安全。

協(xié)議消息加密

協(xié)議消息加密用于IKE協(xié)商階段。協(xié)議消息加密所用的算法也是DES、3DES和AES。用于加密的對(duì)稱密鑰通過DH算法生成。有關(guān)DH算法具體能夠生成哪些密鑰及密鑰的作用請(qǐng)參見IKEv1 Phase-1 Negotiation。

認(rèn)證算法

 

IPSec采用Hmac（Keyed-Hash Message Authentication Code）功能進(jìn)行認(rèn)證。HMAC是HASH函數(shù)（單向散列函數(shù)）和消息認(rèn)證碼MAC（Message Authentication Code）的結(jié)合，HMAC利用Hash函數(shù)，以一個(gè)對(duì)稱密鑰和一個(gè)數(shù)據(jù)包作為輸入，生成一個(gè)固定長(zhǎng)度的輸出，這個(gè)輸出被稱為完整性校驗(yàn)值ICV（Integrity Check Value）。接收方通過比較自身生成的ICV和對(duì)端發(fā)送的ICV來判斷數(shù)據(jù)的完整性和真實(shí)性。

數(shù)據(jù)源驗(yàn)證和數(shù)據(jù)完整性驗(yàn)證統(tǒng)一被稱為驗(yàn)證。因?yàn)檫@兩種安全服務(wù)總是綁定在一起提供的。數(shù)據(jù)完整性驗(yàn)證是基于每個(gè)IP數(shù)據(jù)包進(jìn)行計(jì)算；將完整性驗(yàn)證密鑰同IPSec對(duì)端身份綁定的結(jié)果間接提供了數(shù)據(jù)源驗(yàn)證。

雖然加密后的數(shù)據(jù)只能通過原始的加密密鑰進(jìn)行解密，但是無法驗(yàn)證解密后的信息是否是原始發(fā)送的信息。另外加密和解密的過程非常的消耗CPU資源，惡意用戶可能會(huì)通過發(fā)送欺騙數(shù)據(jù)包，占用CPU資源。HMAC功能通過比較數(shù)字簽名進(jìn)行數(shù)據(jù)包完整性和真實(shí)性驗(yàn)證，這個(gè)過程消耗的CPU資源非常少，效率非常高。

所以在IPSec VPN發(fā)送設(shè)備中，加密和驗(yàn)證通常配合使用。加密后的報(bào)文經(jīng)HMAC生成數(shù)字簽名，IP報(bào)文和數(shù)字簽名同時(shí)發(fā)給對(duì)端（數(shù)字簽名填寫在AH和ESP報(bào)文頭的完整性校驗(yàn)值ICV字段，請(qǐng)參見安全協(xié)議）；在接收設(shè)備中，通過比較數(shù)字簽名進(jìn)行數(shù)據(jù)完整性和真實(shí)性驗(yàn)證，驗(yàn)證不通過的報(bào)文直接丟棄，驗(yàn)證通過的報(bào)文再進(jìn)行解密。

加密和HMAC驗(yàn)證配合使用的過程如圖1所示。圖1 HMAC驗(yàn)證過程

 

用于驗(yàn)證的對(duì)稱密鑰可以手工配置，也可以通過DH算法生成并在兩端設(shè)備共享。有關(guān)DH算法具體能夠生成哪些密鑰及密鑰的作用請(qǐng)參見IKEv1協(xié)商安全聯(lián)盟的過程。

一般來說IPSec使用以下幾種認(rèn)證算法：

• MD5（Message Digest 5）：輸入任意長(zhǎng)度的消息，產(chǎn)生一個(gè)128比特的消息摘要。
• SHA-1（Secure Hash Algorithm）：輸入長(zhǎng)度小于264比特的消息，然后生成一個(gè)160比特的消息摘要。
• SHA2-256：通過輸入長(zhǎng)度小于264比特的消息，產(chǎn)生256比特的消息摘要。
• SHA2-384：通過輸入長(zhǎng)度小于2128比特的消息，產(chǎn)生384比特的消息摘要。
• SHA2-512：通過輸入長(zhǎng)度小于2128比特的消息，產(chǎn)生512比特的消息摘要。

SHA-2的消息摘要長(zhǎng)于MD5和SHA-1，因此，SHA-2比MD5和SHA-1更安全。

密鑰交換

 

IKEv1和IKEv2的協(xié)商過程中，隧道兩端需要進(jìn)行密鑰材料的交換，以便使用相同密鑰進(jìn)行正確的加密和解密。

密鑰交換方法

使用對(duì)稱密鑰進(jìn)行加密、驗(yàn)證時(shí)，如何安全地共享密鑰是一個(gè)很重要的問題。有兩種方法解決這個(gè)問題：

• 帶外共享密鑰在發(fā)送、接收設(shè)備上手工配置靜態(tài)的加密、驗(yàn)證密鑰。雙方通過帶外共享的方式（例如通過電話或郵件方式）保證密鑰一致性。這種方式的缺點(diǎn)是可擴(kuò)展性差，在點(diǎn)到多點(diǎn)組網(wǎng)中配置密鑰的工作量成倍增加。另外，為提升網(wǎng)絡(luò)安全性需要周期性修改密鑰，這種方式下也很難實(shí)施。
• 使用一個(gè)安全的連接分發(fā)密鑰IPSec使用IKE協(xié)議在發(fā)送、接收設(shè)備之間安全地協(xié)商密鑰。IKE采用DH算法在不安全的網(wǎng)絡(luò)上安全地交換密鑰信息，并生成加密、驗(yàn)證密鑰。這種方式配置簡(jiǎn)單，可擴(kuò)展性好，特別是在大型動(dòng)態(tài)的網(wǎng)絡(luò)環(huán)境下此優(yōu)點(diǎn)更加突出。

IKE提供密鑰交換，自動(dòng)協(xié)商建立安全聯(lián)盟等服務(wù)。采用IKE協(xié)議可以使IPSec配置和管理更簡(jiǎn)單、更靈活。

• Internet安全聯(lián)盟和密鑰管理協(xié)議ISAKMP（Internet Security Association and Key Management Protocol）是IKE的基礎(chǔ)，IKE使用ISAKMP協(xié)議定義密鑰交換的過程。ISAKMP提供了對(duì)安全服務(wù)進(jìn)行協(xié)商的方法，密鑰交換時(shí)交換信息的方法，以及對(duì)對(duì)等體身份進(jìn)行驗(yàn)證的方法。
• IKE的精髓在于它永遠(yuǎn)不在不安全的網(wǎng)絡(luò)上傳送密鑰，而是通過一些數(shù)據(jù)的交換，通信雙方最終計(jì)算出共享的密鑰，并且即使第三方截獲了雙方用于計(jì)算密鑰的所有交換數(shù)據(jù)，也無法計(jì)算出真正的密鑰。其中的核心技術(shù)就是DH（Diffie Hellman）交換技術(shù)。

DH密鑰交換

DH用于產(chǎn)生密鑰材料，并通過ISAKMP消息在發(fā)送和接收設(shè)備之間進(jìn)行密鑰材料交換。然后，兩端設(shè)備各自計(jì)算出完全相同的對(duì)稱密鑰。該對(duì)稱密鑰用于加密和驗(yàn)證密鑰的計(jì)算。在任何時(shí)候，雙方都不交換真正的密鑰。

DH密鑰交換過程如圖1所示。圖1 DH密鑰交換過程

 

1. 進(jìn)行DH交換的雙方各自產(chǎn)生一個(gè)隨機(jī)數(shù)，如a和b。
2. 使用雙方確認(rèn)的共享的公開的兩個(gè)參數(shù)：底數(shù)g和模數(shù)p各自用隨機(jī)數(shù)a和b進(jìn)行冪和模運(yùn)算，得到結(jié)果c和d，計(jì)算公式如下：c=gamod(p)d=gbmod(p)
3. 交換計(jì)算所得的結(jié)果c和d
4. 各自進(jìn)一步計(jì)算，得到一個(gè)共同的DH公有值：damod(p)=cbmod(p)=gabmod(p)，此公式可以從數(shù)學(xué)上證明。DH公有值就是雙方的密鑰。

若網(wǎng)絡(luò)上的第三方截獲了雙方的模c和d，那么要計(jì)算出DH公有值gabmod(p)還需要獲得a或b，a和b始終沒有直接在網(wǎng)絡(luò)上傳輸過。如果想由模c和d計(jì)算a或b就需要進(jìn)行離散對(duì)數(shù)運(yùn)算，而p為素?cái)?shù)，當(dāng)p足夠大時(shí)（一般為768位以上的二進(jìn)制數(shù)），數(shù)學(xué)上已經(jīng)證明，其計(jì)算復(fù)雜度非常高，從而認(rèn)為是不可實(shí)現(xiàn)的。所以，DH交換技術(shù)可以保證雙方能夠安全地獲得密鑰信息。

DH使用密鑰組來定義自己產(chǎn)生的密鑰長(zhǎng)度。密鑰長(zhǎng)度越長(zhǎng)，產(chǎn)生的密鑰就越安全，但所需的計(jì)算時(shí)間也依次遞增。

 

IPSec安全聯(lián)盟

 

IPSec在兩個(gè)端點(diǎn)之間提供安全通信，這兩個(gè)端點(diǎn)被稱為IPSec對(duì)等體。

安全聯(lián)盟（Security Association）是通信對(duì)等體間對(duì)某些要素的約定。它定義了保護(hù)IP報(bào)文安全的協(xié)議（AH或者ESP）、IP報(bào)文的封裝模式、認(rèn)證算法、保護(hù)IP報(bào)文的共享密鑰等。通過安全聯(lián)盟實(shí)現(xiàn)了IPSec對(duì)IP報(bào)文的保護(hù)。安全聯(lián)盟是IPSec的基礎(chǔ)，也是IPSec的本質(zhì)。

SA是單向的，輸入的IP報(bào)文和輸出的IP報(bào)文由入方向安全聯(lián)盟和出方向安全聯(lián)盟分別處理。因此，如果有兩個(gè)設(shè)備（DeviceA和DeviceB）使用ESP進(jìn)行通信，則必須在DeviceA上設(shè)置兩個(gè)SA，一個(gè)用于處理外發(fā)IP報(bào)文，另一用于處理接收IP報(bào)文。同樣地，DeviceB也需要兩個(gè)SA。如圖1所示。圖1 SA的單向邏輯連接

 

安全聯(lián)盟還與協(xié)議相關(guān)。如果主機(jī)A和主機(jī)B同時(shí)使用AH和ESP進(jìn)行安全通信，對(duì)于主機(jī)A就需要四個(gè)SA，AH協(xié)議的兩個(gè)SA（入方向和出方向上各一個(gè)SA）和ESP協(xié)議的兩個(gè)SA（入方向和出方向上各一個(gè)SA）。同樣地，主機(jī)B也需要四個(gè)SA。

安全聯(lián)盟由一個(gè)三元組來唯一標(biāo)識(shí)。這個(gè)三元組包括：安全參數(shù)索引SPI（Security Parameter Index）、目的IP地址、安全協(xié)議號(hào)（AH或ESP）。SPI是為唯一標(biāo)識(shí)SA而生成的一個(gè)32比特的數(shù)值，它在AH和ESP頭中傳輸。

安全聯(lián)盟建立方式

安全聯(lián)盟可通過手工配置和自動(dòng)協(xié)商兩種方式建立。

• 手工建立安全聯(lián)盟的方式是指用戶通過在兩端手工設(shè)置一些參數(shù)，在兩端參數(shù)匹配和協(xié)商通過后建立IPSec安全聯(lián)盟。手工方式配置比較復(fù)雜，創(chuàng)建IPSec安全聯(lián)盟所需的全部信息都必須手工配置，而且不支持IPSec的一些高級(jí)特性（例如定時(shí)更新密鑰），但優(yōu)點(diǎn)是可以不依賴IKE而單獨(dú)實(shí)現(xiàn)IPSec功能。手工方式目前主要用于協(xié)議報(bào)文的認(rèn)證，例如RIPng、OSPFv3、IGMP、MLD、PIM和DHCPv6 Relay等。
• 自動(dòng)協(xié)商方式由IKE生成和維護(hù)，通信雙方基于各自的安全策略庫經(jīng)過匹配和協(xié)商，最終建立安全聯(lián)盟而不需要用戶的干預(yù)。IKE屬于一種混合型協(xié)議，它建立在由Internet安全聯(lián)盟和密鑰管理協(xié)議ISAKMP（Internet Security Association and Key Management Protocol）定義的一個(gè)框架上。它能夠?yàn)镮PSec提供自動(dòng)協(xié)商交換密鑰、建立安全聯(lián)盟的服務(wù)，以簡(jiǎn)化IPSec的使用和管理。IKE分為IKEv1和IKEv2兩個(gè)版本，二者建立安全聯(lián)盟的方式大體相同，具體請(qǐng)參考IKEv1協(xié)商安全聯(lián)盟的過程和IKEv2協(xié)商安全聯(lián)盟的過程。

IKE的安全機(jī)制

• DH密鑰交換。
• 完善的前向安全性PFS（Perfect Forward Secrecy）：指一個(gè)密鑰被破解，并不影響其他密鑰的安全性，因?yàn)檫@些密鑰間沒有派生關(guān)系。PFS是由DH算法保障的。此特性是通過在IKE階段2的協(xié)商中增加密鑰交換來實(shí)現(xiàn)的。
• 身份驗(yàn)證：身份驗(yàn)證用于確認(rèn)通信雙方的身份。對(duì)于pre-shared key驗(yàn)證方法，驗(yàn)證字用來作為一個(gè)輸入產(chǎn)生密鑰，驗(yàn)證字不同是不可能在雙方產(chǎn)生相同的密鑰的。驗(yàn)證字是驗(yàn)證雙方身份的關(guān)鍵。
• 身份保護(hù)：身份數(shù)據(jù)在密鑰產(chǎn)生之后加密傳送，實(shí)現(xiàn)了對(duì)身份數(shù)據(jù)的保護(hù)。

IKEv1協(xié)商安全聯(lián)盟的過程

 

采用IKEv1協(xié)商安全聯(lián)盟主要分為兩個(gè)階段。

1. IKEv1階段1的目的是建立IKE SA。IKE SA建立后對(duì)等體間的所有ISAKMP消息都將通過加密和驗(yàn)證，這條安全通道可以保證IKEv1階段2的協(xié)商能夠安全進(jìn)行。
2. IKEv1階段2的目的就是建立用來傳輸數(shù)據(jù)的IPSec SA。

IKEv1協(xié)商階段1

IKEv1階段1主要協(xié)商下面三個(gè)任務(wù)：

1. 協(xié)商建立IKE SA所使用的參數(shù)。加密算法、完整性驗(yàn)證算法、身份認(rèn)證方法和認(rèn)證字、DH組、IKE SA生存周期等等。這些參數(shù)在IKE安全提議中定義。
2. 使用DH算法交換與密鑰相關(guān)的信息（生成各種密鑰的材料）。對(duì)等體雙方設(shè)備能夠使用這些密鑰信息各自生成用于ISAKMP消息加密、驗(yàn)證的對(duì)稱密鑰。
3. 對(duì)等體之間驗(yàn)證彼此身份。使用預(yù)共享密鑰或數(shù)字證書來驗(yàn)證設(shè)備身份。

這三個(gè)任務(wù)都協(xié)商成功后，IKE SA就建立成功了。

IKEv1階段1支持兩種協(xié)商模式：主模式（Main Mode）和野蠻模式（Aggressive Mode）

主模式

主模式采用三個(gè)步驟來完成上述三個(gè)任務(wù)。每個(gè)步驟需要2個(gè)ISAKMP報(bào)文，共6個(gè)ISAKMP報(bào)文。交換密鑰相關(guān)信息的操作在身份認(rèn)證之前完成，故設(shè)備的身份信息受到已生成的共享密鑰的保護(hù)。

采用主模式時(shí)IKEv1階段1的協(xié)商過程如圖1所示。圖1 主模式下IKEv1階段1的協(xié)商過程

 

下面對(duì)這三個(gè)步驟進(jìn)行詳細(xì)說明：

1. 協(xié)商對(duì)等體之間使用的IKE安全提議。DeviceA發(fā)送ISAKMP消息，攜帶建立IKE SA所使用的參數(shù)（由IKE安全提議定義）。DeviceB對(duì)DeviceA的IKE安全提議進(jìn)行協(xié)商。在協(xié)商時(shí)將從優(yōu)先級(jí)最高的提議開始匹配，協(xié)商雙方必須至少有一條匹配的IKE安全提議才能協(xié)商成功。匹配的原則為協(xié)商雙方具有相同的加密算法、認(rèn)證算法、認(rèn)證方法和Diffie-Hellman組標(biāo)識(shí)。DeviceB響應(yīng)ISAKMP消息，攜帶經(jīng)協(xié)商匹配的安全提議及參數(shù)。 如果沒有匹配的安全提議，DeviceB將拒絕發(fā)起方的安全提議。
2. 使用DH算法交換與密鑰相關(guān)的信息，并生成密鑰。兩個(gè)對(duì)等體通過兩條ISAKMP消息（3、4）交換與密鑰相關(guān)的信息。由獲得的密鑰信息推導(dǎo)出4個(gè)密鑰。其中SKEYID為基礎(chǔ)密鑰，通過它可以推導(dǎo)出SKEYID_a，為ISAKMP消息完整性驗(yàn)證密鑰；可以推導(dǎo)出SKEYID_e，為ISAKMP消息加密密鑰；可以推導(dǎo)出SKEYID_d，用于衍生出IPSec報(bào)文加密、驗(yàn)證密鑰。預(yù)共享密鑰方式和數(shù)字證書方式下SKEYID的計(jì)算公式不同。圖2 DH密鑰生成
3. 對(duì)等體之間驗(yàn)證彼此身份。兩個(gè)對(duì)等體通過兩條ISAKMP消息（5、6）交換身份信息（預(yù)共享密鑰方式下為IP地址或名稱，數(shù)字證書方式下還需要傳輸證書的內(nèi)容），身份信息通過SKEYID_e加密，故可以保證身份信息的安全性。兩個(gè)對(duì)等體使用IKE安全提議中定義的加密算法、驗(yàn)證算法、身份驗(yàn)證方法和SKEYID_a、SKEYID_e對(duì)IKE消息進(jìn)行加解密和驗(yàn)證。IKEv1支持如下身份驗(yàn)證方法：預(yù)共享密鑰這種方法要求對(duì)等體雙方必須要有相同的預(yù)共享密鑰（該密鑰直接參與SKEYID的生成計(jì)算）。對(duì)于設(shè)備數(shù)量較少的VPN網(wǎng)絡(luò)來說易于配置，在大型VPN網(wǎng)絡(luò)中，不建議采用預(yù)共享密鑰來做身份驗(yàn)證。RSA簽名（通常稱為數(shù)字證書）數(shù)字證書需要由CA服務(wù)器來頒發(fā)。這種方法適用于大型動(dòng)態(tài)的VPN網(wǎng)絡(luò)。證書驗(yàn)證和預(yù)共享密鑰驗(yàn)證的主要區(qū)別在于SKEYID的計(jì)算和交換的身份信息，其他的交換和計(jì)算過程和預(yù)共享密鑰驗(yàn)證方式相同。數(shù)字信封認(rèn)證在數(shù)字信封認(rèn)證中，發(fā)起方采用對(duì)稱密鑰加密信息內(nèi)容，并通過非對(duì)稱密鑰的公鑰加密對(duì)稱密鑰，從而保證只有特定的對(duì)端才能閱讀通信的內(nèi)容，從而確定對(duì)端的身份。此認(rèn)證方法只能在IKEv1的主模式協(xié)商過程中使用，不能在IKEv1野蠻模式協(xié)商過程中使用。

野蠻模式

野蠻模式僅交換3個(gè)消息就可以完成IKE SA的建立。

采用野蠻模式時(shí)IKEv1階段1的協(xié)商過程如圖3所示。圖3 野蠻模式下IKEv1階段1的協(xié)商過程

 

野蠻模式時(shí)IKEv1階段1的協(xié)商過程：

1. DeviceA發(fā)送ISAKMP消息，攜帶建立IKE SA所使用的參數(shù)、與密鑰生成相關(guān)的信息和身份驗(yàn)證信息。
2. DeviceB對(duì)收到的第一個(gè)數(shù)據(jù)包進(jìn)行確認(rèn)，查找并返回匹配的參數(shù)、密鑰生成信息和身份驗(yàn)證信息。
3. DeviceA回應(yīng)驗(yàn)證結(jié)果，并建立IKE SA。

與主模式相比，野蠻模式的優(yōu)點(diǎn)是建立IKE SA的速度較快。但是由于密鑰交換與身份認(rèn)證一起進(jìn)行，野蠻模式無法提供身份保護(hù)。

主模式與野蠻模式的區(qū)別

野蠻模式安全性比主模式差。但是野蠻模式可以滿足某些特定場(chǎng)合的網(wǎng)絡(luò)環(huán)境的需求。例如：

• 遠(yuǎn)程訪問時(shí)，如果響應(yīng)者（服務(wù)器端）無法預(yù)先知道發(fā)起者（終端用戶）的地址、或者發(fā)起者的地址總在變化時(shí)，而雙方都希望采用預(yù)共享密鑰驗(yàn)證方法來創(chuàng)建IKE SA，此時(shí)可以采用野蠻模式。NE采用預(yù)共享認(rèn)證方式，若是可以獲取出口網(wǎng)關(guān)的代理IP，也可以在此種情形下采用主模式下配置代理IP的方式。
• 如果發(fā)起者已知響應(yīng)者的策略，或者對(duì)響應(yīng)者的策略有全面的了解，采用野蠻模式能夠更快地創(chuàng)建IKE SA。

IKEv1協(xié)商階段2

IKEv1階段2的目的就是建立用來傳輸數(shù)據(jù)的IPSec SA。IPSec SA與IKE SA的關(guān)系如圖4所示。圖4 IPSec SA與IKE SA的關(guān)系

 

IKEv1階段2通過快速交換模式完成。由于快速交換模式使用IKEv1階段1中生成的密鑰SKEYID_a對(duì)ISAKMP消息的完整性和身份進(jìn)行驗(yàn)證，使用密鑰SKEYID_e對(duì)ISAKMP消息進(jìn)行加密，故保證了交換的安全性。

在快速交換模式中，對(duì)等體兩端協(xié)商IPSec SA的各項(xiàng)參數(shù)，并為數(shù)據(jù)傳輸衍生出密鑰。

快速模式的協(xié)商過程如圖5所示。圖5 IKEv1階段2協(xié)商過程

 

快速模式共有3條消息完成雙方IPSec SA的建立。

1. 消息1發(fā)送本端的安全參數(shù)和身份認(rèn)證信息。安全參數(shù)包括被保護(hù)的數(shù)據(jù)流和IPSec安全提議等需要協(xié)商的參數(shù)。身份認(rèn)證信息包括第一階段計(jì)算出的密鑰和第二階段產(chǎn)生的密鑰材料等，可以再次認(rèn)證對(duì)等體。
2. 消息2響應(yīng)消息1，發(fā)送響應(yīng)方的安全參數(shù)和身份認(rèn)證信息并生成新的密鑰。對(duì)等體雙方通過交換密鑰材料生成新的共享密鑰，并最終衍生出IPSec的加密密鑰。此時(shí)響應(yīng)者和發(fā)送者各有兩個(gè)SA。IPSec SA數(shù)據(jù)傳輸需要的加密、驗(yàn)證密鑰由SKEYID_d、SPI、協(xié)議等參數(shù)衍生得出，以保證每個(gè)IPSec SA都有自己獨(dú)一無二的密鑰。當(dāng)啟用PFS時(shí)，要再次應(yīng)用DH算法計(jì)算出一個(gè)共享密鑰，然后參與上述計(jì)算，因此在參數(shù)協(xié)商時(shí)要為PFS協(xié)商DH密鑰組。
3. 消息3響應(yīng)消息2，確認(rèn)與響應(yīng)方可以通信，協(xié)商結(jié)束。

IKEv2協(xié)商安全聯(lián)盟的過程

 

要建立一對(duì)IPSec SA，IKEv1需要經(jīng)歷兩個(gè)階段：“主模式＋快速模式”或者“野蠻模式＋快速模式”。前者至少需要交換9條消息，后者也至少需要6條消息。而IKEv2，正常情況使用2次交換共4條消息就可以完成一個(gè)IKE SA和一對(duì)IPSec SA，如果要求建立的IPSec SA大于一對(duì)時(shí)，每一對(duì)SA只需額外增加1次交換，也就是2條消息就可以完成。這比IKEv1要簡(jiǎn)化很多。

IKEv2協(xié)商安全聯(lián)盟的過程

IKEv2定義了三種交換：初始交換、創(chuàng)建子SA交換以及通知交換。

1. 初始交換IKE通信總是從IKE安全聯(lián)盟初始交換（IKE_SA_INIT交換）和IKE認(rèn)證交換（IKE_AUTH交換）開始。這2個(gè)交換通常由4條消息組成，在某些場(chǎng)景下消息數(shù)目可能會(huì)增加。所有使用IKE的通信都由請(qǐng)求/響應(yīng)對(duì)組成。IKE安全聯(lián)盟初始交換和IKE認(rèn)證交換完成后可以建立一個(gè)IKE SA和第一對(duì)CHILD_SA（即IPSec SA）。具體如圖1所示。圖1 IKEv2初始階段的協(xié)商過程
   詳細(xì)說明如下：第一個(gè)消息對(duì)（IKE_SA_INIT）這個(gè)消息對(duì)負(fù)責(zé)進(jìn)行IKE安全聯(lián)盟參數(shù)的協(xié)商，包括協(xié)商加密和驗(yàn)證算法，交換臨時(shí)隨機(jī)數(shù)（nonces）和DH交換。IKE_SA_INIT交換后可以生成一個(gè)共享密鑰材料。通過這個(gè)共享密鑰材料可以生成其他相關(guān)密鑰。第二個(gè)消息對(duì)（IKE_AUTH）從IKE_AUTH交換開始，所有報(bào)文都必須加密再交換。IKE_AUTH交換至少需要兩個(gè)消息。在這兩個(gè)報(bào)文的交互中完成了身份認(rèn)證以及一個(gè)CHILD_SA的創(chuàng)建過程。IKEv2支持RSA簽名認(rèn)證、預(yù)共享密鑰認(rèn)證。RSA簽名認(rèn)證和預(yù)共享密鑰認(rèn)證方式下，認(rèn)證載荷（AUTH載荷）的計(jì)算方式不同。在IKE_SA_INIT交換階段，生成IPSec SA的密鑰材料，并通過這個(gè)密鑰材料衍生出IPSec SA的所有密鑰。IKEv2除支持RSA簽名和預(yù)共享密鑰認(rèn)證外，還支持?jǐn)U展認(rèn)證方法EAP（Extensible Authentication Protocol）。EAP認(rèn)證是作為附加的IKE_AUTH交換在IKE中實(shí)現(xiàn)的。發(fā)起者通過在消息3中省去AUTH載荷來表明需要使用EAP認(rèn)證。
2. 創(chuàng)建子SA交換當(dāng)一個(gè)IKE SA需要?jiǎng)?chuàng)建多對(duì)IPSec SA時(shí)，需要使用創(chuàng)建子SA交換來協(xié)商多于一對(duì)的SA。另外創(chuàng)建子SA交換還可以用于進(jìn)行IKE SA的重協(xié)商。創(chuàng)建子SA交換包含一個(gè)交換兩個(gè)消息。在IKEv1中這個(gè)交換稱為階段2交換（快速模式交換）。這個(gè)交換必須在IKE初始交換完成之后才能進(jìn)行，交換的發(fā)起者可以是IKE初始交換的發(fā)起者，也可以是IKE初始交換的響應(yīng)者。在交換中的兩個(gè)消息需要由IKE初始交換協(xié)商的密鑰進(jìn)行保護(hù)。類似于IKEv1的PFS，創(chuàng)建子SA交換階段可以重新進(jìn)行一次DH交換，生成新的密鑰材料。生成密鑰材料后，子SA的所有密鑰都從這個(gè)密鑰材料衍生出來。
3. 通知交換運(yùn)行IKE協(xié)商的兩端有時(shí)會(huì)傳遞一些控制信息，例如錯(cuò)誤信息或者通告信息，這些信息在IKEv2中是通過通知交換完成的。通知交換必須在IKE SA保護(hù)下進(jìn)行，也就是說通知交換只能發(fā)生在初始交換之后。

IPSec報(bào)文處理流程

 

IPSec安全聯(lián)盟建立以后，可以對(duì)IP報(bào)文做加解密處理。與IPSec報(bào)文轉(zhuǎn)發(fā)相關(guān)的概念如下：

• 安全策略數(shù)據(jù)庫SPDB（Security Policy Database）：定義IP數(shù)據(jù)報(bào)文應(yīng)使用何種安全服務(wù)，以及如何獲得這些服務(wù)。SPDB是SA創(chuàng)建的前提，決定了SA的作用范圍和相關(guān)屬性。
• 安全聯(lián)盟數(shù)據(jù)庫SADB（Security Association Database）：存放與SA關(guān)聯(lián)的所有狀態(tài)數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)。因?yàn)橐粋€(gè)網(wǎng)絡(luò)實(shí)體可以創(chuàng)建多對(duì)SA，所以需要有個(gè)DB來做存儲(chǔ)管理。
• SPI（安全參數(shù)索引）：一個(gè)攜帶在AH或ESP頭部的一個(gè)32位數(shù)值，接收端通過SPI來判斷接收到的數(shù)據(jù)流應(yīng)該用SADB中的哪個(gè)SA來做安全保護(hù)。

IPSec對(duì)于發(fā)送報(bào)文的處理流程如圖1所示。圖1 IPSec發(fā)送報(bào)文處理流程

 

IPSec對(duì)于接收?qǐng)?bào)文的處理流程如圖2所示。圖2 IPSec接收?qǐng)?bào)文處理流程

 

IPSec DPD

 

DPD

當(dāng)兩個(gè)對(duì)等體之間采用IKE和IPSec進(jìn)行通信時(shí)，對(duì)等體之間可能會(huì)由于路由問題、對(duì)等體重啟或其他原因等導(dǎo)致連接斷開。IKE協(xié)議本身沒有提供對(duì)等體狀態(tài)檢測(cè)機(jī)制，一旦發(fā)生對(duì)等體不可達(dá)的情況，只能等待安全聯(lián)盟的生存周期到期。生存周期到期之前，對(duì)等體之間的安全聯(lián)盟將一直存在。安全聯(lián)盟連接的對(duì)等體不可達(dá)將引發(fā)“黑洞”，導(dǎo)致數(shù)據(jù)流被丟棄。通常情況下，迫切需要識(shí)別和檢測(cè)到這些“黑洞”，以便盡快的恢復(fù)IPSec通信。

Keepalive機(jī)制可以解決這個(gè)問題。Keepalive機(jī)制是指IKE對(duì)等體間通過周期性的交換Hello/Ack消息來告知對(duì)方自己處于活動(dòng)狀態(tài)。但是在設(shè)備上的IKE SA數(shù)量很大時(shí)，發(fā)送的Hello/Ack消息將會(huì)大量消耗設(shè)備的CPU資源，限制了這種機(jī)制的應(yīng)用。

失效對(duì)等體檢測(cè)DPD（Dead Peer Detect）是Keepalive機(jī)制的一種替代機(jī)制，它利用IPSec流量使對(duì)等體狀態(tài)檢測(cè)所需消息的數(shù)量達(dá)到最小化。DPD規(guī)定每個(gè)IKE peer的狀態(tài)和對(duì)端狀態(tài)是完全獨(dú)立的，當(dāng)IKE peer想知道對(duì)端是否在線時(shí)，隨時(shí)請(qǐng)求，不需要等待間隔時(shí)間的到來。當(dāng)peer之間有正常的IPSec流量時(shí)，證明對(duì)端肯定在線，此時(shí)沒有必要去發(fā)送額外的消息探測(cè)對(duì)端是否在線。只有一段時(shí)間內(nèi)沒有流量發(fā)生，peer的活動(dòng)狀態(tài)才值得懷疑，那么本端在發(fā)送流量前應(yīng)該發(fā)送一次DPD消息來檢測(cè)對(duì)端的狀態(tài)。

DPD有兩種模式可以選擇：interval和on-demand。

interval：表示DPD工作在輪詢模式，在check-interval時(shí)間內(nèi)，如果沒有收到對(duì)端發(fā)過來的流量就會(huì)以check-interval為周期循環(huán)發(fā)送DPD檢測(cè)報(bào)文。如果期間收到對(duì)端的響應(yīng)報(bào)文，那么本次DPD流程結(jié)束，進(jìn)入新的DPD檢測(cè)周期。如果期間沒有收到對(duì)端的響應(yīng)報(bào)文，則會(huì)進(jìn)行報(bào)文重傳。重傳結(jié)束后，如果依然沒有收到響應(yīng)則會(huì)刪除本端SA表項(xiàng)，重新執(zhí)行隧道新建流程。

on-demand：表示DPD工作在流量觸發(fā)模式，如果本端沒有加密流量發(fā)送，那么是不會(huì)發(fā)送DPD報(bào)文的，這是和輪詢模式的最大區(qū)別。如果本端有加密流量需要發(fā)送，并且發(fā)送后在check-interval時(shí)間內(nèi)沒有收到對(duì)端發(fā)過來的流量，那么就會(huì)以check-interval為周期循環(huán)發(fā)送DPD檢測(cè)報(bào)文。如果期間收到對(duì)端的響應(yīng)報(bào)文，那么本次DPD流程結(jié)束，進(jìn)入新的DPD檢測(cè)周期。如果期間沒有收到對(duì)端的響應(yīng)報(bào)文，則會(huì)進(jìn)行報(bào)文重傳。重傳結(jié)束后，如果依然沒有收到響應(yīng)則會(huì)刪除本端SA表項(xiàng)，重新執(zhí)行隧道新建流程。

IPSec安全性

 

IKEv2的安全性分析

 

此處著重分析IKEv2的安全性。

IKEv2對(duì)傳統(tǒng)IKE存在的安全漏洞進(jìn)行了修訂，提高了密鑰協(xié)商的安全性，并明確規(guī)定了所有的消息必須以請(qǐng)求/響應(yīng)對(duì)的形式存在，有效的解決了使用UDP作為傳輸層協(xié)議的不可靠性問題。

以下從三方面來討論IKEv2的安全性問題。

• 抵御中間人攻擊中間人攻擊（Man-in-the-middle Attack）是一種主動(dòng)攻擊，指攻擊者對(duì)通信雙方進(jìn)行竊聽，截獲通信雙方的消息并進(jìn)行任意插入、刪除或篡改消息，之后返回消息給發(fā)送者，或者重放舊消息以及重定向消息，是最危險(xiǎn)的攻擊。IKEv2中抵御中間人攻擊的機(jī)制和方法：密鑰材料生成方式與傳統(tǒng)IKE相比，IKEv2的密鑰材料發(fā)生了變化，雙方用于后繼交互使用的加密密鑰與認(rèn)證密鑰都是不同的。這些密鑰是從prf+輸出流中依次提取，從而增加了攻擊者猜測(cè)密鑰的難度，減少了密鑰泄漏的可能性，增強(qiáng)了傳輸?shù)陌踩裕欢ǔ潭壬峡梢缘钟虚g人攻擊。身份認(rèn)證IKEv2使用預(yù)共享密鑰和數(shù)字簽名方式進(jìn)行身份認(rèn)證。身份認(rèn)證方式具有交互性，參與協(xié)商的實(shí)體彼此都對(duì)對(duì)方的身份進(jìn)行認(rèn)證；具有對(duì)稱性，參與協(xié)商的雙方都使用相同的機(jī)制或方法對(duì)對(duì)方的身份進(jìn)行認(rèn)證。雙向的身份認(rèn)證可以有效地抵御中間人攻擊。同時(shí)IKEv2定義了擴(kuò)展認(rèn)證交互，即使用擴(kuò)展認(rèn)證協(xié)議（EAP）描述的方法對(duì)IKEv2協(xié)商進(jìn)行身份認(rèn)證，支持非對(duì)稱雙向認(rèn)證，進(jìn)一步加強(qiáng)了認(rèn)證的靈活性和協(xié)商的可擴(kuò)展性。消息交換IKEv2將傳統(tǒng)IKE主模式交換的六條消息修訂為四條消息，將SA載荷和KE載荷、nonce載荷一同發(fā)送，這樣，消息中包含隨機(jī)的nonce值，如果攻擊者偽裝成響應(yīng)方進(jìn)行應(yīng)答，將收到的發(fā)起方的消息基本上不做改變，再發(fā)回給發(fā)起方，發(fā)起方可以根據(jù)消息內(nèi)容判斷消息的真假，在一定程度上可以抵御重放攻擊。每個(gè)IKEv2消息的頭都包含了一個(gè)消息ID，用于匹配對(duì)應(yīng)的請(qǐng)求和響應(yīng)消息以及識(shí)別消息重傳。當(dāng)發(fā)送和接收到請(qǐng)求時(shí)，必須對(duì)消息ID值順序增加，且除了IKE_SA_INIT交互外其值受加密和完整性保護(hù)，使得它能夠防重放攻擊。同時(shí)IKEv2加入了滑動(dòng)窗口機(jī)制，使交互能夠更加有效地抵御重放攻擊的威脅。
• 抵御DDoS（Distributed Denial of Service）攻擊IKEv2中抵御DDoS攻擊的機(jī)制和方法：SPI值IKEv2消息頭部有發(fā)起方SPIi和響應(yīng)方SPIr，它們是內(nèi)核產(chǎn)生的8字節(jié)的隨機(jī)數(shù)，用來標(biāo)識(shí)SA，同時(shí)也可以標(biāo)識(shí)進(jìn)行消息交換的一對(duì)節(jié)點(diǎn)。具有相同SPI值的請(qǐng)求處理一次（重傳消息除外），而把其他請(qǐng)求作為重復(fù)數(shù)據(jù)包丟棄，可以在一定程度上防止DDoS攻擊。帶Cookie交互IKEv2中使用N載荷攜帶Cookie的輔助交換來抵御拒絕服務(wù)攻擊。在通信過程中，響應(yīng)方認(rèn)為自己正受到DDoS攻擊時(shí)，可以向發(fā)起方請(qǐng)求回復(fù)一個(gè)無狀態(tài)cookie。響應(yīng)方收到對(duì)方發(fā)來的第一條消息后并不急于進(jìn)行IKE_SA_INIT交互，而是再產(chǎn)生一個(gè)新的cookie，封裝在通知載荷中發(fā)送給對(duì)方。如果發(fā)起方不是攻擊者，就可以收到這條消息，然后重新開始協(xié)商，并將響應(yīng)方的cookie封裝在該消息中，其它載荷內(nèi)容保持不變。重傳約定IKEv2中所有消息都是成對(duì)出現(xiàn)，在每對(duì)消息中，發(fā)起方負(fù)責(zé)重傳事件，響應(yīng)方不必對(duì)其響應(yīng)消息進(jìn)行重傳，除非收到對(duì)方的一個(gè)重傳請(qǐng)求。避免了雙方同時(shí)發(fā)起重傳，造成資源的浪費(fèi)，同時(shí)也可以防止攻擊者截獲消息后，偽裝成協(xié)商者不斷地發(fā)送重傳消息，耗費(fèi)協(xié)商雙方的資源。丟棄半開（half-open）連接IKEv2只能通過兩種情況判斷對(duì)方是否失效：一種是重復(fù)嘗試聯(lián)系對(duì)方，直到應(yīng)答時(shí)間過期；另一種是收到對(duì)方的不同IKE SA加密保護(hù)下的INITIAL CONTACT通知消息。IKEv2發(fā)起方允許多個(gè)響應(yīng)方響應(yīng)第一條消息，并把所有的響應(yīng)方視為合法并作回應(yīng)。發(fā)起方發(fā)送一些消息后，一旦收到一個(gè)有效的加密的響應(yīng)消息，將其他的響應(yīng)消息忽略，并將其他所有的無效的半連接丟棄。這樣在協(xié)商開始時(shí)就可以避免受到DDoS攻擊。
• 完善的前向安全性PFS（Perfect Forward Secrecy）IPSec SA數(shù)據(jù)傳輸需要的加密、驗(yàn)證密鑰由SKEYID_d、SPI、協(xié)議等參數(shù)衍生得出，可以保證每個(gè)IPSec SA都有自己獨(dú)一無二的密鑰。但是由于所有IPSec SA密鑰都是相同的來源產(chǎn)生的，所以這些IPSec SA密鑰相互間都有關(guān)聯(lián)，假如有攻擊者能夠根據(jù)IKE SA判斷出SKEYID_d的值，那么就能非常容易的掌握從該SKEYID_d衍生出來的所有IPSec SA的密鑰。IPSec專門提供PFS特性來解決這個(gè)問題，實(shí)現(xiàn)思路是：IKEv2初始交互的密鑰衍生材料不被用于衍生供IPSec SA使用的相關(guān)密鑰，而是通過在CREATE_IPSec_SA交互中引入可選的IKE載荷重新進(jìn)行一次額外的DH交換來生成密鑰材料。通過這種方式，IPSec密鑰之間相互沒有關(guān)聯(lián)，即使攻擊者攻克了一個(gè)密鑰，也只能破解這個(gè)密鑰保護(hù)的數(shù)據(jù)，而不能破解受其它密鑰保護(hù)的數(shù)據(jù)。

防重放

IPSec中的重放攻擊（Replay Attack）主要是指攻擊者大量發(fā)送目的主機(jī)已接收過的數(shù)據(jù)包，大量消耗系統(tǒng)資源，可能導(dǎo)致系統(tǒng)CPU資源耗盡。

IPSec利用序列號(hào)和滑動(dòng)窗口來實(shí)現(xiàn)防重放（Anti-Replay）。IPSec中AH和ESP協(xié)議報(bào)文頭中有個(gè)序列號(hào)字段（Sequence Number）專門用于防重放攻擊。

通信雙方協(xié)商好IPSec SA之后，序列號(hào)字段被置為0，此后發(fā)送方每發(fā)出一個(gè)報(bào)文，該數(shù)值加1。接收方存在一個(gè)防重放滑動(dòng)窗口和已接收?qǐng)?bào)文的序列號(hào)數(shù)據(jù)庫。

• 如果該序列號(hào)的報(bào)文從未被接收過，且在防重放窗口內(nèi)，接收方就接收該報(bào)文。如果該序列號(hào)的報(bào)文已經(jīng)被接收過，則認(rèn)為是重放攻擊，丟棄該報(bào)文。
• 如果該序列號(hào)在防重放窗口的左側(cè)（小于防重放窗口的最小值），則認(rèn)為是已經(jīng)接收的報(bào)文，因而被丟棄。
• 如果該序列號(hào)在防重放窗口的右側(cè)（大于防重放窗口的最大值），則認(rèn)為未被接收的報(bào)文，會(huì)正常接收，同時(shí)觸發(fā)防重放窗口向右滑動(dòng)。

下面結(jié)合圖1詳細(xì)描述防重放的原理。圖1 防重放示意圖

 

• 如圖1（a）所示，初始防重放窗口是[0–63]，序列號(hào)在此范圍內(nèi)的報(bào)文會(huì)被正常接收，接下來如果接收到序列號(hào)大于63的報(bào)文，也會(huì)正常接收，并且防重放窗口向右滑動(dòng)。但是如果再次收到序列號(hào)在[0–63]范圍內(nèi)的報(bào)文，則認(rèn)為是重放攻擊，拒絕接收?qǐng)?bào)文。
• 如果此時(shí)收到序列號(hào)為66的報(bào)文，則防重放窗口滑動(dòng)到[3–66]，接下來如果接收到序列號(hào)大于66的報(bào)文，也會(huì)正常接收，具體如圖1（b）所示。此時(shí)[0–2]這三個(gè)序列號(hào)已經(jīng)不在防重放窗口范圍內(nèi)，如果再次收到此范圍內(nèi)的報(bào)文，則會(huì)認(rèn)為是已經(jīng)接收過的報(bào)文，所以會(huì)丟棄這些報(bào)文。
• 如圖1（c）所示，假如報(bào)文發(fā)生亂序，接收端先接收到序列號(hào)為67的報(bào)文，則防重放窗口滑動(dòng)到[4–67]。然后再接收到序列號(hào)為3的報(bào)文，雖然該報(bào)文之前從未接收過，但是因?yàn)槠湫蛄刑?hào)已經(jīng)在防重放窗口之外，因此也被丟棄。從這一點(diǎn)可以看出，在報(bào)文亂序情況下，防重放窗口設(shè)置越大，報(bào)文被錯(cuò)誤丟棄的幾率就越低，反之就越高。

安全聯(lián)盟生存周期

為了防止密鑰長(zhǎng)期使用而帶來的安全隱患，安全聯(lián)盟存在生存周期。衡量生存周期有兩種方式：基于時(shí)間的生存周期和基于流量的生存周期。

• 基于時(shí)間的生存周期是從安全聯(lián)盟建立開始的時(shí)刻起，此安全聯(lián)盟存活的時(shí)間。
• 基于流量的生存周期是此安全聯(lián)盟允許處理的最大流量。

其中IPSec安全聯(lián)盟兩種方式都支持，IKE安全聯(lián)盟并不傳輸IPSec流量，因此僅支持基于時(shí)間的生存周期。IPSec安全聯(lián)盟和IKE安全聯(lián)盟的生存周期可以分別配置，互不干擾。

對(duì)于IKE安全聯(lián)盟的生存周期：

• 如果生存周期超時(shí)，IKE SA將自動(dòng)更新。因?yàn)镮KE協(xié)商需要進(jìn)行DH計(jì)算，需要經(jīng)過較長(zhǎng)的時(shí)間，為使IKE SA的更新不影響安全通信，建議設(shè)置生存周期大于10分鐘。
• SA在設(shè)定的生存周期超時(shí)前會(huì)提前協(xié)商另一個(gè)SA來替換舊的SA。在新的SA還沒有協(xié)商完之前，依然使用舊的SA；在新的SA建立后，將立即使用新的SA，舊的SA會(huì)被自動(dòng)清除。

對(duì)于IPSec安全聯(lián)盟的生存周期：如果生存周期到達(dá)指定的時(shí)間或指定的流量，則IPSec安全聯(lián)盟就會(huì)失效。IPSec安全聯(lián)盟失效前，IKE將為IPSec協(xié)商建立新的IPSec安全聯(lián)盟，這樣在舊的IPSec安全聯(lián)盟失效前新的IPSec安全聯(lián)盟就已經(jīng)準(zhǔn)備好。在新的IPSec安全聯(lián)盟開始協(xié)商而沒有協(xié)商好之前，繼續(xù)使用舊的IPSec安全聯(lián)盟保護(hù)通信。在新的IPSec安全聯(lián)盟協(xié)商好之后，則立即采用新的IPSec安全聯(lián)盟保護(hù)通信。

此外，為了方便對(duì)于IPSec安全聯(lián)盟的生存周期進(jìn)行配置，系統(tǒng)支持局部超時(shí)和全局超時(shí)兩種配置模式，局部超時(shí)時(shí)間是針對(duì)某個(gè)IPSec SA的超時(shí)時(shí)間。全局超時(shí)時(shí)間是針對(duì)系統(tǒng)中所有IPSec SA的超時(shí)時(shí)間。當(dāng)IKE協(xié)商安全聯(lián)盟時(shí)，如果采用的安全策略沒有配置自己的超時(shí)時(shí)間，將采用全局超時(shí)時(shí)間與對(duì)端協(xié)商。如果安全策略配置了自己的超時(shí)時(shí)間，則系統(tǒng)使用安全策略自己的超時(shí)時(shí)間與對(duì)端協(xié)商。

IPSec QoS

IPSec QoS支持的功能點(diǎn)如表1所示。

 

IPSec NAT穿越

 

NAT技術(shù)主要用于解決IPv4地址緊缺問題，在目前網(wǎng)絡(luò)中NAT應(yīng)用非常廣泛，特別是在企業(yè)網(wǎng)出口網(wǎng)關(guān)大都使用了NAT技術(shù)解決公網(wǎng)地址不足的問題。IPSec提供了端到端的IP通信的安全性，可以實(shí)現(xiàn)同一企業(yè)集團(tuán)不同地域分支之間的低成本安全互連。但是IPSec和NAT技術(shù)本身存在不兼容的問題。

• 從NAT的角度上說，為了完成地址轉(zhuǎn)換，勢(shì)必會(huì)修改IP報(bào)文頭中的IP地址。
• 從IPSec的角度上說，IPSec要保證數(shù)據(jù)的安全，因此它會(huì)加密和校驗(yàn)數(shù)據(jù)。AH主要用于保護(hù)消息的完整性，其驗(yàn)證范圍包含IP報(bào)文頭，而NAT修改IP報(bào)文頭會(huì)導(dǎo)致AH檢查失敗，因此使用AH保護(hù)的IPSec隧道是不能穿越NAT網(wǎng)關(guān)的。但是ESP協(xié)議保護(hù)的報(bào)文不存在該問題，因?yàn)镋SP保護(hù)的部分不包含IP報(bào)文頭（對(duì)隧道方式而言是外層IP報(bào)文頭）。

但是還是有新的不兼容問題，當(dāng)NAT改變了某個(gè)包的IP地址和（或）端口號(hào)時(shí)，它通常要更新TCP或UDP校驗(yàn)和。當(dāng)TCP或UDP校驗(yàn)和使用了ESP來加密時(shí)，它就無法更新這個(gè)校驗(yàn)和。

• ESP封裝的隧道模式：ESP隧道模式將整個(gè)原始的IP包整個(gè)進(jìn)行了加密，且在ESP的頭部外面新加了一層IP頭部，所以NAT如果只改變最前面的IP地址對(duì)后面受到保護(hù)的部分是不會(huì)有影響的。因此，IPSec采用ESP的隧道模式來封裝數(shù)據(jù)時(shí)可以與NAT共存。

IPSec穿越NAT的處理

IPSec NAT穿越的流程是：

• NAT穿越（NAT-Traversal，簡(jiǎn)稱NAT-T）能力檢測(cè)：建立IPSec隧道的兩端需要進(jìn)行NAT穿越能力協(xié)商，這是在IKE協(xié)商的前兩個(gè)消息中進(jìn)行的，通過Vendor ID載荷指明的一組數(shù)據(jù)來標(biāo)識(shí)。
• NAT網(wǎng)關(guān)發(fā)現(xiàn)：通過NAT-D（NAT-Discovery）載荷來實(shí)現(xiàn)的，該載荷用于在IKE Peer之間發(fā)現(xiàn)NAT網(wǎng)關(guān)的存在以及確定NAT設(shè)備在Peer的哪一側(cè)。NAT側(cè)的Peer作為發(fā)起者，需要定期發(fā)送NAT-Keepalive報(bào)文，以使NAT網(wǎng)關(guān)確保安全隧道處于激活狀態(tài)。
• ESP報(bào)文正常穿越NAT網(wǎng)關(guān)：IPSec穿越NAT，簡(jiǎn)單來說就是在原報(bào)文的IP頭和ESP頭（不考慮AH方式）間增加一個(gè)標(biāo)準(zhǔn)的UDP報(bào)文頭。這樣，當(dāng)ESP報(bào)文穿越NAT網(wǎng)關(guān)時(shí)，NAT對(duì)該報(bào)文的外層IP頭和增加的UDP報(bào)頭進(jìn)行地址和端口號(hào)轉(zhuǎn)換；轉(zhuǎn)換后的報(bào)文到達(dá)IPSec隧道對(duì)端時(shí)，與普通IPSec處理方式相同，但在發(fā)送響應(yīng)報(bào)文時(shí)也要在IP頭和ESP頭之間增加一個(gè)UDP報(bào)文頭。。

IKEv2與NAT穿越

NAT-T能力檢測(cè)

NAT-T能力檢測(cè)在IKE協(xié)商的前兩個(gè)消息中交換完成，通過在消息中插入一個(gè)標(biāo)識(shí)NAT-T能力的Vendor ID載荷來告訴對(duì)方自己對(duì)該能力的支持。如果雙方都在各自的消息中包含了該載荷，說明雙方對(duì)NAT-T都是支持的。只有雙方同時(shí)支持NAT-T能力，才能繼續(xù)進(jìn)行其他協(xié)商。

NAT網(wǎng)關(guān)發(fā)現(xiàn)

當(dāng)存在NAT設(shè)備時(shí)必須使用UDP傳輸，所以在IKEv2中的第一階段協(xié)商中必須先探測(cè)是否存在NAT設(shè)備，也就是NAT探測(cè)。

通過發(fā)送NAT-D載荷來實(shí)現(xiàn)NAT探測(cè)是目前比較流行的方法。

在傳統(tǒng)IKE中NAT-D載荷包括在主模式的第三個(gè)和第四個(gè)信息中以及野蠻模式的第二個(gè)和第三個(gè)信息中。對(duì)于創(chuàng)建VPN連接的雙方來說，發(fā)送的信息中一般要包括兩個(gè)連續(xù)的NAT-D載荷，第一個(gè)是關(guān)于目的地址，第二個(gè)是關(guān)于源地址。如果發(fā)送方不知道自己的確切地址(發(fā)送方有多個(gè)接口，應(yīng)用程序并不知道數(shù)據(jù)包從哪個(gè)接口出去)，則需要多個(gè)NAT-D載荷，從第二個(gè)載荷開始，每個(gè)載荷和發(fā)送方的一個(gè)地址相關(guān)。對(duì)方接收到NAT-D載荷后重新根據(jù)收到的包的實(shí)際地址端口來計(jì)算hash值后進(jìn)行比較，就可以知道是否有NAT設(shè)備以及哪一方在NAT設(shè)備之后了。這種方法雖然能檢測(cè)兩個(gè)IKE對(duì)端之間NAT設(shè)備的存在，但存在著明顯的缺陷。因?yàn)樵谥髂Ｊ胶鸵靶U模式中，NAT-D載荷沒有被認(rèn)證，這意味著入侵者可以刪除、改變、增加這些載荷，這將導(dǎo)致DoS攻擊。通過改變NAT-D載荷，攻擊者可以使兩方使用UDP封裝的模式，而不是使用正常的模式，導(dǎo)致浪費(fèi)帶寬。

為了解決上述缺陷，探測(cè)通信鏈路中是否存在NAT設(shè)備，可在協(xié)商雙方增加兩個(gè)Notify載荷，一個(gè)包括NAT_DETECTION_SOURCE_IP，標(biāo)識(shí)發(fā)起方的IP地址；一個(gè)包括NAT_DETECTION_DESTINATION_IP，標(biāo)識(shí)目的方的IP地址。這兩個(gè)載荷主要是為了探測(cè)通信雙方是否存在NAT設(shè)備，并且確定哪一方處在NAT設(shè)備之后。

這一過程在IKEv2協(xié)商的第一組交換中進(jìn)行。具體過程如下：

在IKEv2中，NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP在Notify消息類型中的編號(hào)分別為：16388和16389。載荷使用通用的ISAKMP載荷頭，載荷的值是SPIs、IP地址、發(fā)送數(shù)據(jù)包的端口號(hào)的hash值(IKEv2規(guī)定使用SHA-1)，hash值的計(jì)算如下：hash=SHA-1(SPIs|IP|Port)。其中：

• SPIs為HDR載荷中的安全索引參數(shù)。
• IP為數(shù)據(jù)包發(fā)出方或接收方的IP地址。
• Port為數(shù)據(jù)包發(fā)出方或接收方的端口號(hào)。

當(dāng)接受方收到數(shù)據(jù)包后，對(duì)數(shù)據(jù)包中的SPIs、IP地址、端口號(hào)進(jìn)行hash運(yùn)算，并與Notify載荷進(jìn)行比較，如果不匹配，則說明通信鏈路中存在NAT設(shè)備：如果與NAT_DETECTION_SOURCE_IP不匹配，則說明發(fā)起端在NAT設(shè)備之后；如果與NAT_DETECTION_DESTINATION_IP不匹配，則說明接受端在NAT設(shè)備之后。

NAT穿越的啟用

在第一階段協(xié)商完成之后，協(xié)商雙方均已經(jīng)明確是否存在NAT，以及NAT的位置。至于是否啟用NAT穿越，則由快速模式協(xié)商決定。

NAT穿越的啟用協(xié)商在快速模式的SA載荷中進(jìn)行。

NAT-keepalive

在NAT網(wǎng)關(guān)上NAT會(huì)話有一定的存活時(shí)間，因此，隧道建立后如果中間長(zhǎng)時(shí)間沒有報(bào)文穿越，就會(huì)導(dǎo)致NAT會(huì)話被刪除，這樣將導(dǎo)致無法通過隧道傳輸數(shù)據(jù)。解決方法是在NAT會(huì)話超時(shí)前，發(fā)送一個(gè)NAT-keepalive給對(duì)端，維持NAT會(huì)話的存活。

IPSec增強(qiáng)功能

 

IPSec白名單

IPSec網(wǎng)關(guān)支持通過證書屬性訪問控制策略來認(rèn)證IKE對(duì)端的證書，通過配置此功能也能達(dá)到類似白名單的效果。但是此方案存在以下不足：

1. 配置工作量較大，管理不方便。
2. 沒有提供對(duì)證書通用名稱CN（Common Name）的精確匹配。

IPSec白名單特性可以有效解決上述問題。IPSec白名單可以由用戶自己定義，然后導(dǎo)入設(shè)備，IPSec白名單提供對(duì)證書通用名稱CN（Common Name）的精確匹配。

IPSec白名單的具體實(shí)現(xiàn)過程是：在建立IPSec隧道之前進(jìn)行IKE協(xié)商時(shí)，判斷是否使能了白名單檢驗(yàn)功能，如果使能，則檢驗(yàn)接收到的對(duì)端證書的CN字段是否在IPSec網(wǎng)關(guān)的白名單列表內(nèi)。

• 如果對(duì)端的證書的CN字段在IPSec網(wǎng)關(guān)的白名單列表里面，則驗(yàn)證通過，允許進(jìn)行IKE協(xié)商并建立IPSec隧道。
• 如果對(duì)端的證書的CN字段不在IPSec網(wǎng)關(guān)的白名單列表里面，則驗(yàn)證失敗，不允許進(jìn)行IKE協(xié)商，最終IPSec隧道建立失敗。

通過這種方式，可以有效保證只有在數(shù)字證書白名單內(nèi)的設(shè)備才能接入網(wǎng)絡(luò)，提高了網(wǎng)絡(luò)安全性。

白名單文件一般是xml文件，其格式如下：

<SerialnumberList>
    <Serialnumber>CN-on-Certificate_of-RBS-1</Serialnumber>
    <Serialnumber>CN-on-Certificate_of-RBS-2</Serialnumber>
    …
    <Serialnumber>CN-on-Certificate_of-RBS-n</Serialnumber>
</SerialnumberList>

其中<Serialnumber></Serialnumber>之間的字符串即為與IPSec網(wǎng)關(guān)對(duì)接設(shè)備的證書的CN字段。

為了方便用戶根據(jù)實(shí)際需要刷新白名單，IPSec白名單還支持如下功能：

• 支持導(dǎo)入白名單，如果導(dǎo)入過程失敗，可以回退到導(dǎo)入之前的狀態(tài)。
• 支持刪除白名單。
• 支持增量添加白名單。
• 支持查看白名單內(nèi)容。

如圖1所示，為了保證eNodeB和IPSec網(wǎng)關(guān)之間的通信安全，eNodeB和IPSec網(wǎng)關(guān)之間建立了IPSec隧道。而為了防止非法設(shè)備與IPSec網(wǎng)關(guān)之間建立IPSec隧道，可以提前在IPSec網(wǎng)關(guān)上配置白名單特性，從而保證只有在白名單內(nèi)的設(shè)備才能接入網(wǎng)絡(luò)。

圖1 IPSec白名單的應(yīng)用

 

自動(dòng)生成IPSec業(yè)務(wù)路由

自動(dòng)生成IPSec業(yè)務(wù)路由的功能，主要有如下兩種應(yīng)用場(chǎng)景。

• 當(dāng)使用安全策略模板方式建立IPSec隧道時(shí)，用戶可能不知道對(duì)端隧道的IPSec業(yè)務(wù)路由信息（如對(duì)端的IP地址和接口等），因此無法手工配置靜態(tài)路由，這時(shí)需要配置自動(dòng)生成IPSec業(yè)務(wù)路由的功能。
• 當(dāng)使用安全策略模板方式建立IPSec隧道時(shí)，會(huì)通過IPSec協(xié)商過程自動(dòng)生成IPSec業(yè)務(wù)路由。當(dāng)用戶希望按照自己的網(wǎng)絡(luò)規(guī)劃，通過配置靜態(tài)路由方式生成IPSec業(yè)務(wù)路由時(shí)，需要先去使能自動(dòng)生成IPSec業(yè)務(wù)路由的功能。

IPSec擴(kuò)展應(yīng)用

GRE over IPSec

 

IPSec本身不支持封裝組播、廣播和非IP報(bào)文，GRE無法對(duì)報(bào)文進(jìn)行認(rèn)證加密，通過GRE over IPSec技術(shù)可以將組播、廣播報(bào)文先封裝GRE后，然后再進(jìn)行IPSec加密處理。同時(shí)采用GRE的接口對(duì)接收到的加解密流量來進(jìn)行統(tǒng)計(jì)。當(dāng)網(wǎng)關(guān)之間采用GRE over IPSec連接時(shí)，先進(jìn)行GRE封裝，再進(jìn)行IPSec封裝。下面以ESP為例說明，報(bào)文的封裝格式如圖1所示。圖1 GRE over IPSec封裝模式（隧道模式）

 

IPSec封裝過程中增加的IP頭即源地址為IPSec網(wǎng)關(guān)應(yīng)用IPSec策略的接口地址，目的地址即IPSec對(duì)等體中應(yīng)用IPSec策略的接口地址。

IPSec需要保護(hù)的數(shù)據(jù)流為從GRE起點(diǎn)到GRE終點(diǎn)的數(shù)據(jù)流。GRE封裝過程中增加的IP頭即源地址為GRE隧道的源端地址，目的地址為GRE隧道的目的端地址。

基于GRE over IPSec的應(yīng)用很多，比如BGP、LDP、OSPF、IS-IS和IPv6等協(xié)議，這些應(yīng)用的原理相同，都是將協(xié)議報(bào)文使用GRE封裝成IP報(bào)文，然后再在IPSec隧道里傳輸。

IPSec和GRE結(jié)合，還有一種IPSec over GRE方案，即先使用IPSec對(duì)報(bào)文進(jìn)行封裝，然后再使用GRE封裝。但是，這種封裝方式既沒有充分利用IPSec和GRE的優(yōu)勢(shì)，也無法支持組播、廣播和非IP報(bào)文，因此一般不推薦使用。

L2VPN/L3VPN場(chǎng)景IPSec應(yīng)用

 

L2VPN CE作為IPSec安全網(wǎng)關(guān)

圖1 報(bào)文封裝轉(zhuǎn)發(fā)流程

 

缺省情況下，指定安全策略視圖的IPSec報(bào)文都是先加密再分片，對(duì)端收到所有報(bào)文后，才能進(jìn)行解密。通過命令行ipsec df-bit clear和ipsec fragmentation before-encryption配合可以實(shí)現(xiàn)先分片后加密，這樣對(duì)端的設(shè)備就可以收到一片就對(duì)一片報(bào)文解密，為了加快加密報(bào)文的解析速度。報(bào)文的實(shí)際凈荷可能會(huì)增大。

圖2 QoS方案

 

IPSec報(bào)文傳輸?shù)倪^程中，原始報(bào)文IP頭的DSCP值不會(huì)也不允許被改變。

報(bào)文加密后，原始IP報(bào)文頭的DSCP值映射到IPSec頭部的DSCP域；也可以單獨(dú)設(shè)定外層IP頭的DSCP值。

加密后的IPSec報(bào)文，經(jīng)過加密MPLS網(wǎng)絡(luò)傳輸后解密，原始IP報(bào)文頭的DSCP值不變。MPLS網(wǎng)絡(luò)傳輸過程，外層DSCP值也可以映射到MPLS EXP值中去。

如果按照DSCP優(yōu)先級(jí)協(xié)商IPSec SA，就可以解決Qos帶來的亂序問題。

L3VPN PE作為IPSec安全網(wǎng)關(guān)

圖3 報(bào)文封裝轉(zhuǎn)發(fā)流程

 

圖4 QoS方案

 

IPSec報(bào)文傳輸?shù)倪^程中，原始報(bào)文IP頭的DSCP值不會(huì)也不允許被改變。

報(bào)文加密后，原始IP報(bào)文頭的DSCP值映射到IPSec頭部的DSCP域；也可以單獨(dú)設(shè)定外層IP頭的DSCP值。

加密后的IPSec報(bào)文，經(jīng)過加密MPLS網(wǎng)絡(luò)傳輸后解密，原始IP報(bào)文頭的DSCP值不變。MPLS網(wǎng)絡(luò)傳輸過程，外層DSCP值也可以映射到MPLS EXP值中去。

如果按照DSCP優(yōu)先級(jí)協(xié)商IPSec Sa，就可以解決Qos帶來的亂序問題。

L3VPN CE作為IPSec安全網(wǎng)關(guān)

圖5 報(bào)文封裝轉(zhuǎn)發(fā)流程

 

圖6 QoS方案

 

報(bào)文加密后，原始IP報(bào)文頭的DSCP值映射到IPSec頭部的DSCP域；也可以單獨(dú)設(shè)定外層IP頭的DSCP值。

原始IP報(bào)文頭的DSCP值映射到IPSec頭部的DSCP值，經(jīng)過加密MPLS網(wǎng)絡(luò)傳輸后解密，原始IP報(bào)文頭的DSCP值不變。MPLS網(wǎng)絡(luò)傳輸過程，外層DSCP值也可以映射到MPLS EXP值中去，待解密之后，可以指定原始IP報(bào)文頭的DSCP值。

如果按照DSCP優(yōu)先級(jí)協(xié)商IPSec Sa，就可以解決Qos帶來的亂序問題。

核心網(wǎng)設(shè)備根據(jù)DSCP值進(jìn)行相應(yīng)的QoS處理，承載網(wǎng)中，如果設(shè)備支持DSCP到802.1p的映射，在二層承載網(wǎng)中可根據(jù)802.1p進(jìn)行QoS處理。