RFC4347 日本語訳

4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu. April 2006. (Format: TXT=56014 bytes) (Status: PROPOSED STANDARD)

Network Working Group                                        E. Rescorla
Request for Comments: 4347                                    RTFM, Inc.
Category: Standards Track                                    N. Modadugu
                                                     Stanford University
                                                              April 2006

コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 4347年のRTFM Inc.カテゴリ: 標準化過程N.Modaduguスタンフォード大学2006年4月

                   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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice


   Copyright (C) The Internet Society (2006).




   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.

このドキュメントはデータグラムTransport Layer Security(DTLS)プロトコルのバージョン1.0を指定します。 DTLSプロトコルはコミュニケーションプライバシーをデータグラムプロトコルに提供します。 プロトコルで、クライアント/サーバ・アプリケーションは盗み聞くのを防ぐように設計されている道、改ざん、またはメッセージ偽造で伝えます。 DTLSプロトコルは、Transport Layer Security(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

1. 序論…2 1.1. 要件用語…3 2. 用法モデル…3 3. DTLSの概要…4 3.1. 損失神経の鈍いメッセージング…4 3.2. 信頼性を握手に提供します…4 3.2.1. パケットの損失…5 3.2.2. Reorderingします…5 3.2.3. メッセージサイズ…5 3.3. 検出を再演してください…6 4. TLSからの違い…6 4.1. 層を記録してください…6 4.1.1. 層のマッピングを輸送してください…7

Rescorla & Modadugu         Standards Track                     [Page 1]

RFC 4347           Datagram Transport Layer Security          April 2006


         PMTU Discovery .............................8
           4.1.2. Record Payload Protection ...........................9
         MAC ........................................9
         Null or Standard Stream Cipher .............9
         Block Cipher ..............................10
         New Cipher Suites .........................10
         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
         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 PMTU発見…8 4.1.2. 有効搭載量保護を記録してください…9 Mac…9 ヌルの、または、標準のストリーム暗号…9 暗号を妨げてください…10 新しい暗号スイート…10 反再生…10 4.2. DTLS握手プロトコル…11 4.2.1. サービス妨害対策…11 4.2.2. 握手メッセージ・フォーマット…13 4.2.3. メッセージの断片化とReassembly…15 4.2.4. タイムアウトとRetransmission…15 タイマ値…18 4.2.5. ChangeCipherSpec…19 4.2.6. メッセージを終えます…19 4.2.7. 警告メッセージ…19 4.3. 新しい構文の概要…19 4.3.1. 層を記録してください…20 4.3.2. 握手プロトコル…20 5. セキュリティ問題…21 6. 承認…22 7. IANA問題…22 8. 参照…22 8.1. 標準の参照…22 8.2. 有益な参照…23

1. Introduction

1. 序論

   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]はネットワークトラフィックを確保するためのプロトコルであると最も広く配布されます。 それはウェブトラフィックを保護して、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

しかしながら、過去数年間にわたってUDP輸送を使用する増加する数の応用層プロトコルが設計されています。 Session Initiationなどの特定のプロトコルでは、プロトコル(SIP)[SIP]と電子ゲーミングプロトコルはますますポピュラーです。 (SIPがTCPとUDPの両方をひくことができますが、UDPが望ましい状況があることに注意します。) 現在、これらのアプリケーションのデザイナーは多くの不十分な選択に直面しています。 まず最初に、彼らはIPsec[RFC2401]を使用できます。 しかしながら、[WHYIPSEC]で詳細な多くの理由で、これは単にいくつかのアプリケーションに適しています。 2番目に、彼らはカスタムアプリケーション層のセキュリティプロトコルを設計する場合があります。 例えば、SIPはS/MIMEのa部分集合を使用します。

Rescorla & Modadugu         Standards Track                     [Page 2]

RFC 4347           Datagram Transport Layer Security          April 2006


   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

トラフィックを保証してください。 残念ながら、応用層セキュリティプロトコルは一般に、優れたセキュリティ資産(例えば、S/MIMEの場合における終わりから終わりへのセキュリティ)を提供しますが、彼らは設計する取り組みの多量を通常必要とします--TLSの上にプロトコルを実行するのに必要である比較的少な量の取り組みと対照して。

   In many cases, the most desirable way to secure client/server
   applications would be to use TLS; however, the requirement for
   datagram semantics automatically prohibits use of TLS.  Thus, a
   datagram-compatible variant of TLS would be very desirable.  This
   memo describes such a protocol: Datagram Transport Layer Security
   (DTLS).  DTLS is deliberately designed to be as similar to TLS as
   possible, both to minimize new security invention and to maximize the
   amount of code and infrastructure reuse.

多くの場合、クライアント/サーバ・アプリケーションを保証する最も望ましい方法はTLSを使用するだろうことです。 しかしながら、データグラム意味論のための要件は自動的にTLSの使用を禁止します。 したがって、TLSのデータグラムコンパチブル異形は非常に望ましいでしょう。 このメモはそのようなプロトコルについて説明します: データグラムトランスポート層セキュリティ(DTLS)。 DTLSは、できるだけTLSと同様であり、ともに新しいセキュリティ発明を最小にして、コードとインフラストラクチャ再利用の量を最大にするように故意に設計されています。

1.1. Requirements Terminology

1.1. 要件用語

   In this document, the keywords "MUST", "MUST NOT", "REQUIRED",
   "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described
   in RFC 2119 [REQ].

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 「5月」はRFC2119[REQ]で説明されるように解釈されることになっているべきです。

2. Usage Model

2. 用法モデル

   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プロトコルが無くなっているか再規則正しいデータ通信量を補わないので。

Rescorla & Modadugu         Standards Track                     [Page 3]

RFC 4347           Datagram Transport Layer Security          April 2006


