IPSec之IKEv1協定詳解

IKE簡介

安全聯盟SA：

定義： 安全聯盟是要建立IPSec 隧道的通信雙方對隧道參數的約定，包括隧道兩端的IP位址、隧道采用的驗證方式、驗證算法、驗證密鑰、加密算法、共享密鑰以及生命周期等一系列參數。

SA由三元組來唯一辨別，這個三元組包括安全參數索引SPI（Security Parameter Index）、目的IP位址和使用的安全協定号（AH或ESP）。其中，SPI是為唯一辨別SA而生成的一個32位比特的數值，它在AH和ESP頭中傳輸。在手工配置SA時，需要手工指定SPI的取值。使用IKE協商産生SA時，SPI将随機生成。

SA是單向的邏輯連接配接，是以兩個IPSec對等體之間的雙向通信，最少需要建立兩個SA來分别對兩個方向的資料流進行安全保護。

SA是IPSec的一個基本組成部分，SA是SADB的一個條目，它包含雙方關于IKE和IPSec已經協商完畢的安全資訊。

• IKE or ISAKMP SA：雙向的，決定了IKE協定處理相關細節
• IPSec SA：單向的，與封裝協定相關，決定了具體加密流量的處理方式。

兩種類型的SA都是由IKE協定協商産生的。

建立IPSec SA的方式：

有兩種方式建立IPSec安全聯盟：手工方式和IKE自動協商方式。二者的主要差別為：

• 密鑰生成方式不同

  手工方式下，建立SA所需的全部參數，包括加密、驗證密鑰，都需要使用者手工配置，也隻能手工重新整理，在中大型網絡中，這種方式的密鑰管理成本很高；IKE方式下，建立SA需要的加密、驗證密鑰是通過DH算法生成的，可以動态重新整理，因而密鑰管理成本低，且安全性較高。

• 生存周期不同

  手工方式建立的SA，一經建立永久存在；IKE方式建立的SA，其生存周期由雙方配置的生存周期參數控制。

IKE介紹：

IKE是一個複合協定。

網際網路密鑰交換IKE（Internet Key Exchange）協定建立在Internet安全聯盟和密鑰管理協定ISAKMP定義的架構上，是基于UDP（User Datagram Protocol）500 端口号，的應用層協定。

IKE協商兩種SA：

