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

rfc5996 (ietf.org)

接上篇blog (59条消息) [RFC5996 翻译一] IKEv2 互联网密钥交换协议版本2_羊羊洒洒_Blog的博客-CSDN博客

3.15.配置负载 Configuration Payload

配置负载，在本文档中表示为 CP，用于在 IKE 对等体之间交换配置信息。交换是为了让 IRAC 从 IRAS 请求一个内部 IP 地址，并交换其他信息，如果 IRAC 直接连接到 LAN，则可以使用动态主机配置协议 (DHCP) 获取此类信息。

配置负载定义如下：

配置有效负载的有效负载类型为四十七（47）。

o CFG 类型（1 个八位字节） - 由配置属性表示的交换类型。下表中的值仅是截至 RFC 4306 发布日期的最新值。其他值可能自那时起添加，或者将在本文档发布后添加。读者应参考 [IKEV2IANA] 了解最新值。

CFG Type Value

--------------------------

CFG_REQUEST 1

CFG_REPLY 2

CFG_SET 3

CFG_ACK 4

o 保留（3 个八位字节） - 必须以零形式发送;必须在收到时忽略。

o 配置属性（可变长度） - 这些是特定于配置有效负载的类型长度值（TLV）结构，定义如下。此负载中可能有零个或多个配置属性。

3.15.1. 配置属性

o 保留（1 位） - 此位必须设置为零，并且在收到时必须忽略。

o 属性类型（15 位） - 每个配置属性类型的唯一标识符。

o 长度（2 个八位字节，无符号整数）- 以值的八位字节为单位的长度。

o 值（0 个或多个八位字节） - 此配置属性的可变长度值。下面列出了属性类型。

下表中的值仅是截至 RFC 4306 发布日期的最新值（本文档删除的INTERNAL_ADDRESS_EXPIRY和INTERNAL_IP6_NBNS除外）。其他值可能自那时起添加，或者将在本文档发布后添加。读者应参考 [IKEV2IANA] 了解最新值。

Attribute Type Value Multi-Valued Length

------------------------------------------------------------

INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets

INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets

INTERNAL_IP4_DNS 3 YES 0 or 4 octets

INTERNAL_IP4_NBNS 4 YES 0 or 4 octets

INTERNAL_IP4_DHCP 6 YES 0 or 4 octets

APPLICATION_VERSION 7 NO 0 or more

INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets

INTERNAL_IP6_DNS 10 YES 0 or 16 octets

INTERNAL_IP6_DHCP 12 YES 0 or 16 octets

INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets

SUPPORTED_ATTRIBUTES 14 NO Multiple of 2

INTERNAL_IP6_SUBNET 15 YES 17 octets

* 仅当请求了多个值时，这些属性才可以在返回时具有多个值。

o INTERNAL_IP4_ADDRESS，INTERNAL_IP6_ADDRESS - 内部网络上的地址，有时称为红色节点地址或专用地址，它可能是Internet上的专用地址。在请求消息中，指定的地址是请求的地址（如果没有请求特定地址，则为零长度地址）。如果请求特定地址，则可能表示以前存在与此地址的连接，并且请求者希望重用该地址。使用 IPv6，请求者可以提供它想要使用的低阶地址八位字节。可以通过请求多个内部地址属性来请求多个内部地址。响应者最多只能发送请求的地址数。 INTERNAL_IP6_ADDRESS由两个字段组成：第一个是 16 个八位字节的 IPv6 地址，第二个是 [ADDRIPV6] 中定义的一个八位字节前缀长度。只要请求该地址的此 IKE SA（或其重新键入的后续地址）有效，请求的地址就是有效的。第 3.15.3 节对此有更详细的描述。

o INTERNAL_IP4_NETMASK - 内部网络的网络掩码。请求和响应消息中只允许使用一个网络掩码（例如，255.255.255.0），并且必须仅与INTERNAL_IP4_ADDRESS属性一起使用。 CFG_REPLY中的INTERNAL_IP4_NETMASK与包含相同信息INTERNAL_IP4_SUBNET大致相同（"通过我向这些地址发送流量"），但也意味着链接边界。例如，客户端可以使用自己的地址和网络掩码来计算链路的广播地址。空INTERNAL_IP4_NETMASK属性可以包含在请求此信息CFG_REQUEST中（尽管网关可以发送信息，即使未请求）。 CFG_REQUEST中此属性的非空值没有意义，因此不得包含。