3. Overview of DTLS

3. 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:


      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.


3.1. Loss-Insensitive Messaging

3.1. 損失神経の鈍いメッセージング

   In TLS's traffic encryption layer (called the TLS Record Layer),
   records are not independent.  There are two kinds of inter-record

TLSのトラフィック暗号化層(TLS Record Layerと呼ばれる)の中では、記録は独立していません。 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から超能力[超能力]をよく、知っています: 明白な状態を記録に追加してください。 TLS1.1[TLS11]は既に明白なCBC状態をTLS記録に追加しています。 DTLSはそのメカニズムを借りて、明白な一連番号を加えます。

3.2. Providing Reliability for Handshake

3.2. 信頼性を握手に提供します。

   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

TLS握手は堅苦しい暗号の握手です。 定義されたオーダーにメッセージを送って、受け取らなければなりません、そして、いかなる他のオーダーも誤りです。 そして明確に、これが再命令と非互換である。

Rescorla & Modadugu         Standards Track                     [Page 4]

RFC 4347           Datagram Transport Layer Security          April 2006


   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握手メッセージはどんな与えられたデータグラムよりも潜在的に大きくて、その結果、断片化の問題を生じさせます。 DTLSはこれらの問題の両方にフィックスを提供しなければなりません。

3.2.1. Packet Loss

3.2.1. パケット損失

   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握手の第1段階を使用して、以下の図は基本概念を示します:

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

クライアントサーバ------ ------ ClientHello------>。

                              X<-- HelloVerifyRequest


      [Timer Expires]


      ClientHello           ------>


   Once the client has transmitted the ClientHello message, it expects
   to see a HelloVerifyRequest from the server.  However, if the
   server's message is lost the client knows that either the ClientHello
   or the HelloVerifyRequest has been lost and retransmits.  When the
   server receives the retransmission, it knows to retransmit.  The
   server also maintains a retransmission timer and retransmits when
   that timer expires.

クライアントがいったんClientHelloメッセージを送ると、それは、サーバからHelloVerifyRequestを見ると予想します。しかしながら、サーバのメッセージが無くなるなら、クライアントは、ClientHelloかHelloVerifyRequestのどちらかが失われて、再送するのを知っています。 サーバが「再-トランスミッション」を受けるとき、それは再送するのを知っています。 サーバは、また、再送信タイマーを維持して、そのタイマが期限が切れると、再送されます。

   Note: timeout and retransmission do not apply to the
   HelloVerifyRequest, because this requires creating state on the

以下に注意してください。 これが、サーバに状態を創設するのを必要とするので、タイムアウトと「再-トランスミッション」はHelloVerifyRequestに適用されません。

3.2.2. Reordering

3.2.2. Reorderingします。

   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

DTLSでは、特定の一連番号はその握手の中でそれぞれの握手メッセージに割り当てられます。 同輩が握手メッセージを受け取るとき、それは、そのメッセージが予想する次のメッセージであるかどうかすぐに決定できます。 あるなら、それはそれを処理します。 そうでなければ、いったん前のすべてのメッセージを受け取ると、それは将来の取り扱いのためにそれの列を作ります。

3.2.3. Message Size

3.2.3. メッセージサイズ

   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

TLSとDTLS握手メッセージはかなり大きい場合があります(理論上習慣多くのキロバイトにおける最大2^24-1バイト)。 対照的に、断片化が制限されないなら、UDPデータグラムは<にしばしば1500バイト制限されます。

Rescorla & Modadugu         Standards Track                     [Page 5]

RFC 4347           Datagram Transport Layer Security          April 2006


   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.

必要。 この制限を補うために、それぞれのDTLS握手メッセージはいくつかのDTLS記録の上で断片化されるかもしれません。 それぞれのDTLS握手メッセージは断片オフセットと断片の長さの両方を含んでいます。 したがって、握手メッセージのすべてのバイトの所有物の受取人はオリジナルの非断片化しているメッセージを組み立て直すことができます。

3.3. Replay Detection

3.3. 再生検出

   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/超能力、受信された記録のビットマップの窓を維持することによって、同じです。 窓をうまくはめ込むことができないくらい古い記録と以前に受け取られた記録は静かに捨てられます。 再生検出機能は任意です、パケット重複がいつも悪意があるというわけではありませんが、また、ルーティング誤りのため起こることができるので。 アプリケーションは、多分写しパケットを検出して、それに従って、それらのデータ伝送戦略を変更するかもしれません。

4. Differences from TLS

4. TLSからの違い

   As mentioned in Section 3, DTLS is intentionally very similar to TLS.
   Therefore, instead of presenting DTLS as a new protocol, we present
   it as a series of deltas from TLS 1.1 [TLS11].  Where we do not
   explicitly call out differences, DTLS is the same as in [TLS11].

セクション3で言及されるように、DTLSは故意にTLSと非常に同様です。 したがって、新しいプロトコルとしてDTLSを寄贈することの代わりに、私たちは一連のデルタとしてTLS1.1[TLS11]からそれを提示します。 私たちが明らかに違いを呼び出さないところでは、DTLSは[TLS11]と同じです。

4.1. Record Layer

4.1. 層を記録してください。

   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の記録的な層はTLS1.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;

struct ContentTypeタイプ; ProtocolVersionバージョン; uint16時代; //新しい分野uint48系列_番号; //新しい分野uint16の長さ; 不明瞭な断片[DTLSPlaintext.length];DTLSPlaintext。

       Equivalent to the type field in a TLS 1.1 record.


       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

バージョン、使われるプロトコルのバージョン。 このドキュメントはDTLSバージョン1.0について説明して、どれがバージョンを使用するか。254、255。 254.255のバージョン値はDTLSバージョン1.0の1の補数です。 TLSとDTLSバージョンの間のこの最大限度のスペース

