RFC5238 日本語訳

Network Working Group                                         T. Phelan
Request for Comments: 5238                               Sonus Networks
Category: Standards Track                                      May 2008

コメントを求めるワーキンググループT.フェラン要求をネットワークでつないでください: 5238Sonusはカテゴリをネットワークでつなぎます: 標準化過程2008年5月

       Datagram Transport Layer Security (DTLS) over the Datagram
                   Congestion Control Protocol (DCCP)

データグラム混雑制御プロトコルの上のデータグラムトランスポート層セキュリティ(DTLS)(DCCP)

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)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   This document specifies the use of Datagram Transport Layer Security
   (DTLS) over the Datagram Congestion Control Protocol (DCCP).  DTLS
   provides communications privacy for applications that use datagram
   transport protocols and allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping and
   detect tampering or message forgery.  DCCP is a transport protocol
   that provides a congestion-controlled unreliable datagram service.

このドキュメントはデータグラムCongestion Controlプロトコル(DCCP)の上でデータグラムTransport Layer Security(DTLS)の使用を指定します。 DTLSは、盗み聞くのを防いで、改ざんかメッセージ偽造を検出するためにデータグラムトランスポート・プロトコルを使用するアプリケーションにコミュニケーションプライバシーを前提として、クライアント/サーバ・アプリケーションが設計されている方法で伝えるのを許容します。 DCCPは混雑で制御された頼り無いデータグラムサービスを提供するトランスポート・プロトコルです。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. DTLS over DCCP ..................................................2
      3.1. DCCP and DTLS Sequence Numbers .............................3
      3.2. DCCP and DTLS Connection Handshakes ........................3
      3.3. Effects of DCCP Congestion Control .........................4
      3.4. Relationships between DTLS Sessions/Connections and DCCP
           Connections ................................................5
      3.5. PMTU Discovery .............................................6
      3.6. DCCP Service Codes .........................................7
      3.7. New Versions of DTLS .......................................8
   4. Security Considerations .........................................8
   5. Acknowledgments .................................................8
   6. References ......................................................9
      6.1. Normative References .......................................9
      6.2. Informative References .....................................9

1. 序論…2 2. 用語…2 3. DCCPの上のDTLS…2 3.1. DCCPとDTLS一連番号…3 3.2. DCCPとDTLS接続握手…3 3.3. DCCP混雑の効果は制御されます…4 3.4. DTLSセッション/コネクションズとDCCPコネクションズとの関係…5 3.5. PMTU発見…6 3.6. DCCPはコードを修理します…7 3.7. DTLSの新しいバージョン…8 4. セキュリティ問題…8 5. 承認…8 6. 参照…9 6.1. 標準の参照…9 6.2. 有益な参照…9

Phelan                      Standards Track                     [Page 1]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[1ページ]。

1.  Introduction

1. 序論

   This document specifies how to carry application payloads with
   Datagram Transport Layer Security (DTLS), as specified in [RFC4347],
   in the Datagram Congestion Control Protocol (DCCP), as specified in
   [RFC4340].

このドキュメントは[RFC4347]、データグラムCongestion Controlプロトコル(DCCP)でデータグラムTransport Layer Security(DTLS)と共に指定されるとしてアプリケーションペイロードを運ぶ方法を指定します、[RFC4340]で指定されるように。

   DTLS is an adaptation of Transport Layer Security (TLS, [RFC4346])
   that modifies TLS for use with the unreliable transport protocol UDP.
   TLS is a protocol that allows client/server applications to
   communicate in a way that is designed to prevent eavesdropping and
   detect tampering and message forgery.  DTLS can be viewed as
   TLS-plus-adaptations-for-unreliability.

DTLSは頼り無いトランスポート・プロトコルUDPとの使用のためにTLSを変更するTransport Layer Security(TLS、[RFC4346])の適合です。 TLSはクライアント/サーバ・アプリケーションが盗み聞くのを防いで、改ざんを検出するように設計されている道とメッセージ偽造で伝えるプロトコルです。 非信頼性へのTLSと適合としてDTLSを見なすことができます。

   DCCP provides an unreliable transport service, similar to UDP, but
   with adaptive congestion control, similar to TCP and Stream Control
   Transmission Protocol (SCTP).  DCCP can be viewed equally well as
   either UDP-plus-congestion-control or TCP-minus-reliability
   (although, unlike TCP, DCCP offers multiple congestion control
   algorithms).

DCCPは頼り無い輸送サービスを提供します、UDPと同様ですが、適応型の混雑で制御してください、TCPとStream Control Transmissionプロトコル(SCTP)と同様です。 UDPと輻輳制御か信頼性を引いたTCPのどちらかとして等しく上手にDCCPを見なすことができます(DCCPはTCPと異なって複数の輻輳制御アルゴリズムを提供しますが)。

   The combination of DTLS and DCCP will offer transport security
   capabilities to applications using DCCP similar to those available
   for TCP, UDP, and SCTP.