o INTERNAL_IP4_DNS，INTERNAL_IP6_DNS - 指定网络中 DNS 服务器的地址。可以请求多个 DNS 服务器。响应程序可以使用零个或多个 DNS 服务器属性进行响应。

o INTERNAL_IP4_NBNS - 指定网络中 NetBios 名称服务器（WINS）的地址。可以请求多个 NBNS 服务器。响应程序可以使用零个或多个 NBNS 服务器属性进行响应。

o INTERNAL_IP4_DHCP，INTERNAL_IP6_DHCP - 指示主机将任何内部 DHCP 请求发送到属性中包含的地址。可以请求多个 DHCP 服务器。响应程序可以使用零个或多个 DHCP 服务器属性进行响应。

o APPLICATION_VERSION - IPsec 主机的版本或应用程序信息。这是一个不以空值终止的可打印 ASCII 字符字符串。

o INTERNAL_IP4_SUBNET - 此边缘设备保护的受保护子网。此属性由两个字段组成：第一个是 IP 地址，第二个是网络掩码。可以请求多个子网络。响应程序可以使用零个或多个子网属性进行响应。第 3.15.2 节对此进行了更详细的讨论。

o SUPPORTED_ATTRIBUTES - 在请求中使用时，此属性的长度必须为零，并指定对响应程序的查询，以使用它支持的所有属性进行回复。响应包含一个属性，该属性包含一组属性标识符，每个属性标识符以 2 个八位字节表示。长度除以 2（八位字节）将表示响应中包含的受支持属性的数量。

o INTERNAL_IP6_SUBNET - 此边缘设备保护的受保护子网。此属性由两个字段组成：第一个是 16 个八位字节的 IPv6 地址，第二个是 [ADDRIPV6] 中定义的一个八位字节前缀长度。可以请求多个子网络。响应者可以使用零个或多个子网属性进行响应。第 3.15.2 节对此进行了更详细的讨论。

请注意，本文档中没有关于实现如何实际计算出要在响应中发送哪些信息的建议。也就是说，我们不建议使用 IRAS 的任何特定方法来确定应将哪个 DNS 服务器返回给发出请求的 IRAC。

CFG_REQUEST和CFG_REPLY对允许 IKE 终结点从其对等方请求信息。如果CFG_REQUEST配置负载中的某个属性的长度不是零，则会将其视为该属性的建议。 CFG_REPLY配置有效负载可能会返回该值或新值。它还可能添加新属性，但不包括一些请求的属性。在请求和响应中必须忽略无法识别或不受支持的属性。

CFG_SET和CFG_ACK对允许 IKE 端点将配置数据推送到其对等方。在这种情况下，CFG_SET配置有效负载包含发起者希望其对等方更改的属性。如果响应者接受任何配置数据，则它必须返回配置有效负载，并且它必须包含响应程序接受的具有零长度数据的属性。它不接受的那些属性不得位于CFG_ACK配置有效负载中。如果未接受任何属性，则响应程序必须返回空CFG_ACK有效负载或没有CFG_ACK有效负载的响应消息。目前没有定义CFG_SET/CFG_ACK交换的用途，尽管它们可能与基于供应商 ID 的扩展结合使用。此规范的实现可能会忽略CFG_SET有效负载。

3.15.2. INTERNAL_IP4_SUBNET和INTERNAL_IP6_SUBNET的含义

INTERNAL_IP4/6_SUBNET属性可以指示可以通过公布属性的网关访问的其他子网，即需要一个或多个单独 SA 的子网。 INTERNAL_IP4/6_SUBNET属性还可以表示网关关于应通过网关发送哪些流量的策略; 客户端可以选择是将其他流量（由 TSr 覆盖，但不在INTERNAL_IP4/6_SUBNET中）通过网关发送还是直接发送到目标。因此，发往INTERNAL_IP4/6_SUBNET属性中列出的地址的流量应通过宣布属性的网关发送。如果没有流量选择器覆盖相关地址的现有子 SA，则需要创建新的 SA。

