RFC 5238 - Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5238
タイトル : RFC 5238 - Datagram Congestion Control Protocol（DCCP）を介したDatagram Transport Layer Security（DTLS）
翻訳編集 : 自動生成

[要約] RFC 5238は、Datagram Transport Layer Security (DTLS) を Datagram Congestion Control Protocol (DCCP) 上で動作させる方法について定義しています。この文書の目的は、DCCPの信頼性のないデータグラム配信とDTLSのセキュリティ機能を組み合わせることで、効率的かつ安全なデータ転送を実現することにあります。この組み合わせは、リアルタイムアプリケーションやストリーミングメディアなど、遅延に敏感でありながらセキュリティが要求される通信に特に有用です。関連するRFCには、DCCPを定義するRFC 4340やDTLSを定義するRFC 4347があります。

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

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

Datagram Congestion Control Protocol（DCCP）を介したDatagram Transport Layer Security（DTLS）

Status of This Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

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.

このドキュメントでは、Datagram Congestion Control Protocol（DCCP）を介したDatagram 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. 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]で指定されているデータグラムトランスポート層セキュリティ（DTLS）を使用して、[RFC4340]で指定されているデータグラム輻輳制御プロトコル（DCCP）でアプリケーションペイロードを伝送する方法を指定します。

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を変更するトランスポート層セキュリティ（TLS、[RFC4346]）の適応です。 TLSは、盗聴を防止し、改ざんやメッセージの偽造を検出するように設計された方法でクライアント/サーバーアプリケーションが通信できるようにするプロトコルです。 DTLSは、TLS-plus-adaptations-for-unreliabilityと見なすことができます。

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やストリーム制御伝送プロトコル（SCTP）と同様の適応型輻輳制御を備えています。 DCCPはUDP-plus-congestion-controlまたはTCP-minus-reliabilityと同じように表示できます（ただし、TCPとは異なり、DCCPは複数の輻輳制御アルゴリズムを提供します）。

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の組み合わせにより、DCCPを使用するアプリケーションに、TCP、UDP、SCTPで利用可能なものと同様のトランスポートセキュリティ機能が提供されます。

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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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-DataおよびDCCP-DataAckパケットのアプリケーションデータフィールドで送信されます（このドキュメントの残りの部分では、「DCCP-Dataパケット」は「DCCP-DataまたはDCCP-DataAckを意味するものと想定しています）パケット"）。フラグメント化が許可されていない場合（Do n't Fragment（DF）は、結果のパケットが通常のデータパケットに対して現在有効なパス最大転送ユニット（PMTU）内にある限り、複数のDTLSレコードを1つのDCCP-Dataパケットで送信できます（MAY）。）IPv4にビットが設定されているか、IPv6にフラグメンテーション拡張ヘッダーが使用されていない）、またはフラグメンテーションが許可されている場合は現在のDCCP最大パケットサイズ内（PMTU Discoveryの詳細については、セクション3.5を参照）。単一のDTLSレコードは、単一のDCCP-Dataパケットに完全に含まれている必要があります。複数のパケットに分割することはできません。

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はどちらも、パケット/レコードでシーケンス番号を使用します。これらのシーケンス番号は、完全ではないが多少重複する機能を果たします。その結果、DCCPパケットのシーケンス番号とそのパケットに含まれるDTLSレコードのシーケンス番号の間には関係がなく、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-DataおよびDCCP-DataAckパケットの送信に先行する接続ハンドシェイク手順を備えています。 DTLSも接続指向であり、実際のアプリケーション情報の送信に先行する必要のある独自のハンドシェイク手順があります。上記のセクション3のDTLSレコードをDCCP-DataおよびDCCP-DataAckパケットにマッピングするルールを使用すると、2つのハンドシェイクが強制的に連続して行われ、最初にDCCPハンドシェイク、次にDTLSハンドシェイクが行われます。これがTLS over TCPの仕組みです。

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-RequestおよびDCCP-Responseにはアプリケーションデータフィールドがあり、DCCPハンドシェイク中にユーザーデータを伝送できるため、ハンドシェイクを部分的に並行して実行する機会が生まれます。 DTLSクライアント実装は、DCCP要求パケットで1つ以上のDTLSレコード（通常はDTLSハンドシェイクメッセージまたはその一部を含む）を送信することを選択できます（MAY）。 DTLSサーバーの実装は、これらのレコードを通常どおり処理することを選択できます。また、応答として送信する1つ以上のDTLSレコードがある場合（通常、DTLSハンドシェイクメッセージまたはそれらの一部を含む）、DCCP応答パケットにそれらのレコードを含めることができます（MAY）。 DTLSサーバーは、DCCPハンドシェイクが完了するまで応答を遅らせ、DCCP-DataパケットでDTLS応答を送信することも選択できます（MAY）。

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応答パケットでのアプリケーションデータの転送は必ずしも信頼できるとは限りません。たとえば、DCCPサーバーの実装では、DCCP要求パケットで受信したアプリケーションデータを自由に破棄できます。また、DCCP-RequestまたはDCCP-Responseパケットを再送信する必要がある場合、DCCP実装は、最初のメッセージに存在するアプリケーションデータを含めないことを選択できます。

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-Response / Requestパケットで送信されたか、DCCP-Dataパケットで送信されたかには関係ありません。ただし、DTLSがDCCP-Request / Responseパケットで最初に送信された（そしてそれらが何らかの形で失われた）DTLSレコードを再送信する唯一の方法は、DCCPハンドシェイクが完了するのを待ってから、DCCP-Dataでレコードを再送信することです。パケット。これは、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は、ハンドシェイクメッセージの再送信に同様の戦略を使用します。通常の1秒以内に元の要求（DCCP-Requestまたは応答が予想されるDTLSハンドシェイクメッセージ）に対する応答がない場合、メッセージは再送信されます。その後、タイマーが2倍になり、応答が受信されるまで、または最大時間を超えるまで、このプロセスが繰り返されます。

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.