DTLSとDCCPの組み合わせは、TCP、UDP、およびSCTPに利用可能なそれらと同様のDCCPを使用することで輸送セキュリティ能力をアプリケーションに提供するでしょう。

2.  Terminology

2. 用語

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

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

3.  DTLS over DCCP

3. DCCPの上のDTLS

   The approach here is very straightforward -- DTLS records are
   transmitted in the Application Data fields of DCCP-Data and
   DCCP-DataAck packets (in the rest of the document assume that
   "DCCP-Data packet" means "DCCP-Data or DCCP-DataAck packet").
   Multiple DTLS records MAY be sent in one DCCP-Data packet, as long as
   the resulting packet is within the Path Maximum Transfer Unit (PMTU)
   currently in force for normal data packets, if fragmentation is not
   allowed (the Don't Fragment (DF) bit is set for IPv4 or no
   fragmentation extension headers are being used for IPv6), or within
   the current DCCP maximum packet size if fragmentation is allowed (see
   Section 3.5 for more information on PMTU Discovery).  A single DTLS
   record MUST be fully contained in a single DCCP-Data packet; it MUST
   NOT be split over multiple packets.

ここでのアプローチは非常に簡単です--DTLS記録はDCCP-データとDCCP-DataAckパケットのApplication Data分野で伝えられます(ドキュメントの残りでは、「DCCP-データ・パケット」が「DCCP-データかDCCP-DataAckパケット」を意味すると仮定してください)。 1つのDCCP-データ・パケットで複数のDTLS記録を送るかもしれません、現在、Path Maximum Transfer Unit(PMTU)の中に結果として起こるパケットが正常なデータ・パケットのために大挙してある限り、断片化が許されていないか(どんなFragment(DF)も噛み付かなかったドンがIPv4に用意ができているか、または断片化拡張ヘッダーは全くIPv6に使用されていません)、または最大のパケットサイズが断片化であるなら現在のDCCPの中に許容されているなら(PMTUディスカバリーの詳しい情報に関してセクション3.5を見てください)。 単一のDCCP-データ・パケットにただ一つのDTLS記録を完全に含まなければなりません。 複数のパケットの上でそれを分けてはいけません。

Phelan                      Standards Track                     [Page 2]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[2ページ]。

3.1.  DCCP and DTLS Sequence Numbers

3.1. DCCPとDTLS一連番号

   Both DCCP and DTLS use sequence numbers in their packets/records.
   These sequence numbers serve somewhat, but not completely,
   overlapping functions.  Consequently, there is no connection between
   the sequence number of a DCCP packet and the sequence number in a
   DTLS record contained in that packet, and there is no connection
   between sequence number-related features such as DCCP synchronization
   and DTLS anti-replay protection.

DCCPとDTLSの両方がそれらのパケット/記録で一連番号を使用します。 機能を重ね合わせて、これらの一連番号は、いくらか役立ちますが、完全に役立つというわけではありません。 その結果、そのパケットに含まれたDTLS記録にはDCCPパケットの一連番号と一連番号との関係が全くありません、そして、DCCP同期やDTLS反反復操作による保護などの一連番号関連の特徴の間には、接続が全くありません。

3.2.  DCCP and DTLS Connection Handshakes

3.2. DCCPとDTLS接続握手

   Unlike UDP, DCCP is connection-oriented, and has a connection
   handshake procedure that precedes the transmission of DCCP-Data and
   DCCP-DataAck packets.  DTLS is also connection-oriented, and has a
   handshake procedure of its own that must precede the transmission of
   actual application information.  Using the rule of mapping DTLS
   records to DCCP-Data and DCCP-DataAck packets in Section 3, above,
   the two handshakes are forced to happen in series, with the DCCP
   handshake first, followed by the DTLS handshake.  This is how TLS
   over TCP works.

UDPと異なって、DCCPは接続指向であり、DCCP-データの伝達に先行する接続握手手順とDCCP-DataAckパケットを持っています。 DTLSはまた、接続指向であり、本番適用情報の伝達に先行しなければならないそれ自身の握手手順を持っています。 セクション3でDCCP-データへのDTLS記録とDCCP-DataAckパケットを写像する規則を使用して、上では、2つの握手が最初にDCCP握手でやむを得ず連続的に起こります、DTLS握手があとに続いていて。 これはTCPの上のTLSがどう働いているかということです。

   However, the DCCP handshake packets DCCP-Request and DCCP-Response
   have Application Data fields and can carry user data during the DCCP
   handshake, and this creates the opportunity to perform the handshakes
   partially in parallel.  DTLS client implementations MAY choose to
   transmit one or more DTLS records (typically containing DTLS
   handshake messages or parts of them) in the DCCP-Request packet.  A
   DTLS server implementation MAY choose to process these records as
   usual, and if it has one or more DTLS records to send as a response
   (typically containing DTLS handshake messages or parts of them), it
   MAY include those records in the DCCP-Response packet.  DTLS servers
   MAY also choose to delay the response until the DCCP handshake
   completes and then send the DTLS response in a DCCP-Data packet.