例如，如果有两个子网，则 198.51.100.0/26 和 192.0.2.0/24，并且客户端的请求包含以下内容：

CP(CFG_REQUEST) =

INTERNAL_IP4_ADDRESS()

TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)

TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

则有效响应可以是以下内容（其中 TSr 和 INTERNAL_IP4_SUBNET包含相同的信息）：

CP(CFG_REPLY) =

INTERNAL_IP4_ADDRESS(198.51.100.234)

INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),

(0, 0-65535, 192.0.2.0-192.0.2.255))

在这些情况下，INTERNAL_IP4_SUBNET实际上并不携带任何有用的信息。

另一种不同的可能反应是这样的：

CP(CFG_REPLY) =

INTERNAL_IP4_ADDRESS(198.51.100.234)

INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

该响应意味着客户端可以通过网关发送其所有流量，但网关不介意客户端是否将INTERNAL_IP4_SUBNET未包含的流量直接发送到目标（无需通过网关）。

如果网关具有要求两个子网的流量在单独的 SA 中承载的策略，则会出现不同的情况。然后，这样的响应将向客户端指示，如果它想要访问第二个子网，则需要创建一个单独的 SA：

CP(CFG_REPLY) =

INTERNAL_IP4_ADDRESS(198.51.100.234)

INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

如果客户端的 TSr 仅包含部分地址空间，则INTERNAL_IP4_SUBNET也很有用。例如，如果客户端请求以下内容：

CP(CFG_REQUEST) =

INTERNAL_IP4_ADDRESS()

TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)

TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

则网关的回应可能是：

CP(CFG_REPLY) =

INTERNAL_IP4_ADDRESS(198.51.100.234)

INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)

INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)

TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

由于CFG_REQUESTs中INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET的含义不明确，因此无法在CFG_REQUESTs中可靠地使用它们。

3.15.3. IPv6 的配置有效负载

IPv6 的配置有效负载基于相应的 IPv4 有效负载，并不完全遵循"正常的 IPv6 做事方式"。特别是，不使用 IPv6 无状态自动配置或路由器通告消息，也不使用邻居发现。请注意，还有一个附加文档讨论了 IKEv2 中的 IPv6 配置，[IPV6CONFIG]。目前，它是一个实验性文件，但希望随着更多的实施经验，它将获得与本文档相同的标准待遇。

可以使用INTERNAL_IP6_ADDRESS配置有效负载为客户端分配 IPv6 地址。最小交换可能如下所示：

CP(CFG_REQUEST) =

INTERNAL_IP6_ADDRESS()

INTERNAL_IP6_DNS()

TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =

INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)

INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)

TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)

TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

客户端可以在CFG_REQUEST发送非空INTERNAL_IP6_ADDRESS属性，以请求特定的地址或接口标识符。网关首先检查指定的地址是否可接受，如果可接受，则返回该地址。如果地址不可接受，网关将尝试使用带有其他前缀的接口标识符;即使失败，网关也会选择另一个接口标识符。

INTERNAL_IP6_ADDRESS属性还包含前缀长度字段。在CFG_REPLY中使用时，这对应于 IPv4 情况下的INTERNAL_IP4_NETMASK属性。

尽管这种配置 IPv6 地址的方法相当简单，但它有一些限制。使用 IKEv2 配置的 IPsec 隧道在 IPv6 寻址体系结构意义上不是功能齐全的"接口"[ADDRIPV6]。特别是，它们不一定具有链路本地地址，这可能会使使用假定它们的协议（如[MLDV2]）复杂化。

3.15.4. 地址分配失败

如果在处理配置负载期间，响应程序在尝试将 IP 地址分配给启动器时遇到错误，则会使用INTERNAL_ADDRESS_FAILURE通知进行响应。即使由于此故障而无法创建初始子 SA，仍会创建 IKE SA。如果在IKE_AUTH交换中生成此错误，则不会创建子 SA。但是，还有一些更复杂的错误情况。

如果响应程序根本不支持配置负载，则只需忽略所有配置负载即可。这种类型的实现从不发送INTERNAL_ADDRESS_FAILURE通知。如果启动器要求分配 IP 地址，它将把不CFG_REPLY的响应视为错误。

