IPSEC
一、术语解释
1、IPsec（IP Security，IP安全）是IETF制定的三层隧道加密协议，是一种传统的实现三层VPN（Virtual Private Network，虚拟专用网络）的安全技术。IPsec通过在特定通信方之间（例如两个安全网关之间）建立“通道”，来保护通信方之间传输的用户数据，该通道通常称为IPsec隧道
2、安全联盟 (Security Association)：安全关联是一组特定于安全协议的参数，它完全定义了在该安全协议位置保护流量所需的服务和机制 。这些参数可以包括算法标识符、模式、加密密钥等
3、安全参数索引 (Security Parameter Index)：安全关联的标识符，与某些安全协议相关
4、解释域 (DOI) ：定义有效载荷格式、交换类型和命名安全相关信息（例如安全策略或加密算法和模式）的约定。解释域 (DOI)标识符用于解释 ISAKMP 有效载荷的有效载荷。一个系统应该同时支持多个解释域。
5、AH（Authentication Header，认证头）：定义了AH头在IP报文中的封装格式。AH可提供数据来源认证、数据完整性校验和抗重放功能，它能保护报文免受篡改，但不能防止报文被窃听，适合用于传输非机密数据。AH使用的认证算法有HMAC-MD5和HMAC-SHA1
6、ESP（Encapsulating Security Payload，封装安全载荷）：定义了ESP头和ESP尾在IP报文中的封装格式。ESP可提供数据加密、数据来源认证、数据完整性校验和抗重放功能。与AH不同的是，ESP将需要保护的用户数据进行加密后再封装到IP包中，以保证数据的机密性。ESP使用的加密算法有DES、3DES、AES等。同时，作为可选项，ESP还可以提供认证服务，使用的认证算法有HMAC-MD5和HMAC-SHA1。虽然AH和ESP都可以提供认证服务，但是AH提供的认证服务要强于ESP
7、IKE（Internet Key Exchange，互联网密钥交换）：可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA（Security Association，安全联盟），简化了IPsec的使用和管理
8、HMAC（Hash-based Message Authentication Code，基于散列的消息鉴别码）
9、isakmp（Internet Security Association and Key Management Protocol）：因特网安全联盟和密钥管理协议，ISAKMP结合了身份验证、密钥管理和安全关联的安全概念，为互联网上的政府、商业和私人通信建立了所需的安全性
10、RRI（Reverse Route Injection，反向路由注入）：RRI是一种自动添加到达IPsec VPN私网静态路由的机制，可以实现为受IPsec保护的流量自动添加静态路由的功能。
11、重放报文；通常是指设备再次接收到的已经被IPsec处理过的报文。IPsec通过滑动窗口（抗重放窗口）机制检测重放报文。AH和ESP协议报文中带有序列号，如果收到的报文的序列号与已经解封装过的报文序列号相同，或收到的报文的序列号出现得较早，即已经超过了抗重放窗口的范围，则认为该报文为重放报文
12、PFS（Perfect Forward Secrecy，完善的前向安全性）是一种安全特性，它解决了密钥之间相互无关性的需求。由于IKE第二阶段协商需要从第一阶段协商出的密钥材料中衍生出用于IPsec SA的密钥，若攻击者能够破解IKE SA的一个密钥，则会非常容易得掌握其衍生出的任何IPsec SA的密钥。使用PFS特性后，IKE第二阶段协商过程中会增加一次DH交换，使得IKE SA的密钥和IPsec SA的密钥之间没有派生关系，即使IKE SA的其中一个密钥被破解，也不会影响它协商出的其它密钥的安全性。
二、IPSec协议框架
IPsec（Internet Protocol Security）是为IP网络提供安全性的一系列协议和服务的集合，通过这些协议和服务，可以在两个设备之间建立一条IPsec加密隧道。数据通过IPsec加密隧道进行传输，能够有效保证数据的安全性.IPsec通过加密、验证等方式为IP数据包提供安全服务，可提供的安全服务包括：
-
数据加密(Confidentiality）
发送方对数据进行加密，使数据以密文的形式在Internet上传输；接收方对接收到的加密数据进行解密后进行后续处理或直接转发。
-
数据完整性验证（Data Integrity）
接收方对数据完整性进行验证，确保数据在传输路径上未被篡改。
-
数据源验证（Data Origin Authentication）
接收方对数据发送方的身份进行验证，确保数据来自身份真实且合法的发送者。
-
防止数据重放（Anti-Replay）
接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包进行攻击。
安全联盟
安全联盟SA（Security Association）是通信对等体间对某些要素的协定，它描述了对等体间如何利用安全服务（例如加密）进行安全的通信。这些要素包括对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密和验证算法，以及用于数据安全转换、传输的密钥和SA的生存周期等。
IPSec安全传输数据的前提是在IPSec对等体（即运行IPSec协议的两个端点）之间成功建立安全联盟。IPSec安全联盟简称IPSec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是为唯一标识SA而生成的一个32位比特的数值，它被封装在AH和ESP头中。
IPSec SA是单向的逻辑连接，通常成对建立（Inbound和Outbound）。因此两个IPSec对等体之间的双向通信，最少需要建立一对IPSec SA形成一个安全互通的IPSec隧道，分别对两个方向的数据流进行安全保护，如图所示。
另外，IPSec SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。
建立IPSec SA有两种方式：手工方式和IKE方式。二者的主要差异如表所示。手工和IKE方式的差异
|
对比项 |
手工方式建立IPSec SA |
IKE方式自动建立IPSec SA |
|---|---|---|
|
加密/验证密钥配置和刷新方式 |
手工配置、刷新，而且易出错 密钥管理成本很高 |
密钥通过DH算法生成、动态刷新 密钥管理成本低 |
|
SPI取值 |
手工配置 |
随机生成 |
|
生存周期 |
无生存周期限制，SA永久存在 |
由双方的生存周期参数控制，SA动态刷新 |
|
安全性 |
低 |
高 |
|
适用场景 |
小型网络 |
小型、中大型网络 |
安全协议
IETF RFC中定义了IPsec的框架标准，如图所示。
IPSec使用认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两种IP传输层协议来提供认证或加密等安全服务。
-
AH协议
AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头，如封装模式所示。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
-
ESP协议
ESP支持认证和加密功能。ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data），如封装模式所示。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。
|
安全特性 |
AH |
ESP |
|---|---|---|
|
协议号 |
51 |
50 |
|
数据完整性校验 |
支持（验证整个IP报文） |
支持（传输模式：不验证IP头，隧道模式：验证整个IP报文） |
|
数据源验证 |
支持 |
支持 |
|
数据加密 |
不支持 |
支持 |
|
防报文重放攻击 |
支持 |
支持 |
|
IPSec NAT-T（NAT穿越） |
不支持 |
支持 |
从表中可以看出两个协议各有优缺点，在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。
报文头结构
AH报文头结构
|
字段 |
长度 |
含义 |
|---|---|---|
|
下一头部 |
8比特 |
标识AH报文头后面的负载类型。传输模式下，是被保护的上层协议（TCP或UDP）或ESP协议的编号；隧道模式下，是IP协议或ESP协议的编号。 说明：
当AH与ESP协议同时使用时，AH报文头的下一头部为ESP报文头。 |
|
负载长度 |
8比特 |
表示以32比特为单位的AH报文头长度减2，缺省为4。 |
|
保留字段 |
16比特 |
保留将来使用，缺省为0。 |
|
SPI |
32比特 |
IPSec安全参数索引，用于唯一标识IPSec安全联盟。 |
|
序列号 |
32比特 |
是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。 |
|
认证数据 |
一个变长字段，长度为32比特的整数倍，通常为96比特。 |
该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。 说明：
MD5和SHA1验证算法存在安全隐患，建议优先使用SHA2或SM3算法。 |
ESP报文头结构
ESP报文头结构如图3所示；ESP报文头字段含义如表4所示。
|
字段 |
长度 |
含义 |
|---|---|---|
|
SPI |
32比特 |
IPSec安全参数索引，用于唯一标识IPSec安全联盟。 |
|
序列号 |
32比特 |
是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。 |
|
负载数据 |
— |
包含原始IP报文中可变长度数据内容。ESP保护的内容类型由下一头部字段标识。 |
|
填充字段 |
— |
用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的长度不是加密算法所要求的块长度时，需要进行填充补齐。 |
|
填充长度 |
8比特 |
给出前面填充字段的长度，置0时表示没有填充。 |
|
下一头部 |
8比特 |
标识ESP报文头后面的下一个负载类型。传输模式下，是被保护的上层协议（TCP或UDP）的编号；隧道模式下，是IP协议的编号。 |
|
认证数据 |
一个变长字段，长度为32比特的整数倍，通常为96比特。 |
该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。可选择的认证算法与AH的相同。 ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。 |
封装模式
封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。
传输模式
在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。以TCP报文为例，原始报文经过传输模式封装后，报文格式如图4所示。
传输模式下，与AH协议相比，ESP协议的完整性验证范围不包括IP头，无法保证IP头的安全。
隧道模式
在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。以TCP报文为例，原始报文经隧道模式封装后的报文结构如图5所示。
隧道模式下，与AH协议相比，ESP协议的完整性验证范围不包括新IP头，无法保证新IP头的安全。
传输模式和隧道模式比较
传输模式和隧道模式的区别在于：
-
从安全性来讲，隧道模式优于传输模式。它可以完全地对原始IP数据报进行验证和加密。隧道模式下可以隐藏内部IP地址，协议类型和端口。
-
从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。
-
从场景来讲，传输模式主要应用于两台主机或一台主机和一台VPN网关之间通信；隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。
当安全协议同时采用AH和ESP时，AH和ESP协议必须采用相同的封装模式。
加密和验证
IPSec提供了两种安全机制：加密和验证。加密机制保证数据的机密性，防止数据在传输过程中被窃听；验证机制能保证数据真实可靠，防止数据在传输过程中被仿冒和篡改。
加密
IPSec采用对称加密算法对数据进行加密和解密。如图6所示，数据发送方和接收方使用相同的密钥进行加密、解密。
用于加密和解密的对称密钥可以手工配置，也可以通过IKE协议自动协商生成。
常用的对称加密算法包括：数据加密标准DES（Data Encryption Standard）、3DES（Triple Data Encryption Standard）、先进加密标准AES（Advanced Encryption Standard）、国密算法（SM1和SM4）。其中，DES和3DES算法安全性低，存在安全风险，不推荐使用。
验证
IPSec的加密功能，无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC（Keyed-Hash Message Authentication Code）功能，比较完整性校验值ICV进行数据包完整性和真实性验证。
通常情况下，加密和验证通常配合使用。如图7所示，在IPSec发送方，加密后的报文通过验证算法和对称密钥生成完整性校验值ICV，IP报文和完整性校验值ICV同时发给对端；在IPSec接收方，使用相同的验证算法和对称密钥对加密报文进行处理，同样得到完整性校验值ICV，然后比较完整性校验值ICV进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。
同加密一样，用于验证的对称密钥也可以手工配置，或者通过IKE协议自动协商生成。
常用的验证算法包括：消息摘要MD5（Message Digest 5）、安全散列算法SHA1（Secure Hash Algorithm 1）、SHA2、国密算法SM3。其中，MD5、SHA1算法安全性低，存在安全风险，不推荐使用。
密钥交换
使用对称密钥进行加密、验证时，如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题：
-
带外共享密钥
在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式（例如通过电话或邮件方式）保证密钥一致性。这种方式的缺点是安全性低，可扩展性差，在点到多点组网中配置密钥的工作量成倍增加。另外，为提升网络安全性需要周期性修改密钥，这种方式下也很难实施。
-
使用一个安全的密钥分发协议
通过IKE协议自动协商密钥。IKE采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥。这种方式配置简单，可扩展性好，特别是在大型动态的网络环境下此优点更加突出。同时，通信双方通过交换密钥交换材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥，这样极大地提高了安全性。
IKE协议
因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的配置和维护工作。
IKE与IPSec的关系如图8所示，对等体之间建立一个IKE SA完成身份验证和密钥信息交换后，在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。
IKE SA是一个双向的逻辑连接，两个对等体间只建立一个IKE SA。
IKE安全机制
-
身份认证
身份认证确认通信双方的身份（对等体的IP地址或名称），包括预共享密钥PSK（pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证。
-
在预共享密钥认证中，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。
当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。
-
在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。
-
在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。
数字信封认证用于设备需要符合国家密码管理局要求时使用，此认证方法只能在IKEv1的主模式协商过程中支持。
IKE支持的认证算法有：MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。
-
-
身份保护
身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
IKE支持的加密算法有：DES、3DES、AES-128、AES-192、AES-256
-
DH
DH是一种公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
-
PFS
完善的前向安全性PFS（Perfect Forward Secrecy）通过执行一次额外的DH交换，确保即使IKE SA中使用的密钥被泄露，IPSec SA中使用的密钥也不会受到损害。
-
MD5和SHA1认证算法不安全，建议使用SHA2-256、SHA2-384、SHA2-512、SM3算法。
-
DES和3DES加密算法不安全，建议使用AES或SM算法。
IKE版本
IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：
-
简化了安全联盟的协商过程，提高了协商效率。
IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
-
修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
三、IPSec基本原理
IKE协议的终极目标是通过协商在总舵和分舵之间动态建立IPSec SA，并能够实时维护IPSec SA。为建立IPSec SA而进行的IKE协商工作是由ISAKMP报文来完成的，。ISAKMP报文封装如下：
IP报文头
- 源地址src：本端发起IKE协商的IP地址，可能是接口IP地址，也可能是通过命令配置的IP地址。
- 目的IP地址Dst：对端发起IKE协商的IP地址，由命令配置。
UDP报文头
IKE协议使用端口号500发起协商、响应协商。在总舵和分舵都有固定IP地址时，这个端口在协商过程中保持不变。当总舵和分舵之间有NAT设备时（NAT穿越场景），IKE协议会有特殊处理（后续揭秘）。
ISAKMP报文头
- Initiator’s Cookie（SPI）和responder’s Cookie（SPI）：在IKEv1版本中为Cookie，在IKEv2版本中Cookie为IKE的SPI，唯一标识一个IKE SA。
- Version：IKE版本号1。
- Exchange Type：IKE定义的交互类型2。交换类型定义了ISAKMP消息遵循的交换顺序。
- Next Payload：标识消息中下一个载荷的类型。一个ISAKMP报文中可能装载多个载荷，该字段提供载荷之间的“链接”能力。若当前载荷是消息中最后一个载荷，则该字段为0。
- Type Payload：载荷类型，ISAKMP报文携带的用于协商IKE SA和IPSec SA的“参数包”。载荷类型有很多种，不同载荷携带的“参数包”不同。不同载荷的具体作用我们后面会结合抓包过程逐一分析。
说明：
1：IKE诞生以来，有过一次大的改进。老的IKE被称为IKEv1，改进后的IKE被称为IKEv2。二者可以看做是父子关系，血脉相承，基本功能不变；但青胜于蓝，后者有了长足的进步。
2：IKEv1版本中可以在交换类型字段查看协商模式，阶段1分为两种模式：主模式和野蛮模式，阶段2采用快速模式。主模式是主流技术，野蛮模式是为解决现实问题而产生的。IKEv2版本中定义了查看创建IKE SA和CHILD SA（对应IKEv1的IPSec SA）的IKE_SA_INIT、IKE_AUTH（创建第一对CHILD SA）、CREATE_CHILD_SA（创建后续的CHILD SA）。
IPSec通过在IPSec对等体间建立双向安全联盟形成一个安全互通的IPSec隧道，并通过定义IPSec保护的数据流将要保护的数据引入该IPSec隧道，然后对流经IPSec隧道的数据通过安全协议进行加密和验证，进而实现在Internet上安全传输指定的数据。
IPSec安全联盟可以手工建立，也可以通过IKEv1或IKEv2协议自动协商建立。本文重点介绍如何定义IPSec保护的数据流、IKE自动协商建立安全联盟的过程。
定义IPSec保护的数据流
-
ACL方式
手工方式和IKE自动协商方式建立的IPSec隧道是由ACL来指定要保护的数据流范围，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，未匹配任何permit规则的报文将不被保护。这种方式可以利用ACL的丰富配置功能，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定IPSec的保护方法。需要把感兴趣流的路由指定到出接口。
-
路由方式
通过IPSec虚拟隧道接口建立IPSec隧道，将所有路由到IPSec虚拟隧道接口的报文都进行IPSec保护，根据该路由的目的地址确定哪些数据流需要IPSec保护。其中IPSec虚拟隧道接口是一种三层逻辑接口。
路由方式具有以下优点：
-
通过路由将需要IPSec保护的数据流引到虚拟隧道接口，不需使用ACL定义待加/解密的流量特征，简化了IPSec配置的复杂性。
-
支持动态路由协议。
-
通过GRE over IPSec支持对组播流量的保护。
-
IKEv1协商安全联盟的过程
采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。
IKEv1协商阶段1
IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。
IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。
-
消息①和②用于提议交换
发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
-
消息③和④用于密钥信息交换
双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
- 消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证和对整个主模式交换内容的认证。
-
IKE安全提议指IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等。
-
nonce是个随机数，用于保证IKE SA存活和抗重放攻击。
野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。IKEv1协商阶段1的协商过程如图9所示。
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。
第 1 阶段使用预共享密钥进行身份验证
主模式
Initiator Responder
-------------------------------------------------------
HDR, SA -->
<-- HDR, SA
HDR, KE, Ni -->
<-- HDR, KE, Nr
HDR*, IDii, HASH_I -->
<-- HDR*, IDir, HASH_R野蛮模式
Initiator Responder
-------------------------------------------------------
HDR, SA, KE, Ni, IDii -->
<-- HDR, SA, KE, Nr, IDir, HASH_R
HDR, HASH_I -->
IKEv1协商阶段2
IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图10所示。
IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立：
-
协商发起方发送本端的安全参数和身份认证信息。
安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。
IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。
-
协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。
IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。
如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。
- 发送方发送确认信息，确认与响应方可以通信，协商结束。
Initiator Responder
------------------------------------------------------------------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
其中：
HASH(1) 是消息 id 上的 prf (M-ID) 来自 ISAKMP 标头，与散列后的整个消息连接，包括所有有效负载标头，但不包括为加密添加的任何填充。
HASH(2) 与 HASH(1) 相同，除了发起者的随机数——Ni，减去有效负载标头——添加在 M-ID 之后但在完整消息之前。将 nonce 添加到 HASH(2) 是为了进行
活性证明。
HASH(3)——为了活跃——是表示为单个八位字节的值零上的 prf ，后跟消息 ID 和两个随机数的串联——发起者的，然后是响应者的——减去有效负载标头。换句话说，
上述交换的哈希值是：
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)
第一个包
第二个包
第三、四个包
第五、第六个包
第二阶段三个协商报文
IKEv2协商安全联盟的过程
采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。
初始交换
正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息，如图5-11所示。
消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。
消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
创建子SA交换
当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。
创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。
类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
通知交换
运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的，如图5-12所示。
通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。
IKEv2报文协商详细过程：
消息中包含的有效载荷由下面列出的名称表示
Notation Payload
-----------------------------------------
AUTH Authentication 认证
CERT Certificate 证书
CERTREQ Certificate Request 证书请求
CP Configuration 配置
D Delete 删除
EAP Extensible Authentication 扩展身份认证
HDR IKE header (not a payload) ike的头部
IDi Identification - Initiator 标识-发起人
IDr Identification - Responder 标识-响应人
KE Key Exchange 钥匙交换
Ni, Nr Nonce 随机数
N Notify 通知
SA Security Association 安全联盟
SK Encrypted and Authenticated 加密和认证
TSi Traffic Selector - Initiator 流量选择-发起人
TSr Traffic Selector - Responder 流量选择-响应人
V Vendor ID 供应商 ID初始交换机消息（initial exchanges）
IKE_AUTH交换
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
-------------------------------------------------------------------
其中SAI1和SAr1分别表示发起者的sa和响应者的sa，同理后面的i和r分别代表发起者和响应者HDR 包含安全参数索引 (SPI)、版本号和各种标志。 SAi1 负载说明发起方支持的 IKE SA 的加密算法。 KE 负载发送发起方的 Diffie-Hellman 值。 Ni 是发起者的随机数。响应者收到后会从发起者提供的选择中选择一个加密套件，并在 SAr1 有效载荷中表达该选择，完成与 KEr 有效载荷的 Diffie-Hellman 交换，并在 Nr 有效载荷中发送其随机数。
在协商的这一点上，每一方都可以生成 SKEYSEED，从这个SKEYSEED 派生出该 IKE SA 的所有密钥。除了消息头之外，后面的消息整体上都经过加密和完整性保护。用于加密和完整性保护的密钥源自 SKEYSEED，称为 SK_e（加密）和 SK_a（身份验证，又名完整性保护）；对于每个方向计算单独的 SK_e 和 SK_a。除了从用于保护 IKE SA 的 Diffie-Hellman 值导出的密钥 SK_e 和 SK_a 之外，还导出了另一个数量 SK_d 并用于导出子 SA 的进一步密钥材料。
由于发起者在 IKE_SA_INIT 中发送其 Diffie-Hellman 值，因此它必须猜测响应方将从其支持的组列表中选择的 Diffie-Hellman 组。如果发起者猜错了，响应者将响应一个类型为 INVALID_KE_PAYLOAD（钥匙交换无效） 的通知有效负载进行响应，指示所选组。在这种情况下，发起者必须使用更正的 Diffie-Hellman 组重试 IKE_SA_INIT。发起者必须再次提出其完整的可接受的加密套件集，因为拒绝消息未经身份验证，否则主动攻击者可能会诱使端点协商较弱的套件，而不是他们都喜欢的更强的套件。
第一个包：Responder SPI的值为0，Flags位的Initiator的值为1，标志位发起方。Message ID的值也为0，该值和下一个会回应方的Message ID值相同。用来标即区分一对request/response消息对
KE载荷和Nonce在和主要用来作为密钥素材来交换
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)---------加密密钥
在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设备之后。
第二个包：SPIi为发起方的SPI,SPIr中填充自己生产的spi，Flags中的Response位置1，表示自己为回应方的报文。Message ID的值同第一个报文的Message ID，为0.
Vendor ID Payload 包含一个供应商定义的常量。供应商使用常量来识别和识别其实现的远程实例。这种机制允许供应商在保持向后兼容性的同时试验新功能
IKE_AUTH交换
当需要nat穿越时，目的端口此时已经为4500.
Initiator Responder
-------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}发起者使用 IDi 有效载荷声明其身份，证明知道对应于 IDi 的秘密，并且完整性使用 AUTH 有效载荷保护第一条消息的内容（参见第 2.15 节）。它还可能在 CERT 有效载荷中发送其证书，并在 CERTREQ 有效载荷中发送其信任锚列表。如果包含任何 CERT 有效负载，则提供的第一个证书必须包含用于验证 AUTH 字段的公钥。
可选的有效载荷 IDr 使发起者能够指定它想要与响应者的哪个身份交谈。当运行响应程序的机器在同一 IP 地址上托管多个身份时，这很有用。如果发起者提议的 IDr 不被响应者接受，响应者可能会使用一些其他的 IDr 来完成交换。如果发起者随后不接受响应者使用的 IDr 与请求的 IDr 不同的事实，发起者可以在注意到这一事实后关闭 SA。
流量选择器（TSi 和 TSr）可以用来协商双方的感兴趣流。在IKEv2中可以协商，取感兴趣流的交集。但是在IKEv1中不能协商，只能双方互相配置为镜像地址。
发起方使用 SAi2 负载开始协商子 SA。最终字段（从 SAi2 开始）在 CREATE_CHILD_SA 交换的描述中进行了描述。
响应者使用 IDr 负载声明其身份，可选择发送一个或多个证书（再次使用包含用于验证第一个列出的 AUTH 的公钥的证书），验证其身份并使用 AUTH 负载保护第二个消息的完整性，以及使用下面在 CREATE_CHILD_SA 交换中描述的附加字段完成子 SA 的协商。IKE_AUTH 交换中的双方必须验证所有签名和消息身份验证代码 (MACs) 的计算是否正确。如果任一方使用共享密钥进行认证，则 ID 有效载荷中的名称必须与用于生成 AUTH 有效载荷的密钥相对应。
如果在 IKE_AUTH 交换过程中由于某种原因创建子 SA 失败，仍照常创建 IKE SA。 IKE_AUTH 交换中不会阻止建立 IKE SA 的通知消息类型列表至少包括以下内容：NO_PROPOSAL_CHOSEN（无提议选择）、TS_UNACCEPTABLE（流量选择器不接受）、SINGLE_PAIR_REQUIRED（必须单个配对）、INTERNAL_ADDRESS_FAILURE（内部地址失败） 和 FAILED_CP_REQUIRED（必须配置失败）。
如果失败与创建IKE SA有关（例如，返回AUTHENTICATION_FAILED Notify错误消息），则不会创建IKE SA。注意，虽然 IKE_AUTH 消息经过加密和完整性保护，但如果收到此 Notify 错误消息的对端尚未对另一端进行身份验证（或者对端由于某种原因未能对另一端进行身份验证），则需要对信息进行处理警告。更准确地说，假设MAC验证正确，则已知错误Notify消息的发送者是IKE_SA_INIT交换的响应者，但无法确定发送者的身份。请注意，IKE_AUTH 消息不包含 KEi/KEr 或 Ni/Nr 有效载荷。因此，IKE_AUTH 交换中的 SA 负载不能包含具有除 NONE 之外的任何值的转换类型 4（Diffie-Hellman 组）。实现应该省略整个转换子结构而不是发送值 NONE。
CREATE_CHILD_SA 交换
CREATE_CHILD_SA 交换用于创建新的子 SA 和重新加密 IKE SA 和子 SA。此交换由单个请求/响应对组成，其部分功能在 IKEv1 中称为第 2 阶段交换。它可以在初始交换完成后由 IKE SA 的任一端发起。
CREATE_CHILD_SA 请求可以可选地包含一个额外的 Diffie-Hellman 交换的 KE 有效载荷，以便为子 SA 启用更强大的前向保密保证。 Child SA 的密钥材料是在 IKE SA 建立期间建立的 SK_d、CREATE_CHILD_SA 交换期间交换的随机数以及 Diffie-Hellman 值（如果 KE 有效载荷包含在 CREATE_CHILD_SA 交换中）的函数。
使用 CREATE_CHILD_SA 交换创建新的子 SA
Initiator Responder
------------------------------------ ------------------------------
HDR, SK {SA, Ni, [KEi],
TSi, TSr} -->
<-- HDR, SK {SA, Nr, [KEr],
TSi, TSr}发起者在 SA 有效载荷中发送 SA 提议，在Ni有效载荷中发送随机数，在 KEi 有效载荷中发送可选的 Diffie-Hellman 值，并在 TSi和TSr 有效载荷中为建议的子 SA 发送建议的流量选择器。
如果请求中包含 KEi 并且所选的加密套件包含该组，则响应者回复（使用相同的消息 ID 进行响应）在 SA 有效负载中使用已接受的提议，并在 KEr 有效负载中使用 Diffie-Hellman 值。将在该 SA 上发送的流量的流量选择器在响应中的 TS 有效载荷中指定，这可能是子 SA 的发起者提议的子集。USE_TRANSPORT_MODE 通知可以包含在请求消息中，该消息还包括请求子 SA 的 SA 有效负载。它请求子 SA 为创建的 SA 使用传输模式而不是隧道模式。如果请求被接受，响应还必须包括 USE_TRANSPORT_MODE 类型的通知。如果响应方拒绝该请求，则以隧道模式建立子 SA。如果发起者不能接受，发起者必须删除 SA。注意：除了使用此选项协商传输模式时，所有子 SA 都将使用隧道模式。创建子 SA 的失败尝试不应拆除 IKE SA：没有理由丢失为设置 IKE SA 所做的工作。有关创建子 SA 失败，可能出现的错误消息列表。
使用 CREATE_CHILD_SA 交换IKE SA 进行密钥更新
Initiator Responder
-------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} -->
<-- HDR, SK {SA, Nr, KEr}发起方在 SA 有效载荷中发送 SA 提议，在 Ni 有效载荷中发送随机数，并在 KEi 有效载荷中发送 Diffie-Hellman 值。 必须包括 KEi 有效载荷。 在 SA 有效载荷的 SPI 字段中提供了一个新的发起方 SPI。 一旦对等方收到重新加密 IKE SA 的请求或发送重新加密 IKE SA 的请求，它不应在正在重新加密的 IKE SA 上启动任何新的 CREATE_CHILD_SA 交换
如果选定的加密套件包含该组，则响应者回复（使用相同的消息 ID 进行响应）在 SA 有效载荷中接受提议，并在 KEr 有效载荷中使用 Diffie-Hellman 值。 在 SA 有效载荷的 SPI 字段中提供了一个新的响应者 SPI。新的 IKE SA 将其消息计数器设置为 0，无论它们在早期的 IKE SA 中是什么。 来自新 IKE SA 双方的第一个 IKE 请求将具有消息 ID 0。旧 IKE SA 保留其编号，因此任何进一步的请求（例如，删除 IKE SA）将具有连续编号。 新的 IKE SA 也将其窗口大小重置为 1，并且此密钥交换中的发起者是新 IKE SA 的新“原始发起者”。
使用 CREATE_CHILD_SA 重新加密生成子 SA
Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
TSi, TSr} -->
<-- HDR, SK {SA, Nr, [KEr],
TSi, TSr}如果交换的目的是替换现有的 ESP 或 AH SA，则 REKEY_SA 通知必须包含在 CREATE_CHILD_SA 交换中。重新加密的 SA 由 Notify 有效载荷中的 SPI 字段标识；这是交换发起方在入站 ESP 或 AH 数据包中期望的 SPI。没有与此 Notify 消息类型相关联的数据。 REKEY_SA 通知的协议 ID 字段设置为匹配我们正在重新生成密钥的 SA 的协议，例如，ESP 为 3，AH 为 2。
信息交流
在 IKE SA 操作期间的各个点，对等方可能希望相互传达关于某些事件的错误或通知的控制消息。为了实现这一点，IKE 定义了一个信息交换。信息交换必须仅在初始交换之后发生，并且使用协商密钥进行加密保护。请注意，一些信息性消息，而不是交换，可以在 IKE SA 的上下文之外发送。属于 IKE SA 的控制消息必须在该 IKE SA 下发送。与子 SA 相关的控制消息必须在生成它们的 IKE SA（或其后继，如果 IKE SA 被重新加密）的保护下发送。信息交换中的消息包含零个或多个通知、删除和配置负载。信息交换请求的接收者必须发送一些响应；否则，发送方将假定消息在网络中丢失并重新传输。该响应可能是一个空消息。 INFORMATIONAL 交换中的请求消息也可以不包含有效载荷。这是端点可以要求另一个端点验证它是否处于活动状态的预期方式。
Initiator Responder
-------------------------------------------------------------------
HDR, SK {[N,] [D,]
[CP,] ...} -->
<-- HDR, SK {[N,] [D,]
[CP], ...}ESP 和 AH SA 总是成对存在，每个方向有一个 SA。当一个 SA 关闭时，该对的两个成员都必须关闭（即删除）。每个端点必须关闭它的传入 SA，并允许另一个端点关闭每对中的另一个 SA。为了删除一个 SA，一个带有一个或多个删除有效载荷的信息交换被发送，其中列出了要删除的 SA 的 SPI（正如它们在入站数据包的报头中所预期的那样）。接收者必须关闭指定的 SA。请注意，永远不会在单个消息中为 SA 的两侧发送 Delete 有效负载。如果要同时删除许多 SA，则在 INFORMATIONAL 交换中，每个 SA 对的入站一半包括删除有效负载。通常，INFORMATIONAL 交换中的响应将包含在另一个方向上配对的 SA 的删除有效负载。有一个例外。如果偶然地，一组 SA 的两端独立决定关闭它们，则每个 SA 都可以发送删除有效负载，并且这两个请求可能会在网络中交叉。如果一个节点收到一个删除请求的 SAs，它已经发出了删除请求，它必须在处理请求时删除传出的 SA，在处理响应时删除传入的 SA。在那种情况下，响应不能包括删除的 SA 的删除有效载荷，因为这会导致重复删除并且理论上可能会删除错误的 SA。与 ESP 和 AH SA 类似，IKE SA 也可以通过发送信息交流。删除 IKE SA 会隐式关闭根据它协商的任何剩余子 SA。对删除 IKE SA 的请求的响应是一个空的 INFORMATIONAL 响应。半封闭的 ESP 或 AH 连接是异常的，如果它们持续存在，具有审计能力的节点可能应该审计它们的存在。请注意，此规范未指定时间段，因此由各个端点决定等待多长时间。节点可以拒绝接受半关闭连接上的传入数据，但不得单方面关闭它们并重用 SPI。如果连接状态变得非常混乱，节点可以关闭 IKE SA，如上所述。然后它可以在新的 IKE SA 下的干净基础上重建它需要的 SA。
DPD(dead peer detection)
当两个对等体之间采用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有两种模式可以选择：按需型和周期型。
- 按需型：当本端需要向对端发送IPsec报文时，如果当前距离最后一次收到对端的IPsec报文的时长已超过DPD空闲时间，则触发DPD检测，本端主动向对端发送DPD请求报文。
- 周期型：如果当前距离最后一次收到对端的IPsec报文或DPD请求报文的时长已超过DPD空闲时间，则本端主动向对端发送DPD请求报文。本端主动向对端发送DPD请求报文后，若在DPD报文重传间隔内没有收到对端的DPD回应报文，则向对端重传DPD请求报文，根据重传次数进行重传之后，若仍然没有收到对端的DPD回应报文，则认为对端离线，删除该IKE SA和对应的IPsec SA
DPD 交换是双向 (HELLO/ACK) 通知消息
Sender Responder
---------------------------------------------------------------------------------
HDR*, NOTIFY(R-U-THERE), HASH ------>
<------ HDR*, NOTIFY(R-U-THERE-
ACK), HASH
---------------------------------------------------------------------------------
R-U-THERE消息对应于“HELLO”，R-U-THERE-ACK对应于“ACK”。这两条消息都是简单的 ISAKMP 通知有效载荷，因此，本文档定义了这两种新的 ISAKMP
通知消息类型：
Notify Message Value
R-U-THERE 36136
R-U-THERE-ACK 36137NOTIFY(R-U-THERE/R-U-THERE-ACK) 消息格式
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+由于此消息是ISAKMP NOTIFY，因此应相应地设置下一个有效负载、保留和有效负载长度字段。其余字段设置为：
IKEv1和IKEv2有哪些区别
①、协商过程不同。
IKEv1协商安全联盟主要分为两个阶段。
IKEv1阶段1的目的是建立IKE SA，它支持两种协商模式：主模式和野蛮模式。主模式用6条ISAKMP消息完成协商。野蛮模式用3条ISAKMP消息完成协商。野蛮模式的优点是建立IKE SA的速度较快。但是由于野蛮模式密钥交换与身份认证一起进行无法提供身份保护。
IKEv1阶段2的目的就是建立用来传输数据的IPSec SA，通过快速交换模式（3条ISAKMP消息）完成协商。
− IKEv2
IKEv2简化了安全联盟的协商过程。IKEv2正常情况使用2次交换共4条消息就可以完成一个IKE SA和一对IPSec SA，如果要求建立的IPSec SA大于一对时，每一对SA只需额外增加1次交换，也就是2条消息就可以完成。
②、 认证方法不同。
IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。IKEv1无法提供此功能，必须借助L2TP来分配私网地址。
③、 IKE SA的完整性算法支持情况不同。
IKE SA的完整性算法仅IKEv2支持，IKEv1不支持。
④、DPD中超时重传实现不同。
retry-interval参数仅IKEv1支持。表示发送DPD报文后，如果超过此时间间隔未收到正确的应答报文，DPD记录失败事件1次。当失败事件达到5次时，删除IKE SA和相应的IPSec SA。直到隧道中有流量时，两端重新协商建立IKE SA。
对于IKEv2方式的IPSec SA，超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文，则认为对端已经下线，删除IKE SA和相应的IPSec SA。
⑤、 IKE SA超时时间手工调整功能支持不同。
IKEv2的IKE SA软超时为硬超时的9/10±一个随机数，所以IKEv2一般不存在两端同时发起重协商的情况，故IKEv2不需要配置软超时时间。
表12-1 IKE SA超时时间手工调整功能
⑥、 IPSec SA超时时间手工调整功能支持不同。
IKEv2的IKE SA软超时为硬超时的9/10±一个随机数，所以IKEv2一般不存在两端同时发起重协商的情况，故IKEv2不需要配置软超时时间。
表12-2 IPSec SA超时时间手工调整功能
ikev1和ikev2对比
|
功能项 |
IKEv1 |
IKEv2 |
|
IPSec SA建立过程 |
分两个阶段，阶段1分两种模式：主模式和野蛮模式，阶段2为快速模式。 主模式+快速模式需要9条信息建立IPSec SA。 野蛮模式+快速模式需要6条信息建立IPSec SA。 |
不分阶段，最少4条消息即可建立IPSec SA。 |
|
ISAKMP |
二者支持的载荷类型不同 |
|
|
认证方法 |
预共享密钥 数字证书 数字信封（较少使用） |
预共享密钥 数字证书 EAP 数字信封（较少使用） |
|
IKE SA完整性算法 |
不支持 |
支持 |
|
PFS |
支持 |
支持 |
|
远程接入 |
通过L2TP over IPSec来实现 |
支持 |
四、IPSec报文处理流程
-
安全策略数据库SPDB（Security Policy Database）：定义IP数据报文应使用何种安全服务，以及如何获得这些服务。SPDB是SA创建的前提，决定了SA的作用范围和相关属性。
-
安全联盟数据库SADB（Security Association Database）：存放与SA关联的所有状态数据的存储结构。因为一个网络实体可以创建多对SA，所以需要有个DB来做存储管理。
-
SPI（安全参数索引）：一个携带在AH或ESP头部的一个32位数值，接收端通过SPI来判断接收到的数据流应该用SADB中的哪个SA来做安全保护。
工作原理
IPsec虚拟隧道接口对报文的加封装/解封装发生在隧道接口上。用户流量到达实施IPsec配置的设备后，需要IPsec处理的报文会被转发到IPsec虚拟隧道接口上进行加封装/解封装。
如图1-2所示，IPsec虚拟隧道接口对报文进行加封装的过程如下：
图 3 IPsec虚接口隧道加封装原理图
(1) Router将从入接口接收到的IP明文送到转发模块进行处理；
(2) 转发模块依据路由查询结果，将IP明文发送到IPsec虚拟隧道接口进行加封装：原始IP报文被封装在一个新的IP报文中，新IP头中的源地址和目的地址分别为隧道接口的源地址和目的地址。
(3) IPsec虚拟隧道接口完成对IP明文的加封装处理后，将IP密文送到转发模块进行处理；
(4) 转发模块进行第二次路由查询后，将IP密文通过隧道接口的实际物理接口转发出去。
如图1-3所示，IPsec虚拟隧道接口对报文进行解封装的过程如下：
图 4 IPsec虚接口隧道解封装原理图
(1) Router将从入接口接收到的IP密文送到转发模块进行处理；
(2) 转发模块识别到此IP密文的目的地为本设备的隧道接口地址且IP协议号为AH或ESP时，会将IP密文送到相应的IPsec虚拟隧道接口进行解封装：将IP密文的外层IP头去掉，对内层IP报文进行解密处理。
(3) IPsec虚拟隧道接口完成对IP密文的解封装处理之后，将IP明文重新送回转发模块处理；
(4) 转发模块进行第二次路由查询后，将IP明文从隧道的实际物理接口转发出去。
从上面描述的加封装/解封装过程可见，IPsec虚拟隧道接口将报文的IPsec处理过程区分为两个阶段：“加密前”和“加密后”。需要应用到加密前的明文上的业务（例如NAT、QoS），可以应用到隧道接口上；需要应用到加密后的密文上的业务，则可以应用到隧道接口对应的物理接口上。
五、典型组网应用
1、IPsec反向路由注入功能
如图1所示，某企业在企业分支与企业总部之间的所有流量通过IPsec进行保护，企业总部网关上需要配置静态路由，将总部发往分支的数据引到应用IPsec安全策略的接口上来。当企业分支众多或者内部网络规划发生变化时，就需要同时增加或调整总部网关上的静态路由配置，该项工作量大且容易出现配置错误。
图1 IPsec VPN总部-分支组网图
RRI（Reverse Route Injection，反向路由注入）功能可以很好的解决以上问题。RRI是一种自动添加到达IPsec VPN私网静态路由的机制，可以实现为受IPsec保护的流量自动添加静态路由的功能。如上IPsec VPN组网中，当企业总部侧网关设备GW上配置RRI功能后，每一个IPsec隧道建立之后，GW都会自动为其添加一条相应的静态路由。通过RRI创建的路由表项可以在路由表中查询到，其目的地址为受保护的对端网络，下一跳地址为IPsec隧道的对端地址，它使得发往对端的流量被强制通过IPsec保护并转发。
RRI创建的静态路由和手工配置的静态路由一样，可以向内网设备进行广播，允许内网设备选择合适的路由对IPsec VPN流量进行转发。
在MPLS L3VPN组网环境中，配置了RRI功能的网关设备能够依据应用IPsec安全策略的接口所绑定的VPN实例，在相应VPN实例的IP路由表中自动添加静态路由。
在大规模组网中，这种自动添加静态路由的机制可以简化用户配置，减少在企业总部网关设备上配置静态路由的工作量，并且可以根据IPsec SA的创建和删除进行静态路由的动态增加和删除，增强了IPsec VPN的可扩展性。
华为：route inject命令用来配置路由注入功能
华三：
|
开启IPsec反向路由注入功能 |
reverse-route dynamic |
缺省情况下，IPsec反向路由注入功能处于关闭状态 |
|
（可选）配置IPsec反向路由功能生成的静态路由的优先级 |
reverse-route preference number |
缺省情况下，IPsec反向路由注入功能生成的静态路由的优先级为60 |
|
（可选）配置IPsec反向路由功能生成的静态路由的Tag值 |
reverse-route tag tag-value |
缺省情况下，IPsec反向路由注入功能生成的静态路由的tag值为0 |
2、IPsec智能选路场景
如图2所示，企业分支使用IPsec VPN接入企业总部，通过在分支上配置IPsec智能选路功能，实现IPsec隧道在两条链路上动态切换。
图2 IPsec智能选路场景配置组网图
华为：执行命令ipsec smart-link profileprofile-name，创建IPSec智能选路规则并进入IPSec智能选路视图。执行命令smart-link enable，启用IPSec智能选路规则。缺省情况下，IPSec智能选路规则处于启用状态。
华三：
(1)进入系统视图。
system-view
(2)配置IPsec智能选路策略。
创建一条IPsec智能选路策略，并进入IPsec智能选路策略视图。
ipsec smart-link policy policy-name
缺省情况下，不存在IPsec智能选路策略。
IPsec智能选路策略只能被IKE方式的IPsec安全策略引用，不能被模板方式和手工方式的IPsec安全策略引用。
配置IPsec智能选路的链路。
link link-id interface interface-type interface-number [ local local-address nexthop nexthop-address ] remote remote-address
缺省情况下，不存在IPsec智能选路链路。
开启IPsec智能选路功能。
smart-link enable
缺省情况下，IPsec智能选路功能处于关闭状态。
只有在IPsec智能选路功能处于开启状态的情况下，链路质量探测功能和链路切换功能才会生效。
（可选）手动激活指定的IPsec智能选路的链路。
activate link link-id
手动激活链路后，会直接切换到该链路上建立IPsec隧道。
在智能选路功能开启的情况下，手动激活链路后，如果该链路的丢包率或时延高于设定的阈值，设备同样会进行链路的循环切换。循环切换的起始链路是手动激活的这条链路，循环切换的终止链路仍然是优先级最低的链路。
在智能选路功能关闭的情况下不会进行链路自动切换。
（可选）调整IPsec智能选路的链路优先级。
move link link-id1 before link-id2
缺省情况下，IPsec按照配置的先后顺序选择链路，先配置的链路优先级高，后配置的链路优先级低。
也可使用move link命令移动链路的先后顺序来调整链路的优先级。当链路进行切换时，会按照链路的优先级从高到低顺序切换。
（可选）配置IPsec智能选路链路循环切换的最大次数。
link-switch cycles number
缺省情况下，IPsec智能选路链路循环切换的最大次数为3。
循环切换的最大次数取值为0时，表示不限制链路循环切换的次数。
配置IPsec智能选路链路探测报文的发送时间间隔和每个探测周期内发送探测报文的总数。
link-probe { interval interval | count number }
缺省情况下，IPsec智能选路链路探测报文的发送时间间隔为1秒，每个探测周期内发送探测报文的总数为10个。
配置IPsec智能选路链路探测报文的源IP地址和目的IP地址。
link-probe source source-address destination destination-address
缺省情况下，使用IPsec智能选路链路中配置的本端IP地址和对端IP地址作为探测报文的源IP地址和目的IP地址。
配置IPsec智能选路链路切换的阈值。
link-switch threshold { loss loss-ratio | delay delay }
缺省情况下，IPsec智能选路策略下丢包率阈值为30%，时延阈值为500毫秒。
(3)退回系统视图。
quit
(4)进入接口视图。
interface interface-type { interface-number | interface-number.subnumber }
(5)配置接口的网关地址。
gateway gateway-address [ no-route ]
缺省情况下，接口上未配置网关地址。
当IPsec智能选路链路中没有指定下一跳且不能自动获取时，必须在此接口上配置网关地址。
当本端接口通过DHCP或PPPoE方式获取IP地址时，配置的gateway不生效，获取的网关地址为Server端下发的下一跳。
(6)退回系统视图。
quit
(7)进入IPsec安全策略视图。
ipsec policy policy-name seq-number isakmp
(8)配置IPsec安全策略引用的IPsec智能选路策略。
smart-link policy policy-name
缺省情况下，IPsec安全策略未引用IPsec智能选路策略。3、IPSec隧道途径NAT设备
在防火墙处理流程中，NAT在上游，IPSec在下游，所以IPSec流量难免会受到NAT的干扰。IPSec流量一旦命中NAT策略就会进行NAT转换，转换后的流量不会匹配IPSec中的ACL，也就不会进行IPSec处理。解决这个问题的方法就是在NAT策略中配置一条针对IPSec流量不进行地址转换的策略，该策略的优先级要高于其他的策略，并且该策略中定义的流量范围是其他策略的子集。这样的话，IPSec流量会先命中不进行NAT转换的策略，地址不会被转换，也就不会影响下面IPSec环节的处理，而需要进行NAT处理的流量也可以命中其他策略正常转换。
NAT策略的配置如下：
nat-policy interzone trust untrust outbound
policy 0 //需要IPSec保护的流量不进行NAT转换
action no-nat
policy source 172.16.1.0 mask 24
policy destination 192.168.0.0 mask 24
policy 5 //访问Internet的流量进行NAT转换
action source-nat
policy source 172.16.1.0 mask 24
address-group 1
若分舵网关B上还配置了NAT Server，配置NAT Server时生成的反向Server-map表也干扰IPSec流量。分舵中的服务器访问总舵时，流量会命中反向Server-map表，然后进行地址转换，转换后的流量不会匹配IPSec中的ACL，也就不会进行IPSec处理。此时就需要在配置NAT Server时指定no-reverse参数，不生成反向Server-map表。
- IKEv1协商NAT穿越大揭秘
1. 开启NAT穿越时，IKEv1协商第一阶段的前两个消息会发送标识NAT穿越（NAT Traversal，简称NAT-T）能力的Vendor ID载荷（主模式和野蛮模式都是）。用于检查通信双方是否支持NAT-T。
当双方都在各自的消息中包含了该载荷时，才会进行相关的NAT-T协商。
2. 主模式消息3和消息4（野蛮模式消息2和消息3）中发送NAT-D（NAT Discovery）载荷。NAT-D载荷用于探测两个要建立IPSec隧道的网关之间是否存在NAT网关以及NAT网关的位置。
通过协商双方向对端发送源和目的的IP地址与端口的Hash值，就可以检测到地址和端口在传输过程中是否发生变化。若果协商双方计算出来的Hash值与它收到的Hash值一样，则表示它们之间没有NAT。否则，则说明传输过程中对IP或端口进行了NAT转换。
第一个NAT-D载荷为对端IP和端口的Hash值，第二个NAT-D载荷为本端IP和端口的Hash值。
3. 发现NAT网关后，后续ISAKMP消息（主模式从消息5、野蛮模式从消息3开始）的端口号转换为4500。ISAKMP报文标识了“Non-ESP Marker”。
4. 在第二阶段会启用NAT穿越协商。在IKE中增加了两种IPSec报文封装模式：UDP封装隧道模式报文（UDP-Encapsulated-Tunnel）和UDP封装传输模式报文（UDP-Encapsulated-Transport）。通过为ESP报文封装UDP头，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。
- IKEv2协商NAT穿越大揭秘
1. 开启NAT穿越后，IKE的发起者和响应者都在IKE_SA_INIT消息对中包含类型为NAT_DETECTION_SOURCE_IP和NAT_DETECTION_DESTINATION_IP的通知载荷。这两个通知载荷用于检测在将要建立IPSec隧道的两个网关之间是否存在NAT，哪个网关位于NAT之后。如果接收到的NAT_DETECTION_SOURCE通知载荷没有匹配数据包IP头中的源IP和端口的Hash值，则说明对端位于NAT网关后面。如果接收到的NAT_DETECTION_DESTINATION_IP通知载荷没有匹配数据包IP头中的目的IP和端口的Hash值，则意味着本端位于NAT网关之后。
2. 检测到NAT网关后，从IKE_AUTH消息对开始ISAKMP报文端口号改为4500。报文标识“Non-ESP Marker”。
IKEv2中也使用UDP封装ESP报文，当封装后的报文通过NAT设备时，NAT设备对该报文的外层IP头和增加的UDP头进行地址和端口号转换。UDP报文端口号修改为4500。
六、常见的一些报错导致隧道无法建立
notion消息-错误类型
NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
不支持的关键有效负载
IKEv2 向每个有效负载标头添加了一个“关键”标志，以进一步提高前向兼容性的灵活性。如果设置了关键标志并且有效负载类型无法识别，则必须拒绝该消息
，并且对包含该有效负载的 IKE 请求的响应必须包含通知有效负载 UNSUPPORTED_CRITICAL_PAYLOAD，指示包含不支持的关键有效负载。
INVALID_IKE_SPI 4
无效的IKe spi.
INVALID_IKE_SPI通知表示收到的 IKE 消息的目标 SPI 无法识别；这通常表明接收方已重新启动并忘记了 IKE SA 的存在。接收此类不受保护的通知负载的对等方不得响应
，也不得更改任何现有 SA 的状态。该消息可能是伪造的，也可能是真正的通讯员被欺骗发送的回复。节点应将此类消息（以及诸如该 IP 地址的 SA 可能存在问题的提示任何此
类 IKE SA 发起活动检查。实现应该限制此类测试的频率，以避免被欺骗参与 DoS 攻击。
INVALID_MAJOR_VERSION 5
无效的主要版本
如果端点收到具有更高主版本号的消息，则它必须丢弃该消息，并且应该发送类型为 INVALID_MAJOR_VERSION 的未经身份验证的通知消息，其中包含其支持的最高（最接近）版本号
INVALID_SYNTAX 7
无效语法
表示收到的 IKE 消息无效，因为某些类型、长度或值超出范围，或者由于策略原因拒绝请求。为了避免使用伪造消息进行DoS如果消息 ID 和加密校验和有效，则只能在加密数据包中返回此状态为了避免
向探测节点的人泄露信息，必须发送此状态以响应其他状态类型之一未涵盖的任何错误。为了帮助调试，应将更详细的错误信息写入控制台或日志
INVALID_MESSAGE_ID 9
无效的消息ID
当收到支持窗口之外的IKE 消息 ID 时，将发送 INVALID_MESSAGE_ID 通知。该通知消息不得在响应中发送；无效请求不得被确认
INVALID_SPI 11
无效的SPI
如果 ESP 或 AH 数据包到达时带有无法识别的 SPI。这可能是由于接收节点最近崩溃并丢失了状态，或者因为其他一些系统故障或攻击如果接收节点有一个活动的 IKE SA 到数据包来自的 IP 地址，
它可以在信息交换中通过该 IKE SA 发送一个关于任性数据包的 INVALID_SPI 通知。通知数据包含无效数据包的 SPI
NO_PROPOSAL_CHOSEN 14
没有提议选择
没有一个提议的加密套件是可以接受的。这可以在响应者不接受所提供的提议（包括但不限于 SA 有效载荷值、USE_TRANSPORT_MODE 通知、IPCOMP_SUPPORTED 通知）的任何情况下发送。
当由于某些其他原因无法创建子 SA 时，这也可以用作“通用”子 SA 错误
INVALID_KE_PAYLOAD 17
无效的KE负载
AUTHENTICATION_FAILED 24
认证失败
SINGLE_PAIR_REQUIRED 34
必须单队
SINGLE_PAIR_REQUIRED 错误表明 CREATE_CHILD_SA 请求是不可接受的，因为它的发送者只愿意接受指定一对地址的流量选择器。请求者应通过仅针对它尝试转发的特定流量请求 SA 来进行响应。
NO_ADDITIONAL_SAS 35
无附加SA
响应者发送 NO_ADDITIONAL_SAS 通知以指示 CREATE_CHILD_SA 请求是不可接受的，因为响应者不愿意接受此 IKE SA 上的任何子 SA。此通知还可用于拒绝 IKE SA 重新生成密钥
INTERNAL_ADDRESS_FAILURE 36
内部地址失败
如果响应方在处理配置负载期间尝试将 IP 地址分配给发起方时遇到错误，它将以 INTERNAL_ADDRESS_FAILURE 通知进行响应
FAILED_CP_REQUIRED 37
CP(CFG_REQUEST) 中未包含的其他属性，并且可以忽略它不支持的非强制属性。响应方在未首先从发起方收到 CP(CFG_REQUEST) 之前不得发送 CFG_REPLY ，因为如果 IRAC 无法处理 REPLY ，我们不希望
IRAS 执行不必要的配置查找。如果 IRAS 的配置要求 CP 用于给定身份 IDi，但 IRAC 未能发送CP(CFG_REQUEST)，IRAS 必须使请求失败，并终止子进程
SA 创建时出现 FAILED_CP_REQUIRED 错误。FAILED_CP_REQUIRED对于 IKE SA 来说并不是致命的；它只会导致子 SA 创建失败。发起者可以通过稍后启动新的
配置有效负载请求来解决此问题。FAILED_CP_REQUIRED 错误中没有关联数据
TS_UNACCEPTABLE 38
流量选择器不能接受
如果响应方的策略不允许它接受建议的流量选择器的任何部分，则它会使用 TS_UNACCEPTABLE通知消息进行响应。
INVALID_SELECTORS 39
无效选择器
当节点收到与发送该数据包的 SA 的选择器不匹配丢弃）时，可以在 IKE INFORMATIONAL 交换中发送。通知数据包含违规数据包的开始如 ICMP 消息中），并且通知的 SPI 字段设置为与子 SA 的 SPI 相匹配
TEMPORARY_FAILURE 43
临时故障
当对等方收到由于临时条件（例如重新生成密钥操作）而无法完成的请求时，应该发送 TEMPORARY_FAILURE 通知。当对等方收到 TEMPORARY_FAILURE通知时，它不得立即重试该操作；它必须
等待，以便发送者可以完成导致该错误的任何操作暂时的情况。接收者可以在几分钟内重试该请求一次或多次。如果几分钟后对等方继续在同一个 IKE SA 上收到 TEMPORARY_FAILURE，
则它应该断定状态信息不同步并关闭 IKE SA
CHILD_SA_NOT_FOUND 44
没发现子sa
当对等方收到对不存在的子 SA 重新生成密钥的请求时，应该发送 CHILD_SA_NOT_FOUND 通知。发起者尝试重新生成密钥的 SA由通知负载中的 SPI 字段指示，该字段是从 REKEY_SA 通知中的 SPI 字段复制而来的。
收到 CHILD_SA_NOT_FOUND 通知的对等点应静默删除子 SA（如果仍然存在）并发送请求以从头开始创建新的子 SA（如果子 SA 尚不存在）notion消息状态类型
NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
初始联系
SET_WINDOW_SIZE 16385
设置窗口大小
ADDITIONAL_TS_POSSIBLE 16386
额外可能的流量选择器
ADDITIONAL_TS_POSSIBLE通知断言响应者缩小了建议的流量选择器范围，但其他流量选择器也可以接受，尽管仅在单独的SA 中
IPCOMP_SUPPORTED 16387
支持IP压缩.
NAT_DETECTION_SOURCE_IP 16388
nat检测数据源
NAT_DETECTION_DESTINATION_IP 16389
nat检测数据目的
COOKIE 16390
Cookie是保存在计算机上的一种文件。当我们使用计算机浏览网页时，服务器会生成一个证书并将其返回给我们的计算机。这个证书是cookie。一般来说，cookie是服务器写给客户端的文件，也可以称为浏览器缓存
USE_TRANSPORT_MODE 16391
See Section 1.3.1.
使用传输模式
HTTP_CERT_LOOKUP_SUPPORTED 16392
支持http查找证书
REKEY_SA 16393
重置sa密匙
ESP_TFC_PADDING_NOT_SUPPORTED 16394
ESP_TFC_PADDING_NOT_SUPPORTED 通知断言发送端点不会接受包含通过正在协商的子 SA 的流量流机密性 (TFC) 填充的数据包
NON_FIRST_FRAGMENTS_ALSO 16395
NON_FIRST_FRAGMENTS_ALSO 通知用于碎片控制IPSEC隧道建立失败报错信息
IPSec隧道建立失败的常见原因如下所示：
phase1 proposal mismatch：两端IKE安全提议参数不匹配。
phase2 proposal or pfs mismatch：两端IPSec安全提议参数或PFS算法不匹配。
responder dh mismatch：响应方的DH算法不匹配。
initiator dh mismatch：发起方的DH算法不匹配。
encapsulation mode mismatch：封装模式不匹配。
flow or peer mismatch：两端Security ACL或IKE Peer地址不匹配。
version mismatch：两端IKE版本号不匹配。
peer address mismatch：两端的IKE Peer地址不匹配。
config ID mismatch：根据ID未找到匹配的IKE Peer。
exchange mode mismatch：两端的协商模式不匹配。
authentication fail：身份认证失败。
construct local ID fail：构造本端ID失败。
rekey no find old sa：重协商时找不到旧的SA。
rekey fail：重协商时旧的SA正在下线。
first packet limited：首包限速。
unsupported version：不支持的IKE版本号。
malformed message：畸形消息。
malformed payload：畸形载荷。
critical drop：未识别的critical载荷。
cookie mismatch：Cookie不匹配。
invalid cookie：无效Cookie。
invalid length：报文长度非法。
unknown exchange type：未知的协商模式。
uncritical drop：未识别的非critical载荷。
route limit：路由注入的数目达到规格。
ip assigned fail：IP地址分配失败。
local address mismatch：IKE协商时的本端IP地址和接口IP地址不匹配。
dynamic peers number reaches limitation：IKE对等体数达到规格。
ipsec tunnel number reaches limitation：IPSec隧道数达到规格。
in disconnect state：在disconnect状态拆除IPSec隧道。
netmask mismatch：开启IPSec掩码过滤功能后，掩码不匹配。
flow confict：数据流冲突。
proposal mismatch or use sm in ikev2：IPSec安全提议不匹配或者IKEv2使用SM算法。
ikev2 not support sm in ipsec proposal ikev2：IKEv2不支持IPSec安全提议的SM算法。
no policy applied on interface：没有策略应用到接口上。
none of user's interface is selected：根据对端ID选取用户表中Tunnel接口失败。
nat detection fail：NAT探测失败。
fragment packet limit：分片报文超规格。
fragment packet reassemble timeout：分片报文重组超时。
处理步骤
原因：phase1 proposal mismatch
请查看两端的IKE安全提议参数，并执行相应的命令将不匹配的参数修改一致。
原因：phase2 proposal or pfs mismatch
请查看两端的IPSec安全提议参数或PFS算法，并执行相应的命令将不匹配的参数修改一致。
原因：responder dh mismatch、initiator dh mismatch
请查看两端的DH算法，并执行相应的命令将DH算法修改一致。
原因：encapsulation mode mismatch
请查看两端的封装模式，并执行相应的命令将封装模式修改一致。
原因：ip assigned fail
请确保AAA和IPSec的相关配置正确，例如IP Pool、AAA业务方案、为IKE用户分配的IP地址。
原因：peer address mismatch
请查看两端的IKE对等体地址，并执行相应的命令修改不匹配的IKE对等体地址。
原因：config ID mismatch
请查看身份认证参数，例如ID类型和ID值，执行相应的命令修改不匹配的参数。
原因：authentication fail
请查看两端的IKE安全提议参数或IKE对等体参数，并执行相应的命令将两端的参数修改一致
原因：exchange mode mismatch
请查看两端的IKEv1阶段1协商模式，并执行相应的命令将两端的协商模式修改一致。
原因：route limit
请更换路由注入规格更高的设备，并合理规划网络。
原因：local address mismatch
请查看IKE协商时的本端IP地址和接口IP地址，并执行相应的命令将地址修改一致。
原因：ipsec tunnel number reaches limitation
请删除不必要的IPSec隧道或设备扩容。
原因：dynamic peers number reaches limitation
请设备扩容，并合理规划网络。
原因：none of user's interface is selected
请查看IKE用户表中ID类型和ID值、IKE用户关联的接口，并执行相应的命令修改不匹配的参数。
原因： proposal mismatch or use sm in ikev2、ikev2 not support sm in ipsec proposal
请查看IPSec安全提议中IKEv2使用的算法，并执行相应的命令将算法修改正确。
原因：flow confict
请查看两端的ACL规则，并执行相应的命令将ACL规则修改正确。
原因：netmask mismatch
请修改分支或总部保护的IPSec数据流范围，使得各分支和总部协商的数据流不存在交集。
原因：no policy applied on interface
请在接口上应用相应的IPSec策略。
原因：fragment packet limit
收到的分片报文数超过规格，请合理调整对端设备的MTU值。
原因：fragment packet reassemble timeout
请确保两端链路正常及设备状态正常。
七、协议规范
- RFC 2401：Security Architecture for the Internet Protocol
- RFC 2402：IP Authentication Header
- RFC 2406：IP Encapsulating Security Payload
- RFC 2408：Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409: The Internet Key Exchange https://datatracker.ietf.org/doc/html/rfc2409
- RFC 3706：A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peer
- RFC 4552：Authentication/Confidentiality for OSPFv3
- RFC 5996：Internet Key Exchange Protocol Version 2 (IKEv2) https://datatracker.ietf.org/doc/html/rfc5996