しかしながら、DCCP握手パケットDCCP-要求とDCCP-応答は、Application Data分野を持って、DCCP握手の間、利用者データを運ぶことができます、そして、これは部分的に平行で握手を実行する機会を作成します。 DTLSクライアント実装は、DCCP-リクエスト・パケットで1つ以上のDTLS記録(DTLS握手メッセージかそれらの部分を通常含んでいる)を伝えるのを選ぶかもしれません。 DTLSサーバ実装は、通常通りのこれらの記録を処理するのを選ぶかもしれません、そして、応答として送る1つ以上のDTLS記録があるなら(DTLS握手メッセージかそれらの部分を通常含んでいて)、それはDCCP-応答パケットにそれらの記録を含むかもしれません。 DTLSサーバは、また、DCCP握手までの応答が完成する遅れに選んで、次に、DCCP-データ・パケットで応答をDTLSに送るかもしれません。

   Note that even though the DCCP handshake is a reliable process (DCCP
   handshake messages are retransmitted as required if messages are
   lost), the transfer of Application Data in DCCP-Request and
   DCCP-Response packets is not necessarily reliable.  For example, DCCP
   server implementations are free to discard Application Data received
   in DCCP-Request packets.  And if DCCP-Request or DCCP-Response
   packets need to be retransmitted, the DCCP implementation may choose
   to not include the Application Data present in the initial message.

DCCP握手が信頼できるプロセス(メッセージが無くなるなら、DCCP握手メッセージは必要に応じて再送される)ですが、DCCP-要求とDCCP-応答パケットのApplication Dataの転送が必ず信頼できるというわけではないことに注意してください。 例えば、DCCPサーバ実装は自由にDCCP-リクエスト・パケットに受け取られたApplication Dataを捨てることができます。 そして、DCCP-要求かDCCP-応答パケットが、再送される必要があるなら、DCCP実装は、初期のメッセージの現在のApplication Dataを含んでいないのを選ぶかもしれません。

Phelan                      Standards Track                     [Page 3]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[3ページ]。

   Since the DTLS handshake is also a reliable process, it will
   interoperate across the data delivery unreliability of DCCP (after
   all, one of the basic functions of DTLS is to work over unreliable
   transport).  If the DTLS records containing DTLS handshake messages
   are lost, they will be retransmitted by DTLS.

また、DTLS握手が信頼できるプロセスであるので、それはDCCPのデータ配送非信頼性の向こう側に共同利用するでしょう(結局、DTLSの基本機能の1つは頼り無い輸送の上で働くことです)。 DTLS握手メッセージを含むDTLS記録が無くなると、それらはDTLSによって再送されるでしょう。

   This is regardless of whether the messages were sent in
   DCCP-Response/Request packets or DCCP-Data packets.  However, the
   only way for DTLS to retransmit DTLS records that were originally
   transmitted in DCCP-Request/Response packets (and they or the
   responses were lost somehow) is to wait for the DCCP handshake to
   complete and then resend the records in DCCP-Data packets.  This is
   due to the characteristic of DCCP that the next opportunity to send
   data after sending data in a DCCP-Request is only after the
   connection handshake completes.

DCCP-応答/リクエスト・パケットかDCCP-データ・パケットでメッセージを送ったかどうかにかかわらずこれはあります。 しかしながら、DTLSが元々DCCP-要求/応答パケット(それらか応答がどうにか失われた)で伝えられたDTLS記録を再送する唯一の方法はDCCP握手がDCCP-データ・パケットで記録を完成して、次に、再送するのを待つことです。 これは接続握手の後にだけ、データを送った後のデータにDCCP-要求を送る次の機会があるDCCPの特性のためです。完成します。

   DCCP and DTLS use similar strategies for retransmitting handshake
   messages.  If there is no response to the original request
   (DCCP-Request or any DTLS handshake message where a response is
   expected) within normally 1 second, the message is retransmitted.
   The timer is then doubled and the process repeated until a response
   is received, or a maximum time is exceeded.