启动器可以请求响应程序不支持的特定类型的地址（IPv4 或 IPv6），即使响应程序支持配置有效负载也是如此。在这种情况下，响应程序只是忽略它不支持的地址类型，并像往常一样处理请求的其余部分。

如果发起方请求响应程序支持的类型的多个地址，并且某些（但不是全部）请求失败，则响应方仅使用成功的地址进行回复。仅当无法分配地址时，响应程序才会发送INTERNAL_ADDRESS_FAILURE。

如果启动器未收到其策略所需的 IP 地址，它可以保持 IKE SA 正常运行，并在适当的超时后将配置有效负载作为单独的信息交换重试，或者它可能会通过在单独的信息交换中发送删除有效负载来拆除 IKE SA，然后在超时一段时间后从头开始重试 IKE SA。

这样的超时不应该太短（特别是如果 IKE SA 从头开始），因为这些错误情况可能无法快速修复;超时可能为几分钟。例如，只有当其他客户端断开连接时，或者当响应程序重新配置了更大的地址池时，响应程序上的地址短缺问题才可能得到解决。

3.16. 可扩展认证协议（EAP）有效负载

可扩展身份验证协议有效负载（在本文档中称为 EAP）允许使用 RFC 3748 [EAP] 中定义的协议和该协议的后续扩展对 IKE SA 进行身份验证。使用 EAP 时，需要选择适当的 EAP 方法。已经定义了其中许多方法，指定了协议与各种身份验证机制的用法。 EAP 方法类型列在 [EAP-IANA] 中。为清楚起见，此处包含 EAP 格式的简短摘要。

EAP 有效负载的有效负载类型为四十八（48）。

o 代码（1 个八位字节）指示此消息是请求（1）、响应（2）、成功（3）还是失败（4）。

o 标识符（1 个八位字节）在 PPP 中用于区分重播消息和重复消息。由于在 IKE 中，EAP 通过可靠的协议运行，因此它在这里没有任何作用。在响应消息中，必须将此八位字节设置为与相应请求中的标识符匹配。

o 长度（2 个八位字节，无符号整数）是 EAP 消息的长度，必须比封装有效负载的有效负载长度小 4 个。

o 仅当代码字段为"请求（1）"或"响应"（2）时，才存在类型（1个八位字节）。对于其他代码，EAP 消息长度必须为四个八位字节，并且"类型"和"Type_Data字段不得存在。

在请求（1）消息中，Type 指示所请求的数据。在响应（2）消息中，键入必须为 Nak 或与所请求数据的类型匹配。请注意，由于 IKE 在IKE_AUTH交换中的第一条消息中传递了发起方标识的指示，因此响应程序不应发送 EAP 标识请求（类型 1）。但是，如果发起方收到此类请求，则发起方可以响应这些请求。

o Type_Data（可变长度）因请求类型和相关响应而异。有关 EAP 方法的文档，请参阅 [EAP]。

请注意，由于 IKE 在IKE_AUTH交换中的第一条消息中传递了发起方标识的指示，因此响应程序不应发送 EAP 标识请求。但是，如果发起人收到这些请求，它可以对它们作出回应。

4. 一致性要求

为了确保IKEv2的所有实现都可以互操作，除了其他地方列出的要求外，还有"必须支持"的要求。当然，IKEv2是一种安全协议，其主要功能之一是只允许授权方成功完成SA的建立。

因此，特定实现可以配置有关算法和可信权限的许多限制中的任何一个，这些限制将阻止通用互操作性。

IKEv2 旨在允许可与所有兼容实现互操作的最小实现。以下是在最小实现中可以省略的功能：

o 能够通过 NAT 协商 SA，并通过 UDP 通过隧道传输生成的 ESP SA。

o 能够在隧道的远程端请求（并响应请求）临时 IP 地址。

o 能够支持基于 EAP 的身份验证。

o 能够支持大于 1 的窗口大小。

o 能够在单个 IKE SA 中建立多个 ESP 或 AH SA。

o 能够重新生成 SA 密钥。

为了确保互操作性，所有实现都必须能够解析所有有效负载类型（如果只是跳过它们），并忽略它不支持的有效负载类型，除非在有效负载标头中设置了关键位。如果在不受支持的有效负载标头中设置了临界位，则所有实现都必须拒绝包含这些有效负载的消息。

