[要約] 要約：RFC 3706は、デッドなInternet Key Exchange（IKE）ピアを検出するためのトラフィックベースの方法について説明しています。 目的：このRFCの目的は、IKEセッションの状態を監視し、デッドなピアを検出するための手法を提供することです。
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）The Internet Society（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.
このドキュメントでは、現在多くのベンダーが使用しているDead Internet Key Exchange（IKE）ピアを検出する方法について説明します。Dead Peer Detection（DPD）と呼ばれるこの方法では、IPSECトラフィックパターンを使用して、執着を確認するために必要なIKEメッセージの数を最小限に抑えます。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
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.
2人のピアがIKE [2]とIPSEC [3]と通信すると、2人の間の接続性が予期せずダウンする状況が発生する可能性があります。この状況は、ルーティングの問題、1つのホストの再起動などのために発生する可能性があります。そのような場合、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 Peerを検出するこの問題は、活気を証明するために定期的なHello/ACKメッセージを送信する必要がある提案によって対処されています。これらのスキームは、一方向（ハローのみ）または双方向（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.
現在のハートビートとキープライブの提案の問題は、定期的に送信されるメッセージへの依存です。実装では、これはこれらのメッセージ間隔をサービスするためのいくつかのタイマーの管理につながります。同様に、死んだピアの迅速な検出がしばしば望まれるため、これらのメッセージは何らかの頻度で送信する必要があり、メッセージ処理のためにかなりのオーバーヘッドに変換されます。多数の同時のIKEセッションを管理することが懸念される実装とインストールでは、これらの定期的な心拍/keepAlivesが実行不可能であることが証明されています。
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.
この目的のために、多くのベンダーが、定期的にメッセージを送信する必要なく、仲間の活気を検出する独自のアプローチを実装しています。この情報文書では、これらの実装の現在の慣行について説明しています。Dead Peer Detection（DPD）と呼ばれるこのスキームは、IKEの通知メッセージに依存して、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、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では、キープライブベースのアプローチとハートビートベースのアプローチを検証します。セクション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通知を使用してピアの活気を照会するために、さまざまな方法が生じています。これらの方法は、双方向の「KeepAlive」メッセージ交換（ACKが続くハロー）、または単方向の「ハートビート」メッセージ交換（こんにちはのみ）のいずれかに依存しています。次のセクションでは、これらの両方のスキームを検討します。
4.1. Keepalives:
4.1. Keepalives：
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 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:
ピアAとピアBがお互いの活気の定期的な承認を必要とするKeepalivesスキームを考えてみましょう。メッセージは、認証された通知ペイロードによって交換されます。2人のピアは、キープライブが送信される間隔に同意する必要があります。つまり、フェーズ1中に交渉が必要であることを意味します。この仮説的なKeepalivesシナリオでは、ピアAとBは10秒ごとにKeepaliveを交換することに同意します。基本的に、10秒ごとに、一方のピアはもう一方のピアに挨拶を送る必要があります。このHelloは、送信エンティティの活気の証拠として機能します。次に、他のピアはそれぞれのkeepalive Helloを認めなければなりません。10秒が経過し、片側がHelloを受け取っていない場合、ピアのACKを活気の証明として使用して、Helloメッセージ自体を送信します。HelloまたはACKの受領により、エンティティのKeepalive Timerがリセットされます。特定の期間にACKを受け取らないと、エラーが示されます。説明を以下に示します。
Scenario 1: Peer A's 10-second timer elapses first, and it sends a HELLO to B. B responds with an ACK.
シナリオ1：Peer Aの10秒のタイマーが最初に経過し、B。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.
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は応答できません。最初のHelloが失われた場合に備えて、再送信できます。この状況は、ピアAがピアが死んだことを検出する方法を説明しています。
Peer A: Peer B (dead):
ピアA：ピアB（死んだ）：
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.
---
---
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 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.
このスキームの利点は、他のピアの活気に興味がある当事者がメッセージ交換を開始することです。シナリオ1では、ピアAはピアBの活気に興味があり、ピアAがハローを送信します。これは、ピア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は、お互いの活気に興味があります。各ピアは、定期的なHellosを送信するために他のピアに依存しています。
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.
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 Deadをマークします。これが、エンティティが同業者が死んでいることを検出する方法です。
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 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.
このスキームの欠点は、活気を示すためのピアへの依存です。この目的のために、ピアBはピアAの活気に興味がないかもしれません。それにもかかわらず、AがBの活気に関心がある場合、Bはこれを認識し、Aを定期的にHellosを送信するために必要な状態情報を維持する必要があります。そのようなスキームの欠点は、リモートアクセスシナリオで明らかになります。多数のセッションを終了するVPNアグリゲーターを検討してください（50,000人のピア程度）。各ピアはかなり迅速なフェールオーバーを必要とするため、アグリゲーターは10秒ごとにハローパケットを送信する必要があります。アグリゲーターは数秒ごとに50,000のメッセージを送信する必要があるため、このようなスキームには単にスケーラビリティがありません。
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）の両方で、メッセージ間隔の交渉が発生する必要があります。これにより、各エンティティはピアがこんにちはを期待する頻度を知ることができます。これにより、ある程度の複雑さがすぐに追加されます。同様に、定期的なメッセージを送信する必要性（他の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-Schemesの欠点に対処します。本質的に、キープライブとハートビートは、定期的にHellosの交換を義務付けています。対照的に、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.
精緻化として、2つのDPDピアAとBを検討してください。2つの間に継続的な有効なIPSECトラフィックがある場合、活気の証明の必要性はほとんどありません。IPSECトラフィック自体は、活気の証拠として機能します。一方、パケット交換が発生しない期間が経過する場合、各ピアの活気が疑わしい。ただし、ピアの活気の知識は、送信するトラフィックがある場合にのみ緊急に必要です。たとえば、Peer Aには、怠idleの期間後に送信する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交換の緊急性を定義する間隔です。例を継続すると、PEER 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は次にIPSECパケットをAに送信するときに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を送信する必要があります。IKEセッションの両方のピアは、DPD交換を開始する前に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!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ------>
<------ 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-hereメッセージは「hello」に対応し、r-u-fackは「ack」に対応します。両方のメッセージは単にiSAKMP通知ペイロードを通知するため、このドキュメントでは、これら2つの新しいISAKMP通知メッセージタイプを定義しています。
Notify Message Value
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-hithere queryに応答する必要があります。さらに、エンティティは、暗号化されていないR-U-u-fackメッセージを拒否しなければなりません。
When sent, the R-U-THERE message MUST take the following form:
送信された場合、r-u-メッセージは次の形式を取る必要があります。
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通知であるため、次のペイロード、予約、およびペイロード長のフィールドをそれに応じて設定する必要があります。残りのフィールドは次のように設定されています。
- 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.
- Protocol ID（1 Octet） - ISAKMPのプロトコルIDに設定する必要があります。
- SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of two octet-sized ISAKMP cookies.
- SPIサイズ（1オクテット） - 16（16）、2オクテットサイズのISAKMP Cookieの長さに設定する必要があります。
- Notify Message Type (2 octets) - MUST be set to R-U-THERE
- 通知メッセージタイプ（2オクテット） - r-u-shereに設定する必要があります
- 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-ackメッセージの形式は同じですが、notifyメッセージタイプをr-u-fackに設定する必要があることを除きます。繰り返しますが、通知データは、受信したR-U-Sthereメッセージに対応するシーケンス番号に送信する必要があります。
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-Sthereメッセージの交換を義務付けません。代わりに、IKEピアは、このピアの活気に関心がある場合にのみ、R-U-u-here-hers foreをピアに送信する必要があります。この目的のために、トラフィックが2つのピア間で定期的に交換される場合、ピアはこのトラフィックを活性の証明として使用する必要があり、両方のピアが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-hithere Queryを送信すると、実装定義の期間内にACKが応答することが予想されます。実装では、ACKの受信に失敗した場合、R-U-U-U-U-u-u-u-u-uが再送信する必要があります。いくつかの再送信メッセージの後、実装はそのピアが到達不可能であると仮定し、IPSECとIKE SASをピアに削除する必要があります。
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.
ピアの活気は、トラフィックが交換されない場合にのみ疑わしいため、実行可能な実装は怠idleを監視することによって始まる可能性があります。これらの線に沿って、ピアの活気は、送信するトラフィックがある場合にのみ重要です。この目的のために、実装は、ある程度の怠idle性があったときにDPD交換を開始する（つまり、R-U-Sthereメッセージを送信します）、その後、アウトバウンドトラフィックを送信したいという欲求が続きます。同様に、エンティティは、Autbound IPSECトラフィックを送信した場合にDPD交換を開始できますが、それに応じてインバウンドIPSECパケットを受信していません。完全なDPD交換（つまり、R-U-Thereの送信と対応するR-U-Sthere-cackの受領）は、次のアイドル期間まで活気の証拠として機能します。
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.
DPDが従来のKeepalivesとHeartbeats-Schemesよりも提供するパフォーマンスの利点は、通常のメッセージを送信する必要がないという事実に由来しています。セクション4.1で提示された例に戻ると、提示されたものなどのキープライブ実装では、1つのタイマーがハローメッセージを送信するときに合図する必要があり、別のタイマーはピアからACKを「タイムアウト」します（これは再送信タイマーになる可能性があります）。同様に、セクション4.2に示されているようなハートビートスキームは、1つのタイマーをいつ送信するかを信号するために、およびピアからのHelloの期待を示す別のタイマーと同様に、別のタイマースキームを維持する必要があります。対照的に、DPDスキームは、ピアからの最後の受信したトラフィックを追跡するためにタイムスタンプを維持する必要があります（したがって、「アイドル期間」の始まりを示します）。DPD r-u-uが送信されると、実装では再送信を信号するためのタイマーを維持するだけです。したがって、アクティブなタイマー状態を維持する必要性が低下し、スケーラビリティが改善されます（タイムスタンプを維持することはアクティブなタイマーよりもコストがかからないと仮定します）。さらに、DPD交換は、エンティティが最近ピアからトラフィックを受け取っていない場合にのみ発生するため、送信および処理されるIKEメッセージの数も削減されます。結果として、DPDのスケーラビリティは、Keepaliveや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-hereメッセージに32ビットシーケンス番号を提示する必要があります。r-u-u-hereの応答者は、同じシーケンス番号でr-u-fackを送信する必要があります。r-u-ackメッセージを受信すると、最初の送信者はシーケンス番号の有効性を確認する必要があります。最初の送信者は、r-u-u-here-u-here-u-hersのメッセージと一致しない場合、r-u-fackを拒否する必要があります。
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-fackメッセージの両方は、ペイロードの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-Sthereメッセージを送信できます）、各ピアはR-U-Sthereメッセージに対して独自のシーケンス番号を維持する必要があります。セッションで送信された最初のR-U-u-u-u-u-u-u-u-shoreは、ランダムに選択された番号でなければなりません。32ビットの境界をオーバーフローする過去の転がりを防ぐために、最初にシーケンス番号のハイビットをゼロに設定する必要があります。後続のr-u-メッセージは、シーケンス番号を1つずつ増分する必要があります。シーケンス番号は、IKE SAの有効期限にリセットされ、新しく選択された乱数に移動する場合があります。また、各エンティティはピアのR-U-Sheer Sequence番号を維持する必要があり、エンティティは、予想されるシーケンス番号と一致しない場合、R-U-Sthereメッセージを拒否する必要があります。
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はシーケンス番号を使用して活気を確保します。このセクションでは、ランダムなノンセスよりもシーケンス番号を使用して活気を確保することの利点について説明します。
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がピアBを有効なDPD r-uを送信する場合を考えてみましょう。攻撃者Cは、このメッセージをインターセプトし、メッセージの複数のコピーでBをフラッディングできます。Bは、各パケットを復号化して処理する必要があります（シーケンス番号または非セースが使用されているかどうかに関係なく）。シーケンス番号Bを使用すると、パケットが再生されることを検出できます。これらのリプレイパケットのシーケンス番号は、AからBから受信する予想される増分シーケンス番号と一致しません。対照的に、DPDプロトコルがNoncesを使用した場合、Bがメッセージが再生されることを検出する方法は提供されません（Bが最近受信したNoncesのリストを維持しない限り）。
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.
シーケンス番号のもう1つの利点は、ピアの活気を追加することです。レシーバーがDPD R-U-U-Sthereメッセージの有効性を検証する限り（増分シーケンス番号を確認することにより）、受信者は、送信者がクエリを開始したという事実によって、ピアの活気を保証できます。対照的に、Noncesはこの保証を提供することはできません。
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、「The Internet Key Exchange（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
Geoffrey Huang Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 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 Beauliu Cisco Systems、Inc。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 Grove Street、Suite 205 Franklin、MA 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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。