导语
ucas 2023秋 网络认证技术
作业2：任选一个标准（口令鉴别协议），书写阅读报告。报告内容要求描述基本原理，解决了什么问题，可能存在什么问题。
概述
我选择阅读RFC 7296，该标准是互联网密钥交换 （IKE） 协议的第二个版本。本标准使RFC 5996废弃， IKEv2是当前的互联网标准。
解决了什么问题
IKEv2（Internet Key Exchange version 2）是一种用于建立虚拟专用网络（VPN）连接的协议，它解决了许多与安全通信和远程访问有关的问题。包括：
- 安全性：IKEv2提供了强大的安全性，通过使用加密算法来保护数据的机密性和完整性。它还允许身份验证，以确保通信双方是合法的，并可以抵御各种网络攻击，如中间人攻击和数据篡改。
- 移动性：IKEv2支持移动设备的连接，允许用户从一个网络切换到另一个网络时保持连接的连续性。这对于移动工作人员或在不同网络环境中工作的人员非常有用。
- 多平台兼容性：IKEv2是一种通用的VPN协议，支持多种操作系统和设备，包括Windows、macOS、iOS、Android和Linux。这使得它成为广泛使用的VPN协议，能够在不同平台之间建立安全的连接。
- 快速重新连接：IKEv2具有快速重新连接的能力，可以在断开连接后快速重新建立连接，而不需要用户手动干预。这对于移动设备或不稳定的网络连接非常有用。
- 支持IPv6：随着IPv6的推广，IKEv2也提供了对IPv6的良好支持，使其适用于新一代互联网协议。
- NAT穿透：IKEv2能够穿越网络地址转换（NAT）设备，这使得它在各种网络环境中都能够正常工作，包括家庭网络和企业网络。
在基本原理-1.1节也简述了IKEv2在特定场景下解决了什么问题。
基本原理
1.1 使用场景
IP 安全性 （IPsec） 为 IP 数据报提供机密性、数据完整性、访问控制和数据源身份验证，这些服务是通过维护 IP 数据报的源和接收方之间的共享状态来提供的。以手动方式建立此共享状态不能很好地扩展。IKEv2正是这样一个动态建立此状态的协议。IKE 在双方之间执行相互身份验证，并建立 IKE 安全关联 （SA），该关联包含共享机密信息，可用于高效建立用于封装安全有效负载 （ESP） [ESP] 或身份验证标头 （AH） [AH] 的 SA，以及一组加密算法，供 SA 用于保护其承载的流量。IKE 用于在许多不同的场景中协商 ESP 或 AH SA，每种方案都有自己的特殊要求。
1.1.1 隧道模式下的安全网关到安全网关
在此方案中，IP 连接的两个endpoint都不实现 IPsec，但它们之间的网络节点会保护部分方式的流量。保护对endpoint是透明的，并且依赖于普通路由通过隧道终结点发送数据包进行处理。每个endpoint将宣布其后subnet的地址集，数据包将以隧道模式发送，其中内部 IP 标头将包含实际端点的 IP 地址。
1.1.2 端点到端点传输模式
在此方案中，IP 连接的两个终结点都实现 IPsec，这是 [IPSECARCH] 中主机的要求。该模式通常使用没有内部 IP 标头。将协商一对地址，以便此 SA 保护数据包。这些endpoint可以根据参与者的 IPsec 身份验证身份实现应用层访问控制。此方案实现了端到端安全性。虽然此场景可能不完全适用于 IPv4 公网，但已在使用 IKEv1 的内网内的特定场景中成功部署。在向 IPv6 过渡期间和采用 IKEv2 期间，应该更广泛地启用它。
在这种情况下，一个或两个受保护的端点可能位于网络地址转换 （NAT） 节点后面，在这种情况下，必须对隧道数据包进行 UDP 封装，以便 UDP 标头中的端口号可用于标识 NAT “后面”的各个endpoint。
1.1.3隧道模式下的端点到安全网关
在此方案中，受保护的endpoint（通常是便携式计算机）通过受 IPsec保护的隧道连接回其企业网络。它可能仅使用此隧道访问公司网络上的信息，或者可能通过公司网络将其所有流量通过隧道传输回，以便利用公司防火墙提供的针对基于 Internet 的攻击的保护。在任一情况下，受保护端点都需要一个与安全网关关联的 IP 地址，以便返回到该网关的数据包将转到安全网关并用隧道传回。此 IP 地址可以是静态的，也可以由安全网关动态分配。为了支持后一种情况，IKEv2 包括一种机制（即配置有效负载），发起方请求安全网关拥有的 IP 地址，以便在其 SA 期间使用。
在这种情况下，数据包将使用隧道模式。在来自受保护endpoint的每个数据包上，外部 IP 标头将包含与其当前位置关联的源 IP 地址（即，将流量直接路由到端点的地址），而内部 IP 标头将包含安全网关分配的源 IP 地址（即，将流量路由到安全网关以转发到端点的地址）。外部目标地址将始终是安全网关的地址，而内部目标地址将是数据包的最终目标。
在这种情况下，受保护的终结点可能位于 NAT 后面。在这种情况下，安全网关看到的 IP 地址将与受保护端点发送的 IP 地址不同，并且必须对数据包进行 UDP 封装才能正确路由。
1.2初始交换
使用 IKE 的通信始终从IKE_SA_INIT和IKE_AUTH交换开始（在 IKEv1 中称为阶段 1）。这些初始交换通常由四条消息组成，但在某些情况下，该数字可能会增长。使用 IKE 的所有通信都由请求/响应对组成。我们将首先描述基础交换，然后是变体。第一对消息 （IKE_SA_INIT） 协商加密算法、交换随机数并进行 Diffie-Hellman 交换 [DH]。
第二对消息 （IKE_AUTH） 对以前的消息进行身份验证，交换身份和证书，并建立第一个子 SA。这些消息的某些部分使用通过IKE_SA_INIT交换建立的密钥进行加密和完整性保护，因此身份对窃听者隐藏，并且所有消息中的所有字段都经过身份验证。有关如何生成加密密钥的信息，请参阅第 2.14 节。（无法完成IKE_AUTH交换的中间人攻击者仍可以看到发起者的身份。
初始交换后的所有消息都使用在IKE_SA_INIT交换中协商的加密算法和密钥进行加密保护。这些后续消息使用第 3.14 节中描述的加密有效负载的语法，使用第 2.14 节中所述派生的密钥进行加密。所有后续消息都包含加密有效负载，即使它们在文本中称为“空”。对于CREATE_CHILD_SA、IKE_AUTH或信息交换，标头后面的消息是加密的，包含标头的消息是使用为 IKE SA 协商的加密算法进行完整性保护的。
每个 IKE 消息都包含一个消息 ID 作为其固定标头的一部分。此消息 ID 用于匹配请求和响应，并标识消息的重新传输。
一些简称如下
|
|
第 3 节介绍了每个有效负载的内容的详细信息。可能选择显示的有效负载将显示在括号中，例如 [CERTREQ];这表示可以选择包含证书请求有效负载。
初始交流如下：
发起方→接收方HDR, SAi1, KEi, Ni。
HDR 包含安全参数索引 （SPI）、版本号、Exchange 类型、消息 ID 和各种标志。SAi1 有效负载声明发起方为 IKE SA 支持的加密算法。KE 有效负载发送发起方的 Diffie-Hellman 值。Ni是发起者的随机数。
接收方→发起方HDR, SAr1, KEr, Nr, [CERTREQ]。
响应方从发起方提供的选择中选择加密套件，并在 SAr1 有效负载中表达该选择，完成与 KEr 有效负载的 Diffie-Hellman 交换，并在 Nr 有效负载中发送其随机数。
在协商的这一点上，每一方都可以生成一个名为 SKEYSEED 的数量（参见第 2.14 节），该 IKE SA 的所有密钥都从中派生出来。以下消息完全加密和完整性保护，邮件头除外。用于加密和完整性保护的密钥派生自 SKEYSEED，称为SK_e（加密）和SK_a（身份验证，又名完整性保护）;有关密钥派生的详细信息，请参见第 2.13 和 2.14 节。为每个方向计算单独的SK_e和SK_a。除了从 Diffie-Hellman 值派生的用于保护 IKE SA 的密钥SK_e和SK_a之外，还派生了另一个数量SK_d，并用于派生子 SA 的进一步密钥材料。符号 SK { … } 表示这些有效负载已使用该方向的SK_e和SK_a进行加密和完整性保护。
发起方→接收方HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} 。发起方使用 IDi 有效负载断言其身份，证明与 IDi 对应的密钥的知识，完整性使用 AUTH 有效负载保护第一条消息的内容（请参阅第 2.15 节）。它还可能在 CERT 有效负载中发送其证书，并在 CERTREQ 有效负载中发送其信任锚的列表。如果包含任何 CERT 有效负载，则提供的第一个证书必须包含用于验证 AUTH 字段的公钥。可选的有效负载 IDr 使发起方能够指定要与响应方的哪个身份通信。当运行响应程序的计算机在同一 IP 地址上托管多个标识时，这很有用。如果发起方建议的 IDr 不被响应方接受，则响应方可能会使用其他某个 IDr 来完成交换。如果发起方随后不接受响应方使用的 IDr 与所请求的 IDr 不同的事实，则发起方可以在注意到这一事实后关闭 SA。发起方使用 SAi2 有效负载开始协商子 SA。最终字段（以 SAi2 开头）在CREATE_CHILD_SA交换的描述中描述。
接收方→发起方HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}。响应方使用 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交换期间创建子 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通知错误消息），则不会创建 IKE SA。请注意，尽管IKE_AUTH消息已加密且完整性受到保护，但如果收到此通知错误消息的对等方尚未对另一端进行身份验证（或者如果对等方由于某种原因未能对另一端进行身份验证），则需要谨慎对待这些信息。更准确地说，假设MAC正确验证，则已知错误通知消息的发送方是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 提供更强有力的前向保密保证。子 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 Notify 有效负载中指示其首选的 Diffie-Hellman 组。有两个八位字节的数据与此通知相关联：接受的 Diffie-Hellman 组号，按大端序排列。在此类拒绝的情况下，CREATE_CHILD_SA交换失败，发起方可能会在响应者在INVALID_KE_PAYLOAD通知有效负载中给出的组中使用 Diffie-Hellman 提案和 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请求是：
发起方→接收方 HDR, SK {SA, Ni, [KEi,] TSi, TSr}。
发起方在 SA 有效负载中发送 SA 选件，在 Ni 有效负载中发送随机数，在 KEi 有效负载中发送 Diffie-Hellman 值（可选），并在 TSi 和 TSr 有效负载中发送建议的子 SA 的建议流量选择器。
接收方→发起方 HDR, SK {SA, Nr, [KEr,]TSi, TSr}
如果请求中包含 KEi 并且所选加密套件包含该组，则响应程序使用 SA 有效负载中的已接受产品/服务、Nr 有效负载中的随机数和 KEr 有效负载中的 Diffie-Hellman 值进行回复（使用相同的消息 ID 进行响应）。
要在该 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通知用于碎片控制。有关更全面的解释，请参见 [IPSECARCH]。双方需要同意在任何一方发送非第一个片段之前发送。仅当建议 SA 的请求和接受 SA 的响应中都包含通知NON_FIRST_FRAGMENTS_ALSO才会启用它。如果响应程序不想发送或接收非第一个片段，则它只会从响应中省略NON_FIRST_FRAGMENTS_ALSO通知，但不会拒绝整个子 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请求是：
发起方→接收方HDR, SK {SA, Ni, KEi}
发起方在 SA 有效负载中发送 SA 产品/服务，在 Ni 有效负载中发送随机数，在 KEi 有效负载中发送 Diffie-Hellman 值。必须包括 KEi 有效负载。新的发起方 SPI 在 SA 有效负载的 SPI 字段中提供。一旦对等方收到重新生成 IKE SA 密钥的请求或发送重新生成 IKE SA 的请求，它就不应在正在重新生成密钥的 IKE SA 上发起任何新的CREATE_CHILD_SA交换。
接收方→发起方 HDR, SK {SA, Nr, KEr}
如果所选加密套件包含该组，则响应程序使用 SA 有效负载中的已接受产品/服务、Nr 有效负载中的随机数和 KEr 有效负载中的 Diffie-Hellman 值进行回复（使用相同的消息 ID 进行响应）。新的响应程序 SPI 在 SA 有效负载的 SPI 字段中提供。
新的 IKE SA 将其消息计数器设置为 0，无论它们在早期的 IKE SA 中是什么。来自新 IKE SA 上双方的第一个 IKE 请求的消息 ID 为 0。旧的 IKE SA 保留其编号，因此任何进一步的请求（例如，删除 IKE SA）都将具有连续编号。新的 IKE SA 的窗口大小也重置为 1，并且此重新密钥交换中的发起方是新 IKE SA 的新“原始发起方”。
1.3.3. 使用 CREATE_CHILD_SA 交换重新生成子 SA 的密钥
重新生成子 SA 密钥CREATE_CHILD_SA请求是：
发起方→接收方 HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr}
发起方在 SA 有效负载中发送 SA 选件，在 Ni 有效负载中发送随机数，在 KEi 有效负载中发送 Diffie-Hellman 值（可选），并在 TSi 和 TSr 有效负载中发送建议的子 SA 的建议流量选择器。第 1.3.1 节中描述的通知也可以在重新生成密钥交换中发送。通常，这些通知与原始交换中使用的通知相同;例如，重新生成传输模式 SA 的密钥时，将使用USE_TRANSPORT_MODE通知。如果交换的目的是替换现有的 ESP 或 AH SA，则必须将REKEY_SA通知包含在CREATE_CHILD_SA交换中。正在重新生成密钥的 SA 由通知有效负载中的 SPI 字段标识;这是交换发起方在入站 ESP 或 AH 数据包中期望的 SPI。没有与此通知消息类型关联的数据。REKEY_SA通知的协议 ID 字段设置为与我们要重新生成密钥的 SA 的协议匹配，例如，3 表示 ESP，2 表示 AH。
重新生成子 SA 密钥CREATE_CHILD_SA响应为：
接收方→发起方 HDR, SK {SA, Nr, [KEr,] TSi, TSr}
如果请求中包含 KEi 并且所选加密套件包含该组，则响应程序使用 SA 有效负载中的已接受报价、Nr 有效负载中的随机数和 KEr 有效负载中的 Diffie-Hellman 值进行回复（使用相同的消息 ID 进行响应）。
要在该 SA 上发送的流量的流量选择器在响应的 TS 有效负载中指定，这可能是子 SA 的发起方建议的子集。
1.4. 信息交换
在 IKE SA 运行过程中的不同点，对等方可能希望相互传达有关某些事件的错误或通知的控制消息。为了实现这一点，IKE 定义了一个信息交换。信息交换必须仅在初始交换之后进行，并使用协商密钥进行加密保护。请注意，某些信息性消息（而非交换）可以在 IKE SA 的上下文之外发送。第 2.21 节还详细介绍了错误消息。
与 IKE SA 相关的控制消息必须在该 IKE SA 下发送。与子 SA 相关的控制消息必须在生成它们的 IKE SA（如果 IKE SA 已重新生成密钥，则为其后续消息）的保护下发送。
信息交换中的消息包含零个或多个通知、删除和配置有效负载。信息交换请求的接收者必须发送一些响应;否则，发送方将假定消息在网络中丢失并重新传输。该响应可能是一条空消息。信息交换中的请求消息也可能不包含有效负载。这是终结点可以要求另一个终结点验证其是否处于活动状态的预期方式。
信息交换定义为：
发起方→接收方 HDR, SK {[N,] [D,] [CP,] …}
接收方→发起方 HDR, SK {[N,] [D,] [CP,] …}
信息交换的处理由其组件有效载荷决定。
1.4.1. 删除具有信息交换的 SA
ESP 和 AH SA 始终成对存在，每个方向上有一个 SA。关闭 SA 时，必须关闭（即删除）对的两个成员。每个终结点必须关闭其传入的 SA，并允许另一个终结点关闭每对中的另一个 SA。要删除 SA，将发送具有一个或多个 Delete 有效负载的信息交换，列出要删除的 SA 的 SPI（正如入站数据包标头中预期的那样）。收件人必须关闭指定的 SA。请注意，从不在单个消息中发送 SA 两端的删除有效负载。如果要同时删除多个 SA，则在信息交换中包括每个 SA 对的入站部分的删除有效负载。
通常，信息交换中的响应将包含向另一个方向的配对 SA 的删除有效负载。有一个例外。如果一组 SA 的两端偶然独立决定关闭它们，则每个 SA 都可能发送 Delete 有效负载，并且这两个请求可能会在网络中交叉。如果节点收到已发出删除请求的 SA 的删除请求，则必须在处理请求时删除传出 SA，在处理响应时删除传入 SA。在这种情况下，响应不得包含已删除 SA 的删除有效负载，因为这会导致重复删除，并且理论上可能会删除错误的 SA。
与 ESP 和 AH SA 类似，IKE SA 也通过发送信息交换来删除。删除 IKE SA 会隐式关闭根据该 IKE SA 协商的任何剩余子 SA。对删除 IKE SA 的请求的响应是空的信息响应。
半闭合 ESP 或 AH 连接是异常的，具有审计功能的节点如果它们仍然存在，则可能应该审计它们的存在。请注意，此规范未指定时间段，因此由各个终结点决定等待多长时间。节点可以拒绝接受半闭合连接上的传入数据，但不得单方面关闭它们并重用 SPI。如果连接状态变得足够混乱，节点可能会关闭 IKE SA，如上所述。然后，它可以在新的 IKE SA 下干净的基础上重建所需的 SA。
1.5 IKE SA 之外的信息性消息
在某些情况下，节点收到无法处理的数据包，但它可能希望将这种情况通知发送方。
- 如果 ESP 或 AH 数据包到达时带有无法识别的 SPI。这可能是由于接收节点最近崩溃并丢失状态，或者由于其他一些系统故障或攻击。
- 如果加密的 IKE 请求数据包到达端口 500 或 4500，并且具有无法识别的 IKE SPI。这可能是由于接收节点最近崩溃并丢失状态，或者由于其他一些系统故障或攻击。
- 如果 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 的规则的例外。发起方标志设置为 1，响应标志设置为 0，版本标志以正常方式设置;这些标志在第 3.1 节中描述。
在第两种和第三种情况下，消息始终在没有加密保护的情况下发送（在 IKE SA 外部），并且包括INVALID_IKE_SPI或INVALID_MAJOR_VERSION通知（没有通知数据）。该消息是响应消息，因此它被发送到带有相同 IKE SPI 的 IP 地址和端口，并且消息 ID 和交换类型是从请求中复制的。响应标志设置为 1，版本标志以正常方式设置。
可能存在的问题
参考发表在27th USENIX Security Symposium (USENIX Security 18), 2018的The Dangers of Key Reuse: Practical Attacks on IPsec IKE可IKEv1、v2如果重用密钥可能导致跨协议身份验证绕过，从而使攻击者能够冒充受害者主机或网络。在IKEv1模式下利用Bleichenbacher预言机，其中RSA加密的随机数用于身份验证。利用此漏洞打破了基于 RSA 加密的模式，此外还破坏了 IKEv1 和 IKEv2 中基于 RSA 签名的身份验证。此外，还存在针对基于 PSK（预共享密钥）的 IKE 模式的离线字典攻击，从而涵盖了 IKE 的所有可用身份验证机制。在思科（CVE-2018-0131）、华为（CVE2017-17305）、Clavister（CVE-2018-8753）和合勤科技（CVE-2018-9129）的IKEv1实现中找到了Bleichenbacher预言机。