[RFC5996 翻译一] IKEv2 互联网密钥交换协议版本2

rfc5996 (ietf.org)

本文档介绍了 Internet 密钥交换 (IKE) 协议的第 2 版。 IKE 是 IPsec 的一个组件，用于执行相互身份验证以及建立和维护安全关联 (SA)。本文档替换并更新了 RFC 4306，并包含了 RFC 4718 中的所有说明。

目录

   1. 介绍

      1.1.使用场景

           1.1.1.隧道模式下的安全网关到安全网关

           1.1.2.端点到端点传输模式

           1.1.3.隧道模式下端点到安全网关

           1.1.4.其他场景

      1.2.最初的交流

      1.3. CREATE_CHILD_SA 交换

           1.3.1.使用 CREATE_CHILD_SA 交换创建新的子 SA

           1.3.2.使用 CREATE_CHILD_SA 交换重新加密 IKE SA

           1.3.3.使用 CREATE_CHILD_SA 交换重新生成子 SA

      1.4.信息交流

           1.4.1.使用信息交换删除 SA

      1.5. IKE SA 之外的信息性消息

      1.6.需求术语

 1.7. RFC 4306 与此文档之间的显着差异

   2. IKE 协议细节和变化

      2.1.重传定时器的使用

      2.2.使用序列号作为消息 ID

      2.3.重叠请求的窗口大小

      2.4.状态同步和连接超时

      2.5.版本号和向前兼容性

      2.6. IKE SA SPI 和 Cookie

           2.6.1. COOKIE 和 INVALID_KE_PAYLOAD 的交互

      2.7.密码算法协商

      2.8.更新密钥

           2.8.1.同步子 SA 重新生成密钥

           2.8.2.同步 IKE SA 密钥更新

           2.8.3.重新加密 IKE SA 与重新身份验证

      2.9.流量选择器协商

           2.9.1.违反自身策略的流量选择器

      2.10.随机数

      2.11.地址和端口敏捷性

      2.12.重复使用 Diffie-Hellman 指数

      2.13.生成密钥材料

      2.14.为 IKE SA 生成密钥材料

      2.15. IKE SA的认证

      2.16.可扩展的认证协议方法

      2.17.为子 SA 生成密钥材料

      2.18.使用 CREATE_CHILD_SA 交换重新加密 IKE SA

      2.19.请求远程网络上的内部地址

      2.20.请求对等体的版本

      2.21.错误处理

           2.21.1. IKE_SA_INIT 中的错误处理

           2.21.2. IKE_AUTH 中的错误处理

           2.21.3. IKE SA认证后的错误处理

           2.21.4. IKE SA 外部的错误处理

      2.22.知识产权公司

      2.23. NAT穿越

        2.23.1.传输模式 NAT 穿越

      2.24.显式拥塞通知 (ECN)

      2.25.交换冲突

           2.25.1.重新生成密钥或关闭子 SA 时发生冲突

           2.25.2.重新生成密钥或关闭 IKE SA 时发生冲突

   3. 标头和有效载荷格式

      3.1. IKE 标头

      3.2.通用有效负载标头

      3.3.安全协会有效载荷

           3.3.1.提案子结构

           3.3.2.变换子结构