每个实现都必须能够执行四条消息IKE_SA_INIT和IKE_AUTH交换，从而建立两个SA（一个用于IKE，一个用于ESP或AH）。如果适合其平台，实现可以是仅启动或仅响应。

每个实现都必须能够响应 INFORMATIONAL 交换，但最小实现可以使用空响应来响应 INFORMATIONAL 交换中的任何请求（请注意，在 IKE SA 的上下文中，"空"消息由 IKE 标头后跟加密有效负载组成，其中不包含任何有效负载）。

最小实现可能仅支持CREATE_CHILD_SA交换，以便识别请求并使用NO_ADDITIONAL_SAS类型的 Notify 有效负载拒绝请求。最小的实现不需要能够启动CREATE_CHILD_SA或信息交换。当 SA 过期时（基于本地配置的生存期值或已传递的八位字节），并且实现可以尝试使用CREATE_CHILD_SA交换续订它，也可以删除（关闭）旧 SA 并创建新 SA。如果响应程序拒绝CREATE_CHILD_SA请求并发出NO_ADDITIONAL_SAS通知，则实现必须能够改为删除旧 SA 并创建新 SA。

不需要实现来支持请求临时 IP 地址或响应此类请求。如果实现确实支持发出此类请求，并且其策略要求使用临时 IP 地址，则它必须在IKE_AUTH交换中的第一条消息中包含 CP 有效负载，该有效负载至少包含类型为 INTERNAL_IP4_ADDRESS 或 INTERNAL_IP6_ADDRESS 的字段。所有其他字段都是可选的。如果实现支持响应此类请求，则必须解析IKE_AUTH交换中第一条消息中类型为 CFG_REQUEST 的 CP 有效负载，并识别类型为 INTERNAL_IP4_ADDRESS 或 INTERNAL_IP6_ADDRESS 的字段。如果它支持租用适当类型的地址，则必须返回类型 CFG_REPLY 包含所请求类型的地址的 CP 有效负载。响应程序可以包含任何其他相关属性。

对于要调用符合此规范的实现，必须能够将其配置为接受以下内容：

o 使用 X.509 （PKIX）证书的公钥基础结构

包含大小为 1024 位或 2048 位的 RSA 密钥并对其进行签名，其中传递的 ID 是 ID_KEY_ID、ID_FQDN、ID_RFC822_ADDR 或 ID_DER_ASN1_DN的任何一个。

o 共享密钥身份验证，其中传递的 ID 是ID_KEY_ID、ID_FQDN或ID_RFC822_ADDR中的任何一个。

o 身份验证，其中响应程序使用 PKIX 证书进行身份验证，启动器使用共享密钥身份验证进行身份验证。

5. 安全注意事项

虽然此协议旨在最大限度地减少向未经身份验证的对等方泄露配置信息，但某些此类披露是不可避免的。一个对等体或另一个对等体必须首先识别自己，并首先证明其身份。为避免探测，交易的发起方需要首先标识自身，并且通常需要先对自身进行身份验证。但是，发起方可以了解响应方是否支持 IKE 以及它支持哪些加密协议。响应者（或模拟响应者的人）不仅可以探测启动器的身份，而且使用 CERTREQ 有效负载可以确定启动器愿意使用哪些证书。

使用 EAP 身份验证会在一定程度上改变探测可能性。使用 EAP 身份验证时，响应程序会在启动器之前证明其身份，因此知道有效启动器名称的启动器可以向响应方查询其名称和证书。

使用CREATE_CHILD_SA重复重新生成密钥，而无需额外的Diffie-Hellman交换，使所有SA都容易受到单个密钥的加密分析。实现者应注意这一事实，并对幂之间的CREATE_CHILD_SA交换设置限制。本文件没有规定这种限制。使用此处定义的任何群从 Diffie-Hellman 交换派生的键的强度取决于组的固有强度、所用指数的大小以及所使用的随机数生成器提供的熵。由于这些输入，很难确定任何已定义组的键的强度。Diffie-Hellman 群 2，当与强随机数生成器和不小于 200 位的指数一起使用时，通常与 3DES 一起使用。组 5 提供比组 2 更高的安全性。第一组仅用于历史目的，除了与DES一起使用外，不能提供足够的力量，DES也仅用于历史用途。实现在建立策略和协商安全参数时应注意这些估计值。

