[要約] RFC 4347は、Datagram Transport Layer Security（DTLS）プロトコルの仕様を定義しています。DTLSは、データグラムベースの通信にセキュリティ機能を提供するために設計されており、主な目的はデータの機密性と完全性を保証することです。
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).
Copyright（c）The Internet Society（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を挿入することにより、アプリケーションプロトコルを保護するのは簡単です。ただし、TLSは信頼できる輸送チャネル（通常はTCP [TCP]）を介して実行する必要があります。したがって、信頼できないデータグラムトラフィックを保護するために使用することはできません。
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のデータグラム互換のバリアントは非常に望ましいでしょう。このメモは、このようなプロトコル：Datagram Transport Layer Security（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].
このドキュメントでは、キーワードは「必須」、「必要はない」、「必須」、「「必要」」、「そうでない」、および「可能な」、および「req]で説明されているように解釈されることがあります。
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プロトコルを使用して通信を保護するために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:
信頼性は、2つのレベルで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.
これらの両方の問題の修正は簡単であり、IPSEC ESP [ESP]からよく知られています。記録に明示的な状態を追加します。TLS 1.1 [TLS11]は、すでに明示的なCBC状態をTLSレコードに追加しています。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ハンドシェイクメッセージは、特定のデータグラムよりも潜在的に大きいため、断片化の問題が生じます。DTLは、これらの両方の問題の修正を提供する必要があります。
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)
x <-ElloverifeRequest（紛失）
[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メッセージを送信すると、サーバーからHelloverifeRequestが表示されることが期待されます。ただし、サーバーのメッセージが失われた場合、クライアントはClientHelloまたはHelloverifeRequestが失われ、再送信されたことをクライアントが知っています。サーバーが再送信を受信すると、再送信がわかります。サーバーはまた、そのタイマーが期限切れになったときに再送信タイマーと再送信を維持します。
Note: timeout and retransmission do not apply to the HelloVerifyRequest, because this requires creating state on the server.
注：タイムアウトと再送信は、サーバー上に状態を作成する必要があるため、HelloverifeRequestには適用されません。
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と非常によく似ています。したがって、DTLを新しいプロトコルとして提示する代わりに、TLS 1.1 [TLS11]の一連のデルタとして提示します。違いを明示的に呼び出さない場合、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つのプロトコルからのレコードが簡単に区別できることが保証されます。DTLの将来のワイヤバージョン数の値は価値が減少していることに注意する必要があります（一方、真のバージョン数の値は増加しています）。
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は、レコードのシーケンス_Numberフィールドで運ばれる暗黙のシーケンス番号ではなく、明示的なシーケンス番号を使用します。TLSと同様に、各ChangeciphersPecメッセージが送信された後、シーケンス番号はゼロに設定されます。
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メッセージが送信されるたびに増加します。特定のシーケンス/エポックペアが一意であることを確認するために、実装は、TCP最大セグメント寿命の2倍以内に同じエポック値を再利用できるようにする必要があります。実際には、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レコードは、単一のデータグラム内に適合する必要があります。IP断片化[Mogul]を回避するために、DTLSの実装はMTUを決定し、MTUよりも小さいレコードを送信する必要があります。DTLS実装では、アプリケーションがPMTUの値を決定する方法を提供する必要があります（または、代わりに、PMTUからDTLを差し引いた最大アプリケーションデータグラムサイズ）。アプリケーションが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]などの一部のトランスポートは、独自のシーケンス番号を提供します。これらの輸送機関を持ち越すと、DTLと輸送シーケンス番号の両方が存在します。これは少量の非効率性を導入しますが、輸送層とDTLSシーケンス数は異なる目的を果たすため、概念的なシンプルさのために、両方のシーケンス番号を使用するよりも優れています。将来的には、制約された環境での展開に1つのセットのシーケンス番号のみを使用できるように、DTLへの拡張を指定することができます。
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ハンドシェイクの再送信はすぐに送信されるのではなく、保持される可能性があり、タイムアウトや偽りの再送信につながる可能性があります。このような輸送でDTLが使用される場合、輻輳ウィンドウをオーバーランしないように注意する必要があります。将来的には、この相互作用に最適な動作を提供するために、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の実装がRFC 1191 [RFC1191] ICMP宛先の到達不可能なメッセージを「必要なフラグメンテーションとDFセット」コード（別名データグラムと呼ばれる）を受信した場合、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.
特別なケースの1つは、DTLSハンドシェイクシステムです。握手メッセージは、DFセットで設定する必要があります。一部のファイアウォールとルーターはICMPメッセージをスクリーニングしているため、ハンドシェイクレイヤーがパケットの損失を重複する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のMACと同じです。ただし、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暗号スイートは、それらがDTLの使用に適しているかどうか、および適応が行われなければならないものを示す必要があります。
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のウィンドウサイズが優先され、デフォルトとして使用する必要があります。。別のウィンドウサイズ（最小よりも大きい）は、受信機によって選択される場合があります。（レシーバーは、送信者にウィンドウサイズを通知しません。）
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].
ウィンドウの「右」のエッジは、このセッションで受信した最高の検証されたシーケンス数値を表します。ウィンドウの「左」の端よりも低いシーケンス番号を含むレコードは拒否されます。ウィンドウ内にあるパケットは、ウィンドウ内の受信したパケットのリストに対してチェックされます。ビットマスクの使用に基づいて、このチェックを実行するための効率的な手段は、[RFC 2401]の付録Cに記載されています。
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と同じ握手メッセージとフローをすべて使用し、3つの主要な変更を加えます。
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. メッセージの損失、並べ替え、断片化を処理するための握手ヘッダーの変更。
3. Retransmission timers to handle message loss.
3. メッセージの損失を処理するための再送信タイマー。
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）攻撃の影響を非常に受けやすいです。2つの攻撃は特に懸念されます。
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、証明書メッセージ、非常に大きくなる可能性がある）を被害者マシンに送信し、浸水させます。
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メッセージをサーバーに送信すると、サーバーはHelloverifeRequestメッセージで応答する場合があります。このメッセージには、[Phyuris]の手法を使用して生成されたステートレスCookieが含まれています。クライアントは、Cookieを追加した状態でClientHelloを再送信する必要があります。次に、サーバーはCookieを検証し、有効な場合にのみ、ハンドシェイクで進行します。このメカニズムにより、攻撃者/クライアントはCookieを受け取ることができます。このメカニズムは、有効な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メッセージを変更してCookie値を追加します。
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を送信するとき、クライアントはまだCookieを持っていません。この場合、Cookieフィールドは空のままです（長さはゼロ）。
The definition of HelloVerifyRequest is as follows:
HelloverifeRequestの定義は次のとおりです。
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.
HelloverifeRequestに応答する場合、クライアントは同じパラメーター値（バージョン、ランダム、session_id、cipher_suites、compression_method）を使用する必要があります。サーバーは、それらの値を使用してCookieを生成し、Cookieの領収書時に正しいことを確認する必要があります。サーバーは、ServerHelloを送信するときに使用するHelloverifeRequestで同じバージョン番号を使用する必要があります。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サーバーは、サーバー上のクライアント状態を保持せずに検証できるようにCookieを生成する必要があります。1つの手法は、ランダムに生成された秘密を持ち、Cookie = HMAC（Secret、Client-IP、Client-Parameters）としてCookieを生成することです。
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.
2番目のClientHelloを受信すると、サーバーはCookieが有効であること、およびクライアントが指定された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.
このスキームに対する潜在的な攻撃の1つは、攻撃者がさまざまなアドレスから多くのCookieを収集し、それらを再利用してサーバーを攻撃することです。サーバーは、秘密の値を頻繁に変更することにより、この攻撃に対して防御することができ、それらのCookieを無効にすることができます。サーバーが正当なクライアントがトランジションを介して握手をすることを望んでいる場合（たとえば、サーバーがSecret 2に変更された後、Secret 1のCookieを受け取り、2番目のClientHelloを送信した場合、サーバーは限られたウィンドウを持つことができます。両方の秘密を受け入れます。[IKEV2]は、このケースを検出するためにCookieにバージョン番号を追加することをお勧めします。別のアプローチは、単に両方の秘密を検証することです。
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サーバーは、新しい握手が実行されるたびにCookie Exchangeを実行する必要があります。増幅が問題にならない環境でサーバーが動作している場合、サーバーはCookie Exchangeを実行しないように構成されている場合があります。ただし、デフォルトは、交換が実行されることです。さらに、サーバーは、セッションが再開されたときにCookie交換を行わないことを選択できます。クライアントは、すべての握手でクッキー交換を行う準備をする必要があります。
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are not included in the calculation of the verify_data for the Finished message.
HelloverifeRequestが使用されている場合、最初のClientHelloとHelloverifeRequestは、完成したメッセージの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 = 0があります。新しいメッセージが生成されるたびに、message_seq値は1つで増加します。メッセージが再送信されると、同じmessage_seq値が使用されます。例えば：
Client Server
------ ------
ClientHello (seq=0) ------>
X<-- HelloVerifyRequest (seq=0) (lost)
X <-ElloverifeRequest（seq = 0）（lost）（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連続データ範囲に分割します。これらの範囲は、最大握手フラグメントサイズよりも大きくてはならず、握手メッセージ全体を共同で含める必要があります。範囲は重複してはいけません。その後、送信者はnハンドシェイクメッセージを作成します。すべては、元のハンドシェイクメッセージと同じmessage_seq値を備えています。新しいメッセージには、fragment_offset（以前のフラグメントに含まれるバイト数）とfragment_length（このフラグメントの長さ）でラベル付けされます。すべてのメッセージの長さフィールドは、元のメッセージの長さフィールドと同じです。fragmented fragmentedメッセージは、fragment_offset = 0およびfragment_length = 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の実装は、重複するフラグメント範囲を処理できる必要があります。これにより、送信者はPath 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つのDTLメッセージをパックする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.セッションを展開する握手のためのメッセージフライト（Cookie Exchangeなし）
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.
送信状態では、実装はメッセージのバッファリングフライトを送信します。メッセージが送信されると、実装は、これが握手の最後のフライトである場合、完成状態に入ります。または、実装がより多くのメッセージを受信することを期待している場合、再送信タイマーを設定してから待機状態に入ります。
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を受け取ったとき、ITは完成から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.
タイマーの値は実装の選択ですが、タイマーを誤って扱うことは深刻な混雑の問題につながる可能性があります。たとえば、DTLの多くのインスタンスが早期にタイムアウトし、混雑したリンクであまりにも速く再送信した場合。実装では、初期タイマー値は1秒（RFC 2988 [RFC2988]で定義されている最小）を使用し、各再送信で値を2倍にし、RFC 2988最大60秒以上になります。時間に敏感なアプリケーションの遅延を改善するために、3秒のRFC 2988デフォルトではなく、1秒のタイマーをお勧めします。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倍以上の長期間の怠idle性の後、実装はタイマーを初期値にリセットする場合があります。これが発生する可能性のある状況の1つは、実質的なデータ転送後に再ハンドシェイクが使用される場合です。
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 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を単一のフラグメントとして送信したかのように完成したMACを計算する必要があります。Cookie Exchangeが使用される場合、最初のClientHelloとHelloverifeRequestを完成した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のバリアントについて説明するため、セキュリティ上の考慮事項のほとんどは、付録D、E、およびFで説明されているTLS 1.1 [TLS11]のものと同じです。
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には、サービスの拒否から保護するために設計されたCookie Exchangeが含まれています。ただし、このCookie Exchangeを使用していない実装は、依然としてDOSに対して脆弱です。特に、Cookie Exchangeを使用していないDTLSサーバーは、DOSが経験していない場合でも、攻撃アンプとして使用できます。したがって、DTLSサーバーは、増幅が環境の脅威ではないと信じる正当な理由がない限り、Cookie Exchangeを使用する必要があります。クライアントは、すべての握手でクッキー交換を行う準備をする必要があります。
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の設計に関する議論とコメントについて、Dan Boneh、Eu-Jin Goh、Russ Housley、Constantine Sapuntzakis、Hovav Shachamに感謝したいと思います。コメントについては、DTLS [DTLS]に関する元のNDSSペーパーの匿名のNDSSレビュアーに感謝します。また、多くのポイントを明確にするのに役立ったフィードバックをしてくれたSteve Kentに感謝します。PMTUのセクションは、DCCP仕様[DCCP]からCribbedでした。Pasi Eronenは、この仕様の詳細なレビューを提供しました。この文書に関する有益なコメントは、マーク・オールマン、ジャリ・アークコ、ジョエル・ハルパーン、テッド・ハーディ、アリソン・マンキンからも受け取られました。
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に新しい識別子が割り当てられている場合、著者はDTLに適しているかどうかを指定する必要があります。
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ハンドシェークタイプレジストリから値が割り当てられた新しいハンドシェイクメッセージhello_verify_requestを定義します。値「3」はIANAによって割り当てられています。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.1」、RFC 4346、2006年4月。
[AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[Aescache] Bernstein、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] Kent、S。およびR. Atkinson、「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] Kohler、E.、Handley、M.、Floyd、S.、Padhye、J。、「Datagram渋滞制御プロトコル」、Work in Progress、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.、Rescorla、E。、「Datagram TLSの設計と実装」、ISOC NDSS 2004の議事録、2004年2月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[Photuris] Karn、P。and W. Simpson、「ICMPセキュリティ障害メッセージ」、RFC 2521、1999年3月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[Pop] Myers、J。and M. Rose、「郵便局プロトコル - バージョン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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、RFC 3261、2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「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
Eric Rescorla RTFM、Inc。2064 Edgewood Drive Palo Alto、CA 94303
EMail: ekr@rtfm.com
Nagendra Modadugu Computer Science Department Stanford University 353 Serra Mall Stanford, CA 94305
Nagendra Modadugu Computer Science Department Stanford University 353 Serra Mall Stanford、CA 94305
EMail: nagendra@cs.stanford.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。