3.3.3.协议的有效转换类型

           3.3.4.强制转换 ID

      3.3.5.变换属性

           3.3.6.属性协商

      3.4.密钥交换有效载荷

      3.5.识别有效载荷

      3.6.证书有效载荷

      3.7.证书请求负载

      3.8.身份验证负载

      3.9.随机数有效载荷

      3.10.通知有效载荷

           3.10.1.通知消息类型

      3.11.删除有效载荷

      3.12.供应商 ID 有效载荷

      3.13.流量选择器有效载荷

           3.13.1.流量选择器

      3.14.加密有效载荷

      3.15.配置负载

           3.15.1.配置属性

           3.15.2. INTERNAL_IP4_SUBNET 和 INTERNAL_IP6_SUBNET 的含义

           3.15.3. IPv6 的配置负载

           3.15.4.地址分配失败

      3.16.可扩展身份验证协议 (EAP) 有效负载

   4. 一致性要求

   5. 安全考虑

      5.1.流量选择器授权

   6. IANA 考虑

   7. 致谢

   8. 参考文献

      8.1.规范参考

      8.2.参考资料

   附录 A. IKEv1 更改摘要

   附录 B. Diffie-Hellman 群

     B.1.第 1 组 - 768 位 MODP

     B.2.第 2 组 - 1024 位 MODP

   附录 C. 交换和有效载荷

     C.1. IKE_SA_INIT 交换

     C.2.没有 EAP 的 IKE_AUTH 交换

     C.3. IKE_AUTH 与 EAP 交换

     C.4. CREATE_CHILD_SA 用于创建或重新生成子 SA 的交换

     C.5. CREATE_CHILD_SA 用于重新加密 IKE SA 的交换

     C.6.信息交流

1. 介绍

IP 安全 (IPsec) 为 IP 数据报提供机密性、数据完整性、访问控制和数据源身份验证。这些服务是通过维护 IP 数据报的源和接收器之间的共享状态来提供的。该状态定义了提供给数据报的特定服务、将使用哪些密码算法来提供服务以及用作密码算法输入的密钥。

以手动方式建立这种共享状态不能很好地扩展。因此，需要一个协议来动态建立这种状态。本文档描述了这样一种协议——互联网密钥交换 (IKE)。 IKE 的第 1 版在 RFC 2407 [DOI]、2408 [ISAKMP] 和 2409 [IKEV1] 中定义。 IKEv2 替换了所有这些 RFC。 IKEv2 在 [IKEV2] (RFC 4306) 中定义并在 [Clarif] (RFC 4718) 中得到澄清。本文档替换并更新了 RFC 4306 和 RFC 4718。IKEv2 是对 IKE 协议的更改，不向后兼容。相比之下，当前文档不仅提供了对 IKEv2 的澄清，而且对 IKE 协议进行了最少的更改。第 1.7 节列出了 RFC 4306 与本文档之间的显着差异。

IKE 在两方之间执行相互身份验证，并建立一个 IKE 安全关联 (SA)，其中包含共享的秘密信息，可用于有效地建立用于封装安全负载 (ESP) [ESP] 或身份验证头 (AH) [AH] 的 SA，以及SA 使用的一组加密算法来保护它们承载的流量。在本文档中，术语“套件”或“密码套件”是指用于保护 SA 的完整算法集。发起者通过列出支持的算法来提出一个或多个套件，这些算法可以以混合匹配的方式组合成套件。 IKE 还可以协商使用与 ESP 或 AH SA 相关的 IP 压缩 (IPComp) [IP-COMP]。通过我们称为“子 SA”的 IKE SA 设置的 ESP 或 AH 的 SA。

所有 IKE 通信都由消息对组成：请求和响应。这对称为“交换”，有时也称为“请求/响应对”。建立 IKE SA 的第一次消息交换称为 IKE_SA_INIT 和 IKE_AUTH 交换；随后的 IKE 交换称为 CREATE_CHILD_SA 或 INFORMATIONAL 交换。一般情况下，有一个IKE_SA_INIT交换和一个IKE_AUTH交换（共4条消息）来建立IKE SA和第一个Child SA。在特殊情况下，这些交换中的每一个都可能不止一个。在所有情况下，所有 IKE_SA_INIT 交换必须在任何其他交换类型之前完成，然后所有 IKE_AUTH 交换必须完成，然后，任意数量的 CREATE_CHILD_SA 和 INFORMATIONAL 交换可能以任何顺序发生。在某些情况下，IPsec 端点之间只需要一个 Child SA，因此不会有额外的交换。随后的交换可以用于在同一对已验证端点之间建立额外的子 SA 并执行内务处理功能。

