RFC3706 日本語訳
3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange(IKE) Peers. G. Huang, S. Beaulieu, D. Rochefort. February 2004. (Format: TXT=30196 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Huang
Request for Comments: 3706 S. Beaulieu
Category: Informational D. Rochefort
Cisco Systems, Inc.
February 2004
コメントを求めるワーキンググループG.ホアン要求をネットワークでつないでください: 3706秒間ボーリューカテゴリ: 情報のD.ロシュフォールシスコシステムズInc.2004年2月
A Traffic-Based Method of Detecting Dead Internet
Key Exchange (IKE) Peers
死んでいるインターネット・キー・エクスチェンジ(IKE)同輩を検出する交通ベースの方法
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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)同輩を検出しながら、方法を説明します。 方法、呼ばれたDead Peer Detection(DPD)は活性を確認するのに必要であるIKEメッセージの数を最小にするのにIPSecトラフィック・パターンを使用します。 他の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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 道路地図. . . . . . . . . . . . . . . . . . . . . . . 3 3を記録してください。 活気. . . . . . . . . . . . . . . . . . . . . . . . . . 3 4の証拠のための周期的な交換処理のための原理。 Keepalives対鼓動. . . . . . . . . . . . . . . . . . 3 4.1 Keepalives. . . . . . . . . . . . . . . . . . . . . . . 3 4.2。 鼓動. . . . . . . . . . . . . . . . . . . . . . . 5 5。 DPDは.65.1について議定書の中で述べます。 DPD業者ID。 . . . . . . . . . . . . . . . . . . . . . 7 5.2. 交換処理。 . . . . . . . . . . . . . . . . . . . 7 5.3. 通知、(そこのR-U/、そこのR-U、ACK、)、メッセージ・フォーマット. . . . . 8 5.4 DPD交換. . . . . . . . . . . . . . . . 9 5.5のための起動力。 実現提案。 . . . . . . . . . . . . . . . 9 5.6. 比較。 . . . . . . . . . . . . . . . . . . . . . . 10 6. 反射攻撃への抵抗と活気の誤った証拠。 . . 10 6.1. DPDメッセージの一連番号。 . . . . . . . . . . . . 10
Huang, et al. Informational [Page 1] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[1ページ]のRFC3706
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. 一連番号の選択と維持。 . . . . . 11 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 11 8. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 12 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1。 引用規格。 . . . . . . . . . . . . . . . . . . 12 9.2. 有益な参照. . . . . . . . . . . . . . . . . 12 10。 エディタのアドレス. . . . . . . . . . . . . . . . . . . . . . 12 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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は残ることができます、パケットが忘却にトンネルを堀られる「ブラックホール」状況をもたらして。 できるだけ早くブラックホールを認識するのがしばしば望ましいので、aに異なった実体缶のフェイルオーバーはすぐにじっと見ます。 同様に、無くなっているリソースを回復するためにブラックホールを検出するのが時々必要です。
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.
活気を立証する周期的なHELLO/ACKメッセージを送るのを必要とする提案で死んでいるIKE同輩を検出するというこの問題を記述してあります。 これらの計画は、単方向(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.
現在の鼓動とkeepalive提案に関する問題はそれらの一定の間隔を置いて送られるべきメッセージへの彼らの信用です。 実現では、これはこれらのメッセージ間隔を修理するためにあるタイマを管理するのに翻訳されます。 同様に、死んでいる同輩の急速な検出がしばしば望まれているので、何らかの頻度と共にこれらのメッセージを送らなければなりません、メッセージ処理のために再びかなりのオーバーヘッドに翻訳して。 実現とインストールでは、多くの同時の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 Notifyメッセージを当てにします。
Huang, et al. Informational [Page 2] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[2ページ]のRFC3706
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Document Roadmap
2. ドキュメント道路地図
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提案を完全に提示します、セクション4で寄贈されたDPDと計画の違いを目立たせて、スケーラビリティ問題を強調して。 セクション6は再演されたメッセージと誤った活気を囲む安全保障問題を調べます。
3. Rationale for Periodic Message Exchange for Proof of Liveliness
3. 活気の証拠のための周期的な交換処理のための原理
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はrekeyの期間、当時の試みまで待つことは別としてこれが起こる方法を全く提供しません(rekeyに失敗して)。 これはセキュリティ協会(SA)の生涯の残りを持続する損失の接続性の1回の時代に結果として生じるでしょう、そして、ほとんどの展開では、容認できません。 そういうものとして、方法が同輩の状態を自由自在に調べるのに必要です。 通常、同輩の活気について質問するのにIKE Notifyを使用して、異なった方法は起こりました。 これらの方法は双方向の"keepalive"交換処理(ACKによって続かれたHELLO)か単方向の「鼓動」交換処理(HELLO専用)のどちらかを当てにします。 次のセクションはこれらの計画の両方を考えます。
4. Keepalives vs. Heartbeats
4. Keepalives対鼓動
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
同輩Aと同輩Bが互いの活気の定期的な承認を必要とするkeepalives計画を考えてください。 による、メッセージを交換する、認証されて、ペイロードに通知してください。 2人の同輩がkeepalivesが送られる間隔に同意しなければなりません、何らかの交渉がPhase1の間必要であることを意味して。 また、どんな迅速なフェイルオーバーも可能であるように、かなり頻繁な間隔--およそ10秒にkeepalivesを送らなければなりません。 この仮定しているkeepalivesシナリオでは、同輩AとBは、10秒毎にkeepalivesを交換するのに同意します。 本質的には、10秒毎に、1人の同輩がHELLOをもう片方に送らなければなりません。 このHELLOは送付実体のための活気の証拠として機能します。 順番に、もう片方の同輩は各keepalive HELLOを承認しなければなりません。 10秒が経過して、半面がHELLOを受けていないと、HELLOメッセージ自体を送るでしょう、活気の証拠として同輩のACKを使用して。 aの領収書
Huang, et al. Informational [Page 3] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[3ページ]のRFC3706
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がACKと共に反応させるB.にHELLOを送ります。
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.
同輩A: 同輩B: 10 2番目のタイマは撃たれます。 ------>は、Bが生きているのを知りたがっています。 HELLOを送ります。 こんにちはを受けます。 Aの活気を承認します。 <、-、-、-、-、-- keepaliveタイマをリセットして、ACKを送ります。 ビーズ活気の証拠としてACKを受けます。 タイマをリセットします。
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.にHELLOを送ります。 初期のHELLOが無くなるといけないので、Aは再送されることができます。 この状況が説明する、同輩Aがどう同輩を検出するかは、死んでいます。
Peer A: Peer B (dead):
同輩A: 同輩B(死んでいる):
10 second timer fires; ------X wants to know that B is alive; sends HELLO.
10 2番目のタイマは撃たれます。 ------Xは、Bが生きているのを知りたがっています。 HELLOを送ります。
Retransmission timer ------X expires; initial message could have been lost in transit; A increments error counter and sends another HELLO.
再送信タイマー------Xは期限が切れます。 初期のメッセージはトランジットで失われたかもしれません。 誤りが別の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
この計画の利点はもう片方の同輩の活気における利害関係当事者が交換処理を始めるということです。 Scenario1では、同輩Aは同輩ビーズ活気に興味を持っています、そして、その結果、同輩Aは発信します。
Huang, et al. Informational [Page 4] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[4ページ]のRFC3706
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とPeer 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.
同輩A: 同輩B: 10 2番目のタイマは撃たれます。 ------>はHELLOを送ります。 また、タイマはビーズHELLOへの期待に合図します。 Aの活気の証拠としてHELLOを受けます。
<------ 10 second timer fires; sends
HELLO.
Receives HELLO as proof
of B's liveliness.
<。------ 10 2番目のタイマは撃たれます。 HELLOを送ります。 ビーズ活気の証拠としてHELLOを受けます。
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.
同輩A: 同輩B(死んでいる): 10 2番目のタイマは撃たれます。 ------XはHELLOを送ります。 また、タイマはビーズ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の活気に決して興味を持たないかもしれません。 それにもかかわらず、Bは、Aが関心があるビーズ活気であるなら、これを意識していて、A. 不都合への周期的なHELLOsを送る必要な州の情報を保守しなければなりません。
Huang, et al. Informational [Page 5] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[5ページ]のRFC3706
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.
そのような計画は遠隔アクセスシナリオで明確になります。 多くのセッション(およそ5万人の同輩の注文での)に終わるVPNアグリゲータを考えてください。 したがって、アグリゲータがおよそ10秒毎にパケットをHELLOに送るのが必要であることで、各同輩は急速なフェイルオーバーを公正に必要とします。 アグリゲータがあらゆる数秒単位で5万のメッセージを送らなければならないとき、そのような計画は単にスケーラビリティを欠いています。
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と鼓動)の両方では、メッセージ間隔の何らかの交渉が起こらなければなりません、各実体が、同輩がどれくらいの頻度でHELLOを予想するかを知ることができるように。 これはすぐに、1段階の複雑さを加えます。 同様に、また周期的なメッセージ(他のIPSec/IKE活動にかかわらず)を送る必要性はコンピュータのオーバーヘッドをシステムに上げます。
5. DPD Protocol
5. DPDプロトコル
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と鼓動計画の短所を記述します。 本質的には、keepalivesと鼓動は一定の間隔を置いて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.
そこのB.Ifが2つの間の進行中の有効なIPSec交通である、労作と、2人のDPD同輩Aを考えてください。そうすれば、活気の証拠の必要がほとんどありません。 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は急速なフェイルオーバーを必要とするかもしれませんが、リソースクリーンアップのための同輩ビーズ要件はそれほど緊急ではありません。 DPDでは、各同輩は「心配メートル法」でそれ自身のものを定義できます--DPD交換の緊急を定義する間隔。 例を続けていて、同輩Aは、10秒になるようにDPD間隔を定義するかもしれません。 そして、同輩Aが外国行きのIPSec交通を送りますが、10秒間どんなインバウンドトラフィックも受けないなら、それはDPD交換を起こすことができます。
Huang, et al. Informational [Page 6] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[6ページ]のRFC3706
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はそれが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を見てください。
5.1. DPD Vendor ID
5.1. DPD業者ID
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能力を示すために、実体は業者IDをDPDに送らなければなりません。 DPD交換が始まることができる前にIKEセッションの両方の同輩は業者IDをDPDに送らなければなりません。 DPD Vendor 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! ! 論じ尽くされた_業者_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、0×13、0×68、0xA1、0xF1、0xC9、0x6B、0×86、0×96、0xFC、0×77、0×57、MJRとMNRがこのプロトコルの現在の主要で小さい方のバージョンに対応している、(1、0 それぞれ) それがDPD交換に参加したいなら、IKE同輩はVendor IDを送らなければなりません。
5.2. Message Exchanges
5.2. 交換処理
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*、(そこのR-U)、細切れ肉料理に通知してください。------>。
<------ HDR*, NOTIFY(R-U-THERE-
ACK), HASH
<。------ HDR*、(そこのR-U ACK)、細切れ肉料理に通知してください。
Huang, et al. Informational [Page 7] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[7ページ]のRFC3706
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メッセージが「こんにちは」に対応している、そこのR-U、ACK、"ACK"に対応しています。 両方のメッセージは単にISAKMP Notifyペイロードです、そして、そういうものとして、このドキュメントはこれらの2つの新しいISAKMP Notifyメッセージタイプを定義します:
Notify Message Value
R-U-THERE 36136
R-U-THERE-ACK 36137
-そこのメッセージ値のR-U36136に通知してください、そこのR-U、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 Vendor IDを送った実体はR-U THERE質問に応じなければなりません。 その上、実体はunencrypted R-U- THEREとR-U-THERE-ACKメッセージを拒絶しなければなりません。
5.3. NOTIFY(R-U-THERE/R-U-THERE-ACK) Message Format
5.3. 通知、(そこのR-U/、そこのR-U、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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
次..有効搭載量..予約..ペイロード長..ドメイン..解釈; プロトコルID!SPIサイズ!はメッセージタイプ!+++++++++++++++++++++++++++++++++に通知します!~セキュリティパラメタは(SPI!)~ +++++++++++++++++++++++++++++++++! 通知データ!+++++++++++++++++++++++++++++++++に索引をつけます。
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であるので、Next有効搭載量、RESERVED、および有効搭載量Length分野はそれに従って、用意ができるべきです。 残っているフィールドは以下として設定されます。
- Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI.
- Interpretation(4つの八重奏)のドメイン--、SHOULD、IPSEC-DOIに設定されてください。
- Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP.
- プロトコルへのセットがISAKMPのためのIDでなければならなかったならID(1つの八重奏)について議定書の中で述べてください。
- SPI Size (1 octet) - SHOULD be set to sixteen (16), the length of
two octet-sized ISAKMP cookies.
- SPI Size(1つの八重奏)--、SHOULD、16(16)、2個の八重奏サイズのISAKMPクッキーの長さに設定されてください。
- Notify Message Type (2 octets) - MUST be set to R-U-THERE
- Message Type(2つの八重奏)に通知してください--R-U-THEREに設定しなければなりません。
Huang, et al. Informational [Page 8] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[8ページ]のRFC3706
- Security Parameter Index (16 octets) - SHOULD be set to the
cookies of the Initiator and Responder of the IKE SA (in that
order)
- セキュリティParameter Index(16の八重奏)--、SHOULD、IKE SAのInitiatorとResponderのクッキーに設定されてください。(そのオーダーにおける)
- Notification Data (4 octets) - MUST be set to the sequence number
corresponding to this message
- 通知Data(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メッセージの形式は同じです、Notify Message Typeがそうであるに違いない例外がR-U-THERE-ACKにセットして。 一方、受信されたR-U-THEREメッセージに対応する一連番号にNotification Dataを送らなければなりません。
5.4. Impetus for DPD Exchange
5.4. DPD交換のための起動力
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メッセージの交換を強制しません。 代わりに、SHOULDがそれである場合にだけ同輩へのR U-THERE質問を送るIKE同輩はこの同輩の活気に興味を持っています。 このために、2人の同輩の間で定期的に交通を交換するなら、同輩SHOULDは活気の証拠としてこの交通を使用します、そして、両方の同輩SHOULD NOTは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を受け取らないと、実現SHOULDはR-U-THERE質問を再送します。 同輩への再送されたメッセージ、SHOULDが手が届かなく、IPSecを削除するために同輩であると仮定する実現、およびIKE SAsの何らかの数の後に。
5.5. Implementation Suggestion
5.5. 実現提案
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が少しの間隔も強制しないので、この「活動していない期間」(「メートル法で、心配する」)は実現決定として残されます。 それは交渉された値ではありません。
Huang, et al. Informational [Page 9] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[9ページ]のRFC3706
5.6. Comparisons
5.6. 比較
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と鼓動計画の上で通常のメッセージが送られる必要はないという事実から来ます。 セクション4.1に提示された例に戻って、提示されたものなどのkeepalive実現は、「タイムアウト」へのACKを同輩からHELLOメッセージと別のタイマに送るようにいつに合図するかためにワンタイマーを必要とするでしょう(また、これは再送信タイマであるかもしれません)。 同様に、セクション4.2に示されたものなどの鼓動計画は、同輩からHELLOへの期待に合図するようにいつHELLOを送るか、そして、別のタイマに合図するためにワンタイマーを保つ必要があるでしょう。 対照的に、DPD計画は、同輩からの最後の容認された交通の動向をおさえるためにタイムスタンプを保つ必要があります(その結果、「活動していない期間」の始まりを示します)。 いったんDPD R-U-THEREメッセージを送ると、実現は、「再-トランスミッション」に合図するためにはタイマを維持するだけでよいです。 したがって、活動的なタイマ状態を維持する必要性は減少します、スケーラビリティ改良をもたらして(タイムスタンプを維持するのがアクティブなタイマほど高価でないと仮定して)。 その上、実体が最近同輩から交通を受けていない場合にだけDPD交換が起こるので、また、送られた、処理されるべきIKEメッセージの数は減少します。 結果として、DPDのスケーラビリティはkeepalivesと鼓動よりはるかに良いです。
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モデルを維持します、交換が同輩の活気に興味を持っている実体だけによって起こされるということになるとき。
6. Resistance to Replay Attack and False Proof of Liveliness
6. 反射攻撃への抵抗と活気の誤った証拠
6.1. Sequence Number in DPD Messages
6.1. DPDメッセージの一連番号
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メッセージを受け取り次第、初期の送付者SHOULDは一連番号の正当性をチェックします。 一連番号がR-U-THEREメッセージと共に送られたものに合っていないなら、初期の送付者SHOULDは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メッセージSHOULDの両方がクッキーがペイロードのSPI分野で寄贈したInitiatorとResponderの正当性をチェックします。
Huang, et al. Informational [Page 10] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[10ページ]のRFC3706
6.2. Selection and Maintenance of Sequence Numbers
6.2. 一連番号の選択と維持
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ビットの境界、一連番号の高いビットからはみ出すところでSHOULDを回転させるのを防ぐには、ゼロに設定されてください。 その後のR-U-THEREメッセージは一連番号を1つ増加しなければなりません。 一連番号はIKE SAの満期のリセット、新たに選ばれた乱数への動きがそうするかもしれません。 また、予想された一連番号を合わせないなら、各実体SHOULDは、同輩のR-U-THERE一連番号、および実体SHOULD廃棄物が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.
実現は許容できる一連番号の窓を維持するかもしれませんが、この仕様はこれがどう完了しているかに関する仮定を全くしません。 一方、それは実現の特定の詳細です。
7. Security Considerations
7. セキュリティ問題
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).
一連番号は1同輩あたりの状態を維持するために実体を必要としますが、また、それらは保護の加えられた方法をある反射攻撃に提供します。 同輩Aが有効なDPD R-U- THEREメッセージを同輩Bに送るケースを考えてください。 攻撃者Cはメッセージの複本でこのメッセージと洪水Bを傍受できます。 Bは、各パケット(一連番号か一回だけが使用中であるかどうかにかかわらず)を解読して、処理しなければならないでしょう。 一連番号Bで、それを検出できます。パケットは再演されます: これらの再演されたパケットの一連番号はBがThisが、BがACKsを造って、コード化して、送る必要であるのを防ぐA.から受けると予想する増加している一連番号に合わないでしょう。 対照的に、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.
一連番号の別の利益は同輩の活気の余分な保証を加えるということです。 そして、受信機がDPD R-U-THEREメッセージ(増加している一連番号について確かめるのによる)の正当性について確かめる限り、まさしくその事実による同輩の活気を送付者が質問を開始したことを受信機を保証できます。 対照的に、一回だけはこの保証を提供できません。
Huang, et al. Informational [Page 11] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[11ページ]のRFC3706
8. IANA Considerations
8. IANA問題
There is no IANA action required for this document. DPD uses notify numbers from the private range.
このドキュメントのためのIANA必要な行動が全くありません。 DPD用途は個人的な範囲から数に通知します。
9. References
9. 参照
9.1. Normative Reference
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[2] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[2] ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
10. Editors' Addresses
10. エディタのアドレス
Geoffrey Huang Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ジェフリーホアンシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 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
8歳のK2K3EカナダのステファーヌボーリューシスコシステムズInc.2000革新ドライブKanata
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
Suite205フランクリン、MA ダニーロシュフォールシスコシステムズ, Inc.124Grove通り、02038
Phone: (508) 553-8644 EMail: danyr@cisco.com
以下に電話をしてください。 (508) 553-8644 メールしてください: danyr@cisco.com
Huang, et al. Informational [Page 12] RFC 3706 Detecting Dead IKE Peers February 2004
ホアン、他 2004年2月に死んでいるIKE同輩を検出する情報[12ページ]のRFC3706
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Huang, et al. Informational [Page 13]
ホアン、他 情報[13ページ]
一覧
スポンサーリンク