• IKE(ISAKMP) SA (階段一）
• IPSEC SA（階段二）

IKE負責建立和維護IKE SAs 和 IPSec SAs。功能主要展現在如下幾個方面：

• 對雙方進行認證
• 交換公共密鑰，産生密鑰資源，管理密鑰
• 協商協定參數（封裝、加密、驗證…）

IKE的三個元件：

• SKEME：實作公鑰加密認證的機制
• Oakley：基于到達兩個對等體間的加密密鑰的機制
• ISAKMP：在兩個實體間進行分組格式及狀态轉換的消息交換的體系結構。

IKE有兩個版本:

• IKEV1
• IKEV2-------華為預設

IKE與IPSec的關系：

IKE為IPSec提供了自動協商密鑰、建立IPSec安全聯盟的服務，能夠簡化IPSec的使用和管理，大大簡化IPSec的配置和維護工作。

圖：IKE與IPSec的關系圖

IKE與IPSec的關系如上圖所示，對等體之間建立一個IKE SA完成身份驗證和密鑰資訊交換後，在IKE SA的保護下，根據配置的AH/ESP安全協定等參數協商出一對IPSec SA。此後，對等體間的資料将在IPSec隧道中加密傳輸。

IKE的安全機制：

IKE具有一套自保護機制，可以在不安全的網絡上安全地認證身份、分發密鑰、建立IPsec SA：

身份認證

身份認證确認通信雙方的身份（對等體的IP位址或名稱），包括預共享密鑰PSK（pre-shared key）認證、數字證書RSA（rsa-signature）認證和數字信封認證。

• 在預共享密鑰認證中，認證字作為一個輸入來産生密鑰，通信雙方采用共享的密鑰對封包進行Hash計算，判斷雙方的計算結果是否相同。如果相同，則認證通過；否則認證失敗。
• 在數字證書認證中，通信雙方使用CA憑證進行數字證書合法性驗證，雙方各有自己的公鑰（網絡上傳輸）和私鑰（自己持有）。發送方對原始封包進行Hash計算，并用自己的私鑰對封包計算結果進行加密，生成數字簽名。接收方使用發送方的公鑰對數字簽名進行解密，并對封包進行Hash計算，判斷計算結果與解密後的結果是否相同。如果相同，則認證通過；否則認證失敗。
• 在數字信封認證中，發送方首先随機産生一個對稱密鑰，使用接收方的公鑰對此對稱密鑰進行加密（被公鑰加密的對稱密鑰稱為數字信封），發送方用對稱密鑰加密封包，同時用自己的私鑰生成數字簽名。接收方用自己的私鑰解密數字信封得到對稱密鑰，再用對稱密鑰解密封包，同時根據發送方的公鑰對數字簽名進行解密，驗證發送方的數字簽名是否正确。如果正确，則認證通過；否則認證失敗。

DH

• DH是一種公共密鑰交換方法，它用于産生密鑰材料，并通過ISAKMP消息在發送和接收裝置之間進行密鑰材料交換。然後，兩端裝置各自計算出完全相同的對稱密鑰。該對稱密鑰用于計算加密和驗證的密鑰。在任何時候，通信雙方都不交換真正的密鑰。DH密鑰交換是IKE的精髓所在。

  MD5、SHA1、DES、3DES、AES等算法都可以采用DH算法來共享對稱密鑰。

  DH使用密鑰組定義自己産生的密鑰長度。密鑰組長度越長，産生的密鑰就越強壯。

  IKE的精髓在于它永遠不在不安全的網絡上傳送密鑰，而是通過一些資料的交換，通信雙方最終計算出共享的密鑰，并且即使第三方截獲了雙方用于計算密鑰的所有交換資料，也無法計算出真正的密鑰。其中的核心技術就是DH（Diffie Hellman）交換技術。

PFS

• 短暫的一次性密鑰系統稱為“完善的前向保密“PFS（Perfect Forward Secrecy）
• 如果加密系統中有個密鑰是所有對稱密鑰的衍生者（始祖），便不能認為那是一個“完美向前保密”的系統。在這種情況下、一旦破解了跟密鑰，便能拿到其他衍生的所有密鑰，收那些密鑰保護的全部資料都會曝光。
• 在IPsec 裡，PFS是通過在IPSec SA協商階段重新進行一個DH交換來實作的。
• 完善的前向安全性PFS（Perfect Forward Secrecy）是一種安全特性，指一個密鑰被破解，并不影響其他密鑰的安全性，因為這些密鑰間沒有派生關系。IPSec SA的密鑰是從IKE SA的密鑰導出的，由于一個IKE SA協商生成一對或多對IPSec SA，當IKE的密鑰被竊取後，攻擊者将可能收集到足夠的資訊來導出IPSec SA的密鑰，PFS通過執行一次額外的DH交換，保證IPSec SA密鑰的安全。

ISAKMP封包格式：

8      12      16              24              32
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            發起者                             !
    !                      Initiator Cookie                       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            應答                               !
    !                      Responder Cookie                         !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   下一個載荷  ! MjVer ! MnVer !    交換類型   !     标志      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            消息  ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                             長度                              !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           

• Initiator Cookie ― Initiator Cookie：啟動 SA 建立、SA 通知或 SA 删除的實體 Cookie。
• Responder Cookie ― Responder Cookie：響應 SA 建立、SA 通知或 SA 删除的實體 Cookie。
• Next Payload ― 資訊中的 Next Payload 字段類型。
• Major Version ― 使用的 ISAKMP 協定的主要版本。
• Minor Version ― 使用的 ISAKMP 協定的次要版本。
• Exchange Type ―

表示所用的交換類型。這表示消息和載荷遵循所用的交換順序。
                        交換類型                值
                         NONE                    0
                         Base                    1
                         Identity Protection     2
                         Authentication Only     3
                         Aggressive              4
                         Informational           5
                         ISAKMP Future Use     6 - 31
                         DOI Specific Use     32 - 239
                         Private Use         240 - 255
           

• Flags ― 為 ISAKMP 交換設定的各種選項。
• Message ID ― 唯一的資訊辨別符，用來識别第2階段的協定狀态。
• Length ― 全部資訊（頭＋有效載荷）長（八位）。

IKE的兩個階段：

采用IKEv1協商安全聯盟主要分為兩個階段：第一階段，通信雙方協商和建立IKE協定本身使用的安全通道，即建立一個IKE SA；第二階段，利用第一階段已認證認證和安全保護的安全通道，建立一對用于資料安全傳輸的IPSec安全聯盟。

IKEv1協商階段1支援兩種協商模式：主模式（Main Mode）和野蠻模式（Aggressive Mode）。

經典版本的IKEv1有兩個階段：

• 階段一 ： IKE SA

  主模式（6個包）

  野蠻模式（3個包）

• 階段二：IPSec SA

  快速模式（3個包）

詳解IKEv1主模式的協商過程

IKEv1階段一協商過程：

IKEv1的主模式協商：包含了三次雙向交換，用到了六條ISAKMP資訊。協商過程如下圖所示：

圖：IKEv1主模式的協商過程

圖：IKEv1主模式協商抓包

IKEv1的協商過程總用用到了9個包。

這三次交換分别是：

1. 消息①和②用于政策交換

   發起方發送一個或多個IKE安全提議，響應方查找最先比對的IKE安全提議，并将這個IKE安全提議回應給發起方。比對的原則為協商雙方具有相同的加密算法、認證算法、認證方法和Diffie-Hellman組辨別。

2. 消息③和④用于密鑰資訊交換

   雙方交換Diffie-Hellman公共值和nonce值，用于IKE SA的認證和加密密鑰在這個階段産生。

3. 消息⑤和⑥用于身份和認證資訊交換（雙方使用生成的密鑰發送資訊），雙方進行身份認證和對整個主模式交換内容的認證。

IKE安全提議指IKE協商過程中用到的加密算法、認證算法、Diffie-Hellman組及認證方法等。

nonce是個随機數，用于保證IKE SA存活和抗重播攻擊。

使用預共享秘鑰進行身份驗證主模式的詳細過程：

當做一個預共享秘鑰認證時，主模式的協商如下：

follows:

              Initiator                        Responder
             ----------                       -----------
        1      HDR, SA             -->
        2                          <--    HDR, SA
        3      HDR, KE, Ni         -->
        4                          <--    HDR, KE, Nr
        5      HDR*, IDii, HASH_I  -->
        6                          <--    HDR*, IDir, HASH_R
           

縮寫名詞的解釋：

• HDR ：是ISAKMP的标頭。當記為 HDR* 表示該流量被加密。
• SA： 是SA帶有一個或多個提議的有效載荷。針對多個提議，隻回複一個。
• KE：秘鑰交換

• IDii和IDir------辨別，通常要IP位址

  HASH_I = prf(SKEYID,K| Ci | Cr| SAi | IDi )

  HASH_R = prf(SKEYID, K| Ci | Cr | SAr | IDr )

• Ni：第一個随機數，用于生成密鑰
• Nr：第二個随機數，用于生成密鑰
• Ni Nr----代表随機數，通過KE交換素材得到公共的K值
• K值為推導SKEYID使用
• HASH值用進行身份資料驗證。

• HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
  HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
    //prf僞随機函數
    //g^xy is the Diffie-Hellman shared secret.
    // CKY-I and CKY-R are the Initiator's cookie and the Responder's cookie, respectively, from the ISAKMP header.
     // SAi_b is the entire body of the SA payload (minus the ISAKMP generic header)-- i.e. the DOI, situation, all proposals and all transforms offered by the Initiator.
             

筆記：封包協商參數拆解

階段一: IKE SA	
主模式（6個包）
Initiator                        Responder
             ----------                       -----------
-----------------------------------------------------------
    1-2包，用于安全參數協商（明文）
 
              HDR, SA             -->
              Ci  SAi
                                  <--    HDR, SA

                                           Ci Cr  SAr

SA安全聯盟(協商各種參數  加密算法   驗證算法  驗證方式【預共享密鑰  數字證書】 DH組  密鑰有效期） 
HDR拆解為Ci，Cr，分别代表Initiator cookie和Responder Cookie。第一個包Cr為0。

------------------------------------------------------------
 
3-4個包   交換密鑰素材，以及産生密鑰(明文）

              HDR, KE, Ni         -->
              Ci  Cr  K   Ni
                                  <--    HDR, KE, Nr
                                           Ci Cr  k  Nr
 
Ni Nr----代表随機數
通過KE交換素材得到公共的K值

K值為推導SKEYID使用  K = g^xy
SKEYID ------基準密鑰
使用預共享密鑰
SKEYID = prf(pre-shared-key, Ni|Nr)

使用數字證書
SKEYID = prf(Ni | Nr, K) -----基準密鑰

 通過SKEYID推導三個密鑰
   SKEYID_d = prf(SKEYID, K | Ci | Cr | 0) -----------推導密鑰，衍生密鑰
  
   SKEYID_a = prf(SKEYID, SKEYID_d | K | Ci | Cr | 1)---------驗證密鑰
   SKEYID_e = prf(SKEYID, SKEYID_a | K | Ci | Cr | 2)---------加密密鑰
   
-----------------------------------------------------------

5-6 兩個包    做身份驗證 （加密）

采用預共享密鑰5 6兩個包
   HDR*, IDii, HASH_I  --> 
   Ci Cr  
                                  <--    HDR*, IDir, HASH_R


IDii和IDir------辨別，通常要IP位址
 HASH_I =   prf(SKEYID,K| Ci | Cr| SAi | IDi )
 HASH_R =  prf(SKEYID, K| Ci | Cr | SAr | IDr )



采用數字證書的5 6兩個包
 HDR*, IDii, [ CERT, ] SIG_I -->

                                    <--    HDR*, IDir, [ CERT, ] SIG_R
                                    
-----------------------------------------------------------------

           

圖：通過DH算法得出密鑰

階段一的第1個包（明文）：

第一包的作用是，協商發起發，發送IKE安全提議，給響應方。下圖為抓包示例内容：

圖：主模式的第一個包内容抓包示例

首先當兩個路由器或防火牆啟用IPSEC的時候，我們以其中之一為起點。A->B，那麼A開始發送IKE的資料封包。封包是UDP的類型，封裝在端口500裡面。

首先是第一個資訊被發送，主要内容是COOKIE号碼，辨別一個唯一的IPSEC會話，也有防止重放的功能。它的建立是通常是基于IP位址，端口的号碼，時間和日期等等進行一個雜湊演算法，生成一個8位的随機數。對方的COOKIE為0。

**内容還包含一個SA負載，還有提議負載，轉換負載。**sa的負載是定位這個ISAKMP是為了IPSEC工作。因為IKE是一個标準的協定，是以在SA負載中通過DOI，解釋域，來說明這條消息交換用于IPSEC。

提議負載的内容包含一個提議号，協定ID，SPI，轉換号，其中SPI為0，轉換号指向了相應的轉換負載

轉換負載的内容是加密的參數，如des，dh算法，存活時間，hash算法等等。

階段一的第2個包（明文）：

第2個包的作用主要是：通過查找第一個包的安全提議。給發送者回複一個确認的安全提議。下圖是第二個包的抓包内容。

圖：IKEv1主模式協商第二個包抓包

第二個包是響應方響應一個資訊，主要内容就是對方的COOKIE号碼，和一個提議和一個政策，注意，這個提議和政策是和開始裡面的一個對應的，否則，就回一個失敗資訊。

階段一的第3個包（明文）：

第三個包的作用：如果發起方接受了安全提議，就給對方發送密鑰生成資訊，對方用來生成IKE的秘鑰。

圖：IKEv1主模式協商第三個包抓包示例

初始方然後回應第三個資訊，内容是自己的公鑰，發給對方，注意，此處我的了解是素數已經交換完畢，公鑰就是根據自己随機産生的私鑰加上素數和一個産生器g三者來産生的。同時傳輸一個随機數NI。

階段一第四個包（明文）：

主要作用：協商相應方給協商發起方發送密鑰生成資訊，使得協定發起方能生成密鑰。

圖：IKEv1主模式協商第4個包抓包

接收方回應自己的公鑰給初始方。包含一個随機數NR。

然後雙方各自計算出共享的密鑰，一共有三個密鑰，SKEYID_a，d，e，其中d是根據z=pfs（pre-shared key，cookie_i，cookie_ni，nl|0），其中d用來給第二階段提供密鑰的素材。a用來對IKE的資料進行認證，e用來加密整個IKE協商的資料。

K值為推導SKEYID使用 
	SKEYID ------基準密鑰
使用預共享密鑰

	SKEYID = prf(pre-shared-key, Ni|Nr)

使用數字證書
	SKEYID = prf(Ni | Nr, K) 

 通過SKEYID推導三個密鑰
 	  SKEYID_d = prf(SKEYID, K | Ci | Cr | 0) -----------推導密鑰
  	 SKEYID_a = prf(SKEYID, SKEYID_d | K | Ci | Cr | 1)---------驗證密鑰,對資料進行驗證
 	  SKEYID_e = prf(SKEYID, SKEYID_a | K | Ci | Cr | 2)---------加密密鑰
           

當使用預共享密鑰認證與主模式時，密鑰可以隻能通過對等點的IP位址來辨別，因為必須使用HASH_I，在啟動程式處理IDir之前計算。野蠻模式允許更大範圍的預共享密鑰辨別符被使用。此外，野蠻模式允許雙方進行維護多個不同的預共享密鑰，并确定正确的密鑰一個特定的交換。

階段一的第5個包（密文）：

主要作用：發起方發送身份和驗證資料。

圖：IKEv1主模式協商第5個包抓包

初始方開始繼續協商，發送第五個資訊，注意，此刻所有的負載資訊是被ekey加密過的。資訊主要包含兩個内容，其中之一是辨別負載，另一個是散

列負載，辨別負載的主要内容是包含自己的IP位址，就是我們所謂的ID_I，或者是主機名稱。散列負載主要的内容是使用session_a進行的散列計 算，計算的參數有上述的Z，和兩端的cookie，pre-share key ，提議，轉換集，SA的内容。

階段一的第6個包（密文）：

主要作用: 協商響應方給發起方發送身份和驗證資料。

圖：IKEv1主模式協商第6個包抓包

然後當接收方收到的時候進行确認，先解密，然後根據ID找到pre-key，然後進行相同的計算，得出散列的值，然後對比接收呼叫。

總結：在這個過程中，所有的資料都是被封裝在UDP 500的端口内進行協商的。

IKEv1階段二 快速模式協商過程：

IKEv1協商階段2的目的就是建立用來安全傳輸資料的IPSec SA，并為資料傳輸衍生出密鑰。這一階段采用快速模式（Quick Mode）。該模式使用IKEv1協商階段1中生成的密鑰對ISAKMP消息的完整性和身份進行驗證，并對ISAKMP消息進行加密，故保證了交換的安全性。

圖：IKEv1階段二協商過程

階段二的快速模式的協商如下：

Initiator                         Responder
   -----------                   -----------
   HDR*, HASH(1), SA, Ni
     [, KE ] [, IDci, IDcr ] -->
                              <--    HDR*, HASH(2), SA, Nr
                                     [, KE ] [, IDci, IDcr ]
      HDR*, HASH(3)       -->
           

HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
   HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
   IDcr )
   HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
           

IKEv1協商階段2通過三條ISAKMP消息完成雙方IPSec SA的建立：

1. 協商發起方發送本端的安全參數和身份認證資訊。

   安全參數包括被保護的資料流和IPSec安全提議等需要協商的參數。身份認證資訊包括第一階段計算出的密鑰和第二階段産生的密鑰材料等，可以再次認證對等體。

2. 協商響應方發送确認的安全參數和身份認證資訊并生成新的密鑰。

   IPSec SA資料傳輸需要的加密、驗證密鑰由第一階段産生的密鑰、SPI、協定等參數衍生得出，以保證每個IPSec SA都有自己獨一無二的密鑰。

   如果啟用PSF，則需要再次應用DH算法計算出一個共享密鑰，然後參與上述計算，是以在參數協商時要為PFS協商DH密鑰組。

3. 發送方發送确認資訊，确認與響應方可以通信，協商結束。

圖：快速模式第1個包，第2個包，第3個包都除了加密資料格式都相同

第二階段，當第一階段結束後，根據session-d的密鑰資源，然後繼續進行兩次交換：

第一次交換，首先，判斷是否啟用了PFS（完美轉發安全），如果啟用的話，根據pfs中定義的參數繼續進 行一個協商。PFS是提議者向接收者提供建議 的屬性。如果協商就支援，否則就不支援。它的作用是在快速模式中重新協商DH密鑰的屬性。這允許使用新的密鑰進行ipsec加密，而不是使用第一階段生産的密鑰。

快速模式隻有一次交換，DH交換必須馬上發生。不能幾次協商了。是以，兩端的DH配置必須比對。

當執行PFS的時候，再次執行DH算法，然後，重新生産密鑰。

配置感興趣流時的注意事項：

在IKEv1中，雙方的感興趣劉必須互為鏡像，不能取交集。而在IKEv2中可以取交集。

例如：在1.1.1.1/34 ----> 2.2.2.2/32 與 2.2.2.2/32 ------> 1.1.1.1/32 在IKEv1中可以協商。而1.1.1.1/34 ----> 2.2.2.2/32 與 2.2.2.0/24 ---->1.1.1.0/24 在IKEv1中不可以協商，在IKEv2中可以協商成功。

注意：SKEYID-e用來加密包弧ISAMKP的協定的資料，而不是用來保護感興趣流。

保護資料流的密鑰用的是密鑰是：KEYMAT。

• 無PFS

  KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

• 有PFS

  KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

If PFS is not needed, and KE payloads are not exchanged, the new
   keying material is defined as

       KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b).

   If PFS is desired and KE payloads were exchanged, the new keying
   material is defined as

       KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b)

   where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman
   exchange of this Quick Mode.
           