Rescorla & Modadugu         Standards Track                     [Page 6]

RFC 4347           Datagram Transport Layer Security          April 2006


       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.)

数は、容易に2つのプロトコルからの記録を区別できるのを確実にします。 ワイヤのDTLSの将来のバージョン番号が値に縮小していることに注意されるべきです。(真のバージョン番号が値を増やしている間。)

       A counter value that is incremented on every cipher state


       The sequence number for this record.


       Identical to the length field in a TLS 1.1 record.  As in TLS
       1.1, the length should not exceed 2^14.

TLS1.1の長さの分野への長さのIdenticalは記録します。 TLS1.1のように、長さは2^14を超えるべきではありません。

       Identical to the fragment field of a TLS 1.1 record.


   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

DTLSは記録の系列_ナンバーフィールドで暗黙のものよりむしろ運ばれた明白な一連番号を使用します。 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実装では、これが問題であると予想してください。

4.1.1. Transport Layer Mapping

4.1.1. トランスポート層マッピング

   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断片化[ムガール人]を避けるために、DTLS実装SHOULDはMTUより小さくMTUを決定して、記録を送ります。 DTLS実装SHOULDはアプリケーションがPMTU(交互に1記録あたりのDTLSオーバーヘッドを引いたPMTUである最大のアプリケーションデータグラムサイズ)の値を決定する方法を提供します。 アプリケーションが、MTUより大きい記録を送るのを試みるなら、DTLS実装SHOULDはエラーを起こします、その結果、断片化されるパケットを送るのを避けます。

Rescorla & Modadugu         Standards Track                     [Page 7]

RFC 4347           Datagram Transport Layer Security          April 2006


   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

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

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.  In the future,
   a DTLS-DCCP mapping may be specified to provide optimal behavior for
   this interaction.

DCCPなどのいくつかの輸送がそれらの上まで運ばれたトラフィックのための輻輳制御を提供します。 混雑ウィンドウが十分細長いなら、DTLS握手「再-トランスミッション」はすぐに伝えられるよりむしろ持たれているかもしれません、潜在的にタイムアウトと偽物の「再-トランスミッション」に通じて。 DTLSがそのような輸送の上で使用されるとき、ありそうな混雑ウィンドウをオーバランさせないように注意するべきです。 将来、DTLS-DCCPマッピングは、この相互作用のための最適の振舞いを提供するために指定されるかもしれません。 PMTU Discovery PMTU発見

   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 SHOULD、パケットを送るのに使用されるインタフェースMTUから、初期化されてください。 DTLS実装が「必要である断片化とDFセット」Code(そうでなければ、データグラムToo Bigとして、知られている)と共にRFC1191[RFC1191]ICMP Destination Unreachableメッセージを受け取るなら、それはICMPメッセージで与えられたそれとPMTU見積りを減少させるべきです。 SHOULDが時折へのアプリケーションを許容するDTLS実装はPMTU見積りをリセットしました。 また、DTLS実装SHOULDはアプリケーションにDFビットの状態を制御させます。 これらのコントロールで、アプリケーションはPMTU発見を実行できます。 RFC1981[RFC1981]手順SHOULD、IPv6には、続かれてください。

Rescorla & Modadugu         Standards Track                     [Page 8]

RFC 4347           Datagram Transport Layer Security          April 2006


   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実装SHOULDがオフ握手パケットサイズを支持する接続を許す、セクション4.2で.4に説明されたbackoffを再送してください。 例えば、大きいパケットを送るなら、3が再送された後に握手層は、「再-トランスミッション」に関する握手メッセージを断片化するのを選ぶかもしれません。 一般に、保守的な初期のMTUの選択はこの問題を避けるでしょう。

4.1.2. Record Payload Protection

4.1.2. 有効搭載量保護を記録してください。

   Like TLS, DTLS transmits data as a series of protected records.  The
   rest of this section describes the details of that format.

