ikev2
RFC 5996 - Internet Key Exchange Protocol Version 2 (IKEv2) (ietf.org)
https://datatracker.ietf.org/doc/html/rfc5996定义在RFC4306,更新于RFC5996
不兼容IKEV1，ikev1不支持认证，ikev2支持认证，eap。
支持nat穿越
支持私密性、完整性、源认证
工作在UDP500端口NAT-T时使用UDP4500端口。
初始交换
正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息
消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。
消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
RFC4306节选：
使用 IKE 的通信总是从 IKE_SA_INIT 和 IKE_AUTH 交换开始（在 IKEv1 中称为阶段 1）。 这些初始交换通常由四个消息组成，但在某些情况下，数量可能会增加。 所有使用 IKE 的通信都由请求/响应对组成。 我们将首先描述基础交换，然后是变体。 第一对消息 (IKE_SA_INIT) 协商加密算法，交换随机数，并进行 Diffie-Hellman 交换 [DH]。
第二对消息 (IKE_AUTH) 验证先前的消息，交换身份和证书，并建立第一个 CHILD_SA。 这些消息的一部分通过 IKE_SA_INIT 交换建立的密钥进行加密和完整性保护，因此对窃听者隐藏身份，并且所有消息中的所有字段都经过身份验证。
初步交流如下:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni --><-- HDR, SAr1, KEr, Nr, [CERTREQ]HDR 包含各种安全参数索引 (SPI)、版本号和标志。 SAi1 载荷携带发起方为 IKE_SA 支持的加密算法。 KE 载荷携带发起者的 Diffie-Hellman 值（K值）。 Ni是发起者的nonce。
响应者从发起者提供的选项中选择一个加密套件，并在 SAr1 有效负载中表达该选择，完成与 KEr 有效负载的 Diffie-Hellman 交换，并在 Nr 有效负载中发送其随机数。
Notation Payload
-----------------------------------------
AUTH Authentication
CERT Certificate
CERTREQ Certificate Request
CP Configuration
D Delete
EAP Extensible Authentication
HDR IKE header (not a payload)
IDi Identification - Initiator
IDr Identification - Responder
KE Key Exchange，发起方提供的密钥交换材料，优先使用最高安全级别的dh组
Ni, Nr Nonce
N Notify
SA Security Association，发起方提供的密码学算法
SK Encrypted and Authenticated，负载被加密并且完整性保护
TSi Traffic Selector - Initiator，感兴趣流
TSr Traffic Selector - Responder，感兴趣流
V Vendor ID
1.2消息用于初始交换，相当于ike v1主模式的1234消息。
第一个包：发起方提供基本的ike sa参数和密钥交换材料
responder cookie的值为0，flags位的init值置位，标志发起方，messageid的值也为0，该值和下一个回应方的message id值相同，用来标识一对request/response消息对。
第二个包：响应方发送匹配的ike sa参数和密钥交换材料
3.4个包是ike-auth
ike-auth在ike-sa-init所创建的ike-sa之上，协商各种加密、验证、完整性校验协议，用于建立第一个child-sa。
协商到达这一步，每一方都可以生成 SKEYSEED，从该 SKEYSEED 中为该 IKE_SA 派生所有密钥。 除了后面的所有消息的头部之外，所有消息都经过加密和完整性保护。 用于加密和完整性保护的密钥源自 SKEYSEED，称为 SK_e（加密）和 SK_a（身份验证，也称为完整性保护）。 为每个方向计算单独的 SK_e 和 SK_a。 除了从 DH 值导出的用于保护 IKE_SA 的密钥 SK_e 和 SK_a 之外，还导出了另一个数量 SK_d 并将其用于导出用于 CHILD_SA 的进一步密钥材料。 符号 SK { ... } 表示这些有效载荷是使用该方向的 SK_e 和 SK_a 加密和完整性保护的。
Initiator Responder
----------- -----------
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr} --><-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}发起者用 IDi 有效载荷声明其身份，证明与 IDi 对应的秘密的知识，完整性保护使用 AUTH 有效载荷的第一条消息的内容。 它还可能在 CERT 有效负载中发送其证书，并在 CERTREQ 有效负载中发送其信任列表。 如果包含任何 CERT 有效负载，则提供的第一个证书必须包含用于验证 AUTH 字段的公钥。 可选的有效载荷 IDr 使发起者能够指定它想要与哪个响应者的身份进行交谈。 当运行响应程序的机器在同一个 IP 地址托管多个身份时，这很有用。 发起者使用 SAi2 有效负载开始协商 CHILD_SA。 最后的字段（从 SAi2 开始）在 CREATE_CHILD_SA 交换的描述中描述。
响应者使用 IDr 有效负载声明其身份，可选地发送一个或多个证书（再次使用包含用于验证第一个列出的 AUTH 的公钥的证书），验证其身份并使用 AUTH 有效负载保护第二条消息的完整性，以及 使用 CREATE_CHILD_SA 交换中描述的附加字段完成 CHILD_SA 的协商。
消息 3 和 4 的接收者必须验证所有签名和 MAC 的计算是否正确，并且 ID 有效负载中的名称与用于生成 AUTH 有效负载的密钥相对应。
SK:负载被加密并且完整性保护
AUTH:发起方认证数据，如果没有EAP就没有这个字段
SAi2:发起方child sa转换集，描述create-child-sa的交换参数，指的是ipsec sa，而init中的SAi1指的是IKE SA
TSi/TSr:child sa流量选择器，即感兴趣流，在ikev2中感兴趣流是可以进行协商的，协商得到交集。
第三个包（加密）：创建child sa相关的认证内容和参数
相当于ikev1的主模式5和部分快速模式的内容
第四个包（加密）：创建与child sa相关的认证内容和参数
相当于ikev1主模式的第6个包和部分快速模式的包
创建子SA交换
当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。
创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。
类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
rfc4306节选：
创建子SA交换
此交换由单个请求/响应对组成，在 IKEv1 中称为第 2 阶段交换。 它可以在初始交换完成后由 IKE_SA 的任一端发起。
初始交换之后的所有消息都使用 IKE 交换的前两条消息中协商的加密算法和密钥进行加密保护。 所有后续消息都包含一个加密有效载荷。
任何一个端点都可以启动CREATE_CHILD_SA交换，因此在本节中，术语“启动器”指启动此交换的端点。
CHILD_SA 是通过发送 CREATE_CHILD_SA 请求来创建的。 CREATE_CHILD_SA 请求可以可选地包含一个 KE 有效负载，用于额外的 Diffie-Hellman 交换，以增强对 CHILD_SA 前向保密的保证。 CHILD_SA 的密钥材料是 IKE_SA 建立期间建立的 SK_d、CREATE_CHILD_SA 交换期间交换的 nonces 和 Diffie-Hellman 值的函数（如果 KE 有效负载包含在 CREATE_CHILD_SA 交换中）。
在作为初始交换的一部分创建的 CHILD_SA 中，不得发送第二个 KE 有效负载和 nonce。 初始交换的随机数用于计算 CHILD_SA 的密钥。
The CREATE_CHILD_SA request contains:
Initiator Responder
----------- -----------
HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} -->The CREATE_CHILD_SA response contains:
<-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]}
发起者在 SA 有效载荷中发送 SA 提议，在 Ni 有效载荷中发送随机数，在 KEi 有效载荷中发送可选的 Diffie-Hellman 值，以及在 TSi 和 TSr 有效载荷中建议的流量选择器。 如果这个 CREATE_CHILD_SA 交换正在更新除 IKE_SA 之外的现有 SA，则 REKEY_SA 类型的前导 N 有效负载必须标识正在更新密钥的 SA。 如果这个 CREATE_CHILD_SA 交换没有更新现有 SA 的密钥，则必须省略 N 有效载荷。 如果 SA 提议包含不同的 Diffie-Hellman 组，则 KEi 必须是发起方期望响应方接受的组的一个元素。 如果它猜错了，CREATE_CHILD_SA 交换将失败，它必须用不同的 KEi 重试。
使用为IKE_SA协商的加密算法对标头后面的消息进行加密，并对包含标头的消息进行完整性保护。
如果 KEi 包含在请求中并且所选加密套件包含该组，则响应者使用 SA 有效负载中接受的提议和 KEr 有效负载中的 Diffie-Hellman 值来回复（使用相同的消息 ID 进行响应）。 如果响应者选择了具有不同组的加密套件，它必须拒绝该请求。 发起者应该重复请求，但现在使用响应者选择的组中的 KEi 有效负载。
在该 SA 上发送的流量的流量选择器在 TS 有效载荷中指定，它可能是 CHILD_SA 的发起者提议的内容的子集。 如果此 CREATE_CHILD_SA 请求用于更改 IKE_SA 的密钥，则忽略流量选择器。
共享密钥计算如下。 一个称为 SKEYSEED 的数量是根据在 IKE_SA_INIT 交换期间交换的随机数和在该交换期间建立的 Diffie-Hellman 共享秘密计算得出的。 SKEYSEED 用于计算其他七个秘密： SK_d 用于为使用此 IKE_SA 建立的 CHILD_SA 导出新密钥； SK_ai 和 SK_ar 用作完整性保护算法的密钥，用于验证后续交换的组件消息； SK_ei 和 SK_er 用于加密（当然还有解密）所有后续交换； 以及 SK_pi 和 SK_pr，它们在生成 AUTH 有效负载时使用。
SKEYSEED = prf(Ni | Nr, K)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
(SKEYSEED, Ni | Nr | SPIi | SPIr )
（表示量SK_d、SK_ai、SK_ar、SK_ei、SK_er、SK_pi、SK_pr从prf+的生成位开始依次取）。 K是来自短暂的 Diffie-Hellman 交换的共享秘密。 g^ir 表示为大端顺序的八位字节串，如有必要，用零填充以使其成为模数的长度。 Ni 和 Nr 是随机数，没有任何标题。 如果协商的 prf 采用一个固定长度的密钥，并且 Ni 和 Nr 的长度加起来不等于该长度，则一半的位必须来自 Ni，一半来自 Nr，取每个的第一个位。
两个交通流方向使用不同的密钥。 用于保护来自原始发起者的消息的密钥是 SK_ai 和 SK_ei。 用于保护另一个方向的消息的密钥是 SK_ar 和 SK_er。 每个算法都采用固定数量的密钥材料，这是算法的一部分。 对于基于密钥散列的完整性算法，密钥大小始终等于底层散列函数的输出长度。
通知交换
运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的。
通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。
ikev1默认不支持对远程接入者的认证机制，需要配置l2tp，形成l2tp over ipsec
flags字段不同
IKEv1与IKEv2的区别：
可比较的角度：
- IPsec建立过程，报文角度
阶段比较，IKEv1有两个阶段，IKEv2没有阶段。
- IKEv1
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条消息就可以完成。
- 载荷角度
AUTH，TSi，TSr，EAP - 认证方法
IKEv2支持EAP身份认证。IKEv2可以借助认证服务器对远程接入的PC、手机等进行身份认证、分配私网IP地址。IKEv1无法提供此功能，必须借助L2TP来分配私网地址。 - 支持远程接入
L2TP OVER IPSEC---------IKEV1解决方案 - 其他功能
NAT -T DPD
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不需要配置软超时时间。
总结：
IKEv1的主要问题：
- 不支持远程用户接入
- 协商建立IPSec SA的时间太长
IKEv2的改进：
- IKEv1是一个混合型协议，其自身的复杂性不可避免地带来一些安全及性能上的缺陷，已经成为目前实现IPSec系统的瓶颈。
- IKEv2协议保留了IKEv1的基本功能，并针对IKEv1研究过程中发现的问题进行修订，同时兼顾简洁性、高效性、安全性和见健壮性的需要，整合了IKEv1的相关文档，由RFC4306单个文档替代。通过核心功能最小化规定，新协议极大提高了不同IPSec VPN系统的互操作性。
IKEv2与IKEv1相比有以下优点：
- 简化了安全联盟的协商过程，提高了协商效率。
IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。 - 修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
- 加入对EAP（Extensible Authentication Protocol）身份认证方式的支持，提高了认证方式的灵活性和可扩展性。
EAP是一种支持多种认证方法的认证协议，可扩展性是其最大的优点，即若想加入新的认证方式，可以像组件一样加入，而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。 - 通过EAP协议解决了远程接入用户的认证问题，彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。
