RFC 6520 - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6520
タイトル : RFC 6520 - トランスポートレイヤーセキュリティ（TLS）およびデータグラムトランスポートレイヤーセキュリティ（DTLS）ハートビートエクステンション
翻訳編集 : 自動生成

[要約] RFC 6520は、Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) にハートビート機能を追加するための拡張を定義しています。この拡張の主な目的は、接続の生存確認やパスMTU探索などを可能にすることです。利用場面としては、長時間の接続維持が必要なアプリケーションや、ネットワークの状態を確認したい場合などがあります。関連するRFCには、TLSを定義するRFC 5246（TLS 1.2）や、DTLSを定義するRFC 6347などがあります。RFC 6520によるハートビート拡張は、セキュリティと効率性を向上させるために重要な役割を果たします。

Internet Engineering Task Force (IETF)                     R. Seggelmann
Request for Comments: 6520                                     M. Tuexen
Category: Standards Track               Muenster Univ. of Appl. Sciences
ISSN: 2070-1721                                              M. Williams
                                                   GWhiz Arts & Sciences
                                                           February 2012

Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension

トランスポートレイヤーセキュリティ（TLS）およびデータグラムトランスポートレイヤーセキュリティ（DTLS）ハートビートエクステンション

Abstract

概要

This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.

このドキュメントでは、トランスポートレイヤーセキュリティ（TLS）およびデータグラムトランスポートレイヤーセキュリティ（DTLS）プロトコルのハートビート拡張について説明します。

The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.

Heartbeat拡張機能は、TLS/DTLの新しいプロトコルを提供し、再交渉を実行せずにKeep-Alive機能の使用と、DTLSのPATH MTU（PMTU）ディスカバリーの基礎を実行できます。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6520.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6520で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
   3.  Heartbeat Protocol  . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Heartbeat Request and Response Messages . . . . . . . . . . . . 5
   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

1. はじめに

1.1. Overview

1.1. 概要

This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols, as defined in [RFC5246] and [RFC6347] and their adaptations to specific transport protocols described in [RFC3436], [RFC5238], and [RFC6083].

このドキュメントでは、[RFC5246]および[RFC6347]で定義されているように、[RFC3436]、[RFC5238]で説明されている特定の輸送プロトコルへの適応への輸送層セキュリティ（TLS）およびデータグラム輸送層セキュリティ（DTLS）プロトコルのハートビート拡張について説明します。、および[RFC6083]。

DTLS is designed to secure traffic running on top of unreliable transport protocols. Usually, such protocols have no session management. The only mechanism available at the DTLS layer to figure out if a peer is still alive is a costly renegotiation, particularly when the application uses unidirectional traffic. Furthermore, DTLS needs to perform path MTU (PMTU) discovery but has no specific message type to realize it without affecting the transfer of user messages.

DTLSは、信頼できない輸送プロトコルの上で実行されるトラフィックを保護するように設計されています。通常、そのようなプロトコルにはセッション管理がありません。DTLSレイヤーで利用可能な唯一のメカニズムは、ピアがまだ生きているかどうかを把握するための唯一のメカニズムは、特にアプリケーションが単方向トラフィックを使用する場合、費用のかかる再交渉です。さらに、DTLはPath MTU（PMTU）ディスカバリーを実行する必要がありますが、ユーザーメッセージの転送に影響を与えることなく実現するための特定のメッセージタイプはありません。

TLS is based on reliable protocols, but there is not necessarily a feature available to keep the connection alive without continuous data transfer.

TLSは信頼できるプロトコルに基づいていますが、連続データ転送なしで接続を生かし続けるための機能は必ずしも利用できません。

The Heartbeat Extension as described in this document overcomes these limitations. The user can use the new HeartbeatRequest message, which has to be answered by the peer with a HeartbeartResponse immediately. To perform PMTU discovery, HeartbeatRequest messages containing padding can be used as probe packets, as described in [RFC4821].

このドキュメントで説明されているハートビート拡張は、これらの制限を克服します。ユーザーは、新しいHeartBeatest Equestメッセージを使用できます。これは、すぐにハートベアトレップサブサスペンポンスでピアが回答する必要があります。PMTUの発見を実行するために、[RFC4821]で説明されているように、パディングを含むハートビアトレートメッセージをプローブパケットとして使用できます。

1.2. Conventions

1.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].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

2. Heartbeat Hello Extension

2. ハートビートハローエクステンション