DCCPとDTLSは、握手メッセージを再送するのに同様の戦略を使用します。 オリジナルの要求(DCCP-要求か応答が予想されるどんなDTLS握手メッセージも)への応答が全く通常1秒以内になければ、メッセージは再送されます。 次に、タイマは倍にされました、そして、応答が受け取られているか、または最大の時間が超えられるまで、プロセスは繰り返されました。

   Therefore, if DTLS records are sent in a DCCP-Request packet, and the
   DCCP-Request or DCCP-Response message is lost, the DCCP and DTLS
   handshakes could be timing out on similar schedules.  The
   DCCP-Request packets will be retransmitted on timeout, but the DTLS
   records cannot be retransmitted until the DCCP handshake completes
   (there is no possibility of adding new Application Data to a
   DCCP-Request retransmission).  In order to avoid multiple DTLS
   retransmissions queuing up before the first retransmission can be
   sent, DTLS over DCCP MUST wait until the completion of the DCCP
   handshake before restarting its DTLS handshake retransmission timer.

したがって、DCCP-リクエスト・パケットでDTLS記録を送って、DCCP-要求かDCCP-応答メッセージが無くなるなら、DCCPとDTLS握手は同様のスケジュールのタイミングであるかもしれません。 DCCP-リクエスト・パケットはタイムアウトで再送されるでしょうが、DCCP握手までDTLS記録は再送できません。完成します(DCCP-要求「再-トランスミッション」に新しいApplication Dataを加える可能性が全くありません)。 最初の「再-トランスミッション」を送ることができる前に列を作る複数のDTLS retransmissionsを避けるために、DTLS握手再送信タイマーを再開する前に、DCCP MUSTの上のDTLSはDCCP握手の完成まで待ちます。

3.3.  Effects of DCCP Congestion Control

3.3. DCCP輻輳制御の効果

   Given the large potential sizes of the DTLS handshake messages, it is
   possible that DCCP congestion control could throttle the transmission
   of the DTLS handshake to the point that the transfer cannot complete
   before the DTLS timeout and retransmission procedures take effect.
   Adding retransmitted messages to a congested situation might only
   make matters worse and delay connection establishment.

DTLS握手メッセージの大きい潜在的サイズを考えて、DTLSタイムアウトと「再-トランスミッション」手順が実施する前にDCCP輻輳制御が転送が終了できない肝心のDTLS握手の送信を阻止するかもしれないのは、可能です。 混雑している状況に再送されたメッセージを加えるのは、事態をますます悪化させるだけであり、コネクション確立を遅らせるかもしれません。

   Note that a DTLS over UDP application transmitting handshake data
   into this same network situation will not necessarily receive better
   throughput, and might actually see worse effective throughput.

この同じネットワーク状況に握手データを送るUDPアプリケーションの上のDTLSが必ずより良い効率を受け取るというわけではなくて、実際により悪い有効なスループットを見るかもしれないことに注意してください。

Phelan                      Standards Track                     [Page 4]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[4ページ]。

   Without the pacing of slow-start and congestion control, a UDP
   application might be making congestion worse and lowering the
   effective throughput it receives.

遅れた出発と輻輳制御のペースがなければ、UDPアプリケーションは、混雑をより悪くして、それが受け取る有効なスループットを下げているかもしれません。

   As stated in [RFC4347], "mishandling of the [retransmission] timer
   can lead to serious congestion problems".  This remains as true for
   DTLS over DCCP as it is for DTLS over UDP.

[RFC4347]に述べられているように、「[「再-トランスミッション」]タイマを誤って扱うのは重大な混雑問題を引き起こすことができます」。 UDPの上にそれがDTLSのためにあるとき、これはDTLSに本当であるとしてDCCPの上に残っています。

   DTLS over DCCP implementations SHOULD take steps to avoid
   retransmitting a request that has been queued but not yet actually
   transmitted by DCCP, when the underlying DCCP implementation can
   provide this information.  For example, DTLS could delay starting the
   retransmission timer until DCCP indicates the message has been
   transferred from DCCP to the IP layer.

DCCP実装SHOULDの上のDTLSは列に並ばせられましたが、実際にDCCPによってまだ伝えられなかった要求を再送するのを避けるために手を打ちます、基本的なDCCP実装がこの情報を提供できるなら。 例えば、DTLSは、DCCPが、メッセージがDCCPからIP層まで移されたのを示すまで再送信タイマーを始動するのを遅らせるかもしれません。

   In addition to the retransmission issues, if the throughput needs of
   the actual application data differ from the needs of the DTLS
   handshake, it is possible that the handshake transference could leave
   the DCCP congestion control in a state that is not immediately
   suitable for the application data that will follow.  For example,
   DCCP Congestion Control Identifier (CCID) 2 ([RFC4341]) congestion
   control uses an Additive Increase Multiplicative Decrease (AIMD)
   algorithm similar to TCP congestion control.  If it is used, then it
   is possible that transference of a large handshake could cause a
   multiplicative decrease that would not have happened with the
   application data.  The application might then be throttled while
   waiting for additive increase to return throughput to acceptable
   levels.

