[要約] RFC 4101は、プロトコルモデルの作成に関するガイドラインを提供するものであり、プロトコルの設計と実装のための手法を提供します。目的は、プロトコルの明確な定義と相互運用性の向上を促進することです。
Network Working Group E. Rescorla
Request for Comments: 4101 RTFM, Inc.
Category: Informational IAB
June 2005
Writing Protocol Models
プロトコルモデルの書き込み
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system.
IETFプロセスは、ピアレビューに依存します。ただし、IETFドキュメントは一般に、レビュアーではなく実装者に役立つように書かれています。特に、一般に、ワイヤー上の状態マシンとビットの完全な説明を提供するために細心の注意が払われていますが、このレベルの詳細は最初の理解の邪魔になる傾向があります。このドキュメントでは、レビュアーがシステムの本質を迅速に把握できるようにするプロトコル「モデル」を提供するためのアプローチについて説明します。
The IETF process depends on peer review. However, in many cases, the documents submitted for publication are extremely difficult to review. Because reviewers have only limited amounts of time, this leads to extremely long review times, inadequate reviews, or both. In our view, a large part of the problem is that most documents fail to present an architectural model for how the protocol operates, opting instead to simply describe the protocol and let the reviewer figure it out.
IETFプロセスは、ピアレビューに依存します。ただし、多くの場合、公開のために提出された文書をレビューするのは非常に困難です。レビュアーの時間は限られているため、これは非常に長いレビュー時間、不十分なレビュー、またはその両方につながります。私たちの見解では、問題の大部分は、ほとんどのドキュメントがプロトコルの動作についてアーキテクチャモデルを提示できないことです。
This is acceptable when documenting a protocol for implementors, because they need to understand the protocol in any case; but it dramatically increases the strain on reviewers. Reviewers need to get the big picture of the system and then focus on particular points. They simply do not have time to give the entire document the attention an implementor would.
これは、いずれにせよ、プロトコルを理解する必要があるため、実装者のプロトコルを文書化する場合に受け入れられます。しかし、それはレビュアーの緊張を劇的に増加させます。レビュー担当者は、システムの全体像を取得し、特定のポイントに集中する必要があります。彼らは単にドキュメント全体に実装者に注意を払う時間がない。
One way to reduce this load is to present the reviewer with a MODEL -- a short description of the system in overview form. This provides the reviewer with the context to identify the important or difficult pieces of the system and focus on them for review. As a side benefit, if the model is done first, it can be serve as an aid to the detailed protocol design and a focus for early review, prior to protocol completion. The intention is that the model would either be the first section of the protocol document or be a separate document provided with the protocol.
この負荷を減らす1つの方法は、レビュアーにモデルを提示することです。これは、概要フォームのシステムの簡単な説明です。これにより、レビュアーにコンテキストを提供し、システムの重要なまたは困難な部分を特定し、レビューのためにそれらに焦点を合わせます。副次的な利点として、モデルが最初に行われた場合、プロトコルの完了前に、詳細なプロトコル設計の援助と早期レビューの焦点として役立つことができます。意図は、モデルがプロトコルドキュメントの最初のセクションであるか、プロトコルで提供される個別のドキュメントになることです。
A protocol model needs to answer three basic questions:
プロトコルモデルは、3つの基本的な質問に答える必要があります。
1. What problem is the protocol trying to achieve? 2. What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol?
1. プロトコルが達成しようとしている問題は何ですか？2.どのようなメッセージが送信されていますか？3.プロトコルの重要な、しかし邪悪な特徴は何ですか？
The basic idea is to provide enough information that the reader could design a protocol which was roughly isomorphic to the protocol being described. Of course, this doesn't mean that the protocol would be identical, but merely that it would share most important features. For instance, the decision to use a KDC-based authentication model is an essential feature of Kerberos [KERBEROS]. By contrast, the use of ASN.1 is a simple implementation decision. S-expressions -- or XML, had it existed at the time -- would have served equally well.
基本的なアイデアは、読者が記述されているプロトコルに対してほぼ等分率のプロトコルを設計できる十分な情報を提供することです。もちろん、これはプロトコルが同一であることを意味するのではなく、単に最も重要な機能を共有することを意味します。たとえば、KDCベースの認証モデルを使用する決定は、Kerberos [Kerberos]の重要な機能です。対照的に、ASN.1の使用は単純な実装決定です。S-Expressions（またはXMLが当時存在していた）は、同様にうまく機能していたでしょう。
The purpose of a protocol model is explicitly not to provide a complete or alternate description of the protocol being discussed. Instead, it is to provide a big picture overview of the protocol so that readers can quickly understand the essential elements of how it works.
プロトコルモデルの目的は、議論されているプロトコルの完全または代替の説明を明示的に提供しないことです。代わりに、読者がその仕組みの重要な要素を迅速に理解できるように、プロトコルの全体像の概要を提供することです。
In this section we discuss basic principles that should guide your presentation.
このセクションでは、プレゼンテーションを導くべき基本原則について説明します。
Humans are only capable of keeping a very small number of pieces of information in their head at once. Because we're interested in ensuring that people get the big picture, we have to dispense with a lot of detail. That's good, not bad. The simpler you can make things the better.
人間は、非常に少数の情報を頭の中に一度に保つことができるだけです。私たちは人々が全体像を得ることに興味があるので、多くの詳細を分配しなければなりません。それは良いことです、悪くない。より簡単に物事をより良くすることができます。
A key technique for representing complex systems is to try to abstract away pieces. For instance, maps are better than photographs for finding out where you want to go because they provide an abstract, stylized, view of the information you're interested in. Don't be afraid to compress multiple protocol elements into a single abstract piece for pedagogical purposes.
複雑なシステムを表現するための重要な手法は、ピースを抽象化しようとすることです。たとえば、マップは、興味のある情報の抽象的で様式化されたビューを提供するため、どこに行きたいかを見つけるための写真よりも優れています。教育目的。
The converse of the previous principle is that sometimes details help to bring a description into focus. Many people work better when given examples. Thus, it's often a good approach to talk about the material in the abstract and then provide a concrete description of one specific piece to bring it into focus. Authors should focus on the normal path. Error cases and corner cases should only be discussed where they help illustrate an important point.
前の原則の逆は、詳細が説明を焦点にするのに役立つことがあるということです。多くの人が例を与えられたとき、よりよく働きます。したがって、多くの場合、抽象の素材について話すことは良いアプローチであり、1つの特定の部分の具体的な説明を提供して焦点を合わせます。著者は通常のパスに焦点を当てる必要があります。エラーケースとコーナーケースは、重要なポイントを説明するのに役立つ場合にのみ議論する必要があります。
Our experience indicates that it is easiest to grasp protocol models when they are presented in visual form. We recommend a presentation format centered around a few key diagrams, with explanatory text for each. These diagrams should be simple and typically consist of "boxes and arrows" -- boxes representing the major components, arrows representing their relationships, and labels indicating important features.
私たちの経験は、プロトコルモデルが視覚的な形で提示されたときに、プロトコルモデルを把握するのが最も簡単であることを示しています。いくつかの重要な図を中心としたプレゼンテーション形式をお勧めします。それぞれに説明テキストが記載されています。これらの図はシンプルでなければならず、通常は「ボックスと矢印」で構成されています。主要なコンポーネントを表すボックス、関係を表す矢印、重要な機能を示すラベルです。
We recommend a presentation structured in three parts to match the three questions mentioned in the previous sections. Each part should contain 1-3 diagrams intended to illustrate the relevant points.
前のセクションで述べた3つの質問に一致するように、3つの部分で構成されたプレゼンテーションをお勧めします。各部分には、関連するポイントを説明することを目的とした1〜3の図を含める必要があります。
The most critical task that a protocol model must perform is to explain what the protocol is trying to achieve. This provides crucial context for understanding how the protocol works, and whether it meets its goals. Given the desired goals, an experienced reviewer will usually have an idea of how they would approach the problem and, thus, be able to compare that approach with the approach taken by the protocol under review.
プロトコルモデルが実行しなければならない最も重要なタスクは、プロトコルが達成しようとしていることを説明することです。これは、プロトコルがどのように機能するか、そしてそれが目標を達成するかどうかを理解するための重要なコンテキストを提供します。望ましい目標を考えると、経験豊富なレビュアーは通常、問題にどのようにアプローチするかについてのアイデアを持ち、そのアプローチをレビュー中のプロトコルが取ったアプローチと比較することができます。
The "Problem" section of the model should start with a short statement of the environments in which the protocol is expected to be used. This section should describe the relevant entities and the likely scenarios under which they would participate in the protocol. The Problem section should feature a diagram of the major communicating parties and their inter-relationships. It is particularly important to lay out the trust relationships between the various parties, as these are often unobvious.
モデルの「問題」セクションは、プロトコルが使用されると予想される環境の短いステートメントから開始する必要があります。このセクションでは、関連するエンティティと、プロトコルに参加する可能性のあるシナリオについて説明する必要があります。問題セクションでは、主要な通信当事者とその相互関係の図を紹介する必要があります。さまざまな当事者間の信頼関係をレイアウトすることは特に重要です。
STUN [STUN] is a UNilateral Self-Address Fixing (UNSAF) [UNSAF] protocol that allows a machine located behind a NAT to determine what its external apparent IP address is. Although STUN provides a complete and thorough description of the operation of the protocol, it does not provide a brief, up-front overview suitable for a quick understanding of its operation. The rest of this section shows what a suitable overview might look like.
Stun [Stun]は、NATの後ろにあるマシンが外部の見かけのIPアドレスが何であるかを判断できる一方的な自己アドレス固定（UNSAF）[UNSAF]プロトコルです。Stunはプロトコルの動作について完全かつ徹底的な説明を提供しますが、その動作を迅速に理解するのに適した簡単な前向きな概要は提供されません。このセクションの残りの部分は、適切な概要がどのように見えるかを示しています。
Network Address Translation (NAT) makes it difficult to run a number of classes of service from behind the NAT gateway. This is particularly a problem when protocols need to advertise address/port pairs as part of the application layer protocol. Although the NAT can be configured to accept data destined for that port, address translation means the address that the application knows about is not the same as the one on which it is reachable.
ネットワークアドレス変換（NAT）により、NATゲートウェイの後ろから多くのクラスのサービスを実行することが困難になります。これは、プロトコルがアプリケーションレイヤープロトコルの一部としてアドレス/ポートペアを宣伝する必要がある場合に特に問題です。NATはそのポートに導かれたデータを受け入れるように構成できますが、アドレス変換は、アプリケーションが知っているアドレスが到達可能なものと同じではないことを意味します。
Consider the scenario represented in the figure below. A SIP client is initiating a session with a SIP server in which it wants the SIP server to send it some media. In its Session Description Protocol (SDP) [SDP] request it provides the IP address and port on which it is listening. However, unbeknownst to the client, a NAT is in the way. The NAT translates the IP address in the header, but unless it is SIP aware, it doesn't change the address in the request. The result is that the media goes into a black hole.
下の図に示すシナリオを考えてみましょう。SIPクライアントは、SIPサーバーがメディアを送信することを望んでいるSIPサーバーでセッションを開始しています。そのセッション説明プロトコル（SDP）[SDP]リクエストでは、リスニングしているIPアドレスとポートを提供します。ただし、クライアントには知られていないため、NATは邪魔になります。NATはヘッダー内のIPアドレスを翻訳しますが、SIPが認識しない限り、リクエストのアドレスを変更しません。その結果、メディアはブラックホールに入ります。
+-----------+
| SIP |
| Server |
| |
+-----------+
^
| [FROM: 198.203.2.1:8954]
| [MSG: SEND MEDIA TO 10.0.10.5:6791]
|
|
+-----------+
| |
| NAT |
--------------+ Gateway +----------------
| |
+-----------+
^
| [FROM: 10.0.10.5:6791]
| [MSG: SEND MEDIA TO 10.0.10.5:6791]
|
10.0.10.5
+-----------+
| SIP |
| Client |
| |
+-----------+
The purpose of STUN is to allow clients to detect this situation and determine the address mapping. They can then place the appropriate address in their application-level messages. This is done by using an external STUN server. That server is able to determine the translated address and tell the STUN client, as shown below.
スタンの目的は、クライアントがこの状況を検出し、アドレスマッピングを決定できるようにすることです。その後、適切なアドレスをアプリケーションレベルのメッセージに配置できます。これは、外部STUNサーバーを使用して行われます。そのサーバーは、以下に示すように、翻訳されたアドレスを決定し、スタンクライアントに伝えることができます。
+-----------+
| STUN |
| Server |
| |
+-----------+
^ |
[IP HDR FROM: 198.203.2.1:8954] | | [IP HDR TO: 198.203.2.1:8954]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954]
| v
+-----------+
| |
| NAT |
--------------+ Gateway +----------------
| |
+-----------+
^ |
[IP HDR FROM: 10.0.10.5:6791] | | [IP HDR TO: 10.0.10.5:6791]
[MSG: WHAT IS MY ADDRESS?] | | [MSG: YOU ARE 198.203.2.1:8954]
| v
10.0.10.5
+-----------+
| SIP |
| Client |
| |
+-----------+
Once the problem has been described, the next task is to give a broad overview of the protocol. This means showing, either in "ladder diagram" or "boxes and arrows" form, the protocol messages that flow between the various networking agents. This diagram should be accompanied with explanatory text that describes the purpose of each message and the MAJOR data elements.
問題が記載されたら、次のタスクはプロトコルの幅広い概要を説明することです。これは、「はしご図」または「ボックスと矢印」フォームのいずれかで、さまざまなネットワーキングエージェント間で流れるプロトコルメッセージを表示することを意味します。この図には、各メッセージの目的と主要なデータ要素を説明する説明テキストを添付する必要があります。
This section SHOULD NOT contain detailed descriptions of the protocol messages or of each data element. In particular, bit diagrams, ASN.1 modules, and XML schema SHOULD NOT be shown. The purpose of this section is not to provide a complete description of the protocol, but to provide enough of a map that a person reading the full protocol document can see where each specific piece fits.
このセクションには、プロトコルメッセージまたは各データ要素の詳細な説明を含めるべきではありません。特に、ビット図、ASN.1モジュール、XMLスキーマは表示されないでください。このセクションの目的は、プロトコルの完全な説明を提供することではなく、完全なプロトコルドキュメントを読んでいる人が各特定のピースがどこに適合するかを確認できるほど十分なマップを提供することです。
In certain cases, it may be helpful to provide a state machine description of the behavior of network elements. However, such state machines should be kept as minimal as possible. Remember that the purpose is to promote high-level comprehension, not complete understanding.
特定の場合、ネットワーク要素の動作の状態マシンの説明を提供することが役立つ場合があります。ただし、そのような状態マシンは、できるだけ最小限に抑える必要があります。目的は、完全な理解ではなく、高レベルの理解を促進することであることを忘れないでください。
Datagram Congestion Control Protocol [DCCP] is a protocol for providing datagram transport with network-friendly congestion avoidance behavior. The DCCP base protocol document is over 100 pages long and the congestion control mechanisms themselves are separate. Therefore, it is very helpful to have a an architectural overview of DCCP that abstracts away the details. The remainder of this section is an attempt to do so.
Datagram混雑制御プロトコル[DCCP]は、ネットワークに優しい混雑回避動作を備えたデータグラムトランスポンドを提供するためのプロトコルです。DCCPベースプロトコルドキュメントの長さは100ページ以上で、混雑制御メカニズム自体は別々です。したがって、詳細を抽象化するDCCPのアーキテクチャの概要を持つことは非常に役立ちます。このセクションの残りの部分は、そうする試みです。
NOTE: The author of this document was on the DCCP review team and his experience with that document was one of the motivating factors for this document. Since the review, the DCCP authors have added some overview material, some of which derives from earlier versions of this document.
注：このドキュメントの著者はDCCPレビューチームにあり、そのドキュメントでの彼の経験は、このドキュメントの動機付け要因の1つでした。レビュー以来、DCCPの著者はいくつかの概要資料を追加しており、その一部はこのドキュメントの以前のバージョンから派生しています。
Although DCCP is datagram-oriented like UDP, it is stateful like TCP. Connections go through the following phases:
DCCPはUDPのようにデータグラム指向ですが、TCPのようにステートフしています。接続は次のフェーズを通過します。
1. Initiation 2. Feature negotiation 3. Data transfer 4. Termination
1. 開始2.機能交渉3.データ転送4.終了
As with TCP, the initiation phase of DCCP involves a three-way handshake, shown below.
TCPと同様に、DCCPの開始フェーズには、以下に示す3方向の握手が含まれます。
Client Server
------ ------
DCCP-Request ->
[Ports, Service,
Features]
<- DCCP-Response
[Features,
Cookie]
DCCP-Ack ->
[Features,
Cookie]
DCCP 3-way handshake
DCCP 3ウェイハンドシェイク
In the DCCP-Request message, the client tells the server the name of the service it wants to talk to and the ports it wants to communicate on. Note that ports are not tightly bound to services, as they are in TCP or UDP common practice. It also starts feature negotiation. For pedagogical reasons, we will present feature negotiation separately in the next section. However, realize that the early phases of feature negotiation happen concurrently with initiation.
DCCP-Requestメッセージでは、クライアントはサーバーに通信したいサービスの名前と通信したいポートをサーバーに伝えます。ポートはTCPまたはUDPの一般的な慣行にあるため、サービスにしっかりと結合していないことに注意してください。また、機能交渉を開始します。教育的な理由から、次のセクションで特集交渉を個別に提示します。ただし、機能交渉の初期段階が開始と同時に行われることを認識してください。
In the DCCP-Response message, the server tells the client that it is willing to accept the connection and continues feature negotiation. In order to prevent SYN flood-style DOS attacks, DCCP incorporates an IKE-style cookie exchange. The server can provide the client with a cookie that contains all of the negotiation state. This cookie must be echoed by the client in the DCCP-Ack, thus removing the need for the server to keep state.
DCCP応答メッセージでは、サーバーはクライアントに、接続を受け入れる意思があり、機能交渉を継続することを伝えます。Syn FloodスタイルのDOS攻撃を防ぐために、DCCPにはIKEスタイルのCookie Exchangeが組み込まれています。サーバーは、すべてのネゴシエーション状態を含むCookieをクライアントに提供できます。このCookieは、DCCP-CACKのクライアントがエコーする必要があるため、サーバーが状態を維持する必要性を削除する必要があります。
In the DCCP-Ack message, the client acknowledges the DCCP-Response and returns the cookie to permit the server to complete its side of the connection. As indicated above, this message may also include feature negotiation messages.
DCCP-ackメッセージで、クライアントはDCCP応答を認め、Cookieを返してサーバーが接続の側面を完成させることを許可します。上記のように、このメッセージには機能交渉メッセージも含まれる場合があります。
In DCCP, feature negotiation is performed by attaching options to other DCCP packets. Thus, feature negotiation can be piggybacked on any other DCCP message. This allows feature negotiation during connection initiation as well as during data flow.
DCCPでは、他のDCCPパケットにオプションを添付することにより、機能交渉が実行されます。したがって、特徴のネゴシエーションは、他のDCCPメッセージでピギーバックすることができます。これにより、接続開始中およびデータフロー中の機能交渉が可能になります。
Somewhat unusually, DCCP features are one-sided. Thus, it's possible to have a different congestion control regime for data sent from client to server than from server to client.
やや異常に、DCCP機能は片側です。したがって、サーバーからクライアントまでよりも、クライアントからサーバーに送信されるデータのために、異なる混雑制御体制を持つことができます。
Feature negotiation is done with the Change and Confirm options. There are four feature negotiation options in all: Change L, Confirm L, Change R, and Confirm R. The "L" options are sent by the feature location, where the feature is maintained, and the "R" options are sent by the feature remote.
機能交渉は、変更を行い、オプションを確認します。すべてに4つの機能交渉オプションがあります。L、変更l、確認l、変更r、および確認。「l」オプションは、機能が維持されている機能の場所によって送信され、「r」オプションは送信されます。機能リモート。
A Change R message says to the peer "change this option setting on your side". The peer can respond with a Confirm L, meaning "I've changed it". Some features allow Change R options to contain multiple values, sorted in preference order. For example:
Change Rメッセージには、ピアに「このオプション設定を変更する」と書かれています。ピアは、「私はそれを変更した」ということを意味する確認lで応答できます。いくつかの機能により、Rオプションの変更は、優先順序でソートされた複数の値を含めることができます。例えば：
Client Server
------ ------
Change R(CCID, 2) -->
<-- Confirm L(CCID, 2)
* agreement that CCID/Server = 2 *
Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
In the second exchange, the client requests that the server use either CCID 3 or CCID 4, with 3 preferred. The server chooses 4 and supplies its preference list, "4 2".
2番目の交換では、クライアントはサーバーがCCID 3またはCCID 4のいずれかを使用することを要求します。サーバーは4を選択し、優先リスト「4 2」を提供します。
The Change L and Confirm R options are used for feature negotiations that are initiated by the feature location. In the following example, the server requests that CCID/Server be set to 3 or 2 (with 3 being preferred), and the client agrees.
変更lおよび確認rオプションは、機能の場所によって開始される機能交渉に使用されます。次の例では、サーバーはCCID/サーバーを3または2に設定することを要求し、クライアントは同意します。
Client Server
------ ------
<-- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) -->
* agreement that CCID/Server = 3 *
Rather than have a single congestion control regime, as in TCP, DCCP offers a variety of negotiable congestion control regimes. The DCCP documents describe two congestion control regimes: additive increase, multiplicative decrease (CCID-2 [CCID2]), and TCP-friendly rate control (CCID-3 [CCID3]). CCID-2 is intended for applications that want maximum throughput. CCID-3 is intended for real-time applications that want smooth response to congestion.
TCPのように、単一の混雑制御体制があるのではなく、DCCPはさまざまな交渉可能な混雑制御体制を提供します。DCCPドキュメントでは、2つの混雑制御レジームが記載されています：加法の増加、乗法減少（CCID-2 [CCID2]）、およびTCPに優しいレート制御（CCID-3 [CCID3]）。CCID-2は、最大スループットを必要とするアプリケーションを対象としています。CCID-3は、うっ血に対するスムーズな応答を必要とするリアルタイムアプリケーションを対象としています。
CCID-2's congestion control is extremely similar to that of TCP. The sender maintains a congestion window and sends packets until that window is full. Packets are Acked by the receiver. Dropped packets and ECN [ECN] are used to indicate congestion. The response to congestion is to halve the congestion window. One subtle difference between DCCP and TCP is that the Acks in DCCP must contain the sequence numbers of all received packets (within a given window), not just the highest sequence number, as in TCP.
CCID-2の混雑制御は、TCPの混雑制御と非常に似ています。送信者は輻輳ウィンドウを維持し、そのウィンドウがいっぱいになるまでパケットを送信します。パケットはレシーバーによってackedされます。ドロップされたパケットとECN [ECN]は、混雑を示すために使用されます。輻輳に対する応答は、うっ血ウィンドウを半分にすることです。DCCPとTCPの微妙な違いの1つは、DCCPのACKに、TCPのように最高のシーケンス番号だけでなく、すべての受信パケット（特定のウィンドウ内）のシーケンス番号を含める必要があることです。
CCID-3 is an equation-based form of rate control, intended to provide smoother response to congestion than CCID-2. The sender maintains a "transmit rate". The receiver sends Ack packets that contain information about the receiver's estimate of packet loss. The sender uses this information to update its transmit rate. Although CCID-3 behaves somewhat differently than TCP in its short-term congestion response, it is designed to operate fairly with TCP over the long term.
CCID-3は、CCID-2よりもうっ血に対するより滑らかな応答を提供することを目的とした方程式ベースのレート制御形式です。送信者は「送信率」を維持します。受信者は、受信者のパケット損失の推定に関する情報を含むACKパケットを送信します。送信者は、この情報を使用して送信率を更新します。CCID-3は、短期輻輳応答でTCPとは多少異なって動作しますが、長期にわたってTCPで公正に動作するように設計されています。
Connection termination in DCCP is initiated by sending a Close message. Either side can send a Close message. The peer then responds with a Reset message, at which point the connection is closed. The side that sent the Close message must quietly preserve the socket in TIMEWAIT state for 2MSL.
DCCPの接続終了は、密接なメッセージを送信することにより開始されます。どちらの側も密接なメッセージを送信できます。次に、ピアはリセットメッセージで応答し、その時点で接続が閉じられます。密接なメッセージを送信した側は、2MSLのタイムウェイト状態のソケットを静かに保存する必要があります。
Client Server
------ ------
Close ->
<- Reset
[Remains in TIMEWAIT]
Note that the server may wish to close the connection but not remain in TIMEWAIT (e.g., due to a desire to minimize server-side state). In order to accomplish this, the server can elicit a Close from the client by sending a CloseReq message and, thus, keep the TIMEWAIT state on the client.
サーバーは接続を閉じたいが、タイムウェイトには留まらないことに注意してください（たとえば、サーバー側の状態を最小限に抑えたいという要望のため）。これを達成するために、サーバーはクローズレクメッセージを送信することでクライアントからクライアントを引き出すことができ、したがって、クライアントにタイムウェイト状態を維持できます。
The final section (if there is one) should contain an explanation of any important protocol features that are not obvious from the previous sections. In the best case, all the important features of the protocol would be obvious from the message flow. However, this isn't always the case. This section is an opportunity for the author to explain those features. Authors should think carefully before writing this section. If there are no important points to be made, they should not populate this section.
最後のセクション（ある場合）には、前のセクションからは明らかではない重要なプロトコル機能の説明を含める必要があります。最良の場合、プロトコルのすべての重要な機能は、メッセージフローから明らかです。ただし、これは必ずしもそうではありません。このセクションは、著者がこれらの機能を説明する機会です。著者は、このセクションを書く前に慎重に考える必要があります。重要なポイントがない場合は、このセクションを入力しないでください。
Examples of the kind of feature that belongs in this section include: high-level security considerations, congestion control information, and overviews of the algorithms that the network elements are intended to follow. For instance, if you have a routing protocol, you might use this section to sketch out the algorithm that the router uses to determine the appropriate routes from protocol messages.
このセクションに属する機能の種類の例には、次のものがあります。高レベルのセキュリティに関する考慮事項、混雑制御情報、およびネットワーク要素が従うことを意図しているアルゴリズムの概要。たとえば、ルーティングプロトコルがある場合は、このセクションを使用して、ルーターが使用するアルゴリズムをスケッチしてプロトコルメッセージから適切なルートを決定できます。
The WebDAV standard [WEBDAV] is fairly terse, preferring to define the required behaviors and let the reader work out the implications. In some situations, explanatory material that details those implications can help the reader understand the overall model. The rest of this section describes one such case.
WebDav標準[WebDav]はかなり簡潔で、必要な動作を定義し、読者に意味を解決できるようにします。状況によっては、これらの意味を詳述する説明資料は、読者がモデル全体を理解するのに役立ちます。このセクションの残りの部分では、そのようなケースの1つについて説明します。
WebDAV [WEBDAV] includes both a COPY method and a MOVE method. While a MOVE can be thought of as a COPY followed by DELETE, COPY+DELETE and MOVE aren't entirely equivalent.
webdav [webdav]には、コピー方法と移動方法の両方が含まれています。動きはコピーとその後の削除と考えることができますが、コピー削除と移動は完全に同等ではありません。
The use of COPY+DELETE as a substitute for MOVE is problematic because of the creation of the intermediate file. Consider the case where the user is approaching a quota boundary. A COPY+DELETE should be forbidden because it would temporarily exceed the quota. However, a simple rename should work in this situation.
中間ファイルが作成されているため、移動の代替品としてコピー削除の使用に問題があります。ユーザーがクォータ境界に近づいている場合を考えてください。コピー削除は、一時的にクォータを超えるため、禁止されている必要があります。ただし、この状況では簡単な名前の変更が機能するはずです。
The second issue is permissions. The WebDAV permissions model allows the server to grant users permission to rename files, but not to create new ones. This is unusual in ordinary filesystems, but nothing prevents it in WebDAV. This is clearly not possible if a client uses COPY+DELETE to do a MOVE.
2番目の問題は許可です。WebDAV許可モデルにより、サーバーはユーザーにファイルの名前を変更する許可を付けることができますが、新しいファイルを作成することはできません。これは通常のファイルシステムでは珍しいことですが、WebDavでは何も防止しません。これは、クライアントがコピー削除を使用して移動を行う場合、明らかに不可能です。
Finally, a COPY+DELETE does not produce the same logical result as would be expected with a MOVE. Because COPY creates a new resource, it is permitted (but not required) to use the time of new file creation as the creation date property. By contrast, the expectation for MOVE is that the renamed file will have the same properties as the original.
最後に、コピー削除は、移動で予想されるのと同じ論理的結果を生成しません。Copyは新しいリソースを作成するため、新しいファイル作成の時間を作成日付プロパティとして使用することが許可されています（必要ありません）。対照的に、移動への期待は、名前変更されたファイルが元のプロパティと同じプロパティを持つことです。
The requirement that Internet-Drafts and RFCs be renderable in ASCII is a significant obstacle when writing the sort of graphics-heavy document being described here. Authors may find it more convenient to do a separate protocol model document in Postscript or PDF and simply make it available at review time -- though an archival version would certainly be handy.
ASCIIでインターネットドラフトとRFCがレンダリング可能であるという要件は、ここで説明されているグラフィックが多いドキュメントの種類を書く際の重要な障害です。著者は、PostScriptまたはPDFで個別のプロトコルモデルドキュメントを作成し、レビュー時に使用できるようにする方が便利な場合がありますが、アーカイブバージョンは確かに便利です。
Internet Key Exchange (IKE) [IKE] is one of the most complicated security protocols ever designed by the IETF. Although the basic IKE core is a fairly straightforward Diffie-Hellman-based handshake, this can often be difficult for new readers to understand abstractly, apart from the protocol details. The remainder of this section provides overview of IKE suitable for those new readers.
Internet Key Exchange（IKE）[IKE]は、IETFによってこれまでに設計された最も複雑なセキュリティプロトコルの1つです。Basic Ike Coreはかなり単純なDiffie-Hellmanベースのハンドシェイクですが、これは、プロトコルの詳細を除いて、新しい読者が抽象的に理解することがしばしば困難になる可能性があります。このセクションの残りの部分では、これらの新しい読者に適したIKEの概要を説明します。
Internet key Exchange (IKE) [IKE] is a key establishment and parameter negotiation protocol for Internet protocols. Its primary application is for establishing security associations (SAs) [IPSEC] for IPsec AH [AH] and ESP [ESP].
インターネットキーエクスチェンジ（IKE）[IKE]は、インターネットプロトコルの主要な確立およびパラメーターネゴシエーションプロトコルです。その主なアプリケーションは、IPSEC AH [AH]およびESP [ESP]のセキュリティ協会（SAS）[IPSEC]を確立するためです。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | Key | | IKE | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec | | AH/ESP | | IPsec | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
The general deployment model for IKE is shown above. The IPsec engines and IKE engines typically are separate modules. When no security association exists for a packet that needs to be processed (either sent or received), the IPsec engine contacts the IKE engine and asks it to establish an appropriate SA. The IKE engine contacts the appropriate peer and uses IKE to establish the SA. Once the IKE handshake is finished it registers the SA with the IPsec engine.
IKEの一般的な展開モデルを上に示します。IPSECエンジンとIKEエンジンは通常、個別のモジュールです。IPSECエンジンはIKEエンジンに接触し、適切なSAを確立するように依頼する（送信または受信）、処理する必要がある（送信または受信）セキュリティアソシエーションが存在しない場合です。IKEエンジンは適切なピアに接触し、IKEを使用してSAを確立します。IKEハンドシェイクが終了すると、IPSECエンジンでSAを登録します。
In addition, IKE traffic between the peers can be used to refresh keying material or adjust operating parameters, such as algorithms.
さらに、ピア間のIKEトラフィックを使用して、キーイング素材を更新したり、アルゴリズムなどの動作パラメーターを調整できます。
Although IPsec is basically symmetrical, IKE is not. The party who sends the first message is called the INITIATOR. The other party is called the RESPONDER. In the case of TCP connections, the INITIATOR will typically be the peer doing the active open (i.e., the client).
IPSECは基本的に対称的ですが、IKEはそうではありません。最初のメッセージを送信するパーティーは、イニシエーターと呼ばれます。相手はレスポンダーと呼ばれます。TCP接続の場合、イニシエーターは通常、アクティブなオープン（つまり、クライアント）を行うピアです。
One of the major concerns in IKE design was that traffic be protected even if the keying material of the nodes was later compromised, provided that the session in question had terminated and so the session-specific keying material was gone. This property is often called Perfect Forward Secrecy (PFS) or back traffic protection.
IKE設計の主な懸念の1つは、問題のセッションが終了したため、セッション固有のキーイング材料がなくなった場合、ノードのキーイング材料が後に侵害されたとしても、トラフィックが保護されることでした。このプロパティは、多くの場合、Perfect Forward Secrecy（PFS）または逆交通保護と呼ばれます。
Because IKE allows arbitrary peers to initiate computationally-expensive cryptographic operations, it potentially allows resource consumption denial of service (DoS) attacks to be mounted against the IKE engine. IKE includes countermeasures designed to minimize this risk.
IKEは、任意のピアが計算的に高価な暗号操作を開始できるようにするため、リソース消費拒否（DOS）攻撃をIKEエンジンに対して取り付けることができる可能性があります。IKEには、このリスクを最小限に抑えるために設計された対策が含まれています。
Because Security Associations are essentially symmetric, both sides must, in general, be authenticated. Because IKE needs to be able to establish SAs between a broad range of peers with various kinds of prior relationships, IKE supports a very flexible keying model. Peers can authenticate via shared keys, digital signatures (typically from keys vouched for by certificates), or encryption keys.
セキュリティ関連は本質的に対称であるため、双方は一般に認証されなければなりません。IKEは、さまざまな種類の以前の関係を持つ幅広い仲間の間でSASを確立できる必要があるため、IKEは非常に柔軟なキーイングモデルをサポートしています。ピアは、共有キー、デジタル署名（通常は証明書で保証されたキーから）、または暗号化キーを介して認証できます。
Although IKE requires the peers to authenticate to each other, it was considered desirable by the working group to provide some identity protection for the communicating peers. In particular, the peers should be able to hide their identity from passive observers and one peer should be able to require the author to authenticate before they self-identity. In this case, the designers chose to make the party who speaks first (the INITIATOR) identify first.
IKEは仲間に互いに認証することを要求していますが、ワーキンググループが通信仲間にある程度のアイデンティティ保護を提供することは望ましいと考えられていました。特に、ピアは受動的なオブザーバーから身元を隠すことができるはずであり、1人のピアは、著者が自己同一性の前に認証するように要求できるはずです。この場合、デザイナーは、最初に話す（イニシエーター）を最初に識別するようにすることを選択しました。
At a very high level, there are two kinds of IKE handshake:
非常に高いレベルでは、2種類のIKEハンドシェイクがあります。
(1) Those that establish an IKE security association. (2) Those that establish an AH or ESP security association.
(1) IKEセキュリティ協会を設立するもの。（2）AHまたはESPセキュリティ協会を設立するもの。
When two peers that have never communicated before need to establish an AH/ESH SA, they must first establish an IKE SA. This allows them to exchange an arbitrary amount of protected IKE traffic. They can then use that SA to do a second handshake to establish SAs for AH and ESP. This process is shown in schematic form below. The notation E(SA,XXXX) is used to indicate that traffic is encrypted under a given SA.
AH/ESH SAを確立する必要がある前に通信したことのない2人のピアが、最初にIKE SAを確立する必要があります。これにより、保護されたIKEトラフィックの任意の量を交換できます。その後、そのSAを使用して、AHおよびESPのSASを確立するために首をかき立てることができます。このプロセスは、以下の概略形式で示されています。表記E（SA、XXXX）は、特定のSAの下でトラフィックが暗号化されていることを示すために使用されます。
Initiator Responder
--------- ---------
Handshake MSG -> \ Stage 1:
<- Handshake MSG \ Establish IKE
/ SA (IKEsa)
[...] /
\ Stage 2:
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA
The two kinds of IKE handshake
2種類のIKEハンドシェイク
IKE terminology is somewhat confusing, referring under different circumstances to "phases" and "modes". For maximal clarity we will refer to the Establishment of the IKE SA as "Stage 1" and the Establishment of AH/ESP SAs as "Stage 2". Note that it's quite possible for there to be more than one Stage 2 handshake, once Stage 1 has been finished. This might be useful for establishing multiple AH/ESP SAs with different cryptographic properties.
Ikeの用語はやや混乱しており、さまざまな状況下で「フェーズ」と「モード」を参照しています。最大の明確さのために、IKE SAの確立を「ステージ1」と呼び、AH/ESP SASを「ステージ2」と呼びます。ステージ1が終了すると、ステージ2以上の握手があることはかなり可能であることに注意してください。これは、異なる暗号化特性を持つ複数のAH/ESP SASを確立するのに役立つかもしれません。
The Stage 1 and Stage 2 handshakes are actually rather different, because the Stage 2 handshake can, of course, assume that its traffic is being protected with an IKE SA. Accordingly, we will first discuss Stage 1 and then Stage 2.
ステージ2とステージ2の握手は、実際にはかなり異なります。もちろん、ステージ2の握手は、そのトラフィックがIKE SAで保護されていると仮定する可能性があるためです。したがって、最初にステージ1、次にステージ2について説明します。
There are a large number of variants of the IKE Stage 1 handshake, necessitated by use of different authentication mechanisms. However, broadly speaking Stage 1 handshakes fall into one of two basic categories: MAIN MODE, which provides identity protection and DoS resistance, and AGGRESSIVE MODE, which does not. We will cover MAIN MODE first.
さまざまな認証メカニズムを使用することで必要とされるIKEステージ1の握手には、多数のバリエーションがあります。ただし、段階的に言えば、ステージ1の握手は2つの基本的なカテゴリのいずれかに分類されます。メインモードは、アイデンティティ保護とDOS抵抗を提供し、積極的なモードではありません。最初にメインモードをカバーします。
Main Mode is a six message (3 round trip) handshake, which offers identity protection and DoS resistance. An overview of the handshake is below.
メインモードは、6つのメッセージ（3ラウンド旅行）の握手で、アイデンティティ保護とDOS抵抗を提供します。握手の概要を以下に示します。
Initiator Responder
--------- ---------
CookieI, Algorithms -> \ Parameter
<- CookieR, Algorithms / Establishment
CookieR,
Nonce, Key Exchange ->
<- Nonce, Key Exchange\ Establish
/ Shared key
E(IKEsa, Auth Data) ->
<- E(IKEsa, Auth data)\ Authenticate
/ Peers
IKE Main Mode handshake (Stage 1)
IKEメインモードハンドシェイク（ステージ1）
In the first round trip, the Initiator offers a set of algorithms and parameters. The Responder picks out the single set that it likes and responds with that set. It also provides CookieR, which will be used to prevent DoS attacks. At this point, there is no secure association but the peers have tentatively agreed upon parameters. These parameters include a Diffie-Hellman (DH) group, which will be used in the second round trip.
最初のラウンド旅行では、イニシエーターは一連のアルゴリズムとパラメーターを提供します。レスポンダーは、そのセットで気に入って応答するシングルセットを選択します。また、DOS攻撃を防ぐために使用される調理器も提供します。この時点で、安全な関連付けはありませんが、ピアはパラメーターについて暫定的に同意しています。これらのパラメーターには、2回目のラウンド旅行で使用されるDiffie-Hellman（DH）グループが含まれます。
In the second round trip, the Initiator sends the key exchange information. This generally consists of the Initiator's Diffie-Hellman public share (Yi). He also supplies CookieR, which was provided by the responder. The Responder replies with his own DH share (Yr). At this point, both Initiator and Responder can compute the shared DH key (ZZ). However, there has been no authentication and, therefore, they don't know with any certainty that the connection hasn't been attacked. Note that as long as the peers generate fresh DH shares for each handshake, PFS will be provided.
2回目のラウンド旅行では、イニシエーターが主要な交換情報を送信します。これは通常、イニシエーターのdiffie-hellman public share（yi）で構成されています。彼はまた、レスポンダーによって提供されたCookierも供給しています。レスポンダーは、彼自身のDHシェア（YR）で返信します。この時点で、イニシエーターとレスポンダーの両方が共有DHキー（ZZ）を計算できます。しかし、認証はなかったため、接続が攻撃されていないことを確実に知りません。ピアが握手ごとに新しいDH株を生成する限り、PFSが提供されることに注意してください。
Before we move on, let's take a look at the cookie exchange. The basic anti-DoS measure used by IKE is to force the peer to demonstrate that it can receive traffic from you. This foils blind attacks like SYN floods [SYNFLOOD] and also makes it somewhat easier to track down attackers. The cookie exchange serves this role in IKE. The Responder can verify that the Initiator supplied a valid CookieR before doing the expensive DH key agreement. This does not totally eliminate DoS attacks, because an attacker who was willing to reveal his location could still consume server resources; but it does protect against a certain class of blind attack.
先に進む前に、Cookie Exchangeを見てみましょう。IKEが使用する基本的なアンチドスメジャーは、ピアにあなたからトラフィックを受け取ることができることを示すように強制することです。これにより、Syn Floods [Synflood]のようなブラインド攻撃が阻止され、攻撃者の追跡がやや簡単になります。Cookie Exchangeは、IKEでこの役割を果たしています。レスポンダーは、高価なDHキー契約を締結する前に、イニシエーターが有効な調理器を提供したことを確認できます。これは、自分の場所を明らかにしようとした攻撃者がサーバーリソースを消費する可能性があるため、DOS攻撃を完全に排除するわけではありません。しかし、それは特定のクラスのブラインド攻撃から保護します。
In the final round trip, the peers establish their identities. Because they share an (unauthenticated) key, they can send their identities encrypted, thus providing identity protection from eavesdroppers. The exact method of proving identity depends on what form of credential is being used (signing key, encryption key, shared secret, etc.), but in general you can think of it as a signature over some subset of the handshake messages. So, each side would supply its certificate and then sign using the key associated with that certificate. If shared keys are used, the authentication data would be a key ID and a MAC. Authentication using public key encryption follows similar principles, but is more complicated. Refer to the IKE document for more details.
最後の往復では、ピアはアイデンティティを確立します。彼らは（無慈悲な）キーを共有しているため、暗号化されたアイデンティティを送信することができ、盗聴者からのアイデンティティ保護を提供します。アイデンティティを証明する正確な方法は、クレデンシャルの形式（キー、暗号化キー、共有秘密など）の形式に依存しますが、一般的に、ハンドシェイクメッセージのサブセット上の署名と考えることができます。そのため、各側は証明書を提供し、その証明書に関連付けられたキーを使用して署名します。共有キーを使用すると、認証データはキーIDとMacになります。公開キーの暗号化を使用した認証は、同様の原則に従いますが、より複雑です。詳細については、IKEドキュメントを参照してください。
At the end of the Main Mode handshake, the peers share:
メインモードの握手の終わりに、ピアは共有します。
(1) A set of algorithms for encryption of further IKE traffic. (2) Traffic encryption and authentication keys. (3) Mutual knowledge of the peer's identity.
(1) さらなるIKEトラフィックの暗号化のためのアルゴリズムのセット。（2）トラフィック暗号化と認証キー。（3）ピアのアイデンティティに関する相互の知識。
Although IKE Main Mode provides the required services, there was concern that the large number of round trips required added, excessive latency. Accordingly, an Aggressive Mode was defined. Aggressive mode packs more data into fewer messages, and thus reduces latency. However, it does not provide identity protection or protection against DoS.
IKE Mainモードは必要なサービスを提供しますが、必要な多数の往復が追加され、過度の遅延が追加されるという懸念がありました。したがって、積極的なモードが定義されました。Aggressive Modeは、より多くのデータをより少ないメッセージにパックするため、遅延が減少します。ただし、DOSに対する身元保護や保護は提供されません。
Initiator Responder
--------- ---------
Algorithms, Nonce,
Key Exchange, ->
<- Algorithms, Nonce,
Key Exchange, Auth Data
Auth Data ->
IKE Aggressive Mode Handshake (Stage 1)
IKEアグレッシブモードハンドシェイク（ステージ1）
After the first round trip, the peers have all the required properties, but the Initiator has not authenticated to the Responder. The third message closes the loop by authenticating the Initiator. Note that since the authentication data is sent in the clear, no identity protection is provided; and because the Responder does the DH key agreement without a round trip to the Initiator, there is no DoS protection
最初のラウンド旅行の後、ピアは必要なすべてのプロパティを持っていますが、イニシエーターはレスポンダーに認証されていません。3番目のメッセージは、イニシエーターを認証することによりループを閉じます。認証データは明確に送信されるため、ID保護は提供されていないことに注意してください。また、レスポンダーはイニシエーターへの往復旅行なしでDHキー契約を締結するため、DOS保護はありません
Stage 1 on its own isn't very useful. The purpose of IKE, after all, is to establish associations to be used to protect other traffic, not merely to establish IKE SAs. Stage 2 (what IKE calls "Quick Mode") is used for this purpose. The basic Stage 2 handshake is shown below.
ステージ1自体はあまり役に立ちません。結局のところ、IKEの目的は、単にIKE SASを確立するためだけでなく、他のトラフィックを保護するために使用される関連付けを確立することです。ステージ2（IKEが「クイックモード」と呼ぶもの）は、この目的に使用されます。基本的なステージ2の握手を以下に示します。
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash ->
<- AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash
Handshake Hash ->
The Basic IKE Quick Mode (Stage 2)
基本的なIKEクイックモード（ステージ2）
As with quick mode, the first two messages establish the algorithms and parameters while the final message is a check over the previous messages. In this case, the parameters also include the transforms to be applied to the traffic (AH or ESP) and the kinds of traffic that are to be protected. Note that there is no key exchange information shown in these messages.
クイックモードと同様に、最初の2つのメッセージはアルゴリズムとパラメーターを確立し、最終メッセージは以前のメッセージに対するチェックです。この場合、パラメーターには、トラフィック（AHまたはESP）に適用される変換と、保護されるトラフィックの種類も含まれます。これらのメッセージに示されている重要な交換情報はないことに注意してください。
In this version of Quick Mode, the peers use the preexisting Stage 1 keying material to derive fresh keying material for traffic protection (with the nonces to ensure freshness). Quick mode also allows for a new Diffie-Hellman handshake for per-traffic key PFS. In that case, the first two messages shown above would also include Key Exchange payloads, as shown below.
このバージョンのクイックモードでは、ピアは既存のステージ1キーイング材料を使用して、交通保護のための新鮮なキーイング素材を導き出します（新鮮さを確保するために非セースを使用します）。また、クイックモードでは、トラフィックごとのキーPFSの新しいdiffie-hellmanの握手も可能になります。その場合、上記の最初の2つのメッセージには、以下に示すように、キーエクスチェンジペイロードも含まれます。
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Key Exchange, ->
Handshake Hash
<- AH/ESP parameters,
Algorithms, Nonce,
Key Exchange,
Handshake Hash
Handshake Hash ->
A Variant of Quick Mode with PFS (Stage 2)
PFSを使用したクイックモードのバリアント（ステージ2）
There are a number of features of IKE that deserve special consideration. They are discussed here.
IKEには、特別な考慮に値する多くの機能があります。ここで説明します。
As mentioned previously, IKE uses cookies as a partial defense against DoS attacks. When the responder receives Main Mode message 3 containing the Key Exchange data and the cookie, it verifies that the cookie is correct. However, this verification must not involve having a list of valid cookies. Otherwise, an attacker could potentially consume arbitrary amounts of memory by repeatedly requesting cookies from a responder. The recommended way to generate a cookie, as suggested by Phil Karn, is to have a single master key and compute a hash of the secret and the initiator's address information. This cookie can be verified by recomputing the cookie value based on information in the third message, and seeing if it matches.
前述のように、IkeはDOS攻撃に対する部分的な防御としてCookieを使用しています。レスポンダーが主要な交換データとCookieを含むメインモードメッセージ3を受信すると、Cookieが正しいことを確認します。ただし、この検証には、有効なCookieのリストが含まれていてはなりません。それ以外の場合、攻撃者は、レスポンダーからCookieを繰り返し要求することにより、任意の量のメモリを潜在的に消費する可能性があります。Phil Karnが示唆しているように、Cookieを生成する推奨される方法は、単一のマスターキーを持ち、秘密のハッシュとイニシエーターのアドレス情報を計算することです。このCookieは、3番目のメッセージの情報に基づいてCookie値を再計算し、それが一致するかどうかを確認することで検証できます。
So far we have been rather vague about what kinds of endpoint identities are used. In principle, there are three ways a peer might be identified: by a shared key, a pre-configured public key, or a certificate.
これまでのところ、私たちはどのような種類のエンドポイントアイデンティティが使用されているかについてかなり曖昧でした。原則として、ピアが特定される3つの方法があります。共有キー、事前に構成された公開鍵、または証明書によって。
In a shared key scheme, the peers share a symmetric key. This key is associated with a key identifier, which is known to both parties. It is assumed that the party verifying that identity also has a table that indicates for which traffic (i.e., what addresses) that identity is allowed to negotiate SAs.
共有キースキームでは、ピアは対称キーを共有します。このキーは、両当事者に知られているキー識別子に関連付けられています。アイデンティティがSASを交渉することを許可されているトラフィック（つまり、どのような対処するか）を示すテーブルもあることを確認する当事者が想定されています。
A pre-configured public key scheme is the same as a shared key scheme except that the verifying party has the authenticating party's public key instead of a shared key.
事前に構成された公開キースキームは、検証党が共有キーではなく認証当事者の公開鍵を持っていることを除いて、共有キースキームと同じです。
In a certificate scheme, the authenticating party presents a certificate containing their public key. It is straightforward to establish that this certificate matches the authentication data provided by the peer. What is less straightforward is to determine whether a given peer is entitled to negotiate for a given class of traffic. In theory, one might be able to determine this from the name in the certificate (e.g., the subject name contains an IP address that matches the ostensible IP address). In practice, this is not clearly specified in IKE and, therefore, is not really interoperable. Currently, it is likely that a configuration table maps certificates to policies, as in the other two authentication schemes.
証明書スキームでは、認証当事者は公開鍵を含む証明書を提示します。この証明書がピアが提供する認証データと一致することを確立するのは簡単です。あまり簡単ではないのは、特定のピアが特定のクラスのトラフィックについて交渉する権利があるかどうかを判断することです。理論的には、証明書の名前からこれを決定できる場合があります（たとえば、件名には、表向きのIPアドレスに一致するIPアドレスが含まれています）。実際には、これはIKEで明確に指定されていないため、実際には相互運用できません。現在、構成テーブルは、他の2つの認証スキームのように、証明書をポリシーにマップする可能性があります。
This document does not define any protocols and therefore has no security issues.
このドキュメントはプロトコルを定義していないため、セキュリティの問題はありません。
A. Appendix: IAB Members at the Time of This Writing
A.付録：この執筆時点でのIABメンバー
Bernard Aboba Harald Alvestrand Rob Austein Leslie Daigle Patrik Falstrom Sally Floyd Jun-ichiro Itojun Hagino Mark Handley Bob Hinden Geoff Huston Eric Rescorla Pete Resnick Jonathan Rosenberg
バーナード・アボバ・ハラルド・アルベストランド・ロブ・オーストイン・レスリー・デイグル・パトリック・ファルトロム・サリー・フロイド・ジュン・チーロ・イトジノ・マーク・ハンドリー・ボブ・ヒンデン・ジェフ・ヒューストン・エリック・レスカルラ・ピート・レストニックジョナサン・ローゼンバーグ
Normative References
引用文献
There are no normative references for this document.
このドキュメントには規範的な参照はありません。
Informative References
参考引用
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent、S。、およびR. Atkinson、「IP認証ヘッダー」、RFC 2402、1998年11月。
[CCID2] Floyd, S. and E. Kohler, "Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control", Work in Progress, October 2003.
[CCID2] Floyd、S。およびE. Kohler、「DCCP混雑コントロールIDのプロファイル：TCP様渋滞制御」、2003年10月の作業。
[CCID3] Floyd, S., Kohler, E., and J. Padhye, "Profile for DCCP Congestion Control ID 3: TFRC Congestion Control", Work in Progress, February 2004.
[CCID3] Floyd、S.、Kohler、E。、およびJ. Padhye、「DCCP輻輳制御IDのプロファイル：TFRC混雑制御」、2004年2月の作業。
[DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", Work in Progress, November 2004.
[DCCP] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram輻輳制御プロトコル（DCCP）」、2004年11月、Work in Progress。
[ECN] Ramakrishnan, K. Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[ECN] Ramakrishnan、K。Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[Kerberos] Kohl、J。and C. Neuman、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol" RFC 2327, April 1998.
[SDP] Handley、M。and V. Jacobson、 "SDP：セッション説明プロトコル" RFC 2327、1998年4月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP)", RFC 3489, March 2003.
[Stun] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「Stun-ユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[SYNFLOOD] CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks <http://www.cert.org/advisories/CA-1996-21.html>, September 19, 1996.
[Synflood] Cert Advisory CA-1996-21 TCP Syn洪水とIPスプーフィング攻撃<http://www.cert.org/advisories/ca-1996-21.html>、1996年9月19日。
[UNSAF] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF] Daigle、L。およびIAB、「ネットワークアドレス変換全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
[WebDav] Goland、Y.、Whitehead、E.、Faizi、A.、Carter、S。、およびD. Jensen、「分散オーサリングのHTTP拡張 - Webdav」、RFC 2518、1999年2月。
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
Eric Rescorla RTFM、Inc。2064 Edgewood Drive Palo Alto、CA 94303
Phone: (650)-320-8549 EMail: ekr@rtfm.com
電話：（650）-320-8549メール：ekr@rtfm.com
Internet Architecture Board IAB
インターネットアーキテクチャボードIAB
EMail: iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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.
この文書は、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エディター機能の資金は現在、インターネット協会によって提供されています。