The support of Heartbeats is indicated with Hello Extensions. A peer cannot only indicate that its implementation supports Heartbeats, it can also choose whether it is willing to receive HeartbeatRequest messages and respond with HeartbeatResponse messages or only willing to send HeartbeatRequest messages. The former is indicated by using peer_allowed_to_send as the HeartbeatMode; the latter is indicated by using peer_not_allowed_to_send as the Heartbeat mode. This decision can be changed with every renegotiation. HeartbeatRequest messages MUST NOT be sent to a peer indicating peer_not_allowed_to_send. If an endpoint that has indicated peer_not_allowed_to_send receives a HeartbeatRequest message, the endpoint SHOULD drop the message silently and MAY send an unexpected_message Alert message.

ハートビートのサポートは、Hello Extensionsで示されています。ピアは、その実装がハートビートをサポートしていることを示すだけではありません。また、ハートビアトレートのメッセージを受け取り、ハートビアトレストサスデスペンセップメッセージで応答するのか、それともハートビアトレトレストメッセージを送信する意思があるかを選択することもできます。前者は、heartbeatmodeとしてpeer_allowed_to_sendを使用することで示されます。後者は、heartbeatモードとしてpeer_not_allowed_to_sendを使用することで示されます。この決定は、再交渉ごとに変更できます。heartBeatERQUESTメッセージは、PEER_NOT_ALLOWED_TO_SENDを示すピアに送信してはなりません。PEER_NOT_ALLOWED_TO_SENDがHeartBEATREQUESTメッセージを受信したことを示したエンドポイントが、エンドポイントはメッセージを静かにドロップし、予期しない_Messageアラートメッセージを送信する場合があります。

The format of the Heartbeat Hello Extension is defined by:

ハートビートハロー拡張機能の形式は、次のように定義されています。

   enum {
      peer_allowed_to_send(1),
      peer_not_allowed_to_send(2),
      (255)
   } HeartbeatMode;

   struct {
      HeartbeatMode mode;
   } HeartbeatExtension;

Upon reception of an unknown mode, an error Alert message using illegal_parameter as its AlertDescription MUST be sent in response.

不明なモードを受信すると、AlertDescriptionとしてIllegal_Parameterを使用したエラーアラートメッセージを応答して送信する必要があります。

3. Heartbeat Protocol

3. ハートビートプロトコル

The Heartbeat protocol is a new protocol running on top of the Record Layer. The protocol itself consists of two message types: HeartbeatRequest and HeartbeatResponse.

ハートビートプロトコルは、レコードレイヤーの上で実行される新しいプロトコルです。プロトコル自体は、HeartBeatre -EquestとHeartBeateSponseの2つのメッセージタイプで構成されています。

   enum {
      heartbeat_request(1),
      heartbeat_response(2),
      (255)
   } HeartbeatMessageType;

A HeartbeatRequest message can arrive almost at any time during the lifetime of a connection. Whenever a HeartbeatRequest message is received, it SHOULD be answered with a corresponding HeartbeatResponse message.

ハートビアトレートのメッセージは、接続の寿命の間、ほぼいつでも到着できます。HeartBeatre -Equestメッセージが受信されるときはいつでも、対応するHeartBeateSponseメッセージで回答する必要があります。

However, a HeartbeatRequest message SHOULD NOT be sent during handshakes. If a handshake is initiated while a HeartbeatRequest is still in flight, the sending peer MUST stop the DTLS retransmission timer for it. The receiving peer SHOULD discard the message silently, if it arrives during the handshake. In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be discarded.

ただし、ハートビアトレートの最大のメッセージは、握手中に送信されないでください。HeartBeatre -Equestがまだ飛行中に握手が開始された場合、送信ピアはDTLS再送信タイマーを停止する必要があります。受信ピアは、握手中に到着した場合、メッセージを静かに廃棄する必要があります。DTLSの場合、古いエポックからのHeartBeater -Equestメッセージを破棄する必要があります。

There MUST NOT be more than one HeartbeatRequest message in flight at a time. A HeartbeatRequest message is considered to be in flight until the corresponding HeartbeatResponse message is received, or until the retransmit timer expires.

一度に飛行中にハートビアトレートの最大のメッセージを1つ以上存在させてはなりません。HeartBeatre -Equestメッセージは、対応するHeartBeatesponseメッセージが受信されるまで、または再送信タイマーの有効期限が切れるまで、飛行中であると見なされます。