したがって、DTLSレコードがDCCP-Requestパケットで送信され、DCCP-RequestまたはDCCP-Responseメッセージが失われた場合、DCCPとDTLSのハンドシェイクが同様のスケジュールでタイムアウトになる可能性があります。 DCCP-Requestパケットはタイムアウト時に再送信されますが、DCCPハンドシェイクが完了するまでDTLSレコードを再送信できません（DCCP-Request再送信に新しいアプリケーションデータを追加する可能性はありません）。最初の再送信が送信される前に複数のDTLS再送信がキューに入れられることを回避するために、DCCP上のDTLSは、DCCPハンドシェイクが完了するまで待機してから、DTLSハンドシェイク再送信タイマーを再開する必要があります。

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ハンドシェイクメッセージの潜在的なサイズが大きい場合、DCCP輻輳制御により、DTLSタイムアウトと再送信の手順が有効になる前に転送が完了しなくなるまで、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.

この同じネットワーク状況にハンドシェイクデータを送信するDTLS over UDPアプリケーションが必ずしもより良いスループットを受信するとは限らず、実際にはより効果的なスループットが低下する可能性があることに注意してください。

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]で述べられているように、「[再送信]タイマーの取り扱いを誤ると、深刻な輻輳の問題が発生する可能性があります」。これは、DTLS over UDPの場合と同様に、DCCP over 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 over DCCP実装は、基礎となるDCCP実装がこの情報を提供できる場合、DCCPによってキューに入れられたが実際にはまだ送信されていない要求の再送信を回避する手順を実行する必要があります。たとえば、DTLSは、メッセージがDCCPからIP層に転送されたことをDCCPが示すまで、再送信タイマーの開始を遅らせる可能性があります。

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輻輳制御識別子（CCID）2（[RFC4341]）輻輳制御は、TCP輻輳制御と同様の加法増加乗法減少（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 CCID 3（[RFC4342]）の使用を検討する必要があります。 CCID 3はTCPフレンドリーレートコントロール（TFRC、[RFC3448]））を実装しています。 TFRCはAIMDよりもゆっくりと許容スループットを変化させ、CCID 2で起こり得る不連続性を回避する可能性があります。

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接続を作成するために必要なラウンドトリップと計算の数を減らすために使用される、キャッシュされた状態情報が含まれています。

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.

DTLS over DCCPでは、DTLS接続はDCCP接続によって行われます。多くの場合、DCCP接続確立の直後にDTLS接続確立（フルハンドシェイクで新しいDTLSセッションを作成するか、既存のDTLSセッションを再開する）が行われ、DTLS接続終了の直後にDCCP接続終了が続きますが、これだけではありません可能性。

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.

