Internet Engineering Task Force (IETF) Y. Nir, Ed.
Request for Comments: 6290 Check Point
Category: Standards Track D. Wierbowski
ISSN: 2070-1721 IBM
F. Detienne
P. Sethi
Cisco
June 2011
Internet Engineering Task Force (IETF) Y. Nir, Ed.
Request for Comments: 6290 Check Point
Category: Standards Track D. Wierbowski
ISSN: 2070-1721 IBM
F. Detienne
P. Sethi
Cisco
June 2011
A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)
一种Internet密钥交换协议（IKE）的快速崩溃检测方法
Abstract
摘要
This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token.
本文档描述了对Internet密钥交换协议版本2（IKEv2）的扩展，该扩展允许使用保存的令牌更快地检测安全关联（SA）取消同步。
When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart.
当两个IKEv2对等方之间的IPsec隧道由于一个对等方重新启动而断开时，另一个对等方可能需要几分钟的时间才能发现已重新启动，从而延迟恢复。在本文中，我们建议对协议进行扩展，允许在重启后立即恢复。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc6290.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6290.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请审阅这些文件
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.
请仔细阅读，因为他们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. RFC 5996 Crash Recovery . . . . . . . . . . . . . . . . . . . 4
3. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . . 5
4. Formats and Exchanges . . . . . . . . . . . . . . . . . . . . 6
4.1. Notification Format . . . . . . . . . . . . . . . . . . . 6
4.2. Passing a Token in the AUTH Exchange . . . . . . . . . . . 7
4.3. Replacing Tokens after Rekey or Resumption . . . . . . . . 8
4.4. Replacing the Token for an Existing SA . . . . . . . . . . 9
4.5. Presenting the Token in an Unprotected Message . . . . . . 9
5. Token Generation and Verification . . . . . . . . . . . . . . 10
5.1. A Stateless Method of Token Generation . . . . . . . . . . 11
5.2. A Stateless Method with IP Addresses . . . . . . . . . . . 11
5.3. Token Lifetime . . . . . . . . . . . . . . . . . . . . . . 12
6. Backup Gateways . . . . . . . . . . . . . . . . . . . . . . . 12
7. Interaction with Session Resumption . . . . . . . . . . . . . 13
8. Operational Considerations . . . . . . . . . . . . . . . . . . 14
8.1. Who Should Implement This Specification . . . . . . . . . 14
8.2. Response to Unknown Child SPI . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. QCD Token Generation and Handling . . . . . . . . . . . . 16
9.2. QCD Token Transmission . . . . . . . . . . . . . . . . . . 17
9.3. QCD Token Enumeration . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. The Path Not Taken . . . . . . . . . . . . . . . . . 20
A.1. Initiating a New IKE SA . . . . . . . . . . . . . . . . . 20
A.2. SIR . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Birth Certificates . . . . . . . . . . . . . . . . . . . . 20
A.4. Reducing Liveness Check Length . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. RFC 5996 Crash Recovery . . . . . . . . . . . . . . . . . . . 4
3. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . . 5
4. Formats and Exchanges . . . . . . . . . . . . . . . . . . . . 6
4.1. Notification Format . . . . . . . . . . . . . . . . . . . 6
4.2. Passing a Token in the AUTH Exchange . . . . . . . . . . . 7
4.3. Replacing Tokens after Rekey or Resumption . . . . . . . . 8
4.4. Replacing the Token for an Existing SA . . . . . . . . . . 9
4.5. Presenting the Token in an Unprotected Message . . . . . . 9
5. Token Generation and Verification . . . . . . . . . . . . . . 10
5.1. A Stateless Method of Token Generation . . . . . . . . . . 11
5.2. A Stateless Method with IP Addresses . . . . . . . . . . . 11
5.3. Token Lifetime . . . . . . . . . . . . . . . . . . . . . . 12
6. Backup Gateways . . . . . . . . . . . . . . . . . . . . . . . 12
7. Interaction with Session Resumption . . . . . . . . . . . . . 13
8. Operational Considerations . . . . . . . . . . . . . . . . . . 14
8.1. Who Should Implement This Specification . . . . . . . . . 14
8.2. Response to Unknown Child SPI . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. QCD Token Generation and Handling . . . . . . . . . . . . 16
9.2. QCD Token Transmission . . . . . . . . . . . . . . . . . . 17
9.3. QCD Token Enumeration . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. The Path Not Taken . . . . . . . . . . . . . . . . . 20
A.1. Initiating a New IKE SA . . . . . . . . . . . . . . . . . 20
A.2. SIR . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. Birth Certificates . . . . . . . . . . . . . . . . . . . . 20
A.4. Reducing Liveness Check Length . . . . . . . . . . . . . . 21
IKEv2, as described in [RFC5996] and its predecessor RFC 4306, has a method for recovering from a reboot of one peer. As long as traffic flows in both directions, the rebooted peer should re-establish the tunnels immediately. However, in many cases, the rebooted peer is a VPN gateway that protects only servers, so all traffic is inbound. In other cases, the non-rebooted peer has a dynamic IP address, so the rebooted peer cannot initiate IKE because its current IP address is unknown. In such cases, the rebooted peer will not be able to re-establish the tunnels. Section 2 describes how recovery works under RFC 5996, and explains why it may take several minutes.
如[RFC5996]及其前身RFC 4306中所述，IKEv2具有从一个对等机的重新启动中恢复的方法。只要流量在两个方向上流动，重新启动的对等方应立即重新建立隧道。但是，在许多情况下，重新启动的对等方是一个VPN网关，它只保护服务器，因此所有流量都是入站的。在其他情况下，未重新启动的对等方具有动态IP地址，因此重新启动的对等方无法启动IKE，因为其当前IP地址未知。在这种情况下，重新启动的对等方将无法重新建立隧道。第2节描述了在RFC 5996下恢复是如何工作的，并解释了为什么可能需要几分钟的时间。
The method proposed here is to send an octet string, called a "QCD token", in the IKE_AUTH exchange that establishes the tunnel. That token can be stored on the peer as part of the IKE SA. After a reboot, the rebooted implementation can re-generate the token and send it to the peer, so as to delete the IKE SA. Deleting the IKE SA results in a quick establishment of new IPsec tunnels. This is described in Section 3.
这里提出的方法是在建立隧道的IKE_AUTH交换中发送一个八位字节字符串，称为“QCD令牌”。该令牌可以作为IKE SA的一部分存储在对等方上。重新启动后，重新启动的实现可以重新生成令牌并将其发送给对等方，从而删除IKE SA。删除IKE SA会导致快速建立新的IPsec隧道。第3节对此进行了描述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The term "token" refers to an octet string that an implementation can generate using only the properties of a protected IKE message (such as IKE Security Parameter Indexes (SPIs)) as input. A conforming implementation MUST be able to generate the same token from the same input even after rebooting.
术语“令牌”指的是八位字节字符串，实现仅使用受保护IKE消息的属性（例如IKE安全参数索引（SPI））作为输入即可生成该字符串。一致性实现必须能够从相同的输入生成相同的令牌，即使在重新启动后也是如此。
The term "token maker" refers to an implementation that generates a token and sends it to the peer as specified in this document.
术语“令牌制造者”是指按照本文档的规定生成令牌并将其发送给对等方的实现。
The term "token taker" refers to an implementation that stores such a token or a digest thereof, in order to verify that a new token it receives is identical to the old token it has stored.
术语“令牌接受者”是指存储这样的令牌或其摘要的实现，以验证它接收的新令牌与它存储的旧令牌相同。
The term "non-volatile storage" in this document refers to a data storage module that persists across restarts of the token maker. Examples of such a storage module include an internal disk, an internal flash memory module, an external disk, and an external database. A small non-volatile storage module is required for a token maker, but a larger one can be used to enhance performance, as described in Section 8.2.
本文档中的术语“非易失性存储”指的是在令牌制造商重启期间持续存在的数据存储模块。此类存储模块的示例包括内部磁盘、内部闪存模块、外部磁盘和外部数据库。令牌制造商需要一个小型非易失性存储模块，但可以使用更大的存储模块来提高性能，如第8.2节所述。
When one peer loses state or reboots, the other peer does not get any notification, so unidirectional IPsec traffic can still flow. The rebooted peer will not be able to decrypt it, however, and the only remedy is to send an unprotected INVALID_SPI notification as described in Section 3.10.1 of [RFC5996]. That section also describes the processing of such a notification:
当一个对等方失去状态或重新启动时，另一个对等方不会收到任何通知，因此单向IPsec通信仍然可以流动。但是，重新启动的对等机将无法对其进行解密，唯一的补救办法是发送未受保护的无效_SPI通知，如[RFC5996]第3.10.1节所述。该节还描述了此类通知的处理：
If this Informational Message is sent outside the context of an IKE_SA, it should be used by the recipient only as a "hint" that something might be wrong (because it could easily be forged).
如果此信息消息是在IKE_SA的上下文之外发送的，则收件人应仅将其用作可能出错的“提示”（因为它很容易被伪造）。
Since the INVALID_SPI can only be used as a hint, the non-rebooted peer has to determine whether the IPsec SA and indeed the parent IKE SA are still valid. The method of doing this is described in Section 2.4 of [RFC5996]. This method, called "liveness check", involves sending a protected empty INFORMATIONAL message, and awaiting a response. This procedure is sometimes referred to as "Dead Peer Detection" or DPD.
由于无效的_SPI只能用作提示，因此未重新启动的对等方必须确定IPsec SA以及父IKE SA是否仍然有效。[RFC5996]第2.4节描述了执行此操作的方法。此方法称为“活动性检查”，包括发送受保护的空信息消息，并等待响应。此过程有时称为“死点检测”或DPD。
Section 2.4 does not mandate how many times the liveness check message should be retransmitted, or for how long, but does recommend the following:
第2.4节未规定活动性检查消息应重新传输多少次，或传输多长时间，但建议如下：
It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA...
建议在放弃使用SA之前，在至少几分钟的时间内至少重新传输十几次消息。。。
Those "at least several minutes" are a time during part of which both peers are active, but IPsec cannot be used.
这些“至少几分钟”是两个对等方都处于活动状态的时间，但不能使用IPsec。
Especially in the case of a reboot (rather than fail-over or administrative clearing of state), the peer does not recover immediately. Reboot, depending on the system, may take from a few seconds to a few minutes. This means that at first the peer just goes silent, i.e., does not send or respond to any messages. IKEv2 implementations can detect this situation and follow the rules given in Section 2.4:
尤其是在重新启动的情况下（而不是故障转移或管理性状态清除），对等机不会立即恢复。根据系统的不同，重新启动可能需要几秒钟到几分钟。这意味着一开始，对等方只是保持沉默，即不发送或响应任何消息。IKEv2实现可以检测到这种情况，并遵循第2.4节中给出的规则：
If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer.
如果与IKE SA关联的所有SA上只有传出流量，则必须确认另一个端点的活动性以避免黑洞。如果IKE SA或其任何子SA最近未收到任何受加密保护的消息，则系统需要执行活动性检查，以防止向死对等方发送消息。
[RFC5996] does not mandate any time limits, but it is possible that the peer will start liveness checks even before the other end is sending INVALID_SPI notification, as it detected that the other end is not sending any packets anymore while it is still rebooting or recovering from the situation.
[RFC5996]没有规定任何时间限制，但对等方可能会在另一端发送无效的_SPI通知之前启动活动性检查，因为它检测到另一端在重新启动或从该情况中恢复时不再发送任何数据包。
This means that the several minutes recovery period is overlapping the actual recover time of the other peer; i.e., if the security gateway requires several minutes to boot up from the crash, then the other peers have already finished their liveness checks before the crashing peer even has a chance to send INVALID_SPI notifications.
这意味着几分钟的恢复时间与另一个对等方的实际恢复时间重叠；i、 例如，如果安全网关需要几分钟才能从崩溃中启动，那么在崩溃的对等方甚至有机会发送无效的_SPI通知之前，其他对等方已经完成了活动性检查。
There are cases where the peer loses state and is able to recover immediately; in those cases it might take several minutes to recreate the IPsec SAs.
在某些情况下，对等方失去状态并能够立即恢复；在这些情况下，可能需要几分钟来重新创建IPsec SAs。
Note that the IKEv2 specification specifically gives no guidance for the number of retries or the length of timeouts, as these do not affect interoperability. This means that implementations are allowed to use the hints provided by the INVALID_SPI messages to shorten those timeouts (i.e., a different environment and situation requiring different rules).
请注意，IKEv2规范没有明确给出重试次数或超时长度的指导，因为这些不会影响互操作性。这意味着允许实现使用无效的_SPI消息提供的提示来缩短这些超时（即，需要不同规则的不同环境和情况）。
Some existing IKEv2 implementations already do that (i.e., shorten timeouts or limit number of retries) based on these kinds of hints and also start liveness checks quickly after the other end goes silent. However, see Appendix A.4 for a discussion of why this may not be enough.
一些现有的IKEv2实现已经基于这些类型的提示实现了这一点（即缩短超时或限制重试次数），并且在另一端沉默后也会快速启动活动性检查。但是，有关这可能不够的原因，请参见附录A.4。
Supporting implementations will send a notification, called a "QCD token", as described in Section 4.1 in the first IKE_AUTH exchange messages. These are the first IKE_AUTH request and final IKE_AUTH response that contain the AUTH payloads. The generation of these tokens is a local matter for implementations, but considerations are described in Section 5. Implementations that send such a token will be called "token makers".
支持实现将发送一个称为“QCD令牌”的通知，如第一个IKE_认证交换消息第4.1节所述。这是包含验证有效载荷的第一个IKE_验证请求和最后一个IKE_验证响应。这些令牌的生成对于实现来说是一个局部问题，但是注意事项在第5节中描述。发送这种令牌的实现称为“令牌制造者”。
A supporting implementation receiving such a token MUST store it (or a digest thereof) along with the IKE SA. Implementations that support this part of the protocol will be called "token takers". Section 8.1 has considerations for which implementations need to be token takers, and which should be token makers. Implementations that are not token takers will silently ignore QCD tokens.
接收此类令牌的支持实现必须将其（或其摘要）与IKE SA一起存储。支持协议这一部分的实现称为“令牌接受者”。第8.1节考虑了哪些实现需要是令牌获取者，哪些实现应该是令牌制造者。不是令牌接受者的实现将默默地忽略QCD令牌。
When a token maker receives a protected IKE request message with unknown IKE SPIs, it SHOULD generate a new token that is identical to the previous token, and send it to the requesting peer in an unprotected IKE message as described in Section 4.5.
当令牌制造商接收到具有未知IKE SPI的受保护IKE请求消息时，它应生成一个与先前令牌相同的新令牌，并按照第4.5节所述，以未受保护的IKE消息的形式将其发送给请求对等方。
When a token taker receives the QCD token in an unprotected notification, it MUST verify that the TOKEN_SECRET_DATA matches the token stored with the matching IKE SA. If the verification fails, or if the IKE SPIs in the message do not match any existing IKE SA, it SHOULD log the event. If it succeeds, it MUST silently delete the IKE SA associated with the IKE_SPI fields and all dependent child SAs. This event MAY also be logged. The token taker MUST accept such tokens from any IP address and port combination, so as to allow different kinds of high-availability configurations of the token maker.
当令牌接受者在未受保护的通知中收到QCD令牌时，它必须验证令牌\u SECRET\u数据是否与存储在匹配IKE SA中的令牌匹配。如果验证失败，或者如果消息中的IKE SPI与任何现有IKE SA不匹配，则应记录事件。如果成功，它必须以静默方式删除与IKE_SPI字段关联的IKE SA和所有从属子SA。也可能会记录此事件。令牌接受者必须接受来自任何IP地址和端口组合的令牌，以便允许令牌制造商的不同类型的高可用性配置。
A supporting token taker MAY immediately create new SAs using an Initial exchange, or it may wait for subsequent traffic to trigger the creation of new SAs.
支持令牌接受者可以使用初始交换立即创建新SA，也可以等待后续流量触发新SA的创建。
See Section 7 for a short discussion about this extension's interaction with IKEv2 Session Resumption ([RFC5723]).
有关此扩展与IKEv2会话恢复（[RFC5723]）的交互的简短讨论，请参见第7节。
The notification payload called "QCD token" is formatted as follows:
名为“QCD令牌”的通知有效负载的格式如下：
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 ! SPI Size ! QCD Token Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ TOKEN_SECRET_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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! QCD Token Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ TOKEN_SECRET_DATA ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA.
o 协议ID（1个八位组）必须为1，因为此消息与IKE SA相关。
o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 of [RFC5996].
o SPI大小（1个八位字节）必须为零，符合[RFC5996]第3.10节的规定。
o QCD Token Notify Message Type (2 octets) - MUST be 16419, the value assigned for QCD token notifications.
o QCD令牌通知消息类型（2个八位字节）-必须为16419，为QCD令牌通知分配的值。
o TOKEN_SECRET_DATA (variable) contains a generated token as described in Section 5.
o 令牌\机密\数据（变量）包含生成的令牌，如第5节所述。
For brevity, only the Extensible Authentication Protocol (EAP) version of an AUTH exchange will be presented here. The non-EAP version is very similar. The figures below are based on Appendix C.3 of [RFC5996].
为简洁起见，此处仅介绍身份验证交换的可扩展身份验证协议（EAP）版本。非EAP版本非常相似。下图基于[RFC5996]的附录C.3。
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[N(QCD_TOKEN)]
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[N(QCD_TOKEN)]
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
first response <-- IDr, [CERT+], AUTH, EAP, [V+]
第一个响应<--IDr、[CERT+]，认证，EAP，[V+]
/ --> EAP repeat 1..N times | \ <-- EAP
/-->EAP重复1..N次| \<--EAP
last request --> AUTH
上次请求-->身份验证
last response <-- AUTH,
[N(QCD_TOKEN)]
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
last response <-- AUTH,
[N(QCD_TOKEN)]
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
Note that the QCD_TOKEN notification is marked as optional because it is not required by this specification that every implementation be both token maker and token taker. If only one peer sends the QCD token, then a reboot of the other peer will not be recoverable by this method. This may be acceptable if traffic typically originates from the other peer.
注意，QCD_令牌通知被标记为可选的，因为本规范不要求每个实现都是令牌制造者和令牌获取者。如果只有一个对等方发送QCD令牌，则通过此方法无法恢复另一个对等方的重新启动。如果流量通常来自另一个对等方，则这是可以接受的。
In any case, the lack of a QCD_TOKEN notification MUST NOT be taken as an indication that the peer does not support this standard. Conversely, if a peer does not understand this notification, it will simply ignore it. Therefore, a peer may send this notification freely, even if it does not know whether the other side supports it.
在任何情况下，缺少QCD_令牌通知不得视为对等方不支持该标准的指示。相反，如果对等方不理解此通知，它将直接忽略它。因此，对等方可以自由发送此通知，即使它不知道对方是否支持它。
The QCD_TOKEN notification is related to the IKE SA and should follow the AUTH payload and precede the Configuration payload and all payloads related to the child SA.
QCD_令牌通知与IKE SA相关，并且应该在验证有效负载之后，在配置有效负载和与子SA相关的所有有效负载之前。
After rekeying an IKE SA, the IKE SPIs are replaced, so the new SA also needs to have a token. If only the responder in the rekey exchange is the token maker, this can be done within the CREATE_CHILD_SA exchange. If the initiator is a token maker, then we need an extra informational exchange.
在为IKE SA重新设置密钥后，IKE SPI将被替换，因此新SA还需要具有令牌。如果只有密钥交换中的响应者是令牌制造者，那么这可以在CREATE_CHILD_SA交换中完成。如果启动器是令牌生成器，那么我们需要额外的信息交换。
The following figure shows the CREATE_CHILD_SA exchange for rekeying the IKE SA. Only the responder sends a QCD token.
下图显示了用于重新设置IKE SA密钥的CREATE_CHILD_SA交换。只有响应者发送QCD令牌。
request --> SA, Ni, [KEi]
请求-->SA，Ni，[KEi]
response <-- SA, Nr, [KEr], N(QCD_TOKEN)
响应<--SA，Nr，[KEr]，N（QCD_令牌）
If the initiator is also a token maker, it SHOULD initiate an INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as follows:
如果发起人也是令牌制造者，则应在创建子令牌交换后立即发起信息交换，如下所示：
request --> N(QCD_TOKEN)
request --> N(QCD_TOKEN)
response <--
回应<--
For session resumption, as specified in [RFC5723], the situation is similar. The responder, which is necessarily the peer that has crashed, SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.
对于[RFC5723]中规定的会话恢复，情况类似。响应者（必然是崩溃的对等方）应该在IKE_会话_恢复交换的受保护负载内发送新的票证。如果发起方也是令牌制造者，则需要在单独的信息交换中发送QCD_令牌。
The INFORMATIONAL exchange described in this section can also be used if QCD tokens need to be replaced due to a key rollover. However, since token takers are required to verify at least 4 QCD tokens, this is only necessary if secret QCD keys are rolled over more than four times as often as IKE SAs are rekeyed. See Section 5.1 for an example method that uses secret keys that may require rollover.
如果由于密钥翻转需要更换QCD令牌，也可以使用本节中描述的信息交换。然而，由于令牌接受者需要验证至少4个QCD令牌，因此只有当密钥QCD密钥的滚动频率是IKE SA重新密钥的四倍以上时，才需要验证。有关使用可能需要滚动的密钥的示例方法，请参见第5.1节。
With some token generation methods, such as that described in Section 5.2, a QCD token may sometimes become invalid, although the IKE SA is still perfectly valid.
对于某些令牌生成方法，如第5.2节所述，QCD令牌有时可能会失效，尽管IKE SA仍然完全有效。
In such a case, the token maker MUST send the new token in a protected message under that IKE SA. That exchange could be a simple INFORMATIONAL, such as in the last figure in the previous section, or else it can be part of a MOBIKE INFORMATIONAL exchange such as in the following figure taken from Section 2.2 of [RFC4555] and modified by adding a QCD_TOKEN notification:
在这种情况下，令牌制造商必须在该IKE SA下的受保护消息中发送新令牌。该交换可以是一个简单的信息交换，如前一节的最后一个图所示，也可以是MOBIKE信息交换的一部分，如下图所示，取自[RFC4555]第2.2节，并通过添加QCD_令牌通知进行修改：
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2), [N(QCD_TOKEN)] }
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2), [N(QCD_TOKEN)] }
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(COOKIE2), [N(QCD_TOKEN)] } -->
(IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(COOKIE2), [N(QCD_TOKEN)] } -->
A token taker MUST accept such gratuitous QCD_TOKEN notifications as long as they are carried in protected exchanges. A token maker SHOULD NOT generate them unless it is no longer able to generate the old QCD_TOKEN.
令牌接受者必须接受这种免费的QCD_令牌通知，只要它们是在受保护的交换中携带的。令牌制造商不应生成它们，除非它不再能够生成旧的QCD_令牌。
This QCD_TOKEN notification is unprotected, and is sent as a response to a protected IKE request, which uses an IKE SA that is unknown.
此QCD_令牌通知不受保护，并作为对受保护IKE请求的响应发送，该请求使用未知的IKE SA。
message --> N(INVALID_IKE_SPI), N(QCD_TOKEN)+
message --> N(INVALID_IKE_SPI), N(QCD_TOKEN)+
If child SPIs are persistently mapped to IKE SPIs as described in Section 8.2, a token taker may get the following unprotected message in response to an Encapsulating Security Payload (ESP) or Authentication Header (AH) packet.
如第8.2节所述，如果子SPI持续映射到IKE SPI，则令牌接收者可能会收到以下未受保护的消息，以响应封装安全负载（ESP）或身份验证头（AH）数据包。
message --> N(INVALID_SPI), N(QCD_TOKEN)+
message --> N(INVALID_SPI), N(QCD_TOKEN)+
The QCD_TOKEN and INVALID_IKE_SPI notifications are sent together to support both implementations that conform to this specification and implementations that don't. Similar to the description in Section 2.21 of [RFC5996], the IKE SPI and message ID fields in the packet headers are taken from the protected IKE request.
QCD_令牌和无效_IKE_SPI通知一起发送，以支持符合此规范的实现和不符合此规范的实现。与[RFC5996]第2.21节中的描述类似，数据包头中的IKE SPI和消息ID字段取自受保护的IKE请求。
To support a periodic rollover of the secret used for token generation, the token taker MUST support at least four QCD_TOKEN notifications in a single packet. The token is considered verified if any of the QCD_TOKEN notifications matches. The token maker MAY generate up to four QCD_TOKEN notifications, based on several generations of keys.
为了支持用于令牌生成的秘密的定期滚动，令牌接收者必须在单个数据包中支持至少四个QCD_令牌通知。如果任何QCD_令牌通知匹配，则认为该令牌已验证。令牌制造商可以基于几代密钥生成多达四个QCD_令牌通知。
If the QCD_TOKEN verifies OK, the receiver MUST silently discard the IKE SA and all associated child SAs. If the QCD_TOKEN cannot be validated, a response MUST NOT be sent, and the event may be logged. Section 5 defines token verification.
如果QCD_令牌验证为OK，则接收器必须静默地丢弃IKE SA和所有关联的子SA。如果无法验证QCD_令牌，则不得发送响应，并且可能会记录事件。第5节定义了令牌验证。
No token generation method is mandated by this document. Two methods are documented in the following sub-sections, but they only serve as examples.
本文档未强制要求任何令牌生成方法。以下小节中记录了两种方法，但它们仅用作示例。
The following lists the requirements for a token generation mechanism:
以下列出了令牌生成机制的要求：
o Tokens MUST be at least 16 octets long, and no more than 128 octets long, to facilitate storage and transmission. Tokens SHOULD be indistinguishable from random data.
o 令牌长度必须至少为16个八位字节，且不超过128个八位字节，以便于存储和传输。令牌应该与随机数据无法区分。
o It should not be possible for an external attacker to guess the QCD token generated by an implementation. Cryptographic mechanisms such as a pseudo-random number generator (PRNG) and hash functions are RECOMMENDED.
o 外部攻击者不可能猜测实现生成的QCD令牌。建议使用伪随机数生成器（PRNG）和哈希函数等加密机制。
o The token maker MUST be able to re-generate or retrieve the token based on the IKE SPIs even after it reboots.
o 令牌生成器必须能够基于IKE SPI重新生成或检索令牌，即使在其重新启动后也是如此。
o The method of token generation MUST be such that a collision of QCD tokens between different pairs of IKE SPI will be highly unlikely.
o 令牌生成的方法必须确保不同IKE SPI对之间QCD令牌的冲突极不可能发生。
For verification, the token taker makes a bitwise comparison of the token stored along with the IKE SA with the token sent in the unprotected message. Multihomed takers might flip back-and-forth between several addresses, and have their tokens replaced as described in Section 4.4. To help avoid the case where the latest stored token does not match the address used after the maker lost state, the token taker MAY store several earlier tokens associated with the IKE SA, and silently discard the SA if any of them matches.
为了验证，令牌接受者将与IKE SA一起存储的令牌与未受保护消息中发送的令牌进行逐位比较。多宿接收者可能在多个地址之间来回切换，并按照第4.4节所述更换其令牌。为了帮助避免最新存储的令牌与maker丢失状态后使用的地址不匹配的情况，令牌接受者可以存储几个与IKE SA相关联的早期令牌，并在其中任何一个匹配时自动丢弃SA。
The following describes a stateless method of generating a token. In this case, 'stateless' means not maintaining any per-tunnel state, although there is a small amount of non-volatile storage required.
下面描述生成令牌的无状态方法。在这种情况下，“无状态”意味着不维护任何每通道状态，尽管需要少量非易失性存储。
o At installation or immediately after the first boot of the token maker, 32 random octets are generated using a secure random number generator or a PRNG.
o 在安装时或令牌生成器首次启动后，使用安全随机数生成器或PRNG生成32个随机八位字节。
o Those 32 bytes, called the "QCD_SECRET", are stored in non-volatile storage on the machine, and kept indefinitely.
o 这32个字节被称为“QCD_机密”，存储在机器上的非易失性存储器中，并无限期保存。
o If key rollover is required by policy, the implementation MAY periodically generate a new QCD_SECRET and keep up to 3 previous generations. When sending an unprotected QCD_TOKEN, as many as 4 notification payloads may be sent, each from a different QCD_SECRET.
o 如果策略要求密钥滚动，则实现可能会定期生成新的QCD_密钥，并最多保留前三代密钥。发送未受保护的QCD_令牌时，最多可发送4个通知有效负载，每个有效负载来自不同的QCD_密钥。
o The TOKEN_SECRET_DATA is calculated as follows:
o 令牌\u秘密\u数据的计算如下：
TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R)
令牌_SECRET_DATA=HASH（QCD_SECRET | SPI-I | SPI-R）
This method is similar to the one in the previous section, except that the IP address of the token taker is also added to the block being hashed. This has the disadvantage that the token needs to be replaced (as described in Section 4.4) whenever the token taker changes its address.
此方法与上一节中的方法类似，不同之处在于令牌接收者的IP地址也被添加到正在散列的块中。这样做的缺点是，每当令牌接受者更改其地址时，都需要更换令牌（如第4.4节所述）。
See Section 9.2 for a discussion of a use-case for this method. When using this method, the TOKEN_SECRET_DATA field is calculated as follows:
有关此方法的用例讨论，请参见第9.2节。使用此方法时，TOKEN_SECRET_数据字段的计算如下：
TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T)
令牌_SECRET_DATA=HASH（QCD_SECRET | SPI-I | SPI-R | IPaddr-T）
The IPaddr-T field specifies the IP address of the token taker. Secret rollover considerations are similar to those in the previous section.
IPaddr-T字段指定令牌接收者的IP地址。秘密滚动注意事项与上一节中的注意事项类似。
Note that with a multihomed token taker, the QCD token matches just one of the token taker IP addresses. Usually this is not a problem, as packets sent to the token maker come out the same IP address. If for some reason this changes, then the token maker can replace the token as described in Section 4.4. If IKEv2 Mobility and Multihoming (MOBIKE) is used, replacing the tokens SHOULD be piggybacked on the INFORMATIONAL exchange with the UPDATE_SA_ADDRESSES notifications.
请注意，对于多宿令牌接受者，QCD令牌仅与令牌接受者IP地址中的一个匹配。通常这不是问题，因为发送到令牌制造商的数据包的IP地址相同。如果由于某种原因发生变化，则令牌制造商可以按照第4.4节所述更换令牌。如果使用IKEv2 Mobility and Multihoming（MOBIKE），则应在信息交换上使用更新地址通知替换令牌。
There is a corner case where the token taker begins using a new IP address (because of multihoming, roaming, or normal network operations) and the token maker loses state before replacing the token. In that case, it will send a correct QCD token, but the token taker will still have the old token. In that case, the extension will not work, and the peers will revert to RFC 5996 recovery.
在这种情况下，令牌接受者开始使用新的IP地址（由于多归属、漫游或正常网络操作），令牌制造商在更换令牌之前会失去状态。在这种情况下，它将发送一个正确的QCD令牌，但令牌接收者仍将拥有旧令牌。在这种情况下，扩展将无法工作，对等方将恢复到RFC 5996恢复。
The token is associated with a single IKE SA and SHOULD be deleted by the token taker when the SA is deleted or expires. More formally, the token is associated with the pair (SPI-I, SPI-R).
令牌与单个IKE SA关联，当SA被删除或过期时，令牌接收者应将其删除。更正式地说，令牌与该对（SPI-I，SPI-R）相关联。
Making crash detection and recovery quick is a worthy goal, but since rebooting a gateway takes a non-zero amount of time, many implementations choose to have a standby gateway ready to take over as soon as the primary gateway fails for any reason. [RFC6027] describes considerations for such clusters of gateways with synchronized state, but the rest of this section is relevant even when there is no synchronized state.
使崩溃检测和恢复快速是一个值得追求的目标，但由于重新启动网关需要非零的时间，因此许多实现选择在主网关因任何原因出现故障时，让备用网关随时准备接管。[RFC6027]描述了具有同步状态的网关集群的注意事项，但本节的其余部分即使在没有同步状态的情况下也是相关的。
If such a configuration is available, it is RECOMMENDED that the standby gateway be able to generate the same token as the active gateway. If the method described in Section 5.1 is used, this means that the QCD_SECRET field is identical in both gateways. This has the effect of having the crash recovery available immediately.
如果这种配置可用，建议备用网关能够生成与活动网关相同的令牌。如果使用第5.1节中描述的方法，这意味着两个网关中的QCD_秘密字段是相同的。这会使崩溃恢复立即可用。
Note that this refers to "high-availability" configurations, where only one gateway is active at any given moment. This is different from "load sharing" configurations where more than one gateway is active at the same time. For load sharing configurations, please see Section 9.2 for security considerations.
请注意，这指的是“高可用性”配置，其中在任何给定时刻只有一个网关处于活动状态。这与多个网关同时处于活动状态的“负载共享”配置不同。有关负载共享配置，请参阅第9.2节了解安全注意事项。
Session resumption, specified in [RFC5723], allows the setting up of a new IKE SA to consume less computing resources. This is particularly useful in the case of a remote access gateway that has many tunnels. A failure of such a gateway requires all these many remote access clients to establish an IKE SA either with the rebooted gateway or with a backup. This tunnel re-establishment occurs within a short period of time, creating a burden on the remote access gateway. Session resumption addresses this problem by having the clients store an encrypted derivative of the IKE SA for quick re-establishment.
[RFC5723]中指定的会话恢复允许设置新的IKE SA以消耗更少的计算资源。这在具有许多隧道的远程访问网关的情况下特别有用。这种网关的故障需要所有这些远程访问客户端通过重新启动的网关或备份来建立IKE SA。此隧道重建在短时间内发生，对远程访问网关造成负担。会话恢复通过让客户端存储IKE SA的加密衍生物以快速重新建立来解决此问题。
What Session Resumption does not help is the problem of detecting that the peer gateway has failed. A failed gateway may go undetected for an arbitrarily long time, because IPsec does not have packet acknowledgement, and applications cannot signal the IPsec layer that the tunnel "does not work". Section 2.4 of RFC 5996 does not specify how long an implementation needs to wait before beginning a liveness check, and only says "not recently" (see full quote in Section 2). In practice, some mobile devices wait a very long time before beginning a liveness check, in order to extend battery life by allowing parts of the device to remain in low-power modes.
会话恢复没有帮助的是检测对等网关故障的问题。由于IPsec没有数据包确认，应用程序无法向IPsec层发出隧道“不工作”的信号，因此发生故障的网关可能在任意长的时间内未被检测到。RFC 5996的第2.4节没有指定在开始活动性检查之前实现需要等待多长时间，只是说“不是最近”（请参阅第2节中的完整引用）。实际上，一些移动设备在开始活动性检查之前会等待很长时间，以便通过允许设备的某些部分保持低功耗模式来延长电池寿命。
QCD tokens provide a way to detect the failure of the peer in the case where a liveness check has not yet ended (or begun).
QCD令牌提供了一种在活动性检查尚未结束（或开始）的情况下检测对等方故障的方法。
A remote access client conforming to both specifications will store QCD tokens, as well as the Session Resumption ticket, if provided by the gateway. A remote access gateway conforming to both specifications will generate a QCD token for the client. When the gateway reboots, the client will discover this in either of two ways:
符合这两个规范的远程访问客户端将存储QCD令牌以及会话恢复票证（如果网关提供）。符合这两个规范的远程访问网关将为客户端生成QCD令牌。网关重新启动时，客户端将通过以下两种方式之一发现此问题：
1. The client does regular liveness checks, or else the time for some other IKE exchange has come. Since the gateway is still down, the IKE exchange times out after several minutes. In this case, QCD does not help.
1. 客户机定期进行活动性检查，或者进行其他IKE交换的时间到了。由于网关仍处于关闭状态，IKE交换在几分钟后超时。在这种情况下，QCD没有帮助。
2. Either the primary gateway or a backup gateway (see Section 6) is ready and sends a QCD token to the client. In that case, the client will quickly re-establish the IPsec tunnel, either with the rebooted primary gateway or the backup gateway as described in this document.
2. 主网关或备份网关（参见第6节）已准备就绪，并向客户端发送QCD令牌。在这种情况下，客户端将使用重新启动的主网关或备份网关（如本文档所述）快速重新建立IPsec隧道。
The full combined protocol looks like this:
完整的组合协议如下所示：
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
<--HDR、SAr1、KEr、Nr、[CERTREQ]
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,]
AUTH, N(QCD_TOKEN)
SAi2, TSi, TSr,
N(TICKET_REQUEST)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
N(QCD_TOKEN), SAr2, TSi, TSr,
N(TICKET_LT_OPAQUE) }
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,]
AUTH, N(QCD_TOKEN)
SAi2, TSi, TSr,
N(TICKET_REQUEST)} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
N(QCD_TOKEN), SAr2, TSi, TSr,
N(TICKET_LT_OPAQUE) }
---- Reboot -----
---- Reboot -----
HDR, {} -->
<-- HDR, N(QCD_TOKEN)
HDR, {} -->
<-- HDR, N(QCD_TOKEN)
HDR, [N(COOKIE),]
Ni, N(TICKET_OPAQUE)
[,N+] -->
<-- HDR, Nr [,N+]
HDR, [N(COOKIE),]
Ni, N(TICKET_OPAQUE)
[,N+] -->
<-- HDR, Nr [,N+]
Throughout this document, we have referred to reboot time alternatingly as the time that the implementation crashes and the time when it is ready to process IPsec packets and IKE exchanges. Depending on the hardware and software platforms and the cause of the reboot, rebooting may take anywhere from a few seconds to several minutes. If the implementation is down for a long time, the benefit of this protocol extension is reduced. For this reason, critical systems should implement backup gateways as described in Section 6.
在本文档中，我们交替地将重新启动时间称为实现崩溃的时间和准备处理IPsec数据包和IKE交换的时间。根据硬件和软件平台以及重新启动的原因，重新启动可能需要几秒钟到几分钟的时间。如果实现中断很长时间，此协议扩展的好处就会降低。因此，关键系统应实施第6节所述的备份网关。
Implementing the "token maker" side of QCD makes sense for IKE implementation where protected connections originate from the peer, such as inter-domain VPNs and remote access gateways. Implementing the "token taker" side of QCD makes sense for IKE implementations where protected connections originate, such as inter-domain VPNs and remote access clients.
实现QCD的“令牌制造者”端对于IKE实现是有意义的，在IKE实现中，受保护的连接来自对等方，例如域间VPN和远程访问网关。实现QCD的“令牌接受者”端对于发起受保护连接的IKE实现是有意义的，例如域间VPN和远程访问客户端。
To clarify this discussion:
为了澄清这一讨论：
o For remote-access clients it makes sense to implement the token taker role.
o 对于远程访问客户端，实现令牌接收者角色是有意义的。
o For remote-access gateways it makes sense to implement the token maker role.
o 对于远程访问网关，实现令牌生成器角色是有意义的。
o For inter-domain VPN gateways it makes sense to implement both roles, because it can't be known in advance where the traffic originates.
o 对于域间VPN网关来说，实现这两个角色是有意义的，因为无法预先知道流量的来源。
o It is perfectly valid to implement both roles in any case, for example, when using a single library or a single gateway to perform several roles.
o 在任何情况下实现这两个角色都是完全有效的，例如，当使用单个库或单个网关执行多个角色时。
In order to limit the effects of Denial-of-Service (DoS) attacks, a token taker SHOULD limit the rate of QCD_TOKENs verified from a particular source.
为了限制拒绝服务（DoS）攻击的影响，令牌接收者应限制从特定来源验证QCD_令牌的速率。
If excessive amounts of IKE requests protected with unknown IKE SPIs arrive at a token maker, the IKE module SHOULD revert to the behavior described in Section 2.21 of [RFC5996] and either send an INVALID_IKE_SPI notification or ignore it entirely.
如果使用未知IKE SPI保护的过多IKE请求到达令牌制造商，IKE模块应恢复到[RFC5996]第2.21节中描述的行为，并发送无效的IKE SPI通知或完全忽略它。
Section 9.2 requires that token makers never send a QCD token in the clear for a valid IKE SA and describes some configurations where this could occur. Implementations that may be installed in such configurations SHOULD automatically detect this and disable this extension in unsafe configurations and MUST allow the user to control whether the extension is enabled or disabled.
第9.2节要求令牌制造商不得在clear中为有效的IKE SA发送QCD令牌，并描述了可能发生这种情况的一些配置。可能安装在此类配置中的实现应自动检测并在不安全配置中禁用此扩展，并且必须允许用户控制是启用还是禁用扩展。
After a reboot, it is more likely that an implementation will receive IPsec packets than IKE packets. In that case, the rebooted implementation will send an INVALID_SPI notification, triggering a liveness check. The token will only be sent in a response to the liveness check, thus requiring an extra round trip.
重新启动后，实现更有可能接收IPsec数据包，而不是IKE数据包。在这种情况下，重新启动的实现将发送一个无效的\u SPI通知，触发活动性检查。令牌将仅作为对活动性检查的响应发送，因此需要额外的往返。
To avoid this, an implementation that has access to enough non-volatile storage MAY store a mapping of child SPIs to owning IKE SPIs, or to generated tokens. If such a mapping is available and persistent across reboots, the rebooted implementation SHOULD respond to the IPsec packet with an INVALID_SPI notification, along with the appropriate QCD_TOKEN notifications. A token taker SHOULD verify the QCD token that arrives with an INVALID_SPI notification the same as if it arrived with the IKE SPIs of the parent IKE SA.
为了避免这种情况，可以访问足够的非易失性存储的实现可以存储子SPI到拥有IKE SPI或生成令牌的映射。如果这种映射在重新启动期间可用且持久，则重新启动的实现应使用无效的\u SPI通知以及相应的QCD\u令牌通知响应IPsec数据包。令牌接受者应验证随无效_SPI通知到达的QCD令牌，就像它随父IKE SA的IKE SPI到达一样。
However, a persistent storage module might not be updated in a timely manner and could be populated with tokens relating to IKE SPIs that have already been rekeyed. A token taker MUST NOT take an invalid QCD token sent along with an INVALID_SPI notification as evidence that the peer is either malfunctioning or attacking, but it SHOULD limit the rate at which such notifications are processed.
但是，持久性存储模块可能不会及时更新，并且可能会填充与已重新设置密钥的IKE SPI相关的令牌。令牌接收者不得将随无效_SPI通知一起发送的无效QCD令牌作为对等方出现故障或攻击的证据，但应限制此类通知的处理速率。
The extension described in this document must not reduce the security of IKEv2 or IPsec. Specifically, an eavesdropper must not learn any non-public information about the peers.
本文档中描述的扩展不得降低IKEv2或IPsec的安全性。具体而言，窃听者不得了解任何关于对等方的非公开信息。
The proposed mechanism should be secure against attacks by a passive man in the middle (MITM) (eavesdropper). Such an attacker must not be able to disrupt an existing IKE session, either by resetting the session or by introducing significant delays. This requirement is especially significant, because this document introduces a new way to reset an IKE SA.
所提出的机制应该是安全的，以防止被动的中间人（MITM）（窃听者）的攻击。此类攻击者不得通过重置会话或引入显著延迟来中断现有IKE会话。这一要求特别重要，因为本文档介绍了重置IKE SA的新方法。
The mechanism need not be similarly secure against an active MITM, since this type of attacker is already able to disrupt IKE sessions.
该机制不需要对活动的MITM具有类似的安全性，因为这种类型的攻击者已经能够中断IKE会话。
Tokens MUST be hard to guess. This is critical, because if an attacker can guess the token associated with an IKE SA, they can tear down the IKE SA and associated tunnels at will. When the token is delivered in the IKE_AUTH exchange, it is encrypted. When it is sent again in an unprotected notification, it is not, but that is the last time this token is ever used.
代币一定很难猜。这是至关重要的，因为如果攻击者能够猜出与IKE SA关联的令牌，他们可以随意拆除IKE SA和关联的隧道。当令牌在IKE_身份验证交换中传递时，它将被加密。如果在未受保护的通知中再次发送，则不会发送，但这是最后一次使用此令牌。
An aggregation of some tokens generated by one maker together with the related IKE SPIs MUST NOT give an attacker the ability to guess other tokens. Specifically, if one taker does not properly secure the QCD tokens and an attacker gains access to them, this attacker MUST NOT be able to guess other tokens generated by the same maker. This is the reason that the QCD_SECRET in Section 5.1 needs to be sufficiently long.
一个制造商生成的某些令牌与相关IKE SPI的聚合不得使攻击者能够猜测其他令牌。具体地说，如果一个攻击者没有正确保护QCD令牌，并且攻击者获得了对它们的访问权，那么该攻击者必须无法猜测同一制造商生成的其他令牌。这就是第5.1节中QCD_机密需要足够长的原因。
The token taker MUST store the token in a secure manner. No attacker should be able to gain access to a stored token.
令牌接受者必须以安全的方式存储令牌。任何攻击者都不能访问存储的令牌。
The QCD_SECRET MUST be protected from access by other parties. Anyone gaining access to this value will be able to delete all the IKE SAs for this token maker.
必须保护QCD_机密，防止其他方访问。任何获得此值访问权限的人都可以删除此令牌制造商的所有IKE SA。
The QCD token is sent by the rebooted peer in an unprotected message. A message like that is subject to modification, deletion, and replay by an attacker. However, these attacks will not compromise the security of either side. Modification is meaningless because a modified token is simply an invalid token. Deletion will only cause the protocol not to work, resulting in a delay in tunnel re-establishment as described in Section 2. Replay is also meaningless, because the IKE SA has been deleted after the first transmission.
QCD令牌由重新启动的对等方在未受保护的消息中发送。这样的消息可能会被攻击者修改、删除和重播。然而，这些攻击不会损害任何一方的安全。修改是没有意义的，因为修改后的令牌只是一个无效的令牌。删除只会导致协议不起作用，导致隧道重建延迟，如第2节所述。重播也没有意义，因为IKE SA在第一次传输后已被删除。
A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA.
令牌生成器不得在现有IKE SA的未受保护消息中发送有效的QCD令牌。
This requirement is obvious and easy in the case of a single gateway. However, some implementations use a load balancer to divide the load between several physical gateways. It MUST NOT be possible even in such a configuration to trick one gateway into sending a valid QCD token for an IKE SA that is valid on another gateway. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address.
在单个网关的情况下，这一要求显而易见且简单。但是，有些实现使用负载平衡器在几个物理网关之间分配负载。即使在这种配置中，也不可能欺骗一个网关为另一个网关上有效的IKE SA发送有效的QCD令牌。无论欺骗网关的尝试使用令牌接收者的IP地址还是其他IP地址，都是如此。
IPsec failure detection is not applicable to deployments where the QCD secret is shared by multiple gateways and the gateways cannot assess whether the token can be legitimately sent in the clear while another gateway may actually still own the SA's. Load balancing configurations typically fall in this category. In order for a load balancing configuration of IPsec gateways to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster. One way to do this is to synchronize a list of active IKE SPIs among all the cluster members.
IPsec故障检测不适用于QCD机密由多个网关共享的部署，并且网关无法评估令牌是否可以合法地以明文形式发送，而另一个网关可能仍然实际拥有SA。负载平衡配置通常属于这一类。为了使IPsec网关的负载平衡配置支持此规范，所有成员必须能够判断特定IKE SA是否在群集中的任何位置处于活动状态。一种方法是在所有集群成员之间同步活动IKE SPI的列表。
Because it includes the token taker's IP address in the token generation, the method in Section 5.2 can (under certain conditions) prevent revealing the QCD token for an existing pair of IKE SPIs to an attacker who is using a different IP address, even in a load-sharing cluster without state synchronization. That method does not prevent revealing the QCD token to an active attacker who is spoofing the token taker's IP address. Such an attacker may attempt to direct messages to a cluster member other than the member responsible for
由于在令牌生成过程中包含令牌接受者的IP地址，因此第5.2节中的方法（在某些条件下）可以防止向使用不同IP地址的攻击者泄露现有IKE SPI对的QCD令牌，即使在没有状态同步的负载共享群集中也是如此。该方法不会阻止将QCD令牌泄露给正在欺骗令牌接收者IP地址的活动攻击者。此类攻击者可能会试图将消息定向到除负责
the IKE SA in an attempt to trick that gateway into sending a QCD token for a valid IKE SA. That method should not be used unless the load balancer guarantees that IKE packets from the same source IP address always go to the same cluster member.
IKE SA试图欺骗该网关为有效的IKE SA发送QCD令牌。除非负载平衡器保证来自同一源IP地址的IKE数据包始终到达同一集群成员，否则不应使用该方法。
An attacker may try to attack QCD if the generation algorithm described in Section 5.1 is used. The attacker will send several fake IKE requests to the gateway under attack, receiving and recording the QCD tokens in the responses. This will allow the attacker to create a dictionary of IKE SPIs to QCD tokens, which can later be used to tear down any IKE SA.
如果使用第5.1节中描述的生成算法，攻击者可能会尝试攻击QCD。攻击者将向受攻击的网关发送多个伪造的IKE请求，并在响应中接收和记录QCD令牌。这将允许攻击者创建一个IKE SPI到QCD令牌的字典，该字典稍后可用于拆除任何IKE SA。
Three factors mitigate this threat:
有三个因素可以缓解这一威胁：
o The space of all possible IKE SPI pairs is huge: 2^128, so making such a dictionary is impractical. Even if we assume that one implementation always generates predictable IKE SPIs, the space is still at least 2^64 entries, so making the dictionary is extremely hard. To ensure this, token makers MUST generate unpredictable IKE SPIs by using a cryptographically strong pseudo-random number generator.
o 所有可能的IKE SPI对的空间都很大：2^128，因此制作这样的字典是不切实际的。即使我们假设一个实现总是生成可预测的IKE SPI，空间仍然至少有2^64个条目，因此制作字典非常困难。为了确保这一点，令牌制造商必须使用加密强伪随机数生成器生成不可预测的IKE SPI。
o Throttling the amount of QCD_TOKEN notifications sent out, as discussed in Section 8.1, especially when not soon after a crash will limit the attacker's ability to construct a dictionary.
o 如第8.1节所述，限制发送的QCD_令牌通知的数量，特别是在崩溃后不久，这将限制攻击者构建字典的能力。
o The methods in Section 5.1 and Section 5.2 allow for a periodic change of the QCD_SECRET. Any such change invalidates the entire dictionary.
o 第5.1节和第5.2节中的方法允许定期更改QCD_机密。任何这样的更改都会使整个词典失效。
IANA has assigned a notify message type (16419) from the status types range (16406-40959) of the "IKEv2 Notify Message Types" registry with the name "QUICK_CRASH_DETECTION".
IANA已从“IKEv2 notify message types”注册表的状态类型范围（16406-40959）中分配了一个名为“QUICK_CRASH_DETECTION”的通知消息类型（16419）。
We would like to thank Hannes Tschofenig and Yaron Sheffer for their comments about Session Resumption.
我们要感谢Hannes Tschofenig和Yaron Sheffer对会议复会的评论。
Others who have contributed valuable comments are, in alphabetical order, Lakshminath Dondeti, Paul Hoffman, Tero Kivinen, Scott C Moonen, Magnus Nystrom, and Keith Welter.
按字母顺序排列，其他发表了宝贵评论的人有Lakshminath Dondeti、Paul Hoffman、Tero Kivinen、Scott C Moonen、Magnus Nystrom和Keith Welter。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723]Sheffer，Y.和H.Tschofenig，“互联网密钥交换协议第2版（IKEv2）会话恢复”，RFC 57232010年1月。
[RFC6027] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
[RFC6027]Nir，Y，“IPsec群集问题声明”，RFC 6027，2010年10月。
[recovery] Detienne, F., Sethi, P., and Y. Nir, "Safe IKE Recovery", Work in Progress, July 2009.
[恢复]Detienne，F.，Sethi，P.，和Y.Nir，“安全IKE恢复”，正在进行的工作，2009年7月。
Instead of sending a QCD token, we could have the rebooted implementation start an Initial exchange with the peer, including the INITIAL_CONTACT notification. This would have the same effect, instructing the peer to erase the old IKE SA, as well as establishing a new IKE SA with fewer rounds.
我们可以让重新启动的实现启动与对等方的初始交换，包括初始_联系人通知，而不是发送QCD令牌。这将具有相同的效果，指示对等方擦除旧的IKE SA，以及用更少的回合建立新的IKE SA。
The disadvantage here is that in IKEv2, an authentication exchange MUST have a piggybacked Child SA set up. Since our use-case is such that the rebooted implementation does not have traffic flowing to the peer, there are no good selectors for such a Child SA.
这里的缺点是，在IKEv2中，身份验证交换必须设置一个子SA。因为我们的用例是这样的，重新启动的实现没有流向对等方的流量，所以对于这样的子SA没有好的选择器。
Additionally, when authentication is asymmetric, such as when EAP is used, it is not possible for the rebooted implementation to initiate IKE.
此外，当身份验证是非对称的时，例如使用EAP时，重新启动的实现不可能启动IKE。
Another proposal that was considered for this work item is the SIR extension, which is described in [recovery]. Under that proposal, the non-rebooted peer sends a non-protected query to the possibly rebooted peer, asking whether the IKE SA exists. The peer replies with either a positive or negative response, and the absence of a positive response, along with the existence of a negative response, is taken as proof that the IKE SA has really been lost.
为本工作项目考虑的另一个提案是SIR扩展，在[恢复]中进行了描述。根据该方案，未重新启动的对等方向可能重新启动的对等方发送一个不受保护的查询，询问IKE SA是否存在。对等方以肯定或否定的响应进行回复，并且没有肯定响应以及否定响应的存在被视为IKE SA确实丢失的证据。
The working group preferred the QCD proposal to this one.
工作组倾向于QCD提案而非本提案。
Birth Certificates is a method of crash detection that has never been formally defined. Bill Sommerfeld suggested this idea in a mail to the IPsec mailing list on August 7, 2000, in a thread discussing methods of crash detection:
出生证明是一种从未正式定义过的碰撞检测方法。Bill Sommerfeld在2000年8月7日发送给IPsec邮件列表的邮件中提出了这一想法，在一篇讨论崩溃检测方法的文章中：
If we have the system sign a "birth certificate" when it reboots (including a reboot time or boot sequence number), we could include that with a "bad spi" ICMP error and in the negotiation of the IKE SA.
如果我们让系统在重新启动时签署“出生证书”（包括重新启动时间或启动序列号），我们可以在IKE SA协商中包含“坏spi”ICMP错误。
We believe that this method would have some problems. First, it requires Alice to store the certificate, so as to be able to compare the public keys. That requires more storage than does a QCD token. Additionally, the public key operations needed to verify the self-signed certificates are more expensive for Alice.
我们相信这种方法会有一些问题。首先，它要求Alice存储证书，以便能够比较公钥。这需要比QCD令牌更多的存储。此外，对于Alice来说，验证自签名证书所需的公钥操作成本更高。
We believe that a symmetric-key operation such as proposed here is more light-weight and simple than that implied by the Birth Certificate idea.
我们相信，像这里提出的对称密钥操作比出生证书思想所暗示的更轻、更简单。
Some implementations require fewer retransmissions over a shorter period of time for cases of liveness check started because of an INVALID_SPI or INVALID_IKE_SPI notification.
对于由于无效的_-SPI或无效的_-IKE_-SPI通知而启动的活动性检查，一些实现需要在较短的时间内进行较少的重新传输。
We believe that the default retransmission policy should represent a good balance between the need for a timely discovery of a dead peer, and a low probability of false detection. We expect the policy to be set to take the shortest time such that this probability achieves a certain target. Therefore, we believe that reducing the elapsed time and retransmission count may create an unacceptably high probability of false detection, and this can be triggered by a single INVALID_IKE_SPI notification.
我们认为，默认的重传策略应该在及时发现死点的需要和低错误检测概率之间取得良好的平衡。我们希望将策略设置为花费最短的时间，以使该概率达到某个目标。因此，我们认为，减少经过的时间和重传计数可能会产生不可接受的高错误检测概率，这可能由单个无效的_IKE_SPI通知触发。
Additionally, even if the retransmission policy is reduced to, say, one minute, it is still a very noticeable delay from a human perspective, from the time that the gateway has come up (i.e., is able to respond with an INVALID_SPI or INVALID_IKE_SPI notification) and until the tunnels are active, or from the time the backup gateway has taken over until the tunnels are active. The use of QCD tokens can reduce this delay.
此外，即使重传策略减少到（例如）一分钟，从人的角度来看，从网关出现的时间（即，能够使用无效的_SPI或无效的_IKE_SPI通知进行响应）到隧道处于活动状态，仍然是非常明显的延迟，或者从备份网关接管到隧道处于活动状态。使用QCD令牌可以减少这种延迟。
Authors' Addresses
作者地址
Yoav Nir (editor) Check Point Software Technologies, Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
Yoav Nir（编辑）Check Point软件技术有限公司以色列特拉维夫Hasolelim街5号67897
EMail: ynir@checkpoint.com
EMail: ynir@checkpoint.com
David Wierbowski International Business Machines 1701 North Street Endicott, New York 13760 United States
美国纽约州恩迪科特北街1701号David Wierbowski International Business Machines 13760
EMail: wierbows@us.ibm.com
EMail: wierbows@us.ibm.com
Frederic Detienne Cisco Systems, Inc. De Kleetlaan, 7 Diegem B-1831 Belgium
Frederic Detienne Cisco Systems，Inc.De Kleetlaan，7 Diegem B-1831比利时
Phone: +32 2 704 5681
EMail: fd@cisco.com
Phone: +32 2 704 5681
EMail: fd@cisco.com
Pratima Sethi Cisco Systems, Inc. O'Shaugnessy Road, 11 Bangalore, Karnataka 560027 India
Pratima Sethi Cisco Systems，Inc.印度卡纳塔克邦班加罗尔11号O'Shaugnessy路560027号
Phone: +91 80 4154 1654
EMail: psethi@cisco.com
Phone: +91 80 4154 1654
EMail: psethi@cisco.com