When using an unreliable transport protocol like the Datagram Congestion Control Protocol (DCCP) or UDP, HeartbeatRequest messages MUST be retransmitted using the simple timeout and retransmission scheme DTLS uses for flights as described in Section 4.2.4 of [RFC6347]. In particular, after a number of retransmissions without receiving a corresponding HeartbeatResponse message having the expected payload, the DTLS connection SHOULD be terminated. The threshold used for this SHOULD be the same as for DTLS handshake messages. Please note that after the timer supervising a HeartbeatRequest messages expires, this message is no longer considered in flight. Therefore, the HeartbeatRequest message is eligible for retransmission. The retransmission scheme, in combination with the restriction that only one HeartbeatRequest is allowed to be in flight, ensures that congestion control is handled appropriately in case of the transport protocol not providing one, like in the case of DTLS over UDP.

データグラムの混雑制御プロトコル（DCCP）やUDPなどの信頼性の低いトランスポートプロトコルを使用する場合、[RFC6347]のセクション4.2.4で説明されているように、DTLSがフライトに使用する単純なタイムアウトおよび再送信スキームの使用を使用して、heartBeateTrequestメッセージを再送信する必要があります。特に、対応するHeartBeateSponseメッセージを受信せずに多くの再送信を受け取った後、Payloadが予想される場合、DTLS接続を終了する必要があります。これに使用されるしきい値は、DTLSハンドシェイクメッセージと同じでなければなりません。ハートビアトレートのメッセージが期限切れになったタイマーが期限切れになった後、このメッセージは飛行中に考慮されなくなったことに注意してください。したがって、HeartBeatre -Equestメッセージは再送信の対象となります。再送信スキームは、1つのHeartBeate -Equestのみが飛行中に許可されているという制限と組み合わせて、UDPを介したDTLSの場合のように、輸送プロトコルが1つを提供しない場合に、混雑制御が適切に処理されることを保証します。

When using a reliable transport protocol like the Stream Control Transmission Protocol (SCTP) or TCP, HeartbeatRequest messages only need to be sent once. The transport layer will handle retransmissions. If no corresponding HeartbeatResponse message has been received after some amount of time, the DTLS/TLS connection MAY be terminated by the application that initiated the sending of the HeartbeatRequest message.

Stream Control Transmission Protocol（SCTP）やTCPなどの信頼できる輸送プロトコルを使用する場合、HeartBeatest Equestメッセージは1回だけ送信する必要があります。輸送層は再送信を処理します。ある程度の時間後に対応するHeartBeateSponseメッセージが受信されていない場合、DTLS/TLS接続は、HeartBeatErtequestメッセージの送信を開始したアプリケーションによって終了する場合があります。

4. Heartbeat Request and Response Messages

4. ハートビートリクエストと応答メッセージ

The Heartbeat protocol messages consist of their type and an arbitrary payload and padding.

ハートビートプロトコルメッセージは、そのタイプと任意のペイロードとパディングで構成されています。

   struct {
      HeartbeatMessageType type;
      uint16 payload_length;
      opaque payload[HeartbeatMessage.payload_length];
      opaque padding[padding_length];
   } HeartbeatMessage;

The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066].

[RFC6066]で定義されているように交渉した場合、心拍数の総長さは2^14またはMAX_FRAGMENT_LENGTHを超えてはなりません。

type: The message type, either heartbeat_request or heartbeat_response.

タイプ：メッセージタイプ、heartbeat_requestまたはheartbeat_responseのいずれか。

payload_length: The length of the payload.

Payload_length：ペイロードの長さ。

payload: The payload consists of arbitrary content.

ペイロード：ペイロードは任意のコンテンツで構成されています。

padding: The padding is random content that MUST be ignored by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length for TLS and DTLSPlaintext.length for DTLS. Furthermore, the length of the type field is 1 byte, and the length of the payload_length is 2. Therefore, the padding_length is TLSPlaintext.length - payload_length - 3 for TLS and DTLSPlaintext.length - payload_length - 3 for DTLS. The padding_length MUST be at least 16.

パディング：パディングはランダムなコンテンツであり、受信機は無視する必要があります。心拍数の長さは、tlsのtlsplantext.lengthとdtlsplantext.dtlsの長さです。さらに、タイプフィールドの長さは1バイトで、Payload_lengthの長さは2です。したがって、padding_lengthはtlsplaintext.length -length -3 for tlsおよびdtlsplaintext.length -length -3です。padding_lengthは少なくとも16でなければなりません。