请注意，这些限制仅限于Diffie-Hellman组本身。 IKE中没有任何内容禁止使用更强的组，也没有任何内容会稀释从较强组获得的强度（受包括PRF在内的其他算法的强度的限制）。事实上，IKE的可扩展框架鼓励定义更多的群体;使用椭圆曲线组可以使用更小的数字大大增加强度。

假设所有Diffie-Hellman指数在使用后都会从内存中删除。

IKE_SA_INIT和IKE_AUTH交换发生在启动器经过身份验证之前。因此，当部署在任何不安全的网络上时，此协议的实现需要完全可靠。实现漏洞，特别是 DoS 攻击，可能被未经身份验证的对等方利用。此问题尤其令人担忧，因为基于 EAP 的身份验证中的消息数量不受限制。

所有键的强度受协商的 PRF 输出大小的限制。因此，输出小于 128 位的 PRF（例如，3DES-CBC）不得与此协议一起使用。该协议的安全性主要取决于随机选择的参数的随机性。这些应由强随机或正确播种的伪随机源生成（参见[随机性]）。实现者应注意确保以不破坏密钥安全性的方式设计密钥和随机数的随机数。

有关此协议中许多加密设计选择的基本原理的信息，请参阅 [SIGMA] 和 [SKEME]。尽管协商的子 SA 的安全性不依赖于在 IKE SA 中协商的加密和完整性保护的强度，但实现不得协商 NONE 作为 IKE 完整性保护算法或ENCR_NULL作为 IKE 加密算法。

使用预共享密钥时，一个关键的考虑因素是如何确保这些机密的随机性。最强的做法是确保任何预先共享的密钥包含与正在协商的最强密钥一样多的随机性。从密码、名称或其他低熵源派生共享机密是不安全的。这些来源受到字典和社会工程学攻击等。

NAT_DETECTION_*_IP通知包含地址和端口的哈希，试图隐藏 NAT 后面的内部 IP 地址。由于 IPv4 地址空间只有 32 位，并且通常非常稀疏，因此攻击者可以通过尝试所有可能的 IP 地址并尝试查找匹配的哈希值来找出 NAT 框后面使用的内部地址。端口号通常固定为 500，并且可以从数据包中提取 SPI。这会将哈希计算的数量减少到 2^32。通过对私有地址空间的使用进行有根据的猜测，哈希计算的数量要少得多。因此，设计人员不应假设使用 IKE 不会泄露内部地址信息。

当使用不生成共享密钥来保护后续 AUTH 有效负载的 EAP 身份验证方法时，某些中间人服务器模拟攻击是可能的 [EAPMITM]。当 EAP 也用于未受安全隧道保护的协议中时，会发生这些漏洞。由于 EAP 是一种通用身份验证协议，通常用于提供单点登录功能，因此依赖于不生成共享密钥的 EAP 身份验证方法（也称为非密钥生成 EAP 方法）的已部署 IPsec 解决方案可能会受到威胁由于部署了一个完全不相关的应用程序，该应用程序也碰巧使用相同的非密钥生成EAP方法，但以不受保护的方式。请注意，此漏洞不仅限于 EAP，还可能发生在重用身份验证基础结构的其他方案中。例如，如果 IKEv2 使用的 EAP 机制使用令牌身份验证器，则中间人攻击者可以模拟 Web 服务器，拦截令牌身份验证交换，并使用它来启动 IKEv2 连接。因此，应尽可能避免使用非密钥生成 EAP 方法。在使用它们的情况下，这些 EAP 方法的所有用法都应使用受保护的隧道，在该隧道中，发起方在启动 EAP 身份验证之前验证响应方的证书，这一点非常重要。实施者应在其实现文档中描述使用非密钥生成 EAP 方法的漏洞，以便部署 IPsec 解决方案的管理员了解这些危险。

使用 EAP 的实现还必须在 EAP 身份验证开始之前对客户端使用基于公钥的服务器身份验证，即使 EAP 方法提供相互身份验证也是如此。这样可以避免其他 IKEv2 协议变体，并保护 EAP 数据免受活动攻击者的攻击。

