一、什么是安全联盟

IPSec中通信双方建立的连接叫做安全联盟SA (Security Association) ,顾名思义，通信双方结成盟友，使用相同的封装模式、加密算法、加密密钥、验证算法、验证密钥，相互信任亲密无间。安全联盟是单向的逻辑连接，为了使每个方向都得到保护，总舵和分舵的每个方向上都要建立安全联盟。总舵入方向上的安全联盟对应分舵出方向上的安全联盟,总舵出方向上的安全联盟对应分舵入方向卜的安全联明。

SA在传输模式下也存在  只是不存在隧道报头IP        SA表示一种安全环境

安全联盟定义了IPSec对等体间将使用的数据封装模式、认证和加密算法、密钥等参数。

安全联盟是单向的，两个对等体之间的双向通信，至少需要两个SA。

同时使用了AH和ESP需要4个联盟

需要考虑参数：本地IP      远端IP   入方向索引编号   出方向索引（编号） （A入=B出）

                      加密的密钥      建立联盟的提议（标识）

二、协商参数两种方式：（手动、IKE）

1. 手动

手动方式：适用于小型网络      （有匹配流量才会触发ipsce）

      现在手工配置不存在：不安全/不方便（密钥不会变化）

2. IKE方式

IKE-互联网隧道交换协议：IPsce的加解密(对称加密、非对称加密都需要密钥解密)、哈希(密钥参与哈希)、身份认证(数字证书本身就是非对称加密算法做的密钥)都需要密钥  

解决手工配置问题

IKE用来管理、 生成、删除、变更各种密钥

IKE负责自动建立和维护IKE SAs（密钥素材安全环境（要是生成环境安全？？？））和IPSec SAs（IPSec安全环境  生成密钥，确定参数）功能主要体现在

如下几个方面:

对双方进行认证

交换公共密钥，产生密钥资源，管理密钥。

协商协议参数(封装，加密，验证”.) .

IKE协议分IKEv1和IKEv2两个版本。IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA。

第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKESA。

第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA

IKEv2则简化了协商过程，在一次协商中可直接产生IPSec的密钥，生成IPSec SAo

华为默认v2

三、IKE的三个组件：

SKEME：实现公钥加密认证的机制

Oakley：基于到达两个对等体间的加密密钥的机制

ISAKMP：在两个实体间进行分组格式及状态转换的消息交换的体系结构。

四、IKEv1三种模式（主模式/野蛮模式+快速模式）

IKEv1建立IKE SA的过程定义了主模式(Main Mode)和野蛮模式(Aggressive Mode)两种交换模式。

主模式包含三次双向交换，用到了六条信息。

野蛮模式只用到三条信息。

1. 主模式：

1. 数据包分析

IKEv1的主模式协商：包含了三次双向交换，用到了六条ISAKMP信息。协商过程如下图所示：              IKEv1的协商过程总用用到了9个包。（加上快速模式3个包）

这三次交换分别是：

   消息①和②用于策略交换

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

   消息③和④用于密钥信息交换

   双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。

   消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。

IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。nonce是个随机数，用于保证IKE SA存活和抗重放攻击。

2. 详细过程

协商过程
使用预共享密钥进行身份认证主模式的详细过程
阶段一: 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
-----------------------------------------------------------------

2. 快速模式（三个包）

IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：

1.发起方发送IPSec安全提议、被保护的数据流(ACL)和密钥材料给响应方。

2.响应方回应匹配的IPSec安全提议、被保护的数据流，同时双方生成用于IPSec SA的密钥。IKEv1不协商ACL规则，建议两端设备配置的ACL规则互为镜像,避免IPSec SA协商失败。IPSec对等体两端交换密钥材料(SKEYID_ _d、SPI和协议1、nonce等参数) ,然后各自进行密钥计算生成用于IPSec SA加密验证的密钥,这样可以保证每个IPSec SA都有自己独一无二的密钥。由于IPSec SA的密钥都是由SKEYID_d衍生的,一旦SKEYID_d泄露将可能导致IPSec VPN受到侵犯。为提升密钥管理的安全性，IKE提供了PPS (完美向前保密)功能。启用PFS后，在进行IPSec SA协商时会进行一次附加的DH交换, 重新生成新的IPSec SA密钥,提高了IPSec SA的安全性。

说明: 协议指AH和或ESP协议。

3. 发送方发送确认信息，确认与响应方可以通信，协商结束。

协商完成后发送方开始发送IPSec (ESP) 报文。

3. 野蛮模式

主模式 需要知道对方IP进行指定

野蛮模式 解决一端为动态IP的问题（用的少不太安全）

配置命令exchange- mode aggressive即可将IKEv1的协商模式改为野蛮模式。

野蛮模式只用到三条信息：前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。

协商过程

当做一个预共享秘钥认证时，野蛮模式的协商如下：

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等，发送给协商发起方。

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

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

   交换的消息：主模式为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组相同的提议转换对。

   协商能力：由于野蛮模式交换次数的限制，因此野蛮模式协商能力低于主模式。

   主模式常用，野蛮已经不推荐使用,推荐使用模板方式

   两者之间的协商过程不同

   场景不同：

5. 野蛮模式适用场景

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

当IPSec隧道中存在NAT设备时，需要启用NAT穿越功能，而NAT转换会改变对等体的IP地址，由于野蛮模式不依赖于IP地址标识身份，使得采用预共享密钥验证方法时，NAT穿越只能在野蛮模式中实现。

如果发起方的IP地址不固定或者无法预知道，而双方都希望采用预共享密钥验证方法来创建IKE SA，则只能采用野蛮模式。

如果发起方已知响应方的策略，或者对响应者的策略有全面的了解，采用野蛮模式能够更快地创建IKE SA。