「再-トランスミッション」問題に加えて、本番適用データのスループットの必要性がDTLS握手の必要性と異なっているなら、握手移転がすぐに従うアプリケーションデータに適していない状態の輻輳制御にDCCPを残すかもしれないのは、可能です。 例えば、DCCP Congestion Control Identifier(CCID)2([RFC4341])輻輳制御はTCP輻輳制御と同様のAdditive Increase Multiplicative Decrease(AIMD)アルゴリズムを使用します。 それが使用されているなら、大きい握手の移転がアプリケーションデータで起こっていない乗法的な減少を引き起こす場合があったのは、可能です。 そして、付加的な増加がスループットを合格水準に返すのを待っている間、アプリケーションは阻止されるかもしれません。

   Applications where this might be a problem should consider using DCCP
   CCID 3 ([RFC4342]).  CCID 3 implements TCP-Friendly Rate Control
   (TFRC, [RFC3448])).  TFRC varies the allowed throughput more slowly
   than AIMD and might avoid the discontinuities possible with CCID 2.

これが問題であるかもしれないアプリケーションは、DCCP CCID3([RFC4342])を使用すると考えるべきです。 CCID3はTCP好意的なRate Control(TFRC、[RFC3448])を実装します。 TFRCはAIMDよりゆっくり許容スループットを変えて、CCID2で可能な不連続を避けるかもしれません。

3.4.  Relationships between DTLS Sessions/Connections and DCCP
      Connections

3.4. DTLSセッション/コネクションズとDCCPコネクションズとの関係

   DTLS uses the concepts of sessions and connections.  A DTLS
   connection is used by upper-layer endpoints to exchange data over a
   transport protocol.  DTLS sessions contain cached state information
   that is used to reduce the number of roundtrips and computation
   required to create multiple DTLS connections between the same
   endpoints.

DTLSはセッションと接続の概念を使用します。 DTLS接続は上側の層の終点によって使用されて、トランスポート・プロトコルの上とデータを交換します。 セッションが含むDTLSは往復旅行の数を減少させるのに使用される州の情報をキャッシュしました、そして、計算が同じ終点の間の複数のDTLS接続を創造するのが必要です。

Phelan                      Standards Track                     [Page 5]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[5ページ]。

   In DTLS over DCCP, a DTLS connection is carried by a DCCP connection.
   Often the DCCP connection establishment is immediately followed by
   DTLS connection establishment (either creating a new DTLS session
   with full handshake, or resuming an existing DTLS session), and the
   DTLS connection termination is immediately followed by DCCP
   connection termination, but this is not the only possibility.

DCCPの上のDTLSでは、DTLS接続はDCCP接続によって運ばれます。 しばしば、DCCPコネクション確立はすぐにDTLSコネクション確立(完全な握手との新しいDTLSセッションを作成するか、または既存のDTLSセッションを再開する)によって続かれています、そして、DCCP接続終了はすぐに、DTLS接続終了のあとに続きますが、これは唯一の可能性ではありません。

   The life of a DTLS over DCCP connection is completely contained
   within the life of the underlying DCCP connection; a DTLS connection
   cannot continue if its underlying DCCP connection terminates.
   However, multiple DTLS connections can be resumed from the same DTLS
   session, each running over its own DCCP connection.  The session
   resumption features of DTLS are widely used, and this situation is
   likely to occur in many use cases.  It is also possible to resume a
   DTLS session with a new DTLS connection running over a different
   transport.

DCCP接続の上のDTLSの寿命は基本的なDCCP接続の寿命の中に完全に含まれています。 基本的なDCCP接続が終わるなら、DTLS接続は続くことができません。 しかしながら、それぞれそれ自身のDCCP接続をひいて、同じDTLSセッションから複数のDTLS接続を再開できます。 DTLSのセッション再開機能は広く使用されます、そして、この状況は多くで起こるのがケースを使用する傾向があります。 また、異なった輸送をひく新しいDTLS接続とのDTLSセッションを再開するのも可能です。

   Note that it is possible for an application to start a DCCP
   connection by transferring unprotected packets, and then switch to
   DTLS after some time.  This is likely to be useful for applications
   that would like to negotiate using DTLS or not and has implications
   for the choice of DCCP Service Code.  See Section 3.6 for more
   information.

アプリケーションが保護のないパケットを移すことによってDCCP接続を始めて、次に、いつか後にDTLSに切り替わるのが、可能であることに注意してください。 これは、DTLSを使用することで交渉されたいアプリケーションの役に立つのがありそうであり、DCCP Service Codeの選択のための意味を持っています。 詳しい情報に関してセクション3.6を見てください。

   Many DTLS Application Programming Interfaces (APIs) do not prevent an
   application from sending a mix of encrypted and clear packets over
   the same transport connection.  Applications MUST NOT send
   unprotected data on a DCCP connection while it is also carrying a
   DTLS connection, since this presents a vulnerability to packet
   insertion attacks.