DTLS over DCCP接続の存続期間は、基礎となるDCCP接続の存続期間内に完全に含まれます。基になるDCCP接続が終了すると、DTLS接続を続行できません。ただし、同じDTLSセッションから複数のDTLS接続を再開でき、それぞれが独自のDCCP接続を介して実行されます。 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サービスコードの選択に影響を与えるアプリケーションに役立つ可能性があります。詳細については、セクション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アプリケーションプログラミングインターフェイス（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-Dataパケット内に収まる必要があります。 DCCPパケットは、通常、IPv4用に設定されたDF（Do n't Fragment）ビットを使用して（またはIPv6用のフラグメンテーション拡張ヘッダーなしで）送信されます。このため、DCCPはパス最大伝送ユニット（PMTU）ディスカバリを実行します。

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ビットを使用し、DCCPで使用されるアルゴリズムと非常によく似たアルゴリズムを使用して、それ自体でPMTU検出を実行します。 DTLS over DCCPの実装では、PMTUにDCCP管理の値を使用しても、PMTU Discoveryを単独で実行することはできません。ただし、DCCP管理のPMTU値の使用を選択する実装は、ハンドシェイク再送信中のハンドシェイクメッセージの断片化に関して、[RFC4347]のセクション4.1.1.1の手順に従う必要があります（SHOULD）。あるいは、DTLS over DCCP実装は、[RFC4347]で指定されているように、独自のPMTU Discovery計算を使用することを選択できますが、DCCPによって決定された値より大きい値を使用してはなりません。

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 over DCCP実装は、DCCP PMTU推定もリセットする必要があります（SHOULD）。

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 over DCCP実装は、DCCP実装がこれをサポートしている場合、アプリケーションの指示と連携して、DCCPによるDFビットまたはフラグメンテーション拡張ヘッダーの使用を制御する必要があります（SHOULD）。フラグメント化可能なパケットの送信をサポートするために、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の最大パケットサイズ（[RFC4340]のMPS）は、現在の輻輳制御状態（[RFC4340]の輻輳制御最大パケットサイズ、CCMPS）によって制限されることに注意してください。 DFビットが設定されておらず、DCCPパケットがフラグメント化される場合でも、MPSは、UDPで通常使用される65,535バイト未満になる場合があります。また、DCCP CCMPS、つまりMPSは、輻輳状態の変化に応じて時間とともに変化する可能性があります。 DTLS over DCCP実装は、現在有効なDCCP MPSよりも大きいDTLSレコードサイズを使用してはなりません（MUST NOT）。

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接続ハンドシェイクには、「クライアントアプリケーションが接続するアプリケーションレベルのサービス」を記述することを目的としたサービスコードと呼ばれるフィールドが含まれています。さらに、「サービスコードは、接続が使用するアプリケーションプロトコルに関する情報を提供することを目的としているため、ミドルボックスを支援し、広く知られているポートへの依存を減らします」[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 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だけでなく、DCCPを介してDTLSを実行するアプリケーションに異なる特権を与えると予想されます。したがって、DCCP over DCCPを使用するアプリケーションや、DCCPだけを使用するアプリケーションは、動作モードごとに異なるサービスコードを登録して使用する必要があります（SHOULD）。 DCCPおよびDTLS over DCCPの両方を使用するアプリケーションは、同じDCCPポートで着信接続をリッスンし、提供されたサービスコードによって要求のモードを区別することを選択できます（MAY）。

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を使用するように切り替える場合があります。接続の確立後にサービスコードを変更する方法がないため、これらのアプリケーションは1つのサービスコードを使用します。

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には使用中のバージョンを識別するためのメカニズムが含まれており、おそらく将来のバージョンには下位互換性モードが含まれるか、少なくとも異なるバージョン間の接続を許可しないでしょう。 DTLS over DCCPは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（関連するCCIDを含む）の改訂により、カプセル化の改訂が必要になった場合にのみ改訂されます。

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サービスコードを維持し、DTLSがバージョンネゴシエーションサポートを提供できるようにすることをお勧めします。 DTLSの新しいバージョンが、アプリケーションに関するミドルボックスの動作を変更する可能性のある重要な新機能をアプリケーションに提供する場合、アプリケーション開発者は新しいサービスコードを登録できます（MAY）。

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]と[CCP]の[RFC4340]で指定されています。 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.

著者は、DCCPへのDTLSの適用に関する最初のガイダンスを提供してくれたEric Rescorlaと、ドキュメントへのコメントを提供してくれたGorry Fairhurst、Pasi Eronen、Colin Perkins、Lars Eggert、Magnus Westerlund、Tom Petchに感謝します。

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] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、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. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。

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

[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、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] Handley、M.、Floyd、S.、Padhye、J。、およびJ. Widmer、「TCP Friendly Rate Control（TFRC）：Protocol Specification」、RFC 3448、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] Floyd、S。およびE. Kohler、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 2：TCP-like Congestion Control」、RFC 4341、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] Floyd、S.、Kohler、E。、およびJ. Padhye、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 3：TCP-Friendly Rate Control（TFRC）」、RFC 4342、2006年3月。

Author's Address

著者のアドレス

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

Tom Phelan Sonus Networks 7 Technology Park Dr. Westford、MA USA 01886電話：978-614-8456メール：tphelan@sonusnet.com

Full Copyright Statement

完全な著作権表示

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

このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。

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

IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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

IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。