IKE 消息流总是由一个请求和一个响应组成。确保可靠性是请求者的责任。如果在超时间隔内没有收到响应，请求者需要重新发送请求（或放弃连接）。

IKE 会话的第一次交换 IKE_SA_INIT，协商 IKE SA 的安全参数，发送随机数，并发送 Diffie-Hellman 值。

第二个交换，IKE_AUTH，传输身份，证明与两个身份对应的秘密的知识，并为第一个（通常是唯一的）AH 或 ESP Child SA 设置 SA（除非设置 AH 或 ESP Child 失败SA，在这种情况下，IKE SA 仍然在没有 Child SA 的情况下建立）。

后续交换的类型是 CREATE_CHILD_SA（创建子 SA）和 INFORMATIONAL（删除 SA、报告错误情况或进行其他内务处理）。每个请求都需要响应。没有有效载荷（除了语法要求的空加密有效载荷）的 INFORMATIONAL 请求通常用作活性检查。在初始交换完成之前，不能使用这些后续交换。

在下面的描述中，我们假设没有发生错误。发生错误时对流程的修改在第 2.21 节。

1.1.使用场景

IKE 用于在许多不同的场景中协商 ESP 或 AH SA，每个场景都有自己的特殊要求。

1.1.1. 隧道模式下的安全网关到安全网关

在这种情况下，IP 连接的两个端点都没有实现 IPsec，但它们之间的网络节点会保护部分方式的流量。 保护对端点是透明的，并依赖于普通路由通过隧道端点发送数据包进行处理。 每个端点将宣布其“后面”的一组地址，并且数据包将以隧道模式发送，其中内部 IP 标头将包含实际端点的 IP 地址。

1.1.2. 端点到端点传输模式

在这种情况下，IP 连接的两个端点都按照 [IPSECARCH] 中主机的要求实现了 IPsec。传输模式通常用于没有内部 IP 标头。将为要受此 SA 保护的数据包协商一对地址。这些端点可以基于参与者的 IPsec 验证身份实现应用层访问控制。此方案实现了端到端安全性，自 [ARCHPRINC]、[透明性] 以来一直是 Internet 的指导原则，并且是一种限制 [ARCHGUIDEPHIL] 指出的网络复杂性固有问题的方法。虽然这种场景可能不能完全适用于IPv4 Internet，但已经在使用IKEv1的内网特定场景中成功部署。在向 IPv6 过渡和采用 IKEv2 期间，应该更广泛地启用它。

在这种情况下，受保护端点中的一个或两个可能位于网络地址转换 (NAT) 节点之后，在这种情况下，隧道数据包必须进行 UDP 封装，以便 UDP 标头中的端口号可用于识别 NAT“后面”的各个端点（参见第 2.23 节）。

1.1.3.隧道模式下端点到安全网关

在这种情况下，受保护的端点（通常是便携式漫游计算机）通过受 IPsec 保护的隧道连接回其公司网络。它可能仅使用此隧道来访问公司网络上的信息，也可能会将其所有流量通过公司网络返回，以便利用公司防火墙提供的保护来抵御基于 Internet 的攻击。在任何一种情况下，受保护端点都需要一个与安全网关关联的 IP 地址，以便返回到它的数据包将进入安全网关并通过隧道返回。这个IP地址可以是静态的，也可以是由安全网关动态分配的。为支持后一种情况，IKEv2 包含一种机制（即配置有效载荷），用于发起方请求安全网关拥有的 IP 地址以在其 SA 期间使用。

在这种情况下，数据包将使用隧道模式。对于来自受保护端点的每个数据包，外部 IP 标头将包含与其当前位置关联的源 IP 地址（即，将流量直接路由到端点的地址），而内部 IP 标头将包含源 IP 地址由安全网关分配（即，将流量路由到安全网关以转发到端点的地址）。外部目标地址将始终是安全网关的地址，而内部目标地址将是数据包的最终目的地。

