定義
IPSec是Internet工程任務組（IETF）制定的一個開放的網絡層安全框架協議。它并不是一個單獨的協議，而是一系列為IP網絡提供安全性的協議和服務的集合。IPSec主要包括安全協議AH（Authentication Header）和ESP（Encapsulating Security Payload），密鑰管理交換協議IKE（Internet Key Exchange）以及用于網絡認證及加密的一些算法等。
目的
在IPv4協議誕生之時，Internet網絡的規模還非常小，Internet網絡的安全完全可以通過物理隔離的方式來保證。另一方面，所有人都未預料到以后Internet網絡會爆炸式的增長，所以在設計和開發IPv4協議時，沒有考慮IPv4協議的安全保護手段。
由于IP報文本身并不集成任何安全特性，惡意用戶很容易便可偽造IP報文的地址、修改報文內容、重播以前的IP數據包以及在傳輸途中攔截并查看數據包的內容。因此，傳統IP層協議不能擔保收到的IP數據包的安全。在應用層保證網絡安全的方法只對特定的應用有效，不夠通用。人們迫切需要能夠在IP層提供安全服務的協議，這樣可以使TCP/IP高層的所有協議受益。IPSec（Internet Protocol Security）正是用來解決IP層安全性問題的技術。
IPSec主要通過加密與驗證等方式，為IP數據包提供安全服務。IPSec可以提供的安全服務包括：
- 數據加密通過數據加密提供數據私密性。
- 數據源驗證通過對發送數據的源進行身份驗證，保證數據來自真實的發送者。
- 防止數據重放通過在接收方拒絕重復的數據包防止惡意用戶通過重復發送捕獲到的數據包進行攻擊。
受益
IPSec具有以下優點：
- 所有使用IP協議進行協議報文傳輸的應用系統和服務都可以使用IPsec，而不必對這些應用系統和服務本身做任何修改。
- 對協議報文的加密是以數據包為單位的，而不是以整個數據流為單位，這不僅靈活而且有助于進一步提高協議報文的安全性，可以有效防范網絡攻擊。
運營商場景
點到點VPN（Site-to-Site VPN）
IPSec可以為任何基于IP的通信提供安全保護，既可以保護傳統的固定網絡，也可以保護LTE等移動網絡。
點到點VPN也稱網關到網關VPN（Gateway to Gateway VPN），可以保證兩個網關之間IP流量的安全性。典型組網如圖1所示。圖1 點到點VPN組網
點到點VPN部署非常靈活，而且當兩個IPSec網關之間存在NAT設備時，支持IPSec NAT穿越。
企業場景
企業場景里IPSec主要用于公司之間通過IPSec VPN網絡互連，典型應用是點到點VPN。企業場景里IPSec的組網更加靈活多樣。
點到點VPN（Site-to-Site VPN）
點到點VPN主要用于公司總部與分支機構之間建立IPSec隧道，從而實現局域網之間互通。典型組網如圖1所示。圖1 點到點VPN組網
點到多點VPN（Hub-Spoke VPN）
實際組網中最常見的是公司總部與多個分支機構通過點到多點IPSec VPN互通，典型組網如圖2所示。圖2 Hub-Spoke VPN組網
在這種組網中，用戶可以根據實際需求配置IPSec。
此時網絡內數據流量可能存在如下兩種情況：
- 各分支機構之間不需要通信只有總部和分支之間部署IPSec VPN，也只有總部和分支之間存在業務流量。如圖3所示。圖3 Hub-Spoke VPN組網應用一
- 各分支機構之間需要通信分支機構之間通過總部進行通信，如圖4所示。圖4 Hub-Spoke VPN組網應用二
分支機構用戶上網控制
在點到點或點到多點VPN中，分支機構用戶上網可以通過兩種方式來實現。
- 分支機構用戶通過總部接入Internet為進行統一管理和監控，分支機構用戶不允許通過自身的網關接入Internet，只能通過VPN接入到總部，然后通過總部訪問Internet。分支訪問Internet的流量一般需要在總部做NAT才能到公網。如圖5所示。圖5 分支機構用戶通過總部接入Internet
- 分支機構用戶自行接入Internet對分支機構的上網流量不做控制，如圖6所示。圖6 分支機構用戶自行接入Internet
安全協議
IPSec通過AH（Authentication Header，驗證頭）和ESP（Encapsulating Security Payload，封裝安全載荷）兩個安全協議實現IP報文的封裝/解封裝。
- AH是報文頭驗證協議，主要提供數據源驗證、數據完整性驗證和防報文重放功能，不提供加密功能。
- ESP是封裝安全載荷協議，主要提供加密、數據源驗證、數據完整性驗證和防報文重放功能。
雖然AH協議和ESP協議都可以提供數據源驗證和數據完整性校驗服務，但是兩者不能互相取代。兩者之間的差別在于驗證報文的范圍不同，驗證范圍請參見封裝模式。
AH和ESP協議的簡單比較如表1所示。
從上表中可以看出兩個協議各有優缺點，AH協議不提供數據加密功能，ESP的驗證范圍不包括IP頭，其安全性不如AH，故在安全性要求較高的場景中可以考慮聯合使用AH協議和ESP協議。AH協議和ESP協議聯合使用時，需要先使用ESP，這是因為AH對整個IP數據報文進行認證，如果先使用AH再使用ESP，ESP的頭和尾會改變數據報文的長度，而且ESP的填充字段也會改變數據報文的長度，造成AH認證失敗。
封裝模式
目前NE支持隧道模式。
隧道模式
隧道模式的報文格式如圖1所示。在隧道模式下，原始IP數據報文被封裝成一個新的IP數據報文，并在舊IP報文頭（圖1中的IP Header）和新IP報文頭（圖1中的New IP Header）之間插入一個IPSec報文頭（AH或ESP），原IP地址被當作有效載荷的一部分受到IPSec的安全保護。圖1 隧道模式的報文格式
隧道模式隱藏了原始IP報文頭信息，因此主要應用于兩臺VPN網關之間或一臺主機與一臺VPN網關之間的通信。
隧道模式下，AH協議的完整性驗證范圍為包括新增IP頭在內的整個IP報文。ESP協議驗證報文的完整性檢查部分包括ESP頭、原IP頭、傳輸層協議頭、數據和ESP尾，但不包括新IP頭，因此ESP協議無法保證新IP頭的安全。ESP的加密部分包括傳輸層協議頭、數據和ESP尾。
當安全協議同時采用AH和ESP時，AH和ESP協議必須采用相同的封裝模式。
加密算法
加密是一種將數據從明文轉換成無法讀懂的密文的過程，接收方只有在擁有正確的密鑰的情況下才能對密文進行解密，從而保證了數據的私密性。
IPSec VPN工作過程中涉及數據加密（IP報文加密）和協議消息加密（ISAKMP消息加密）兩種情況。
數據加密
ESP能夠對IP報文內容進行加密保護，以防止IP報文內容在傳輸過程中被窺探。IPSec采用對稱加密算法對數據進行加密和解密。對稱加密算法是指數據發送方和接收方使用相同的密鑰進行加密、解密。
采用對稱加密算法進行數據加密和解密的過程如圖1所示。圖1 加密和解密的過程
用于加密的對稱密鑰可以手工配置，也可以通過DH算法生成并在兩端設備共享。有關DH算法具體能夠生成哪些密鑰及密鑰的作用請參見IKEv1 Phase-1 Negotiation。
一般來說IPSec使用以下加密算法：
- DES（Data Encryption Standard）：使用64bit的密鑰對一個64bit的明文塊進行加密。
- 3DES（Triple Data Encryption Standard）：使用三個64bit的DES密鑰（共192bit密鑰）對明文形式的IP報文進行加密。
- AES-CBC-128（Advanced Encryption Standard Cipher Block Chaining 128）：使用128bit加密算法對IP報文進行加密。
- AES-CBC-192（Advanced Encryption Standard Cipher Block Chaining 192）：使用192bit加密算法對IP報文進行加密。
- AES-CBC-256（Advanced Encryption Standard Cipher Block Chaining 256）：使用256bit加密算法對IP報文進行加密。
3DES比DES安全得多，但是其加密速度慢于DES。AES比3DES更安全。
協議消息加密
協議消息加密用于IKE協商階段。協議消息加密所用的算法也是DES、3DES和AES。用于加密的對稱密鑰通過DH算法生成。有關DH算法具體能夠生成哪些密鑰及密鑰的作用請參見IKEv1 Phase-1 Negotiation。
認證算法
IPSec采用Hmac（Keyed-Hash Message Authentication Code）功能進行認證。HMAC是HASH函數（單向散列函數）和消息認證碼MAC（Message Authentication Code）的結合，HMAC利用Hash函數，以一個對稱密鑰和一個數據包作為輸入，生成一個固定長度的輸出，這個輸出被稱為完整性校驗值ICV（Integrity Check Value）。接收方通過比較自身生成的ICV和對端發送的ICV來判斷數據的完整性和真實性。
數據源驗證和數據完整性驗證統一被稱為驗證。因為這兩種安全服務總是綁定在一起提供的。數據完整性驗證是基于每個IP數據包進行計算；將完整性驗證密鑰同IPSec對端身份綁定的結果間接提供了數據源驗證。
雖然加密后的數據只能通過原始的加密密鑰進行解密，但是無法驗證解密后的信息是否是原始發送的信息。另外加密和解密的過程非常的消耗CPU資源，惡意用戶可能會通過發送欺騙數據包，占用CPU資源。HMAC功能通過比較數字簽名進行數據包完整性和真實性驗證，這個過程消耗的CPU資源非常少，效率非常高。
所以在IPSec VPN發送設備中，加密和驗證通常配合使用。加密后的報文經HMAC生成數字簽名，IP報文和數字簽名同時發給對端（數字簽名填寫在AH和ESP報文頭的完整性校驗值ICV字段，請參見安全協議）；在接收設備中，通過比較數字簽名進行數據完整性和真實性驗證，驗證不通過的報文直接丟棄，驗證通過的報文再進行解密。
加密和HMAC驗證配合使用的過程如圖1所示。圖1 HMAC驗證過程
用于驗證的對稱密鑰可以手工配置，也可以通過DH算法生成并在兩端設備共享。有關DH算法具體能夠生成哪些密鑰及密鑰的作用請參見IKEv1協商安全聯盟的過程。
一般來說IPSec使用以下幾種認證算法：
- MD5（Message Digest 5）：輸入任意長度的消息，產生一個128比特的消息摘要。
- SHA-1（Secure Hash Algorithm）：輸入長度小于264比特的消息，然后生成一個160比特的消息摘要。
- SHA2-256：通過輸入長度小于264比特的消息，產生256比特的消息摘要。
- SHA2-384：通過輸入長度小于2128比特的消息，產生384比特的消息摘要。
- SHA2-512：通過輸入長度小于2128比特的消息，產生512比特的消息摘要。
SHA-2的消息摘要長于MD5和SHA-1，因此，SHA-2比MD5和SHA-1更安全。
密鑰交換
IKEv1和IKEv2的協商過程中，隧道兩端需要進行密鑰材料的交換，以便使用相同密鑰進行正確的加密和解密。
密鑰交換方法
使用對稱密鑰進行加密、驗證時，如何安全地共享密鑰是一個很重要的問題。有兩種方法解決這個問題：
- 帶外共享密鑰在發送、接收設備上手工配置靜態的加密、驗證密鑰。雙方通過帶外共享的方式（例如通過電話或郵件方式）保證密鑰一致性。這種方式的缺點是可擴展性差，在點到多點組網中配置密鑰的工作量成倍增加。另外，為提升網絡安全性需要周期性修改密鑰，這種方式下也很難實施。
- 使用一個安全的連接分發密鑰IPSec使用IKE協議在發送、接收設備之間安全地協商密鑰。IKE采用DH算法在不安全的網絡上安全地交換密鑰信息，并生成加密、驗證密鑰。這種方式配置簡單，可擴展性好，特別是在大型動態的網絡環境下此優點更加突出。
IKE提供密鑰交換，自動協商建立安全聯盟等服務。采用IKE協議可以使IPSec配置和管理更簡單、更靈活。
- Internet安全聯盟和密鑰管理協議ISAKMP（Internet Security Association and Key Management Protocol）是IKE的基礎，IKE使用ISAKMP協議定義密鑰交換的過程。ISAKMP提供了對安全服務進行協商的方法，密鑰交換時交換信息的方法，以及對對等體身份進行驗證的方法。
- IKE的精髓在于它永遠不在不安全的網絡上傳送密鑰，而是通過一些數據的交換，通信雙方最終計算出共享的密鑰，并且即使第三方截獲了雙方用于計算密鑰的所有交換數據，也無法計算出真正的密鑰。其中的核心技術就是DH（Diffie Hellman）交換技術。
DH密鑰交換
DH用于產生密鑰材料，并通過ISAKMP消息在發送和接收設備之間進行密鑰材料交換。然后，兩端設備各自計算出完全相同的對稱密鑰。該對稱密鑰用于加密和驗證密鑰的計算。在任何時候，雙方都不交換真正的密鑰。
DH密鑰交換過程如圖1所示。圖1 DH密鑰交換過程
- 進行DH交換的雙方各自產生一個隨機數，如a和b。
- 使用雙方確認的共享的公開的兩個參數：底數g和模數p各自用隨機數a和b進行冪和模運算，得到結果c和d，計算公式如下：c=gamod(p)d=gbmod(p)
- 交換計算所得的結果c和d
- 各自進一步計算，得到一個共同的DH公有值：damod(p)=cbmod(p)=gabmod(p)，此公式可以從數學上證明。DH公有值就是雙方的密鑰。
若網絡上的第三方截獲了雙方的模c和d，那么要計算出DH公有值gabmod(p)還需要獲得a或b，a和b始終沒有直接在網絡上傳輸過。如果想由模c和d計算a或b就需要進行離散對數運算，而p為素數，當p足夠大時（一般為768位以上的二進制數），數學上已經證明，其計算復雜度非常高，從而認為是不可實現的。所以，DH交換技術可以保證雙方能夠安全地獲得密鑰信息。
DH使用密鑰組來定義自己產生的密鑰長度。密鑰長度越長，產生的密鑰就越安全，但所需的計算時間也依次遞增。
IPSec安全聯盟
IPSec在兩個端點之間提供安全通信，這兩個端點被稱為IPSec對等體。
安全聯盟（Security Association）是通信對等體間對某些要素的約定。它定義了保護IP報文安全的協議（AH或者ESP）、IP報文的封裝模式、認證算法、保護IP報文的共享密鑰等。通過安全聯盟實現了IPSec對IP報文的保護。安全聯盟是IPSec的基礎，也是IPSec的本質。
SA是單向的，輸入的IP報文和輸出的IP報文由入方向安全聯盟和出方向安全聯盟分別處理。因此，如果有兩個設備（DeviceA和DeviceB）使用ESP進行通信，則必須在DeviceA上設置兩個SA，一個用于處理外發IP報文，另一用于處理接收IP報文。同樣地，DeviceB也需要兩個SA。如圖1所示。圖1 SA的單向邏輯連接
安全聯盟還與協議相關。如果主機A和主機B同時使用AH和ESP進行安全通信，對于主機A就需要四個SA，AH協議的兩個SA（入方向和出方向上各一個SA）和ESP協議的兩個SA（入方向和出方向上各一個SA）。同樣地，主機B也需要四個SA。
安全聯盟由一個三元組來唯一標識。這個三元組包括：安全參數索引SPI（Security Parameter Index）、目的IP地址、安全協議號（AH或ESP）。SPI是為唯一標識SA而生成的一個32比特的數值，它在AH和ESP頭中傳輸。
安全聯盟建立方式
安全聯盟可通過手工配置和自動協商兩種方式建立。
- 手工建立安全聯盟的方式是指用戶通過在兩端手工設置一些參數，在兩端參數匹配和協商通過后建立IPSec安全聯盟。手工方式配置比較復雜，創建IPSec安全聯盟所需的全部信息都必須手工配置，而且不支持IPSec的一些高級特性（例如定時更新密鑰），但優點是可以不依賴IKE而單獨實現IPSec功能。手工方式目前主要用于協議報文的認證，例如RIPng、OSPFv3、IGMP、MLD、PIM和DHCPv6 Relay等。
- 自動協商方式由IKE生成和維護，通信雙方基于各自的安全策略庫經過匹配和協商，最終建立安全聯盟而不需要用戶的干預。IKE屬于一種混合型協議，它建立在由Internet安全聯盟和密鑰管理協議ISAKMP（Internet Security Association and Key Management Protocol）定義的一個框架上。它能夠為IPSec提供自動協商交換密鑰、建立安全聯盟的服務，以簡化IPSec的使用和管理。IKE分為IKEv1和IKEv2兩個版本，二者建立安全聯盟的方式大體相同，具體請參考IKEv1協商安全聯盟的過程和IKEv2協商安全聯盟的過程。
IKE的安全機制
- DH密鑰交換。
- 完善的前向安全性PFS（Perfect Forward Secrecy）：指一個密鑰被破解，并不影響其他密鑰的安全性，因為這些密鑰間沒有派生關系。PFS是由DH算法保障的。此特性是通過在IKE階段2的協商中增加密鑰交換來實現的。
- 身份驗證：身份驗證用于確認通信雙方的身份。對于pre-shared key驗證方法，驗證字用來作為一個輸入產生密鑰，驗證字不同是不可能在雙方產生相同的密鑰的。驗證字是驗證雙方身份的關鍵。
- 身份保護：身份數據在密鑰產生之后加密傳送，實現了對身份數據的保護。
IKEv1協商安全聯盟的過程
采用IKEv1協商安全聯盟主要分為兩個階段。
- IKEv1階段1的目的是建立IKE SA。IKE SA建立后對等體間的所有ISAKMP消息都將通過加密和驗證，這條安全通道可以保證IKEv1階段2的協商能夠安全進行。
- IKEv1階段2的目的就是建立用來傳輸數據的IPSec SA。
IKEv1協商階段1
IKEv1階段1主要協商下面三個任務：
- 協商建立IKE SA所使用的參數。加密算法、完整性驗證算法、身份認證方法和認證字、DH組、IKE SA生存周期等等。這些參數在IKE安全提議中定義。
- 使用DH算法交換與密鑰相關的信息（生成各種密鑰的材料）。對等體雙方設備能夠使用這些密鑰信息各自生成用于ISAKMP消息加密、驗證的對稱密鑰。
- 對等體之間驗證彼此身份。使用預共享密鑰或數字證書來驗證設備身份。
這三個任務都協商成功后，IKE SA就建立成功了。
IKEv1階段1支持兩種協商模式：主模式（Main Mode）和野蠻模式（Aggressive Mode）
主模式
主模式采用三個步驟來完成上述三個任務。每個步驟需要2個ISAKMP報文，共6個ISAKMP報文。交換密鑰相關信息的操作在身份認證之前完成，故設備的身份信息受到已生成的共享密鑰的保護。
采用主模式時IKEv1階段1的協商過程如圖1所示。圖1 主模式下IKEv1階段1的協商過程
下面對這三個步驟進行詳細說明：
- 協商對等體之間使用的IKE安全提議。DeviceA發送ISAKMP消息，攜帶建立IKE SA所使用的參數（由IKE安全提議定義）。DeviceB對DeviceA的IKE安全提議進行協商。在協商時將從優先級最高的提議開始匹配，協商雙方必須至少有一條匹配的IKE安全提議才能協商成功。匹配的原則為協商雙方具有相同的加密算法、認證算法、認證方法和Diffie-Hellman組標識。DeviceB響應ISAKMP消息，攜帶經協商匹配的安全提議及參數。 如果沒有匹配的安全提議，DeviceB將拒絕發起方的安全提議。
- 使用DH算法交換與密鑰相關的信息，并生成密鑰。兩個對等體通過兩條ISAKMP消息（3、4）交換與密鑰相關的信息。由獲得的密鑰信息推導出4個密鑰。其中SKEYID為基礎密鑰，通過它可以推導出SKEYID_a，為ISAKMP消息完整性驗證密鑰；可以推導出SKEYID_e，為ISAKMP消息加密密鑰；可以推導出SKEYID_d，用于衍生出IPSec報文加密、驗證密鑰。預共享密鑰方式和數字證書方式下SKEYID的計算公式不同。圖2 DH密鑰生成
- 對等體之間驗證彼此身份。兩個對等體通過兩條ISAKMP消息（5、6）交換身份信息（預共享密鑰方式下為IP地址或名稱，數字證書方式下還需要傳輸證書的內容），身份信息通過SKEYID_e加密，故可以保證身份信息的安全性。兩個對等體使用IKE安全提議中定義的加密算法、驗證算法、身份驗證方法和SKEYID_a、SKEYID_e對IKE消息進行加解密和驗證。IKEv1支持如下身份驗證方法：預共享密鑰這種方法要求對等體雙方必須要有相同的預共享密鑰（該密鑰直接參與SKEYID的生成計算）。對于設備數量較少的VPN網絡來說易于配置，在大型VPN網絡中，不建議采用預共享密鑰來做身份驗證。RSA簽名（通常稱為數字證書）數字證書需要由CA服務器來頒發。這種方法適用于大型動態的VPN網絡。證書驗證和預共享密鑰驗證的主要區別在于SKEYID的計算和交換的身份信息，其他的交換和計算過程和預共享密鑰驗證方式相同。數字信封認證在數字信封認證中，發起方采用對稱密鑰加密信息內容，并通過非對稱密鑰的公鑰加密對稱密鑰，從而保證只有特定的對端才能閱讀通信的內容，從而確定對端的身份。此認證方法只能在IKEv1的主模式協商過程中使用，不能在IKEv1野蠻模式協商過程中使用。
野蠻模式
野蠻模式僅交換3個消息就可以完成IKE SA的建立。
采用野蠻模式時IKEv1階段1的協商過程如圖3所示。圖3 野蠻模式下IKEv1階段1的協商過程
野蠻模式時IKEv1階段1的協商過程：
- DeviceA發送ISAKMP消息，攜帶建立IKE SA所使用的參數、與密鑰生成相關的信息和身份驗證信息。
- DeviceB對收到的第一個數據包進行確認，查找并返回匹配的參數、密鑰生成信息和身份驗證信息。
- DeviceA回應驗證結果，并建立IKE SA。
與主模式相比，野蠻模式的優點是建立IKE SA的速度較快。但是由于密鑰交換與身份認證一起進行，野蠻模式無法提供身份保護。
主模式與野蠻模式的區別
野蠻模式安全性比主模式差。但是野蠻模式可以滿足某些特定場合的網絡環境的需求。例如：
- 遠程訪問時，如果響應者（服務器端）無法預先知道發起者（終端用戶）的地址、或者發起者的地址總在變化時，而雙方都希望采用預共享密鑰驗證方法來創建IKE SA，此時可以采用野蠻模式。NE采用預共享認證方式，若是可以獲取出口網關的代理IP，也可以在此種情形下采用主模式下配置代理IP的方式。
- 如果發起者已知響應者的策略，或者對響應者的策略有全面的了解，采用野蠻模式能夠更快地創建IKE SA。
IKEv1協商階段2
IKEv1階段2的目的就是建立用來傳輸數據的IPSec SA。IPSec SA與IKE SA的關系如圖4所示。圖4 IPSec SA與IKE SA的關系
IKEv1階段2通過快速交換模式完成。由于快速交換模式使用IKEv1階段1中生成的密鑰SKEYID_a對ISAKMP消息的完整性和身份進行驗證，使用密鑰SKEYID_e對ISAKMP消息進行加密，故保證了交換的安全性。
在快速交換模式中，對等體兩端協商IPSec SA的各項參數，并為數據傳輸衍生出密鑰。
快速模式的協商過程如圖5所示。圖5 IKEv1階段2協商過程
快速模式共有3條消息完成雙方IPSec SA的建立。
- 消息1發送本端的安全參數和身份認證信息。安全參數包括被保護的數據流和IPSec安全提議等需要協商的參數。身份認證信息包括第一階段計算出的密鑰和第二階段產生的密鑰材料等，可以再次認證對等體。
- 消息2響應消息1，發送響應方的安全參數和身份認證信息并生成新的密鑰。對等體雙方通過交換密鑰材料生成新的共享密鑰，并最終衍生出IPSec的加密密鑰。此時響應者和發送者各有兩個SA。IPSec SA數據傳輸需要的加密、驗證密鑰由SKEYID_d、SPI、協議等參數衍生得出，以保證每個IPSec SA都有自己獨一無二的密鑰。當啟用PFS時，要再次應用DH算法計算出一個共享密鑰，然后參與上述計算，因此在參數協商時要為PFS協商DH密鑰組。
- 消息3響應消息2，確認與響應方可以通信，協商結束。
IKEv2協商安全聯盟的過程
要建立一對IPSec SA，IKEv1需要經歷兩個階段：“主模式＋快速模式”或者“野蠻模式＋快速模式”。前者至少需要交換9條消息，后者也至少需要6條消息。而IKEv2，正常情況使用2次交換共4條消息就可以完成一個IKE SA和一對IPSec SA，如果要求建立的IPSec SA大于一對時，每一對SA只需額外增加1次交換，也就是2條消息就可以完成。這比IKEv1要簡化很多。
IKEv2協商安全聯盟的過程
IKEv2定義了三種交換：初始交換、創建子SA交換以及通知交換。
- 初始交換IKE通信總是從IKE安全聯盟初始交換（IKE_SA_INIT交換）和IKE認證交換（IKE_AUTH交換）開始。這2個交換通常由4條消息組成，在某些場景下消息數目可能會增加。所有使用IKE的通信都由請求/響應對組成。IKE安全聯盟初始交換和IKE認證交換完成后可以建立一個IKE SA和第一對CHILD_SA（即IPSec SA）。具體如圖1所示。圖1 IKEv2初始階段的協商過程
詳細說明如下：第一個消息對（IKE_SA_INIT）這個消息對負責進行IKE安全聯盟參數的協商，包括協商加密和驗證算法，交換臨時隨機數（nonces）和DH交換。IKE_SA_INIT交換后可以生成一個共享密鑰材料。通過這個共享密鑰材料可以生成其他相關密鑰。第二個消息對（IKE_AUTH）從IKE_AUTH交換開始，所有報文都必須加密再交換。IKE_AUTH交換至少需要兩個消息。在這兩個報文的交互中完成了身份認證以及一個CHILD_SA的創建過程。IKEv2支持RSA簽名認證、預共享密鑰認證。RSA簽名認證和預共享密鑰認證方式下，認證載荷（AUTH載荷）的計算方式不同。在IKE_SA_INIT交換階段，生成IPSec SA的密鑰材料，并通過這個密鑰材料衍生出IPSec SA的所有密鑰。IKEv2除支持RSA簽名和預共享密鑰認證外，還支持擴展認證方法EAP（Extensible Authentication Protocol）。EAP認證是作為附加的IKE_AUTH交換在IKE中實現的。發起者通過在消息3中省去AUTH載荷來表明需要使用EAP認證。 - 創建子SA交換當一個IKE SA需要創建多對IPSec SA時，需要使用創建子SA交換來協商多于一對的SA。另外創建子SA交換還可以用于進行IKE SA的重協商。創建子SA交換包含一個交換兩個消息。在IKEv1中這個交換稱為階段2交換（快速模式交換）。這個交換必須在IKE初始交換完成之后才能進行，交換的發起者可以是IKE初始交換的發起者，也可以是IKE初始交換的響應者。在交換中的兩個消息需要由IKE初始交換協商的密鑰進行保護。類似于IKEv1的PFS，創建子SA交換階段可以重新進行一次DH交換，生成新的密鑰材料。生成密鑰材料后，子SA的所有密鑰都從這個密鑰材料衍生出來。
- 通知交換運行IKE協商的兩端有時會傳遞一些控制信息，例如錯誤信息或者通告信息，這些信息在IKEv2中是通過通知交換完成的。通知交換必須在IKE SA保護下進行，也就是說通知交換只能發生在初始交換之后。
IPSec報文處理流程
IPSec安全聯盟建立以后，可以對IP報文做加解密處理。與IPSec報文轉發相關的概念如下：
- 安全策略數據庫SPDB（Security Policy Database）：定義IP數據報文應使用何種安全服務，以及如何獲得這些服務。SPDB是SA創建的前提，決定了SA的作用范圍和相關屬性。
- 安全聯盟數據庫SADB（Security Association Database）：存放與SA關聯的所有狀態數據的存儲結構。因為一個網絡實體可以創建多對SA，所以需要有個DB來做存儲管理。
- SPI（安全參數索引）：一個攜帶在AH或ESP頭部的一個32位數值，接收端通過SPI來判斷接收到的數據流應該用SADB中的哪個SA來做安全保護。
IPSec對于發送報文的處理流程如圖1所示。圖1 IPSec發送報文處理流程
IPSec對于接收報文的處理流程如圖2所示。圖2 IPSec接收報文處理流程
IPSec DPD
DPD
當兩個對等體之間采用IKE和IPSec進行通信時，對等體之間可能會由于路由問題、對等體重啟或其他原因等導致連接斷開。IKE協議本身沒有提供對等體狀態檢測機制，一旦發生對等體不可達的情況，只能等待安全聯盟的生存周期到期。生存周期到期之前，對等體之間的安全聯盟將一直存在。安全聯盟連接的對等體不可達將引發“黑洞”，導致數據流被丟棄。通常情況下，迫切需要識別和檢測到這些“黑洞”，以便盡快的恢復IPSec通信。
Keepalive機制可以解決這個問題。Keepalive機制是指IKE對等體間通過周期性的交換Hello/Ack消息來告知對方自己處于活動狀態。但是在設備上的IKE SA數量很大時，發送的Hello/Ack消息將會大量消耗設備的CPU資源，限制了這種機制的應用。
失效對等體檢測DPD（Dead Peer Detect）是Keepalive機制的一種替代機制，它利用IPSec流量使對等體狀態檢測所需消息的數量達到最小化。DPD規定每個IKE peer的狀態和對端狀態是完全獨立的，當IKE peer想知道對端是否在線時，隨時請求，不需要等待間隔時間的到來。當peer之間有正常的IPSec流量時，證明對端肯定在線，此時沒有必要去發送額外的消息探測對端是否在線。只有一段時間內沒有流量發生，peer的活動狀態才值得懷疑，那么本端在發送流量前應該發送一次DPD消息來檢測對端的狀態。
DPD有兩種模式可以選擇：interval和on-demand。
interval：表示DPD工作在輪詢模式，在check-interval時間內，如果沒有收到對端發過來的流量就會以check-interval為周期循環發送DPD檢測報文。如果期間收到對端的響應報文，那么本次DPD流程結束，進入新的DPD檢測周期。如果期間沒有收到對端的響應報文，則會進行報文重傳。重傳結束后，如果依然沒有收到響應則會刪除本端SA表項，重新執行隧道新建流程。
on-demand：表示DPD工作在流量觸發模式，如果本端沒有加密流量發送，那么是不會發送DPD報文的，這是和輪詢模式的最大區別。如果本端有加密流量需要發送，并且發送后在check-interval時間內沒有收到對端發過來的流量，那么就會以check-interval為周期循環發送DPD檢測報文。如果期間收到對端的響應報文，那么本次DPD流程結束，進入新的DPD檢測周期。如果期間沒有收到對端的響應報文，則會進行報文重傳。重傳結束后，如果依然沒有收到響應則會刪除本端SA表項，重新執行隧道新建流程。
IPSec安全性
IKEv2的安全性分析
此處著重分析IKEv2的安全性。
IKEv2對傳統IKE存在的安全漏洞進行了修訂，提高了密鑰協商的安全性，并明確規定了所有的消息必須以請求/響應對的形式存在，有效的解決了使用UDP作為傳輸層協議的不可靠性問題。
以下從三方面來討論IKEv2的安全性問題。
- 抵御中間人攻擊中間人攻擊（Man-in-the-middle Attack）是一種主動攻擊，指攻擊者對通信雙方進行竊聽，截獲通信雙方的消息并進行任意插入、刪除或篡改消息，之后返回消息給發送者，或者重放舊消息以及重定向消息，是最危險的攻擊。IKEv2中抵御中間人攻擊的機制和方法：密鑰材料生成方式與傳統IKE相比，IKEv2的密鑰材料發生了變化，雙方用于后繼交互使用的加密密鑰與認證密鑰都是不同的。這些密鑰是從prf+輸出流中依次提取，從而增加了攻擊者猜測密鑰的難度，減少了密鑰泄漏的可能性，增強了傳輸的安全性，一定程度上可以抵御中間人攻擊。身份認證IKEv2使用預共享密鑰和數字簽名方式進行身份認證。身份認證方式具有交互性，參與協商的實體彼此都對對方的身份進行認證；具有對稱性，參與協商的雙方都使用相同的機制或方法對對方的身份進行認證。雙向的身份認證可以有效地抵御中間人攻擊。同時IKEv2定義了擴展認證交互，即使用擴展認證協議（EAP）描述的方法對IKEv2協商進行身份認證，支持非對稱雙向認證，進一步加強了認證的靈活性和協商的可擴展性。消息交換IKEv2將傳統IKE主模式交換的六條消息修訂為四條消息，將SA載荷和KE載荷、nonce載荷一同發送，這樣，消息中包含隨機的nonce值，如果攻擊者偽裝成響應方進行應答，將收到的發起方的消息基本上不做改變，再發回給發起方，發起方可以根據消息內容判斷消息的真假，在一定程度上可以抵御重放攻擊。每個IKEv2消息的頭都包含了一個消息ID，用于匹配對應的請求和響應消息以及識別消息重傳。當發送和接收到請求時，必須對消息ID值順序增加，且除了IKE_SA_INIT交互外其值受加密和完整性保護，使得它能夠防重放攻擊。同時IKEv2加入了滑動窗口機制，使交互能夠更加有效地抵御重放攻擊的威脅。
- 抵御DDoS（Distributed Denial of Service）攻擊IKEv2中抵御DDoS攻擊的機制和方法：SPI值IKEv2消息頭部有發起方SPIi和響應方SPIr，它們是內核產生的8字節的隨機數，用來標識SA，同時也可以標識進行消息交換的一對節點。具有相同SPI值的請求處理一次（重傳消息除外），而把其他請求作為重復數據包丟棄，可以在一定程度上防止DDoS攻擊。帶Cookie交互IKEv2中使用N載荷攜帶Cookie的輔助交換來抵御拒絕服務攻擊。在通信過程中，響應方認為自己正受到DDoS攻擊時，可以向發起方請求回復一個無狀態cookie。響應方收到對方發來的第一條消息后并不急于進行IKE_SA_INIT交互，而是再產生一個新的cookie，封裝在通知載荷中發送給對方。如果發起方不是攻擊者，就可以收到這條消息，然后重新開始協商，并將響應方的cookie封裝在該消息中，其它載荷內容保持不變。重傳約定IKEv2中所有消息都是成對出現，在每對消息中，發起方負責重傳事件，響應方不必對其響應消息進行重傳，除非收到對方的一個重傳請求。避免了雙方同時發起重傳，造成資源的浪費，同時也可以防止攻擊者截獲消息后，偽裝成協商者不斷地發送重傳消息，耗費協商雙方的資源。丟棄半開（half-open）連接IKEv2只能通過兩種情況判斷對方是否失效：一種是重復嘗試聯系對方，直到應答時間過期；另一種是收到對方的不同IKE SA加密保護下的INITIAL CONTACT通知消息。IKEv2發起方允許多個響應方響應第一條消息，并把所有的響應方視為合法并作回應。發起方發送一些消息后，一旦收到一個有效的加密的響應消息，將其他的響應消息忽略，并將其他所有的無效的半連接丟棄。這樣在協商開始時就可以避免受到DDoS攻擊。
- 完善的前向安全性PFS（Perfect Forward Secrecy）IPSec SA數據傳輸需要的加密、驗證密鑰由SKEYID_d、SPI、協議等參數衍生得出，可以保證每個IPSec SA都有自己獨一無二的密鑰。但是由于所有IPSec SA密鑰都是相同的來源產生的，所以這些IPSec SA密鑰相互間都有關聯，假如有攻擊者能夠根據IKE SA判斷出SKEYID_d的值，那么就能非常容易的掌握從該SKEYID_d衍生出來的所有IPSec SA的密鑰。IPSec專門提供PFS特性來解決這個問題，實現思路是：IKEv2初始交互的密鑰衍生材料不被用于衍生供IPSec SA使用的相關密鑰，而是通過在CREATE_IPSec_SA交互中引入可選的IKE載荷重新進行一次額外的DH交換來生成密鑰材料。通過這種方式，IPSec密鑰之間相互沒有關聯，即使攻擊者攻克了一個密鑰，也只能破解這個密鑰保護的數據，而不能破解受其它密鑰保護的數據。
防重放
IPSec中的重放攻擊（Replay Attack）主要是指攻擊者大量發送目的主機已接收過的數據包，大量消耗系統資源，可能導致系統CPU資源耗盡。
IPSec利用序列號和滑動窗口來實現防重放（Anti-Replay）。IPSec中AH和ESP協議報文頭中有個序列號字段（Sequence Number）專門用于防重放攻擊。
通信雙方協商好IPSec SA之后，序列號字段被置為0，此后發送方每發出一個報文，該數值加1。接收方存在一個防重放滑動窗口和已接收報文的序列號數據庫。
- 如果該序列號的報文從未被接收過，且在防重放窗口內，接收方就接收該報文。如果該序列號的報文已經被接收過，則認為是重放攻擊，丟棄該報文。
- 如果該序列號在防重放窗口的左側（小于防重放窗口的最小值），則認為是已經接收的報文，因而被丟棄。
- 如果該序列號在防重放窗口的右側（大于防重放窗口的最大值），則認為未被接收的報文，會正常接收，同時觸發防重放窗口向右滑動。
下面結合圖1詳細描述防重放的原理。圖1 防重放示意圖
- 如圖1（a）所示，初始防重放窗口是[0–63]，序列號在此范圍內的報文會被正常接收，接下來如果接收到序列號大于63的報文，也會正常接收，并且防重放窗口向右滑動。但是如果再次收到序列號在[0–63]范圍內的報文，則認為是重放攻擊，拒絕接收報文。
- 如果此時收到序列號為66的報文，則防重放窗口滑動到[3–66]，接下來如果接收到序列號大于66的報文，也會正常接收，具體如圖1（b）所示。此時[0–2]這三個序列號已經不在防重放窗口范圍內，如果再次收到此范圍內的報文，則會認為是已經接收過的報文，所以會丟棄這些報文。
- 如圖1（c）所示，假如報文發生亂序，接收端先接收到序列號為67的報文，則防重放窗口滑動到[4–67]。然后再接收到序列號為3的報文，雖然該報文之前從未接收過，但是因為其序列號已經在防重放窗口之外，因此也被丟棄。從這一點可以看出，在報文亂序情況下，防重放窗口設置越大，報文被錯誤丟棄的幾率就越低，反之就越高。
安全聯盟生存周期
為了防止密鑰長期使用而帶來的安全隱患，安全聯盟存在生存周期。衡量生存周期有兩種方式：基于時間的生存周期和基于流量的生存周期。
- 基于時間的生存周期是從安全聯盟建立開始的時刻起，此安全聯盟存活的時間。
- 基于流量的生存周期是此安全聯盟允許處理的最大流量。
其中IPSec安全聯盟兩種方式都支持，IKE安全聯盟并不傳輸IPSec流量，因此僅支持基于時間的生存周期。IPSec安全聯盟和IKE安全聯盟的生存周期可以分別配置，互不干擾。
對于IKE安全聯盟的生存周期：
- 如果生存周期超時，IKE SA將自動更新。因為IKE協商需要進行DH計算，需要經過較長的時間，為使IKE SA的更新不影響安全通信，建議設置生存周期大于10分鐘。
- SA在設定的生存周期超時前會提前協商另一個SA來替換舊的SA。在新的SA還沒有協商完之前，依然使用舊的SA；在新的SA建立后，將立即使用新的SA，舊的SA會被自動清除。
對于IPSec安全聯盟的生存周期：如果生存周期到達指定的時間或指定的流量，則IPSec安全聯盟就會失效。IPSec安全聯盟失效前，IKE將為IPSec協商建立新的IPSec安全聯盟，這樣在舊的IPSec安全聯盟失效前新的IPSec安全聯盟就已經準備好。在新的IPSec安全聯盟開始協商而沒有協商好之前，繼續使用舊的IPSec安全聯盟保護通信。在新的IPSec安全聯盟協商好之后，則立即采用新的IPSec安全聯盟保護通信。
此外，為了方便對于IPSec安全聯盟的生存周期進行配置，系統支持局部超時和全局超時兩種配置模式，局部超時時間是針對某個IPSec SA的超時時間。全局超時時間是針對系統中所有IPSec SA的超時時間。當IKE協商安全聯盟時，如果采用的安全策略沒有配置自己的超時時間，將采用全局超時時間與對端協商。如果安全策略配置了自己的超時時間，則系統使用安全策略自己的超時時間與對端協商。
IPSec QoS
IPSec QoS支持的功能點如表1所示。
IPSec NAT穿越
NAT技術主要用于解決IPv4地址緊缺問題，在目前網絡中NAT應用非常廣泛，特別是在企業網出口網關大都使用了NAT技術解決公網地址不足的問題。IPSec提供了端到端的IP通信的安全性，可以實現同一企業集團不同地域分支之間的低成本安全互連。但是IPSec和NAT技術本身存在不兼容的問題。
- 從NAT的角度上說，為了完成地址轉換，勢必會修改IP報文頭中的IP地址。
- 從IPSec的角度上說，IPSec要保證數據的安全，因此它會加密和校驗數據。AH主要用于保護消息的完整性，其驗證范圍包含IP報文頭，而NAT修改IP報文頭會導致AH檢查失敗，因此使用AH保護的IPSec隧道是不能穿越NAT網關的。但是ESP協議保護的報文不存在該問題，因為ESP保護的部分不包含IP報文頭（對隧道方式而言是外層IP報文頭）。
但是還是有新的不兼容問題，當NAT改變了某個包的IP地址和（或）端口號時，它通常要更新TCP或UDP校驗和。當TCP或UDP校驗和使用了ESP來加密時，它就無法更新這個校驗和。
- ESP封裝的隧道模式：ESP隧道模式將整個原始的IP包整個進行了加密，且在ESP的頭部外面新加了一層IP頭部，所以NAT如果只改變最前面的IP地址對后面受到保護的部分是不會有影響的。因此，IPSec采用ESP的隧道模式來封裝數據時可以與NAT共存。
IPSec穿越NAT的處理
IPSec NAT穿越的流程是：
- NAT穿越（NAT-Traversal，簡稱NAT-T）能力檢測：建立IPSec隧道的兩端需要進行NAT穿越能力協商，這是在IKE協商的前兩個消息中進行的，通過Vendor ID載荷指明的一組數據來標識。
- NAT網關發現：通過NAT-D（NAT-Discovery）載荷來實現的，該載荷用于在IKE Peer之間發現NAT網關的存在以及確定NAT設備在Peer的哪一側。NAT側的Peer作為發起者，需要定期發送NAT-Keepalive報文，以使NAT網關確保安全隧道處于激活狀態。
- ESP報文正常穿越NAT網關：IPSec穿越NAT，簡單來說就是在原報文的IP頭和ESP頭（不考慮AH方式）間增加一個標準的UDP報文頭。這樣，當ESP報文穿越NAT網關時，NAT對該報文的外層IP頭和增加的UDP報頭進行地址和端口號轉換；轉換后的報文到達IPSec隧道對端時，與普通IPSec處理方式相同，但在發送響應報文時也要在IP頭和ESP頭之間增加一個UDP報文頭。。
IKEv2與NAT穿越
NAT-T能力檢測
NAT-T能力檢測在IKE協商的前兩個消息中交換完成，通過在消息中插入一個標識NAT-T能力的Vendor ID載荷來告訴對方自己對該能力的支持。如果雙方都在各自的消息中包含了該載荷，說明雙方對NAT-T都是支持的。只有雙方同時支持NAT-T能力，才能繼續進行其他協商。
NAT網關發現
當存在NAT設備時必須使用UDP傳輸，所以在IKEv2中的第一階段協商中必須先探測是否存在NAT設備，也就是NAT探測。
通過發送NAT-D載荷來實現NAT探測是目前比較流行的方法。
在傳統IKE中NAT-D載荷包括在主模式的第三個和第四個信息中以及野蠻模式的第二個和第三個信息中。對于創建VPN連接的雙方來說，發送的信息中一般要包括兩個連續的NAT-D載荷，第一個是關于目的地址，第二個是關于源地址。如果發送方不知道自己的確切地址(發送方有多個接口，應用程序并不知道數據包從哪個接口出去)，則需要多個NAT-D載荷，從第二個載荷開始，每個載荷和發送方的一個地址相關。對方接收到NAT-D載荷后重新根據收到的包的實際地址端口來計算hash值后進行比較，就可以知道是否有NAT設備以及哪一方在NAT設備之后了。這種方法雖然能檢測兩個IKE對端之間NAT設備的存在，但存在著明顯的缺陷。因為在主模式和野蠻模式中，NAT-D載荷沒有被認證，這意味著入侵者可以刪除、改變、增加這些載荷，這將導致DoS攻擊。通過改變NAT-D載荷，攻擊者可以使兩方使用UDP封裝的模式，而不是使用正常的模式，導致浪費帶寬。
為了解決上述缺陷，探測通信鏈路中是否存在NAT設備，可在協商雙方增加兩個Notify載荷，一個包括NAT_DETECTION_SOURCE_IP，標識發起方的IP地址；一個包括NAT_DETECTION_DESTINATION_IP，標識目的方的IP地址。這兩個載荷主要是為了探測通信雙方是否存在NAT設備，并且確定哪一方處在NAT設備之后。
這一過程在IKEv2協商的第一組交換中進行。具體過程如下：
在IKEv2中，NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP在Notify消息類型中的編號分別為：16388和16389。載荷使用通用的ISAKMP載荷頭，載荷的值是SPIs、IP地址、發送數據包的端口號的hash值(IKEv2規定使用SHA-1)，hash值的計算如下：hash=SHA-1(SPIs|IP|Port)。其中：
- SPIs為HDR載荷中的安全索引參數。
- IP為數據包發出方或接收方的IP地址。
- Port為數據包發出方或接收方的端口號。
當接受方收到數據包后，對數據包中的SPIs、IP地址、端口號進行hash運算，并與Notify載荷進行比較，如果不匹配，則說明通信鏈路中存在NAT設備：如果與NAT_DETECTION_SOURCE_IP不匹配，則說明發起端在NAT設備之后；如果與NAT_DETECTION_DESTINATION_IP不匹配，則說明接受端在NAT設備之后。
NAT穿越的啟用
在第一階段協商完成之后，協商雙方均已經明確是否存在NAT，以及NAT的位置。至于是否啟用NAT穿越，則由快速模式協商決定。
NAT穿越的啟用協商在快速模式的SA載荷中進行。
NAT-keepalive
在NAT網關上NAT會話有一定的存活時間，因此，隧道建立后如果中間長時間沒有報文穿越，就會導致NAT會話被刪除，這樣將導致無法通過隧道傳輸數據。解決方法是在NAT會話超時前，發送一個NAT-keepalive給對端，維持NAT會話的存活。
IPSec增強功能
IPSec白名單
IPSec網關支持通過證書屬性訪問控制策略來認證IKE對端的證書，通過配置此功能也能達到類似白名單的效果。但是此方案存在以下不足：
- 配置工作量較大，管理不方便。
- 沒有提供對證書通用名稱CN（Common Name）的精確匹配。
IPSec白名單特性可以有效解決上述問題。IPSec白名單可以由用戶自己定義，然后導入設備，IPSec白名單提供對證書通用名稱CN（Common Name）的精確匹配。
IPSec白名單的具體實現過程是：在建立IPSec隧道之前進行IKE協商時，判斷是否使能了白名單檢驗功能，如果使能，則檢驗接收到的對端證書的CN字段是否在IPSec網關的白名單列表內。
- 如果對端的證書的CN字段在IPSec網關的白名單列表里面，則驗證通過，允許進行IKE協商并建立IPSec隧道。
- 如果對端的證書的CN字段不在IPSec網關的白名單列表里面，則驗證失敗，不允許進行IKE協商，最終IPSec隧道建立失敗。
通過這種方式，可以有效保證只有在數字證書白名單內的設備才能接入網絡，提高了網絡安全性。
白名單文件一般是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網關對接設備的證書的CN字段。
為了方便用戶根據實際需要刷新白名單，IPSec白名單還支持如下功能：
- 支持導入白名單，如果導入過程失敗，可以回退到導入之前的狀態。
- 支持刪除白名單。
- 支持增量添加白名單。
- 支持查看白名單內容。
如圖1所示，為了保證eNodeB和IPSec網關之間的通信安全，eNodeB和IPSec網關之間建立了IPSec隧道。而為了防止非法設備與IPSec網關之間建立IPSec隧道，可以提前在IPSec網關上配置白名單特性，從而保證只有在白名單內的設備才能接入網絡。
圖1 IPSec白名單的應用
自動生成IPSec業務路由
自動生成IPSec業務路由的功能，主要有如下兩種應用場景。
- 當使用安全策略模板方式建立IPSec隧道時，用戶可能不知道對端隧道的IPSec業務路由信息（如對端的IP地址和接口等），因此無法手工配置靜態路由，這時需要配置自動生成IPSec業務路由的功能。
- 當使用安全策略模板方式建立IPSec隧道時，會通過IPSec協商過程自動生成IPSec業務路由。當用戶希望按照自己的網絡規劃，通過配置靜態路由方式生成IPSec業務路由時，需要先去使能自動生成IPSec業務路由的功能。
IPSec擴展應用
GRE over IPSec
IPSec本身不支持封裝組播、廣播和非IP報文，GRE無法對報文進行認證加密，通過GRE over IPSec技術可以將組播、廣播報文先封裝GRE后，然后再進行IPSec加密處理。同時采用GRE的接口對接收到的加解密流量來進行統計。當網關之間采用GRE over IPSec連接時，先進行GRE封裝，再進行IPSec封裝。下面以ESP為例說明，報文的封裝格式如圖1所示。圖1 GRE over IPSec封裝模式（隧道模式）
IPSec封裝過程中增加的IP頭即源地址為IPSec網關應用IPSec策略的接口地址，目的地址即IPSec對等體中應用IPSec策略的接口地址。
IPSec需要保護的數據流為從GRE起點到GRE終點的數據流。GRE封裝過程中增加的IP頭即源地址為GRE隧道的源端地址，目的地址為GRE隧道的目的端地址。
基于GRE over IPSec的應用很多，比如BGP、LDP、OSPF、IS-IS和IPv6等協議，這些應用的原理相同，都是將協議報文使用GRE封裝成IP報文，然后再在IPSec隧道里傳輸。
IPSec和GRE結合，還有一種IPSec over GRE方案，即先使用IPSec對報文進行封裝，然后再使用GRE封裝。但是，這種封裝方式既沒有充分利用IPSec和GRE的優勢，也無法支持組播、廣播和非IP報文，因此一般不推薦使用。
L2VPN/L3VPN場景IPSec應用
L2VPN CE作為IPSec安全網關
圖1 報文封裝轉發流程
缺省情況下，指定安全策略視圖的IPSec報文都是先加密再分片，對端收到所有報文后，才能進行解密。通過命令行ipsec df-bit clear和ipsec fragmentation before-encryption配合可以實現先分片后加密，這樣對端的設備就可以收到一片就對一片報文解密，為了加快加密報文的解析速度。報文的實際凈荷可能會增大。
圖2 QoS方案
IPSec報文傳輸的過程中，原始報文IP頭的DSCP值不會也不允許被改變。
報文加密后，原始IP報文頭的DSCP值映射到IPSec頭部的DSCP域；也可以單獨設定外層IP頭的DSCP值。
加密后的IPSec報文，經過加密MPLS網絡傳輸后解密，原始IP報文頭的DSCP值不變。MPLS網絡傳輸過程，外層DSCP值也可以映射到MPLS EXP值中去。
如果按照DSCP優先級協商IPSec SA，就可以解決Qos帶來的亂序問題。
L3VPN PE作為IPSec安全網關
圖3 報文封裝轉發流程
圖4 QoS方案
IPSec報文傳輸的過程中，原始報文IP頭的DSCP值不會也不允許被改變。
報文加密后，原始IP報文頭的DSCP值映射到IPSec頭部的DSCP域；也可以單獨設定外層IP頭的DSCP值。
加密后的IPSec報文，經過加密MPLS網絡傳輸后解密，原始IP報文頭的DSCP值不變。MPLS網絡傳輸過程，外層DSCP值也可以映射到MPLS EXP值中去。
如果按照DSCP優先級協商IPSec Sa，就可以解決Qos帶來的亂序問題。
L3VPN CE作為IPSec安全網關
圖5 報文封裝轉發流程
圖6 QoS方案
報文加密后，原始IP報文頭的DSCP值映射到IPSec頭部的DSCP域；也可以單獨設定外層IP頭的DSCP值。
原始IP報文頭的DSCP值映射到IPSec頭部的DSCP值，經過加密MPLS網絡傳輸后解密，原始IP報文頭的DSCP值不變。MPLS網絡傳輸過程，外層DSCP值也可以映射到MPLS EXP值中去，待解密之后，可以指定原始IP報文頭的DSCP值。
如果按照DSCP優先級協商IPSec Sa，就可以解決Qos帶來的亂序問題。
核心網設備根據DSCP值進行相應的QoS處理，承載網中，如果設備支持DSCP到802.1p的映射，在二層承載網中可根據802.1p進行QoS處理。