TLSのように、DTLSは一連の保護された記録としてデータを送ります。 このセクションの残りはその形式の詳細について説明します。 MAC Mac

   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はTLS1.1のものと同じです。 しかしながら、MACを計算するのに使用される一連番号は、TLSの暗黙の一連番号を使用するよりむしろ、時代を連結することによって形成された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計算はプロトコルバージョン番号でparameterizedされます(DTLSの場合では、ワイヤの上のバージョン、すなわち、254、DTLS1.0のための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では、受信実装は、単に怒っている記録を捨てて、接続を続行するかもしれません。 TLS記録がそうであるというDTLS記録が方法で互いに依存していないので、この変化は可能です。

   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

一般に、DTLS実装SHOULDは悪いMACsと共にデータを静かに捨てます。 DTLS実装が、無効のMACと共にメッセージを受け取るとき、警戒を生成するのを選ぶなら、それは、レベルが致命的に悪い_が記録_mac警戒であると生成して、接続状態を終えなければなりません。 Null or Standard Stream Cipher ヌルの、または、標準のストリーム暗号

   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.

ちょうどTLS1.1NULLが解くようにDTLS NULL暗号は実行されます。

   The only stream cipher described in TLS 1.1 is RC4, which cannot be
   randomly accessed.  RC4 MUST NOT be used with DTLS.

TLS1.1で説明された唯一のストリーム暗号がRC4です。(手当たりしだいにそのRC4にアクセスできません)。 RC4 MUST NOT、DTLSと共に使用されてください。

Rescorla & Modadugu         Standards Track                     [Page 9]

RFC 4347           Datagram Transport Layer Security          April 2006

レスコラとModadugu規格はデータグラムトランスポート層セキュリティ2006年4月にRFC4347を追跡します[9ページ]。 Block Cipher ブロック暗号

   DTLS block cipher encryption and decryption are performed exactly as
   with TLS 1.1.

DTLSブロック暗号暗号化と復号化はちょうどTLS1.1のように実行されます。 New Cipher Suites 新しい暗号スイート

   Upon registration, new TLS cipher suites MUST indicate whether they
   are suitable for DTLS usage and what, if any, adaptations must be

登録、それらがDTLS用法と適合がどんなであるもそうしなければならないことに適しているか否かに関係なく、暗号スイートが示さなければならない新しいTLSでは、作られてください。 Anti-replay 反再生

   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記録は反復操作による保護を提供する一連番号を含んでいます。 一連番号検証SHOULDは使用することで実行されて、以下の滑りが手順に窓を付けるということであり、.3セクション3.4[RFC2402]から借りました。

   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.

セッションが確立されるとき、このセッションのための受信機パケットカウンタをゼロに初期化しなければなりません。 それぞれの受信された記録に関しては、受信機は、記録がこのセッションの寿命の間に受け取られたいかなる他の記録のSequence NumberもコピーしないSequence Numberを含むことを確かめなければなりません。 この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

写しは拒絶されて、滑りの使用で、窓に受信されているということです。 (窓がどう実装されるかは、地域にかかわる事柄ですが、以下のテキストは実装が示さなければならない機能性について説明します。) 32の最小のウィンドウサイズをサポートしなければなりませんが、64のウィンドウサイズが好まれる、SHOULD、デフォルトとして、使われてください。 別のウィンドウサイズ(最小限より大きい)は受信機によって選ばれるかもしれません。(受信機はウィンドウサイズについて送付者に通知しません。)

   The "right" edge of the window represents the highest validated
   Sequence Number value received on this session.  Records that contain
   Sequence Numbers lower than the "left" edge of the window are
   rejected.  Packets falling within the window are checked against a
   list of received packets within the window.  An efficient means for
   performing this check, based on the use of a bit mask, is described
   in Appendix C of [RFC 2401].

窓の「正しい」縁はこのセッションで最も高い有効にされたSequence Number対価領収を表します。 窓の「左」の縁より低いSequence民数記を含む記録が拒絶されます。 窓の中に落ちるパケットは窓の中で容認されたパケットのリストに対してチェックされます。 しばらくマスクの使用に基づくこのチェックを実行するための効率的な手段は[RFC2401]のAppendix 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検証が成功する場合にだけ、アップデートします。

Rescorla & Modadugu         Standards Track                    [Page 10]

RFC 4347           Datagram Transport Layer Security          April 2006


4.2. The DTLS Handshake Protocol

4.2. DTLS握手プロトコル

   DTLS uses all of the same handshake messages and flows as TLS, with
   three principal changes:


      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.


4.2.1. Denial of Service Countermeasures

4.2.1. サービス妨害対策

   Datagram security protocols are extremely susceptible to a variety of
   denial of service (DoS) attacks.  Two attacks are of particular

データグラムセキュリティプロトコルはサービス(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のかなり大きい場合があるCertificateメッセージ)を犠牲マシンに送ります、その結果、それをあふれさせます。

   In order to counter both of these attacks, DTLS borrows the stateless
   cookie technique used by Photuris [PHOTURIS] and IKE [IKE].  When the
   client sends its ClientHello message to the server, the server MAY
   respond with a HelloVerifyRequest message.  This message contains a
   stateless cookie generated using the technique of [PHOTURIS].  The
   client MUST retransmit the ClientHello with the cookie added.  The
   server then verifies the cookie and proceeds with the handshake only
   if it is valid.  This mechanism forces the attacker/client to be able
   to receive the cookie, which makes DoS attacks with spoofed IP
   addresses difficult.  This mechanism does not provide any defense
   against DoS attacks mounted from valid IP addresses.

これらの攻撃の両方を打ち返すために、DTLSはPhoturis[PHOTURIS]とIKE[IKE]によって使用された状態がないクッキーのテクニックを借ります。 クライアントがClientHelloメッセージをサーバに送るとき、サーバはHelloVerifyRequestメッセージで反応するかもしれません。 このメッセージは[PHOTURIS]のテクニックを使用することで生成された状態がないクッキーを含んでいます。 クッキーが加えられている状態で、クライアントはClientHelloを再送しなければなりません。 それが有効である場合にだけ、サーバは、次に、クッキーについて確かめて、握手を続けます。 このメカニズムは、攻撃者/クライアントがクッキーを受け取ることができるのを強制します。(クッキーはDoSを攻撃に偽造されたIPアドレスが難しい状態でします)。 このメカニズムは有効なIPアドレスから仕掛けられたDoS攻撃に対してどんなディフェンスも提供しません。

Rescorla & Modadugu         Standards Track                    [Page 11]

RFC 4347           Datagram Transport Layer Security          April 2006


   The exchange is shown below:


         Client                                   Server
         ------                                   ------
         ClientHello           ------>

クライアントサーバ------ ------ ClientHello------>。

                               <----- HelloVerifyRequest
                                      (contains cookie)

<。----- HelloVerifyRequest(クッキーを含んでいます)

         ClientHello           ------>
         (with cookie)


         [Rest of handshake]


   DTLS therefore modifies the ClientHello message to add the 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;

struct ProtocolVersionクライアント_バージョン; ; SessionIDセッション_イド;無作為の無作為の不透明なクッキー<0..32>; //新しい分野CipherSuite暗号_スイート<2..2^16-1>; CompressionMethod圧縮_メソッド<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野原は空の(ゼロ・レングス)に出られます。

   The definition of HelloVerifyRequest is as follows:


      struct {
        ProtocolVersion server_version;
        opaque cookie<0..32>;
      } HelloVerifyRequest;

struct ProtocolVersionサーバ_バージョン; 不透明なクッキー<0..32>;HelloVerifyRequest。

   The HelloVerifyRequest message type is hello_verify_request(3).


   The server_version field is defined as in TLS.


   When responding to a HelloVerifyRequest the client MUST use the same
   parameter values (version, random, session_id, cipher_suites,
   compression_method) as it did in the original ClientHello.  The
   server SHOULD use those values to generate its cookie and verify that
   they are correct upon cookie receipt.  The server MUST use the same
   version number in the HelloVerifyRequest that it would use when
   sending a ServerHello.  Upon receipt of the ServerHello, the client
   MUST verify that the server version values match.

HelloVerifyRequestに応じるとき、クライアントはそれとしての値(バージョン、無作為のセッション_イドは_スイートを解きます、圧縮_メソッド)がオリジナルのClientHelloでした同じパラメタを使用しなければなりません。 サーバSHOULDは、クッキーを生成して、それらがクッキー領収書で正しいことを確かめるのにそれらの値を使用します。 サーバはServerHelloを送るときそれが使用するHelloVerifyRequestで同じバージョン番号を使用しなければなりません。 ServerHelloを受け取り次第、クライアントは、サーババージョン値が合っていることを確かめなければなりません。

Rescorla & Modadugu         Standards Track                    [Page 12]

RFC 4347           Datagram Transport Layer Security          April 2006


   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サーバSHOULDはサーバでどんな属国も保有しないでそれらについて確かめることができるような方法でクッキーを生成します。1つのテクニックは、手当たりしだいに発生している秘密を持って、以下としてクッキーを生成することです。 クッキー=HMAC(秘密、クライアントIP、クライアントパラメタ)

   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.


   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つの起こり得るかもしれない攻撃は、攻撃者が異なったアドレスから多くのクッキーを集めて、次に、サーバを攻撃するためにそれらを再利用することです。サーバは頻繁にSecret値を変えることによって、この攻撃に対して防御されることができます、その結果、それらのクッキーを無効にします。 サーバが、正統のクライアントが変遷で握手にできることを願うなら(例えば、彼らは、Secret1と共にクッキーを受けて、次に、サーバがSecret2に変化した後に第2ClientHelloを送りました)、サーバはそれが両方の秘密を受け入れる限られた窓を持つことができます。 [IKEv2]は、本件を検出するためにバージョン番号をクッキーに加えるのを示します。 代替的アプローチは両方の秘密で単に確かめてみることです。

   DTLS servers SHOULD perform a cookie exchange whenever a new
   handshake is being performed.  If the server is being operated in an
   environment where amplification is not a problem, the server MAY be
   configured not to perform a cookie exchange.  The default SHOULD be
   that the exchange is performed, however.  In addition, the server MAY
   choose not to do a cookie exchange when a session is resumed.
   Clients MUST be prepared to do a cookie exchange with every

新しい握手が実行されているときはいつも、DTLSサーバSHOULDはクッキー交換を実行します。 サーバが増幅が問題でない環境で操作されているなら、サーバは、クッキー交換を実行しないように構成されるかもしれません。 しかしながら、交換が実行されるということになってください。デフォルトSHOULD、さらに、サーバは、セッションが再開されるとき、クッキー交換をしないのを選んでもよいです。 クライアントはあらゆる握手によるクッキー交換をする用意ができていなければなりません。

   If HelloVerifyRequest is used, the initial ClientHello and
   HelloVerifyRequest are not included in the calculation of the
   verify_data for the Finished message.


4.2.2. Handshake Message Format

4.2.2. 握手メッセージ・フォーマット

   In order to support message loss, reordering, and fragmentation, DTLS
   modifies the TLS 1.1 handshake header:


      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;

struct、seqに、//新しい分野uint24断片_が相殺されたというHandshakeType msg_タイプ; uint24の長さ; uint16メッセージ_; //新しい分野uint24の断片_長さ; //新しい分野の選んだ(HandshakeType)、_要求: こんにちは、HelloRequestをケースに入れてください; _: こんにちは、ケースクライアントClientHello

Rescorla & Modadugu         Standards Track                    [Page 13]

RFC 4347           Datagram Transport Layer Security          April 2006


          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;

ケース、こんにちは、__要求について確かめてください: HelloVerifyRequest。 //新しいタイプがサーバ_をケースに入れる、こんにちは: ServerHello。 証明書をケースに入れてください: 証明書 サーバの_の主要な_交換をケースに入れてください: ServerKeyExchange。 証明書_要求をケースに入れてください: CertificateRequest。 _行われた_: こんにちは、サーバServerHelloDoneをケースに入れてください。 ケース証明書_は以下について確かめます。 CertificateVerify。 クライアントの_の主要な_交換をケースに入れてください: ClientKeyExchange。 ケースは終わりました: 終わっています。 ボディー。 } 握手。

   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:

それぞれの側が各握手で送る最初のメッセージはいつもメッセージ_seq=0を持っています。 それぞれの新しいメッセージが発生しているときはいつも、メッセージ_seq値は1つ増加されます。 メッセージが再送されるとき、同じメッセージ_seq値は使用されています。 例えば:

      Client                             Server
      ------                             ------
      ClientHello (seq=0)  ------>

クライアントサーバ------ ------ ClientHello(seq=0)------>。

                              X<-- HelloVerifyRequest (seq=0)


      [Timer Expires]


      ClientHello (seq=0)  ------>


                           <------ HelloVerifyRequest (seq=0)

<。------ HelloVerifyRequest(seq=0)

      ClientHello (seq=1)  ------>
      (with cookie)


                           <------        ServerHello (seq=1)
                           <------        Certificate (seq=2)
                           <------    ServerHelloDone (seq=3)

<。------ ServerHello(seq=1)<。------ 証明書(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_数の値があるでしょう。

   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

実装が次の_であることを支持する(少なくとも概念的です)DTLSは_seqカウンタを受けます。 このカウンタは初めは、ゼロに設定されます。 次の一連番号マッチ_が_seqを受けるならメッセージが受信されていて、次の_が_増加されたseqを受けて、メッセージが受けるとき

Rescorla & Modadugu         Standards Track                    [Page 14]

RFC 4347           Datagram Transport Layer Security          April 2006


   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).

処理にされる。 一連番号が次の_以下が_seqを受けるということであるなら、メッセージを捨てなければなりません。 一連番号が次の_が_seqを受けるより大きいなら、実装SHOULDはメッセージを列に並ばせますが、それを捨てるかもしれません。 (これは簡単なスペース/帯域幅見返りです。)

4.2.3. Message Fragmentation and Reassembly

4.2.3. メッセージ断片化とReassembly

   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隣接のデータ範囲に分割します。 これらの範囲は、最大の握手断片サイズより大きいはずがなく、共同で全体の握手メッセージを含まなければなりません。 SHOULD NOTが重ね合わせる範囲。 そして、送付者はすべてオリジナルの握手メッセージと同じメッセージ_seq値でN握手メッセージを作成します。 それぞれの新しいメッセージは断片_オフセット(前の断片に含まれたバイト数)と断片_の長さ(この断片の長さ)でラベルされます。 すべてのメッセージの長さの分野はオリジナルのメッセージの長さの分野と同じです。 非断片化しているメッセージは断片_オフセット=0がある堕落したケースです、そして、断片_長さは長さと等しいです。

   When a DTLS implementation receives a handshake message fragment, it
   MUST buffer it until it has the entire handshake message.  DTLS
   implementations MUST be able to handle overlapping fragment ranges.
   This allows senders to retransmit handshake messages with smaller
   fragment sizes during path MTU discovery.

DTLS実装が握手メッセージ断片を受けるとき、全体の握手メッセージがあるまで、それはそれをバッファリングしなければなりません。 DTLS実装は重なっている断片範囲を扱うことができなければなりません。 これで、送付者は経路MTU探索の間、より小さい断片サイズで握手メッセージを再送できます。

   Note that as with TLS, multiple handshake messages may be placed in
   the same DTLS record, provided that there is room and that they are
   part of the same flight.  Thus, there are two acceptable ways to pack
   two DTLS messages into the same datagram: in the same record or in
   separate records.

複数の握手メッセージがTLSなら、余地があれば同じDTLS記録に置かれるかもしれなくて、彼らが同じ飛行の一部であることに注意してください。 したがって、2つのDTLSメッセージに同じデータグラムに詰め込む2つの許容できる方法があります: 同じ記録か別々の記録で。

4.2.4. Timeout and Retransmission

4.2.4. タイムアウトとRetransmission

   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メッセージは一連のメッセージ飛行に分類されます。 メッセージの各飛行は多くのメッセージから成るかもしれませんが、それらはタイムアウトと「再-トランスミッション」の目的のために一枚岩的であるとして見なされるべきです。

Rescorla & Modadugu         Standards Track                    [Page 15]

RFC 4347           Datagram Transport Layer Security          April 2006


    Client                                          Server
    ------                                          ------

クライアントサーバ------ ------

    ClientHello             -------->                           Flight 1


                            <-------    HelloVerifyRequest      Flight 2

<。------- 第2HelloVerifyRequest便

   ClientHello              -------->                           Flight 3


                                               ServerHello    \
                                              Certificate*     \
                                        ServerKeyExchange*      Flight 4
                                       CertificateRequest*     /
                            <--------      ServerHelloDone    /

第4ServerKeyExchange*便 ServerHello\証明書*\CertificateRequest*/<。-------- ServerHelloDone/

    Certificate*                                              \
    ClientKeyExchange                                          \
    CertificateVerify*                                          Flight 5
    [ChangeCipherSpec]                                         /
    Finished                -------->                         /


                                        [ChangeCipherSpec]    \ Flight 6
                            <--------             Finished    /

第6[ChangeCipherSpec]\便 <。-------- 終わっている/

          Figure 1. Message flights for full handshake

図1。 完全な握手へのメッセージフライト

    Client                                           Server
    ------                                           ------

クライアントサーバ------ ------

    ClientHello             -------->                          Flight 1


                                               ServerHello    \
                                        [ChangeCipherSpec]     Flight 2
                             <--------             Finished    /

第2ServerHello\[ChangeCipherSpec]便 <。-------- 終わっている/

    [ChangeCipherSpec]                                         \Flight 3
    Finished                 -------->                         /


   Figure 2. Message flights for session-resuming handshake
                           (no cookie exchange)

図2。 セッションを再開する握手へのメッセージフライト(クッキー交換がありません)

   DTLS uses a simple timeout and retransmission scheme with the
   following state machine.  Because DTLS clients send the first message
   (ClientHello), they start in the PREPARING state.  DTLS servers start
   in the WAITING state, but with empty buffers and no retransmit timer.

DTLSは以下の州のマシンがある簡単なタイムアウトと「再-トランスミッション」体系を使用します。 DTLSクライアントが最初のメッセージ(ClientHello)を送るので、彼らはPREPARING状態で始まります。 DTLSサーバはWAITING状態にもかかわらず、空のバッファにもかかわらず、どんな再送信タイマからも始まりません。

Rescorla & Modadugu         Standards Track                    [Page 16]

RFC 4347           Datagram Transport Layer Security          April 2006


                   | 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  | -------------------------------+
         |           |

+-----------+ | 準備| +--->|、| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | +-----------+ | | | | | | | | | 次の飛行をバッファリングしてください。| | | | | \|/ | | +-----------+ | | | | | | | 発信します。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | | 発信してください。| +-----------+ | | HelloRequestは受信します。| | | | 次へ| | 飛行を送ってください。| | または、飛行| +--------+ | | | | | 再送信タイマを設定してください。| | 受信してください。| | \|/ | | HelloRequest| | +-----------+ | | 発信してください。| | | | | | ClientHello+--、)、--| 待ち|-------------------+ | | | | | タイマは期限が切れます。| | | | +-----------+ | | | | | | | | | | | | | | +------------------------+ | | | 読まれて、再送してください。| 受信してください。| | | 最終| | | 飛行| | | | | | \|/\|/ | | +-----------+ | | | | | 終わっています。| -------------------------------+ | | +-----------+

        Figure 3. DTLS timeout and retransmission state machine