在这种情况下，受保护端点可能位于 NAT 之后。在这种情况下，安全网关看到的 IP 地址将与受保护端点发送的 IP 地址不同，并且数据包必须经过 UDP 封装才能正确路由。第 2.23 节详细介绍了与 NAT 的交互。

1.1.4.其他场景

其他场景也是可能的，如上述的嵌套组合。一个值得注意的例子结合了第 1.1.1 节和第 1.1.3 节的各个方面。子网可以使用 IPsec 隧道通过远程安全网关进行所有外部访问，其中子网上的地址由 Internet 的其余部分路由到安全网关。一个例子是某人的家庭网络实际上是在互联网上，具有静态 IP 地址，即使连接是由 ISP 提供的，该 ISP 为用户的安全网关分配了一个动态分配的 IP 地址（其中静态 IP 地址和 IPsec 中继由位于其他地方的第三方）。

1.2.最初的交流

使用 IKE 的通信总是从 IKE_SA_INIT 和 IKE_AUTH 交换开始（在 IKEv1 中称为阶段 1）。这些初始交换通常由四个消息组成，但在某些情况下，这个数字可能会增加。所有使用 IKE 的通信都由请求/响应对组成。我们将首先描述基础交换，然后是变化。第一对消息 (IKE_SA_INIT) 协商加密算法，交换随机数，并进行 Diffie-Hellman 交换 [DH]。

第二对消息 (IKE_AUTH) 验证前面的消息，交换身份和证书，并建立第一个 Child SA。这些消息的一部分被加密并使用通过 IKE_SA_INIT 交换建立的密钥进行完整性保护，因此身份对窃听者是隐藏的，并且所有消息中的所有字段都经过身份验证。有关如何生成加密密钥的信息，请参阅第 2.14 节。 （无法完成 IKE_AUTH 交换的中间人攻击者仍然可以看到发起者的身份。）

初始交换之后的所有消息都使用在 IKE_SA_INIT 交换中协商的加密算法和密钥进行加密保护。这些后续消息使用第 3.14 节中描述的加密有效负载的语法，并使用第 2.14 节中描述的派生密钥加密。所有后续消息都包含一个加密的有效负载，即使它们在文本中被称为“空”。对于 CREATE_CHILD_SA、

IKE_AUTH 或 INFORMATIONAL 交换，标头后面的消息被加密，包括标头的消息使用为 IKE SA 协商的加密算法进行完整性保护。

每个 IKE 消息都包含一个消息 ID 作为其固定标头的一部分。此消息 ID 用于匹配请求和响应，以及识别消息的重传。

在以下描述中，消息中包含的有效载荷由以下列出的名称表示。

每个payload内容的详细信息在第3节中描述。可以选择出现的payload将显示在括号中，例如[CERTREQ]; 这表明可以选择包含证书请求有效负载。

最初的交流如下：

HDR 包含安全参数索引 (SPI)、版本号和各种标志。 SAi1 负载说明发起方支持的 IKE SA 的加密算法。 KE 负载发送发起方的 Diffie-Hellman 值。 Ni 是发起者的随机数。

响应者从发起者提供的选择中选择一个加密套件，并在 SAr1 有效载荷中表达该选择，完成与 KEr 有效载荷的 Diffie-Hellman 交换，并在 Nr 有效载荷中发送其随机数。

在协商的这一点上，每一方都可以生成 SKEYSEED，从该 SKEYSEED 导出该 IKE SA 的所有密钥。除了消息头之外，后面的消息整体上都经过加密和完整性保护。用于加密和完整性保护的密钥源自 SKEYSEED，称为 SK_e（加密）和 SK_a（身份验证，又名完整性保护）；有关密钥派生的详细信息，请参见第 2.13 和 2.14 节。为每个方向计算单独的 SK_e 和 SK_a。除了从用于保护 IKE SA 的 Diffie-Hellman 值导出的密钥 SK_e 和 SK_a 之外，还导出了另一个数量 SK_d 并用于导出子 SA 的进一步密钥材料。

