[要約] RFC 6347は、Datagram Transport Layer Security（DTLS）のバージョン1.2に関する仕様を提供しています。DTLSは、UDPを使用するネットワーク通信にセキュリティを提供するためのプロトコルであり、このRFCはその目的と仕様をまとめています。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 6347 RTFM, Inc.
Obsoletes: 4347 N. Modadugu
Category: Standards Track Google, Inc.
ISSN: 2070-1721 January 2012
Datagram Transport Layer Security Version 1.2
データグラムトランスポート層セキュリティバージョン1.2
Abstract
概要
This document specifies version 1.2 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. This document updates DTLS 1.0 to work with TLS version 1.2.
このドキュメントは、Datagram Transport Layer Security（DTLS）プロトコルのバージョン1.2を指定します。 DTLSプロトコルは、データグラムプロトコルの通信プライバシーを提供します。このプロトコルにより、クライアント/サーバーアプリケーションは、盗聴、改ざん、またはメッセージの偽造を防止するように設計された方法で通信できます。 DTLSプロトコルはトランスポート層セキュリティ（TLS）プロトコルに基づいており、同等のセキュリティが保証されます。基礎となるトランスポートのデータグラムセマンティクスは、DTLSプロトコルによって保持されます。このドキュメントは、TLSバージョン1.2で動作するようにDTLS 1.0を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6347.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6347で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
2. Usage Model .....................................................5
3. Overview of DTLS ................................................5
3.1. Loss-Insensitive Messaging .................................6
3.2. Providing Reliability for Handshake ........................6
3.2.1. Packet Loss .........................................6
3.2.2. Reordering ..........................................7
3.2.3. Message Size ........................................7
3.3. Replay Detection ...........................................7
4. Differences from TLS ............................................7
4.1. Record Layer ...............................................8
4.1.1. Transport Layer Mapping ............................10
4.1.1.1. PMTU Issues ...............................10
4.1.2. Record Payload Protection ..........................12
4.1.2.1. MAC .......................................12
4.1.2.2. Null or Standard Stream Cipher ............13
4.1.2.3. Block Cipher ..............................13
4.1.2.4. AEAD Ciphers ..............................13
4.1.2.5. New Cipher Suites .........................13
4.1.2.6. Anti-Replay ...............................13
4.1.2.7. Handling Invalid Records ..................14
4.2. The DTLS Handshake Protocol ...............................14
4.2.1. Denial-of-Service Countermeasures ..................15
4.2.2. Handshake Message Format ...........................18
4.2.3. Handshake Message Fragmentation and Reassembly .....19
4.2.4. Timeout and Retransmission .........................20
4.2.4.1. Timer Values ..............................24
4.2.5. ChangeCipherSpec ...................................25
4.2.6. CertificateVerify and Finished Messages ............25
4.2.7. Alert Messages .....................................25
4.2.8. Establishing New Associations with Existing
Parameters .........................................25
4.3. Summary of New Syntax .....................................26
4.3.1. Record Layer .......................................26
4.3.2. Handshake Protocol .................................27
5. Security Considerations ........................................27
6. Acknowledgments ................................................28
7. IANA Considerations ............................................28
8. Changes since DTLS 1.0 .........................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
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]. Therefore, it cannot be used to secure unreliable datagram traffic.
TLS [TLS]は、ネットワークトラフィックを保護するために最も広く導入されているプロトコルです。 Webトラフィックの保護や、IMAP [IMAP]やPOP [POP]などの電子メールプロトコルに広く使用されています。 TLSの主な利点は、透過的な接続指向のチャネルを提供することです。したがって、アプリケーション層とトランスポート層の間にTLSを挿入することで、アプリケーションプロトコルを簡単に保護できます。ただし、TLSは信頼できるトランスポートチャネル（通常はTCP [TCP]）で実行する必要があります。したがって、信頼できないデータグラムトラフィックを保護するために使用することはできません。
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 [RFC4301]. 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. 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 require 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 [RFC4301]を使用できます。ただし、[WHYIPSEC]で説明されているいくつかの理由により、これは一部のアプリケーションにのみ適しています。次に、カスタムアプリケーションレイヤーセキュリティプロトコルを設計できます。残念ながら、アプリケーション層のセキュリティプロトコルは一般に優れたセキュリティプロパティ（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. This memo describes a protocol for this purpose: 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の使用は自動的に禁止されます。このメモは、この目的のためのプロトコルについて説明しています：データグラムトランスポート層セキュリティ（DTLS）。 DTLSは、新しいセキュリティの発明を最小限に抑え、コードとインフラストラクチャの再利用の量を最大化するために、可能な限りTLSに類似するように意図的に設計されています。
DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This document introduces a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12]. There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS. This version also clarifies some confusing points in the DTLS 1.0 specification.
DTLS 1.0 [DTLS1]は、もともと[TLS11]からのデルタとして定義されていました。このドキュメントでは、新しいバージョンのDTLSであるDTLS 1.2を紹介します。これは、TLS 1.2 [TLS12]に対する一連のデルタとして定義されています。 DTLS 1.1はありません。バージョン番号をTLSと調和させるために、そのバージョン番号はスキップされました。このバージョンでは、DTLS 1.0仕様のいくつかの紛らわしい点も明確になっています。
Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS 1.2 implementations can interoperate with previous versions of TLS (see Appendix E.1 of [TLS12] for details), with the exception that there is no DTLS version of SSLv2 or SSLv3, so backward compatibility issues for those protocols do not apply.
DTLS 1.2とDTLS 1.0の両方を話す実装は、TLS 1.2実装が以前のバージョンのTLSと相互運用できるのと同じように（もちろんDTLS 1.0を使用して）DTLS 1.0のみを話す実装と相互運用できます（詳細については、[TLS12]の付録E.1を参照してください） ）、SSLv2またはSSLv3のDTLSバージョンがないことを除いて、これらのプロトコルの下位互換性の問題は適用されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [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プロトコルを使用して通信を保護する場合、そのようなアプリケーションの動作は変わりません。
The basic design philosophy of DTLS is to construct "TLS over datagram transport". 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; 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 over datagram transport」を構築することです。 TLSをデータグラム環境で直接使用できないのは、単にパケットが失われたり、並べ替えられたりする可能性があるためです。 TLSには、この種の信頼性を処理するための内部機能はありません。したがって、TLS実装は、データグラムトランスポート上でホストし直すと機能しなくなります。 DTLSの目的は、この問題を修正するために必要なTLSへの最小限の変更のみを行うことです。可能な限り、DTLSはTLSと同じです。新しいメカニズムを発明する必要があるときはいつでも、TLSのスタイルを維持するような方法でそれを試みます。
Unreliability creates problems for TLS at two levels:
信頼性が低いと、TLSの問題が2つのレベルで発生します。
1. TLS does not allow independent decryption of individual records. Because the integrity check depends on the sequence number, if record N is not received, then the integrity check on record N+1 will be based on the wrong sequence number and thus will fail. (Note that prior to TLS 1.1, there was no explicit IV and so decryption would also fail.)
1. TLSでは、個々のレコードを個別に復号化することはできません。整合性チェックはシーケンス番号に依存するため、レコードNが受信されない場合、レコードN + 1の整合性チェックは誤ったシーケンス番号に基づいて行われるため、失敗します。 （TLS 1.1以前は、明示的なIVがなかったため、復号化も失敗することに注意してください。）
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 (stream cipher key stream) is retained between records.
1. 暗号化コンテキスト（ストリーム暗号キーストリーム）は、レコード間で保持されます。
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によって提供されますが、シーケンス番号はレコードに暗黙的に含まれます。
DTLS solves the first problem by banning stream ciphers. DTLS solves the second problem by adding explicit sequence numbers.
DTLSは、ストリーム暗号を禁止することによって最初の問題を解決します。 DTLSは、明示的なシーケンス番号を追加することにより、2番目の問題を解決します。
The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order; 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 IP fragmentation. DTLS must provide fixes for both of these problems.
TLSハンドシェイクは、ロックステップ暗号ハンドシェイクです。メッセージは、定義された順序で送受信する必要があります。他の順序はエラーです。明らかに、これは並べ替えやメッセージの損失と互換性がありません。さらに、TLSハンドシェイクメッセージは特定のデータグラムよりも大きくなる可能性があるため、IPフラグメンテーションの問題が発生します。 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)
X <-HelloVerifyRequest（失われた）
[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.
クライアントがClientHelloメッセージを送信すると、サーバーからのHelloVerifyRequestの受信を期待します。ただし、サーバーのメッセージが失われた場合、クライアントはClientHelloまたはHelloVerifyRequestが失われたことを認識し、再送信します。サーバーは再送信を受信すると、再送信することを認識します。
The server also maintains a retransmission timer and retransmits when that timer expires.
また、サーバーは再送信タイマーを維持し、そのタイマーの期限が切れると再送信します。
Note that timeout and retransmission do not apply to the HelloVerifyRequest, because this would require creating state on the server. The HelloVerifyRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloVerifyRequests.
タイムアウトと再送信はHelloVerifyRequestには適用されないことに注意してください。これにはサーバーで状態を作成する必要があるためです。 HelloVerifyRequestは、それ自体がフラグメント化されないように十分に小さく設計されているため、複数の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 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 IP fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records, each of which is intended to fit in a single IP datagram. 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バイト、実際には数キロバイト）。対照的に、IPフラグメンテーションが望まれない場合、UDPデータグラムはしばしば<1500バイトに制限されます。この制限を補うために、各DTLSハンドシェイクメッセージは、それぞれが単一のIPデータグラムに収まるように意図された複数の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.2 [TLS12]. Where we do not explicitly call out differences, DTLS is the same as in [TLS12].
セクション3で述べたように、DTLSは意図的にTLSに非常に似ています。したがって、DTLSを新しいプロトコルとして提示する代わりに、TLS 1.2 [TLS12]からの一連のデルタとして提示します。明示的に違いを明示しない場合、DTLSは[TLS12]と同じです。
The DTLS record layer is extremely similar to that of TLS 1.2. 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.2のレイヤーと非常に似ています。唯一の変更は、明示的なシーケンス番号がレコードに含まれていることです。このシーケンス番号により、受信者は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.2 record.
type TLS 1.2レコードのtypeフィールドに相当します。
version The version of the protocol being employed. This document describes DTLS version 1.2, which uses the version { 254, 253 }. The version value of 254.253 is the 1's complement of DTLS version 1.2. 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.)
version使用されているプロトコルのバージョン。このドキュメントでは、バージョン{254、253}を使用するDTLSバージョン1.2について説明します。 254.253のバージョン値は、DTLSバージョン1.2の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.2 record. As in TLS 1.2, the length should not exceed 2^14.
length TLS 1.2レコードのlengthフィールドと同じです。 TLS 1.2と同様に、長さは2 ^ 14を超えてはなりません。
fragment Identical to the fragment field of a TLS 1.2 record.
TLS 1.2レコードのフラグメントフィールドと同じです。
DTLS uses an explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. Sequence numbers are maintained separately for each epoch, with each sequence_number initially being 0 for each epoch. For instance, if a handshake message from epoch 0 is retransmitted, it might have a sequence number after a message from epoch 1, even if the message from epoch 1 was transmitted first. Note that some care needs to be taken during the handshake to ensure that retransmitted messages use the right epoch and keying material.
DTLSは、レコードのsequence_numberフィールドで伝達される暗黙的なシーケンス番号ではなく、明示的なシーケンス番号を使用します。シーケンス番号はエポックごとに個別に維持され、各sequence_numberは最初は各エポックに対して0です。たとえば、エポック0からのハンドシェイクメッセージが再送信される場合、エポック1からのメッセージが最初に送信された場合でも、エポック1からのメッセージの後にシーケンス番号が付けられることがあります。ハンドシェイク中は、再送信されたメッセージが正しいエポックとキーイングマテリアルを使用するように注意する必要があることに注意してください。
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 a ChangeCipherSpec message 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; therefore, we do not expect this to be a problem.
複数のハンドシェイクが連続して実行される場合、同じシーケンス番号を持つが暗号化状態が異なる複数のレコードが回線上にある可能性があります。エポックフィールドを使用すると、受信者はこのようなパケットを区別できます。エポック番号は最初はゼロで、ChangeCipherSpecメッセージが送信されるたびに増分されます。特定のシーケンス/エポックペアが一意であることを保証するために、実装は、同じエポック値がTCP最大セグメントライフタイムの2倍以内に再利用されることを許可してはなりません。実際には、TLS実装が再ハンドシェイクを行うことはほとんどありません。したがって、これが問題になるとは考えていません。
Note that because DTLS records may be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems they MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [TCP] to allow for packet reordering. (Note that the intention here is that implementors use the current guidance from the IETF for MSL, not that they attempt to interrogate the MSL that the system TCP stack is using.) Until the handshake has completed, implementations MUST accept packets from the old epoch.
DTLSレコードは並べ替えられる可能性があるため、エポック2の開始後に、エポック1からのレコードを受信する場合があります。一般に、実装は以前のエポックからのパケットを破棄する必要がありますが、パケット損失により顕著な問題が発生した場合、TCP [TCP]に指定されたデフォルトのMSLまで、以前のエポックからのキーイングマテリアルを保持して、パケットの並べ替えを可能にすることができます。 （ここでの意図は、実装者がシステムTCPスタックが使用しているMSLに問い合わせるのではなく、MSLのIETFからの現在のガイダンスを使用することです。）ハンドシェイクが完了するまで、実装は古いエポックからのパケットを受け入れる必要があります。 。
Conversely, it is possible for records that are protected by the newly negotiated context to be received prior to the completion of a handshake. For instance, the server may send its Finished message and then start transmitting data. Implementations MAY either buffer or discard such packets, though when DTLS is used over reliable transports (e.g., SCTP), they SHOULD be buffered and processed once the handshake completes. Note that TLS's restrictions on when packets may be sent still apply, and the receiver treats the packets as if they were sent in the right order. In particular, it is still impermissible to send data prior to completion of the first handshake.
逆に、新たにネゴシエートされたコンテキストによって保護されているレコードが、ハンドシェイクの完了前に受信される可能性があります。たとえば、サーバーは完了メッセージを送信し、データの送信を開始します。実装は、そのようなパケットをバッファリングまたは破棄することができますが、DTLSが信頼性の高いトランスポート（SCTPなど）で使用される場合、ハンドシェイクが完了すると、バッファリングして処理する必要があります（SHOULD）。パケットの送信時期に関するTLSの制限が引き続き適用され、受信者はパケットを正しい順序で送信されたかのように処理することに注意してください。特に、最初のハンドシェイクが完了する前にデータを送信することはまだ許されていません。
Note that in the special case of a rehandshake on an existing association, it is safe to process a data packet immediately, even if the ChangeCipherSpec or Finished messages have not yet been received provided that either the rehandshake resumes the existing session or that it uses exactly the same security parameters as the existing association. In any other case, the implementation MUST wait for the receipt of the Finished message to prevent downgrade attack.
既存のアソシエーションでの再ハンドシェイクの特別なケースでは、ChangeCipherSpecまたはFinishedメッセージがまだ受信されていない場合でも、再ハンドシェイクが既存のセッションを再開するか、正確に使用することを条件として、データパケットをすぐに処理しても安全です。既存の関連付けと同じセキュリティパラメータ。それ以外の場合、ダウングレード攻撃を防ぐために、実装は終了メッセージの受信を待機する必要があります。
As in TLS, implementations MUST either abandon an association or rehandshake prior to allowing the sequence number to wrap.
TLSの場合と同様に、実装は、シーケンス番号のラップを許可する前に、関連付けを破棄するか、再ハンドシェイクする必要があります。
Similarly, implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association as described in Section 4.2.8. In practice, implementations rarely rehandshake repeatedly on the same channel, so this is not likely to be an issue.
同様に、実装はエポックのラップを許可してはならず（MUST NOT）、代わりに新しい関連付けを確立して、セクション4.2.8で説明されているように古い関連付けを終了しなければなりません（MUST）。実際には、実装が同じチャネルで繰り返しハンドシェイクを繰り返すことはほとんどないため、これが問題になることはほとんどありません。
Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer.
各DTLSレコードは単一のデータグラム内に収まる必要があります。 IP断片化を回避するために、DTLSレコードレイヤーのクライアントは、レコードレイヤーから取得したPMTUの見積もり内に収まるようにレコードのサイズを設定する必要があります（SHOULD）。
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 the 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レコードを1つのデータグラムに配置できます。それらは単純に連続してエンコードされます。境界を判別するには、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; 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の拡張機能が指定され、制約された環境でのデプロイメントに1セットのシーケンス番号のみを使用できるようになる可能性があります。
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. [DCCPDTLS] defines a mapping of DTLS to DCCP that takes these issues into account.
DCCPなどの一部のトランスポートは、それらを介して伝送されるトラフィックに輻輳制御を提供します。輻輳ウィンドウが十分に狭い場合、DTLSハンドシェイクの再送信がすぐに送信されるのではなく保持され、タイムアウトと偽の再送信が発生する可能性があります。このようなトランスポートでDTLSを使用する場合は、輻輳ウィンドウの可能性を超えないように注意する必要があります。 [DCCPDTLS]は、これらの問題を考慮したDTLSからDCCPへのマッピングを定義します。
In general, DTLS's philosophy is to leave PMTU discovery to the application. However, DTLS cannot completely ignore PMTU for three reasons:
一般的に、DTLSの哲学は、PMTUの発見をアプリケーションに任せることです。ただし、次の3つの理由により、DTLSはPMTUを完全に無視できません。
- The DTLS record framing expands the datagram size, thus lowering the effective PMTU from the application's perspective.
- DTLSレコードフレーミングはデータグラムサイズを拡張するため、アプリケーションの観点から有効なPMTUが低下します。
- In some implementations, the application may not directly talk to the network, in which case the DTLS stack may absorb ICMP [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] "Packet Too Big" indications.
- 一部の実装では、アプリケーションがネットワークと直接通信しない場合があります。その場合、DTLSスタックはICMP [RFC1191]「データグラムが大きすぎます」の表示またはICMPv6 [RFC4443]「パケットが大きすぎます」の表示を吸収する場合があります。
- The DTLS handshake messages can exceed the PMTU.
- DTLSハンドシェイクメッセージはPMTUを超える可能性があります。
In order to deal with the first two issues, the DTLS record layer SHOULD behave as described below.
最初の2つの問題に対処するために、DTLSレコードレイヤーは以下のように動作する必要があります（SHOULD）。
If PMTU estimates are available from the underlying transport protocol, they should be made available to upper layer protocols. In particular:
基礎となるトランスポートプロトコルからPMTUの見積もりが利用できる場合は、上位層のプロトコルでも利用できるようにする必要があります。特に：
- For DTLS over UDP, the upper layer protocol SHOULD be allowed to obtain the PMTU estimate maintained in the IP layer.
- DTLS over UDPの場合、上位層プロトコルは、IP層で維持されているPMTU推定値を取得できる必要があります（SHOULD）。
- For DTLS over DCCP, the upper layer protocol SHOULD be allowed to obtain the current estimate of the PMTU.
- DTLS over DCCPの場合、上位層プロトコルは、PMTUの現在の推定値を取得できる必要があります（SHOULD）。
- For DTLS over TCP or SCTP, which automatically fragment and reassemble datagrams, there is no PMTU limitation. However, the upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes.
- データグラムを自動的に断片化および再構築するDTLS over TCPまたはSCTPの場合、PMTUの制限はありません。ただし、上位層プロトコルは、最大レコードサイズの2 ^ 14バイトを超えるレコードを書き込んではなりません（MUST NOT）。
The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. Note that this number is only an estimate because of block padding and the potential use of DTLS compression.
DTLSレコード層は、上位層プロトコルがDTLS処理によって予期されるレコード拡張の量を発見できるようにする必要があります（SHOULD）。ブロックパディングとDTLS圧縮の潜在的な使用のため、この数は推定値にすぎないことに注意してください。
If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in Section 14 of [DCCP]), then the DTLS record layer MUST inform the upper layer protocol of the error.
トランスポートプロトコルの指示がある場合（ICMP経由、または[DCCP]のセクション14のようにデータグラムの送信拒否を介して）、DTLSレコード層は上位層プロトコルにエラーを通知する必要があります。
The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular:
DTLSレコードレイヤーは、[RFC1191]または[RFC4821]メカニズムを介して、PMTUディスカバリを実行する上位レイヤープロトコルに干渉しないでください。特に：
- Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit (in IPv4) or prohibit local fragmentation (in IPv6).
- 基礎となるトランスポートプロトコルで許可されている場合、上位層プロトコルはDFビットの状態を設定（IPv4の場合）またはローカルフラグメンテーションを禁止（IPv6の場合）できるようにする必要があります（SHOULD）。
- If the underlying transport protocol allows the application to request PMTU probing (e.g., DCCP), the DTLS record layer should honor this request.
- 基礎となるトランスポートプロトコルにより、アプリケーションがPMTUプローブ（DCCPなど）を要求できる場合、DTLSレコードレイヤーはこの要求を受け入れる必要があります。
The final issue is the DTLS handshake protocol. From the perspective of the DTLS record layer, this is merely another upper layer protocol. However, DTLS handshakes occur infrequently and involve only a few round trips; therefore, the handshake protocol PMTU handling places a premium on rapid completion over accurate PMTU discovery. In order to allow connections under these circumstances, DTLS implementations SHOULD follow the following rules:
最後の問題は、DTLSハンドシェイクプロトコルです。 DTLSレコード層の観点から見ると、これは単なる別の上位層プロトコルです。ただし、DTLSハンドシェイクはまれにしか発生せず、ラウンドトリップは数回しか発生しません。したがって、ハンドシェイクプロトコルのPMTU処理では、正確なPMTUの発見よりも迅速な完了が優先されます。これらの状況で接続を許可するために、DTLS実装は次のルールに従う必要があります。
- If the DTLS record layer informs the DTLS handshake layer that a message is too big, it SHOULD immediately attempt to fragment it, using any existing information about the PMTU.
- DTLSレコードレイヤーがDTLSハンドシェイクレイヤーにメッセージが大きすぎることを通知する場合、PMTUに関する既存の情報を使用して、すぐにメッセージをフラグメント化する必要があります（SHOULD）。
- If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a smaller record size, fragmenting the handshake message as appropriate. This standard does not specify an exact number of retransmits to attempt before backing off, but 2-3 seems appropriate.
- 再送信を繰り返しても応答が得られず、PMTUが不明な場合、その後の再送信では、より小さなレコードサイズに戻して、ハンドシェイクメッセージを適宜断片化する必要があります。この標準は、バックオフする前に試行する正確な再送信回数を指定していませんが、2〜3が適切と思われます。
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.2. 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.2と同じです。ただし、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, 253} for DTLS 1.2.
TLS MAC計算は、プロトコルバージョン番号でパラメーター化されます。これは、DTLSの場合、オンザワイヤーバージョンです。つまり、DTLS 1.2の場合は{254、253}です。
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 records with bad MACs or that are otherwise invalid. They MAY log an error. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate a bad_record_mac alert with level fatal and terminate its connection state. Note that because errors do not cause connection termination, DTLS stacks are more efficient error type oracles than TLS stacks. Thus, it is especially important that the advice in Section 6.2.3.2 of [TLS12] be followed.
一般に、DTLS実装は、不正なMACを持つレコード、または無効なレコードを警告なく破棄する必要があります（SHOULD）。エラーを記録する場合があります。 DTLS実装が無効なMACのメッセージを受信したときにアラートを生成することを選択した場合、それはレベルfatalのbad_record_macアラートを生成し、その接続状態を終了する必要があります。エラーによって接続が終了することはないため、DTLSスタックはTLSスタックよりも効率的なエラータイプオラクルであることに注意してください。したがって、[TLS12]のセクション6.2.3.2のアドバイスに従うことが特に重要です。
The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.
DTLS NULL暗号は、TLS 1.2 NULL暗号とまったく同じように実行されます。
The only stream cipher described in TLS 1.2 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
TLS 1.2で説明されている唯一のストリーム暗号は、ランダムにアクセスできないRC4です。 RC4はDTLSと一緒に使用してはなりません。
DTLS block cipher encryption and decryption are performed exactly as with TLS 1.2.
DTLSブロック暗号の暗号化と復号化は、TLS 1.2とまったく同じように実行されます。
TLS 1.2 introduced authenticated encryption with additional data (AEAD) cipher suites. The existing AEAD cipher suites, defined in [ECCGCM] and [RSAGCM], can be used with DTLS exactly as with TLS 1.2.
TLS 1.2は、追加データを使用した認証済み暗号化（AEAD）暗号スイートを導入しました。 [ECCGCM]および[RSAGCM]で定義されている既存のAEAD暗号スイートは、TLS 1.2とまったく同じようにDTLSで使用できます。
Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made (see Section 7 for IANA considerations).
登録時に、新しいTLS暗号スイートは、それらがDTLSの使用に適しているかどうか、および必要に応じて何を調整する必要があるかを示さなければなりません（IANAの考慮事項についてはセクション7を参照）。
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 [ESP].
DTLSレコードには、リプレイ保護を提供するシーケンス番号が含まれています。シーケンス番号の検証は、[ESP]のセクション3.4.3から借用した次のスライディングウィンドウプロシージャを使用して実行する必要があります（SHOULD）。
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.
このセッションの受信側パケットカウンターは、セッションが確立されたときにゼロに初期化される必要があります。受信したレコードごとに、受信者は、レコードに、このセッションの存続中に受信した他のレコードのシーケンス番号と重複しないシーケンス番号が含まれていることを確認する必要があります。これは、重複するレコードの拒否を高速化するために、セッションに一致した後のパケットに適用される最初のチェックである必要があります（SHOULD）。
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） 。別のウィンドウサイズ（最小値より大きい）は、受信者が選択できます（MAY）。 （受信者は送信者にウィンドウサイズを通知しません。）
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 Section 3.4.3 of [ESP].
ウィンドウの「右」端は、このセッションで受信した検証済みのシーケンス番号の最大値を表します。ウィンドウの「左」端より小さいシーケンス番号を含むレコードは拒否されます。ウィンドウ内にあるパケットは、ウィンドウ内で受信したパケットのリストと照合されます。ビットマスクの使用に基づいてこのチェックを実行するための効率的な方法は、[ESP]のセクション3.4.3で説明されています。
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検証が成功した場合にのみ更新されます。
Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead, MUST generate fatal level alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports.
TLSとは異なり、DTLSは無効なレコード（たとえば、無効なフォーマット、長さ、MACなど）に直面しても回復力があります。一般に、無効なレコードは警告なしで破棄されるべきであり（SHOULD）、関連付けを保持します。ただし、診断目的でエラーが記録される場合があります。代わりにアラートを生成することを選択した実装は、攻撃者が実装を繰り返しプローブしてさまざまなタイプのエラーにどのように応答するかを確認する攻撃を回避するために、致命的なレベルのアラートを生成する必要があります。 UDPでDTLSが実行されている場合、UDP偽造は非常に簡単であるため、これを実行する実装はサービス拒否（DoS）攻撃の影響を非常に受けやすいことに注意してください。したがって、この方法はそのようなトランスポートには推奨されません。
If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer.
DTLSが偽造に耐性のあるトランスポート（SCTP-AUTHを使用したSCTPなど）で運ばれている場合、攻撃者はトランスポート層で拒否されないデータグラムを偽造することが困難になるため、アラートを送信する方が安全です。
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. サービス拒否攻撃を防ぐために、ステートレスCookie交換が追加されました。
2. Modifications to the handshake header to handle message loss, reordering, and DTLS message fragmentation (in order to avoid IP fragmentation).
2. メッセージの損失、並べ替え、およびDTLSメッセージの断片化を処理するためのハンドシェイクヘッダーの変更（IPの断片化を回避するため）。
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.2.
これらの例外を除いて、DTLSメッセージの形式、フロー、およびロジックはTLS 1.2のものと同じです。
Datagram security protocols are extremely susceptible to a variety of 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 [IKEv2]. 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 [IKEv2]で使用されるステートレスCookieテクニックを借用します。クライアントがそのClientHelloメッセージをサーバーに送信すると、サーバーはHelloVerifyRequestメッセージで応答してもよい（MAY）。このメッセージには、[PHOTURIS]の手法を使用して生成されたステートレスCookieが含まれています。クライアントは、Cookieを追加してClientHelloを再送信する必要があります。次に、サーバーはCookieを検証し、有効な場合にのみハンドシェイクを続行します。このメカニズムにより、攻撃者/クライアントはCookieを受信できるようになり、なりすましの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メッセージを変更してCookie値を追加します。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // 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:
HelloVerifyRequestの定義は次のとおりです。
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>;
} HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3).
HelloVerifyRequestメッセージタイプはhello_verify_request（3）です。
The server_version field has the same syntax as in TLS. However, in order to avoid the requirement to do version negotiation in the initial handshake, DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
server_versionフィールドの構文はTLSと同じです。ただし、最初のハンドシェイクでバージョンネゴシエーションを行う必要性を回避するために、DTLS 1.2サーバーの実装では、ネゴシエートされることが予想されるTLSのバージョンに関係なく、DTLSバージョン1.0を使用する必要があります。 DTLS 1.2および1.0クライアントは、バージョンのネゴシエーションの一部としてではなく、パケットのフォーマット（DTLS 1.2と1.0の両方で同じ）を示すためにのみバージョンを使用する必要があります。特に、DTLS 1.2クライアントは、サーバーがHelloVerifyRequestでバージョン1.0を使用しているため、サーバーがDTLS 1.2ではないこと、または最終的にDTLS 1.2ではなくDTLS 1.0をネゴシエートすることを想定してはなりません。
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. In order to avoid sequence number duplication in case of multiple HelloVerifyRequests, the server MUST use the record sequence number in the ClientHello as the record sequence number in the HelloVerifyRequest.
HelloVerifyRequestに応答するとき、クライアントは元のClientHelloと同じパラメーター値（version、random、session_id、cipher_suites、compression_method）を使用する必要があります。サーバーはこれらの値を使用してCookieを生成し、Cookieの受信時にそれらが正しいことを確認する必要があります（SHOULD）。サーバーは、HelloVerifyRequestで、ServerHelloの送信時に使用するのと同じバージョン番号を使用する必要があります。 ServerHelloを受信すると、クライアントはサーバーのバージョン値が一致することを確認する必要があります。 HelloVerifyRequestが複数ある場合にシーケンス番号が重複しないようにするために、サーバーはClientHelloのレコードシーケンス番号をHelloVerifyRequestのレコードシーケンス番号として使用する必要があります。
Note: This specification increases the cookie size limit to 255 bytes for greater future flexibility. The limit remains 32 for previous versions of DTLS.
注：この仕様では、将来の柔軟性を高めるために、Cookieサイズの制限を255バイトに増やしています。以前のバージョンのDTLSでは、制限は32のままです。
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:
DTLSサーバーは、サーバー上でクライアントごとの状態を保持せずに検証できるようにCookieを生成する必要があります（SHOULD）。 1つの手法は、ランダムに生成されたシークレットを持ち、次のようにCookieを生成することです。
Cookie = HMAC(Secret, Client-IP, Client-Parameters)
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. In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the record sequence number in the ClientHello as the record sequence number in its initial ServerHello. Subsequent ServerHellos will only be sent after the server has created state and MUST increment normally.
2番目のClientHelloを受信すると、サーバーはCookieが有効であること、およびクライアントが特定のIPアドレスでパケットを受信できることを確認できます。複数のCookie交換の場合にシーケンス番号の重複を回避するために、サーバーは、ClientHelloのレコードシーケンス番号を最初のServerHelloのレコードシーケンス番号として使用する必要があります。後続のServerHelloは、サーバーが状態を作成した後でのみ送信され、通常どおりにインクリメントする必要があります。
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を無効にすることで、この攻撃から防御できます。サーバーが正当なクライアントが移行を通じてハンドシェイクできることを希望する場合（たとえば、クライアントはシークレット1でCookieを受信し、サーバーがシークレット2に変更された後に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交換を実行する必要があります（SHOULD）。増幅が問題にならない環境でサーバーを運用している場合は、Cookie交換を実行しないようにサーバーを構成できます（MAY）。ただし、デフォルトでは、交換が実行される必要があります。さらに、サーバーは、セッションが再開されたときにCookie交換を行わないことを選択できます（MAY）。クライアントは、すべてのハンドシェイクとのCookie交換を行う準備ができていなければなりません。
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are not included in the calculation of the handshake_messages (for the CertificateVerify message) and verify_data (for the Finished message).
HelloVerifyRequestを使用する場合、最初のClientHelloとHelloVerifyRequestは、handshake_messages（CertificateVerifyメッセージの場合）とverify_data（Finishedメッセージの場合）の計算に含まれません。
If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie. This avoids race/deadlock conditions if the client somehow gets a bad cookie (e.g., because the server changes its cookie signing key).
サーバーが無効なCookieを持つClientHelloを受信した場合、サーバーはそれをCookieのないClientHelloと同じように扱う必要があります。これにより、クライアントが何らかの理由で無効なCookieを取得した場合（たとえば、サーバーがCookie署名キーを変更したため）、競合/デッドロック状態を回避できます。
Note to implementors: This may result in clients receiving multiple HelloVerifyRequest messages with different cookies. Clients SHOULD handle this by sending a new ClientHello with a cookie in response to the new HelloVerifyRequest.
実装者への注意：これにより、クライアントは異なるCookieを持つ複数のHelloVerifyRequestメッセージを受信する可能性があります。クライアントは、新しいHelloVerifyRequestへの応答としてCookieを使用して新しいClientHelloを送信することにより、これを処理する必要があります（SHOULD）。
In order to support message loss, reordering, and message fragmentation, DTLS modifies the TLS 1.2 handshake header:
メッセージの損失、並べ替え、およびメッセージの断片化をサポートするために、DTLSはTLS 1.2ハンドシェイクヘッダーを変更します。
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. Note that in the case of a rehandshake, this implies that the HelloRequest will have message_seq = 0 and the ServerHello will have message_seq = 1. When a message is retransmitted, the same message_seq value is used. For example:
各サイドが各ハンドシェイクで送信する最初のメッセージには、常にmessage_seq = 0があります。新しいメッセージが生成されるたびに、message_seq値が1ずつ増加します。再ハンドシェイクの場合、これは、HelloRequestがmessage_seq = 0を持ち、ServerHelloがmessage_seq = 1を持つことを意味することに注意してください。メッセージが再送信されるとき、同じ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より大きい場合、実装はメッセージをキューに入れるべきですが（SHOULD）、メッセージを破棄してもよい（MAY）。 （これは単純なスペースと帯域幅のトレードオフです）。
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, each of which can be transmitted separately, thus avoiding IP fragmentation.
セクション4.1.1で述べたように、各DTLSメッセージは単一のトランスポート層データグラム内に収まる必要があります。ただし、ハンドシェイクメッセージは、最大レコードサイズを超える可能性があります。したがって、DTLSは、ハンドシェイクメッセージを複数のレコードにフラグメント化するメカニズムを提供します。各レコードは個別に送信できるため、IPフラグメント化を回避できます。
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 labeled 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（このフラグメントの長さ）のラベルが付けられます。すべてのメッセージの長さフィールドは、元のメッセージの長さフィールドと同じです。断片化されていないメッセージは、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 if the PMTU estimate changes.
DTLS実装は、ハンドシェイクメッセージフラグメントを受信すると、ハンドシェイクメッセージ全体を受信するまでバッファリングする必要があります。 DTLS実装は、重複するフラグメント範囲を処理できる必要があります。これにより、PMTUの見積もりが変更された場合、送信者はフラグメントサイズの小さいハンドシェイクメッセージを再送信できます。
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.セッション再開ハンドシェイクのメッセージフライト（Cookie交換なし）
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）を送信するため、PREPARE状態で開始されます。 DTLSサーバーはWAITING状態で起動しますが、バッファーは空で、再送信タイマーはありません。
+-----------+
| 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 | -------------------------------+
| |
+-----------+
| /|\
| |
| |
+---+
Read retransmit Retransmit last flight
最後のフライトを再送信する
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.
PREPARING状態では、実装は、メッセージの次のフライトを準備するために必要な計算を行います。次に、それらを送信のためにバッファーに入れ（最初にバッファーを空にする）、SENDING状態に入ります。
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.
SENDING状態では、実装はバッファリングされた一連のメッセージを送信します。メッセージが送信されると、ハンドシェイクの最後のフライトである場合、実装は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. 再送信タイマーの期限が切れます。実装はSENDING状態に移行し、フライトを再送信し、再送信タイマーをリセットして、WAITING状態に戻ります。
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. 実装はピアから再送信されたフライトを読み取ります。実装はSENDING状態に移行し、フライトを再送信し、再送信タイマーをリセットして、WAITING状態に戻ります。ここでの理論的根拠は、重複したメッセージの受信は、ピアでのタイマー満了の結果である可能性が高いため、以前のフライトの一部が失われたことを示唆しています。
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. 実装は次の一連のメッセージを受信します。これがメッセージの最後の一連のフライトである場合、実装はFINISHEDに移行します。実装が新しいフライトを送信する必要がある場合、準備はPREPARING状態に移行します。部分的な読み取り（部分的なメッセージまたはフライト内の一部のメッセージのみ）は、状態遷移やタイマーのリセットを引き起こしません。
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）を送信するため、PREPARE状態で開始されます。 DTLSサーバーはWAITING状態で起動しますが、バッファーは空で、再送信タイマーはありません。
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.
サーバーが再ハンドシェイクを要求すると、サーバーはFINISHED状態からPREPARING状態に移行して、HelloRequestを送信します。クライアントは、HelloRequestを受信すると、FINISHEDからPREPARINGに移行して、ClientHelloを送信します。
In addition, for at least twice the default MSL defined for [TCP], when in the FINISHED state, the node that transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight. This avoids deadlock conditions if the last flight gets lost. This requirement applies to DTLS 1.0 as well, and though not explicit in [DTLS1], it was always required for the state machine to function correctly. To see why this is necessary, consider what happens in an ordinary handshake if the server's Finished message is lost: the server believes the handshake is complete but it actually is not. As the client is waiting for the Finished message, the client's retransmit timer will fire and it will retransmit the client's Finished message. This will cause the server to respond with its own Finished message, completing the handshake. The same logic applies on the server side for the resumed handshake.
さらに、[TCP]に定義されているデフォルトのMSLの2倍以上、FINISHED状態の場合、最後のフライトを送信するノード（通常のハンドシェイクのサーバーまたは再開されたハンドシェイクのクライアント）は、最後のフライトを再送信したピアの最後のフライト。これにより、最後のフライトが失われた場合のデッドロック状態を回避できます。この要件はDTLS 1.0にも適用され、[DTLS1]では明示的ではありませんが、ステートマシンが正しく機能するために常に必要でした。これが必要な理由を確認するには、サーバーの終了メッセージが失われた場合に通常のハンドシェイクで何が起こるかを検討してください。サーバーはハンドシェイクが完了したと信じていますが、実際はそうではありません。クライアントが終了メッセージを待機しているときに、クライアントの再送信タイマーが起動し、クライアントの終了メッセージを再送信します。これにより、サーバーは独自の終了メッセージで応答し、ハンドシェイクを完了します。同じロジックが再開されたハンドシェイクのサーバー側に適用されます。
Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message. Implementations MUST either discard or buffer all application data packets for the new epoch until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer.
パケット損失のため、片側が最初の側の完了メッセージを受信していなくても、片側がアプリケーションデータを送信している可能性があることに注意してください。実装は、新しいエポックのFinishedメッセージを受信するまで、新しいエポックのすべてのアプリケーションデータパケットを破棄またはバッファリングする必要があります。実装は、対応するFinishedメッセージの受信前に、新しいエポックでアプリケーションデータの受信を並べ替えまたはパケット損失の証拠として扱い、最終的なフライトをすぐに再送信して、再送信タイマーを短縮できます（MAY）。
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 6298 [RFC6298]) and double the value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 6298 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 6298 [RFC6298]で定義されている最小値）を使用し、RFC 6298の最大値である60秒まで、再送信のたびに値を2倍にする必要があります（SHOULD）。時間に敏感なアプリケーションの待ち時間を改善するために、3秒のRFC 6298のデフォルトではなく、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倍以上で、実装はタイマーを初期値にリセットします。これが発生する可能性がある状況の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. This creates a potential ambiguity because the order of the ChangeCipherSpec cannot be established unambiguously with respect to the handshake messages in case of message loss.
TLSと同様に、ChangeCipherSpecメッセージは技術的にはハンドシェイクメッセージではありませんが、タイムアウトと再送信のために、関連するFinishedメッセージと同じフライトの一部として扱われる必要があります。メッセージが失われた場合に、ハンドシェイクメッセージに関してChangeCipherSpecの順序を明確に確立できないため、これにより潜在的なあいまいさが生じます。
This is not a problem with any current TLS mode because the expected set of handshake messages logically preceeding the ChangeCipherSpec is predictable from the rest of the handshake state. However, future modes MUST take care to avoid creating ambiguity.
ChangeCipherSpecに論理的に先行する予想される一連のハンドシェイクメッセージは、残りのハンドシェイク状態から予測可能であるため、これは現在のTLSモードの問題ではありません。ただし、将来のモードでは、あいまいさを生じさせないように注意する必要があります。
CertificateVerify and Finished messages have the same format as in TLS. Hash calculations include entire handshake messages, including DTLS-specific fields: message_seq, fragment_offset, and fragment_length. However, in order to remove sensitivity to handshake message 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 CertificateVerify or Finished MAC computations.
CertificateVerifyメッセージとFinishedメッセージの形式は、TLSと同じです。ハッシュ計算には、DTLS固有のフィールド（message_seq、fragment_offset、fragment_length）を含む、ハンドシェイクメッセージ全体が含まれます。ただし、ハンドシェイクメッセージの断片化に対する感度を削除するために、各ハンドシェイクメッセージが単一のフラグメントとして送信されたかのように終了MACを計算する必要があります。 Cookie交換が使用される場合、最初のClientHelloおよびHelloVerifyRequestをCertificateVerifyまたはFinished MACの計算に含めてはならないことに注意してください。
Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation which would ordinarily issue an alert 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実装は、問題のあるレコードが再度受信された場合（たとえば、再送信されたハンドシェイクメッセージとして）、新しいアラートメッセージを生成する必要があります（SHOULD）。実装は、ピアが不良メッセージを永続的に送信していることを検出し、そのような誤動作が検出された後にローカル接続状態を終了する必要があります（SHOULD）。
If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is possible that a client will silently abandon one connection and then initiate another with the same parameters (e.g., after a reboot). This will appear to the server as a new handshake with epoch=0. In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake including delivering a verifiable Finished message. After a correct Finished message is received, the server MUST abandon the previous association to avoid confusion between two valid associations with overlapping epochs. The reachability requirement prevents off-path/blind attackers from destroying associations merely by sending forged ClientHellos.
DTLSクライアント/サーバーペアが、同じホスト/ポートカルテットで繰り返し接続が発生するように構成されている場合、クライアントが1つの接続を黙って破棄し、同じパラメータで別の接続を開始する可能性があります（たとえば、リブート）。これは、epoch = 0の新しいハンドシェイクとしてサーバーに表示されます。特定のホスト/ポートカルテットに既存の関連付けがあるとサーバーが判断し、epoch = 0 ClientHelloを受信した場合、新しいハンドシェイクを続行する必要がありますが、クライアントが到達可能性を示すまで、既存の関連付けを破棄してはなりません。 Cookieの交換、または検証可能な完了メッセージの配信を含む完全なハンドシェイクの完了。正しいFinishedメッセージが受信された後、サーバーは以前の関連付けを破棄して、エポックが重複する2つの有効な関連付けの混乱を回避する必要があります。到達可能性の要件は、偽造されたClientHelloを送信するだけでオフパス/ブラインド攻撃者がアソシエーションを破壊することを防ぎます。
This section includes specifications for the data structures that have changed between TLS 1.2 and DTLS 1.2. See [TLS12] for the definition of this syntax.
このセクションには、TLS 1.2とDTLS 1.2の間で変更されたデータ構造の仕様が含まれています。この構文の定義については、[TLS12]を参照してください。
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;
case aead: GenericAEADCipher; // New field
} 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..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; } ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>; } HelloVerifyRequest;
This document describes a variant of TLS 1.2; therefore, most of the security considerations are the same as those of TLS 1.2 [TLS12], described in Appendices D, E, and F.
このドキュメントでは、TLS 1.2のバリアントについて説明します。したがって、セキュリティに関する考慮事項のほとんどは、付録D、E、およびFで説明されているTLS 1.2 [TLS12]と同じです。
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 that do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers that 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交換が含まれています。ただし、このCookie交換を使用しない実装は、依然としてDoSに対して脆弱です。特に、Cookie交換を使用しないDTLSサーバーは、DoSが発生していない場合でも、攻撃増幅器として使用される可能性があります。したがって、DTLSサーバーは、増幅が環境での脅威ではないと考える正当な理由がない限り、Cookie交換を使用する必要があります（SHOULD）。クライアントは、すべてのハンドシェイクとのCookie交換を行う準備ができていなければなりません。
Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection. See Section 4.1.2.7 for details on this.
TLS実装とは異なり、DTLS実装は、接続を終了することによって無効なレコードに応答してはなりません（SHOULD NOT）。詳細については、セクション4.1.2.7を参照してください。
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. Peter Saint-Andre provided the list of changes in Section 8. Helpful comments on the document were also received from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Adrian Farrell, Joel Halpern, Ted Hardie, Charlia Kaufman, Pekka Savola, Allison Mankin, Nikos Mavrogiannopoulos, Alexey Melnikov, Robin Seggelmann, Michael Tuexen, Juho Vaha-Herttua, and Florian Weimer.
著者は、DTLSの設計に関する議論とコメントを提供してくれたDan Boneh、Eu-Jin Goh、Russ Housley、Constantine Sapuntzakis、およびHovav Shachamに感謝します。コメントを提供してくれたDTLS [DTLS]に関する最初のNDSS論文の匿名のNDSSレビューアに感謝します。また、多くのポイントを明確にするのに役立つフィードバックを提供してくれたSteve Kentに感謝します。 PMTUに関するセクションは、DCCP仕様[DCCP]から引用されました。 Pasi Eronenがこの仕様の詳細なレビューを提供しました。 Peter Saint-Andreは、セクション8で変更点のリストを提供しました。このドキュメントに関する有益なコメントは、Mark Allman、Jari Arkko、Mohamed Badra、Michael D'Errico、Adrian Farrell、Joel Halpern、Ted Hardie、Charlia Kaufman、Pekka Savolaからも受信されました、アリソン・マンキン、ニコス・マブロジアンノプロス、アレクセイ・メルニコフ、ロビン・セゲルマン、マイケル・テューセン、ジュホ・バハ・ヘルトゥア、フロリアン・ワイマー。
This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. IANA has modified all TLS parameter registries to add a DTLS-OK flag, indicating whether the specification may be used with DTLS. At the time of publication, all of the [TLS12] registrations except the following are suitable for DTLS. The full table of registrations is available at [IANA].
このドキュメントはTLS [TLS12]と同じ識別子スペースを使用するため、新しいIANAレジストリは必要ありません。 TLSに新しい識別子が割り当てられる場合、作成者はそれらがDTLSに適しているかどうかを指定する必要があります。 IANAはすべてのTLSパラメータレジストリを変更して、DTLS-OKフラグを追加し、仕様がDTLSで使用できるかどうかを示しています。公開時には、以下を除くすべての[TLS12]登録がDTLSに適しています。登録の完全な表は、[IANA]で入手できます。
From the TLS Cipher Suite Registry:
TLS Cipher Suiteレジストリから：
0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346] 0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC5246] 0x00,0x05 TLS_RSA_WITH_RC4_128_SHA [RFC5246] 0x00,0x17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346] 0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC5246] 0x00,0x05 TLS_RSA_WITH_RC4_128_SHA [RFC5246] 0x00,0x17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC5246] 0x00,0x20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712] 0x00,0x24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712] 0x00,0x28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712] 0x00,0x2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712] 0x00,0x8A TLS_PSK_WITH_RC4_128_SHA [RFC4279] 0x00,0x8E TLS_DHE_PSK_WITH_RC4_128_SHA [RFC4279] 0x00,0x92 TLS_RSA_PSK_WITH_RC4_128_SHA [RFC4279] 0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x16 TLS_ECDH_anon_WITH_RC4_128_SHA [RFC4492] 0xC0,0x33 TLS_ECDHE_PSK_WITH_RC4_128_SHA [RFC5489]
0x00,0x18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC5246] 0x00,0x20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712] 0x00,0x24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712] 0x00,0x28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712] 0x00,0x2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712] 0x00,0x8A TLS_PSK_WITH_RC4_128_SHA [RFC4279] 0x00,0x8E TLS_DHE_PSK_WITH_RC4_128_SHA [RFC4279]は0x00 、0x92 TLS_RSA_PSK_WITH_RC4_128_SHA [RFC4279] 0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA [RFC4492] 0xC0,0x16 TLS_ECDH_anon_WITH_RC4_128_SHA [RFC4492] 0xC0,0x33 TLS_ECDHE_PSK_WITH_RC4_128_SHA [RFC5489]
From the TLS Exporter Label Registry:
TLS Exporter Label Registryから：
client EAP encryption [RFC5216] ttls keying material [RFC5281] ttls challenge [RFC5281]
クライアントEAP暗号化[RFC5216] ttls鍵素材[RFC5281] ttlsチャレンジ[RFC5281]
This document defines a new handshake message, hello_verify_request, whose value has been allocated from the TLS HandshakeType registry defined in [TLS12]. The value "3" has been assigned by the IANA.
このドキュメントでは、新しいハンドシェイクメッセージhello_verify_requestを定義しています。その値は、[TLS12]で定義されているTLS HandshakeTypeレジストリから割り当てられています。値「3」はIANAによって割り当てられています。
This document reflects the following changes since DTLS 1.0 [DTLS1].
このドキュメントは、DTLS 1.0 [DTLS1]以降の次の変更を反映しています。
- Updated to match TLS 1.2 [TLS12].
- TLS 1.2 [TLS12]に一致するように更新されました。
- Addition of AEAD Ciphers in Section 4.1.2.3 (tracking changes in TLS 1.2.
- セクション4.1.2.3でのAEAD暗号の追加（TLS 1.2での変更の追跡。
- Clarifications regarding sequence numbers and epochs in Section 4.1 and a clear procedure for dealing with state loss in Section 4.2.8.
- セクション4.1のシーケンス番号とエポックに関する説明、およびセクション4.2.8の状態損失に対処するための明確な手順。
- Clarifications and more detailed rules regarding Path MTU issues in Section 4.1.1.1. Clarification of the fragmentation text throughout.
- セクション4.1.1.1のパスMTUの問題に関する説明と詳細ルール。全体の断片化テキストの明確化。
- Clarifications regarding handling of invalid records in Section 4.1.2.7.
- セクション4.1.2.7の無効なレコードの処理に関する説明。
- A new paragraph describing handling of invalid cookies at the end of Section 4.2.1.
- セクション4.2.1の最後にある無効なCookieの処理について説明する新しい段落。
- Some new text describing how to avoid handshake deadlock conditions at the end of Section 4.2.4.
- セクション4.2.4の終わりに、ハンドシェイクのデッドロック状態を回避する方法を説明するいくつかの新しいテキスト。
- Some new text about CertificateVerify messages in Section 4.2.6.
- セクション4.2.6のCertificateVerifyメッセージに関するいくつかの新しいテキスト。
- A prohibition on epoch wrapping in Section 4.1.
- セクション4.1でのエポックラッピングの禁止。
- Clarification of the IANA requirements and the explicit requirement for a new IANA registration flag for each parameter.
- IANA要件の明確化、および各パラメーターの新しいIANA登録フラグの明示的な要件。
- Added a record sequence number mirroring technique for handling repeated ClientHello messages.
- 繰り返されるClientHelloメッセージを処理するためのレコードシーケンス番号ミラーリング手法を追加しました。
- Recommend a fixed version number for HelloVerifyRequest.
- HelloVerifyRequestの固定バージョン番号を推奨します。
- Numerous editorial changes.
- 多数の編集上の変更。
[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月。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、2011年6月。
[RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
[RSAGCM] Salowey、J.、Choudhury、A。、およびD. McGrew、「AES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、2008年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS12] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[DCCP] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[DCCPDTLS] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[DCCPDTLS] Phelan、T。、「Datagram Congestion Control Protocol（DCCP）over Datagram Transport Layer Security（DTLS）over the Datagram Congestion Control Protocol（DCCP）」、RFC 5238、2008年5月。
[DTLS] Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
[DTLS] Modadugu、N。およびE. Rescorla、「データグラムTLSの設計と実装」、ISOC NDSS 2004の議事録、2004年2月。
[DTLS1] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS1] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[ECCGCM] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008.
[ECCGCM] Rescorla、E。、「SHA-256 / 384およびAES Galois Counter Mode（GCM）を使用したTLS楕円曲線暗号スイート」、RFC 5289、2008年8月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケントS。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[IANA] IANA, "Transport Layer Security (TLS) Parameters", http://www.iana.org/assignments/tls-parameters.
[IANA] IANA、「Transport Layer Security（TLS）Parameters」、http：//www.iana.org/assignments/tls-parameters。
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[IKEv2] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[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, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[写真] Karn、P。およびW. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP]マイヤーズ、J。およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、1996年5月。
[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。、シュルズリン、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] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[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 Version 1.1」、RFC 4346、2006年4月。
[WHYIPSEC] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[WHYIPSEC] Bellovin、S。、「IPsecバージョン2の使用を指定するためのガイドライン」、BCP 146、RFC 5406、2009年2月。
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
Eric Rescorla RTFM、Inc. 2064 Edgewood Drive Palo Alto、CA 94303
EMail: ekr@rtfm.com
メール：ekr@rtfm.com
Nagendra Modadugu Google, Inc.
Nagendra Modagu Google、Inc.
EMail: nagendra@cs.stanford.edu
メール：nagendra@cs.stanford.edu