図3。 タイムアウトと「再-トランスミッション」州が機械加工するDTLS

   The state machine has three basic states.


Rescorla & Modadugu         Standards Track                    [Page 17]

RFC 4347           Datagram Transport Layer Security          April 2006


   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状態に入力します。 または、実装が、より多くのメッセージを受け取ると予想するなら、それは、再送信タイマを設定して、次に、WAITING状態に入れます。

   There are three ways to exit the WAITING state:


      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

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)を送るので、彼らはPREPARING状態で始まります。 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.

サーバが再握手を望んでいるとき、それは、HelloRequestを伝えるためにFINISHED状態からPREPARING状態に移行します。 クライアントがHelloRequestを受け取るとき、それは、ClientHelloを伝えるためにFINISHEDからPREPARINGに移行します。 Timer Values タイマ値

   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

タイマ値は実装の選択ですが、タイマを誤って扱うのは重大な混雑問題を引き起こすことができます。 例えば、多くが早くDTLSタイムアウトについて例証して、あまりにすばやく再送する、混雑しているリンク。 実装SHOULDは初期のタイマ値を使用します。

Rescorla & Modadugu         Standards Track                    [Page 18]

RFC 4347           Datagram Transport Layer Security          April 2006


   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.

1秒(RFC2988[RFC2988]で定義された最小限)と少なくとも60秒のRFC2988最大までの各「再-トランスミッション」の値の二重について。 私たちが時間敏感なアプリケーションのために潜在を改良するために3秒のRFC2988デフォルトよりむしろ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.