符号 SK { ... } 表示使用该方向的 SK_e 和 SK_a 对这些有效载荷进行加密和完整性保护。

发起方使用 IDi 有效载荷声明其身份，证明知道与 IDi 对应的秘密，并且完整性使用 AUTH 有效载荷保护第一条消息的内容（参见第 2.15 节）。它还可能在 CERT 有效载荷中发送其证书，并在 CERTREQ 有效载荷中发送其信任锚列表。如果包含任何 CERT 有效载荷，则提供的第一个证书必须包含用于验证 AUTH 字段的公钥。

可选的有效载荷 IDr 使发起者能够指定它想要与响应者的哪个身份交谈。当运行响应程序的机器在同一 IP 地址上托管多个身份时，这很有用。如果发起者提议的 IDr 不被响应者接受，响应者可能会使用一些其他的 IDr 来完成交换。如果发起者随后不接受响应者使用的 IDr 与请求的 IDr 不同的事实，发起者可以在注意到这一事实后关闭 SA。

流量选择器（TSi 和 TSr）在 2.9 节中讨论。

发起方使用 SAi2 负载开始协商子 SA。最后的字段（从 SAi2 开始）在 CREATE_CHILD_SA 交换的描述中进行了描述。

响应者使用 IDr 负载声明其身份，可选择发送一个或多个证书（再次使用包含用于验证第一个列出的 AUTH 的公钥的证书），验证其身份并使用 AUTH 负载保护第二个消息的完整性，以及使用下面在 CREATE_CHILD_SA 交换中描述的附加字段完成子 SA 的协商。

IKE_AUTH 交换中的双方必须验证所有签名和消息身份验证代码 (MAC) 的计算是否正确。如果任一方使用共享密钥进行认证，则 ID 有效载荷中的名称必须与用于生成 AUTH 有效载荷的密钥相对应。

由于发起方在 IKE_SA_INIT 中发送其 Diffie-Hellman 值，因此它必须猜测响应方将从其支持的组列表中选择的 Diffie-Hellman 组。如果发起者猜错了，响应者将响应一个类型为 INVALID_KE_PAYLOAD 的通知负载，指示所选组。在这种情况下，发起者必须使用更正的 Diffie-Hellman 组重试 IKE_SA_INIT。发起者必须再次提出其完整的可接受的加密套件集，因为拒绝消息未经身份验证，否则主动攻击者可能会诱使端点协商较弱的套件，而不是他们都喜欢的更强的套件。

如果在 IKE_AUTH 交换期间创建 Child 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。

1.3. CREATE_CHILD_SA 交换

CREATE_CHILD_SA 交换用于创建新的子 SA 和重新加密 IKE SA 和子 SA。此交换由单个请求/响应对组成，其部分功能在 IKEv1 中称为第 2 阶段交换。它可以在初始交换完成后由 IKE SA 的任一端发起。

通过创建新的 SA 然后删除旧的 SA 来重新生成 SA。本节介绍重新生成密钥的第一部分，即创建新的 SA；第 2.8 节介绍了重新生成密钥的机制，包括将流量从旧 SA 移动到新 SA 以及删除旧 SA。这两部分必须一起阅读才能理解重新生成密钥的整个过程。

