Network Working Group E. Rescorla
Request for Comments: 4347 RTFM, Inc.
Category: Standards Track N. Modadugu
Stanford University
April 2006
Datagram Transport Layer Security
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
この文書では、データグラムトランスポート層セキュリティ（DTLS）プロトコルのバージョン1.0を指定します。 DTLSプロトコルは、データグラムプロトコルの通信プライバシーを提供します。プロトコルは、クライアント/サーバアプリケーションは、盗聴、改ざん、またはメッセージ偽造を防ぐために設計された方法で通信することができます。 DTLSプロトコルは、トランスポート層セキュリティ（TLS）プロトコルに基づいており、同等のセキュリティ保証を提供しています。基礎となるトランスポートのデータグラムのセマンティクスは、DTLSプロトコルによって保存されています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Usage Model .....................................................3
3. Overview of DTLS ................................................4
3.1. Loss-Insensitive Messaging .................................4
3.2. Providing Reliability for Handshake ........................4
3.2.1. Packet Loss .........................................5
3.2.2. Reordering ..........................................5
3.2.3. Message Size ........................................5
3.3. Replay Detection ...........................................6
4. Differences from TLS ............................................6
4.1. Record Layer ...............................................6
4.1.1. Transport Layer Mapping .............................7
4.1.1.1. PMTU Discovery .............................8
4.1.2. Record Payload Protection ...........................9
4.1.2.1. MAC ........................................9
4.1.2.2. Null or Standard Stream Cipher .............9
4.1.2.3. Block Cipher ..............................10
4.1.2.4. New Cipher Suites .........................10
4.1.2.5. Anti-replay ...............................10
4.2. The DTLS Handshake Protocol ...............................11
4.2.1. Denial of Service Countermeasures ..................11
4.2.2. Handshake Message Format ...........................13
4.2.3. Message Fragmentation and Reassembly ...............15
4.2.4. Timeout and Retransmission .........................15
4.2.4.1. Timer Values ..............................18
4.2.5. ChangeCipherSpec ...................................19
4.2.6. Finished Messages ..................................19
4.2.7. Alert Messages .....................................19
4.3. Summary of new syntax .....................................19
4.3.1. Record Layer .......................................20
4.3.2. Handshake Protocol .................................20
5. Security Considerations ........................................21
6. Acknowledgements ...............................................22
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel -- typically TCP [TCP]. It therefore cannot be used to secure unreliable datagram traffic.
TLS [TLS]は、ネットワークトラフィックを保護するための最も普及しているプロトコルです。これは、広くWebトラフィックを保護するためや、IMAP [IMAP]とPOP [POP]などの電子メールプロトコルのために使用されています。 TLSの主な利点は、透過的な接続指向のチャネルを提供することです。したがって、アプリケーション層とトランスポート層との間にTLSを挿入することによって、アプリケーションプロトコルを確保することが容易です。通常、TCP [TCP] - しかし、TLSは、信頼性の高いトランスポート・チャネル上で実行する必要があります。したがって、信頼性のないデータグラムトラフィックを保護するために使用することはできません。
However, over the past few years an increasing number of application layer protocols have been designed that use UDP transport. In particular protocols such as the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable). Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. SIP, for instance, uses a subset of S/MIME to secure its traffic. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case of S/MIME), they typically requires a large amount of effort to design -- in contrast to the relatively small amount of effort required to run the protocol over TLS.
しかし、過去数年間にわたり、アプリケーション層プロトコルの増加数は、UDPトランスポートを使用するように設計されています。特に、このようなセッション開始プロトコル（SIP）[SIP]および電子ゲームプロトコルなどのプロトコルは、ますます普及しています。 （SIPの両方のTCPおよびUDP上で実行できることに留意されたいが、UDPが好適である状況が存在すること）。現在、これらのアプリケーションの設計者は不十分な選択肢の数に直面しています。まず、彼らは、IPsec [RFC2401]を使用することができます。しかし、[WHYIPSEC]に詳述さいくつかの理由で、これはいくつかの用途にのみ適しています。第二に、彼らはカスタムアプリケーション層のセキュリティプロトコルを設計することができます。 SIPは、例えば、そのトラフィックを保護するためにS / MIMEのサブセットを使用します。アプリケーション層セキュリティプロトコルは、一般に、優れたセキュリティ特性（S / MIMEの場合には、例えば、エンドツーエンドのセキュリティ）を提供するが、残念ながら、それらは典型的に設計するための努力を大量に必要とする - の比較的少量とは対照的にTLSを超えるプロトコルを実行するのに必要な作業。
In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for datagram semantics automatically prohibits use of TLS. Thus, a datagram-compatible variant of TLS would be very desirable. This memo describes such a protocol: Datagram Transport Layer Security (DTLS). DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse.
多くの場合、クライアント/サーバーアプリケーションを保護するための最も望ましい方法は、TLSを使用することです。しかし、データグラムのセマンティクスのための要件は自動的にTLSの使用を禁止しています。したがって、TLSのデータグラム互換変異体は、非常に望ましいであろう。このメモはそのようなプロトコルについて説明します。データグラムトランスポート層セキュリティ（DTLS）。 DTLSは、意図的に新しいセキュリティ発明を最小限にするために、コードとインフラストラクチャの再利用の量を最大にするために、両方の、可能な限りTLSと同様であるように設計されています。
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119 [REQ].
この文書では、キーワードは "MUST"、 "必須"、 "SHOULD" "MUST NOT"、 "SHOULD NOT"、および[REQ] RFC 2119に記載されるように解釈される "場合があります"。
The DTLS protocol is designed to secure data between communicating applications. It is designed to run in application space, without requiring any kernel modifications.
DTLSプロトコルは、通信アプリケーション間でデータを保護するように設計されています。任意のカーネルの変更を必要とせずに、アプリケーション空間で実行するように設計されています。
Datagram transport does not require or provide reliable or in-order delivery of data. The DTLS protocol preserves this property for payload data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or re-ordered data traffic.
データグラムトランスポートは、データの信頼性や順序どおりの配信を必要とするか、または提供しません。 DTLSプロトコルは、ペイロードデータのために、このプロパティを保持します。転送されるデータの遅延に敏感な性質のために、このようなメディアストリーミング、インターネット電話、および通信のためのオンラインゲームの利用データグラムの輸送などのアプリケーション。 DTLSプロトコルが失われたり、再注文データトラフィックを補償しないので、DTLSプロトコルは、通信を保護するために使用されている場合、このようなアプリケーションの動作は変わりません。
The basic design philosophy of DTLS is to construct "TLS over datagram". The reason that TLS cannot be used directly in datagram environments is simply that packets may be lost or reordered. TLS has no internal facilities to handle this kind of unreliability, and therefore TLS implementations break when rehosted on datagram transport. The purpose of DTLS is to make only the minimal changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. Whenever we need to invent new mechanisms, we attempt to do so in such a way that preserves the style of TLS.
DTLSの基本的な設計思想は、「データグラムを超えるTLS」を構築することです。 TLSは、データグラム環境で直接使用することができないという理由は、パケットが失われたり、並べ替えすることができるということだけです。 TLSは、信頼性の欠如のこの種を扱うためには内部の設備を持っていない、とのデータグラムの輸送にリホストときのでTLSの実装は壊れます。 DTLSの目的は、この問題を解決するために必要なTLSにのみ最小限の変更を行うことです。可能な限り、DTLSは、TLSと同じです。私たちは新しいメカニズムを考案する必要があるたびに、私たちは、TLSのスタイルを維持するような方法でそうしようとします。
Unreliability creates problems for TLS at two levels:
信頼性の欠如は、二つのレベルでTLSのための問題を作成します。
1. TLS's traffic encryption layer does not allow independent decryption of individual records. If record N is not received, then record N+1 cannot be decrypted.
1. TLSのトラフィック暗号化層は、個々のレコードの独立した復号化を許可していません。レコードNが受信されない場合、レコードN + 1を復号することができません。
2. The TLS handshake layer assumes that handshake messages are delivered reliably and breaks if those messages are lost.
2. TLSハンドシェイク層は、それらのメッセージが失われた場合のハンドシェイクメッセージが確実と休憩配信されることを前提としています。
The rest of this section describes the approach that DTLS uses to solve these problems.
このセクションの残りの部分は、DTLSは、これらの問題を解決するために使用する方法が記載されています。
In TLS's traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency:
（TLSレコード層と呼ばれる）TLSのトラフィック暗号化層では、レコードは独立していません。レコード間の依存関係の2種類があります。
1. Cryptographic context (CBC state, stream cipher key stream) is chained between records.
1.暗号コンテキストレコード間連鎖れる（CBC状態は、暗号鍵ストリームをストリーミング）。
2. Anti-replay and message reordering protection are provided by a MAC that includes a sequence number, but the sequence numbers are implicit in the records.
2.アンチリプレイとメッセージの並べ替え保護は、シーケンス番号が含まれているMACが提供するが、シーケンス番号は、レコード内の暗黙的なされています。
The fix for both of these problems is straightforward and well known from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 [TLS11] is already adding explicit CBC state to TLS records. DTLS borrows that mechanism and adds explicit sequence numbers.
レコードを明示的な状態を追加します。これらの問題の両方のための修正は、[ESP] IPsecのESPから簡単で、よく知られています。 TLS 1.1 [TLS11]はすでにTLSレコードへの明示的なCBCの状態を追加しています。 DTLSは、そのメカニズムを借用して、明示的シーケンス番号を追加します。
The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order, and any other order is an error. Clearly, this is incompatible with reordering and message loss. In addition, TLS handshake messages are potentially larger than any given datagram, thus creating the problem of fragmentation. DTLS must provide fixes for both of these problems.
TLSハンドシェイクは、ロックステップ方式の暗号ハンドシェイクです。メッセージが送信され、定義された順序で受信され、そして任意の他の順序がエラーでなければなりません。明らかに、これは、並べ替えやメッセージの損失と互換性がありません。また、TLSハンドシェイクメッセージは、このように断片化の問題を作成し、任意のデータグラムよりも潜在的に大きいです。 DTLSは、これらの問題の両方のためのフィックスを提供しなければなりません。
DTLS uses a simple retransmission timer to handle packet loss. The following figure demonstrates the basic concept, using the first phase of the DTLS handshake:
DTLSは、パケット損失を処理するための簡単な再送タイマーを使用しています。次の図は、DTLSハンドシェイクの最初のフェーズを使用して、基本的な考え方を示しています。
Client Server
------ ------
ClientHello ------>
X<-- HelloVerifyRequest
(lost)
[Timer Expires]
【タイマが終了します】
ClientHello ------>
(retransmit)
Once the client has transmitted the ClientHello message, it expects to see a HelloVerifyRequest from the server. However, if the server's message is lost the client knows that either the ClientHello or the HelloVerifyRequest has been lost and retransmits. When the server receives the retransmission, it knows to retransmit. The server also maintains a retransmission timer and retransmits when that timer expires.
クライアントはClientHelloメッセージを送信した後は、サーバーからHelloVerifyRequestを見ることを期待します。サーバーのメッセージが失われた場合は、クライアントはのClientHelloまたはHelloVerifyRequestいずれかが失われ、再送信されたことを知ります。サーバが再送信を受信すると、再送信することを知っています。また、サーバは、再送タイマーを維持し、そのタイマーが満了したときに再送信します。
Note: timeout and retransmission do not apply to the HelloVerifyRequest, because this requires creating state on the server.
注意：これは、サーバー上の状態を作成する必要があるため、タイムアウトと再送信は、HelloVerifyRequestには適用されません。
In DTLS, each handshake message is assigned a specific sequence number within that handshake. When a peer receives a handshake message, it can quickly determine whether that message is the next message it expects. If it is, then it processes it. If not, it queues it up for future handling once all previous messages have been received.
DTLSでは、各ハンドシェイクメッセージは、ハンドシェーク内の特定のシーケンス番号が割り当てられます。ピアがハンドシェイクメッセージを受信すると、それはすぐにそのメッセージは、それが期待次のメッセージであるか否かを判断することができます。もしそうであれば、それはそれを処理します。そうでない場合には、一度、すべての前のメッセージが受信された将来の取り扱いのためにそれをキューに入れます。
TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented message.
TLSとDTLSは（実際、多くのキロバイト単位で、最大2 ^ 24-1バイトまで理論的には）メッセージが非常に大きくなる可能性がハンドシェイク。フラグメンテーションが所望されていない場合は対照的に、UDPデータグラムは、多くの場合、<1500バイトに制限されています。この制限を補償するために、各DTLSハンドシェイクメッセージは、いくつかのDTLSレコード上に断片化されてもよいです。各DTLSハンドシェイクメッセージは、フラグメントオフセットとフラグメント長さの両方を含みます。したがって、ハンドシェイクメッセージのすべてのバイトの所有における受信者は、元の断片化されていないメッセージを再構成することができます。
DTLS optionally supports record replay detection. The technique used is the same as in IPsec AH/ESP, by maintaining a bitmap window of received records. Records that are too old to fit in the window and records that have previously been received are silently discarded. The replay detection feature is optional, since packet duplication is not always malicious, but can also occur due to routing errors. Applications may conceivably detect duplicate packets and accordingly modify their data transmission strategy.
DTLSは、必要に応じて、レコードリプレイ検出をサポートしています。使用される技術は、受信されたレコードのビットマップ・ウィンドウを維持することにより、IPsecのAH / ESPと同じです。以前に受信されているウィンドウやレコードに収まるように古すぎるレコードは黙って破棄されます。パケットの重複が常に悪意のではなく、また、ルーティングエラーが原因で発生する可能性がありますので、リプレイ検出機能は、オプションです。アプリケーションは、おそらく重複したパケットを検出し、それに応じてデータ伝送戦略を変更することがあります。
As mentioned in Section 3, DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we present it as a series of deltas from TLS 1.1 [TLS11]. Where we do not explicitly call out differences, DTLS is the same as in [TLS11].
第3節で述べたように、DTLSは意図的にTLSと非常によく似ています。そのため、代わりに新しいプロトコルとしてDTLSを提示する、我々は[TLS11] TLS 1.1からデルタのシリーズとしてそれを提示します。私たちは、明示的に違いを呼び出さない場合は、DTLSは[TLS11]と同じです。
The DTLS record layer is extremely similar to that of TLS 1.1. The only change is the inclusion of an explicit sequence number in the record. This sequence number allows the recipient to correctly verify the TLS MAC. The DTLS record format is shown below:
DTLSの記録層は、TLS 1.1のものと非常に類似しています。唯一の変化は、レコード内の明示的なシーケンス番号が含まれていることです。このシーケンス番号は、受信者が正しくTLS MACを確認することができます。 DTLSレコード形式を以下に示します。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
type Equivalent to the type field in a TLS 1.1 record.
TLS 1.1レコード内のタイプフィールドに相当タイプ。
version The version of the protocol being employed. This document describes DTLS Version 1.0, which uses the version { 254, 255 }. The version value of 254.255 is the 1's complement of DTLS Version 1.0. This maximal spacing between TLS and DTLS version numbers ensures that records from the two protocols can be easily distinguished. It should be noted that future on-the-wire version numbers of DTLS are decreasing in value (while the true version number is increasing in value.)
バージョン使用されているプロトコルのバージョン。このドキュメントでは、バージョン{254、255}を使用DTLSバージョン1.0を、記載されています。 254.255のバージョン値は、DTLSバージョン1.0の1の補数です。 TLSとDTLSバージョン番号の間のこの最大の間隔は、2つのプロトコルからのレコードが容易に区別できることを保証します。なお、将来のオンワイヤDTLSのバージョン番号が値が減少している（真のバージョン番号は値が増加されています。）
epoch A counter value that is incremented on every cipher state change.
すべての暗号状態の変化にインクリメントされるカウンタ値をエポック。
sequence_number The sequence number for this record.
このレコードのシーケンス番号をSEQUENCE_NUMBER。
length Identical to the length field in a TLS 1.1 record. As in TLS 1.1, the length should not exceed 2^14.
TLS 1.1レコード内の長さフィールドに同じ長さ。 TLS 1.1のように、長さが2 ^ 14を超えてはなりません。
fragment Identical to the fragment field of a TLS 1.1 record.
TLS 1.1レコードのフラグメントフィールドに同一の断片。
DTLS uses an explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. As with TLS, the sequence number is set to zero after each ChangeCipherSpec message is sent.
DTLSは、明示的なシーケンス番号ではなく、レコードのSEQUENCE_NUMBERフィールドで運ば暗黙の1を、使用しています。各ChangeCipherSpecをメッセージが送信された後、TLSと同様に、シーケンス番号はゼロに設定されています。
If several handshakes are performed in close succession, there might be multiple records on the wire with the same sequence number but from different cipher states. The epoch field allows recipients to distinguish such packets. The epoch number is initially zero and is incremented each time the ChangeCipherSpec messages is sent. In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. In practice, TLS implementations rarely rehandshake and we therefore do not expect this to be a problem.
いくつかの握手が近い連続して行われている場合は、同じシーケンス番号を持つ線ではなく、異なる暗号状態から複数のレコードがある可能性があります。エポックフィールドは、受信者が、そのようなパケットを区別することができます。エポック番号は、最初はゼロであり、ChangeCipherSpecをメッセージが送信されるたびにインクリメントされます。任意の所与の配列/エポックペアが一意であることを確実にするために、実装は、同じエポック値の2倍のTCP最大セグメント寿命内で再利用することを可能にしてはいけません。実際には、TLSの実装はめったに再ハンドシェイクず、それゆえ我々は、これが問題になることを期待しないでください。
Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine the MTU and send records smaller than the MTU. DTLS implementations SHOULD provide a way for applications to determine the value of the PMTU (or, alternately, the maximum application datagram size, which is the PMTU minus the DTLS per-record overhead). If the application attempts to send a record larger than the MTU, the DTLS implementation SHOULD generate an error, thus avoiding sending a packet which will be fragmented.
各DTLSレコードは、単一のデータグラム内に適合しなければなりません。 [MOGUL]をIP断片化を避けるために、DTLS実装はMTUを決定し、MTUより小さいレコードを送信すべきです。 DTLS実装はPMTU（又は、交互に、PMTUマイナスDTLSごとのレコードオーバーヘッド最大アプリケーションデータグラムサイズ）の値を決定するために、アプリケーションのための方法を提供すべきです。アプリケーションがMTUよりも大きいレコードを送信しようとすると、DTLS実装では、このように断片化されたパケットを送信回避、エラーを生成する必要があります。
Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with host/port number.
IPsecのとは異なり、DTLSレコードが任意の関連識別子が含まれていないことに注意してください。アプリケーションは、団体の間で多重化する手配しなければなりません。 UDPでは、これはおそらくホスト/ポート番号で行われます。
Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. The DTLS record framing is sufficient to determine the boundaries. Note, however, that the first byte of the datagram payload must be the beginning of a record. Records may not span datagrams.
複数DTLSレコードが単一のデータグラムに配置することができます。彼らは単に連続してエンコードされます。 DTLSレコードフレーミングは、境界を決定するのに十分です。データグラムのペイロードの最初のバイトは、レコードの先頭でなければならないこと、しかし、注意してください。レコードは、データグラムをまたがることはできません。
Some transports, such as DCCP [DCCP] provide their own sequence numbers. When carried over those transports, both the DTLS and the transport sequence numbers will be present. Although this introduces a small amount of inefficiency, the transport layer and DTLS sequence numbers serve different purposes, and therefore for conceptual simplicity it is superior to use both sequence numbers. In the future, extensions to DTLS may be specified that allow the use of only one set of sequence numbers for deployment in constrained environments.
このようDCCP [DCCP]などの一部のトランスポートは、自分自身のシーケンス番号を提供します。これらのトランスポートを介して搬送される場合、DTLSトランスポートシーケンス番号の両方が存在することになります。これは非効率の少量を導入しているが、トランスポート層及びDTLSシーケンス番号は、異なる目的を果たし、したがって概念簡単にするためには、両方のシーケンス番号を使用するよりも優れています。将来的には、DTLSへの拡張は、制約された環境での展開のためのシーケンス番号の一組のみの使用を許可するように指定することができます。
Some transports, such as DCCP, provide congestion control for traffic carried over them. If the congestion window is sufficiently narrow, DTLS handshake retransmissions may be held rather than transmitted immediately, potentially leading to timeouts and spurious retransmission. When DTLS is used over such transports, care should be taken not to overrun the likely congestion window. In the future, a DTLS-DCCP mapping may be specified to provide optimal behavior for this interaction.
このようDCCPなどの一部のトランスポートは、それらの上に伝送されるトラフィックのための輻輳制御を提供します。輻輳ウィンドウが十分に狭い場合、DTLSハンドシェイクの再送信は、潜在的にタイムアウトとスプリアス再送信につながる、すぐに開催されたのではなく伝送することができます。 DTLSは、このようなトランスポート上で使用する場合は、注意がおそらく輻輳ウィンドウをオーバーランしないように注意してください。将来的には、DTLS-DCCPマッピングは、この相互作用のための最適な動作を提供するために指定することができます。
In general, DTLS's philosophy is to avoid dealing with PMTU issues. The general strategy is to start with a conservative MTU and then update it if events during the handshake or actual application data transport phase require it.
一般的には、DTLSの哲学は、PMTUの問題を扱う避けるためです。一般的な戦略は、保守的なMTUで開始し、その後、ハンドシェイクまたは実際のアプリケーションデータ伝送フェーズ中にイベントがそれを必要とする場合、それを更新することです。
The PMTU SHOULD be initialized from the interface MTU that will be used to send packets. If the DTLS implementation receives an RFC 1191 [RFC1191] ICMP Destination Unreachable message with the "fragmentation needed and DF set" Code (otherwise known as Datagram Too Big), it should decrease its PMTU estimate to that given in the ICMP message. A DTLS implementation SHOULD allow the application to occasionally reset its PMTU estimate. The DTLS implementation SHOULD also allow applications to control the status of the DF bit. These controls allow the application to perform PMTU discovery. RFC 1981 [RFC1981] procedures SHOULD be followed for IPv6.
PMTUは、パケットを送信するために使用されるインターフェイスのMTUから初期化する必要があります。 DTLS実装が「断片化に必要とDFセット」（そうでない場合はデータグラムが大きすぎとして知られている）のコードとRFC 1191 [RFC1191] ICMP宛先到達不能メッセージを受信した場合、それはICMPメッセージで与えられたものにそのPMTU推定値を減少させるはずです。 DTLS実装は、アプリケーションが、時折そのPMTU推定値をリセットできるようにする必要があります。 DTLS実装は、アプリケーションがDFビットの状態を制御できるようにする必要があります。これらのコントロールは、アプリケーションがPMTU検出を行うことを可能にします。 RFC 1981 [RFC1981]の手順は、IPv6のために従わされるべきです。
One special case is the DTLS handshake system. Handshake messages should be set with DF set. Because some firewalls and routers screen out ICMP messages, it is difficult for the handshake layer to distinguish packet loss from an overlarge PMTU estimate. In order to allow connections under these circumstances, DTLS implementations SHOULD back off handshake packet size during the retransmit backoff described in Section 4.2.4. For instance, if a large packet is being sent, after 3 retransmits the handshake layer might choose to fragment the handshake message on retransmission. In general, choice of a conservative initial MTU will avoid this problem.
一つの特別なケースは、DTLSハンドシェーク方式です。ハンドシェイクメッセージは、DFセットで設定する必要があります。一部のファイアウォールやルータがICMPメッセージを選別するので握手層はoverlarge PMTU推定値からのパケット損失を区別することは困難です。このような状況下での接続を可能にするために、DTLS実装は、セクション4.2.4に記載再送バックオフ時のハンドシェイク・パケット・サイズのバックオフすべきです。図3は、ハンドシェイク層が再送にハンドシェイクメッセージを断片化することを選択するかもしれない再送信した後、例えば、大きいパケットが送信されている場合。一般的には、保守的な初期のMTUの選択は、この問題を回避します。
Like TLS, DTLS transmits data as a series of protected records. The rest of this section describes the details of that format.
TLSのように、DTLSは、保護された一連のレコードとしてデータを送信します。このセクションの残りの部分は、そのフォーマットの詳細について説明します。
The DTLS MAC is the same as that of TLS 1.1. However, rather than using TLS's implicit sequence number, the sequence number used to compute the MAC is the 64-bit value formed by concatenating the epoch and the sequence number in the order they appear on the wire. Note that the DTLS epoch + sequence number is the same length as the TLS sequence number.
DTLS MACは、TLS 1.1のものと同じです。しかし、むしろTLSの暗黙のシーケンス番号を使用するよりも、MACを計算するために使用されるシーケンス番号は、それらがワイヤ上に現れるためにエポックとシーケンス番号を連結することによって形成される64ビット値です。 DTLSエポック+シーケンス番号がTLSのシーケンス番号と同じ長さであることに留意されたいです。
TLS MAC calculation is parameterized on the protocol version number, which, in the case of DTLS, is the on-the-wire version, i.e., {254, 255 } for DTLS 1.0.
TLS MAC計算は、DTLSの場合には、オン・ザ・ワイヤバージョン、DTLS 1.0即ち、{254、255}であり、プロトコルのバージョン番号にパラメータ化されます。
Note that one important difference between DTLS and TLS MAC handling is that in TLS MAC errors must result in connection termination. In DTLS, the receiving implementation MAY simply discard the offending record and continue with the connection. This change is possible because DTLS records are not dependent on each other in the way that TLS records are.
DTLSとTLS MAC処理の間に1つの重要な違いは、TLSでMACエラーが接続終了につながるなければならないことであることに注意してください。 DTLSでは、受信実装は、単純に問題のあるレコードを捨てるかもしれとの接続を継続します。 DTLSレコードがTLSレコードがある方法で、お互いに依存しないため、この変更が可能です。
In general, DTLS implementations SHOULD silently discard data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate bad_record_mac alert with level fatal and terminate its connection state.
一般的に、DTLS実装は静かに悪いのMACとデータを破棄すべきです。 DTLS実装は、それが無効なMACでメッセージを受信したアラートを生成することを選択した場合、それは致命的なレベルにbad_record_macアラートを生成し、その接続状態を終了しなければなりません。
The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
DTLS NULL暗号はTLS 1.1 NULL暗号と全く同様に行われます。
The only stream cipher described in TLS 1.1 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
TLS 1.1に記載のみストリーム暗号は、ランダムにアクセスすることができないRC4、です。 RC4は、DTLSを使用してはいけません。
DTLS block cipher encryption and decryption are performed exactly as with TLS 1.1.
DTLSブロック暗号の暗号化と復号化にはTLS 1.1のように正確に実行されます。
Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made.
登録時には、新しいTLS暗号スイートは、彼らがDTLSの使用に適しており、何があれば、適応がなされなければならないかどうかを指定する必要があります。
DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of [RFC 2402].
DTLSレコードは再生保護を提供するために、シーケンス番号が含まれています。シーケンス番号検証は、[RFC 2402]のセクション3.4.3から借用以下スライディングウィンドウプロシージャを使用して行われるべきです。
The receiver packet counter for this session MUST be initialized to zero when the session is established. For each received record, the receiver MUST verify that the record contains a Sequence Number that does not duplicate the Sequence Number of any other record received during the life of this session. This SHOULD be the first check applied to a packet after it has been matched to a session, to speed rejection of duplicate records.
セッションが確立されるとき、このセッションの受信パケットカウンタをゼロに初期化する必要があります。各レコードを受信するために、受信機は、レコードがこのセッションの存続期間中に受けた他のレコードのシーケンス番号を重複しないシーケンス番号が含まれていることを確かめなければなりません。これは、セッションにマッチされた後、最初のチェックは、重複レコードの拒絶反応を高速化するために、パケットに適用されるべきです。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A minimum window size of 32 MUST be supported, but a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does not notify the sender of the window size.)
重複は、受信スライディングウィンドウを使用して拒否されます。 （ウィンドウの実装方法はローカルの問題ですが、次のテキストは、実装が示さなければならない機能について説明します。）32の最小ウィンドウサイズをサポートしなければならないが、64のウィンドウサイズが好まれ、デフォルトとして使用されるべきである（SHOULD） 。別のウィンドウサイズ（最小値よりも大きい）は、受信機によって選択されてもよいです。 （受信ウィンドウサイズの送信者に通知しません。）
The "right" edge of the window represents the highest validated Sequence Number value received on this session. Records that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in Appendix C of [RFC 2401].
ウィンドウの「右」のエッジがこのセッションで受信した最高の検証シーケンス番号値を表しています。ウィンドウの「左」端より低いシーケンス番号を含むレコードは拒否されます。ウィンドウ内に入るパケットは、ウィンドウ内で受信したパケットのリストと照合されます。ビットマスクの使用に基づいて、このチェックを実行するための効率的な手段は、付録Cの[RFC 2401]に記載されています。
If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds.
受信したレコードは、ウィンドウ内に収まると新しいもの、またはパケットは、ウィンドウの右側にある場合、受信機はMACの検証に進む。場合MACの検証に失敗した場合、受信機は無効として受信したレコードを捨てなければなりません。受信ウィンドウは、MAC検証が成功した場合のみ更新されます。
DTLS uses all of the same handshake messages and flows as TLS, with three principal changes:
DTLSは同じハンドシェークメッセージのすべてを使用して、三つの主要変化と、TLSのように流れます。
1. A stateless cookie exchange has been added to prevent denial of service attacks.
1.ステートレスクッキー交換は、サービス拒否攻撃を防ぐために追加されました。
2. Modifications to the handshake header to handle message loss, reordering, and fragmentation.
ハンドシェイクヘッダ2.変更メッセージの損失、並び替え、および断片化を処理します。
With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.1.
これらの例外を除いて、DTLSメッセージ形式、流れ、及びロジックは、TLS 1.1のものと同じです。
Datagram security protocols are extremely susceptible to a variety of denial of service (DoS) attacks. Two attacks are of particular concern:
データグラムのセキュリティプロトコルは、サービス拒否（DoS）攻撃の否定の様々な非常に敏感です。二つの攻撃が特に懸念されています。
1. An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.
1.攻撃者は、サーバが状態を割り当てるために、潜在的に高価な暗号化操作を実行させる、ハンドシェイクの開始要求のシリーズを送信することにより、サーバに過度のリソースを消費することができます。
2. An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim machine, thus flooding it.
2.攻撃者が被害者の偽造ソースとの接続開始メッセージを送信することにより、増幅器としてサーバーを使用することができます。その後、サーバーはこれを洪水、被害者のマシンに（DTLSで、非常に大きくなることがCertificateメッセージ、）その次のメッセージを送信します。
In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris [PHOTURIS] and IKE [IKE]. When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of [PHOTURIS]. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. This mechanism does not provide any defense against DoS attacks mounted from valid IP addresses.
これらの攻撃の両方に対抗するために、DTLSはPhoturis [PHOTURIS]とIKE [IKE]で使用されるステートレスクッキー技術を借用します。クライアントがサーバへのClientHelloメッセージを送信すると、サーバーはHelloVerifyRequestメッセージで応答することができます。このメッセージは、[PHOTURIS]の手法を用いて生成されたステートレスクッキーを含んでいます。クライアントは、追加のCookieとのClientHelloを再送しなければなりません。その後、サーバーはクッキーを検証し、それが有効である場合にのみ、握手して進めます。このメカニズムは、偽装されたIPアドレスを持つDoS攻撃を困難にクッキーを受信できるように、攻撃者/クライアントを強制します。このメカニズムは、有効なIPアドレスから搭載されたDoS攻撃に対する任意の防衛を提供していません。
The exchange is shown below:
交換は以下の通りであります：
Client Server
------ ------
ClientHello ------>
<----- HelloVerifyRequest
(contains cookie)
ClientHello ------>
(with cookie)
[Rest of handshake]
[握手のレスト]
DTLS therefore modifies the ClientHello message to add the cookie value.
DTLSは、したがって、クッキーの値を追加するためにClientHelloメッセージを変更します。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
When sending the first ClientHello, the client does not have a cookie yet; in this case, the Cookie field is left empty (zero length).
最初のClientHelloを送信する場合、クライアントはまだクッキーを持っていません。この場合には、クッキーフィールドは、空（ゼロ長さ）が残されます。
The definition of HelloVerifyRequest is as follows:
次のようにHelloVerifyRequestの定義は次のとおりです。
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3).
HelloVerifyRequestメッセージタイプはhello_verify_requestである（3）。
The server_version field is defined as in TLS.
SERVER_VERSIONフィールドは、TLSのように定義されます。
When responding to a HelloVerifyRequest the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello. The server SHOULD use those values to generate its cookie and verify that they are correct upon cookie receipt. The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. Upon receipt of the ServerHello, the client MUST verify that the server version values match.
HelloVerifyRequestに応答するとき、それは元のClientHelloで行ったように、クライアントは、同じパラメータ値（バージョン、ランダム、SESSION_ID、cipher_suites、圧縮_）を使用する必要があります。サーバーは、そのクッキーを生成し、それらがクッキーの受信時に正しいことを確認するために、これらの値を使用すべきです。サーバはServerHelloメッセージを送信するときに、それが使用することをHelloVerifyRequestで同じバージョン番号を使用しなければなりません。 ServerHelloを受信すると、クライアントは、サーバのバージョン値が一致していることを確かめなければなりません。
The DTLS server SHOULD generate cookies in such a way that they can be verified without retaining any per-client state on the server. One technique is to have a randomly generated secret and generate cookies as: Cookie = HMAC(Secret, Client-IP, Client-Parameters)
DTLSサーバーは、サーバー上で任意のクライアントごとの状態を保持せずに検証することができるようにクッキーを生成する必要があります。 （シークレット、クライアントIP、クライアント・パラメータ）クッキー= HMAC：一つの技術は、ランダムに生成された秘密を持っているとして、クッキーを生成することです
When the second ClientHello is received, the server can verify that the Cookie is valid and that the client can receive packets at the given IP address.
第二のClientHelloを受信した場合、サーバーはクッキーが有効であることを確認することができ、クライアントが指定したIPアドレスのパケットを受信できること。
One potential attack on this scheme is for the attacker to collect a number of cookies from different addresses and then reuse them to attack the server. The server can defend against this attack by changing the Secret value frequently, thus invalidating those cookies. If the server wishes that legitimate clients be able to handshake through the transition (e.g., they received a cookie with Secret 1 and then sent the second ClientHello after the server has changed to Secret 2), the server can have a limited window during which it accepts both secrets. [IKEv2] suggests adding a version number to cookies to detect this case. An alternative approach is simply to try verifying with both secrets.
攻撃者が別のアドレスからのCookieの数を収集し、サーバーを攻撃するためにそれらを再利用するために、このスキームの一つの潜在的な攻撃です。サーバーは、このように、これらのクッキーを無効にする、頻繁に秘密の値を変更することによって、この攻撃を防御することができます。サーバは（例えば、彼らは秘密の1でクッキーを受け取った後、サーバは秘密の2に変更された後、第2のClientHelloを送った）正当なクライアントは、移行を通じてハンドシェイクすることができることを希望する場合、サーバーは、それの間に限定されたウィンドウを持つことができます両方の秘密を受け入れます。 【のIKEv2この場合を検出するためにクッキーにバージョン番号を追加することを示唆しています。別のアプローチは、両方の秘密を検証しようとするだけです。
DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server is being operated in an environment where amplification is not a problem, the server MAY be configured not to perform a cookie exchange. The default SHOULD be that the exchange is performed, however. In addition, the server MAY choose not to do a cookie exchange when a session is resumed. Clients MUST be prepared to do a cookie exchange with every handshake.
新しいハンドシェイクが実行されるたびにDTLSサーバは、クッキー交換を実行する必要があります。サーバは増幅が問題ではありません環境で動作している場合、サーバーはクッキー交換を行わないように構成されるかもしれません。デフォルトでは、しかし、交換が行われていることであるべきです。また、サーバは、セッションが再開されたときにクッキー交換を行うにはないことを選択することができます。クライアントは、すべてのハンドシェークとクッキー交換を行うために準備しなければなりません。
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are not included in the calculation of the verify_data for the Finished message.
HelloVerifyRequestが使用される場合、初期のClientHelloとHelloVerifyRequestが終了メッセージのverify_dataの計算には含まれません。
In order to support message loss, reordering, and fragmentation, DTLS modifies the TLS 1.1 handshake header:
メッセージの損失、並び替え、および断片化をサポートするために、DTLSは、TLSハンドシェイク1.1ヘッダを変更します。
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished:Finished;
} body;
} Handshake;
The first message each side transmits in each handshake always has message_seq = 0. Whenever each new message is generated, the message_seq value is incremented by one. When a message is retransmitted, the same message_seq value is used. For example:
各側は各握手に送信する最初のメッセージは、常にそれぞれの新しいメッセージが生成されるたびに、message_seq値が1だけインクリメントさmessage_seq = 0を有します。メッセージが再送信される場合、同じmessage_seq値が使用されます。例えば：
Client Server
------ ------
ClientHello (seq=0) ------>
X<-- HelloVerifyRequest (seq=0)
(lost)
[Timer Expires]
【タイマが終了します】
ClientHello (seq=0) ------>
(retransmit)
<------ HelloVerifyRequest (seq=0)
ClientHello (seq=1) ------>
(with cookie)
<------ ServerHello (seq=1)
<------ Certificate (seq=2)
<------ ServerHelloDone (seq=3)
[Rest of handshake]
[握手のレスト]
Note, however, that from the perspective of the DTLS record layer, the retransmission is a new record. This record will have a new DTLSPlaintext.sequence_number value.
DTLS記録層の観点から、再送が新しいレコードであること、しかし、注意してください。このレコードは新しいDTLSPlaintext.sequence_number値を持つことになります。
DTLS implementations maintain (at least notionally) a next_receive_seq counter. This counter is initially set to zero. When a message is received, if its sequence number matches next_receive_seq, next_receive_seq is incremented and the message is processed. If the sequence number is less than next_receive_seq, the message MUST be discarded. If the sequence number is greater than next_receive_seq, the implementation SHOULD queue the message but MAY discard it. (This is a simple space/bandwidth tradeoff).
DTLS実装は（少なくとも概念的に）next_receive_seqカウンタを維持します。このカウンタはゼロに初期設定されています。メッセージが受信されると、そのシーケンス番号が一致next_receive_seq、next_receive_seqインクリメントされた場合、メッセージが処理されます。シーケンス番号がnext_receive_seq未満の場合、メッセージは捨てなければなりません。シーケンス番号がnext_receive_seqよりも大きい場合、実装はメッセージをキューすべきであるが、それを捨てるかもしれ。 （これは、単純なスペース/帯域幅のトレードオフです）。
As noted in Section 4.1.1, each DTLS message MUST fit within a single transport layer datagram. However, handshake messages are potentially bigger than the maximum record size. Therefore, DTLS provides a mechanism for fragmenting a handshake message over a number of records.
セクション4.1.1で述べたように、各DTLSメッセージは、単一のトランスポート層データグラム内に収まらなければなりません。しかし、握手メッセージは最大レコード・サイズよりも潜在的に大きなされています。したがって、DTLSは、レコードの数を超えるハンドシェイクメッセージを断片化するための機構を提供します。
When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. These ranges MUST NOT be larger than the maximum handshake fragment size and MUST jointly contain the entire handshake message. The ranges SHOULD NOT overlap. The sender then creates N handshake messages, all with the same message_seq value as the original handshake message. Each new message is labelled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment). The length field in all messages is the same as the length field of the original message. An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.
ハンドシェイクメッセージを送信する場合、送信側は、N個の連続データ範囲のシリーズにメッセージを分割します。これらの範囲は最大ハンドシェーク断片サイズよりも大きくてはならず、共同全体のハンドシェイクメッセージを含まなければなりません。範囲が重複しないようにしてください。送信者は、すべての元のハンドシェークメッセージと同じmessage_seq値と、Nのハンドシェイクメッセージを作成します。それぞれの新しいメッセージはfragment_offset（以前のフラグメントに含まれるバイト数）とfragment_length（この断片の長さ）で標識されます。すべてのメッセージの長さフィールドは、元のメッセージの長さフィールドと同じです。非断片化メッセージはfragment_offset = 0とfragment_length =長さを有する縮退ケースです。
When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message. DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes during path MTU discovery.
DTLS実装がハンドシェイクメッセージフラグメントを受信したとき、それは全体のハンドシェイクメッセージになるまで、それをバッファリングしなければなりません。 DTLS実装は重複断片範囲を扱うことができなければなりません。これは、送信者がパスMTUディスカバリの間に小さなフラグメントサイズでハンドシェイクメッセージを再送することができます。
Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are part of the same flight. Thus, there are two acceptable ways to pack two DTLS messages into the same datagram: in the same record or in separate records.
TLSのように、複数のハンドシェークメッセージが部屋であり、それらが同じ飛行の一部であることという条件で、同じDTLSレコードに置かれてもよいことに留意されたいです。同じレコード内または別のレコード内：このように、同じデータグラムに2つのDTLSメッセージをパックするには、2つの許容可能な方法があります。
DTLS messages are grouped into a series of message flights, according to the diagrams below. Although each flight of messages may consist of a number of messages, they should be viewed as monolithic for the purpose of timeout and retransmission.
DTLSメッセージは、以下の図によれば、メッセージの航空券の系列にグループ化されます。メッセージの各フライトは、メッセージの数からなっていてもよいが、それらは、タイムアウトおよび再送信のためにモノリシックとして見られるべきです。
Client Server
------ ------
ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2
ClientHello --------> Flight 3
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
Figure 1. Message flights for full handshake
完全なハンドシェイクのために、図1のメッセージ便
Client Server
------ ------
ClientHello --------> Flight 1
ServerHello \
[ChangeCipherSpec] Flight 2
<-------- Finished /
[ChangeCipherSpec] \Flight 3
Finished --------> /
Figure 2. Message flights for session-resuming handshake (no cookie exchange)
セッション再開握手図2.メッセージ便（無クッキー交換）
DTLS uses a simple timeout and retransmission scheme with the following state machine. Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
DTLSは、次のステートマシンを持つ単純なタイムアウトと再送方式を使用しています。 DTLSクライアントが最初のメッセージ（のClientHello）を送信するので、彼らは準備中状態で開始します。 DTLSサーバは待ち状態ではなく、空のバッファなし再送信タイマーを開始します。
+-----------+
| PREPARING |
+---> | | <--------------------+
| | | |
| +-----------+ |
| | |
| | |
| | Buffer next flight |
| | |
| \|/ |
| +-----------+ |
| | | |
| | SENDING |<------------------+ |
| | | | | Send
| +-----------+ | | HelloRequest
Receive | | | |
next | | Send flight | | or
flight | +--------+ | |
| | | Set retransmit timer | | Receive
| | \|/ | | HelloRequest
| | +-----------+ | | Send
| | | | | | ClientHello
+--)--| WAITING |-------------------+ |
| | | | Timer expires | |
| | +-----------+ | |
| | | | |
| | | | |
| | +------------------------+ |
| | Read retransmit |
Receive | | |
last | | |
flight | | |
| | |
\|/\|/ |
|
+-----------+ |
| | |
| FINISHED | -------------------------------+
| |
+-----------+
Figure 3. DTLS timeout and retransmission state machine
図3. DTLSタイムアウトと再送ステートマシン
The state machine has three basic states.
ステートマシンは、3つの基本的な状態を持ちます。
In the PREPARING state the implementation does whatever computations are necessary to prepare the next flight of messages. It then buffers them up for transmission (emptying the buffer first) and enters the SENDING state.
準備中状態の実装では、計算は、メッセージの次のフライトを準備するために必要なものは何でもありません。その後、（第一のバッファを空に）送信のためにそれらをバッファと送信状態に入ります。
In the SENDING state, the implementation transmits the buffered flight of messages. Once the messages have been sent, the implementation then enters the FINISHED state if this is the last flight in the handshake. Or, if the implementation expects to receive more messages, it sets a retransmit timer and then enters the WAITING state.
派遣国では、実装は、メッセージのバッファリング飛行を送信します。メッセージが送信されると、これはハンドシェイクの最後のフライトの場合、実装は、FINISHED状態になります。または、実装は複数のメッセージを受信することを期待あれば、それは再送信タイマーを設定し、待ち状態に入ります。
There are three ways to exit the WAITING state:
待ち状態を終了するには、3つの方法があります。
1. The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state.
1.再送信タイマーが満了した：それは、飛行を再送する再送タイマーをリセットし、待ち状態に戻り派遣国へのインプリメンテーションに遷移。
2. The implementation reads a retransmitted flight from the peer: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. The rationale here is that the receipt of a duplicate message is the likely result of timer expiry on the peer and therefore suggests that part of one's previous flight was lost.
、派遣国への実装遷移、それは飛行を再送する再送タイマーをリセットし、待ち状態に戻ります。2.実装は、ピアから再送飛行を読み込みます。ここでの理論的根拠は、重複メッセージの受信がピアのタイマー期限切れの可能性が高い結果であるため、自分の前便の一部が失われたことを示唆しているということです。
3. The implementation receives the next flight of messages: if this is the final flight of messages, the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets.
3.実装では、メッセージの次のフライトを受信します。これは、メッセージの最後の飛行である場合、実装は、完成に移行します。実装は新しいフライトを送信する必要がある場合、それは準備中状態に遷移します。部分的な読み取り（一部のメッセージのみを飛行中のメッセージのいくつかは、かどうか）状態遷移やタイマーのリセットが発生することはありません。
Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
DTLSクライアントが最初のメッセージ（のClientHello）を送信するので、彼らは準備中状態で開始します。 DTLSサーバは待ち状態ではなく、空のバッファなし再送信タイマーを開始します。
When the server desires a rehandshake, it transitions from the FINISHED state to the PREPARING state to transmit the HelloRequest. When the client receives a HelloRequest it transitions from FINISHED to PREPARING to transmit the ClientHello.
サーバが再ハンドシェイクを希望する場合は、HelloRequestを送信するための準備状態に仕上げ状態から遷移します。クライアントがHelloRequestを受信すると、それは、完成からのClientHelloを送信するための準備に移行します。
Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if many instances of a DTLS time out early and retransmit too quickly on a congested link. Implementations SHOULD use an initial timer value of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double the value at each retransmission, up to no less than the RFC 2988 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 2988 default in order to improve latency for time-sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal.
タイマー値は、実装の選択であるが、タイマーの取り扱いを誤ると、深刻な渋滞の問題につながることができます。例えば、初期のDTLSの時間の多くの事例が出ている場合や、混雑リンクをあまりにも早く再送信します。実装は、1秒（RFC 2988で定義された最小の[RFC2988]）の初期タイマ値を使用し、60秒のRFC 2988最大未満ないまで、各再送時の値を倍にすべきです。我々は時間に敏感なアプリケーションのための待ち時間を改善するために、1秒タイマーではなく、3秒RFC 2988のデフォルトを推奨していることに注意してください。 DTLSだけで握手していないデータフローの再送信を使用しているため、混雑への影響は最小限でなければなりません。
Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time the value may be reset to the initial value. After a long period of idleness, no less than 10 times the current timer value, implementations may reset the timer to the initial value. One situation where this might occur is when a rehandshake is used after substantial data transfer.
損失なく伝送が発生するまでの実装は、その時点で値が初期値にリセットすることができ、現在のタイマ値を保持すべきです。怠惰、無未満、10倍現在のタイマ値の長い期間の後、実装が初期値にタイマーをリセットしてもよいです。再ハンドシェイクが実質的なデータ転送後に使用されるとき、これが発生する可能性のある一つの状況があります。
As with TLS, the ChangeCipherSpec message is not technically a handshake message but MUST be treated as part of the same flight as the associated Finished message for the purposes of timeout and retransmission.
TLSと同様に、ChangeCipherSpecをメッセージには、技術的にハンドシェイクメッセージではなく、タイムアウトおよび再送信の目的のために関連したFinishedメッセージと同じフライトの一部として扱われなければなりません。
Finished messages have the same format as in TLS. However, in order to remove sensitivity to fragmentation, the Finished MAC MUST be computed as if each handshake message had been sent as a single fragment. Note that in cases where the cookie exchange is used, the initial ClientHello and HelloVerifyRequest MUST NOT be included in the Finished MAC.
完成したメッセージは、TLSと同じフォーマットを有します。各ハンドシェイクメッセージは、単一の断片として送信されたかのようしかし、断片化に対する感受性を除去するために、完成MACが計算されなければなりません。クッキー交換が使用されている場合には、初期のClientHelloとHelloVerifyRequestが終了MACに含まれてはならないことに注意してください。
Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected.
彼らは握手のコンテキストで発生した場合でも、警告メッセージがすべてで再送信されていないことに注意してください。問題のあるレコードが（例えば、再送されたハンドシェイクメッセージとして）再び受信した場合は、DTLS実装は、新しい警告メッセージを生成する必要があります。実装は、ピアが持続悪いメッセージを送信しているときを検出し、そのような不正行為が検出された後にローカル接続状態を終了すべきです。
This section includes specifications for the data structures that have changed between TLS 1.1 and DTLS.
このセクションでは、TLS 1.1およびDTLSの間で変更されているデータ構造の仕様が含まれています。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSCompressed.length];
} DTLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
select (CipherSpec.cipher_type) {
case block: GenericBlockCipher;
} fragment;
} DTLSCiphertext;
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished:Finished;
} body;
} Handshake;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
This document describes a variant of TLS 1.1 and therefore most of the security considerations are the same as those of TLS 1.1 [TLS11], described in Appendices D, E, and F.
この文書では、TLS 1.1の変形例を説明し、したがって、セキュリティ問題のほとんどは、TLS 1.1 [TLS11]のものと同じである、付録D、E、およびFに記載します
The primary additional security consideration raised by DTLS is that of denial of service. DTLS includes a cookie exchange designed to protect against denial of service. However, implementations which do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers which do not use the cookie exchange may be used as attack amplifiers even if they themselves are not experiencing DoS. Therefore, DTLS servers SHOULD use the cookie exchange unless there is good reason to believe that amplification is not a threat in their environment. Clients MUST be prepared to do a cookie exchange with every handshake.
DTLSが提起した主な追加のセキュリティの考慮事項は、サービス拒否のものです。 DTLSは、サービス拒否から保護するために設計されたクッキーの交換が含まれています。しかし、このクッキー交換を使用していない実装はまだDoS攻撃に対して脆弱です。彼ら自身がDoS攻撃を経験していない場合でも具体的には、クッキー交換を使用していないDTLSサーバは、攻撃アンプとして使用することができます。増幅は、その環境での脅威ではないことを信じる十分な理由がある場合を除きしたがって、DTLSサーバは、クッキー交換を使用すべきです。クライアントは、すべてのハンドシェークとクッキー交換を行うために準備しなければなりません。
The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, Constantine Sapuntzakis, and Hovav Shacham for discussions and comments on the design of DTLS. Thanks to the anonymous NDSS reviewers of our original NDSS paper on DTLS [DTLS] for their comments. Also, thanks to Steve Kent for feedback that helped clarify many points. The section on PMTU was cribbed from the DCCP specification [DCCP]. Pasi Eronen provided a detailed review of this specification. Helpful comments on the document were also received from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison Mankin.
著者は、DTLSの設計に関する議論やコメントのためにダン・ボネ、Euのジンゴー、ラスHousley、コンスタンティンSapuntzakis、およびホバフ・シャチャムに感謝したいと思います。彼らのコメントのためにDTLS [DTLS]に独自のNDSS紙の匿名のNDSSの審査に感謝します。また、多くのポイントを明確に助けたフィードバックのためのスティーブ・ケントに感謝。 PMTUのセクションはDCCP仕様[DCCP]からcribbedました。パシEronenは、本明細書の詳細なレビューを提供します。文書上の参考コメントもマーク・オールマン、ヤリArkko、ジョエル・ハルパーン、テッドハーディー、およびアリソンマンキンから受け取りました。
This document uses the same identifier space as TLS [TLS11], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS.
この文書では、TLS [TLS11]と同じ識別子空間を使用するため、新たなIANAレジストリは必要ありません。新しい識別子がTLS用に割り当てられている場合は、著者は、彼らがDTLSに適しているかどうかを指定しなければなりません。
This document defines a new handshake message, hello_verify_request, whose value has been allocated from the TLS HandshakeType registry defined in [TLS11]. The value "3" has been assigned by the IANA.
この文書では、その値は[TLS11]で定義されたTLS HandshakeTypeレジストリから割り当てられた新しいハンドシェイクメッセージ、hello_verify_requestを、定義します。値「3」は、IANAによって割り当てられています。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981、1996年8月 "IPバージョン6のパスMTUディスカバリー"。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS11]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[AESCACHE]バーンスタイン、D.J.、 "AES上のキャッシュ・タイミング攻撃" http://cr.yp.to/antiforgery/cachetiming-20050414.pdf。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram Congestion Control Protocol", Work in Progress, 10 March 2005.
[DCCP]コーラー、E.、ハンドレー、M.、フロイド、S.、Padhye、J.、 "データグラム輻輳制御プロトコル"、ProgressのWork 2005年3月10日。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
[DTLS] Modadugu、N.、レスコラ、E.、 "データグラムTLSの設計と実装"、ISOC NDSS 2004、2004年2月の議事。
[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月。
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[PHOTURIS]カーン、P.とW.シンプソン、 "ICMPセキュリティの失敗メッセージ"、RFC 2521、1999年3月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, October 2003.
[WHYIPSEC] Bellovin氏、S.、 "IPsecのの使用を義務付けるためのガイドライン"、進歩、2003年10月に作業。
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303
EMail: ekr@rtfm.com
メールアドレス：ekr@rtfm.com
Nagendra Modadugu Computer Science Department Stanford University 353 Serra Mall Stanford, CA 94305
Nagendra Modaduguコンピュータサイエンス学部、スタンフォード大学353セラモールスタンフォード、CA 94305
EMail: nagendra@cs.stanford.edu
メールアドレス：nagendra@cs.stanford.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。