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是一种公共密钥交换方法，它用于产生密钥材料，并通过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个包。

这三次交换分别是：

消息①和②用于策略交换

发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
消息③和④用于密钥信息交换

双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

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的建立：

协商发起方发送本端的安全参数和身份认证信息。

安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。

IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。

如果启用PSF，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
发送方发送确认信息，确认与响应方可以通信，协商结束。

图：快速模式第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           -->
12345
野蛮模式（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等，发送给协商发起方。

第三个包：

图：野蛮模式协商第三个包

第三个包：的传输过程是加密的。主要用于响应方认证发起方。

主模式与野蛮模式的区别：

交换的消息：主模式为6个包，野蛮模式为3个包，野蛮模式能够更快创建IKE SA
NAT支持：对预共享密钥认证：主模式不支持NAT转换，而野蛮模式支持。而对于证书方式认证：两种模式都能支持
对等体标识：主模式只能采用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信息也是明文的，也相应造成了安全隐患。
提议转换对数量：在野蛮模式中，由于第一个消息就需要交换DH消息，而DH消息本身就决定了采用哪个DH组，这样在提议转换对中就确定了使用哪个DH组，如果第一个消息中包含多个提议转换对，那么这多个转换对的DH组必须相同(和DH消息确定的DH组一致)，否则消息1中只能携带和确定DH组相同的提议转换对。
协商能力：由于野蛮模式交换次数的限制，因此野蛮模式协商能力低于主模式。
主模式常用，野蛮已经不推荐使用,推荐使用模板方式
两者之间的协商过程不同
场景不同：

野蛮模式的场景：

与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。虽然野蛮模式不提供身份保护，但它可以满足某些特定的网络环境需求：

当IPSec隧道中存在NAT设备时，需要启动NAT穿越功能，而NAT转化会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享密钥验证方式时，NAT穿越只能在野蛮模式中实现。
如果发起方的IP地址不固定或者无法预知，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。
如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。

主模式场景：

要求两端都是固定IP地址

参考文档：RFC 2409，华为HedEx文档