多くのDTLS Application Programming Interfaces(API)は、アプリケーションが暗号化されて明確なパケットのミックスを同じ輸送接続の上に送るのを防ぎません。 また、それがDTLS接続を運ぶ間、アプリケーションは保護のないデータをDCCP接続に送ってはいけません、これがパケット挿入攻撃に脆弱性を提示するので。

   Many DTLS APIs also allow an application to start multiple DTLS
   connections over one transport connection in series, with the
   termination of one DTLS connection followed by the start of another.
   Processing a DTLS handshake is relatively CPU intensive.  An
   application that uses this strategy is open to an attacker that
   repeatedly starts and immediately stops sessions.  Therefore,
   applications that use this strategy SHOULD limit the potential burden
   on the system by some means.  For example, the application could
   enforce a minimum time of 1 second between session initiations.

また、多くのDTLS APIで、アプリケーションは1つの輸送接続の上で連続的に複数のDTLS接続を始めることができます、別のものの始まりが1つのDTLS接続の終了のあとに続いていて。 DTLS握手を処理するのはCPU比較的徹底的です。 繰り返して始まって、すぐにセッションを中止する攻撃者にとって、この戦略を使用するアプリケーションは開いています。 したがって、この戦略SHOULDを使用するアプリケーションがどうでもシステムの上の潜在的負担を制限します。 例えば、アプリケーションはセッション開始の間で最低1秒の時間を実施するかもしれません。

3.5.  PMTU Discovery

