Network Working Group G. Huang
Request for Comments: 3706 S. Beaulieu
Category: Informational D. Rochefort
Cisco Systems, Inc.
February 2004
Network Working Group G. Huang
Request for Comments: 3706 S. Beaulieu
Category: Informational D. Rochefort
Cisco Systems, Inc.
February 2004
A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
一种基于流量的死密钥交换（IKE）节点检测方法
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document describes the method detecting a dead Internet Key Exchange (IKE) peer that is presently in use by a number of vendors. The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources.
本文档描述了检测死掉的Internet密钥交换（IKE）对等方的方法，该对等方目前正由多家供应商使用。该方法称为死对等检测（Dead Peer Detection，DPD），它使用IPSec通信模式来最小化确认活动性所需的IKE消息数量。与其他keepalive机制一样，需要DPD来确定何时执行IKE对等故障切换，以及回收丢失的资源。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 3
3. Rationale for Periodic Message Exchange for Proof of
Liveliness . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Keepalives vs. Heartbeats . . . . . . . . . . . . . . . . . . 3
4.1. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Heartbeats . . . . . . . . . . . . . . . . . . . . . . . 5
5. DPD Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. DPD Vendor ID. . . . . . . . . . . . . . . . . . . . . . 7
5.2. Message Exchanges. . . . . . . . . . . . . . . . . . . . 7
5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format . . . . . 8
5.4. Impetus for DPD Exchange . . . . . . . . . . . . . . . . 9
5.5. Implementation Suggestion. . . . . . . . . . . . . . . . 9
5.6. Comparisons. . . . . . . . . . . . . . . . . . . . . . . 10
6. Resistance to Replay Attack and False Proof of Liveliness. . . 10
6.1. Sequence Number in DPD Messages. . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Roadmap . . . . . . . . . . . . . . . . . . . . . . . 3
3. Rationale for Periodic Message Exchange for Proof of
Liveliness . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Keepalives vs. Heartbeats . . . . . . . . . . . . . . . . . . 3
4.1. Keepalives . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Heartbeats . . . . . . . . . . . . . . . . . . . . . . . 5
5. DPD Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. DPD Vendor ID. . . . . . . . . . . . . . . . . . . . . . 7
5.2. Message Exchanges. . . . . . . . . . . . . . . . . . . . 7
5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format . . . . . 8
5.4. Impetus for DPD Exchange . . . . . . . . . . . . . . . . 9
5.5. Implementation Suggestion. . . . . . . . . . . . . . . . 9
5.6. Comparisons. . . . . . . . . . . . . . . . . . . . . . . 10
6. Resistance to Replay Attack and False Proof of Liveliness. . . 10
6.1. Sequence Number in DPD Messages. . . . . . . . . . . . . 10
6.2. Selection and Maintenance of Sequence Numbers. . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative Reference. . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
6.2. Selection and Maintenance of Sequence Numbers. . . . . . 11
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative Reference. . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
10. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
When two peers communicate with IKE [2] and IPSec [3], the situation may arise in which connectivity between the two goes down unexpectedly. This situation can arise because of routing problems, one host rebooting, etc., and in such cases, there is often no way for IKE and IPSec to identify the loss of peer connectivity. As such, the SAs can remain until their lifetimes naturally expire, resulting in a "black hole" situation where packets are tunneled to oblivion. It is often desirable to recognize black holes as soon as possible so that an entity can failover to a different peer quickly. Likewise, it is sometimes necessary to detect black holes to recover lost resources.
当两个对等方与IKE[2]和IPSec[3]通信时，可能出现两个对等方之间的连接意外中断的情况。出现这种情况的原因可能是路由问题、一台主机重新启动等，在这种情况下，IKE和IPSec通常无法识别对等连接的丢失。因此，SAs可以一直保留到其生命周期自然到期，从而导致“黑洞”情况，即数据包通过隧道被遗忘。通常希望尽快识别黑洞，以便实体可以快速故障切换到不同的对等方。类似地，有时有必要探测黑洞以恢复丢失的资源。
This problem of detecting a dead IKE peer has been addressed by proposals that require sending periodic HELLO/ACK messages to prove liveliness. These schemes tend to be unidirectional (a HELLO only) or bidirectional (a HELLO/ACK pair). For the purpose of this document, the term "heartbeat" will refer to a unidirectional message to prove liveliness. Likewise, the term "keepalive" will refer to a bidirectional message.
检测死亡IKE对等点的问题已通过要求定期发送HELLO/ACK消息以证明其活跃性的建议得到解决。这些方案倾向于单向（仅HELLO）或双向（HELLO/ACK对）。在本文件中，术语“心跳”指的是证明生动性的单向消息。同样，术语“keepalive”将指双向消息。
The problem with current heartbeat and keepalive proposals is their reliance upon their messages to be sent at regular intervals. In the implementation, this translates into managing some timer to service these message intervals. Similarly, because rapid detection of the dead peer is often desired, these messages must be sent with some frequency, again translating into considerable overhead for message processing. In implementations and installations where managing large numbers of simultaneous IKE sessions is of concern, these regular heartbeats/keepalives prove to be infeasible.
当前heartbeat和keepalive提案的问题在于它们依赖于定期发送消息。在实现中，这转化为管理一些计时器来服务这些消息间隔。类似地，由于通常需要快速检测死点，因此必须以一定的频率发送这些消息，这同样会转化为消息处理的巨大开销。在需要管理大量并发IKE会话的实现和安装中，这些常规心跳/保持活动被证明是不可行的。
To this end, a number of vendors have implemented their own approach to detect peer liveliness without needing to send messages at regular intervals. This informational document describes the current practice of those implementations. This scheme, called Dead Peer Detection (DPD), relies on IKE Notify messages to query the liveliness of an IKE peer.
为此，许多供应商已经实现了自己的方法来检测对等活跃性，而无需定期发送消息。本信息性文档描述了这些实现的当前实践。此方案称为死对等检测（DPD），它依赖IKE Notify消息来查询IKE对等的活跃性。
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 RFC-2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[1]中所述进行解释。
As mentioned above, there are already proposed solutions to the problem of detecting dead peers. Section 3 elaborates the rationale for using an IKE message exchange to query a peer's liveliness. Section 4 examines a keepalives-based approach as well as a heartbeats-based approach. Section 5 presents the DPD proposal fully, highlighting differences between DPD and the schemes presented in Section 4 and emphasizing scalability issues. Section 6 examines security issues surrounding replayed messages and false liveliness.
如上所述，已经提出了检测死亡对等点的解决方案。第3节阐述了使用IKE消息交换来查询对等方活跃性的基本原理。第4节研究了基于keepalives的方法以及基于心跳的方法。第5节全面介绍了DPD提案，强调了DPD与第4节中介绍的方案之间的差异，并强调了可扩展性问题。第6节研究了围绕重播消息和虚假活跃性的安全问题。
As the introduction mentioned, it is often necessary to detect that a peer is unreachable as soon as possible. IKE provides no way for this to occur -- aside from waiting until the rekey period, then attempting (and failing the rekey). This would result in a period of loss connectivity lasting the remainder of the lifetime of the security association (SA), and in most deployments, this is unacceptable. As such, a method is needed for checking up on a peer's state at will. Different methods have arisen, usually using an IKE Notify to query the peer's liveliness. These methods rely on either a bidirectional "keepalive" message exchange (a HELLO followed by an ACK), or a unidirectional "heartbeat" message exchange (a HELLO only). The next section considers both of these schemes.
正如引言中提到的，通常需要尽快检测到无法访问对等方。IKE不提供发生这种情况的方法——除了等待重新密钥周期，然后尝试（并失败重新密钥）。这将导致在安全关联（SA）的剩余生命周期内持续一段时间的连接丢失，在大多数部署中，这是不可接受的。因此，需要一种方法来随意检查对等方的状态。出现了不同的方法，通常使用IKE Notify来查询对等方的活跃度。这些方法依赖于双向“keepalive”消息交换（HELLO后跟ACK）或单向“heartbeat”消息交换（仅HELLO）。下一节将考虑这两种方案。
4.1. Keepalives:
4.1. 禁区：
Consider a keepalives scheme in which peer A and peer B require regular acknowledgements of each other's liveliness. The messages are exchanged by means of an authenticated notify payload. The two peers must agree upon the interval at which keepalives are sent, meaning that some negotiation is required during Phase 1. For any prompt failover to be possible, the keepalives must also be sent at rather frequent intervals -- around 10 seconds or so. In this hypothetical keepalives scenario, peers A and B agree to exchange keepalives every 10 seconds. Essentially, every 10 seconds, one peer must send a HELLO to the other. This HELLO serves as proof of liveliness for the sending entity. In turn, the other peer must acknowledge each keepalive HELLO. If the 10 seconds elapse, and one side has not received a HELLO, it will send the HELLO message itself, using the peer's ACK as proof of liveliness. Receipt of either a
考虑一个KePayLayes方案，其中对等A和对等B需要对彼此的活泼性进行定期确认。消息通过经过身份验证的notify有效负载进行交换。两个对等方必须就发送keepalives的间隔达成一致，这意味着在第1阶段需要进行一些协商。要实现任何快速故障切换，还必须以相当频繁的间隔发送keepalives——大约10秒左右。在这个假设的keepalives场景中，对等点A和B同意每10秒交换一次keepalives。基本上，每10秒，一个对等方必须向另一个发送问候。此HELLO作为发送实体的生动性证明。反过来，另一个对等方必须相互确认keepalive HELLO。如果10秒钟过去了，而其中一方没有收到HELLO，它将自己发送HELLO消息，使用对等方的ACK作为生动性的证明。收到
HELLO or ACK causes an entity's keepalive timer to reset. Failure to receive an ACK in a certain period of time signals an error. A clarification is presented below:
HELLO或ACK导致实体的keepalive计时器重置。在特定时间段内未能接收到ACK表示错误。澄清如下：
Scenario 1: Peer A's 10-second timer elapses first, and it sends a HELLO to B. B responds with an ACK.
场景1：对等方A的10秒计时器先过，然后向B发送HELLO。B用ACK响应。
Peer A: Peer B:
10 second timer fires; ------>
wants to know that B is alive;
sends HELLO.
Receives HELLO; acknowledges
A's liveliness;
<------ resets keepalive timer, sends
ACK.
Receives ACK as proof of
B's liveliness; resets timer.
Peer A: Peer B:
10 second timer fires; ------>
wants to know that B is alive;
sends HELLO.
Receives HELLO; acknowledges
A's liveliness;
<------ resets keepalive timer, sends
ACK.
Receives ACK as proof of
B's liveliness; resets timer.
Scenario 2: Peer A's 10-second timer elapses first, and it sends a HELLO to B. B fails to respond. A can retransmit, in case its initial HELLO is lost. This situation describes how peer A detects its peer is dead.
场景2：对等方A的10秒计时器先过，然后向B发送HELLO。B无法响应。A可以重新传输，以防其初始HELLO丢失。这种情况描述了对等机A如何检测到其对等机已死亡。
Peer A: Peer B (dead):
对等A:对等B（死亡）：
10 second timer fires; ------X
wants to know that B is
alive; sends HELLO.
10 second timer fires; ------X
wants to know that B is
alive; sends HELLO.
Retransmission timer ------X
expires; initial message
could have been lost in
transit; A increments
error counter and
sends another HELLO.
Retransmission timer ------X
expires; initial message
could have been lost in
transit; A increments
error counter and
sends another HELLO.
---
---
After some number of errors, A assumes B is dead; deletes SAs and possibly initiates failover.
在出现一定数量的错误后，A认为B已死亡；删除SAs并可能启动故障切换。
An advantage of this scheme is that the party interested in the other peer's liveliness begins the message exchange. In Scenario 1, peer A is interested in peer B's liveliness, and peer A consequently sends
该方案的一个优点是，对另一个对等方的活跃性感兴趣的一方开始消息交换。在场景1中，对等方A对对等方B的活力感兴趣，因此对等方A发送
the HELLO. It is conceivable in such a scheme that peer B would never be interested in peer A's liveliness. In such a case, the onus would always lie on peer A to initiate the exchange.
你好。可以想象，在这样的方案中，对等方B永远不会对对等方a的活力感兴趣。在这种情况下，对等方a总是有责任发起交换。
4.2. Heartbeats:
4.2. 心跳：
By contrast, consider a proof-of-liveliness scheme involving unidirectional (unacknowledged) messages. An entity interested in its peer's liveliness would rely on the peer itself to send periodic messages demonstrating liveliness. In such a scheme, the message exchange might look like this:
相比之下，考虑一个涉及单向（未确认）消息的生动性方案的证明。对其对等方的活跃性感兴趣的实体将依靠对等方本身定期发送显示活跃性的消息。在这种方案中，消息交换可能如下所示：
Scenario 3: Peer A and Peer B are interested in each other's liveliness. Each peer depends on the other to send periodic HELLOs.
场景3：对等点A和对等点B对彼此的活力感兴趣。每个对等方都依赖另一方定期发送Hello。
Peer A: Peer B:
10 second timer fires; ------>
sends HELLO. Timer also
signals expectation of
B's HELLO.
Receives HELLO as proof of A's
liveliness.
Peer A: Peer B:
10 second timer fires; ------>
sends HELLO. Timer also
signals expectation of
B's HELLO.
Receives HELLO as proof of A's
liveliness.
<------ 10 second timer fires; sends
HELLO.
Receives HELLO as proof
of B's liveliness.
<------ 10 second timer fires; sends
HELLO.
Receives HELLO as proof
of B's liveliness.
Scenario 4: Peer A fails to receive HELLO from B and marks the peer dead. This is how an entity detects its peer is dead.
场景4：对等方A无法从B接收HELLO，并将对等方标记为已死亡。这就是实体检测其对等方已死亡的方式。
Peer A: Peer B (dead):
10 second timer fires; ------X
sends HELLO. Timer also
signals expectation of
B's HELLO.
Peer A: Peer B (dead):
10 second timer fires; ------X
sends HELLO. Timer also
signals expectation of
B's HELLO.
---
---
Some time passes and A assumes B is dead.
一段时间过去了，A认为B死了。
The disadvantage of this scheme is the reliance upon the peer to demonstrate liveliness. To this end, peer B might never be interested in peer A's liveliness. Nonetheless, if A is interested B's liveliness, B must be aware of this, and maintain the necessary state information to send periodic HELLOs to A. The disadvantage of
该方案的缺点是依赖于对等方来展示生动性。为此，对等体B可能永远不会对对等体A的活力感兴趣。尽管如此，如果A对B的活泼感兴趣，B必须意识到这一点，并保持必要的状态信息，以便定期向A发送问候
such a scheme becomes clear in the remote-access scenario. Consider a VPN aggregator that terminates a large number of sessions (on the order of 50,000 peers or so). Each peer requires fairly rapid failover, therefore requiring the aggregator to send HELLO packets every 10 seconds or so. Such a scheme simply lacks scalability, as the aggregator must send 50,000 messages every few seconds.
这种方案在远程访问场景中变得清晰。考虑一个VPN聚合器终止大量会话（按50000个对等点的顺序）。每个对等方都需要相当快速的故障切换，因此需要聚合器每隔10秒左右发送HELLO数据包。这种方案缺乏可伸缩性，因为聚合器必须每几秒钟发送50000条消息。
In both of these schemes (keepalives and heartbeats), some negotiation of message interval must occur, so that each entity can know how often its peer expects a HELLO. This immediately adds a degree of complexity. Similarly, the need to send periodic messages (regardless of other IPSec/IKE activity), also increases computational overhead to the system.
在这两种方案（keepalives和heartbeats）中，必须对消息间隔进行一些协商，以便每个实体都可以知道其对等方期望HELLO的频率。这立即增加了一定程度的复杂性。类似地，需要定期发送消息（无论其他IPSec/IKE活动如何），也会增加系统的计算开销。
DPD addresses the shortcomings of IKE keepalives- and heartbeats-schemes by introducing a more reasonable logic governing message exchange. Essentially, keepalives and heartbeats mandate exchange of HELLOs at regular intervals. By contrast, with DPD, each peer's DPD state is largely independent of the other's. A peer is free to request proof of liveliness when it needs it -- not at mandated intervals. This asynchronous property of DPD exchanges allows fewer messages to be sent, and this is how DPD achieves greater scalability.
DPD通过引入更合理的控制消息交换的逻辑，解决了IKE keepalives和heartbeats方案的缺点。基本上，保持活力和心跳要求定期交流问候。相比之下，对于DPD，每个对等方的DPD状态在很大程度上独立于其他对等方。对等体可以在需要时自由地要求提供生动性证明，而不是在规定的时间间隔内。DPD交换的这种异步特性允许发送更少的消息，这就是DPD实现更大可伸缩性的方式。
As an elaboration, consider two DPD peers A and B. If there is ongoing valid IPSec traffic between the two, there is little need for proof of liveliness. The IPSec traffic itself serves as the proof of liveliness. If, on the other hand, a period of time lapses during which no packet exchange occurs, the liveliness of each peer is questionable. Knowledge of the peer's liveliness, however, is only urgently necessary if there is traffic to be sent. For example, if peer A has some IPSec packets to send after the period of idleness, it will need to know if peer B is still alive. At this point, peer A can initiate the DPD exchange.
作为一个阐述，考虑两个DPD对等体A和B。如果两个DPD对等点之间存在持续有效的IPSec流量，则不需要生动性证明。IPSec通信本身就是生动性的证明。另一方面，如果在一段时间内没有发生数据包交换，则每个对等点的活跃性是有问题的。然而，只有在需要发送流量的情况下，才迫切需要了解对等方的活跃性。例如，如果对等方A在空闲期后有一些IPSec数据包要发送，它将需要知道对等方B是否仍处于活动状态。此时，对等方A可以启动DPD交换。
To this end, each peer may have different requirements for detecting proof of liveliness. Peer A, for example, may require rapid failover, whereas peer B's requirements for resource cleanup are less urgent. In DPD, each peer can define its own "worry metric" - an interval that defines the urgency of the DPD exchange. Continuing the example, peer A might define its DPD interval to be 10 seconds. Then, if peer A sends outbound IPSec traffic, but fails to receive any inbound traffic for 10 seconds, it can initiate a DPD exchange.
为此，每个对等方可能对检测活力证明有不同的要求。例如，对等A可能需要快速故障切换，而对等B对资源清理的要求就不那么迫切了。在DPD中，每个对等方都可以定义自己的“担忧度量”——定义DPD交换紧迫性的时间间隔。继续该示例，对等方A可能将其DPD间隔定义为10秒。然后，如果对等方A发送出站IPSec流量，但在10秒钟内没有接收到任何入站流量，它可以启动DPD交换。
Peer B, on the other hand, defines its less urgent DPD interval to be 5 minutes. If the IPSec session is idle for 5 minutes, peer B can initiate a DPD exchange the next time it sends IPSec packets to A.
另一方面，对等B将其不太紧急的DPD间隔定义为5分钟。如果IPSec会话空闲5分钟，对等方B可以在下次向a发送IPSec数据包时启动DPD交换。
It is important to note that the decision about when to initiate a DPD exchange is implementation specific. An implementation might even define the DPD messages to be at regular intervals following idle periods. See section 5.5 for more implementation suggestions.
需要注意的是，关于何时启动DPD交换的决定是特定于实现的。一个实现甚至可以将DPD消息定义为在空闲期之后的固定间隔。更多实施建议见第5.5节。
To demonstrate DPD capability, an entity must send the DPD vendor ID. Both peers of an IKE session MUST send the DPD vendor ID before DPD exchanges can begin. The format of the DPD Vendor ID is:
为了演示DPD能力，实体必须发送DPD供应商ID。在DPD交换开始之前，IKE会话的两个对等方必须发送DPD供应商ID。DPD供应商ID的格式为：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !M!M!
! HASHED_VENDOR_ID !J!N!
! !R!R!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !M!M!
! HASHED_VENDOR_ID !J!N!
! !R!R!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,
0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond
to the current major and minor version of this protocol (1 and 0
respectively). An IKE peer MUST send the Vendor ID if it wishes to
take part in DPD exchanges.
where HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1,
0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}, and MJR and MNR correspond
to the current major and minor version of this protocol (1 and 0
respectively). An IKE peer MUST send the Vendor ID if it wishes to
take part in DPD exchanges.
The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The exchange is defined as:
DPD交换是一个双向（HELLO/ACK）通知消息。交易所的定义如下：
Sender Responder
-------- -----------
HDR*, NOTIFY(R-U-THERE), HASH ------>
Sender Responder
-------- -----------
HDR*, NOTIFY(R-U-THERE), HASH ------>
<------ HDR*, NOTIFY(R-U-THERE-
ACK), HASH
<------ HDR*, NOTIFY(R-U-THERE-
ACK), HASH
The R-U-THERE message corresponds to a "HELLO" and the R-U-THERE-ACK corresponds to an "ACK." Both messages are simply ISAKMP Notify payloads, and as such, this document defines these two new ISAKMP Notify message types:
R-U-THERE消息对应一个“HELLO”，R-U-THERE-ACK对应一个“ACK”。这两条消息都只是ISAKMP Notify有效载荷，因此，本文档定义了这两种新的ISAKMP Notify消息类型：
Notify Message Value R-U-THERE 36136 R-U-THERE-ACK 36137
通知消息值R-U-THERE 36136 R-U-THERE-ACK 36137
An entity that has sent the DPD Vendor ID MUST respond to an R-U-THERE query. Furthermore, an entity MUST reject unencrypted R-U-THERE and R-U-THERE-ACK messages.
发送DPD供应商ID的实体必须响应R-U-THERE查询。此外，实体必须拒绝未加密的R-U-THERE和R-U-THERE-ACK消息。
When sent, the R-U-THERE message MUST take the following form:
发送时，R-U-THERE消息必须采用以下形式：
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 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification 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 ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As this message is an ISAKMP NOTIFY, the Next Payload, RESERVED, and Payload Length fields should be set accordingly. The remaining fields are set as:
由于此消息是ISAKMP NOTIFY，因此应相应地设置下一个有效负载、保留和有效负载长度字段。其余字段设置为：
- Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI.
- 解释域（4个八位字节）-应设置为IPSEC-DOI。
- Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP.
- 协议ID（1个八位字节）-必须设置为ISAKMP的协议ID。
- SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of two octet-sized ISAKMP cookies.
- SPI大小（1个八位字节）-应设置为十六（16），即两个八位字节大小的ISAKMP cookie的长度。
- Notify Message Type (2 octets) - MUST be set to R-U-THERE
- 通知消息类型（2个八位字节）-必须设置为R-U-THERE
- Security Parameter Index (16 octets) - SHOULD be set to the cookies of the Initiator and Responder of the IKE SA (in that order)
- 安全参数索引（16个八位字节）-应设置为IKE SA的发起方和响应方的cookie（按该顺序）
- Notification Data (4 octets) - MUST be set to the sequence number corresponding to this message
- 通知数据（4个八位字节）-必须设置为与此消息对应的序列号
The format of the R-U-THERE-ACK message is the same, with the exception that the Notify Message Type MUST be set to R-U-THERE-ACK. Again, the Notification Data MUST be sent to the sequence number corresponding to the received R-U-THERE message.
R-U-THERE-ACK消息的格式相同，但通知消息类型必须设置为R-U-THERE-ACK。同样，必须将通知数据发送到与接收到的R-U-THERE消息相对应的序列号。
Again, rather than relying on some negotiated time interval to force the exchange of messages, DPD does not mandate the exchange of R-U-THERE messages at any time. Instead, an IKE peer SHOULD send an R-U-THERE query to its peer only if it is interested in the liveliness of this peer. To this end, if traffic is regularly exchanged between two peers, either peer SHOULD use this traffic as proof of liveliness, and both peers SHOULD NOT initiate a DPD exchange.
同样，DPD并不依赖协商的时间间隔来强制交换消息，而是不要求在任何时候交换R-U-the消息。相反，IKE对等方应仅在对该对等方的活跃性感兴趣时才向其对等方发送R-U-THERE查询。为此，如果两个对等方之间定期交换流量，则任何一个对等方都应使用此流量作为活跃性的证明，并且两个对等方都不应发起DPD交换。
A peer MUST keep track of the state of a given DPD exchange. That is, once it has sent an R-U-THERE query, it expects an ACK in response within some implementation-defined period of time. An implementation SHOULD retransmit R-U-THERE queries when it fails to receive an ACK. After some number of retransmitted messages, an implementation SHOULD assume its peer to be unreachable and delete IPSec and IKE SAs to the peer.
对等方必须跟踪给定DPD交换的状态。也就是说，一旦它发送了一个R-U-THERE查询，它期望在实现定义的时间段内得到一个ACK响应。当实现未能接收到ACK时，它应该重新传输R-U-THERE查询。经过一定数量的重传消息后，实现应假定其对等方不可访问，并将IPSec和IKE SA删除到对等方。
Since the liveliness of a peer is only questionable when no traffic is exchanged, a viable implementation might begin by monitoring idleness. Along these lines, a peer's liveliness is only important when there is outbound traffic to be sent. To this end, an implementation can initiate a DPD exchange (i.e., send an R-U-THERE message) when there has been some period of idleness, followed by the desire to send outbound traffic. Likewise, an entity can initiate a DPD exchange if it has sent outbound IPSec traffic, but not received any inbound IPSec packets in response. A complete DPD exchange (i.e., transmission of R-U-THERE and receipt of corresponding R-U-THERE-ACK) will serve as proof of liveliness until the next idle period.
因为只有在没有流量交换的情况下，对等节点的活跃性才有问题，所以可行的实现可能从监视空闲开始。沿着这些思路，只有当有出站流量要发送时，对等方的活跃性才是重要的。为此，当已经有一段空闲时间，随后希望发送出站通信量时，实现可以发起DPD交换（即，发送R-U-THERE消息）。同样，如果实体已发送出站IPSec通信，但未收到任何入站IPSec数据包作为响应，则可以启动DPD交换。完整的DPD交换（即R-U-THERE的传输和相应R-U-THERE-ACK的接收）将作为活跃性的证明，直到下一个空闲期。
Again, since DPD does not mandate any interval, this "idle period" (or "worry metric") is left as an implementation decision. It is not a negotiated value.
同样，由于DPD不要求任何时间间隔，所以这个“空闲时间”（或“担心度量”）将作为一个实现决策。这不是一个协商的价值。
The performance benefit that DPD offers over traditional keepalives-and heartbeats-schemes comes from the fact that regular messages do not need to be sent. Returning to the examples presented in section 4.1, a keepalive implementation such as the one presented would require one timer to signal when to send a HELLO message and another timer to "timeout" the ACK from the peer (this could also be the retransmit timer). Similarly, a heartbeats scheme such as the one presented in section 4.2 would need to keep one timer to signal when to send a HELLO, as well as another timer to signal the expectation of a HELLO from the peer. By contrast a DPD scheme needs to keep a timestamp to keep track of the last received traffic from the peer (thus marking beginning of the "idle period"). Once a DPD R-U-THERE message has been sent, an implementation need only maintain a timer to signal retransmission. Thus, the need to maintain active timer state is reduced, resulting in a scalability improvement (assuming maintaining a timestamp is less costly than an active timer). Furthermore, since a DPD exchange only occurs if an entity has not received traffic recently from its peer, the number of IKE messages to be sent and processed is also reduced. As a consequence, the scalability of DPD is much better than keepalives and heartbeats.
与传统的keepalives和heartbeats方案相比，DPD提供的性能优势来自这样一个事实：不需要发送常规消息。回到第4.1节中给出的示例，一个keepalive实现（如所示）需要一个计时器来指示何时发送HELLO消息，另一个计时器来“超时”来自对等方的ACK（这也可能是重传计时器）。类似地，第4.2节中介绍的心跳方案需要保持一个计时器，以指示何时发送HELLO，以及另一个计时器，以指示对等方对HELLO的期望。相比之下，DPD方案需要保持时间戳以跟踪来自对等方的最后接收的通信量（从而标记“空闲周期”的开始）。一旦发送了DPD R-U-THERE消息，实现只需要维护一个定时器来信号重传。因此，减少了维护活动计时器状态的需要，从而提高了可伸缩性（假设维护时间戳的成本低于活动计时器）。此外，由于DPD交换仅在实体最近没有从其对等方接收通信量时发生，因此要发送和处理的IKE消息的数量也减少了。因此，DPD的可伸缩性比keepalives和heartbeats好得多。
DPD maintains the HELLO/ACK model presented by keepalives, as it follows that an exchange is initiated only by an entity interested in the liveliness of its peer.
DPD维护keepalives提供的HELLO/ACK模型，因为这样一来，交换只由对其对等方的活跃性感兴趣的实体发起。
To guard against message replay attacks and false proof of liveliness, a 32-bit sequence number MUST be presented with each R-U-THERE message. A responder to an R-U-THERE message MUST send an R-U-THERE-ACK with the same sequence number. Upon receipt of the R-U-THERE-ACK message, the initial sender SHOULD check the validity of the sequence number. The initial sender SHOULD reject the R-U-THERE-ACK if the sequence number fails to match the one sent with the R-U-THERE message.
为了防止消息重播攻击和活性的虚假证明，必须为每个R-U-THERE消息提供一个32位序列号。R-U-THERE消息的响应者必须发送具有相同序列号的R-U-THERE-ACK。在收到R-U-THERE-ACK消息后，初始发送方应检查序列号的有效性。如果序列号与R-U-THERE消息发送的序列号不匹配，则初始发送方应拒绝R-U-THERE-ACK。
Additionally, both the receiver of the R-U-THERE and the R-U-THERE-ACK message SHOULD check the validity of the Initiator and Responder cookies presented in the SPI field of the payload.
此外，R-U-THERE和R-U-THERE-ACK消息的接收器都应检查有效载荷SPI字段中显示的启动器和响应器cookie的有效性。
As both DPD peers can initiate a DPD exchange (i.e., both peers can send R-U-THERE messages), each peer MUST maintain its own sequence number for R-U-THERE messages. The first R-U-THERE message sent in a session MUST be a randomly chosen number. To prevent rolling past overflowing the 32-bit boundary, the high-bit of the sequence number initially SHOULD be set to zero. Subsequent R-U-THERE messages MUST increment the sequence number by one. Sequence numbers MAY reset at the expiry of the IKE SA, moving to a newly chosen random number. Each entity SHOULD also maintain its peer's R-U-THERE sequence number, and an entity SHOULD reject the R-U-THERE message if it fails to match the expected sequence number.
由于两个DPD对等方都可以发起DPD交换（即，两个对等方都可以发送R-U-THE消息），因此每个对等方必须维护其自己的R-U-THE消息序列号。会话中发送的第一条R-U-THERE消息必须是随机选择的数字。为了防止滚动溢出32位边界，序列号的高位最初应设置为零。后续R-U-the消息必须将序列号增加1。序列号可以在IKE SA到期时重置，移动到新选择的随机数。每个实体还应维护其对等方的R-U-THERE序列号，如果R-U-THERE消息与预期序列号不匹配，则实体应拒绝该消息。
Implementations MAY maintain a window of acceptable sequence numbers, but this specification makes no assumptions about how this is done. Again, it is an implementation specific detail.
实现可能会维护一个可接受序列号的窗口，但本规范对如何实现这一点不作任何假设。同样，这是一个特定于实现的细节。
As the previous section highlighted, DPD uses sequence numbers to ensure liveliness. This section describes the advantages of using sequence numbers over random nonces to ensure liveliness.
正如前一节所强调的，DPD使用序列号来确保生动性。本节介绍了使用序列号而不是随机nonce以确保生动性的优点。
While sequence numbers do require entities to keep per-peer state, they also provide an added method of protection in certain replay attacks. Consider a case where peer A sends peer B a valid DPD R-U-THERE message. An attacker C can intercept this message and flood B with multiple copies of the messages. B will have to decrypt and process each packet (regardless of whether sequence numbers or nonces are in use). With sequence numbers B can detect that the packets are replayed: the sequence numbers in these replayed packets will not match the incremented sequence number that B expects to receive from A. This prevents B from needing to build, encrypt, and send ACKs. By contrast, if the DPD protocol used nonces, it would provide no way for B to detect that the messages are replayed (unless B maintained a list of recently received nonces).
虽然序列号确实要求实体保持每个对等状态，但在某些重播攻击中，它们还提供了一种额外的保护方法。考虑对等体A向对等节点发送一个有效的DPD R-U-THE消息的情况。攻击者C可以截获此消息并向B发送消息的多个副本。B必须解密和处理每个数据包（无论使用的是序列号还是nonce）。有了序列号，B可以检测到数据包被重放：这些重放的数据包中的序列号将与B希望从A接收的递增序列号不匹配。这防止了B需要构建、加密和发送ACK。相反，如果DPD协议使用nonce，它将无法为B提供检测消息是否被重放的方法（除非B维护最近接收到的nonce的列表）。
Another benefit of sequence numbers is that it adds an extra assurance of the peer's liveliness. As long as a receiver verifies the validity of a DPD R-U-THERE message (by verifying its incremented sequence number), then the receiver can be assured of the peer's liveliness by the very fact that the sender initiated the query. Nonces, by contrast, cannot provide this assurance.
序列号的另一个好处是，它增加了一个额外的保证，以确保对等的活力。只要接收方验证DPD R-U-THERE消息的有效性（通过验证其递增的序列号），那么接收方就可以通过发送方发起查询这一事实来确保对等方的活跃性。相反，nonce不能提供这种保证。
There is no IANA action required for this document. DPD uses notify numbers from the private range.
本文件不需要IANA操作。DPD使用专用范围内的通知号码。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[2] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Geoffrey Huang Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
杰弗里·黄思科系统有限公司，加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: (408) 525-5354 EMail: ghuang@cisco.com
电话：（408）525-5354电子邮件：ghuang@cisco.com
Stephane Beaulieu Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON Canada, K2K 3E8
Stephane Beaulieu思科系统公司，加拿大卡纳塔创新大道2000号，K2K 3E8
Phone: (613) 254-3678 EMail: stephane@cisco.com
电话：（613）254-3678电子邮件：stephane@cisco.com
Dany Rochefort Cisco Systems, Inc. 124 Grove Street, Suite 205 Franklin, MA 02038
Dany Rochefort Cisco Systems，Inc.马萨诸塞州富兰克林格罗夫街124号205室02038
Phone: (508) 553-8644 EMail: danyr@cisco.com
电话：（508）553-8644电子邮件：danyr@cisco.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。