如果 IKEv2 的消息足够长，需要 IP 级碎片，则攻击者可能会通过耗尽重组缓冲区来阻止交换完成。通过使用哈希和 URL 编码而不是发送证书，可以最大程度地减少这种情况的发生（请参见第 3.6 节）。 [DOSUDPPROT] 中讨论了其他缓解措施。

准入控制对于协议的安全性至关重要。例如，用于标识 IKE 对等体的信任锚点可能不同于用于其他形式的信任（如用于标识公共 Web 服务器的信任锚）。此外，尽管 IKE 在为可信对等方的身份、凭据及其之间的相关性定义安全策略方面提供了很大的回旋余地，但显式定义此类安全策略对于安全实现至关重要。

5.1. 流量选择器授权

IKEv2 在确定允许对等方创建哪种子 SA 时，依赖于对等授权数据库（PAD）中的信息。此过程在 [IPSECARCH] 的第 4.4.3 节中进行了介绍。当对等方请求使用某些流量选择器创建子 SA 时，PAD 必须包含"子 SA 授权数据"，该数据链接由 IKEv2 验证的身份和流量选择器允许的地址。

例如，可以将 PAD 配置为允许经过身份验证的标识"sgw23.example.com"为 192.0.2.0/24 创建子 SA，这意味着此安全网关是这些地址的有效"代表"。主机到主机 IPsec 需要类似的条目，例如，将"fooserver4.example.com"与 198.51.100.66/32 链接起来，这意味着此标识是相关地址的有效"所有者"或"代表"。

如 [IPSECARCH] 中所述，"有必要对子 SA 的创建施加这些限制，以防止经过身份验证的对等方欺骗与其他合法对等体关联的 ID"。在上面给出的示例中，PAD 的正确配置可防止 sgw23 创建地址为 198.51.100.66 的子 SA，并阻止 fooserver4 创建地址为 192.0.2.0/24 的子 SA。

请务必注意，仅使用某个特定地址发送 IKEv2 数据包并不意味着有权在流量选择器中使用该地址创建子 SA。例如，即使 sgw23 能够将其 IP 地址欺骗为 198.51.100.66，它也无法创建与 fooserver4 的流量匹配的子 SA。

IKEv2 规范未指定使用配置有效负载进行 IP 地址分配与 PAD 的确切交互方式。我们的解释是，当安全网关使用配置有效负载分配地址时，它还会创建一个临时 PAD 条目，链接经过身份验证的对等标识和新分配的内部地址。

人们已经认识到，在某些环境中正确配置PAD可能很困难。例如，如果在一对使用 DHCP 动态分配地址的主机之间使用 IPsec，则很难确保 PAD 为每个 IP 地址指定正确的"所有者"。这将需要一种机制来安全地传达来自 DHCP 服务器的地址分配，并将它们链接到使用 IKEv2 进行身份验证的身份。

由于此限制，已知某些供应商会将其 PAD 配置为允许经过身份验证的对等方创建具有流量选择器的子 SA，该子 SA 包含用于 IKEv2 数据包的相同地址。在可能进行 IP 欺骗的环境中（即几乎无处不在），这基本上允许任何对等方使用任何流量选择器创建子 SA。

在大多数情况下，这不是一个适当或安全的配置。有关此问题以及主机到主机 IPsec 的一般限制的广泛讨论，请参阅 [H2HIPSEC]。

6. IANA 注意事项

[IKEV2] 定义了许多字段类型和值。 IANA 已经在 [IKEV2IANA] 中注册了这些类型和值，因此它们不会在此处再次列出。

已从 IKEv2 配置有效负载属性类型表中删除两个项目：INTERNAL_IP6_NBNS和INTERNAL_ADDRESS_EXPIRY。

此处定义了 IKEv2 参数"通知消息 - 错误类型"注册表中未定义的两个新添加项：

43 TEMPORARY_FAILURE

44 CHILD_SA_NOT_FOUND

IANA 已将现有的 IKEv2 Payload Types 表从以下位置更改为：

   46        Encrypted                        E          [IKEV2]

to

   46        Encrypted and Authenticated      SK    [This document]

IANA 已更新所有对 RFC 4306 的引用，以指向本文档。