詳解IKEv1野蠻模式的協商過程

野蠻模式協商過程：

圖：野蠻模式協商過程

圖：野蠻模式協商過程

野蠻模式隻用到三條資訊：前兩條消息①和②用于協商IKE安全提議，交換Diffie-Hellman公共值、必需的輔助資訊以及身份資訊，并且消息②中還包括響應方發送身份資訊供發起方認證，消息③用于響應方認證發起方。

使用預共享秘鑰進行身份驗證野蠻模式的詳細過程：

當做一個預共享秘鑰認證時，野蠻模式的協商如下：

Initiator                        Responder
           -----------                      -----------
            HDR, SA, KE, Ni, IDii -->
                                  <--    HDR, SA, KE, Nr, IDir, HASH_R
            HDR, HASH_I           -->
           

野蠻模式（3個包）
      Initiator                        Responder
           -----------                      ----------- 
第1包-------安全提議（各種協商）  密鑰交換素材   随機數  身份ID
            HDR, SA, KE, Ni, IDii -->
                                  <--    HDR, SA, KE, Nr, IDir, HASH_R

第2包---------安全提議，密鑰交換素材  随機數  身份ID  HASH_R

第3包---------加密的環境
            HDR*, HASH_I           -->
           

第一個包封包抓包：

圖：野蠻模式協商第一個包

