IKE v2为什么协商速度快？

IKEv2在第一次发包的时候猜测对端要使用的DH组，于是先手在本端使用了它觉得对端可能使用的DH组，然后将KE值以及随机数都准备好，然后发送过去，如果猜中了那么对端将进行响应回复。如果猜错了，那么将回复INVALID_KE_PAYLOAD，并在该包中携带自己使用DH组和相关密钥材料，这样IKEv2在协商密钥的阶段交互的包的数量是2-4个。在普通的主模式或者野蛮模式中，身份验证和IPsecSA的协商是分离的，在主模式或者野蛮模式中，身份的验证一般是在最后一对数据报文中实现，在IKEv2中，由于第一次报文交互中就有可能协商出IKE SA，所以它们在传统的主模式上进行了改造，将身份验证和IPsec SA的协商糅合在一起，即在第二次报文交互的时候既发送身份信息，也发送创建相关IPsec SA的材料，如果身份验证成功了那么对端自然会在回包中与你进行正常的IPsec SA的交互，如若不然则不会对你进行响应。

1. IKEv2 支持 DH 猜想

在 IKEv2 初始交换阶段，发起方采用“猜”的办法，猜一个响应方最可能使用的 DH 组，携带在第 一条消息中发送。响应方根据发起方“猜”的 DH 组来响应发起方。如果发起方猜测成功，则这样 通过两条消息就可以完成 IKEv2 初始交换。如果发起方猜测错误，则响应方会回应一个 INVALID_KE_PAYLOAD 消息，并在该消息中指明将要使用的 DH 组。之后，发起方采用响应方指 定的 DH 组重新发起协商。 这种 DH 猜想机制，使得发起方的 DH 组配置更为灵活，可适应不同的响应方。

2. IKEv2 支持 Cookie-challenge 机制

在 IKEv2 初始交换中的 IKE_INIT_SA 消息是明文传输的，因此该消息有可能被篡改仿冒，响应方 接收到第一个消息后无法确认该消息是否来自一个仿冒的地址。如果此时一个网络攻击者伪造大量 地址向响应方发送 IKEv2 初始交换请求，根据 IKEv1 协议，响应方需要维护这些半连接状态的 IKE 会话信息，从而耗费响应方大量的系统资源，造成对响应方的 DoS 攻击。 IKEv2 使用 Cookie-challenge 机制来解决这类 DoS 攻击问题。当响应方发现存在的半连接状态的 IKEv2 SA 超过指定的数目时，就会启用 Cookie-challenge 机制。响应方收到 IKEv2 初始连接请求 后，构造一个 Cookie 通知载荷并发送给发起方，若发起方能够正确携带收到的 Cookie 通知载荷向 响应方重新发起 IKEv2 初始交换请求，则可以继续后续的协商过程。 半连接状态的 IKEv2 SA 是指那些正在协商过程中的 IKEv2 SA。若半连接状态的 IKEv2 SA 数目减 少至阈值以下，则 Cookie-challenge 功能将会停止工作。

3. IKEv2 SA 重协商

为了保证安全，IKE SA 和 IPsec SA 都有一个生存时间，超过生存时间的 SA 需要重新协商，即 SA 的重协商。与 IKEv1 不同的是，IKEv2 SA 的生存时间不需要协商，由各自的配置决定，重协商总 是由生存时间较小的一方发起，可尽量避免两端同时发起重协商造成冗余 SA 的生成，导致两端 SA 状态不一致。

4. IKEv2 报文确认重传机制

与 IKEv1 不同的是，IKEv2 中发起方发送的所有消息都需要响应方进行确认，从而提高报文传输的 可靠性。IKEv2 中所有消息都是以“请求–响应”对的形式出现，IKEv2 通过消息头中的一个 Message ID 字段来标识一个“请求–响应”对，发起方发送的每一条消息都需要响应方给予确认。例如建立 一个 IKEv2 SA 一般需要两个“请求-响应”对，如果发起方在规定时间内没有接收到确认报文，则 需要对该请求消息进行重传。IKEv2 消息的重传只能由发起方发起，且重传消息的 Message ID 必 须与原始消息的 Message ID 一致。

参考文档：IPsec技术白皮书