値がどの時に初期の値にリセットされるかもしれないかとき損失のないトランスミッションが起こるまで、実装SHOULDは現在のタイマ値を保有します。 長期の怠惰の後に、少なくとも現在のタイマ値の10倍、実装は初期の値にタイマをリセットするかもしれません。 これが起こるかもしれない1つの状況が再握手がかなりのデータ転送の後に使用される時です。

4.2.5. ChangeCipherSpec

4.2.5. ChangeCipherSpec

   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


4.2.6. Finished Messages

4.2.6. 終わっているメッセージ

   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のようにあります。 しかしながら、感度を断片化に移すために、まるでただ一つの断片としてそれぞれの握手メッセージを送ったかのようにFinished Macを計算しなければなりません。 クッキー交換が使用されている場合では、Finished MACに初期のClientHelloとHelloVerifyRequestを含んではいけないことに注意してください。

4.2.7. Alert Messages

4.2.7. 警告メッセージ

   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.

握手の文脈に起こったら、Alertメッセージが全く再送されないことに注意してください。 しかしながら、再び(例えば、再送された握手メッセージとして)SHOULDが怒っている記録であるなら新しい警告メッセージを生成するDTLS実装を受け取ります。 実装SHOULDは同輩がいつ悪いメッセージを持続して送るかを検出して、そのような不正行為が検出された後に市内接続状態を終えます。