The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes. The padding of a received HeartbeatMessage message MUST be ignored.

心拍数の送信者は、少なくとも16バイトのランダムパディングを使用する必要があります。受信した心拍数メッセージのパディングは無視する必要があります。

If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.

受信した心拍数のPayload_lengthが大きすぎる場合、受信した心拍数は静かに廃棄する必要があります。

When a HeartbeatRequest message is received and sending a HeartbeatResponse is not prohibited as described elsewhere in this document, the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest.

HeartBeatest Equestメッセージが受信され、このドキュメントの他の場所で説明されているようにHeartBeateSponseを送信することは禁止されていない場合、受信したHeartBeatestのペイロードの正確なコピーを運ぶ対応するハートビアトゥールサスデスペンペンメッセージを送信する必要があります。

If a received HeartbeatResponse message does not contain the expected payload, the message MUST be discarded silently. If it does contain the expected payload, the retransmission timer MUST be stopped.

受信したHeartBeateSponseメッセージに予想されるペイロードが含まれていない場合、メッセージは静かに破棄する必要があります。予想されるペイロードが含まれている場合、再送信タイマーを停止する必要があります。

5. Use Cases

5. ユースケース

Each endpoint sends HeartbeatRequest messages at a rate and with the padding required for the particular use case. The endpoint should not expect its peer to send HeartbeatRequests. The directions are independent.

各エンドポイントは、特定のユースケースに必要なパディングを使用して、heartBeatest Equestメッセージをレートで送信します。エンドポイントは、ピアがハートビアトレートの送信を期待してはなりません。指示は独立しています。

5.1. Path MTU Discovery

5.1. Path MTUディスカバリー

DTLS performs path MTU discovery as described in Section 4.1.1.1 of [RFC6347]. A detailed description of how to perform path MTU discovery is given in [RFC4821]. The necessary probe packets are the HeartbeatRequest messages.

DTLSは、[RFC6347]のセクション4.1.1.1で説明されているように、PATH MTU発見を実行します。パスMTU発見の実行方法の詳細な説明は、[RFC4821]に記載されています。必要なプローブパケットは、HeartBeatre -Equestメッセージです。

This method of using HeartbeatRequest messages for DTLS is similar to the one for the Stream Control Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) defined in [RFC4820].

DTLSにHeartBeatre-Equestメッセージを使用するこの方法は、[RFC4820]で定義されたパディングチャンク（PAD-CHUNK）を使用して、ストリーム制御伝送プロトコル（SCTP）のものと類似しています。

5.2. Liveliness Check

5.2. 活気のあるチェック

Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive. Even in the case of TLS/TCP, this allows a check at a much higher rate than the TCP keep-alive feature would allow.

HeartBeatre -Equestメッセージを送信すると、送信者がピアに到達し、ピアが生きていることを確認できます。TLS/TCPの場合でも、これにより、TCPのキープアライブ機能が許可されるよりもはるかに高いレートでチェックが可能になります。

Besides making sure that the peer is still reachable, sending HeartbeatRequest messages refreshes the NAT state of all involved NATs.

ピアがまだ到達可能であることを確認することに加えて、HeartBeactest Equestメッセージを送信すると、関係するすべてのNATのNAT状態がリフレッシュされます。

HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round-trip times long. This idle period SHOULD be configurable up to a period of multiple minutes and down to a period of one second. A default value for the idle period SHOULD be configurable, but it SHOULD also be tunable on a per-peer basis.

HeartBeate-Beatestメッセージは、少なくとも複数の往復時間のアイドル期間後にのみ送信する必要があります。このアイドル期間は、数分間、1秒間までまでに構成できる必要があります。アイドル期間のデフォルト値は構成可能である必要がありますが、ピアごとに調整可能である必要があります。

6. IANA Considerations

6. IANAの考慮事項

IANA has assigned the heartbeat content type (24) from the "TLS ContentType Registry" as specified in [RFC5246]. The reference is to RFC 6520.

IANAは、[RFC5246]で指定されている「TLS ContentTypeレジストリ」からハートビートコンテンツタイプ（24）を割り当てました。参照はRFC 6520へのものです。

IANA has created and now maintains a new registry for Heartbeat Message Types. The message types are numbers in the range from 0 to 255 (decimal). IANA has assigned the heartbeat_request (1) and the heartbeat_response (2) message types. The values 0 and 255 should be reserved. This registry uses the Expert Review policy as described in [RFC5226]. The reference is to RFC 6520.

