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).
著作権（C）インターネット協会（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.
概要形態のシステムの簡単な説明 - この負荷を軽減する一つの方法は、モデルとのレビューを提示することです。これは、システムの重要なまたは困難な部分を特定し、レビューのためにそれらに集中するコンテキストにレビューを提供します。モデルが最初に行われている場合は副次的な利点としては、それは前のプロトコルの完了に、詳細なプロトコルの設計と早期審査のための焦点の補助として機能することができます。意図は、モデルのいずれかのプロトコル文書の最初のセクションであるか、またはプロトコルを備えた別の文書であろうということです。
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式 - または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.
前回の原則の逆は、時には詳細が焦点に説明をもたらすのに役立つということです。例与えられたとき、多くの人がより良い仕事します。したがって、それはしばしば抽象的に材料の話をして、フォーカスにそれを持って来るためにある特定の部分の具体的な説明を提供するための良いアプローチです。著者は、通常のパスに焦点を当てるべきです。彼らは重要なポイントを説明するのに役立つところエラーケースとコーナーケースにのみ議論されるべきです。
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つの質問に一致するように三つの部分で構成プレゼンテーションをお勧めします。各部分は、関連する点を説明することを意図して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]はその外部の見かけのIPアドレスが何であるかを決定するためにNATの背後にあるマシンを可能にする一方的な自己アドレス固定（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サーバーを使用して行われます。そのサーバーは、翻訳されたアドレスを決定し、以下に示すように、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.
データグラム輻輳制御プロトコルは、[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レビューチームにあったし、その文書を持つ彼の経験は、このドキュメントのための動機付けの要因の一つでした。レビュー以来、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の開始段階は、以下に示すスリーウェイハンドシェイクを含みます。
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-Responseメッセージでは、サーバーは、接続を受け入れることを望んで、機能の交渉を続けて、クライアントに指示します。 SYNフラッドスタイルDOS攻撃を防ぐために、DCCPは、IKEスタイルのクッキー交換を内蔵しています。サーバーは、ネゴシエーション状態のすべてが含まれているクッキーをクライアントに提供することができます。このクッキーは、このようにサーバが状態を維持するための必要性を取り除く、DCCP-Ackの中で、クライアントによってエコーされなければなりません。
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-応答を認識し、接続のその側面を完了するために、サーバーを可能にするためにクッキーを返します。上記に示したように、このメッセージはまた、特徴交渉メッセージを含むことができます。
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.
機能のネゴシエーションが変更に行われ、オプションを確認しています。 「L」オプションが機能が維持されている特徴位置によって送信され、Lを変更してL、変更Rを確認し、R.を確認し、「R」オプションがで送信されます。そこにすべての4つの特徴交渉オプションがあります。リモート備えています。
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:
変更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 *
変更R（CCID、3 4） - > < - Lを確認し（CCID、4,4 2）*契約CCID /サーバ= 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".
第二の交換では、クライアントは3でサーバ使用CCID 3またはCCID 4のいずれかが、好ましいことを要求します。サーバーは、「4 2」、4を選択し、その優先リストを提供します。
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に設定するサーバ要求（3とが好ましい）、およびクライアントが同意します。
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は交渉輻輳制御政権をご用意しております。添加物の増加、乗算減少（CCID2 [CCID2]）、およびTCPフレンドリーなレート制御（CCID3 [CCID3]）：DCCP文書は、2つの輻輳制御政権を記述する。 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のものと非常に類似しています。送信者は輻輳ウィンドウを維持し、そのウィンドウがいっぱいになるまでパケットを送信します。パケットは、受信機によってACKされています。ドロップされたパケットと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のためTIMEWAIT状態でソケットを保持する必要があります。
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.
サーバは、（サーバ側の状態を最小化する要望に例えば起因）TIMEWAITに残る接続をクローズしたいなくてもよいことに留意されたいです。これを実現するためには、サーバはCloseReqメッセージを送信することにより、クライアントから閉じるを引き出すことができ、したがって、クライアント上TIMEWAIT状態を保ちます。
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]は必要な動作を定義し、読者が意味をうまく聞かせすることを好む、かなり簡潔です。いくつかの状況では、それらの影響を詳細に説明資料は、読者がモデル全体を理解するのに役立ちます。このセクションの残りの部分は、そのような場合について説明します。
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は】COPY方法及びMOVE方法の両方を含みます。 MOVEはDELETE続いコピーとして考えることができるが、COPY + DELETEとMOVEは完全に等価ではありません。
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.
COPY + MOVEの代わりにDELETEの使用は、中間ファイルの作成の問題があります。ユーザーがクォータの境界に近づいている場合を考えてみましょう。それは一時的にクォータを超えるためCOPY + DELETEを禁止する必要があります。しかし、単純な名前の変更は、このような状況で動作するはずです。
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.
第二の問題は、権限あります。 WebDAVのアクセス許可モデルは、サーバーがユーザーにファイルの名前を変更する権限を付与することができますが、新しいものを作成していません。これは、通常のファイルシステムでは珍しいですが、何ものWebDAVでそれを妨げるものはありません。クライアントがCOPY + MOVEを行うためにDELETEを使用する場合、これは明らかに可能ではありません。
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.
最後に、+ DELETE COPYは、MOVEと予想されるのと同じ論理的な結果を生成しません。 COPYは、新しいリソースを作成するので、作成日プロパティとして新規ファイル作成時の使用を許可（必須ではありません）です。これとは対照的に、MOVEへの期待は、名前を変更したファイルは、オリジナルと同じ性質を持っているということです。
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.
ここで説明されているグラフィックスを多用文書の並べ替えを書くときにインターネットドラフトやRFCはASCIIでレンダリング可能であるという要件は重大な障害です。著者はそれがより便利に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.
インターネット鍵交換（IKE）[IKE]はこれまで、IETFによって設計された最も複雑なセキュリティプロトコルの一つです。基本的なIKEコアはかなり簡単なの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]が[IPSEC]セキュリティアソシエーション（SA）を確立するためです。
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | 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エンジンは、一般的に独立したモジュールです。 NOの場合、セキュリティアソシエーションを処理する必要があるパケットのために存在しない（送信または受信のいずれか）のIPsecエンジンに接触IKEエンジンと適切なSAを確立することを要求します。 IKEエンジンの連絡先の適切なピアとSAを確立するためにIKEを使用しています。 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ではありません。最初のメッセージを送信パーティは、イニシエータと呼ばれています。相手がRESPONDERと呼ばれています。 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の設計における主要な関心事の一つは、トラフィックがノードの鍵材料は、後に侵害された場合でも、保護されるということであった問題のセッションが終了していたので、セッション固有の鍵材料が消えていたことを条件とします。このプロパティは、多くの場合、完全転送秘密（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は前の関係の様々な種類のピアの幅広い範囲の間でSAを確立できるようにする必要があるため、IKEは、非常に柔軟なキーイングモデルをサポートしています。ピアは、共有鍵、デジタル署名（典型的には、証明書によってためvouchedキーから）、または暗号化キーを介して認証することができます。
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:
非常に高いレベルでは、IKEハンドシェイクの2種類があります。
(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のためにSAを確立するために、第2のハンドシェイクを行うためにすることを使用することができます。このプロセスは、以下の概略的に示されています。表記E（SA、XXXX）は、トラフィックが所定のSAの下で暗号化されていることを示すために使用されます。
Initiator Responder
--------- ---------
Handshake MSG -> \ Stage 1: <- Handshake MSG \ Establish IKE / SA (IKEsa) [...] /
握手MSG - > \ステージ1：< - ハンドシェイクMSG \確立/ SA（配信）[...] /
\ Stage 2: E(IKEsa, Handshake MSG) -> \ Establish AH/ESP <- E(IKEsa, Handshake MSG) / SA
\ステージ2：E（分布、握手MSG） - > \設立AH / ESP < - E（分布、握手MSG）/ SA
The two kinds of IKE handshake
IKEハンドシェイクの2種類
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の用語は、「相」と「モード」に異なる状況下で参照し、多少混乱します。最大明確にするために、私たちは「ステージ1」と「ステージ2」としてAH / ESPのSAの確立として、IKE SAの確立を参照します。それはステージ1が終了した後に、複数の第2段階のハンドシェイクするためにそこにかなり可能だということに注意してください。これは、異なる暗号化特性を持つ複数のAH / ESP SAを確立するために有用であるかもしれません。
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ハンドシェイクは、もちろん、そのトラフィックはIKE SAで保護されていると想定できるので、ステージ1とステージ2ハンドシェイクは、実際にはかなり異なっています。したがって、我々は、まず、ステージ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段階のハンドシェイクの多数の変異体は、あります。アイデンティティ保護とDoSの抵抗せず、アグレッシブモードを、提供MAIN MODE、：しかし、大まかに言えば、ステージ1のハンドシェイクは、2つの基本的なカテゴリのいずれかに分類されます。私たちは、最初のメインモードをカバーします。
Main Mode is a six message (3 round trip) handshake, which offers identity protection and DoS resistance. An overview of the handshake is below.
メインモードは、ID保護とDoS攻撃耐性を提供しています6つのメッセージ（3往復）握手、です。ハンドシェイクの概要は以下の通りです。
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
（配布、認証データ） - > < - E（分布、認証データ）\認証/ピア
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.
最初のラウンドトリップでは、イニシエータは、アルゴリズムやパラメータのセットを提供しています。 Responderはそれが好きで、そのセットで応答し、単一のセットを選び出します。また、DoS攻撃を防ぐために使用されるCookieRを提供します。この時点では、安全な関連はありませんが、ピアは、暫定的にパラメータに合意しました。これらのパラメータは、第二ラウンドトリップで使用されるディフィー・ヘルマン（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.
第二ラウンドトリップでは、イニシエータは、鍵交換情報を送信します。これは、一般的にイニシエータののDiffie-Hellman公開株（李）から構成されています。彼はまた、応答者によって提供されたCookieRを供給する。 Responderは彼自身の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.
私たちが上に移動する前に、のは、クッキー交換を見てみましょう。 IKEで使用される基本的なアンチのDoS対策は、それはあなたからのトラフィックを受信できることを実証するために、ピアを強制することです。これは、[SYNFLOOD] SYNフラッドのような盲目の攻撃を箔も、攻撃者を追跡することが多少容易になります。クッキー交換はIKEでこの役割を提供しています。レスポンダは、イニシエータが、高価なDH鍵合意を実行する前に、有効なCookieRを供給していることを確認することができます。彼の場所を明らかに喜んでいた攻撃者は、まだサーバーのリソースを消費する可能性があるため、これは完全に、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メインモードは、必要なサービスを提供していますが、必要なラウンドトリップの数が多い、過度の遅延を追加することを懸念がありました。したがって、アグレッシブモードを定義しました。アグレッシブモードでは、より少ないメッセージに、より多くのデータをパックし、したがって、待ち時間を減らします。しかし、それは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のメッセージは、イニシエータを認証することによって、ループを閉じます。認証データは平文で送信されているので、何のアイデンティティ保護が提供されていないことに注意してください。レスポンダがイニシエータへのラウンドトリップなしの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 SAを確立するために使用される関連付けを確立することです。ステージ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攻撃に対する部分的な防御としてクッキーを使用しています。応答者は、鍵交換データとクッキーを含むメインモードメッセージ3を受信すると、クッキーが正しいことを確認します。しかし、この検証は有効なクッキーのリストを持っ関与してはいけません。そうしないと、攻撃者は、潜在的に繰り返し応答からクッキーを要求することにより、メモリの任意の量を消費することができます。フィル・カーンにより示唆されるように、クッキーを生成するために推奨される方法は、単一のマスターキーを持っていると秘密のハッシュとイニシエータのアドレス情報を計算することです。このクッキーは、第3のメッセージ内の情報に基づいてクッキー値を再計算し、それが一致した場合に見て確認することができます。
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.
共有鍵方式では、ピアは、対称鍵を共有します。このキーは、両当事者に知られているキーの識別子に関連付けられています。その身元を確認する党も（すなわち、どのようなアドレス）そのアイデンティティはSAをネゴシエートすることが許可されているトラフィックのために示すテーブルを有しているものとします。
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
バーナードAbobaハラルドAlvestrandロブAusteinとレスリーDaigle氏パトリックFalstromサリーフロイド6月-イチローいとぢゅん萩野マーク・ハンドリーボブHindenとジェフ・ヒューストンエリックレスコラピートレズニックジョナサン・ローゼンバーグ
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]ケント、S.、およびR.アトキンソン、 "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]フロイド、S.、およびE.コーラー、 "DCCP輻輳制御ID 2用のプロフィール：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]フロイド、S.、ケーラー、E.、およびJ. Padhye、 "DCCP輻輳制御ID 3のプロファイル：TFRC輻輳制御"、進歩、2004年2月に働いています。
[DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", Work in Progress, November 2004.
[DCCP]コーラー、E.、ハンドレー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、進歩、2004年11月に働いています。
[ECN] Ramakrishnan, K. Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [ECN]ラマクリシュナン、K.フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPSEC]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[KERBEROS]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年9月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol" RFC 2327, April 1998.
[SDP]ハンドリー、M.および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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 "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勧告CA-1996から1921 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、 "一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）ネットワークアドレス変換アクロス"、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.、ホワイトヘッド、E.、フェッチ、A.、カーター、S.、およびD.ジェンセン、 "分散オーサリングのHTTP拡張 - WEBDAV"、RFC 2518、1999年2月。
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303
Phone: (650)-320-8549 EMail: ekr@rtfm.com
電話：（650）-320-8549 Eメール：ekr@rtfm.com
Internet Architecture Board IAB
インターネットアーキテクチャ委員会IAB
EMail: iab@iab.org
メールアドレス：iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。