RFC4101 日本語訳
4101 Writing Protocol Models. E. Rescorla, IAB. June 2005. (Format: TXT=47287 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rescorla
Request for Comments: 4101 RTFM, Inc.
Category: Informational IAB
June 2005
コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 4101年のRTFM Inc.カテゴリ: 情報のIAB2005年6月
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)インターネット協会(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ドキュメントは、評論家ではなく、作成者の役に立つように書かれています。 ワイヤにおける州のマシンとビットの完全な記述を提供するために一般に高度の注意を取りますが、特に、このレベルの詳細は、初期の理解の邪魔をする傾向があります。 このドキュメントは評論家がすぐにシステムの本質を理解できるプロトコル「モデル」を提供するためのアプローチについて説明します。
1. Introduction
1. 序論
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.
作成者のためにプロトコルを記録するとき、彼らが、どのような場合でも、プロトコルを理解する必要があるので、これは許容できます。 しかし、それは評論家で緊張を劇的に増強します。 評論家は、特定のポイントに関してシステムの大きい画像を得て、次に、焦点を得る必要があります。 彼らには、作成者がそうする注意を全体のドキュメントに与える時間が絶対にありません。
Rescorla Informational [Page 1] RFC 4101 Writing Protocol Models June 2005
情報[1ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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つの方法はMODELを評論家に与えることです--概要フォームにおける、システムの短い記述。 これは、レビューのためにそれらの上のシステムと焦点の重要であるか難しい断片を特定するために文脈を評論家に提供します。 側が利益を得るとき、最初にモデルをするなら、それは詳細なプロトコルデザインへの援助とプロトコル完成の前の早めのレビューのための焦点としてサーブであるかもしれません。 意志はモデルがプロトコルドキュメントの最初のセクションであるかプロトコルが提供された別々のドキュメントであるだろうということです。
2. The Purpose of a Protocol Model
2. プロトコルモデルの目的
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. 重要、unobviousだけ、プロトコルの特徴は何ですか?
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ベースの認証モデルを使用するという決定はケルベロス[ケルベロス]に関する基本的な特徴です。 対照的に、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.
プロトコルモデルの目的は明らかに議論するプロトコルの完全であるか代替の記述を提供しないことです。 代わりに、それは、読者がすぐにどう働くかに関する必須元素を理解できるように、プロトコルの大きい画像概要を提供することになっています。
3. Basic Principles
3. 基本原理
In this section we discuss basic principles that should guide your presentation.
このセクションで、私たちはあなたのプレゼンテーションを誘導するべきである基本原理について議論します。
3.1. Less is more
3.1. 以下は、より多いです。
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.
人間はすぐに、彼らの頭に非常にわずかな個数の情報を保つことができるだけです。 人々が大きい画像を得るのを確実にしたいと思うので、私たちは多くの詳細を省かなければなりません。 それは悪いのではなく良いです。 より純真なあなたは事態をより良くすることができます。
Rescorla Informational [Page 2] RFC 4101 Writing Protocol Models June 2005
情報[2ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
3.2. Abstraction is good
3.2. 抽象化は良いです。
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.
複合システムを表すための主要なテクニックは遠くの要約に断片を試すことです。 例えば、それらがあなたが興味を持っている情報の抽象的で、様式化された意見を提供するのであなたがどこに行きたいかを見つけるには、地図は写真より良いです。 教育学の目的のためにただ一つの抽象的な断片に複数のプロトコル要素を圧縮するのを恐れないでください。
3.3. A few well-chosen details sometimes help
3.3. いくつかの適切な詳細が時々助けます。
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つのつの具体的な記述を提供するのは、良いアプローチです。 作者は正常な経路に焦点を合わせるべきです。 重要なポイントを例証するのを助けるところで誤り事件と角のケースについて議論するだけであるべきです。
4. Writing Protocol Models
4. プロトコルモデルに書きます。
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 関連ポイントを例証することを意図するダイヤグラムを含むはずです。
4.1. Describe the problem you're trying to solve
4.1. あなたが解決しようとしている問題について説明してください。
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
モデルの「問題」セクションはプロトコルが使用されると予想される環境の短い声明から始まるべきです。 このセクションはそれらがプロトコルに参加する関連実体とありそうなシナリオについて説明するべきです。 Problem部は少佐のダイヤグラムを特徴とするべきです。
Rescorla Informational [Page 3] RFC 4101 Writing Protocol Models June 2005
情報[3ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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.
パーティーと彼らの相互関係を伝えます。 様々なパーティーの間の信頼関係を広げるのは、しばしばこれらがunobviousであるので、特に重要です。
4.1.1. Example: STUN (RFC 3489)
4.1.1. 例: 気絶させてください。(RFC3489)
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アドレスが何であるかを決定できるUNilateral Self-アドレスFixing(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.
ネットワークAddress Translation(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サーバとのセッションを開始しています。 Session記述プロトコル(SDP)[SDP]で、聴いているIPアドレスとポートを提供するよう要求してください。 しかしながら、クライアントに知られずに、NATは邪魔をしています。 NATはヘッダーでIPアドレスを翻訳しますが、SIP意識していない場合、それは要求におけるアドレスを変えません。 結果はメディアがブラックホールに入るということです。
Rescorla Informational [Page 4] RFC 4101 Writing Protocol Models June 2005
情報[4ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
+-----------+
| 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 |
| |
+-----------+
+-----------+ | 一口| | サーバ| | | +-----------+ ^ | [FROM:198.203.2、.1、: 8954]| [エムエスジー: メディアを10.0に送ってください、.10、.5、: 6791]| | +-----------+ | | | NAT| --------------+ ゲートウェイ+---------------- | | +-----------+ ^ | [FROM:10.0.10、.5、: 6791]| [エムエスジー: メディアを10.0に送ってください、.10、.5、: 6791]| 10.0.10.5 +-----------+ | 一口| | クライアント| | | +-----------+
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クライアントに言うことができます、以下に示すように。
Rescorla Informational [Page 5] RFC 4101 Writing Protocol Models June 2005
情報[5ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
+-----------+
| 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 |
| |
+-----------+
+-----------+ | 気絶させてください。| | サーバ| | | +-----------+ ^ | [IP HDR FROM:198.203.2.1:8954]| | [IP HDR TO:198.203.2.1: 8954] [エムエスジー: 私のアドレスは何ですか?] | | [エムエスジー: あなたが198.203である、.2、.1、: 8954]| +に対して-----------+ | | | NAT| --------------+ ゲートウェイ+---------------- | | +-----------+ ^ | [IP HDR FROM:10.0.10.5:6791]| | [IP HDR TO:10.0.10.5: 6791] [エムエスジー: 私のアドレスは何ですか?] | | [エムエスジー: あなたが198.203である、.2、.1、: 8954]| v10.0.10.5+-----------+ | 一口| | クライアント| | | +-----------+
4.2. Describe the protocol in broad overview
4.2. 広い概要におけるプロトコルについて説明してください。
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.
このセクションSHOULD NOTはプロトコルメッセージかそれぞれのデータ要素の詳述を含んでいます。 特定の、そして、噛み付いているダイヤグラム、ASN.1モジュール、およびXML図式SHOULD NOTで、示されてください。 このセクションの目的はプロトコルの完全な記述を提供するのではなく、地図を人が完全なプロトコルドキュメントを読む場合それぞれの特定の断片がどこで合うかを見ることができる十分提供することです。
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.
ある場合には、ネットワーク要素の動きの州のマシン記述を提供するのは役立っているかもしれません。 しかしながら、そのような州のマシンはできるだけ最小量に保たれるべきです。 目的は忘れずに完全な理解ではなく、ハイレベルの読解を促進してくださいことです。
Rescorla Informational [Page 6] RFC 4101 Writing Protocol Models June 2005
情報[6ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
4.2.1. Example: DCCP
4.2.1. 例: DCCP
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.
データグラムCongestion Controlプロトコル[DCCP]は、ネットワークに優しい混雑回避行動をデータグラム輸送に提供するためのプロトコルです。 DCCPベースプロトコルドキュメントは長さ100ページ以上です、そして、混雑制御機構自体は別々です。 したがって、aを持っているのは非常に役立っています。遠くで詳細を抜き取る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のようにstatefulです。 コネクションズは以下のフェーズに直面しています:
1. Initiation
2. Feature negotiation
3. Data transfer
4. Termination
1. 開始2。 交渉3を特徴としてください。 データ転送4。 終了
4.2.1.1. Initiation
4.2.1.1. 開始
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-要求->[ポート、サービス、特徴]<DCCP-応答[特徴、クッキー]DCCP-Ack->。[特徴、クッキー]
DCCP 3-way handshake
DCCP3ウェイ握手
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
DCCP-要求メッセージでは、クライアントはそれが話したがっているサービスとそれが話し合いたがっているポートの名前をサーバに言います。 TCPかUDPの一般的な習慣にはそれらがあって、ポートがしっかりサービスに縛られないことに注意してください。 また、それは特徴交渉を始めます。 教育学の理由で、私たちは特徴交渉を提示するつもりです。
Rescorla Informational [Page 7] RFC 4101 Writing Protocol Models June 2005
情報[7ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
separately in the next section. However, realize that the early phases of feature negotiation happen concurrently with initiation.
別々に、次のセクションで。 しかしながら、特徴交渉の早めのフェーズが同時に開始と共に起こるとわかってください。
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洪水スタイル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-応答を承諾して、サーバが接続の側面を完成することを許可するためにクッキーを返します。 また、上で示されるように、このメッセージは特徴交渉メッセージを含むかもしれません。
4.2.1.2. Feature Negotiation
4.2.1.2. 特徴交渉
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.
ChangeとConfirmオプションで特徴交渉をします。 全部で4つの特徴交渉オプションがあります: 特徴位置でConfirm L、Change R、およびConfirm R.「L」オプションを送ります、そして、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メッセージは同輩に言います。 「私はそれを変えました」と意味して、同輩はConfirm Lと共に応じることができます。 いくつかの特徴で、Change Rオプションは好みの命令で分類された複数の値を含むことができます。 例えば:
Client Server
------ ------
Change R(CCID, 2) -->
<-- Confirm L(CCID, 2)
* agreement that CCID/Server = 2 *
クライアントサーバ------ ------ 変化R(CCID、2)(><)はCCID/サーバが2*と等しいというL(CCID、2)*協定を確認します。
Change R(CCID, 3 4) -->
<-- Confirm L(CCID, 4, 4 2)
* agreement that CCID/Server = 4 *
変化R(CCID、3 4)(><)はCCID/サーバが4*と等しいというL(CCID、4、4 2)*協定を確認します。
Rescorla Informational [Page 8] RFC 4101 Writing Protocol Models June 2005
情報[8ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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番目の交換、サーバが使用するクライアント要求、CCID3かCCID4のどちらか3が都合のよい状態で。 サーバが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.
Change LとConfirm Rオプションは特徴位置によって開始される特徴交渉に使用されます。 以下の例では、サーバは、CCID/サーバが3か2(3が好まれている)に設定されるよう要求します、そして、クライアントは同意します。
Client Server
------ ------
<-- Change L(CCID, 3 2)
Confirm R(CCID, 3, 3 2) -->
* agreement that CCID/Server = 3 *
クライアントサーバ------ ------ <-- 変化L(CCID、3 2)はR(CCID、3、3 2)を確認します-->*、CCID/サーバが3*と等しいという協定
4.2.1.3. Data Transfer
4.2.1.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.
むしろ、DCCPはTCPのようにただ一つの輻輳制御政権を持っているよりさまざまな交渉可能な輻輳制御政権を提供します。 DCCPドキュメントは2つの輻輳制御政権について説明します: 付加的な増加、乗法的な減少(CCID-2[CCID2])、およびTCPに優しいレートは(CCID-3[CCID3])を制御します。 CCID-2は最大のスループットを必要とするアプリケーションのために意図します。 CCID-3は混雑への滑らかな応答を必要とするリアルタイムのアプリケーションのために意図します。
4.2.1.3.1. CCID-2
4.2.1.3.1. CCID-2
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です。下げられたパケットと電子証券取引ネットワーク[電子証券取引ネットワーク]は、混雑を示すのに使用されます。 混雑への応答は混雑ウィンドウを半分にすることです。 DCCPとTCPの1つの微妙な違いはDCCPのAcksが最も高い一連番号だけではなく、すべての容認されたパケット(与えられた窓の中の)の一連番号を含まなければならないということです、TCPのように。
4.2.1.3.2. CCID-3
4.2.1.3.2. CCID-3
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より混雑へのさらに滑らかな応答を提供することを意図する方程式ベースの形式の速度制御です。 送付者は、aが「レートを伝えてください。」であると主張します。 受信機は受信機のパケット損失の見積りの情報を含むパケットをAckに送ります。 送付者がアップデートするこの情報を使用する、それ、レートを伝えてください。 CCID-3はいくらか短期的な混雑応答におけるTCPと異なって振る舞いますが、それは、長期的に見るとTCPと共に公正に作動するように設計されています。
Rescorla Informational [Page 9] RFC 4101 Writing Protocol Models June 2005
情報[9ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
4.2.1.4. Termination
4.2.1.4. 終了
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の接続終了は、Closeメッセージを送ることによって、開始されます。 どちらの側もCloseメッセージを送ることができます。 そして、同輩はResetメッセージで応じます。そのポイントでは、接続は閉じられます。 Closeメッセージを送った側は2MSLのためにTIMEWAIT状態に静かにソケットを保存しなければなりません。
Client Server
------ ------
Close ->
<- Reset
[Remains in TIMEWAIT]
クライアントサーバ------ ------ 近い-><リセット[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メッセージを送ることによってCloseを聞き出して、その結果、クライアントの上にTIMEWAITが状態であることを保つことができます。
4.3. Describe any important protocol features
4.3. あらゆる重要なプロトコル機能について説明してください。
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.
最後のセクション(1つがあれば)はどんな前項から明白でない重要なプロトコル機能に関する説明も含むべきです。 最も良い場合では、プロトコルのすべての重要な特徴がメッセージ流動によって明白でしょう。 しかしながら、これはいつもそうであるというわけではありません。 このセクションは作者がそれらの特徴について説明する機会です。 作者はこのセクションに書く前に、慎重に考えるべきです。 指摘されるどんな重要なポイントもなければ、それらはこのセクションに居住するべきではありません。
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.
このセクションにはある特徴の種類に関する例は: ネットワーク要素が続くことを意図するアルゴリズムのハイレベルのセキュリティ問題、混雑制御情報、および概要。 例えば、ルーティング・プロトコルがありましたら、あなたは、ルータがプロトコルメッセージから適切なルートを決定するのに使用するアルゴリズムの概略を述べるのにこのセクションを使用するかもしれません。
4.3.1. Example: WebDAV COPY and MOVE
4.3.1. 例: WebDAVはコピーして、移行します。
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]はかなり簡潔です、必要な振舞いを定義して、読者に含意を解決させるのを好んで。 いくつかの状況で、それらの含意を詳しく述べる説明資料は、読者が総合的なモデルを理解しているのを助けることができます。 このセクションの残りはそのようなある場合について説明します。
Rescorla Informational [Page 10] RFC 4101 Writing Protocol Models June 2005
情報[10ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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メソッドの両方を含んでいます。 DELETEによって続かれたCOPYとしてMOVEを考えることができますが、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.
MOVEの代用品としてのCOPY+DELETEの使用は中間ファイルの作成のために問題が多いです。 ユーザが割当て限界にアプローチしているケースを考えてください。 一時割当てを超えているでしょう、したがって、COPY+DELETEは禁じられるべきです。 しかしながら、a簡単である、改名、この状況で働くべきです。
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でそれを防ぎません。 クライアントがMOVEをするのにCOPY+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への期待は改名されたファイルにはオリジナルと同じ特性があるということです。
5. Formatting Issues
5. 形式問題
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.
ここで説明されるグラフィックス重いドキュメントの種類を書くとき、インターネット草稿とRFCsがASCIIでレンダリング可能であるという要件は重要な障害です。 作者は、PostscriptかPDFで別々のプロトコルモデルドキュメントをするのが、より便利であることがわかって、記録保管所のバージョンは確かに便利でしょうが、レビュー時に単にそれを利用可能にするかもしれません。
6. A Complete Example: Internet Key Exchange (IKE)
6. 完全な例: インターネット・キー・エクスチェンジ(イケ)
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によって設計された中で最も複雑なセキュリティプロトコルの1つです。 基本的なIKEコアはかなり簡単なディフィー・ヘルマンベースの握手ですが、新しい読者にとって、これは抽象的に理解しているのがしばしば難しい場合があります、プロトコルの詳細は別として。 このセクションの残りはそれらの新しい読者に適任のIKEの概要を提供します。
Rescorla Informational [Page 11] RFC 4101 Writing Protocol Models June 2005
情報[11ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
6.1. Operating Environment
6.1. 操作環境
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].
インターネットの主要なExchange(IKE)[IKE]はインターネットプロトコルのための主要な設立とパラメタ交渉プロトコルです。 プライマリ利用は、IPsec AH[AH]と超能力[超能力]のために、セキュリティ協会(SAs)[IPSEC]を設立するものです。
+--------------------+ +--------------------+ | | | | | +------------+ | | +------------+ | | | Key | | IKE | | Key | | | | Management | <-+-----------------------+-> | Management | | | | Process | | | | Process | | | +------------+ | | +------------+ | | ^ | | ^ | | | | | | | | v | | v | | +------------+ | | +------------+ | | | IPsec | | AH/ESP | | IPsec | | | | Stack | <-+-----------------------+-> | Stack | | | | | | | | | | | +------------+ | | +------------+ | | | | | | | | | | Initiator | | Responder | +--------------------+ +--------------------+
+--------------------+ +--------------------+ | | | | | +------------+ | | +------------+ | | | キー| | イケ| | キー| | | | 管理| <。+-----------------------+->。| 管理| | | | プロセス| | | | プロセス| | | +------------+ | | +------------+ | | ^ | | ^ | | | | | | | | v| | v| | +------------+ | | +------------+ | | | IPsec| | ああ、/、超能力| | IPsec| | | | スタック| <。+-----------------------+->。| スタック| | | | | | | | | | | +------------+ | | +------------+ | | | | | | | | | | 創始者| | 応答者| +--------------------+ +--------------------+
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エンジンは、適切な同輩に連絡して、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トラフィックを使用できます、アルゴリズムなどのように。
6.1.1. Initiator and Responder
6.1.1. 創始者と応答者
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はそれほど対称ではありません。 最初のメッセージを送るパーティーはINITIATORと呼ばれます。 相手はRESPONDERと呼ばれます。 TCP接続の場合では、INITIATORはアクティブな戸外(すなわち、クライアント)をしている通常同輩になるでしょう。
Rescorla Informational [Page 12] RFC 4101 Writing Protocol Models June 2005
情報[12ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
6.1.2. Perfect Forward Secrecy
6.1.2. 完全な前進の秘密保持
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)か逆トラフィック保護と呼ばれます。
6.1.3. Denial of Service Resistance
6.1.3. サービス妨害抵抗
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はこの危険を最小にするように設計された対策を含んでいます。
6.1.4. Keying Assumptions
6.1.4. 仮定を合わせます。
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.
Security Associationsが本質的には左右対称であるので、一般に、両側を認証しなければなりません。 IKEが、様々な種類の先の関係で広範囲な同輩の間のSAsを設立できる必要があるので、IKEは非常にフレキシブルな合わせているモデルをサポートします。 同輩は共有にされるを通してキー、デジタル署名(通常証明書によって保証されたキーからの)、または暗号化キーを認証できます。
6.1.5. Identity Protection
6.1.5. アイデンティティ保護
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人の同輩からの彼らのアイデンティティが、作者が以前認証するのを必要とすることができるべきである獣皮に特に、できるべきである、彼ら、自己アイデンティティ。 この場合、デザイナーは、最初に話すパーティー(INITIATOR)に1番目を特定させるのを選びました。
Rescorla Informational [Page 13] RFC 4101 Writing Protocol Models June 2005
情報[13ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
6.2. Protocol Overview
6.2. プロトコル概要
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か超能力セキュリティ協会を設立するもの。
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.
以前一度も交信したことがない2人の同輩が、AH/ESH SAを設立する必要があると、彼らは最初に、IKE SAを設立しなければなりません。 これで、彼らは任意の量の保護されたIKEトラフィックを交換できます。 そして、彼らは、AHと超能力のためにSAsを証明するために2番目の握手をするのにそのSAを使用できます。 このプロセスは以下の概要のフォームで見せられます。 記法E(SA、XXXX)は、トラフィックが与えられたSAの下で暗号化されるのを示すのに使用されます。
Initiator Responder --------- ---------
創始者応答者--------- ---------
Handshake MSG -> \ Stage 1:
<- Handshake MSG \ Establish IKE
/ SA (IKEsa)
[...] /
握手MSG->\は1を上演します: <。 握手MSG\はIKE / SA(IKEsa)[…]を設立します。 /
\ Stage 2:
E(IKEsa, Handshake MSG) -> \ Establish AH/ESP
<- E(IKEsa, Handshake MSG) / SA
\は2を上演します: E(IKEsa、握手MSG)->\はああ、/超能力<E(IKEsa、握手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の特権階級について言及するために望んでいる最大限度の明快、「「2インチを上演してください。」としてああ、/超能力SAsの1インチと特権階級を上演してください。 1Stageの2つのの握手であることがそこにおいてかなり立てられることに注意してください、Stage1がいったん終わると。 これは異なった暗号の特性がある複数のAH/超能力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.
Stage1とStage2つの握手が実際にかなり異なっています、Stage2握手が、もちろんトラフィックがIKE SAと共に保護されていると仮定できるので。 それに従って、私たちは、最初に、Stage1について議論して、次に、Stage2について議論するつもりです。
Rescorla Informational [Page 14] RFC 4101 Writing Protocol Models June 2005
情報[14ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
6.2.1. Stage 1
6.2.1. ステージ1
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 Stage1握手の多くの異形があります。しかしながら、概してStage1握手は2つの基本的なカテゴリの1つになります: (そのAGGRESSIVE MODEはそうしません)。(MAIN MODEはアイデンティティ保護とDoS抵抗を提供します)。MAIN MODEとAGGRESSIVE MODE。 私たちは最初に、MAIN MODEをカバーするつもりです。
6.2.1.1. Main Mode
6.2.1.1. 主なモード
Main Mode is a six message (3 round trip) handshake, which offers identity protection and DoS resistance. An overview of the handshake is below.
主なModeは6メッセージ(3周遊旅行)握手です。(その握手はアイデンティティ保護とDoS抵抗を示します)。 握手の概要が以下にあります。
Initiator Responder
--------- ---------
CookieI, Algorithms -> \ Parameter
<- CookieR, Algorithms / Establishment
創始者応答者--------- --------- CookieI、アルゴリズム->\パラメタ<CookieR、アルゴリズム/設立
CookieR,
Nonce, Key Exchange ->
<- Nonce, Key Exchange\ Establish
/ Shared key
Key Exchange-><CookieR、Nonce、一回だけ、Key Exchange\Establish/はキーを共有しました。
E(IKEsa, Auth Data) ->
<- E(IKEsa, Auth data)\ Authenticate
/ Peers
E(IKEsa、Auth Data)-><E(IKEsa、Authデータ)\Authenticate/同輩
IKE Main Mode handshake (Stage 1)
IKE Main Mode握手(ステージ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.
最初の周遊旅行では、Initiatorは1セットのアルゴリズムとパラメタを提供します。 Responderはそれがそのセットで好きであり、反応させるただ一つのセットを選びます。 また、それはCookieRを提供します。(CookieRは、DoS攻撃を防ぐのに使用されるでしょう)。 ここに、どんな安全な協会もありませんが、同輩は試験的にパラメタに同意しました。 これらのパラメタはディフィー-ヘルマン(DH)グループを含んでいます。(それは、2番目の周遊旅行に使用されるでしょう)。
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番目の周遊旅行では、Initiatorは主要な交換情報を送ります。 一般に、これはヘルマン公衆が共有するInitiatorのディフィー(イー)から成ります。 また、彼はCookieRを供給します。(CookieRは応答者によって提供されました)。 Responderは彼自身のDHシェア(年)で返答します。 ここに、InitiatorとResponderの両方が共有されたDHキー(ZZ)を計算できます。 しかしながら、認証が全くありませんでした、そして、したがって、彼らは接続が攻撃されていないというどんな確実性でも知りません。 同輩が各握手のために新鮮なDHシェアを生成する限り、PFSが提供されることに注意してください。
Rescorla Informational [Page 15] RFC 4101 Writing Protocol Models June 2005
情報[15ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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測定は同輩にあなたからトラフィックを受けることができるのを示させることです。 これで、SYNが[SYNFLOOD]をあふれさせるように盲目の攻撃をくじいて、また、攻撃者を捜し出すのはいくらか簡単になります。 クッキー交換はIKEにおけるこの役割を受けます。 Responderは、高価なDH主要な協定をする前にInitiatorが有効な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:
Main Mode握手の終わりに、同輩は共有します:
(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トラフィックの暗号化のための1セットのアルゴリズム。 (2) トラフィック暗号化と認証キー。 (3) 同輩のアイデンティティに関する互いの知識。
6.2.1.2. Aggressive Mode
6.2.1.2. 攻撃的なモード
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 Modeは必要なサービスを提供しますが、多くの周遊旅行が加えられて、過度の潜在を必要としたという関心がありました。 それに従って、Aggressive Modeは定義されました。 攻撃的なモードは、より多くのデータにより少ないメッセージに詰め込んで、その結果、レイテンシを減少させます。 しかしながら、それはDoSに対するアイデンティティ保護か保護を提供しません。
Initiator Responder
--------- ---------
Algorithms, Nonce,
Key Exchange, ->
<- Algorithms, Nonce,
Key Exchange, Auth Data
Auth Data ->
創始者応答者--------- --------- アルゴリズム、一回だけの、そして、主要な交換、-><アルゴリズム、一回だけの、そして、主要な交換、AuthデータAuthデータ->。
IKE Aggressive Mode Handshake (Stage 1)
IKEの攻撃的なモード握手(ステージ1)
Rescorla Informational [Page 16] RFC 4101 Writing Protocol Models June 2005
情報[16ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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
同輩は、最初の周遊旅行の後に、すべての必要な特性を持っていて、Initiatorを持っています。認証されないで、Responderに持っています。 3番目のメッセージは、Initiatorを認証することによって、輪を閉じます。 アイデンティティ保護が全く明確で認証データを送るので提供されないことに注意してください。 そして、Responderが周遊旅行なしでDHの主要な協定をInitiatorにするので、DoS保護が全くありません。
6.2.2. Stage 2
6.2.2. ステージ2
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が「迅速なモード」と呼ぶもの)はこのために使用されます。 基本的なStage2握手は以下に示されます。
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash ->
<- AH/ESP parameters,
Algorithms, Nonce,
Handshake Hash
Handshake Hash ->
創始者応答者--------- --------- Handshake Hash-><AH/超能力パラメタ、Algorithms、Nonce、AH/超能力パラメタ、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か超能力)と保護されることになっているトラフィックの種類に適用されるために変換を含んでいます。 これらのメッセージに示されたどんな主要な交換情報もないことに注意してください。
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.
クィックModeのこのバージョンでは、同輩はトラフィック保護(新しさを確実にする一回だけがある)に材料を合わせながら新たに誘導する材料を合わせる先在のStage1を使用します。 また、迅速なモードは1トラフィックあたりの主要なPFSに関して新しいディフィー-ヘルマンの握手を考慮します。 また、その場合、上に示された最初の2つのメッセージが以下に示されるようにKey Exchangeペイロードを含んでいるでしょう。
Rescorla Informational [Page 17] RFC 4101 Writing Protocol Models June 2005
情報[17ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
Initiator Responder
--------- ---------
AH/ESP parameters,
Algorithms, Nonce,
Key Exchange, ->
Handshake Hash
<- AH/ESP parameters,
Algorithms, Nonce,
Key Exchange,
Handshake Hash
Handshake Hash ->
創始者応答者--------- --------- ->Handshake Hash<AH/超能力パラメタ、Algorithms、Nonce、Key Exchange、AH/超能力パラメタ、Algorithms、Nonce、Key Exchange、Handshake Hash Handshake Hash->。
A Variant of Quick Mode with PFS (Stage 2)
PFSがある迅速なモードの異形(ステージ2)
6.3. Other Considerations
6.3. 他の問題
There are a number of features of IKE that deserve special consideration. They are discussed here.
特別の配慮に値するIKEの多くの特徴があります。 ここでそれらについて議論します。
6.3.1. Cookie Generation
6.3.1. クッキー世代
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.
既述のとおり、DoSに対する部分的なディフェンスが攻撃されるとき、IKEはクッキーを使用します。 応答者がKey Exchangeデータとクッキーを含むMain Modeメッセージ3を受け取るとき、それは、クッキーが正しいことを確かめます。 しかしながら、この検証は、有効なクッキーのリストを持っていることを伴ってはいけません。 さもなければ、攻撃者は、応答者からクッキーを繰り返して要求することによって、潜在的に任意の量のメモリを消費できるでしょう。 フィルKarnによって勧められるようにクッキーを生成するお勧めの方法は、単一のマスターキーを持って、秘密と創始者のアドレス情報のハッシュを計算することです。 3番目のメッセージの情報に基づくクッキー値を再計算して、それが合っているかどうかわかることによって、このクッキーについて確かめることができます。
6.3.2. Endpoint Identities
6.3.2. 終点のアイデンティティ
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つの方法があります: 共有されたキー、あらかじめ設定された公開鍵、または証明書で。
6.3.2.1. Shared Key
6.3.2.1. 共有されたキー
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を交渉できると思われます。
Rescorla Informational [Page 18] RFC 4101 Writing Protocol Models June 2005
情報[18ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
6.3.2.2. Pre-Configured Public Key
6.3.2.2. あらかじめ設定された公開鍵
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.
検証パーティーには共有されたキーの代わりに認証パーティーの公開鍵があるのを除いて、あらかじめ設定された公開鍵体系が共有された主要な体系と同じです。
6.3.2.3. Certificate
6.3.2.3. 証明書
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.
証明書体系では、認証パーティーはそれらの公開鍵を含む証明書を提示します。 この証明書が同輩によって提供された認証データに合っていると証明するのは簡単です。 それほど簡単でないことは、与えられた同輩が与えられたクラスのトラフィックを交渉する権利を与えられるかどうか決定することになっています。 理論上、1つは証明書の名前からこれを決定できるかもしれません(例えば、対象の名前は表向きのIPアドレスに合っているIPアドレスを含んでいます)。 実際には、これは、IKEで明確に指定されないで、またしたがって、本当に共同利用できません。 現在、構成テーブルは他の2つの認証体系のように証明書を方針に写像しそうです。
7. Security Considerations
7. セキュリティ問題
This document does not define any protocols and therefore has no security issues.
このドキュメントは、どんなプロトコルも定義しないで、またしたがって、安全保障問題を全く持っていません。
Rescorla Informational [Page 19] RFC 4101 Writing Protocol Models June 2005
情報[19ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
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 Sallyフロイド・6月-ichiro Itojun Haginoマークハンドレー・ボブ・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.
[ああ] ケント、S.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、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輻輳制御ID2のために以下の輪郭を描きます」。 「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輻輳制御ID3のために以下の輪郭を描きます」。 「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.
[電子証券取引ネットワーク]Ramakrishnan、K.フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Rescorla Informational [Page 20] RFC 4101 Writing Protocol Models June 2005
情報[20ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPSEC] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[KERBEROS] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[ケルベロス] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol" RFC 2327, April 1998.
[SDP] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 1998年4月の「セッション記述プロトコル」RFC2327。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)",
RFC 3489, March 2003.
[気絶させます] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、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勧告カリフォルニア-1996-21TCP SYN氾濫と攻撃が<カリフォルニアhttp://www.cert.org/状況報告/1996-21.html>であると偽造するIP、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問題」、RFC3424、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.、Faizi、A.、カーター、S.、およびD.ジェンセン、「分配されたオーサリングのためのHTTP拡大--、WEBDAV、」、RFC2518(1999年2月)
Authors' Addresses
作者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
エリックレスコラRTFM Inc.2064Edgewood Driveパロアルト、カリフォルニア 94303
Phone: (650)-320-8549 EMail: ekr@rtfm.com
以下に電話をしてください。 (650)-320-8549 メールしてください: ekr@rtfm.com
Internet Architecture Board IAB
インターネット・アーキテクチャ委員会IAB
EMail: iab@iab.org
メール: iab@iab.org
Rescorla Informational [Page 21] RFC 4101 Writing Protocol Models June 2005
情報[21ページ]のRFC4101が2005年6月にモデル化するとプロトコルに書くレスコラ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rescorla Informational [Page 22]
レスコラInformationalです。[22ページ]
一覧
スポンサーリンク