3.5. PMTU発見

   Each DTLS record must fit within a single DCCP-Data packet.  DCCP
   packets are normally transmitted with the DF (Don't Fragment) bit set
   for IPv4 (or without fragmentation extension headers for IPv6).
   Because of this, DCCP performs Path Maximum Transmission Unit (PMTU)
   Discovery.

それぞれのDTLS記録は単一のDCCP-データ・パケットの中で合わなければなりません。 通常、DCCPパケットがDFと共に伝えられる、(Fragment) IPv4(またはIPv6のための断片化拡張ヘッダーなしで)に設定されたビットはそうしませんか? これのために、DCCPはPath Maximum Transmission Unit(PMTU)発見を実行します。

Phelan                      Standards Track                     [Page 6]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[6ページ]。

   DTLS also normally uses the DF bit and performs PMTU Discovery on its
   own, using an algorithm that is strongly similar to the one used by
   DCCP.  A DTLS over DCCP implementation MAY use the DCCP-managed value
   for PMTU and not perform PMTU Discovery on its own.  However,
   implementations that choose to use the DCCP-managed PMTU value SHOULD
   continue to follow the procedures of Section 4.1.1.1 of [RFC4347]
   with regard to fragmenting handshake messages during handshake
   retransmissions.  Alternatively, a DTLS over DCCP implementation MAY
   choose to use its own PMTU Discovery calculations, as specified in
   [RFC4347], but MUST NOT use a value greater than the value determined
   by DCCP.

DTLSはまた、通常、DFビットを使用して、それ自身のものにPMTUディスカバリーを実行します、強くDCCPによって使用されたものと同様のアルゴリズムを使用して。 DCCP実装の上のDTLSはPMTUにDCCPによって管理された値を使用して、それ自身のものにPMTUディスカバリーを実行しないかもしれません。 しかしながら、DCCPによって管理されたPMTU値のSHOULDを使用するのを選ぶ実装は、握手を断片化することに関する.1[RFC4347]が握手「再-トランスミッション」の間に通信させるセクション4.1.1の手順に従い続けています。 あるいはまた、DCCP実装の上のDTLSは、それ自身のPMTUディスカバリー計算を使用するのを選ぶかもしれません、DCCPで決定している値より大きい値を使用してはいけなくて[RFC4347]で指定されるように。

   DTLS implementations normally allow applications to reset the PMTU
   estimate back to the initial state.  When that happens, DTLS over
   DCCP implementations SHOULD also reset the DCCP PMTU estimation.

DTLS実装で、通常、アプリケーションはPMTU見積りを初期状態にリセットであって戻しできます。 また、それが起こると、DCCP実装SHOULDの上のDTLSはDCCP PMTU見積りをリセットします。

   DTLS implementations also sometimes allow applications to control the
   use of the DF bit (when running over IPv4) or the use of
   fragmentation extension headers (when running over IPv6).  DTLS over
   DCCP implementations SHOULD control the use of the DF bit or
   fragmentation extension headers by DCCP in concert with the
   application's indications, when the DCCP implementation supports
   this.  Note that DCCP implementations are not required to support
   sending fragmentable packets.

また、DTLS実装で、アプリケーションは時々DFビット(IPv4をひくとき)の使用か断片化拡張ヘッダーの使用を制御できます(IPv6をひくとき)。 DCCP実装SHOULDの上のDTLSはアプリケーションの指摘と協力してDCCPによるDFビットか断片化拡張ヘッダーの使用を制御します、DCCP実装がこれをサポートすると。 DCCP実装は送付が「断片-可能」パケットであるとサポートするのに必要でないことに注意してください。

   Note that the DCCP Maximum Packet Size (MPS in [RFC4340]) is bounded
   by the current congestion control state (Congestion Control Maximum
   Packet Size, CCMPS in [RFC4340]).  Even when the DF bit is not set
   and DCCP packets may then be fragmented, the MPS may be less than the
   65,535 bytes normally used in UDP.  It is also possible for the DCCP
   CCMPS, and thus the MPS, to vary over time as congestion conditions
   change.  DTLS over DCCP implementations MUST NOT use a DTLS record
   size that is greater than the DCCP MPS currently in force.

DCCP Maximum Packet Size([RFC4340]のMPS)は現在の輻輳制御状態(混雑Control Maximum Packet Size、[RFC4340]のCCMPS)のそばで境界があることに注意してください。 DFビットが設定されないで、次に、DCCPパケットが断片化さえされるとき、MPSは通常、6万5535バイトがUDPで使用した以下であるかもしれません。 また、DCCP CCMPS、およびその結果、MPSに、それも、混雑状態が変化するのに従って時間がたつにつれて異なるように可能です。 DCCP実装の上のDTLSは大挙して現在DCCP MPSより大きいDTLSレコード・サイズを使用してはいけません。

3.6.  DCCP Service Codes

3.6. DCCP接客規範

   The DCCP connection handshake includes a field called Service Code
   that is intended to describe "the application-level service to which
   the client application wants to connect".  Further, "Service Codes
   are intended to provide information about which application protocol
   a connection intends to use, thus aiding middleboxes and reducing
   reliance on globally well-known ports" [RFC4340].

DCCP接続握手は「クライアントアプリケーションが接続したがっているアプリケーションレベルサービス」について説明することを意図するService Codeと呼ばれる分野を含んでいます。 接続がどのアプリケーション・プロトコルでmiddleboxesと減少を使用して、その結果、支援するのに信用を意図するかに関してサービスCodesは情報をグローバルに提供するつもりです。さらに、「」 ウェルノウンポート[RFC4340。]

   It is expected that many middleboxes will give different privileges
   to applications running DTLS over DCCP versus just DCCP.  Therefore,
   applications that use DTLS over DCCP sometimes and just DCCP other
   times SHOULD register and use different Service Codes for each mode

多くのmiddleboxesがDCCPの上のアプリケーションの実行しているDTLSに対まさしくDCCP異なった特権を与えると予想されます。 したがって、DCCPの上で時々DTLSを使用するアプリケーションとまさしくDCCP他の回のSHOULDは各モードに異なったService Codesを登録して、使用します。

Phelan                      Standards Track                     [Page 7]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[7ページ]。

   of operation.  Applications that use both DCCP and DTLS over DCCP MAY
   choose to listen for incoming connections on the same DCCP port and
   distinguish the mode of the request by the offered Service Code.

操作について。 DCCP MAYの上でDCCPとDTLSの両方を使用するアプリケーションは、同じDCCPポートの上で接続要求の聞こうとして、提供されたService Codeで要求の方法を区別するのを選びます。

   Some applications may start out using DCCP without DTLS, and then
   optionally switch to using DTLS over the same connection.  Since
   there is no way to change the Service Code for a connection after it
   is established, these applications will use one Service Code.

いくつかのアプリケーションが、DTLSなしでDCCPを使用することで始めて、次に、任意に同じ接続の上でDTLSを使用するのに切り替わるかもしれません。 それが設立された後に接続のためにService Codeを変える方法が全くないので、これらのアプリケーションは1Service Codeを使用するでしょう。

3.7.  New Versions of DTLS

3.7. DTLSの新しいバージョン

   As DTLS matures, revisions to and updates for [RFC4347] can be
   expected.  DTLS includes mechanisms for identifying the version in
   use, and presumably future versions will either include backward
   compatibility modes or at least not allow connections between
   dissimilar versions.  Since DTLS over DCCP simply encapsulates the
   DTLS records transparently, these changes should not affect this
   document and the methods of this document should apply to future
   versions of DTLS.

DTLSが熟すとき、[RFC4347]のための改正とアップデートを予想できます。 DTLSが使用中のバージョンを特定するためのメカニズムを含んでいて、おそらく将来のバージョンは、後方の互換性モードを含んでいるか、または異なったバージョンの間の関係を少なくとも許さないでしょう。 DCCPの上のDTLSが、DTLSが記録であると単に透過的にカプセル化するので、これらの変化はこのドキュメントに影響するはずがありません、そして、このドキュメントのメソッドはDTLSの将来のバージョンに適用されるべきです。

   Therefore, in the absence of a revision to this document, this
   document is assumed to apply to all future versions of DTLS.  This
   document will only be revised if a revision to DTLS or DCCP
   (including its related CCIDs) makes a revision to the encapsulation
   necessary.

したがって、このドキュメントへの改正がないとき、このドキュメントがDTLSのすべての将来のバージョンに適用すると思われます。 カプセル化への改正がDTLSかDCCP(関連するCCIDsを含んでいる)への改正で必要になる場合にだけ、このドキュメントは改訂されるでしょう。

   It is RECOMMENDED that an application migrating to a new version of
   DTLS keep the same DCCP Service Code used for the old version and
   allow DTLS to provide the version negotiation support.  If a new
   version of DTLS provides significant new capabilities to the
   application that could change the behavior of middleboxes with regard
   to the application, an application developer MAY register a new
   Service Code.

DTLSの新しいバージョンにわたるアプリケーションが、古いバージョンに同じDCCP Service Codeを使用しておいて、DTLSがバージョン交渉サポートを提供するのを許容するのは、RECOMMENDEDです。 DTLSの新しいバージョンがアプリケーションに関してmiddleboxesの動きを変えることができたアプリケーションに重要な新しい能力を提供するなら、アプリケーション開発者は新しいService Codeを登録するかもしれません。

4. Security Considerations

4. セキュリティ問題

   Security considerations for DTLS are specified in [RFC4347] and for
   DCCP in [RFC4340].  The combination of DTLS and DCCP introduces no
   new security considerations.

DTLSのためのセキュリティ問題は[RFC4347]と[RFC4340]のDCCPに指定されます。 DTLSとDCCPの組み合わせはどんな新しいセキュリティ問題も紹介しません。

5. Acknowledgments

5. 承認

   The author would like to thank Eric Rescorla for initial guidance on
   adapting DTLS to DCCP, and Gorry Fairhurst, Pasi Eronen, Colin
   Perkins, Lars Eggert, Magnus Westerlund, and Tom Petch for comments
   on the document.

DTLSをDCCPに適合させるときの初期の指導についてエリック・レスコラに感謝します、そして、作者は、ドキュメントのコメントのためにゴーリーFairhurst、パシEronen、コリン・パーキンス、ラース・エッゲルト、マグヌスWesterlund、およびトムPetchに感謝したいです。

Phelan                      Standards Track                     [Page 8]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[8ページ]。

6. References

6. 参照

6.1.  Normative References

6.1. 引用規格

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

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

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

[RFC4347] レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、RFC4347、2006年4月。

6.2.  Informative References

6.2. 有益な参照

   [RFC3448]  Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification", RFC
              3448, January 2003.

[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。

   [RFC4341]  Floyd, S. and E. Kohler, "Profile for Datagram Congestion
              Control Protocol (DCCP) Congestion Control ID 2: TCP-like
              Congestion Control", RFC 4341, March 2006.

[RFC4341] フロイド、S.、およびE.コーラーは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID2のために以下の輪郭を描きます」。 「TCPのような輻輳制御」、RFC4341、2006年3月。

   [RFC4342]  Floyd, S., Kohler, E., and J. Padhye, "Profile for
              Datagram Congestion Control Protocol (DCCP) Congestion
              Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
              March 2006.

[RFC4342] フロイド、S.、コーラー、E.、およびJ.Padhyeは「データグラム混雑制御プロトコル(DCCP)輻輳制御ID3のために以下の輪郭を描きます」。 「TCPに優しい速度制御(TFRC)」、2006年3月のRFC4342。

Author's Address

作者のアドレス

   Tom Phelan
   Sonus Networks
   7 Technology Park Dr.
   Westford, MA USA 01886
   Phone: 978-614-8456
   Email: tphelan@sonusnet.com

トムフェランSonusはMAウェストフォード(米国)01886が電話をする7技術Park博士をネットワークでつなぎます: 978-614-8456 メールしてください: tphelan@sonusnet.com

Phelan                      Standards Track                     [Page 9]

RFC 5238                     DTLS over DCCP                     May 2008

フェラン規格は2008年5月にDCCPの上でRFC5238DTLSを追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(2008)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

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

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

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

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

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

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

Phelan                      Standards Track                    [Page 10]

フェラン標準化過程[10ページ]