主要攜帶了安全提議（各種協商） 密鑰交換素材 随機數 身份ID等，發送給響應方。

第二個封包抓包：

圖：野蠻模式協商第二個包

第二個包：主要攜帶确認雙方都支援的安全提議，密鑰交換素材 随機數 身份ID HASH_R等，發送給協商發起方。

第三個包：

圖：野蠻模式協商第三個包

第三個包：的傳輸過程是加密的。主要用于響應方認證發起方。

主模式與野蠻模式的差別：

1. 交換的消息：主模式為6個包，野蠻模式為3個包，野蠻模式能夠更快建立IKE SA
2. NAT支援：對預共享密鑰認證：主模式不支援NAT轉換，而野蠻模式支援。而對于證書方式認證：兩種模式都能支援

3. 對等體辨別：主模式隻能采用IP位址方式辨別對等體；而野蠻模式可以采用IP位址方式或者Name方式辨別對等體。這是由于主模式在交換完3、4消息以後，需要使用預共享密鑰來計算SKEYID，當一個裝置有多個對等體時，必須查找到該對等體對應的預共享密鑰，但是由于其對等體的ID資訊在消息5、6中才會發送，此時主模式的裝置隻能使用消息3、4中的IP封包源位址來找到與其對應的預共享密鑰；如果主模式采用Name方式，Name資訊卻包含在消息5、6中，而裝置必須在消息5、6之前找到其對等體的預共享密鑰，是以就造成了沖突，無法完成Name方式的辨別。

   而在野蠻模式中，ID消息在消息1、2中就已經發送了，裝置可以根據ID資訊查找到對應的預共享密鑰，進而計算SKEYID。但是由于野蠻模式交換的2個消息沒有經過加密，是以ID資訊也是明文的，也相應造成了安全隐患。

