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
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.
この文書では、多くのベンダーで現在使用されて死んでインターネットキー交換（IKE）ピアを検出する方法を説明します。デッドピア検出（DPD）と呼ばれる方法は、生存性を確認するために必要なIKEメッセージの数を最小限に抑えるためのIPSecトラフィックパターンを使用しています。 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]、状況は、二つの間の接続が突然ダウンした生じ得ます。この状況は、理由などルーティングの問題、一つのホストの再起動の発生する可能性があり、そのような場合には、IKEおよびIPSecピア接続の損失を識別するための方法がしばしばありません。そのため、SAはパケットは忘却の彼方にトンネリングされている「ブラックホール」の状況が生じ、その寿命は自然に期限が切れるまで残ることができます。企業がすぐに別のピアにフェイルオーバーできるように、できるだけ早くブラックホールを認識することが望ましい場合が多いです。同様に、失われた資源を回復するためにブラックホールを検出することが必要な場合があります。
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メッセージを送信する必要の提案によって対処されています。これらのスキームは、一方向（ハローのみ）または双方向（ハロー/ ACK対）である傾向があります。このドキュメントの目的のために、用語「ハートビート」は活気を証明するために一方向のメッセージを参照します。同様に、「キープアライブ」という用語は、双方向のメッセージを参照します。
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セッションの多数を管理することは懸念されるの実装やインスタレーションでは、これらの定期的なハートビート/キープアライブは実行不可能であることを証明します。
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ピアの活気を照会するメッセージを通知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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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および第4節で提示スキームとの違いを強調し、拡張性の問題を重視し、完全にDPD案を提示しています。第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を使用して、生じています。これらの方法は、双方向の「キープアライブ」メッセージ交換（ACK続いハロー）、または単方向「ハートビート」メッセージ交換（ハローのみ）のいずれかに依存しています。次のセクションでは、これらの方式の両方を考慮します。
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
ピアAとピアBは、互いの活気の定期的な確認を必要とするキープアライブ方式を考えます。メッセージは、ペイロードを通知し、認証によって交換されています。約10秒程度 - 2つのピアが、いくつかの交渉が可能であることを任意のプロンプトフェイルオーバーのためにフェーズ1の間に必要とされることを意味し、キープアライブが送信される間隔に合意しなければならない、キープアライブもかなり頻繁に送信する必要があります。この仮定のキープアライブのシナリオでは、ピアAとBは、キープアライブに10秒ごとに交換することに同意します。基本的に、10秒ごとに、1つのピアは他に、HELLOを送信する必要があります。このハローは、送信エンティティの活気の証拠として役立ちます。ターンでは、他のピアは、各キープアライブのHELLOを確認する必要があります。 10秒が経過し、片側は、HELLOを受信していない場合、それは活気の証拠としてピアのACKを使用して、HELLOメッセージ自体を送信します。 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:
ハローまたはACKは、エンティティのキープアライブタイマーがリセットされます。一定の期間に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. 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. Bに挨拶を送ります。その最初のハローが失われた場合には、再送信することができます。この状況は、ピアAがピアが死んで検知する方法を説明します。
Peer A: Peer B (dead):
ピア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が死んでいるとみなします。 SAを削除し、可能性のフェイルオーバーを開始します。
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の活気に興味があり、その結果、HELLOを送信するピア。これは、Bは、ピアAの活気に興味が決してピアなどの方式で考えられます。このような場合には、責任は常に交換を開始するために、ピアA上に位置することになります。
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.
<------ 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.
---
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.に定期的helloを送信するために必要な状態情報を維持しなければなりません。 （50,000ピア程度のオーダー）セッション多数の終了VPNアグリゲータを考えます。各ピアは、従って、HELLOパケットごとに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.
各エンティティは、そのピアが、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-とハートビート・スキームの欠点に対処します。基本的に、キープアライブおよび定期的にハローズの心拍の任務交換。対照的に、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.
両者の間の継続的な有効なIPSecトラフィックがある場合は推敲ように、2つのDPDピアAとBを考慮し、活気の証明のための必要はほとんどありません。 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.
この目的のために、各ピアは活気の証拠を検出するための異なる要件を有してもよいです。リソースのクリーンアップのためにBの要件はあまり緊急であるのに対し、ピア、ピアAは、例えば、迅速なフェイルオーバーを必要とし得ます。 DPDにおいて、各ピアは、それ自身を定義することができ、「メトリック心配」 - DPD交換の緊急性を定義する間隔。例を続けると、ピアAは10秒にそのDPD間隔を定義できます。ピア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は、一方、5分であることが、その少ない緊急DPDの間隔を規定します。 IPSecセッションが5分間アイドル状態である場合、ピアBはDPD交換を、それがAにIPSecパケットを送信する次の時間を開始することができます
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!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
HASHED_VENDOR_ID = {0xAF、0xCA、0xD7、0x13に、0x68、0xA1の、0xF1、0xC9、0x6B、0x86で、0x96、0xFC、0x77、0x57}、及びMJRとMNRがこのプロトコルの現在のメジャーおよびマイナーバージョンに対応する（1それぞれ0）。それはDPD交換に参加することを望む場合、IKEピアは、ベンダーIDを送信しなければなりません。
The DPD exchange is a bidirectional (HELLO/ACK) Notify message. The exchange is defined as:
DPD交換は、双方向（ハロー/ 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-THEREメッセージは、 "HELLO" とR-U-THERE-ACKが対応する "ACK" に対応両方のメッセージは、単にISAKMPは、ペイロードを通知であり、そのように、このドキュメントはこれら二つの新しいISAKMP通知メッセージタイプを定義します。
Notify Message Value R-U-THERE 36136 R-U-THERE-ACK 36137
NOTIFYメッセージ値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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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あるとして、次にペイロード、RESERVED、ペイロード長フィールドは、それに応じて設定されるべきです。残りのフィールドは以下のように設定されています。
- 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（16）、2オクテットサイズISAKMPクッキーの長さに設定する必要があります。
- 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のイニシエータとレスポンダのクッキーに設定されるべきである（SHOULD）
- 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-THEREメッセージの交換を強制しません。代わりに、IKEピアは、それがこのピアの活気に興味がある場合にのみ、そのピアにTHERE R-U-クエリを送るべきです。トラフィックを定期的に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-THEREクエリを送信した後、それは時間のいくつかの実装で定義された期間内に応答してACKを期待しています。インプリメンテーションは、再送信すべきであるR-U-THEREそれはACKの受信に失敗したときに問い合わせます。再送信されたメッセージのいくつかの数の後、実装が到達不能になると、ピアへの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.
DPDは、伝統的なキープアライブ-とハートビート・スキームの上に提供していますパフォーマンス上の利点は、通常のメッセージを送信する必要がないという事実から来ています。セクション4.1に提示例に戻ると、キープアライブ実装例えばHELLOメッセージを送信するときに知らせるために1つのタイマーを必要と提示された1つ、別のタイマとして「タイムアウト」ピアからのACK（これはまた、再送信タイマーであってもよい）に。同様に、セクション4.2に提示された1つのようなハートビート方式は、ピアからのHELLOの期待を知らせるために、HELLO、ならびに別のタイマーを送信するときに知らせるために1つのタイマーを維持する必要があります。これとは対照的にDPD方式は（したがって、「アイドル期間」の始まりをマーキング）ピアから最後に受信したトラフィックを追跡するためにタイムスタンプを維持する必要があります。 DPD R-U-THEREメッセージは、実装に送信されるとすると、再送を通知するタイマーを維持するだけでよいです。したがって、アクティブタイマーの状態を維持する必要性は（タイムスタンプを維持することがアクティブタイマーよりも安価であると仮定して）スケーラビリティの改善をもたらす、低減されます。エンティティがそのピアからの最近のトラフィックを受信していない場合DPD交換のみ起こるので、送られて処理されるIKEメッセージの数も減少します。その結果、DPDのスケーラビリティは、キープアライブとハートビートよりもはるかに優れています。
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は、キープアライブによって提示されたハロー/ 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.
メッセージリプレイ攻撃と活気の偽の証明を防ぐために、32ビットのシーケンス番号は、各R-U-THEREメッセージで提示されなければなりません。 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.
また、-THERE R-Uの受信機との両方R-U-THERE-ACKメッセージは、ペイロードのSPIフィールドに提示イニシエータとレスポンダクッキーの有効性を確認してください。
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-THEREメッセージのために独自のシーケンス番号を維持しなければならない（すなわち、両方のピアは、R-U-THEREメッセージを送信することができます）。セッション中に送信された最初のR-U-THEREメッセージは、ランダムに選択された番号でなければなりません。 32ビット境界をオーバーフロー圧延過去のを防止するために、シーケンス番号の高ビットは、最初はゼロに設定されるべきです。その後のR-U-THEREメッセージを一つのシーケンス番号をインクリメントしなければなりません。シーケンス番号は、新たに選ばれた乱数に移動し、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は活気を確実にするために、シーケンス番号を使用します。このセクションでは、活気を確保するために、ランダムなナンスの上にシーケンス番号を使用することの利点を説明しています。
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-THEREをメッセージピアBを送信する場合を考えます。攻撃者Cは、メッセージの複数のコピーを使用してこのメッセージや洪水Bを傍受することができます。 Bは（かかわらず、シーケンス番号またはナンスが使用中であるかどうかの）各パケットを復号化し、処理する必要があります。これらのリプレイパケットのシーケンス番号はBこれは、構築暗号化し、ACKを送信するために必要とするからBを防ぎAから受信することを期待インクリメントされたシーケンス番号と一致しません。シーケンス番号Bを持つパケットが再生されていることを検出することができます。 DPDプロトコルがノンスを使用した場合のコントラストによって、それは（B最近受信ナンスのリストを維持していない限り）メッセージが再生されていることを検出するためにBのための方法を提供しないであろう。
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-THEREメッセージの正当性を検証するように、受信機は、送信者がクエリを開始することが非常に事実によってピアの活気を保証することができます。ナンスは、対照的に、この保証を提供することはできません。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[2]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
Geoffrey Huang Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ジェフリー・黄シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
Phone: (408) 525-5354 EMail: ghuang@cisco.com
電話：（408）525-5354 Eメール：ghuang@cisco.com
Stephane Beaulieu Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON Canada, K2K 3E8
ステファン・ボーリューシスコシステムズ株式会社2000年カナダ、K2K 3E8 ONイノベーションドライブカナタ、
Phone: (613) 254-3678 EMail: stephane@cisco.com
電話：（613）254-3678 Eメール：stephane@cisco.com
Dany Rochefort Cisco Systems, Inc. 124 Grove Street, Suite 205 Franklin, MA 02038
ダニーロシュフォールシスコシステムズ社124グローブストリート、スイート205フランクリン、MA 02038
Phone: (508) 553-8644 EMail: danyr@cisco.com
電話：（508）553-8644 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。