IKEv2
IKEv2简介
IKEv2（Internet Key Exchange Version 2，互联网密钥交换协议第 2 版）是第 1 版本的 IKE 协议（本文简称 IKEv1）的增强版本。 IKEv2 与 IKEv1 相同，具有一套自保护机制，可以在不安全的网络上安全地进行身份认证、密钥分发、建立 IPsec SA。相对于 IKEv1， IKEv2 具有抗攻击能力和密钥交换能力更强以及报文交互数量较少等特点。
IKEv2的协商过程
要建立一对 IPsec SA， IKEv1 需要经历两个阶段，至少需要交换 6 条消息。在正常情况下， IKEv2只需要进行两次交互，使用 4 条消息就可以完成一个 IKEv2 SA 和一对 IPsec SA 的协商建立，如果要求建立的 IPsec SA 的数目大于一对，则每增加一对 IPsec SA 只需要额外增加一次交互，也就是两条消息就可以完成，这相比于 IKEv1 简化了设备的处理过程，提高了协商效率。
IKEv2 定义了三种交互：初始交换、创建子 SA 交换以及通知交换。下面简单介绍一下 IKEv2 协商过程中的初始交换过程。
如上图所示，IKEv2的初始交换过程中包含两个交换：IKE_SA_INIT交换（两条消息）和 IKE_AUTH交换（两条消息）。
- IKE_SA_INIT 交换：完成 IKEv2 SA 参数的协商以及密钥交换；
- IKE_AUTH 交换：完成通信对等体的身份认证以及 IPsec SA 的创建。这两个交换过程顺序完成后，可以建立一个 IKEv2 SA 和一对 IPsec SA。
创建子 SA 交换：当一个 IKE SA 需要创建多个 IPsec SA 时，使用创建子 SA 交换来协商多于一个的 SA，另外还可用于进行 IKE SA 的重协商功能。
通知交换：用于传递控制信息，例如错误信息或通告信息。
IKEv2 引入的新特性
IKEv2 支持DH猜想
在 IKE_SA_INIT 交换阶段，发起方采用“猜”的办法，猜一个响应方最可能使用的 DH 组携带在第一条消息中发送。响应方根据发起方“猜”的 DH 组来响应发起方。如果发起方猜测成功，则这样通过两条消息就可以完成 IKE_SA_INIT 交换。如果发起方猜测错误，则响应方会回应一个INVALID_KE_PAYLOAD 消息，并在该消息中指明将要使用的 DH 组。之后，发起方采用响应方指定的 DH 组重新发起协商。这种 DH 猜想机制，使得发起方的 DH 组配置更为灵活，可适应不同的响应方。
IKEv2 支持cookie-challenge机制
在 IKE_SA_INIT 交换中消息是明文传输的，响应方接收到第一个消息后无法确认该消息是否来自一个仿冒的地址。如果此时一个网络攻击者伪造大量地址向响应方发送 IKE_SA_INIT 请求，根据IKEv1 协议，响应方需要维护这些半开的 IKE 会话信息，从而耗费大量响应方的系统资源，造成对响应方的 DoS 攻击。IKEv2 使用 cookie-challenge 机制来解决这类 DoS 攻击问题。当响应方发现存在的半开 IKE SA 超过指定的数目时，就启用cookie-challenge机制。响应方收到IKE_SA_INIT请求后，构造一个Cookie通知载荷并响应发起方，若发起方能够正确携带收到的 Cookie 通知载荷向响应方重新发起IKE_SA_INIT 请求，则可以继续后续的协商过程。半开状态的 IKEv2 SA 是指那些正在协商过程中的 IKEv2 SA。 若半开状态的 IKEv2 SA 数目减少到阈值以下，则 cookie-challenge 功能将会停止工作
IKEv2 SA重协商
为了保证安全， IKE SA 和 IPsec SA 都有一个生存时间，超过生存时间的 SA 需要重新协商，即 SA 的重协商。与 IKEv1 不同的是， IKEv2 SA 的生存时间不需要协商，由各自的配置决定，重协商总 是由生存时间较小的一方发起，可尽量避免两端同时发起重协商造成冗余 SA 的生成，导致两端 SA 状态不一致。
IKEv2 报文确认重传机制
与 IKEv1 不同，IKEv2 中所有消息都是以“请求–响应”对的形式出现， IKEv2 通过消息头中的一 个 Message ID 字段来标识一个“请求–响应”对。发起方发送的每一条消息都需要响应方给予确认， 例如建立一个 IKE SA 一般需要两个“请求-响应”对。如果发起方在规定时间内没有接收到确认报 文，则需要对该请求消息进行重传。 IKEv2 消息的重传只能由发起方发起，且重传消息的 Message ID 必须与原始消息的 Message ID 一致。
协议规范
与 IKEv2 相关的协议规范有： • RFC 2408： Internet Security Association and Key Management Protocol (ISAKMP) • RFC 4306： Internet Key Exchange (IKEv2) Protocol • RFC 4718： IKEv2 Clarifications and Implementation Guidelines • RFC 2412： The OAKLEY Key Determination Protocol • RFC 5996： Internet Key Exchange Protocol Version 2 (IKEv2)