4. 提議轉換對數量：在野蠻模式中，由于第一個消息就需要交換DH消息，而DH消息本身就決定了采用哪個DH組，這樣在提議轉換對中就确定了使用哪個DH組，如果第一個消息中包含多個提議轉換對，那麼這多個轉換對的DH組必須相同(和DH消息确定的DH組一緻)，否則消息1中隻能攜帶和确定DH組相同的提議轉換對。
5. 協商能力：由于野蠻模式交換次數的限制，是以野蠻模式協商能力低于主模式。
6. 主模式常用，野蠻已經不推薦使用,推薦使用模闆方式
7. 兩者之間的協商過程不同
8. 場景不同：

野蠻模式的場景：

與主模式相比，野蠻模式減少了交換資訊的數目，提高了協商的速度**，但是沒有對身份資訊進行加密保護**。雖然野蠻模式不提供身份保護，但它可以滿足某些特定的網絡環境需求：

• 當IPSec隧道中存在NAT裝置時，需要啟動NAT穿越功能，而NAT轉化會改變對等體的IP位址，由于野蠻模式不依賴于IP位址辨別身份，使得采用預共享密鑰驗證方式時，NAT穿越隻能在野蠻模式中實作。
• v 如果發起方的IP位址不固定或者無法預知，而雙方都希望采用預共享密鑰驗證方法來建立IKE SA，則隻能采用野蠻模式。
• 如果發起方已知響應方的政策，或者對響應者的政策有全面的了解，采用野蠻模式能夠更快地建立IKE SA。

主模式場景：

要求兩端都是固定IP位址

參考文檔：RFC 2409， 華為HedEx文檔