任一端点都可以发起 CREATE_CHILD_SA 交换，因此在本节中，术语发起方是指发起此交换的端点。一个实现可以拒绝 IKE SA 中的所有 CREATE_CHILD_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 交换包含 KEi 有效载荷，则至少一个 SA 提议必须包含 KEi 的 Diffie-Hellman 组。 KEi 的 Diffie-Hellman 组必须是发起者期望响应者接受的组的一个元素（可以提议额外的 Diffie-Hellman 组）。如果响应者选择使用不同的 Diffie-Hellman 组（非 NONE）的提议，响应者必须拒绝该请求并在 INVALID_KE_PAYLOAD 通知负载中指明其首选的 Diffie-Hellman 组。有两个与此通知相关联的数据八位字节：大端顺序中接受的 Diffie-Hellman 组号。在这种拒绝的情况下，CREATE_CHILD_SA 交换失败，发起者可能会使用 Diffie-Hellman 提议和响应者在 INVALID_KE_PAYLOAD 通知负载中给出的组中的 KEi 重试交换。响应者发送 NO_ADDITIONAL_SAS 通知以指示 CREATE_CHILD_SA 请求是不可接受的，因为响应者不愿意接受此 IKE SA 上的任何子 SA。此通知还可用于拒绝 IKE SA 重新生成密钥。一些最小的实现可能只接受初始 IKE 交换上下文中的单个子 SA 设置，并拒绝任何后续添加更多的尝试。

1.3.1. 使用 CREATE_CHILD_SA 交换创建新的子 SA

可以通过发送 CREATE_CHILD_SA 请求来创建子 SA。 用于创建新子 SA 的 CREATE_CHILD_SA 请求是：

发起方在 SA 有效载荷中发送 SA 提议，在 Ni 有效载荷中发送一个随机数，在 KEi 有效载荷中可选地发送一个 Diffie-Hellman 值，以及在 TSi 和 TSr 有效载荷中为提议的子 SA 提议的流量选择器。

  创建新子 SA 的 CREATE_CHILD_SA 响应是：

如果请求中包含 KEi 并且所选的加密套件包含该组，则响应者回复（使用相同的消息 ID 进行响应）在 SA 有效负载中使用已接受的提议，并在 KEr 有效负载中使用 Diffie-Hellman 值。

要在该 SA 上发送的流量的流量选择器在响应中的 TS 有效载荷中指定，这可能是子 SA 的发起者提议的子集。

USE_TRANSPORT_MODE 通知可以包含在请求消息中，该消息还包括请求子 SA 的 SA 有效负载。它请求子 SA 为创建的 SA 使用传输模式而不是隧道模式。如果请求被接受，响应还必须包括 USE_TRANSPORT_MODE 类型的通知。如果响应方拒绝该请求，则以隧道模式建立子 SA。如果发起者不能接受，发起者必须删除 SA。注意：除了使用此选项协商传输模式时，所有子 SA 都将使用隧道模式。

ESP_TFC_PADDING_NOT_SUPPORTED 通知断言发送端点将不接受包含正在协商的子 SA 上的流量机密性 (TFC) 填充的数据包。如果两个端点都不接受 TFC 填充，则此通知将包含在请求和响应中。如果这个通知只包含在一个消息中，TFC 填充仍然可以在另一个方向发送。

NON_FIRST_FRAGMENTS_ALSO 通知用于碎片控制。有关更完整的解释，请参阅 [IPSEARCH]。在任何一方这样做之前，双方需要同意发送非第一片段。只有在提议 SA 的请求和接受它的响应中都包含 NON_FIRST_FRAGMENTS_ALSO 通知时才启用它。如果响应者不想发送或接收非第一个片段，它只会从其响应中省略 NON_FIRST_FRAGMENTS_ALSO 通知，但不会拒绝整个 Child SA 创建。

2.22 节中介绍的 IPCOMP_SUPPORTED 通知也可以包含在交换中。

创建子 SA 的失败尝试不应拆除 IKE SA：没有理由丢失为设置 IKE SA 所做的工作。有关创建子 SA 失败时可能出现的错误消息列表，请参阅第 2.21 节。

1.3.2. 使用 CREATE_CHILD_SA 交换重新加密 IKE SA

重新加密 IKE SA 的 CREATE_CHILD_SA 请求是：

