Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8019 Check Point
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
November 2016
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 8019 Check Point
Category: Standards Track V. Smyslov
ISSN: 2070-1721 ELVIS-PLUS
November 2016
Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks
保护Internet密钥交换协议版本2（IKEv2）实现免受分布式拒绝服务攻击
Abstract
摘要
This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial-of-Service and Distributed Denial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task.
本文档建议Internet密钥交换协议版本2（IKEv2）响应程序的实施和配置最佳做法，以使其能够抵御拒绝服务和分布式拒绝服务攻击。此外，该文档还引入了一种称为“客户机难题”的新机制，有助于完成此任务。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8019.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8019.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
4. Defense Measures While the IKE SA Is Being Created . . . . . 6
4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 8
4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 11
4.6. Keeping Computed Shared Keys . . . . . . . . . . . . . . 11
4.7. Preventing "Hash and URL" Certificate Encoding Attacks . 11
4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 12
5. Defense Measures after an IKE SA Is Created . . . . . . . . . 12
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 14
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 16
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 16
7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 17
7.1.2. Solving a Puzzle and Returning the Solution . . . . . 19
7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 20
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 21
7.1.5. Deciding Whether to Serve the Request . . . . . . . . 22
7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 23
7.2.1. Presenting the Puzzle . . . . . . . . . . . . . . . . 24
7.2.2. Solving the Puzzle and Returning the Solution . . . . 24
7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 25
7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 25
8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 26
8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 27
9. Operational Considerations . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
4. Defense Measures While the IKE SA Is Being Created . . . . . 6
4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 8
4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 11
4.6. Keeping Computed Shared Keys . . . . . . . . . . . . . . 11
4.7. Preventing "Hash and URL" Certificate Encoding Attacks . 11
4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 12
5. Defense Measures after an IKE SA Is Created . . . . . . . . . 12
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 14
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 16
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 16
7.1.1. Presenting a Puzzle . . . . . . . . . . . . . . . . . 17
7.1.2. Solving a Puzzle and Returning the Solution . . . . . 19
7.1.3. Computing a Puzzle . . . . . . . . . . . . . . . . . 20
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 21
7.1.5. Deciding Whether to Serve the Request . . . . . . . . 22
7.2. Puzzles in an IKE_AUTH Exchange . . . . . . . . . . . . . 23
7.2.1. Presenting the Puzzle . . . . . . . . . . . . . . . . 24
7.2.2. Solving the Puzzle and Returning the Solution . . . . 24
7.2.3. Computing the Puzzle . . . . . . . . . . . . . . . . 25
7.2.4. Receiving the Puzzle Solution . . . . . . . . . . . . 25
8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 26
8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 27
9. Operational Considerations . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Denial-of-Service (DoS) attacks have always been considered a serious threat. These attacks are usually difficult to defend against since the amount of resources the victim has is always bounded (regardless of how high it is) and because some resources are required for distinguishing a legitimate session from an attack.
拒绝服务（DoS）攻击一直被认为是一种严重威胁。这些攻击通常很难防御，因为受害者拥有的资源量总是有限的（无论多高），并且需要一些资源来区分合法会话和攻击。
The Internet Key Exchange Protocol version 2 (IKEv2) described in [RFC7296] includes defense against DoS attacks. In particular, there is a cookie mechanism that allows the IKE Responder to defend itself against DoS attacks from spoofed IP addresses. However, botnets have become widespread, allowing attackers to perform Distributed Denial-of-Service (DDoS) attacks, which are more difficult to defend against. This document presents recommendations to help the Responder counter DoS and DDoS attacks. It also introduces a new mechanism -- "puzzles" -- that can help accomplish this task.
[RFC7296]中描述的Internet密钥交换协议版本2（IKEv2）包括防御DoS攻击。特别是，有一种cookie机制，允许IKE响应程序抵御来自伪造IP地址的DoS攻击。然而，僵尸网络已经变得非常普遍，使得攻击者能够执行分布式拒绝服务（DDoS）攻击，这使得防御更加困难。本文档提供了帮助响应者抵御DoS和DDoS攻击的建议。它还引入了一种新的机制——“谜题”——可以帮助完成这项任务。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The IKE_SA_INIT exchange described in Section 1.2 of [RFC7296] involves the Initiator sending a single message. The Responder replies with a single message and also allocates memory for a structure called a half-open IKE Security Association (SA). This half-open SA is later authenticated in the IKE_AUTH exchange. If that IKE_AUTH request never comes, the half-open SA is kept for an unspecified amount of time. Depending on the algorithms used and implementation, such a half-open SA will use from around one hundred to several thousand bytes of memory.
[RFC7296]第1.2节中描述的IKE_SA_INIT交换涉及启动器发送单个消息。响应者用一条消息进行回复，并为一个称为半开放IKE安全关联（SA）的结构分配内存。该半开放SA稍后在IKE_身份验证交换中进行身份验证。如果IKE_AUTH请求从未出现，则半开放SA将保留一段未指定的时间。根据使用的算法和实现，这种半开放SA将使用大约100到数千字节的内存。
This creates an easy attack vector against an IKE Responder. Generating the IKE_SA_INIT request is cheap. Sending large amounts of IKE_SA_INIT requests can cause a Responder to use up all its resources. If the Responder tries to defend against this by throttling new requests, this will also prevent legitimate Initiators from setting up IKE SAs.
这就创建了一个攻击IKE响应的简单攻击向量。生成IKE_SA_INIT请求的成本很低。发送大量IKE_SA_INIT请求可能会导致响应程序耗尽其所有资源。如果响应者试图通过限制新请求来防御此问题，这也将阻止合法的启动器设置IKE SA。
An obvious defense, which is described in Section 4.2, is limiting the number of half-open SAs opened by a single peer. However, since all that is required is a single packet, an attacker can use multiple spoofed source IP addresses.
第4.2节中描述的一个明显的防御措施是限制由单个对等方打开的半开放SAs的数量。但是，由于只需要一个数据包，攻击者可以使用多个伪造的源IP地址。
If we break down what a Responder has to do during an initial exchange, there are three stages:
如果我们将响应者在初始交换期间必须做的事情分解为三个阶段：
1. When the IKE_SA_INIT request arrives, the Responder:
1. 当IKE_SA_INIT请求到达时，响应者：
* Generates or reuses a Diffie-Hellman (DH) private part.
* 生成或重用Diffie Hellman（DH）私有部分。
* Generates a Responder Security Parameter Index (SPI).
* 生成响应程序安全参数索引（SPI）。
* Stores the private part and peer public part in a half-open SA database.
* 将私有部分和对等公共部分存储在半开放的SA数据库中。
2. When the IKE_AUTH request arrives, the Responder:
2. 当IKE_认证请求到达时，响应者：
* Derives the keys from the half-open SA.
* 从半开SA派生关键点。
* Decrypts the request.
* 解密请求。
3. If the IKE_AUTH request decrypts properly, the Responder:
3. 如果IKE_AUTH请求正确解密，则响应程序：
* Validates the certificate chain (if present) in the IKE_AUTH request.
* 验证IKE_验证请求中的证书链（如果存在）。
The fourth stage where the Responder creates the Child SA is not reached by attackers who cannot pass the authentication step.
无法通过身份验证步骤的攻击者无法到达响应者创建子SA的第四阶段。
Stage #1 is pretty light on CPU usage, but requires some storage, and it's very light for the Initiator as well. Stage #2 includes private-key operations, so it is much heavier CPU-wise. Stage #3 may include public key operations if certificates are involved. These operations are often more computationally expensive than those performed at stage #2.
阶段#1的CPU使用率非常低，但需要一些存储，而且对于启动器来说也非常轻。第2阶段包括私钥操作，因此在CPU方面要重得多。如果涉及证书，第3阶段可能包括公钥操作。这些操作通常比在第2阶段执行的操作在计算上更昂贵。
To attack such a Responder, an attacker can attempt to exhaust either memory or CPU. Without any protection, the most efficient attack is to send multiple IKE_SA_INIT requests and exhaust memory. This is easy because IKE_SA_INIT requests are cheap.
要攻击此类响应程序，攻击者可以尝试耗尽内存或CPU。在没有任何保护的情况下，最有效的攻击是发送多个IKE_SA_INIT请求并耗尽内存。这很容易，因为IKE_SA_INIT请求很便宜。
There are obvious ways for the Responder to protect itself without changes to the protocol. It can reduce the time that an entry remains in the half-open SA database, and it can limit the amount of concurrent half-open SAs from a particular address or prefix. The attacker can overcome this by using spoofed source addresses.
响应者有明显的方法可以在不更改协议的情况下保护自己。它可以减少条目保留在半开放SA数据库中的时间，并且可以从特定地址或前缀限制并发半开放SA的数量。攻击者可以通过使用伪造的源地址来克服这一问题。
The stateless cookie mechanism from Section 2.6 of [RFC7296] prevents an attack with spoofed source addresses. This doesn't completely solve the issue, but it makes the limiting of half-open SAs by address or prefix work. Puzzles, introduced in Section 4.4,
[RFC7296]第2.6节中的无状态cookie机制可防止使用伪造源地址的攻击。这并不能完全解决这个问题，但它使地址或前缀对半开放SAs的限制起作用。第4.4节中介绍的谜题，
accomplish the same thing -- only more of it. They make it harder for an attacker to reach the goal of getting a half-open SA. Puzzles do not have to be so hard that an attacker cannot afford to solve a single puzzle; it is enough that puzzles increase the cost of creating half-open SAs, so the attacker is limited in the amount they can create.
完成同样的事情——只是更多。它们使攻击者更难达到半开SA的目标。谜题不必太难，以至于攻击者无法解决单个谜题；拼图游戏增加了创建半开放SAs的成本就足够了，因此攻击者可以创建的数量有限。
Reducing the lifetime of an abandoned half-open SA also reduces the impact of such attacks. For example, if a half-open SA is kept for 1 minute and the capacity is 60,000 half-open SAs, an attacker would need to create 1,000 half-open SAs per second. If the retention time is reduced to 3 seconds, the attacker would need to create 20,000 half-open SAs per second to get the same result. By introducing a puzzle, each half-open SA becomes more expensive for an attacker, making it more likely to prevent an exhaustion attack against Responder memory.
减少被遗弃的半开放SA的使用寿命也会减少此类攻击的影响。例如，如果半开SA保持1分钟，容量为60000个半开SA，则攻击者每秒需要创建1000个半开SA。如果保留时间减少到3秒，攻击者将需要每秒创建20000个半开SAs才能获得相同的结果。通过引入一个谜题，对于攻击者来说，每个半开放的SA都会变得更昂贵，从而更有可能防止针对响应者内存的耗尽攻击。
At this point, filling up the half-open SA database is no longer the most efficient DoS attack. The attacker has two alternative attacks to do better:
此时，填充半开放的SA数据库不再是最有效的DoS攻击。攻击者有两种替代攻击可以做得更好：
1. Go back to spoofed addresses and try to overwhelm the CPU that deals with generating cookies, or
1. 返回到伪造的地址，并尝试压倒处理生成cookie的CPU，或
2. Take the attack to the next level by also sending an IKE_AUTH request.
2. 通过发送IKE_AUTH请求，将攻击提升到下一级别。
If an attacker is so powerful that it is able to overwhelm the Responder's CPU that deals with generating cookies, then the attack cannot be dealt with at the IKE level and must be handled by means of the Intrusion Prevention System (IPS) technology.
如果攻击者非常强大，能够压倒响应者处理生成cookie的CPU，则攻击无法在IKE级别处理，必须通过入侵预防系统（IPS）技术进行处理。
On the other hand, the second alternative of sending an IKE_AUTH request is very cheap. It requires generating a proper IKE header with the correct IKE SPIs and a single Encrypted payload. The content of the payload is irrelevant and might be junk. The Responder has to perform the relatively expensive key derivation, only to find that the Message Authentication Code (MAC) on the Encrypted payload on the IKE_AUTH request fails the integrity check. If a Responder does not hold on to the calculated SKEYSEED and SK_* keys (which it should in case a valid IKE_AUTH comes in later), this attack might be repeated on the same half-open SA. Puzzles make attacks of such sort more costly for an attacker. See Section 7.2 for details.
另一方面，发送IKE_AUTH请求的第二种选择非常便宜。它需要生成具有正确IKE SPI和单个加密负载的正确IKE头。有效负载的内容是无关的，可能是垃圾。响应者必须执行相对昂贵的密钥推导，结果发现IKE_AUTH请求上加密负载上的消息身份验证码（MAC）未通过完整性检查。如果响应者没有保留计算出的SKEYSEED和SK_*密钥（如果稍后出现有效的IKE_身份验证，则应保留这些密钥），则此攻击可能会在相同的半开放SA上重复。对于攻击者来说，谜题使得此类攻击的成本更高。详见第7.2节。
Here too, the number of half-open SAs that the attacker can achieve is crucial, because each one allows the attacker to waste some CPU time. So making it hard to make many half-open SAs is important.
在这里，攻击者可以实现的半开放SA的数量也是至关重要的，因为每一个都会让攻击者浪费一些CPU时间。因此，使许多半开放的SA难以实现是很重要的。
A strategy against DDoS has to rely on at least 4 components:
针对DDoS的策略必须依赖于至少4个组件：
1. Hardening the half-open SA database by reducing retention time.
1. 通过减少保留时间强化半开放SA数据库。
2. Hardening the half-open SA database by rate-limiting single IPs/ prefixes.
2. 通过限制单个IP/前缀的速率来强化半开放SA数据库。
3. Guidance on what to do when an IKE_AUTH request fails to decrypt.
3. 关于IKE_身份验证请求解密失败时如何操作的指导。
4. Increasing the cost of half-open SAs up to what is tolerable for legitimate clients.
4. 将半开放SAs的成本提高到合法客户可以承受的水平。
Puzzles are used as a solution for strategy #4.
谜题被用作策略4的解决方案。
As a UDP-based protocol, IKEv2 has to deal with packet loss through retransmissions. Section 2.4 of [RFC7296] recommends "that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up." Many retransmission policies in practice wait one or two seconds before retransmitting for the first time.
作为一种基于UDP的协议，IKEv2必须通过重传来处理数据包丢失。[RFC7296]的第2.4节建议“在放弃之前，在至少几分钟的时间段内，至少要重新传输十几次消息。”实际上，许多重新传输策略在第一次重新传输之前要等待一到两秒钟。
Because of this, setting the timeout on a half-open SA too low will cause it to expire whenever even one IKE_AUTH request packet is lost. When not under attack, the half-open SA timeout SHOULD be set high enough that the Initiator will have enough time to send multiple retransmissions, minimizing the chance of transient network congestion causing an IKE failure.
因此，将半开放SA上的超时设置得太低将导致它在一个IKE_AUTH请求数据包丢失时过期。当不受攻击时，应将半开放SA超时设置得足够高，以使启动器有足够的时间发送多次重传，从而最大限度地减少导致IKE故障的暂时网络拥塞的机会。
When the system is under attack, as measured by the amount of half-open SAs, it makes sense to reduce this lifetime. The Responder should still allow enough time for the round-trip, for the Initiator to derive the DH shared value, and to derive the IKE SA keys and create the IKE_AUTH request. Two seconds is probably as low a value as can realistically be used.
当系统受到攻击时（以半开放SAs的数量衡量），缩短此寿命是有意义的。响应者仍应留出足够的时间进行往返，以便发起方派生DH共享值，派生IKE SA密钥并创建IKE_AUTH请求。两秒可能是现实中可以使用的最低值。
It could make sense to assign a shorter value to half-open SAs originating from IP addresses or prefixes that are considered suspect because of multiple concurrent half-open SAs.
将一个较短的值分配给源于IP地址或前缀的半开放SAs是有意义的，因为这些IP地址或前缀被认为是可疑的，因为有多个并发半开放SAs。
Even with DDoS, the attacker has only a limited amount of nodes participating in the attack. By limiting the amount of half-open SAs that are allowed to exist concurrently with each such node, the total amount of half-open SAs is capped, as is the total amount of key derivations that the Responder is forced to complete.
即使使用DDoS，攻击者也只有有限数量的节点参与攻击。通过限制允许与每个这样的节点同时存在的半开放SA的数量，半开放SA的总量被限制，响应者被迫完成的密钥派生的总量也被限制。
In IPv4, it makes sense to limit the number of half-open SAs based on IP address. Most IPv4 nodes are either directly attached to the Internet using a routable address or hidden behind a NAT device with a single IPv4 external address. For IPv6, ISPs assign between a /48 and a /64, so it does not make sense for rate limiting to work on single IPv6 IPs. Instead, rate limits should be done based on either the /48 or /64 of the misbehaving IPv6 address observed.
在IPv4中，根据IP地址限制半开放SAs的数量是有意义的。大多数IPv4节点要么使用可路由地址直接连接到Internet，要么隐藏在具有单个IPv4外部地址的NAT设备后面。对于IPv6，ISP在a/48和a/64之间分配，因此在单个IPv6 IP上进行速率限制是没有意义的。相反，速率限制应该基于观察到的异常IPv6地址的/48或/64进行。
The number of half-open SAs is easy to measure, but it is also worthwhile to measure the number of failed IKE_AUTH exchanges. If possible, both factors should be taken into account when deciding which IP address or prefix is considered suspicious.
半开放SA的数量很容易测量，但也值得测量失败的IKE_身份验证交换的数量。如果可能，在决定哪个IP地址或前缀被视为可疑时，应考虑这两个因素。
There are two ways to rate limit a peer address or prefix:
有两种方法可以对对等地址或前缀进行速率限制：
1. Hard Limit -- where the number of half-open SAs is capped, and any further IKE_SA_INIT requests are rejected.
1. 硬限制——半开放SA的数量被限制，任何进一步的IKE_SA_INIT请求都被拒绝。
2. Soft Limit -- where if a set number of half-open SAs exist for a particular address or prefix, any IKE_SA_INIT request will be required to solve a puzzle.
2. 软限制——如果特定地址或前缀存在一定数量的半开放SA，则需要任何IKE_SA_INIT请求来解决难题。
The advantage of the hard limit method is that it provides a hard cap on the amount of half-open SAs that the attacker is able to create. The disadvantage is that it allows the attacker to block IKE initiation from small parts of the Internet. For example, if a network service provider or some establishment offers Internet connectivity to its customers or employees through an IPv4 NAT device, a single malicious customer can create enough half-open SAs to fill the quota for the NAT device external IP address. Legitimate Initiators on the same network will not be able to initiate IKE.
硬限制方法的优点是，它为攻击者能够创建的半开放SA数量提供了硬上限。缺点是，它允许攻击者阻止IKE从互联网的一小部分发起。例如，如果网络服务提供商或某些机构通过IPv4 NAT设备向其客户或员工提供Internet连接，则单个恶意客户可以创建足够的半开放SAs，以填充NAT设备外部IP地址的配额。同一网络上的合法启动器将无法启动IKE。
The advantage of a soft limit is that legitimate clients can always connect. The disadvantage is that an adversary with sufficient CPU resources can still effectively DoS the Responder.
软限制的优点是合法客户端始终可以连接。缺点是，拥有足够CPU资源的对手仍然可以有效地拒绝响应者。
Regardless of the type of rate limiting used, legitimate Initiators that are not on the same network segments as the attackers will not be affected. This is very important as it reduces the adverse impact
无论使用何种速率限制，与攻击者不在同一网段上的合法启动器都不会受到影响。这一点非常重要，因为它可以减少不利影响
caused by the measures used to counteract the attack and allows most Initiators to keep working even if they do not support puzzles.
这是由用来抵抗攻击的措施引起的，即使大多数发起者不支持拼图，他们也可以继续工作。
Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attacks: the stateless cookie. When the server is under load, the Responder responds to the IKE_SA_INIT request with a calculated "stateless cookie" -- a value that can be recalculated based on values in the IKE_SA_INIT request without storing Responder-side state. The Initiator is expected to repeat the IKE_SA_INIT request, this time including the stateless cookie. This mechanism prevents DoS attacks from spoofed IP addresses, since an attacker needs to have a routable IP address to return the cookie.
[RFC7296]的第2.6节提供了一种缓解DoS攻击的机制：无状态cookie。当服务器处于负载状态时，响应程序使用计算出的“无状态cookie”响应IKE_SA_INIT请求——该值可以基于IKE_SA_INIT请求中的值重新计算，而无需存储响应程序端的状态。启动器应该重复IKE_SA_INIT请求，这次包括无状态cookie。此机制可防止来自伪造IP地址的DoS攻击，因为攻击者需要具有可路由的IP地址才能返回cookie。
Attackers that have multiple source IP addresses with return routability, such as in the case of botnets, can fill up a half-open SA table anyway. The cookie mechanism limits the amount of allocated state to the number of attackers, multiplied by the number of half-open SAs allowed per peer address, multiplied by the amount of state allocated for each half-open SA. With typical values, this can easily reach hundreds of megabytes.
具有多个具有返回路由能力的源IP地址的攻击者（如僵尸网络）可以填充半开放的SA表。cookie机制将分配的状态量限制为攻击者数量乘以每个对等地址允许的半开放SA数量，再乘以为每个半开放SA分配的状态量。对于典型值，这很容易达到数百兆字节。
The puzzle introduced here extends the cookie mechanism of [RFC7296]. It is loosely based on the proof-of-work technique used in Bitcoin [BITCOINS]. Puzzles set an upper bound, determined by the attacker's CPU, to the number of negotiations the attacker can initiate in a unit of time.
这里介绍的谜题扩展了[RFC7296]的cookie机制。它大致基于比特币[比特币]中使用的工作证明技术。谜题将由攻击者的CPU确定的上限设置为攻击者在一个时间单位内可以发起的协商次数。
A puzzle is sent to the Initiator in two cases:
在两种情况下，向发起人发送谜题：
o The Responder is so overloaded that no half-open SAs may be created without solving a puzzle, or
o 响应者的负载过重，如果不解决难题，就无法创建半开SAs，或者
o The Responder is not too loaded, but the rate-limiting method described in Section 4.2 prevents half-open SAs from being created with this particular peer address or prefix without first solving a puzzle.
o 响应程序的负载不太大，但第4.2节中描述的速率限制方法可防止使用此特定对等地址或前缀创建半开放SAs，而无需先解决难题。
When the Responder decides to send the challenge to solve a puzzle in response to an IKE_SA_INIT request, the message includes at least three components:
当响应者决定响应IKE_SA_INIT请求发送解决谜题的质询时，该消息至少包括三个组件：
1. Cookie -- this is calculated the same as in [RFC7296], i.e., the process of generating the cookie is not specified.
1. Cookie——计算方法与[RFC7296]中相同，即未指定生成Cookie的过程。
2. Algorithm, this is the identifier of a Pseudorandom Function (PRF) algorithm, one of those proposed by the Initiator in the SA payload.
2. 算法，这是伪随机函数（PRF）算法的标识符，该算法是SA有效负载中发起方提出的算法之一。
3. Zero-Bit Count (ZBC). This is a number between 8 and 255 (or a special value - 0; see Section 7.1.1.1) that represents the length of the zero-bit run at the end of the output of the PRF function calculated over the cookie that the Initiator is to send. The values 1-8 are explicitly excluded, because they create a puzzle that is too easy to solve. Since the mechanism is supposed to be stateless for the Responder, either the same ZBC is used for all Initiators or the ZBC is somehow encoded in the cookie. If it is global, then it means that this value is the same for all the Initiators who are receiving puzzles at any given point of time. The Responder, however, may change this value over time depending on its load.
3. 零位计数（ZBC）。这是一个介于8和255之间的数字（或一个特殊值-0；请参阅第7.1.1.1节），它表示通过启动器要发送的cookie计算的PRF函数输出结束时零位运行的长度。值1-8被明确排除在外，因为它们创建了一个太容易解决的难题。由于该机制对于响应者来说应该是无状态的，所以所有启动器都使用相同的ZBC，或者ZBC以某种方式编码在cookie中。如果它是全局的，则意味着该值对于在任何给定时间点接收谜题的所有发起者都是相同的。但是，响应程序可能会根据其负载随时间改变此值。
Upon receiving this challenge, the Initiator attempts to calculate the PRF output using different keys. When enough keys are found such that the resulting PRF output calculated using each of them has a sufficient number of trailing zero bits, that result is sent to the Responder.
收到此质询后，启动器尝试使用不同的键计算PRF输出。当找到足够的键时，使用每个键计算的结果PRF输出具有足够数量的尾随零位，该结果被发送到响应程序。
The reason for using several keys in the results, rather than just one key, is to reduce the variance in the time it takes the Initiator to solve the puzzle. We have chosen the number of keys to be four (4) as a compromise between the conflicting goals of reducing variance and reducing the work the Responder needs to perform to verify the puzzle solution.
在结果中使用多个键而不是一个键的原因是为了减少发起者解决难题所需时间的差异。我们选择了四（4）个键作为减少差异和减少响应者验证谜题解决方案所需的工作量这两个相互冲突的目标之间的折衷。
When receiving a request with a solved puzzle, the Responder verifies two things:
当收到带有已解决难题的请求时，响应者验证两件事：
o That the cookie is indeed valid.
o cookie确实有效。
o That the results of PRF of the transmitted cookie calculated with the transmitted keys has a sufficient number of trailing zero bits.
o 使用传输密钥计算的传输cookie的PRF结果具有足够数量的尾随零位。
Example 1: Suppose the calculated cookie is 739ae7492d8a810cf5e8dc0f9626c9dda773c5a3 (20 octets), the algorithm is PRF-HMAC-SHA256, and the required number of zero bits is 18. After successively trying a bunch of keys, the Initiator finds the following four 3-octet keys that work:
示例1：假设计算出的cookie为739ae7492d8a810cf5e8dc0f9626c9dda773c5a3（20个八位字节），算法为PRF-HMAC-SHA256，所需的零位数为18。在连续尝试一组密钥后，启动器会找到以下四个3-octet密钥：
+--------+----------------------------------+----------------+
| Key | Last 32 Hex PRF Digits | # of Zero Bits |
+--------+----------------------------------+----------------+
| 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 |
| 073324 | 0d4233d6278c96e3369227a075800000 | 23 |
| 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 |
| 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 |
+--------+----------------------------------+----------------+
+--------+----------------------------------+----------------+
| Key | Last 32 Hex PRF Digits | # of Zero Bits |
+--------+----------------------------------+----------------+
| 061840 | e4f957b859d7fb1343b7b94a816c0000 | 18 |
| 073324 | 0d4233d6278c96e3369227a075800000 | 23 |
| 0c8a2a | 952a35d39d5ba06709da43af40700000 | 20 |
| 0d94c8 | 5a0452b21571e401a3d00803679c0000 | 18 |
+--------+----------------------------------+----------------+
Table 1: Four Solutions for the 18-Bit Puzzle
表1：18位拼图的四种解决方案
Example 2: Same cookie, but modify the required number of zero bits to 22. The first 4-octet keys that work to satisfy that requirement are 005d9e57, 010d8959, 0110778d, and 01187e37. Finding these requires 18,382,392 invocations of the PRF.
示例2：相同的cookie，但将所需的零位数修改为22。满足该要求的前4个八位键是005d9e57、010d8959、0110778d和01187e37。找到这些需要18382392次PRF调用。
+----------------+-------------------------------+
| # of Zero Bits | Time to Find 4 Keys (Seconds) |
+----------------+-------------------------------+
| 8 | 0.0025 |
| 10 | 0.0078 |
| 12 | 0.0530 |
| 14 | 0.2521 |
| 16 | 0.8504 |
| 17 | 1.5938 |
| 18 | 3.3842 |
| 19 | 3.8592 |
| 20 | 10.8876 |
+----------------+-------------------------------+
+----------------+-------------------------------+
| # of Zero Bits | Time to Find 4 Keys (Seconds) |
+----------------+-------------------------------+
| 8 | 0.0025 |
| 10 | 0.0078 |
| 12 | 0.0530 |
| 14 | 0.2521 |
| 16 | 0.8504 |
| 17 | 1.5938 |
| 18 | 3.3842 |
| 19 | 3.8592 |
| 20 | 10.8876 |
+----------------+-------------------------------+
Table 2: The Time Needed to Solve a Puzzle of Various Difficulty for
the Cookie 39ae7492d8a810cf5e8dc0f9626c9dda773c5a3
Table 2: The Time Needed to Solve a Puzzle of Various Difficulty for
the Cookie 39ae7492d8a810cf5e8dc0f9626c9dda773c5a3
The figures above were obtained on a 2.4 GHz single-core Intel i5 processor in a 2013 Apple MacBook Pro. Run times can be halved or quartered with multi-core code, but they would be longer on mobile phone processors, even if those are multi-core as well. With these figures, 18 bits is believed to be a reasonable choice for puzzle level difficulty for all Initiators, and 20 bits is acceptable for specific hosts/prefixes.
上述数据是在2013年苹果MacBook Pro的2.4 GHz单核Intel i5处理器上获得的。使用多核代码可以将运行时间减少一半或四分之一，但在移动电话处理器上运行时间会更长，即使这些处理器也是多核的。根据这些图，18位被认为是所有启动器谜题级难度的合理选择，20位可用于特定主机/前缀。
Using the puzzles mechanism in the IKE_SA_INIT exchange is described in Section 7.1.
第7.1节介绍了在IKE_SA_INIT交换中使用谜题机制。
When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723]. However, the Responder SHOULD NOT serve resumed Initiators exclusively because dropping all IKE_SA_INIT requests would lock out legitimate Initiators that have no resumption ticket. When under attack, the Responder SHOULD require Initiators presenting Session Resumption tickets to pass a return routability check by including the COOKIE notification in the IKE_SESSION_RESUME response message, as described in Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache tickets for a short time to reject reused tickets (Section 4.3.1 of [RFC5723]); therefore, there should be no issue of half-open SAs resulting from replayed IKE_SESSION_RESUME messages.
当响应者受到攻击时，它应该优先选择提供会话恢复票证的先前经过身份验证的对等方[RFC5723]。但是，响应者不应仅为恢复的启动器提供服务，因为删除所有IKE_SA_INIT请求将锁定没有恢复票证的合法启动器。当受到攻击时，响应者应要求出示会话恢复票证的启动器通过返回路由性检查，方法是将COOKIE通知包含在IKE_会话_RESUME响应消息中，如第4.3.2节所述。属于[RFC5723]。注意，响应者应在短时间内缓存票据，以拒绝重复使用的票据（RFC5723第4.3.1节）；因此，不应存在因重播IKE_会话_恢复消息而导致半开SAs的问题。
Several kinds of DoS attacks are possible on servers supported by IKE Session Resumption. See Section 9.3 of [RFC5723] for details.
IKE会话恢复支持的服务器上可能存在多种DoS攻击。详见[RFC5723]第9.3节。
Once the IKE_SA_INIT exchange is finished, the Responder is waiting for the first message of the IKE_AUTH exchange from the Initiator. At this point, the Initiator is not yet authenticated, and this fact allows an attacker to perform an attack, described in Section 3. Instead of sending a properly formed and encrypted IKE_AUTH message, the attacker can just send arbitrary data, forcing the Responder to perform costly CPU operations to compute SK_* keys.
IKE_SA_INIT交换完成后，响应程序将等待来自启动器的IKE_AUTH交换的第一条消息。此时，启动器尚未通过身份验证，这一事实允许攻击者执行第3节中描述的攻击。攻击者可以发送任意数据，而不是发送格式正确且加密的IKE_AUTH消息，从而迫使响应者执行代价高昂的CPU操作来计算SK_*密钥。
If the received IKE_AUTH message failed to decrypt correctly (or failed to pass the Integrity Check Value (ICV) check), then the Responder SHOULD still keep the computed SK_* keys, so that if it happened to be an attack, then an attacker cannot get an advantage of repeating the attack multiple times on a single IKE SA. The Responder can also use puzzles in the IKE_AUTH exchange as described in Section 7.2.
如果接收到的IKE_AUTH消息未能正确解密（或未能通过完整性检查值（ICV）检查），则响应者仍应保留计算出的SK_*密钥，这样，如果碰巧是攻击，则攻击者无法在单个IKE SA上多次重复攻击。响应者还可以在IKE_认证交换中使用谜题，如第7.2节所述。
In IKEv2, each side may use the "Hash and URL" Certificate Encoding to instruct the peer to retrieve certificates from the specified location (see Section 3.6 of [RFC7296] for details). Malicious Initiators can use this feature to mount a DoS attack on the Responder by providing a URL pointing to a large file possibly
在IKEv2中，各方可以使用“哈希和URL”证书编码来指示对等方从指定位置检索证书（有关详细信息，请参阅[RFC7296]的第3.6节）。恶意启动器可通过提供指向大文件的URL，利用此功能在响应程序上发起DoS攻击
containing meaningless bits. While downloading the file, the Responder consumes CPU, memory, and network bandwidth.
包含无意义的位。下载文件时，响应程序会消耗CPU、内存和网络带宽。
To prevent this kind of attack, the Responder should not blindly download the whole file. Instead, it SHOULD first read the initial few bytes, decode the length of the ASN.1 structure from these bytes, and then download no more than the decoded number of bytes. Note that it is always possible to determine the length of ASN.1 structures used in IKEv2, if they are DER-encoded, by analyzing the first few bytes. However, since the content of the file being downloaded can be under the attacker's control, implementations should not blindly trust the decoded length and SHOULD check whether it makes sense before continuing to download the file. Implementations SHOULD also apply a configurable hard limit to the number of pulled bytes and SHOULD provide an ability for an administrator to either completely disable this feature or limit its use to a configurable list of trusted URLs.
为了防止这种攻击，响应者不应该盲目下载整个文件。相反，它应该首先读取最初的几个字节，从这些字节中解码ASN.1结构的长度，然后下载不超过解码字节数的内容。请注意，如果IKEv2中使用的ASN.1结构是DER编码的，则通过分析前几个字节始终可以确定其长度。但是，由于被下载文件的内容可能在攻击者的控制下，因此实现不应盲目信任解码长度，并应在继续下载文件之前检查其是否合理。实现还应该对提取的字节数应用可配置的硬限制，并且应该为管理员提供完全禁用此功能或将其使用限制为可配置的受信任URL列表的能力。
IKE fragmentation described in [RFC7383] allows IKE peers to avoid IP fragmentation of large IKE messages. Attackers can mount several kinds of DoS attacks using IKE fragmentation. See Section 5 of [RFC7383] for details on how to mitigate these attacks.
[RFC7383]中描述的IKE分段允许IKE对等方避免大型IKE消息的IP分段。攻击者可以使用IKE碎片装载多种DoS攻击。有关如何减轻这些攻击的详细信息，请参阅[RFC7383]的第5节。
Once an IKE SA is created, there is usually only a limited amount of IKE messages exchanged. This IKE traffic consists of exchanges aimed to create additional Child SAs, IKE rekeys, IKE deletions, and IKE liveness tests. Some of these exchanges require relatively little resources (like a liveness check), while others may be resource consuming (like creating or rekeying a Child SA with DH exchange).
一旦创建了IKE SA，通常只交换有限数量的IKE消息。此IKE通信由旨在创建附加子SA、IKE密钥、IKE删除和IKE活动性测试的交换组成。其中一些交换需要相对较少的资源（如活动性检查），而另一些交换可能需要消耗资源（如使用DH交换创建或重新键入子SA）。
Since any endpoint can initiate a new exchange, there is a possibility that a peer would initiate too many exchanges that could exhaust host resources. For example, the peer can perform endless continuous Child SA rekeying or create an overwhelming number of Child SAs with the same Traffic Selectors, etc. Such behavior can be caused by broken implementations, misconfiguration, or as an intentional attack. The latter becomes more of a real threat if the peer uses NULL Authentication, as described in [RFC7619]. In this case, the peer remains anonymous, allowing it to escape any responsibility for its behavior. See Section 3 of [RFC7619] for details on how to mitigate attacks when using NULL Authentication.
由于任何端点都可以启动一个新的交换，因此存在一种可能性，即对等端可能会启动太多的交换，从而耗尽主机资源。例如，对等方可以执行无休止的连续子SA密钥更新，或者使用相同的流量选择器创建大量的子SA，等等。此类行为可能是由中断的实现、错误配置或故意攻击造成的。如[RFC7619]所述，如果对等方使用空身份验证，后者将成为更大的真正威胁。在这种情况下，对等方保持匿名，允许其逃避对其行为的任何责任。请参阅[RFC7619]的第3节，了解使用空身份验证时如何减轻攻击的详细信息。
The following recommendations apply especially for NULL-authenticated IKE sessions, but also apply to authenticated IKE sessions, with the difference that in the latter case, the identified peer can be locked out.
以下建议特别适用于经过空身份验证的IKE会话，但也适用于经过身份验证的IKE会话，不同之处在于，在后一种情况下，可以锁定已识别的对等方。
o If the IKEv2 window size is greater than one, peers are able to initiate multiple simultaneous exchanges that increase host resource consumption. Since there is no way in IKEv2 to decrease window size once it has been increased (see Section 2.3 of [RFC7296]), the window size cannot be dynamically adjusted depending on the load. It is NOT RECOMMENDED to allow an IKEv2 window size greater than one when NULL Authentication has been used.
o 如果IKEv2窗口大小大于1，则对等方能够启动多个同时交换，从而增加主机资源消耗。由于在IKEv2中，一旦窗口大小增加，就无法减少窗口大小（见[RFC7296]第2.3节），因此无法根据负载动态调整窗口大小。当使用空身份验证时，不建议允许IKEv2窗口大小大于1。
o If a peer initiates an abusive amount of CREATE_CHILD_SA exchanges to rekey IKE SAs or Child SAs, the Responder SHOULD reply with TEMPORARY_FAILURE notifications indicating the peer must slow down their requests.
o 如果对等方发起滥用数量的CREATE_CHILD_SA交换以重新注册IKE SA或CHILD SA，响应方应回复临时_失败通知，指示对等方必须减慢其请求。
o If a peer creates many Child SAs with the same or overlapping Traffic Selectors, implementations MAY respond with the NO_ADDITIONAL_SAS notification.
o 若一个对等方使用相同或重叠的流量选择器创建了多个子SA，则实现可能会响应无额外的SAs通知。
o If a peer initiates many exchanges of any kind, the Responder MAY introduce an artificial delay before responding to each request message. This delay would decrease the rate the Responder needs to process requests from any particular peer and frees up resources on the Responder that can be used for answering legitimate clients. If the Responder receives retransmissions of the request message during the delay period, the retransmitted messages MUST be silently discarded. The delay must be short enough to avoid legitimate peers deleting the IKE SA due to a timeout. It is believed that a few seconds is enough. Note, however, that even a few seconds may be too long when settings rely on an immediate response to the request message, e.g., for the purposes of quick detection of a dead peer.
o 如果对等方发起许多任何类型的交换，响应方可能在响应每个请求消息之前引入人为延迟。此延迟将降低响应者处理来自任何特定对等方的请求所需的速率，并释放响应者上可用于应答合法客户端的资源。如果响应者在延迟期间接收到请求消息的重新传输，则必须悄悄地丢弃重新传输的消息。延迟必须足够短，以避免合法对等方由于超时而删除IKE SA。人们相信几秒钟就足够了。然而，请注意，当设置依赖于对请求消息的即时响应时，即使是几秒钟也可能太长，例如，为了快速检测死点。
o If these countermeasures are inefficient, implementations MAY delete the IKE SA with an offending peer by sending Delete Payload.
o 如果这些对策效率低下，则实现可能会通过发送delete有效负载来删除具有违规对等方的IKE SA。
In IKE, a client can request various configuration attributes from the server. Most often, these attributes include internal IP addresses. Malicious clients can try to exhaust a server's IP address pool by continuously requesting a large number of internal addresses. Server implementations SHOULD limit the number of IP
在IKE中，客户机可以从服务器请求各种配置属性。通常，这些属性包括内部IP地址。恶意客户端可以通过连续请求大量内部地址来尝试耗尽服务器的IP地址池。服务器实现应该限制IP地址的数量
addresses allocated to any particular client. Note, this is not possible with clients using NULL Authentication, since their identity cannot be verified.
分配给任何特定客户机的地址。注意，对于使用空身份验证的客户端，这是不可能的，因为它们的身份无法验证。
This section outlines a plan for defending a Responder from a DDoS attack based on the techniques described earlier. The numbers given here are not normative, and their purpose is to illustrate the configurable parameters needed for surviving DDoS attacks.
本节概述了基于前面描述的技术防御响应者DDoS攻击的计划。此处给出的数字不是标准数字，其目的是说明DDoS攻击幸存所需的可配置参数。
Implementations are deployed in different environments, so it is RECOMMENDED that the parameters be settable. For example, most commercial products are required to undergo benchmarking where the IKE SA establishment rate is measured. Benchmarking is indistinguishable from a DoS attack, and the defenses described in this document may defeat the benchmark by causing exchanges to fail or to take a long time to complete. Parameters SHOULD be tunable to allow for benchmarking (if only by turning DDoS protection off).
实现部署在不同的环境中，因此建议设置参数。例如，在衡量IKE SA建立率的情况下，大多数商业产品都需要进行基准测试。基准测试与DoS攻击无法区分，本文档中描述的防御可能会导致交换失败或需要很长时间才能完成，从而使基准测试失败。参数应可调，以便进行基准测试（如果仅通过关闭DDoS保护）。
Since all countermeasures may cause delays and additional work for the Initiators, they SHOULD NOT be deployed unless an attack is likely to be in progress. To minimize the burden imposed on Initiators, the Responder should monitor incoming IKE requests for two scenarios:
由于所有反措施都可能导致延迟和启动器的额外工作，因此不应部署反措施，除非可能正在进行攻击。为了最大限度地减少对启动器施加的负担，响应者应针对两种情况监控传入的IKE请求：
1. A general DDoS attack. Such an attack is indicated by a high number of concurrent half-open SAs, a high rate of failed IKE_AUTH exchanges, or a combination of both. For example, consider a Responder that has 10,000 distinct peers of which at peak, 7,500 concurrently have VPN tunnels. At the start of peak time, 600 peers might establish tunnels within any given minute, and tunnel establishment (both IKE_SA_INIT and IKE_AUTH) takes anywhere from 0.5 to 2 seconds. For this Responder, we expect there to be less than 20 concurrent half-open SAs, so having 100 concurrent half-open SAs can be interpreted as an indication of an attack. Similarly, IKE_AUTH request decryption failures should never happen. Supposing that the tunnels are established using Extensible Authentication Protocol (EAP) (see Section 2.16 of [RFC7296]), users may be expected to enter a wrong password about 20% of the time. So we'd expect 125 wrong password failures a minute. If we get IKE_AUTH decryption failures from multiple sources more than once per second, or EAP failures more than 300 times per minute, this can also be an indication of a DDoS attack.
1. 一般DDoS攻击。此类攻击表现为并发半开放SA数量多、IKE_身份验证交换失败率高或两者兼而有之。例如，考虑一个响应者，它有10000个不同的对等体，它们在峰值处，7500个同时具有VPN隧道。在高峰时间开始时，600个对等方可能在任何给定的分钟内建立隧道，而隧道建立（IKE_SA_INIT和IKE_AUTH）需要0.5到2秒的时间。对于该响应者，我们预计并发半开放SA少于20个，因此有100个并发半开放SA可被解释为攻击的迹象。类似地，IKE_AUTH请求解密失败也不应该发生。假设隧道是使用可扩展认证协议（EAP）建立的（见[RFC7296]第2.16节），用户可能会在大约20%的时间内输入错误的密码。因此，我们预计每分钟会有125次密码错误。如果我们每秒从多个来源获得超过一次IKE_身份验证解密失败，或者EAP失败超过每分钟300次，这也可能表示DDoS攻击。
2. An attack from a particular IP address or prefix. Such an attack is indicated by an inordinate amount of half-open SAs from a specific IP address or prefix, or an inordinate amount of IKE_AUTH failures. A DDoS attack may be viewed as multiple such attacks. If these are mitigated successfully, there will not be a need to enact countermeasures on all Initiators. For example, measures might be 5 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures within a minute.
2. 来自特定IP地址或前缀的攻击。此类攻击由来自特定IP地址或前缀的大量半开放SA或大量IKE_AUTH失败表示。DDoS攻击可被视为多个此类攻击。如果成功缓解了这些问题，则无需对所有发起者采取反措施。例如，测量值可能是5个并发半开放SAs、1个解密失败或一分钟内10个EAP失败。
Note that using countermeasures against an attack from a particular IP address may be enough to avoid the overload on the half-open SA database. In this case, the number of failed IKE_AUTH exchanges will never exceed the threshold of attack detection.
请注意，使用针对特定IP地址的攻击的对策可能足以避免半开放SA数据库上的过载。在这种情况下，失败的IKE_身份验证交换的数量永远不会超过攻击检测的阈值。
When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point, the only defensive measure is to monitor the number of half-open SAs, and set a soft limit per peer IP or prefix. The soft limit can be set to 3-5. If the puzzles are used, the puzzle difficulty SHOULD be set to such a level (number of zero bits) that all legitimate clients can handle it without degraded user experience.
当没有一般DDoS攻击时，建议不要使用cookie或拼图。此时，唯一的防御措施是监视半开放SA的数量，并为每个对等IP或前缀设置软限制。软限制可以设置为3-5。如果使用了拼图，则拼图难度应设置为所有合法客户端都可以在不降低用户体验的情况下处理的水平（零位数）。
As soon as any kind of attack is detected, either a lot of initiations from multiple sources or a lot of initiations from a few sources, it is best to begin by requiring stateless cookies from all Initiators. This will mitigate attacks based on IP address spoofing and help avoid the need to impose a greater burden in the form of puzzles on the general population of Initiators. This makes the per-node or per-prefix soft limit more effective.
一旦检测到任何类型的攻击，无论是来自多个来源的大量发起还是来自少数来源的大量发起，最好从要求所有发起方提供无状态cookie开始。这将减轻基于IP地址欺骗的攻击，并有助于避免以谜题的形式对启动器的一般人群施加更大的负担。这使得每节点或每前缀软限制更加有效。
When cookies are activated for all requests and the attacker is still managing to consume too many resources, the Responder MAY start to use puzzles for these requests or increase the difficulty of puzzles imposed on IKE_SA_INIT requests coming from suspicious nodes/ prefixes. This should still be doable by all legitimate peers, but the use of puzzles at a higher difficulty may degrade the user experience, for example, by taking up to 10 seconds to solve the puzzle.
当对所有请求激活cookie且攻击者仍在设法消耗过多资源时，响应者可能会开始对这些请求使用谜语，或增加对来自可疑节点/前缀的IKE_SA_INIT请求施加谜语的难度。这对于所有合法的对等方来说仍然是可行的，但是使用难度更高的谜题可能会降低用户体验，例如，解决谜题最多需要10秒。
If the load on the Responder is still too great, and there are many nodes causing multiple half-open SAs or IKE_AUTH failures, the Responder MAY impose hard limits on those nodes.
如果响应程序上的负载仍然太大，并且有许多节点导致多个半开放SAs或IKE_AUTH故障，则响应程序可能会对这些节点施加硬限制。
If it turns out that the attack is very widespread and the hard caps are not solving the issue, a puzzle MAY be imposed on all Initiators. Note that this is the last step, and the Responder should avoid this if possible.
如果事实证明攻击非常普遍，且硬上限无法解决问题，则可能会对所有发起人造成困惑。请注意，这是最后一步，如果可能，响应者应该避免这样做。
This section describes how the puzzle mechanism is used in IKEv2. It is organized as follows. Section 7.1 describes using puzzles in the IKE_SA_INIT exchange and Section 7.2 describes using puzzles in the IKE_AUTH exchange. Both sections are divided into subsections describing how puzzles should be presented, solved, and processed by the Initiator and the Responder.
本节介绍如何在IKEv2中使用拼图机制。它的组织如下。第7.1节描述了在IKE_SA_INIT交换中使用拼图，第7.2节描述了在IKE_AUTH交换中使用拼图。这两部分都分为几个小节，描述了发起者和响应者应该如何呈现、解决和处理谜题。
The IKE Initiator indicates the desire to create a new IKE SA by sending an IKE_SA_INIT request message. The message may optionally contain a COOKIE notification if this is a repeated request performed after the Responder's demand to return a cookie.
IKE启动器通过发送IKE_SA_INIT请求消息来表示创建新IKE SA的愿望。如果这是响应者要求返回COOKIE后执行的重复请求，则消息可以选择性地包含COOKIE通知。
HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->
HDR, [N(COOKIE),] SA, KE, Ni, [V+][N+] -->
Figure 1: Initial IKE_SA_INIT Request
图1：初始IKE_SA_初始化请求
According to the plan, described in Section 6, the IKE Responder monitors incoming requests to detect whether it is under attack. If the Responder learns that a DoS or DDoS attack is likely to be in progress, then its actions depend on the volume of the attack. If the volume is moderate, then the Responder requests the Initiator to return a cookie. If the volume is high to such an extent that puzzles need to be used for defense, then the Responder requests the Initiator to solve a puzzle.
根据第6节中描述的计划，IKE响应程序监视传入的请求，以检测其是否受到攻击。如果响应者了解到DoS或DDoS攻击可能正在进行，则其行动取决于攻击量。如果卷大小适中，则响应程序请求启动器返回cookie。如果音量太大，以至于需要将谜题用于防御，则响应者会请求发起者解决谜题。
The Responder MAY choose to process some fraction of IKE_SA_INIT requests without presenting a puzzle while being under attack to allow legacy clients, that don't support puzzles, to have a chance to be served. The decision whether to process any particular request must be probabilistic, with the probability depending on the Responder's load (i.e., on the volume of attack). The requests that don't contain the COOKIE notification MUST NOT participate in this lottery. In other words, the Responder must first perform a return routability check before allowing any legacy client to be served if it is under attack. See Section 7.1.4 for details.
响应者可以选择处理IKE_SA_INIT请求的一部分，而不在受到攻击时呈现谜题，以允许不支持谜题的遗留客户端有机会获得服务。是否处理任何特定请求的决定必须是概率性的，概率取决于响应者的负载（即，攻击量）。不包含COOKIE通知的请求不得参与此抽签。换句话说，响应者必须首先执行返回可路由性检查，然后才允许在任何遗留客户端受到攻击时为其提供服务。详见第7.1.4节。
If the Responder makes a decision to use puzzles, then it includes two notifications in its response message -- the COOKIE notification and the PUZZLE notification. Note that the PUZZLE notification MUST always be accompanied with the COOKIE notification, since the content of the COOKIE notification is used as an input data when solving the puzzle. The format of the PUZZLE notification is described in Section 8.1.
如果响应者决定使用谜题，那么它在响应消息中包含两个通知——COOKIE通知和谜题通知。请注意，谜题通知必须始终伴随COOKIE通知，因为在解决谜题时，COOKIE通知的内容被用作输入数据。拼图通知的格式见第8.1节。
<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
<-- HDR, N(COOKIE), N(PUZZLE), [V+][N+]
Figure 2: IKE_SA_INIT Response Containing Puzzle
图2:IKE_SA_INIT包含谜题的响应
The presence of these notifications in an IKE_SA_INIT response message indicates to the Initiator that it should solve the puzzle to have a better chance to be served.
IKE_SA_INIT响应消息中存在这些通知，这向发起方表明它应该解决这个难题，以便有更好的机会得到服务。
The PUZZLE notification contains the difficulty level of the puzzle -- the minimum number of trailing zero bits that the result of PRF must contain. In diverse environments, it is nearly impossible for the Responder to set any specific difficulty level that will result in roughly the same amount of work for all Initiators, because computation power of different Initiators may vary by an order of magnitude, or even more. The Responder may set the difficulty level to 0, meaning that the Initiator is requested to spend as much power to solve a puzzle as it can afford. In this case, no specific value of ZBC is required from the Initiator; however, the larger the ZBC that the Initiator is able to get, the better the chance is that it will be served by the Responder. In diverse environments, it is RECOMMENDED that the Initiator set the difficulty level to 0, unless the attack volume is very high.
拼图通知包含拼图的难度级别——PRF结果必须包含的最小尾随零位数。在不同的环境中，响应者几乎不可能设置任何特定的难度级别，这将导致所有启动器的工作量大致相同，因为不同启动器的计算能力可能会相差一个数量级，甚至更多。响应者可以将难度级别设置为0，这意味着发起者需要花费尽可能多的精力来解决难题。在这种情况下，不需要发起者提供ZBC的特定值；然而，发起方能够获得的ZBC越大，响应方提供服务的机会就越大。在不同的环境中，建议启动器将难度级别设置为0，除非攻击量非常大。
If the Responder sets a non-zero difficulty level, then the level SHOULD be determined by analyzing the volume of the attack. The Responder MAY set different difficulty levels to different requests depending on the IP address the request has come from.
如果响应者设置了非零难度等级，则应通过分析攻击量来确定该等级。响应者可以根据请求来自的IP地址为不同的请求设置不同的难度级别。
The PUZZLE notification also contains an identifier of the algorithm that is used by the Initiator to compute the puzzle.
谜题通知还包含启动器用于计算谜题的算法标识符。
Cryptographic algorithm agility is considered an important feature for modern protocols [RFC7696]. Algorithm agility ensures that a protocol doesn't rely on a single built-in set of cryptographic algorithms but has a means to replace one set with another and negotiate new algorithms with the peer. IKEv2 fully supports cryptographic algorithm agility for its core operations.
密码算法的灵活性被认为是现代协议的一个重要特征[RFC7696]。算法敏捷性确保协议不依赖于单个内置的密码算法集，而是能够用一组密码算法替换另一组密码算法，并与对等方协商新算法。IKEv2完全支持其核心操作的加密算法灵活性。
To support crypto-agility in case of puzzles, the algorithm that is used to compute a puzzle needs to be negotiated during the IKE_SA_INIT exchange. The negotiation is performed as follows. The initial request message from the Initiator contains an SA payload containing a list of transforms of different types. In that manner, the Initiator asserts that it supports all transforms from this list and can use any of them in the IKE SA being established. The Responder parses the received SA payload and finds mutually supported transforms of type PRF. The Responder selects the preferred PRF from the list of mutually supported ones and includes it into the PUZZLE notification. There is no requirement that the PRF selected for puzzles be the same as the PRF that is negotiated later for use in core IKE SA crypto operations. If there are no mutually supported PRFs, then IKE SA negotiation will fail anyway and there is no reason to return a puzzle. In this case, the Responder returns a NO_PROPOSAL_CHOSEN notification. Note that PRF is a mandatory transform type for IKE SA (see Sections 3.3.2 and 3.3.3 of [RFC7296]), and at least one transform of this type is always present in the SA payload in an IKE_SA_INIT request message.
为了在出现谜题时支持加密灵活性，需要在IKE_SA_INIT交换期间协商用于计算谜题的算法。谈判过程如下。来自启动器的初始请求消息包含SA有效负载，其中包含不同类型的转换列表。以这种方式，发起方声明它支持此列表中的所有转换，并且可以在正在建立的IKE SA中使用其中的任何转换。响应程序解析接收到的SA有效负载，并找到相互支持的PRF类型的转换。响应者从相互支持的PRF列表中选择首选PRF，并将其包括在拼图通知中。不要求为谜题选择的PRF与稍后协商用于核心IKE SA加密操作的PRF相同。如果没有相互支持的PRF，那么IKE SA协商无论如何都会失败，并且没有理由返回谜题。在这种情况下，响应者返回一个NO_PROPOSAL_Selected通知。请注意，PRF是IKE SA的强制转换类型（请参见[RFC7296]的第3.3.2和3.3.3节），并且IKE_SA_INIT请求消息中的SA有效负载中始终存在至少一种此类型的转换。
If the Responder supports puzzles, then a cookie should be computed in such a manner that the Responder is able to learn some important information from the sole cookie, when it is later returned back by the Initiator. In particular, the Responder SHOULD be able to learn the following information:
如果响应者支持谜题，那么cookie的计算方式应确保响应者能够从唯一的cookie中学习一些重要信息，稍后启动器会返回这些信息。特别是，响应者应能够了解以下信息：
o Whether the puzzle was given to the Initiator or only the cookie was requested.
o 是将谜题提交给发起人还是仅请求cookie。
o The difficulty level of the puzzle given to the Initiator.
o 给发起者的谜题难度。
o The number of consecutive puzzles given to the Initiator.
o 给发起者的连续谜题数。
o The amount of time the Initiator spent to solve the puzzles. This can be calculated if the cookie is timestamped.
o 发起者解决谜题所花费的时间。如果cookie带有时间戳，则可以计算此值。
This information helps the Responder to make a decision whether to serve this request or demand more work from the Initiator.
此信息有助于响应者做出决定，是服务于此请求，还是要求发起者完成更多工作。
One possible approach to get this information is to encode it in the cookie. The format of such encoding is an implementation detail of the Responder, as the cookie would remain an opaque block of data to the Initiator. If this information is encoded in the cookie, then the Responder MUST make it integrity protected, so that any intended or accidental alteration of this information in the returned cookie is detectable. So, the cookie would be generated as:
获取此信息的一种可能方法是将其编码到cookie中。这种编码的格式是响应程序的一个实现细节，因为cookie对于启动器来说仍然是一个不透明的数据块。如果此信息编码在cookie中，则响应者必须对其进行完整性保护，以便可以检测到返回cookie中此信息的任何有意或意外更改。因此，cookie将生成为：
Cookie = <VersionIDofSecret> | <AdditionalInfo> |
Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
Cookie = <VersionIDofSecret> | <AdditionalInfo> |
Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)
Note that according to Section 2.6 of [RFC7296], the size of the cookie cannot exceed 64 bytes.
请注意，根据[RFC7296]的第2.6节，cookie的大小不能超过64字节。
Alternatively, the Responder may generate a cookie as suggested in Section 2.6 of [RFC7296], but associate the additional information, using local storage identified with the particular version of the secret. In this case, the Responder should have different secrets for every combination of difficulty level and number of consecutive puzzles, and should change the secrets periodically, keeping a few previous versions, to be able to calculate how long ago a cookie was generated.
或者，响应者可以按照[RFC7296]第2.6节中的建议生成cookie，但使用与特定版本的机密标识的本地存储来关联附加信息。在这种情况下，响应者对于每个难度级别和连续谜题数量的组合都应该有不同的秘密，并且应该定期更改秘密，保留一些以前的版本，以便能够计算cookie生成的时间。
The Responder may also combine these approaches. This document doesn't mandate how the Responder learns this information from a cookie.
响应者也可以结合这些方法。本文档不强制要求响应者如何从cookie中学习此信息。
When selecting cookie generation, algorithm implementations MUST ensure that an attacker gains no or insignificant benefit from reusing puzzle solutions in several requests. See Section 10 for details.
在选择cookie生成时，算法实现必须确保攻击者不会从多次请求中重用谜题解决方案中获得任何或微不足道的好处。详见第10节。
If the Initiator receives a puzzle but it doesn't support puzzles, then it will ignore the PUZZLE notification as an unrecognized status notification (in accordance with Section 3.10.1 of [RFC7296]). The Initiator MAY ignore the PUZZLE notification if it is not willing to spend resources to solve the puzzle of the requested difficulty, even if it supports puzzles. In both cases, the Initiator acts as described in Section 2.6 of [RFC7296] -- it restarts the request and includes the received COOKIE notification in it. The Responder
如果发起者接收到一个谜题，但它不支持谜题，那么它将忽略谜题通知作为一个未识别的状态通知（根据[RFC7296]第3.10.1节）。如果发起者不愿意花费资源来解决请求难度的谜题，即使它支持谜题，也可以忽略谜题通知。在这两种情况下，发起者都按照[RFC7296]第2.6节中的描述行事——它重新启动请求并将收到的COOKIE通知包含在其中。响应者
should be able to distinguish the situation when it just requested a cookie from the situation where the puzzle was given to the Initiator, but the Initiator for some reason ignored it.
应该能够区分仅请求cookie时的情况和将谜题提供给发起方但发起方出于某种原因忽略它的情况。
If the received message contains a PUZZLE notification and doesn't contain a COOKIE notification, then this message is malformed because it requests to solve the puzzle but doesn't provide enough information to allow the puzzle to be solved. In this case, the Initiator MUST ignore the received message and continue to wait until either a valid PUZZLE notification is received or the retransmission timer fires. If it fails to receive a valid message after several retransmissions of IKE_SA_INIT requests, then this means that something is wrong and the IKE SA cannot be established.
如果收到的消息包含谜题通知，但不包含COOKIE通知，则此消息的格式不正确，因为它请求解决谜题，但没有提供足够的信息来解决谜题。在这种情况下，发起者必须忽略接收到的消息，并继续等待，直到收到有效的拼图通知或重传计时器触发。如果在多次重传IKE_SA_INIT请求后，它未能接收到有效消息，则这意味着出现了问题，IKE SA无法建立。
If the Initiator supports puzzles and is ready to solve them, then it tries to solve the given puzzle. After the puzzle is solved, the Initiator restarts the request and returns back to the Responder the puzzle solution in a new payload called a Puzzle Solution (PS) payload (see Section 8.2) along with the received COOKIE notification.
如果发起者支持谜题并准备解决它们，那么它将尝试解决给定的谜题。谜题解决后，发起者重新启动请求，并将称为谜题解决方案（PS）有效载荷的新有效载荷（见第8.2节）中的谜题解决方案以及收到的COOKIE通知返回给响应者。
HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+] -->
Figure 3: IKE_SA_INIT Request Containing Puzzle Solution
图3：包含谜题解决方案的IKE_SA_INIT请求
General principles of constructing puzzles in IKEv2 are described in Section 4.4. They can be summarized as follows: given unpredictable string S and PRF, find N different keys Ki (where i=[1..N]) for that PRF so that the result of PRF(Ki,S) has at least the specified number of trailing zero bits. This specification requires that the puzzle solution contains 4 different keys (i.e., N=4).
第4.4节描述了在IKEv2中构建谜题的一般原则。它们可以总结如下：给定不可预测的字符串S和PRF，为该PRF找到N个不同的键Ki（其中i=[1..N]），以便PRF（Ki，S）的结果至少具有指定数量的尾随零位。本规范要求拼图解决方案包含4个不同的键（即N=4）。
In the IKE_SA_INIT exchange, it is the cookie that plays the role of
unpredictable string S. In other words, in the IKE_SA_INIT, the task
for the IKE Initiator is to find the four different, equal-sized keys
Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)
where i = [1..4] has a sufficient number of trailing zero bits. Only
the content of the COOKIE notification is used in puzzle calculation,
i.e., the header of the Notify payload is not included.
In the IKE_SA_INIT exchange, it is the cookie that plays the role of
unpredictable string S. In other words, in the IKE_SA_INIT, the task
for the IKE Initiator is to find the four different, equal-sized keys
Ki for the agreed upon PRF such that each result of PRF(Ki,cookie)
where i = [1..4] has a sufficient number of trailing zero bits. Only
the content of the COOKIE notification is used in puzzle calculation,
i.e., the header of the Notify payload is not included.
Note that puzzles in the IKE_AUTH exchange are computed differently than in the IKE_SA_INIT_EXCHANGE. See Section 7.2.3 for details.
请注意，IKE_AUTH交换中的谜题计算方式与IKE_SA_INIT_交换中的不同。详见第7.2.3节。
The received request must at least contain a COOKIE notification. Otherwise, it is an initial request and in this case, it MUST be processed according to Section 7.1. First, the cookie MUST be checked for validity. If the cookie is invalid, then the request is treated as initial and is processed according to Section 7.1. It is RECOMMENDED that a new cookie is requested in this case.
收到的请求必须至少包含COOKIE通知。否则，这是一个初始请求，在这种情况下，必须根据第7.1节进行处理。首先，必须检查cookie的有效性。如果cookie无效，则请求将被视为初始请求，并根据第7.1节进行处理。在这种情况下，建议请求一个新的cookie。
If the cookie is valid, then some important information is learned from it or from local state based on the identifier of the cookie's secret (see Section 7.1.1.3 for details). This information helps the Responder to sort out incoming requests, giving more priority to those that were created by spending more of the Initiator's resources.
如果cookie是有效的，则根据cookie的机密标识符从cookie或本地状态中学习一些重要信息（有关详细信息，请参阅第7.1.1.3节）。此信息有助于响应者对传入的请求进行分类，从而为那些花费启动器更多资源而创建的请求提供更高的优先级。
First, the Responder determines if it requested only a cookie or presented a puzzle to the Initiator. If no puzzle was given, this means that at the time the Responder requested a cookie, it didn't detect the DoS or DDoS attack, or the attack volume was low. In this case, the received request message must not contain the PS payload, and this payload MUST be ignored if the message contains a PS payload for any reason. Since no puzzle was given, the Responder marks the request with the lowest priority since the Initiator spent little resources creating it.
首先，响应者确定它是否只请求了一个cookie，还是向发起人呈现了一个谜题。如果没有给出谜题，这意味着在响应者请求cookie时，它没有检测到DoS或DDoS攻击，或者攻击量很低。在这种情况下，收到的请求消息不得包含PS有效负载，如果消息出于任何原因包含PS有效负载，则必须忽略此有效负载。由于没有给出任何谜题，响应者将请求标记为最低优先级，因为发起人几乎没有花费资源来创建它。
If the Responder learns from the cookie that the puzzle was given to the Initiator, then it looks for the PS payload to determine whether its request to solve the puzzle was honored or not. If the incoming message doesn't contain a PS payload, this means that the Initiator either doesn't support puzzles or doesn't want to deal with them. In either case, the request is marked with the lowest priority since the Initiator spent little resources creating it.
如果响应者从cookie中得知谜题已交给发起方，则它将查找PS有效负载以确定其解决谜题的请求是否得到满足。如果传入消息不包含PS负载，这意味着发起者不支持谜题或不想处理谜题。在这两种情况下，请求都被标记为最低优先级，因为发起方几乎没有花费资源来创建它。
If a PS payload is found in the message, then the Responder MUST verify the puzzle solution that it contains. The solution is interpreted as four different keys. The result of using each of them in the PRF (as described in Section 7.1.3) must contain at least the requested number of trailing zero bits. The Responder MUST check all of the four returned keys.
如果在消息中找到PS有效负载，则响应者必须验证其包含的谜题解决方案。该解决方案被解释为四个不同的键。在PRF中使用它们的结果（如第7.1.3节所述）必须至少包含请求数量的尾随零位。响应者必须检查所有四个返回的密钥。
If any checked result contains fewer bits than were requested, this means that the Initiator spent less resources than expected by the Responder. This request is marked with the lowest priority.
如果任何检查结果包含的比特数少于请求的比特数，这意味着启动器花费的资源少于响应程序预期的资源。此请求标记为最低优先级。
If the Initiator provided the solution to the puzzle satisfying the requested difficulty level, or if the Responder didn't indicate any particular difficulty level (by setting the ZBC to 0) and the
如果发起者提供了满足要求难度的谜题解决方案，或者如果响应者没有指明任何特定难度（通过将ZBC设置为0），则
Initiator was free to select any difficulty level it can afford, then the priority of the request is calculated based on the following considerations:
发起人可以自由选择其能够承受的任何难度级别，然后根据以下考虑因素计算请求的优先级：
o The Responder MUST take the smallest number of trailing zero bits among the checked results and count it as the number of zero bits the Initiator solved for.
o 响应程序必须获取检查结果中的最小尾随零位数，并将其作为启动器解决的零位数。
o The higher number of zero bits the Initiator provides, the higher priority its request should receive.
o 启动器提供的零位数越高，其请求应接收的优先级越高。
o The more consecutive puzzles the Initiator solved, the higher priority it should receive.
o 发起者解决的连续难题越多，其应获得的优先级越高。
o The more time the Initiator spent solving the puzzles, the higher priority it should receive.
o 发起者解决谜题的时间越长，其应获得的优先级越高。
After the priority of the request is determined, the final decision whether to serve it or not is made.
在确定请求的优先级后，将做出是否送达请求的最终决定。
The Responder decides what to do with the request based on the request's priority and the Responder's current load. There are three possible actions:
响应者根据请求的优先级和响应者的当前负载决定如何处理请求。有三种可能的行动：
o Accept request.
o 接受请求。
o Reject request.
o 拒绝请求。
o Demand more work from the Initiator by giving it a new puzzle.
o 通过给发起者一个新的谜题，要求发起者做更多的工作。
The Responder SHOULD accept an incoming request if its priority is high -- this means that the Initiator spent quite a lot of resources. The Responder MAY also accept some low-priority requests where the Initiators don't support puzzles. The percentage of accepted legacy requests depends on the Responder's current load.
如果传入请求的优先级很高，响应程序应该接受该请求——这意味着发起程序花费了大量资源。响应者也可以接受一些低优先级的请求，其中发起者不支持谜题。接受的旧请求的百分比取决于响应者的当前负载。
If the Initiator solved the puzzle, but didn't spend much resources for it (the selected puzzle difficulty level appeared to be low and the Initiator solved it quickly), then the Responder SHOULD give it another puzzle. The more puzzles the Initiator solves the higher its chances are to be served.
如果发起者解决了谜题，但没有为此花费太多资源（选定的谜题难度较低，发起者很快就解决了），那么响应者应该给它另一个谜题。发起者解决的谜题越多，获得服务的机会就越高。
The details of how the Responder makes a decision for any particular request are implementation dependent. The Responder can collect all of the incoming requests for some short period of time, sort them out based on their priority, calculate the number of available memory
响应者如何对任何特定请求做出决策的细节取决于实现。响应者可以在短时间内收集所有传入请求，根据优先级对它们进行排序，计算可用内存的数量
slots for half-open IKE SAs, and then serve that number of requests from the head of the sorted list. The remainder of requests can be either discarded or responded to with new puzzle requests.
为半开放的IKE SA分配插槽，然后从排序列表的开头提供该数量的请求。其余的请求可以被丢弃，也可以用新的益智请求来响应。
Alternatively, the Responder may decide whether to accept every incoming request with some kind of lottery, taking into account its priority and the available resources.
或者，响应者可以考虑到每个传入请求的优先级和可用资源，决定是否以某种抽签方式接受每个传入请求。
Once the IKE_SA_INIT exchange is completed, the Responder has created a state and is waiting for the first message of the IKE_AUTH exchange from the Initiator. At this point, the Initiator has already passed the return routability check and has proved that it has performed some work to complete the IKE_SA_INIT exchange. However, the Initiator is not yet authenticated, and this allows a malicious Initiator to perform an attack, as described in Section 3. Unlike a DoS attack in the IKE_SA_INIT exchange, which is targeted on the Responder's memory resources, the goal of this attack is to exhaust a Responder's CPU power. The attack is performed by sending the first IKE_AUTH message containing arbitrary data. This costs nothing to the Initiator, but the Responder has to perform relatively costly operations when computing the DH shared secret and deriving SK_* keys to be able to verify authenticity of the message. If the Responder doesn't keep the computed keys after an unsuccessful verification of the IKE_AUTH message, then the attack can be repeated several times on the same IKE SA.
IKE_SA_INIT交换完成后，响应程序已创建状态，并等待来自发起程序的IKE_AUTH交换的第一条消息。此时，发起者已经通过了返回可路由性检查，并且已经证明它已经执行了一些工作来完成IKE_SA_INIT交换。但是，启动器尚未通过身份验证，这允许恶意启动器执行攻击，如第3节所述。与IKE_SA_INIT exchange中针对响应者内存资源的DoS攻击不同，此攻击的目标是耗尽响应者的CPU资源。通过发送包含任意数据的第一条IKE_AUTH消息来执行攻击。这对发起者来说没有任何成本，但是响应者在计算DH共享机密和导出SK_*密钥时必须执行相对昂贵的操作，以便能够验证消息的真实性。如果响应者在IKE_AUTH消息验证失败后没有保留计算出的密钥，那么攻击可能会在同一IKE SA上重复数次。
The Responder can use puzzles to make this attack more costly for the Initiator. The idea is that the Responder includes a puzzle in the IKE_SA_INIT response message and the Initiator includes a puzzle solution in the first IKE_AUTH request message outside the Encrypted payload, so that the Responder is able to verify a puzzle solution before computing the DH shared secret.
响应者可以使用谜题使发起方的攻击成本更高。其思想是，响应者在IKE_SA_INIT响应消息中包括谜题，并且发起者在加密有效载荷之外的第一个IKE_AUTH请求消息中包括谜题解决方案，以便响应者能够在计算DH共享秘密之前验证谜题解决方案。
The Responder constantly monitors the amount of the half-open IKE SA states that receive IKE_AUTH messages that cannot be decrypted due to integrity check failures. If the percentage of such states is high and it takes an essential fraction of the Responder's computing power to calculate keys for them, then the Responder may assume that it is under attack and SHOULD use puzzles to make it harder for attackers.
响应程序不断监视接收由于完整性检查失败而无法解密的IKE_AUTH消息的半开放IKE SA状态的数量。如果此类状态的百分比很高，并且需要响应者计算能力的一小部分来计算它们的密钥，那么响应者可能会认为它受到了攻击，并且应该使用谜题使攻击者更难理解。
The Responder requests the Initiator to solve a puzzle by including the PUZZLE notification in the IKE_SA_INIT response message. The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a puzzle has been previously presented and solved in the preceding IKE_SA_INIT exchange.
响应者通过在IKE_SA_INIT响应消息中包含谜题通知来请求发起方解决谜题。响应者不得在IKE_认证交换中使用谜题，除非之前在IKE_SA_初始交换中已经呈现并解决了谜题。
<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]
<-- HDR, SA, KE, Nr, N(PUZZLE), [V+][N+]
Figure 4: IKE_SA_INIT Response Containing IKE_AUTH Puzzle
图4:IKE_SA_INIT响应包含IKE_AUTH谜题
The difficulty level of the puzzle in the IKE_AUTH exchange should be chosen so that the Initiator would spend more time to solve the puzzle than the Responder to compute the DH shared secret and the keys needed to decrypt and verify the IKE_AUTH request message. On the other hand, the difficulty level should not be too high, otherwise legitimate clients will experience an additional delay while establishing the IKE SA.
应选择IKE_身份验证交换中谜题的难度级别，以便发起方比响应方花费更多的时间来解决谜题，以计算DH共享秘密以及解密和验证IKE_身份验证请求消息所需的密钥。另一方面，难度不应太高，否则合法客户端在建立IKE SA时将经历额外的延迟。
Note that since puzzles in the IKE_AUTH exchange are only allowed to be used if they were used in the preceding IKE_SA_INIT exchange, the Responder would be able to roughly estimate the computational power of the Initiator and select the difficulty level accordingly. Unlike puzzles in the IKE_SA_INIT, the requested difficulty level for IKE_AUTH puzzles MUST NOT be 0. In other words, the Responder must always set a specific difficulty level and must not let the Initiator choose it on its own.
请注意，由于IKE_验证交换中的谜题仅在之前的IKE_SA_INIT交换中使用时才允许使用，因此响应者将能够粗略估计启动器的计算能力并相应地选择难度级别。与IKE_SA_INIT中的谜题不同，IKE_AUTH谜题请求的难度级别不得为0。换句话说，响应者必须始终设置一个特定的难度级别，并且不能让发起者自己选择。
The algorithm for the puzzle is selected as described in Section 7.1.1.2. There is no requirement that the algorithm for the puzzle in the IKE_SA INIT exchange be the same as the algorithm for the puzzle in the IKE_AUTH exchange; however, it is expected that in most cases they will be the same.
如第7.1.1.2节所述，选择谜题的算法。IKE_SA INIT交换中的谜题算法不要求与IKE_AUTH交换中的谜题算法相同；然而，预计在大多数情况下，它们将是相同的。
If the IKE_SA_INIT regular response message (i.e., the message containing SA, KE, NONCE payloads) contains the PUZZLE notification and the Initiator supports puzzles, it MUST solve the puzzle. Note that puzzle construction in the IKE_AUTH exchange differs from the puzzle construction in the IKE_SA_INIT exchange and is described in Section 7.2.3. Once the puzzle is solved, the Initiator sends the IKE_AUTH request message containing the PS payload.
如果IKE_SA_INIT常规响应消息（即，包含SA、KE、NONCE有效负载的消息）包含谜题通知，并且启动器支持谜题，则它必须解决谜题。请注意，IKE_AUTH exchange中的拼图构造不同于IKE_SA_INIT exchange中的拼图构造，请参见第7.2.3节。谜题解决后，启动器发送包含PS有效负载的IKE_AUTH请求消息。
HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SA, TSi, TSr} -->
HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SA, TSi, TSr} -->
Figure 5: IKE_AUTH Request Containing IKE_AUTH Puzzle Solution
图5：包含IKE_AUTH谜题解决方案的IKE_AUTH请求
The PS payload MUST be placed outside the Encrypted payload, so that the Responder is able to verify the puzzle before calculating the DH shared secret and the SK_* keys.
PS有效载荷必须置于加密有效载荷之外，以便响应者能够在计算DH共享密钥和SK_*密钥之前验证谜题。
If IKE fragmentation [RFC7383] is used in the IKE_AUTH exchange, then the PS payload MUST be present only in the first IKE Fragment message, in accordance with Section 2.5.3 of [RFC7383]. Note that calculation of the puzzle in the IKE_AUTH exchange doesn't depend on the content of the IKE_AUTH message (see Section 7.2.3). Thus, the Initiator has to solve the puzzle only once, and the solution is valid for both unfragmented and fragmented IKE messages.
如果IKE碎片[RFC7383]用于IKE_身份验证交换，则根据[RFC7383]第2.5.3节，PS有效负载必须仅出现在第一条IKE碎片消息中。请注意，IKE_AUTH交换中谜题的计算不取决于IKE_AUTH消息的内容（参见第7.2.3节）。因此，发起者只需解决一次难题，并且该解决方案对未分段和分段的IKE消息都有效。
A puzzle in the IKE_AUTH exchange is computed differently than in the IKE_SA_INIT exchange (see Section 7.1.3). The general principle is the same; the difference is in the construction of the string S. Unlike the IKE_SA_INIT exchange, where S is the cookie, in the IKE_AUTH exchange, S is a concatenation of Nr and SPIr. In other words, the task for the IKE Initiator is to find the four different keys Ki for the agreed upon PRF such that each result of PRF(Ki,Nr | SPIr) where i=[1..4] has a sufficient number of trailing zero bits. Nr is a nonce used by the Responder in the IKE_SA_INIT exchange, stripped of any headers. SPIr is the IKE Responder's SPI from the IKE header of the SA being established.
IKE_验证交换中的谜题计算方式与IKE_SA_INIT交换中的谜题计算方式不同（参见第7.1.3节）。总的原则是一样的；不同之处在于字符串S的构造。与IKE_SA_INIT交换不同，在IKE_AUTH交换中，S是Nr和SPIr的串联。换言之，IKE发起方的任务是为商定的PRF找到四个不同的密钥Ki，以便其中i=[1..4]的PRF（Ki，Nr | SPIr）的每个结果具有足够数量的尾随零位。Nr是响应程序在IKE_SA_INIT交换中使用的一个nonce，去掉任何头。SPIr是来自正在建立的SA的IKE头的IKE响应者的SPI。
If the Responder requested the Initiator to solve a puzzle in the IKE_AUTH exchange, then it MUST silently discard all the IKE_AUTH request messages without the PS payload.
如果响应者请求发起方解决IKE_AUTH交换中的难题，则它必须在没有PS有效负载的情况下默默地丢弃所有IKE_AUTH请求消息。
Once the message containing a solution to the puzzle is received, the Responder MUST verify the solution before performing computationally intensive operations, i.e., computing the DH shared secret and the SK_* keys. The Responder MUST verify all four of the returned keys.
一旦接收到包含谜题解决方案的消息，响应者必须在执行计算密集型操作（即，计算DH共享密钥和SK_*密钥）之前验证该解决方案。响应者必须验证所有四个返回的密钥。
The Responder MUST silently discard the received message if any checked verification result is not correct (contains insufficient number of trailing zero bits). If the Responder successfully verifies the puzzle and calculates the SK_* key, but the message authenticity check fails, then it SHOULD save the calculated keys in the IKE SA state while waiting for the retransmissions from the
如果任何检查的验证结果不正确（包含的尾随零位数量不足），响应程序必须以静默方式放弃接收到的消息。如果响应者成功验证谜题并计算SK_*密钥，但消息真实性检查失败，则在等待来自消息的重新传输时，应将计算出的密钥保存在IKE SA状态
Initiator. In this case, the Responder may skip verification of the puzzle solution and ignore the PS payload in the retransmitted messages.
发起者。在这种情况下，响应者可以跳过谜题解决方案的验证，并忽略重传消息中的PS有效载荷。
If the Initiator uses IKE fragmentation, then it sends all fragments of a message simultaneously. Due to packets loss and/or reordering, it is possible that the Responder receives subsequent fragments before receiving the first one that contains the PS payload. In this case, the Responder MAY choose to keep the received fragments until the first fragment containing the solution to the puzzle is received. In this case, the Responder SHOULD NOT try to verify authenticity of the kept fragments until the first fragment with the PS payload is received, and the solution to the puzzle is verified. After successful verification of the puzzle, the Responder can then calculate the SK_* key and verify authenticity of the collected fragments.
如果启动器使用IKE分段，那么它会同时发送消息的所有片段。由于数据包丢失和/或重新排序，响应者可能在接收到包含PS有效负载的第一个片段之前接收到后续片段。在这种情况下，响应者可以选择保留接收到的片段，直到接收到包含谜题解决方案的第一个片段。在这种情况下，响应者不应尝试验证保留片段的真实性，直到接收到具有PS有效负载的第一个片段，并且验证谜题的解决方案。成功验证谜题后，响应者可以计算SK_*密钥并验证收集片段的真实性。
The PUZZLE notification is used by the IKE Responder to inform the Initiator about the need to solve the puzzle. It contains the difficulty level of the puzzle and the PRF the Initiator should use.
IKE响应者使用谜题通知通知发起者需要解决谜题。它包含谜题的难度等级和发起者应该使用的PRF。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF | Difficulty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRF | Difficulty |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) -- MUST be 0.
o 协议ID（1个八位字节）--必须为0。
o SPI Size (1 octet) -- MUST be 0, meaning no SPI is present.
o SPI大小（1个八位字节）——必须为0，表示不存在SPI。
o Notify Message Type (2 octets) -- MUST be 16434, the value assigned for the PUZZLE notification.
o 通知消息类型（2个八位字节）--必须是16434，为拼图通知指定的值。
o PRF (2 octets) -- Transform ID of the PRF algorithm that MUST be used to solve the puzzle. Readers should refer to the "Transform Type 2 - Pseudorandom Function Transform IDs" subregistry on [IKEV2-IANA] for the list of possible values.
o PRF（2个八位字节）——必须用于解决难题的PRF算法的变换ID。读者应参考[IKEV2-IANA]上的“变换类型2-伪随机函数变换ID”子区域，了解可能值的列表。
o Difficulty (1 octet) -- Difficulty level of the puzzle. Specifies the minimum number of trailing zero bits (ZBC) that each of the results of PRF must contain. Value 0 means that the Responder doesn't request any specific difficulty level, and the Initiator is free to select an appropriate difficulty level on its own (see Section 7.1.1.1 for details).
o 难度（1个八位组）——谜题的难度等级。指定PRF的每个结果必须包含的最小尾随零位数（ZBC）。值0表示响应者不请求任何特定的难度级别，发起人可以自行选择适当的难度级别（详见第7.1.1.1节）。
This notification contains no data.
此通知不包含任何数据。
The solution to the puzzle is returned back to the Responder in a dedicated payload, called the PS payload.
谜题的解决方案在一个称为PS负载的专用负载中返回给响应者。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Puzzle Solution Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Puzzle Solution Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Puzzle Solution Data (variable length) -- Contains the solution to the puzzle -- four different keys for the selected PRF. This field MUST NOT be empty. All of the keys MUST have the same size; therefore, the size of this field is always a multiple of 4 bytes. If the selected PRF accepts only fixed-size keys, then the size of each key MUST be of that fixed size. If the agreed upon PRF accepts keys of any size, then the size of each key MUST be between 1 octet and the preferred key length of the PRF (inclusive). It is expected that in most cases, the keys will be 4 (or even less) octets in length; however, it depends on puzzle difficulty and on the Initiator's strategy to find solutions, and thus the size is not mandated by this specification. The Responder determines the size of each key by dividing the size of the Puzzle Solution Data by 4 (the number of keys). Note that the size of Puzzle Solution Data is the size of the Payload (as indicated in the Payload Length field) minus 4 -- the size of the Payload header.
o 拼图解决方案数据（可变长度）——包含拼图的解决方案——选定PRF的四个不同键。此字段不能为空。所有钥匙的尺寸必须相同；因此，此字段的大小始终是4字节的倍数。如果选定的PRF仅接受固定大小的键，则每个键的大小必须为该固定大小。如果商定的PRF接受任何大小的密钥，则每个密钥的大小必须介于1个八位组和PRF的首选密钥长度（包括）之间。预计在大多数情况下，密钥长度为4个（甚至更少）八位组；然而，这取决于谜题的难度和发起者寻找解决方案的策略，因此大小不受本规范的约束。响应者通过将谜题解决方案数据的大小除以4（键数）来确定每个键的大小。请注意，拼图解决方案数据的大小是有效负载的大小（如有效负载长度字段中所示）减去4--有效负载标头的大小。
The payload type for the PS payload is 54.
PS有效负载的有效负载类型为54。
The puzzle difficulty level should be set by balancing the requirement to minimize the latency for legitimate Initiators with making things difficult for attackers. A good rule of thumb is taking about 1 second to solve the puzzle. At the time this document was written, a typical Initiator or botnet member can perform slightly less than a million hashes per second per core, so setting the number of zero bits to 20 is a good compromise. It should be noted that mobile Initiators, especially phones, are considerably weaker than that. Implementations should allow administrators to set the difficulty level and/or be able to set the difficulty level dynamically in response to load.
设置谜题难度级别时，应平衡使合法启动器的延迟最小化的要求与使攻击者难以应对的要求。一个好的经验法则是花大约1秒来解决这个难题。在编写本文档时，一个典型的启动器或僵尸网络成员可以在每个核心每秒执行略少于一百万次哈希，因此将零位数设置为20是一个很好的折衷方案。应该注意的是，移动启动器，尤其是手机，比这要弱得多。实现应允许管理员设置难度级别和/或能够根据负载动态设置难度级别。
Initiators SHOULD set a maximum difficulty level beyond which they won't try to solve the puzzle and log or display a failure message to the administrator or user.
发起者应该设置一个最大难度，超过这个难度，他们将不会尝试解决难题，并记录或向管理员或用户显示失败消息。
Until the widespread adoption of puzzles happens, most Initiators will ignore them, as will all attackers. For puzzles to become a really powerful defense measure against DDoS attacks, they must be supported by the majority of legitimate clients.
在谜题被广泛采用之前，大多数发起者和所有攻击者都会忽略它们。谜题要成为抵御DDoS攻击的真正强大防御措施，必须得到大多数合法客户端的支持。
Care must be taken when selecting parameters for the puzzles, in particular the puzzle difficulty. If the puzzles are too easy for the majority of attackers, then the puzzle mechanism wouldn't be able to prevent DoS or DDoS attacks and would only impose an additional burden on legitimate Initiators. On the other hand, if the puzzles are too hard for the majority of Initiators, then many legitimate users would experience unacceptable delays in IKE SA setup (and unacceptable power consumption on mobile devices) that might cause them to cancel the connection attempt. In this case, the resources of the Responder are preserved; however, the DoS attack can be considered successful. Thus, a sensible balance should be kept by the Responder while choosing the puzzle difficulty -- to defend itself and to not over-defend itself. It is RECOMMENDED that the puzzle difficulty be chosen, so that the Responder's load remains close to the maximum it can tolerate. It is also RECOMMENDED to dynamically adjust the puzzle difficulty in accordance to the current Responder's load.
为拼图选择参数时必须小心，尤其是拼图难度。如果谜题对于大多数攻击者来说太容易了，那么谜题机制将无法阻止DoS或DDoS攻击，并且只会给合法的发起人带来额外的负担。另一方面，如果谜题对大多数发起者来说太难，那么许多合法用户将在IKE SA设置中遇到不可接受的延迟（以及移动设备上不可接受的功耗），这可能会导致他们取消连接尝试。在这种情况下，响应者的资源被保留；但是，可以认为DoS攻击是成功的。因此，在选择谜题难度时，回答者应该保持一种合理的平衡——保护自己，而不是过度保护自己。建议选择拼图难度，以便响应者的负载保持接近其可以承受的最大负载。还建议根据当前响应者的负载动态调整拼图难度。
If the cookie is generated as suggested in Section 2.6 of [RFC7296], then an attacker can use the same SPIi and the same Ni for several requests from the same IPi. This will result in generating the same
如果cookie是按照[RFC7296]第2.6节中的建议生成的，那么攻击者可以对来自同一IPi的多个请求使用相同的SPIi和相同的Ni。这将产生相同的结果
cookies for these requests until the Responder changes the value of its cookie generation secret. Since the cookies are used as an input data for puzzles in the IKE_SA_INIT exchange, generating the same cookies allows the attacker to reuse puzzle solutions, thus bypassing the proof-of-work requirement. Note that the attacker can get only limited benefit from this situation -- once the half-open SA is created by the Responder, all the subsequent initial requests with the same IPi and SPIi will be treated as retransmissions and discarded by the Responder. However, once this half-open SA is expired and deleted, the attacker can create a new one for free if the Responder hasn't changed its cookie generation secret yet.
这些请求的cookie，直到响应者更改其cookie generation secret的值。由于Cookie被用作IKE_SA_INIT交换中谜题的输入数据，因此生成相同的Cookie允许攻击者重用谜题解决方案，从而绕过工作证明要求。请注意，攻击者只能从这种情况中获得有限的好处——一旦响应者创建了半开放的SA，所有具有相同IPi和SPIi的后续初始请求都将被视为重传，并被响应者丢弃。但是，一旦此半开放SA过期并被删除，如果响应者尚未更改其cookie生成机密，攻击者可以免费创建一个新的SA。
The Responder can use various countermeasures to completely eliminate or mitigate this scenario. First, the Responder can change its cookie generation secret frequently especially if under attack, as recommended in Section 2.6 of [RFC7296]. For example, if the Responder keeps two values of the secret (current and previous) and the secret lifetime is no more than a half of the current half-open SA retention time (see Section 4.1), then the attacker cannot get benefit from reusing a puzzle solution. However, short cookie generation secret lifetime could have a negative consequence on weak legitimate Initiators, since it could take too long for them to solve puzzles, and their solutions would be discarded if the cookie generation secret has been already changed few times.
响应者可以使用各种对策来完全消除或缓解这种情况。首先，响应者可以频繁更改其cookie生成秘密，特别是在受到攻击时，如[RFC7296]第2.6节所建议。例如，如果响应者保留两个秘密值（当前和以前），并且秘密生存期不超过当前半开放SA保留时间的一半（参见第4.1节），则攻击者无法从重用谜题解决方案中获益。但是，短的cookie生成密钥生存期可能会对弱合法启动器产生负面影响，因为它们可能需要太长的时间来解决难题，如果cookie生成密钥已经更改了几次，它们的解决方案将被丢弃。
Another approach for the Responder is to modify the cookie generation algorithm in such a way that the generated cookies are always different or are repeated only within a short time period. If the Responder includes a timestamp in <AdditionalInfo> as suggested in Section 7.1.1.3, then the cookies will repeat only within a short time interval equal to timestamp resolution. Another approach for the Responder is to maintain a global counter that is incremented every time a cookie is generated and include this counter in <AdditionalInfo>. This will make every cookie unique.
响应者的另一种方法是修改cookie生成算法，使生成的cookie始终不同或仅在短时间内重复。如果响应者按照第7.1.1.3节的建议在<AdditionalInfo>中包含时间戳，则cookies将仅在与时间戳分辨率相等的短时间间隔内重复。响应程序的另一种方法是维护一个全局计数器，该计数器在每次生成cookie时递增，并将该计数器包含在<AdditionalInfo>中。这将使每一块饼干都独一无二。
Implementations MUST use one of the above (or some other) countermeasures to completely eliminate or make insignificant the possible benefit an attacker can get from reusing puzzle solutions. Note that this issue doesn't exist in IKE_AUTH puzzles (Section 7.2) since the puzzles in IKE_AUTH are always unique if the Responder generates SPIr and Nr randomly in accordance with [RFC7296].
实现必须使用上述（或某些其他）对策之一，以完全消除或忽略攻击者从重用谜题解决方案中可能获得的好处。请注意，IKE_AUTH拼图（第7.2节）中不存在此问题，因为如果响应者根据[RFC7296]随机生成SPIr和Nr，IKE_AUTH中的拼图总是唯一的。
Solving puzzles requires a lot of CPU usage that increases power consumption. This additional power consumption can negatively affect battery-powered Initiators, e.g., mobile phones or some Internet of Things (IoT) devices. If puzzles are too hard, then the required additional power consumption may appear to be unacceptable for some Initiators. The Responder SHOULD take this possibility into
解决难题需要大量CPU使用，这会增加功耗。这种额外的功耗会对电池供电的启动器产生负面影响，例如移动电话或某些物联网（IoT）设备。如果拼图太难，那么对于某些启动器来说，所需的额外功耗似乎是不可接受的。响应者应考虑到这种可能性
consideration while choosing the puzzle difficulty and while selecting which percentage of Initiators are allowed to reject solving puzzles. See Section 7.1.4 for details.
在选择谜题难度和选择允许哪些百分比的发起者拒绝解决谜题时要考虑。详见第7.1.4节。
If the Initiator uses NULL Authentication [RFC7619], then its identity is never verified. This condition may be used by attackers to perform a DoS attack after the IKE SA is established. Responders that allow unauthenticated Initiators to connect must be prepared to deal with various kinds of DoS attacks even after the IKE SA is created. See Section 5 for details.
如果启动器使用空身份验证[RFC7619]，则永远不会验证其身份。在IKE SA建立后，攻击者可利用此条件执行DoS攻击。即使在创建IKE SA之后，允许未经身份验证的启动器连接的响应者也必须准备好应对各种DoS攻击。详见第5节。
To prevent amplification attacks, implementations must strictly follow the retransmission rules described in Section 2.1 of [RFC7296].
为了防止放大攻击，实现必须严格遵守[RFC7296]第2.1节中描述的重传规则。
This document defines a new payload in the "IKEv2 Payload Types" registry:
本文档在“IKEv2有效负载类型”注册表中定义了一个新的有效负载：
54 Puzzle Solution PS
54拼图解答PS
This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:
本文档还定义了“IKEv2通知消息类型-状态类型”注册表中的新通知消息类型：
16434 PUZZLE
16434拼图
[IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>.
[IKEV2-IANA]IANA，“互联网密钥交换版本2（IKEV2）参数”<http://www.iana.org/assignments/ikev2-parameters>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <http://www.rfc-editor.org/info/rfc5723>.
[RFC5723]Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议版本2（IKEv2）会话恢复”，RFC 5723，DOI 10.17487/RFC5723，2010年1月<http://www.rfc-editor.org/info/rfc5723>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <http://www.rfc-editor.org/info/rfc7383>.
[RFC7383]Smyslov，V.，“互联网密钥交换协议版本2（IKEv2）消息碎片”，RFC 7383，DOI 10.17487/RFC7383，2014年11月<http://www.rfc-editor.org/info/rfc7383>.
[BITCOINS] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", October 2008, <https://bitcoin.org/bitcoin.pdf>.
[比特币]Nakamoto，S.，“比特币：点对点电子现金系统”，2008年10月<https://bitcoin.org/bitcoin.pdf>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <http://www.rfc-editor.org/info/rfc7619>.
[RFC7619]Smyslov，V.和P.Wouters，“互联网密钥交换协议版本2（IKEv2）中的空身份验证方法”，RFC 7619，DOI 10.17487/RFC7619，2015年8月<http://www.rfc-editor.org/info/rfc7619>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <http://www.rfc-editor.org/info/rfc7696>.
[RFC7696]Housley，R.，“加密算法敏捷性和选择强制算法的指南”，BCP 201，RFC 7696，DOI 10.17487/RFC7696，2015年11月<http://www.rfc-editor.org/info/rfc7696>.
Acknowledgements
致谢
The authors thank Tero Kivinen, Yaron Sheffer, and Scott Fluhrer for their contributions to the design of the protocol. In particular, Tero Kivinen suggested the kind of puzzle where the task is to find a solution with a requested number of zero trailing bits. Yaron Sheffer and Scott Fluhrer suggested a way to make puzzle difficulty less erratic by solving several weaker puzzles. The authors also thank David Waltermire and Paul Wouters for their careful reviews of the document, Graham Bartlett for pointing out the possibility of an attack related to "Hash & URL", Stephen Farrell for catching the repeated cookie issue, and all others who commented on the document.
作者感谢Tero Kivinen、Yaron Sheffer和Scott Fluhrer对协议设计的贡献。特别是，Tero Kivinen提出了一种谜题，其中的任务是找到一个具有所需数量的零尾随位的解决方案。亚龙·谢弗和斯科特·弗勒提出了一种方法，通过解决几个较弱的谜题来降低谜题的难度。作者还感谢David Waltermire和Paul Wouters对文档的仔细审阅，感谢Graham Bartlett指出了与“哈希和URL”相关的攻击的可能性，感谢Stephen Farrell抓住了重复的cookie问题，感谢所有对文档发表评论的人。
Authors' Addresses
作者地址
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 6789735 Israel
以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司6789735
Email: ynir.ietf@gmail.com
Email: ynir.ietf@gmail.com
Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation
Valery Smyslov ELVIS-PLUS邮政信箱81莫斯科（Zelenograd）124460俄罗斯联邦
Phone: +7 495 276 0211
Email: svan@elvis.ru
Phone: +7 495 276 0211
Email: svan@elvis.ru