4.3. Summary of new syntax

4.3. 新しい構文の概要

   This section includes specifications for the data structures that
   have changed between TLS 1.1 and DTLS.


Rescorla & Modadugu         Standards Track                    [Page 19]

RFC 4347           Datagram Transport Layer Security          April 2006


4.3.1. Record Layer

4.3.1. 層を記録してください。

      struct {
        ContentType type;
        ProtocolVersion version;
        uint16 epoch;                                     // New field
        uint48 sequence_number;                           // New field
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
      } DTLSPlaintext;

struct ContentTypeタイプ; ProtocolVersionバージョン; uint16時代; //新しい分野uint48系列_番号; //新しい分野uint16の長さ; 不明瞭な断片[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タイプ; ProtocolVersionバージョン; uint16時代; //新しい分野uint48系列_番号; //新しい分野uint16の長さ; 不明瞭な断片[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;

ContentTypeはuint16時代; _番号(//新しい分野uint16の長さ)が選択する//新しい分野uint48系列をタイプします; ProtocolVersionバージョン;。struct、(CipherSpec.cipher_はタイプされます) ブロックをケースに入れてください: GenericBlockCipher、断片化してください;、DTLSCiphertext。

4.3.2. Handshake Protocol

4.3.2. 握手プロトコル

      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

struct、seqに、//新しい分野uint24断片_が相殺されたというHandshakeType msg_タイプ; uint24の長さ; uint16メッセージ_; //新しい分野uint24の断片_長さ; //新しい分野

Rescorla & Modadugu         Standards Track                    [Page 20]

RFC 4347           Datagram Transport Layer Security          April 2006


        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;

__要求について確かめてください: HelloVerifyRequest。(HandshakeType)を選択してください、_要求: こんにちは、HelloRequestをケースに入れてください; : こんにちは、ClientHello_: (こんにちは、ケースサーバServerHello)がケースに入れるクライアント_をケースに入れてください、こんにちは、//新しい分野ケース証明書: 証明書; ケースサーバ_キー_交換: ServerKeyExchange; ケース証明書_要求: CertificateRequest; _行われた_: こんにちは、サーバServerHelloDoneをケースに入れてください; _が確かめる証明書をケースに入れてください: CertificateVerify; ケースクライアント_キー_交換: ClientKeyExchange; ケースは終わりました: 終わっています;、ボディー。 } 握手。

      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クライアント_バージョン; ; SessionIDセッション_イド;無作為の無作為の不透明なクッキー<0..32>; //新しい分野CipherSuite暗号_スイート<2..2^16-1>; CompressionMethod圧縮_メソッド<1..2^8-1>;ClientHello。

      struct {
        ProtocolVersion server_version;
        opaque cookie<0..32>;
      } HelloVerifyRequest;

struct ProtocolVersionサーバ_バージョン; 不透明なクッキー<0..32>;HelloVerifyRequest。

5. Security Considerations

5. セキュリティ問題

   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.

このドキュメントはTLS1.1の異形について説明します、そして、したがって、セキュリティ問題の大部分はAppendices D、E、およびFで説明されたTLS1.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はサービスの否定から守るように設計されたクッキー交換を含んでいます。 しかしながら、このクッキー交換を使用しない実装はまだDoSに被害を受け易いです。 DoSを経験していなくても、特に、クッキー交換を使用しないDTLSサーバは攻撃アンプとして使用されるかもしれません。 したがって、増幅が脅威でないと信じるために彼らの環境でもっともな理由がない場合、DTLSサーバSHOULDはクッキー交換を使用します。 クライアントはあらゆる握手によるクッキー交換をする用意ができていなければなりません。

Rescorla & Modadugu         Standards Track                    [Page 21]

RFC 4347           Datagram Transport Layer Security          April 2006


6. Acknowledgements

6. 承認

   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

作者はDTLSのデザインの議論とコメントについてダンBoneh、ユー-チン・ゴー、ラスHousley、コンスタンティーヌSapuntzakis、およびHovav Shachamに感謝したがっています。 彼らのコメントをDTLS[DTLS]に関する私たちのオリジナルのNDSS紙の匿名のNDSS評論家をありがとうございます。 また、助けたフィードバックのためのスティーブ・ケントへの感謝は多くのポイントはっきりさせます。 PMTUの上のセクションはDCCP仕様[DCCP]から盗用されました。 パシEronenはこの仕様の詳細なレビューを提供しました。 また、マーク・オールマン、ヤリArkko、ジョエル・アルペルン、テッド・ハーディー、およびアリソン・マンキンからドキュメントにおける役に立つコメントを受けました。

7. IANA Considerations

7. IANA問題

   This document uses the same identifier space as TLS [TLS11], so no
   new IANA registries are required.  When new identifiers are assigned
   for TLS, authors MUST specify whether they are suitable for DTLS.

このドキュメントがTLS[TLS11]と同じ識別子スペースを使用するので、どんな新しいIANA登録も必要ではありません。 新しい識別子がTLSのために割り当てられるとき、作者は、彼らがDTLSに適当であるかどうか指定しなければなりません。

   This document defines a new handshake message, hello_verify_request,
   whose value has been allocated from the TLS HandshakeType registry
   defined in [TLS11].  The value "3" has been assigned by the IANA.

このドキュメントが新しい握手メッセージを定義する、こんにちは。_値が[TLS11]で定義されたTLS HandshakeType登録から割り当てられた_要求について確かめてください。 「3インチはIANAによって割り当てられた」値。

8. References

8. 参照

8.1. Normative References

8.1. 引用規格

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, November 2000.

[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。

   [TCP]      Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

Rescorla & Modadugu         Standards Track                    [Page 22]

RFC 4347           Datagram Transport Layer Security          April 2006


8.2. Informative References

8.2. 有益な参照

   [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES"

[AESCACHE]バーンスタイン、D.J.、「AESに対するキャッシュタイミング攻撃」 http://cr.yp.to/antiforgery/cachetiming-20050414.pdf 。

   [AH]       Kent, S. and R. Atkinson, "IP Authentication Header", RFC
              2402, November 1998.

[ああ] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。

   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
              Congestion Control Protocol", Work in Progress, 10 March

[DCCP] コーラー、E.、ハンドレー、M.、フロイド、S.、Padhye、J.、「データグラム混雑制御プロトコル」が進歩、2005年3月10日に働いています。

   [DNS]      Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.


   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
              of Datagram TLS", Proceedings of ISOC NDSS 2004, February

[DTLS]Modadugu、N.、レスコラ、E.、「データグラムTLSの設計と実装」、ISOC NDSS2004、2004年2月の議事。

   [ESP]      Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998.

[超能力] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。

   [IKE]      Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
              December 2005.


              4rev1", RFC 3501, March 2003.

[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
              Messages", RFC 2521, March 1999.


   [POP]      Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

[飛び出します] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」

   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[REQ] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [SCTP]     Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

[SCTP] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン

Rescorla & Modadugu         Standards Track                    [Page 23]

RFC 4347           Datagram Transport Layer Security          April 2006


   [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.

[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
              Work in Progress, October 2003.


Authors' Addresses


   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA 94303

エリックレスコラRTFM Inc.2064Edgewood Driveパロアルト、カリフォルニア 94303

   EMail: ekr@rtfm.com

メール: ekr@rtfm.com

   Nagendra Modadugu
   Computer Science Department
   Stanford University
   353 Serra Mall
   Stanford, CA 94305

Nagendra Modaduguコンピュータサイエンス部のスタンフォード大学353のセラ・Mallスタンフォード、カリフォルニア 94305

   EMail: nagendra@cs.stanford.edu

メール: nagendra@cs.stanford.edu

Rescorla & Modadugu         Standards Track                    [Page 24]

RFC 4347           Datagram Transport Layer Security          April 2006


Full Copyright Statement


   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.


   This document and the information contained herein are provided on an


Intellectual Property


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。



   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Rescorla & Modadugu         Standards Track                    [Page 25]




 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200