发起方在 SA 有效载荷中发送 SA 提议，在 Ni 有效载荷中发送一个随机数，并在 KEi 有效载荷中发送一个 Diffie-Hellman 值。 必须包括 KEi 有效载荷。 在 SA 有效载荷的 SPI 字段中提供了一个新的发起方 SPI。 一旦对等方收到重新加密 IKE SA 的请求或发送重新加密 IKE SA 的请求，它不应在正在重新加密的 IKE SA 上启动任何新的 CREATE_CHILD_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 的新“原始发起者”。

第 2.18 节还详细介绍了 IKE SA 密钥更新。

1.3.3. 使用 CREATE_CHILD_SA 交换重新生成子 SA

重新加密子 SA 的 CREATE_CHILD_SA 请求是：

发起方在 SA 有效载荷中发送 SA 提议，即 Ni 中的随机数

 有效载荷，可选的 KEi 有效载荷中的 Diffie-Hellman 值，以及 TSi 和 TSr 有效载荷中提议的 Child SA 的提议流量选择器。

第 1.3.1 节中描述的通知也可以在重新加密交换中发送。通常，这些通知与原始交换中使用的通知相同；例如，当重新加密传输模式 SA 时，将使用 USE_TRANSPORT_MODE 通知。

如果交换的目的是替换现有的 ESP 或 AH SA，则 REKEY_SA 通知必须包含在 CREATE_CHILD_SA 交换中。重新加密的 SA 由 Notify 有效载荷中的 SPI 字段标识；这是交换发起方在入站 ESP 或 AH 数据包中期望的 SPI。没有与此 Notify 消息类型相关联的数据。 REKEY_SA 通知的协议 ID 字段设置为匹配我们正在重新生成密钥的 SA 的协议，例如，ESP 为 3，AH 为 2。

为子 SA 重新加密的 CREATE_CHILD_SA 响应是：

如果请求中包含 KEi 并且所选的加密套件包含该组，则响应者回复（使用相同的消息 ID 进行响应）在 SA 有效负载中使用已接受的提议，并在 KEr 有效负载中使用 Diffie-Hellman 值。

要在该 SA 上发送的流量的流量选择器在响应中的 TS 有效载荷中指定，这可能是子 SA 的发起者提议的子集。

1.4.信息交流

在 IKE SA 操作期间的各个点，对等方可能希望相互传达关于某些事件的错误或通知的控制消息。为了实现这一点，IKE 定义了一个信息交换。信息交换必须仅在初始交换之后发生，并且使用协商密钥进行加密保护。请注意，一些信息性消息，而不是交换，可以在 IKE SA 的上下文之外发送。 2.21 节还详细介绍了错误消息。

属于 IKE SA 的控制消息必须在该 IKE SA 下发送。与子 SA 相关的控制消息必须在生成它们的 IKE SA（或其后继，如果 IKE SA 被重新加密）的保护下发送。

信息交换中的消息包含零个或多个通知、删除和配置负载。信息交换请求的接收者必须发送一些响应；否则，发送方将假定消息在网络中丢失并重新传输。该响应可能是一个空消息。 INFORMATIONAL 交换中的请求消息也可以不包含有效载荷。这是端点可以要求另一个端点验证它是否处于活动状态的预期方式。

INFORMATIONAL 交换定义为：

INFORMATIONAL 交换的处理由其组件有效载荷决定。

1.4.1.使用信息交换删除 SA

 

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。

1.5. IKE SA 之外的信息性消息

在某些情况下，节点收到无法处理的数据包，但它可能希望将这种情况通知发送方。

   o 如果 ESP 或 AH 数据包到达时带有无法识别的 SPI。这可能是由于接收节点最近崩溃并丢失了状态，或者因为其他一些系统故障或攻击。

   o 如果加密的 IKE 请求数据包到达端口 500 或 4500 且带有无法识别的 IKE SPI。这可能是由于接收节点最近崩溃并丢失了状态，或者因为其他一些系统故障或攻击。

 o 如果 IKE 请求数据包到达时的主版本号高于实现支持的版本号。