IANAは、ハートビートメッセージタイプの新しいレジストリを作成し、維持しています。メッセージタイプは、0〜255（小数）の範囲の数値です。IANAは、heartbeat_request（1）とheartbeat_response（2）メッセージタイプを割り当てました。値0と255は予約する必要があります。このレジストリは、[RFC5226]に記載されているように、専門家のレビューポリシーを使用します。参照はRFC 6520へのものです。

IANA has assigned the heartbeat extension type (15) from the TLS "ExtensionType Values" registry as specified in [RFC5246]. The reference is to RFC 6520.

IANAは、[RFC5246]で指定されているように、TLS「拡張タイプ値」レジストリからハートビート拡張タイプ（15）を割り当てました。参照はRFC 6520へのものです。

IANA has created and now maintains a new registry for Heartbeat Modes. The modes are numbers in the range from 0 to 255 (decimal). IANA has assigned the peer_allowed_to_send (1) and the peer_not_allowed_to_send (2) modes. The values 0 and 255 should be reserved. This registry uses the Expert Review policy as described in [RFC5226]. The reference is to RFC 6520.

IANAは、ハートビートモードの新しいレジストリを作成し、維持しています。モードは、0〜255（小数）の範囲の数値です。IANAは、PEER_ALLOWED_TO_SEND（1）とPEER_NOT_ALLOWED_TO_SEND（2）モードを割り当てました。値0と255は予約する必要があります。このレジストリは、[RFC5226]に記載されているように、専門家のレビューポリシーを使用します。参照はRFC 6520へのものです。

7. Security Considerations

7. セキュリティに関する考慮事項

The security considerations of [RFC5246] and [RFC6347] apply to this document. This document does not introduce any new security considerations.

[RFC5246]および[RFC6347]のセキュリティ上の考慮事項は、このドキュメントに適用されます。このドキュメントでは、新しいセキュリティ上の考慮事項は導入されていません。

8. Acknowledgments

8. 謝辞

The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their invaluable comments.

著者は、Pasi Eronen、Adrian Farrel、Stephen Farrell、Adam Langley、Nikos Mavrogiannopoulos、Tom Petch、Eric Rescorla、Peter Saint-Andre、Juho Vaehae-Herttuaに非常に熱心なコメントに感謝します。

9. References

9. 参考文献

9.1. Normative References

9.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月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。

[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.

[RFC6066] EastLake、D。、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、2011年1月。

[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.

[RFC6347] Rescorla、E。およびN. Modadugu、「データグラムトランスポートレイヤーセキュリティバージョン1.2」、RFC 6347、2012年1月。

9.2. Informative References

9.2. 参考引用

[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.

[RFC3436] Jungmaier、A.、Rescorla、E。、およびM. Tuexen、「ストリーム制御伝送プロトコルを介した輸送層セキュリティ」、RFC 3436、2002年12月。

[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)", RFC 4820, March 2007.

[RFC4820] Tuexen、M.、Stewart、R。、およびP. Lei、「ストリーム制御伝送プロトコル（SCTP）のパディングチャンクとパラメーター」、RFC 4820、2007年3月。

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.

[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。

[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.

[RFC5238] Phelan、T。、「データグラムの混雑制御プロトコル（DCCP）上のデータグラム輸送層セキュリティ（DTLS）」、RFC 5238、2008年5月。

[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.

[RFC6083] Tuexen、M.、Seggelmann、R。、およびE. Rescorla、「Stream Control Transmission Protocol（SCTP）のデータグラム輸送層セキュリティ（DTLS）」、RFC 6083、2011年1月。

Authors' Addresses

著者のアドレス

Robin Seggelmann Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE

Robin Seggelmann Muenster University of Applied Sciences Stegerwaldstr。39 48565 Steinfurt de

   EMail: seggelmann@fh-muenster.de

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr。39 48565 Steinfurt de

   EMail: tuexen@fh-muenster.de

Michael Glenn Williams GWhiz Arts & Sciences 2885 Denise Court Newbury Park, CA, 91320 USA

マイケル・グレン・ウィリアムズ・GWHIZ芸術＆科学2885デニス・コート・ニューベリー・パーク、カリフォルニア州、91320 USA

   EMail: michael.glenn.williams@gmail.com