在第一种情况下，如果接收节点有一个活动的 IKE SA 到数据包来自的 IP 地址，它可以在信息交换中通过该 IKE SA 发送一个关于任性数据包的 INVALID_SPI 通知。通知数据包含无效数据包的 SPI。

此通知的接收者无法判断 SPI 是用于 AH 还是 ESP，但这并不重要，因为两者的 SPI 应该是不同的。如果不存在合适的 IKE SA，节点可以向源 IP 地址发送没有加密保护的信息性消息，如果数据包是 UDP（UDP 封装的 ESP 或 AH），则使用源 UDP 端口作为目标端口。在这种情况下，它只能被接收者用作暗示可能有问题的提示（因为它很容易被伪造）。该消息不是信息交换的一部分，接收节点不得响应它，因为这样做可能会导致消息循环。该消息的构造如下：没有对此类通知的接收者有意义的 IKE SPI 值；使用零值或随机值都是可以接受的，这是第 3.1 节中禁止零 IKE 启动器 SPI 规则的例外。 Initiator 标志设置为 1，Response 标志设置为 0，版本标志以正常方式设置；这些标志在第 3.1 节中描述。

在第二种和第三种情况下，消息总是在没有加密保护的情况下发送（在 IKE SA 之外），并且包括 INVALID_IKE_SPI 或 INVALID_MAJOR_VERSION 通知（没有通知数据）。消息是响应消息，因此它被发送到 IP 地址和端口，从那里它带有相同的 IKE SPI，并且消息 ID 和交换类型从请求中复制。 响应标志设置为 1，版本标志以正常方式设置。

1.6. 需求术语

本文档中原始术语的定义（例如安全关联或 SA）可以在 [IPSEARCH] 中找到。 应该注意的是，IKEv2 的部分依赖于 [IPSEARCH] 中的一些处理规则，如本文档的各个部分所述。

1.7. RFC 4306 与本文档之间的显着差异

本文档包含对 IKEv2 的澄清和放大

[IKEV2]。许多澄清都基于 [Clarif]。该文件中列出的更改在 IPsec 工作组中进行了讨论，并且在工作组解散后，在 IPsec 邮件列表中进行了讨论。该文档包含对 IKEv2 中不清楚的领域的详细说明，因此对 IKEv2 的实施者很有用。

本文档中描述的协议保留了与 RFC 4306 中使用的相同的主要版本号 (2) 和次要版本号 (0)。也就是说，版本号*未*从 RFC 4306 更改。

此处列出的少量技术更改预计不会影响在本文档发布时已部署的 RFC 4306 实施。

本文档使数字和参考文献比 [IKEV2] 中的更一致。

IKEv2 开发人员注意到 RFC 4306 中的 SHOULD 级别要求通常不明确，因为他们没有说明何时可以不遵守这些要求。他们还指出，存在与互操作性无关的 MUST 级别要求。本文档对其中一些要求进行了更多解释。单词 SHOULD 和 MUST 的所有非大写用法现在表示它们的正常英语含义，而不是 [MUSTSHOULD] 的互操作性含义。

IKEv2（和 IKEv1）开发人员注意到，RFC 4306 第 3.10.1 节的代码表中有大量材料。这导致实施者在文档主体中没有所有需要的信息。这些表格中的大部分材料已移入文档主体的相关部分。

本文档删除了对嵌套 AH 和 ESP 的讨论。这是由完成 RFC 4306 和 RFC 4301 之间的滞后导致的 RFC 4306 中的错误。基本上，IKEv2 基于 RFC 4301，它不包括作为 RFC 2401 一部分的“SA 包”。而单个数据包可以通过IPsec 处理多次，这些传递中的每一个都使用单独的 SA，并且传递由转发表进行协调。在 IKEv2 中，这些 SA 中的每一个都必须使用单独的 CREATE_CHILD_SA 交换来创建。

本文档删除了对 INTERNAL_ADDRESS_EXPIRY 配置属性的讨论，