Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 6083 R. Seggelmann
Category: Standards Track Muenster Univ. of Applied Sciences
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
January 2011
Datagram Transport Layer Security (DTLS)
for Stream Control Transmission Protocol (SCTP)
Abstract
抽象
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).
この文書では、ストリーム制御伝送プロトコル（SCTP）を超えるデータグラムトランスポート層セキュリティ（DTLS）プロトコルの使用法を説明します。
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
SCTP上DTLSは、それらのトランスポートプロトコルとしてSCTPを使用するアプリケーションのための通信のプライバシーを提供し、クライアント/サーバアプリケーションは、盗聴を防止し、改ざんまたはメッセージ偽造を検出するように設計された方法で通信することを可能にします。
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions.
SCTP上でDTLSを使用するアプリケーションは、SCTPとその拡張機能が提供するほぼすべてのトランスポート機能を使用することができます。
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/rfc6083.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6083で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol, as defined in [RFC4347], over the Stream Control Transmission Protocol (SCTP), as defined in [RFC4960].
[RFC4347]で定義されるように[RFC4960]で定義されるように、この文書は、ストリーム制御伝送プロトコル（SCTP）を介して、データグラムトランスポート層セキュリティ（DTLS）プロトコルの使用を記載しています。
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
SCTP上DTLSは、それらのトランスポートプロトコルとしてSCTPを使用するアプリケーションのための通信のプライバシーを提供し、クライアント/サーバアプリケーションは、盗聴を防止し、改ざんまたはメッセージ偽造を検出するように設計された方法で通信することを可能にします。
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions.
SCTP上でDTLSを使用するアプリケーションは、SCTPとその拡張機能が提供するほぼすべてのトランスポート機能を使用することができます。
TLS, from which DTLS was derived, is designed to run on top of a byte-stream-oriented transport protocol providing a reliable, in-sequence delivery. Thus, TLS is currently mainly being used on top of the Transmission Control Protocol (TCP), as defined in [RFC0793].
DTLSが由来したTLSは、信頼性の高い、インシーケンス配信を提供するバイトストリーム指向のトランスポートプロトコルの上で動作するように設計されています。 [RFC0793]で定義されるようにこのように、TLSは、現在主に、伝送制御プロトコル（TCP）の上で使用されています。
TLS over SCTP as described in [RFC3436] has some serious limitations:
で説明したようにSCTPオーバーTLS [RFC3436]はいくつかの深刻な制限があります。
o It does not support the unordered delivery of SCTP user messages.
Oこれは、SCTPユーザメッセージの順不同配信をサポートしていません。
o It does not support partial reliability as defined in [RFC3758].
[RFC3758]で定義されているOこれは、部分的な信頼性をサポートしていません。
o It only supports the usage of the same number of streams in both directions.
Oそれは唯一の両方向でのストリームの同じ番号の使用をサポートしています。
o It uses a TLS connection for every bidirectional stream, which requires a substantial amount of resources and message exchanges if a large number of streams is used.
Oそれは、ストリームの多数が使用される場合、リソースとメッセージ交換のかなりの量を必要とするすべての双方向ストリームのためのTLS接続を使用します。
DTLS over SCTP as described in this document overcomes these limitations of TLS over SCTP. In particular, DTLS/SCTP supports:
この文書で説明するようにSCTPを超えるDTLSはSCTP上でTLSのこれらの制限を克服します。特に、DTLS / SCTPをサポートしています。
o preservation of message boundaries.
メッセージ境界のO保存。
o a large number of unidirectional and bidirectional streams.
単方向および双方向ストリームの多数O。
o ordered and unordered delivery of SCTP user messages.
O命じたとSCTPユーザメッセージの順不同配信。
o the partial reliability extension as defined in [RFC3758].
[RFC3758]で定義されるように部分的信頼性拡張O。
o the dynamic address reconfiguration extension as defined in [RFC5061].
[RFC5061]で定義されるように動的アドレス再構成拡張O。
However, the following limitations still apply:
ただし、以下の制限が適用されます：
o The maximum user message size is 2^14 bytes, which is the DTLS limit.
O最大ユーザメッセージサイズがDTLS限界である2 ^ 14バイトです。
o The DTLS user cannot perform the SCTP-AUTH key management because this is done by the DTLS layer.
これは、DTLS層によって行われるため、O DTLSのユーザーがSCTP-AUTHキー管理を実行することはできません。
The method described in this document requires that the SCTP implementation supports the optional feature of fragmentation of SCTP user messages as defined in [RFC4960] and the SCTP authentication extension defined in [RFC4895].
この文書に記載された方法は、[RFC4960]及び[RFC4895]で定義されたSCTP認証拡張で定義されているSCTP実装はSCTPユーザメッセージのフラグメンテーションのオプション機能をサポートすることを必要とします。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています：
Association: An SCTP association.
協会：SCTPアソシエーション。
Stream: A unidirectional stream of an SCTP association. It is uniquely identified by a stream identifier.
ストリーム：SCTPアソシエーションの一方向の流れ。これは、一意のストリーム識別子によって識別されます。
DTLS: Datagram Transport Layer Security
DTLS：データグラムトランスポート層セキュリティ
MTU: Maximum Transmission Unit
MTU：最大伝送単位
PPID: Payload Protocol Identifier
PPID：ペイロードプロトコル識別子
SCTP: Stream Control Transmission Protocol
SCTP：ストリーム制御伝送プロトコル
TCP: Transmission Control Protocol
TCP：伝送制御プロトコル
TLS: Transport Layer Security
TLS：トランスポート層セキュリティ
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document is based on [RFC4347], and it is expected that DTLS/ SCTP as described in this document will work with future versions of DTLS.
このドキュメントは[RFC4347]に基づいており、この文書で説明したようにDTLS / SCTPは、DTLSの将来のバージョンで動作することが期待されます。
DTLS limits the DTLS user message size to the current Path MTU minus the header sizes. For the purposes of running over SCTP, the DTLS path MTU MUST be considered to be 2^14.
DTLS電流経路MTUマイナスヘッダサイズにDTLSユーザメッセージのサイズを制限します。 SCTP上で動作する目的のために、DTLS経路MTUは、2 ^ 14であると見なされなければなりません。
The replay detection of DTLS may result in the DTLS layer dropping messages. Since DTLS/SCTP provides a reliable service if requested by the application, replay detection cannot be used. Therefore, replay detection of DTLS MUST NOT be used.
DTLSのリプレイ検出は、メッセージをドロップDTLS層をもたらすことができます。アプリケーションによって要求された場合DTLS / SCTPは、信頼性の高いサービスを提供するので、リプレイ検出を使用することはできません。したがって、DTLSのリプレイ検出を使用してはいけません。
SCTP provides Path MTU discovery and fragmentation/reassembly for user messages. According to Section 3.2, DTLS can send maximum sized messages. Therefore, Path MTU discovery of DTLS MUST NOT be used.
SCTPはユーザメッセージのパスMTUディスカバリおよび断片化/再構築を提供します。 3.2節によると、DTLSは、最大サイズのメッセージを送信することができます。したがって、DTLSのパスMTUディスカバリを使用してはいけません。
SCTP provides a reliable and in-sequence transport service for DTLS messages that require it. See Section 4.4. Therefore, DTLS procedures for retransmissions MUST NOT be used.
SCTPは、それを必要とDTLSメッセージの信頼性が高く、中・シーケンスの輸送サービスを提供します。 4.4節を参照してください。したがって、再送信のためのDTLSの手順を使用してはいけません。
The supported maximum length of SCTP user messages MUST be at least 2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of the DTLSCiphertext.fragment, and 13 is the size of the DTLS record header). In particular, the SCTP implementation MUST support fragmentation of user messages.
SCTPユーザメッセージのサポートされる最大長は^ 14 + 2048 + 13 = 18445バイト、少なくとも2（2 ^ 14 + 2048 DTLSCiphertext.fragmentの最大長さであり、13はDTLSレコードヘッダのサイズである）でなければなりません。特に、SCTPの実装では、ユーザメッセージの断片化をサポートしなければなりません。
Every SCTP user message MUST consist of exactly one DTLS record.
すべてのSCTPユーザメッセージは、1つのDTLSレコードで構成する必要があります。
Each DTLS connection MUST be established and terminated within the same SCTP association. A DTLS connection MUST NOT span multiple SCTP associations.
各DTLS接続が確立され、同じSCTPアソシエーション内に終了しなければなりません。 DTLS接続は、複数のSCTP関連付けをまたがってはなりません。
Application protocols using DTLS over SCTP SHOULD register and use a separate payload protocol identifier (PPID) and SHOULD NOT reuse the PPID that they registered for running directly over SCTP.
登録と別ペイロードプロトコル識別子（PPID）を使用し、それらはSCTP上で直接実行するための登録PPIDを再利用すべきでないSCTP上DTLSを使用してアプリケーションプロトコル。
Using the same PPID does not harm as long as the application can determine whether or not DTLS is used. However, for protocol analyzers, for example, it is much easier if a separate PPID is used.
同じPPIDを使用すると、限り、アプリケーションがDTLSが使用されているかどうかを判断することができますよう害はありません。しかしながら、プロトコルアナライザのために、例えば、別個のPPIDが使用される場合、はるかに簡単です。
This means, in particular, that there is no specific PPID for DTLS.
これは、DTLSのための具体的なPPIDがないことを、具体的には、意味します。
All DTLS messages of the ChangeCipherSpec, Alert, or Handshake protocol MUST be transported on stream 0 with unlimited reliability and with the ordered delivery feature.
ChangeCipherSpecを、アラート、またはハンドシェイクプロトコルのすべてのDTLSメッセージは、無制限の信頼性と注文した配信機能を持つストリーム0に輸送されなければなりません。
DTLS messages of the ApplicationData protocol SHOULD use multiple streams other than stream 0; they MAY use stream 0 for everything if they do not care about minimizing head of line blocking.
ストリーム0以外の複数のストリームを使用すべきであるapplicationDataにプロトコルのDTLSメッセージ。彼らはラインブロッキングのヘッドを最小限に気にしない場合、彼らはすべてのためにストリーム0を使用するかもしれません。
DATA chunks of SCTP MUST be sent in an authenticated way as described in [RFC4895]. Other chunks MAY be sent in an authenticated way. This makes sure that an attacker cannot modify the stream in which a message is sent or affect the ordered/unordered delivery of the message.
[RFC4895]に記載されているようにSCTPデータチャンクは、認証された方法で送信されなければなりません。他のチャンクは、認証された方法で送信することができます。これにより、攻撃者は、メッセージが送信されるストリームを変更したり、メッセージの順序付き/順不同配信に影響を与えることができないことを確認します。
If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST also be sent in an authenticated way as described in [RFC4895]. This makes sure that it is not possible for an attacker to drop messages and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this dropping.
PR-SCTP [RFC3758]で定義されるように使用される場合、FORWARD-TSNチャンクはまた、[RFC4895]に記載されているように認証された方法で送信されなければなりません。これにより、攻撃者はメッセージをドロップし、このドロップを非表示にする鍛造FORWARD-TSN、SACK、および/またはSHUTDOWNチャンクを使用することが不可能であることを確認します。
DTLS supports renegotiation, and therefore this feature is also available by DTLS/SCTP. It is up to the upper layer to use/allow it or not. Application writers should be aware that allowing renegotiations may result in changes of security parameters.
DTLSは、再交渉をサポートするため、この機能はDTLS / SCTPでも利用可能です。それはそれを許可したりない/使用する上位層までです。アプリケーションの作成者は、許可の再交渉は、セキュリティパラメータの変化をもたらす可能性があることに注意する必要があります。
A DTLS implementation discards DTLS messages from older epochs after some time, as described in Section 4.1 of [RFC4347]. This is not acceptable when the DTLS user performs a reliable data transfer. To avoid discarding messages, the following procedures are required.
[RFC4347]のセクション4.1で説明したようにDTLSの実装は、いくつかの時間後に古いエポックからDTLSメッセージを破棄します。 DTLSユーザは信頼性の高いデータ転送を行うとき、これは受け入れられません。メッセージを破棄しないようにするには、以下の手順が必要です。
Before sending a ChangeCipherSpec message, all outstanding SCTP user messages MUST have been acknowledged by the SCTP peer and MUST NOT be revoked by the SCTP peer.
ChangeCipherSpecをメッセージを送信する前に、すべての未処理のSCTPユーザメッセージは、SCTPピアによって確認されている必要がありますし、SCTPピアによって取り消されてはなりません。
Prior to processing a received ChangeCipherSpec, all other received SCTP user messages that are buffered in the SCTP layer MUST be read and processed by DTLS.
受信ChangeCipherSpecを処理する前に、SCTPレイヤにバッファリングされている他のすべての受信SCTPユーザメッセージが読み取られ、DTLSによって処理されなければなりません。
User messages that arrive between ChangeCipherSpec and Finished messages and use the new epoch have probably passed the Finished message and MUST be buffered by DTLS until the Finished message is read.
ChangeCipherSpecをとFinishedメッセージの間に到着し、新しい時代を使用するユーザー・メッセージは、おそらくFinishedメッセージを合格し、Finishedメッセージが読み込まれるまでDTLSによってバッファリングされなければなりません。
The endpoint-pair shared secret for Shared Key Identifier 0 is empty and MUST be used when establishing a DTLS connection. Whenever the master key changes, a 64-byte shared secret is derived from every master secret and provided as a new endpoint-pair shared secret by using the exporter described in [RFC5705]. The exporter MUST use the
共有キー識別子0のエンドポイント対共有秘密は空であり、DTLS接続を確立するときに使用されなければなりません。たびにマスターキーの変更は、64バイトの共有秘密は、すべてのマスターシークレットに由来し、[RFC5705]に記載の輸出を使用して、新しいエンドポイントペアの共有秘密として提供されます。輸出は、使用しなければなりません
label given in Section 5 and no context. The new Shared Key Identifier MUST be the old Shared Key Identifier incremented by 1. If the old one is 65535, the new one MUST be 1.
ラベルは、第5節なしコンテキストに与えられました。古いものが65535である場合、新しい共有キー識別子は、新しいものが1でなければならない、1つインクリメント古い共有キー識別子でなければなりません。
Before sending the Finished message, the active SCTP-AUTH key MUST be switched to the new one.
Finishedメッセージを送信する前に、アクティブSCTP-AUTHキーは、新しいものに切り替えなければなりません。
Once the corresponding Finished message from the peer has been received, the old SCTP-AUTH key SHOULD be removed.
ピアからの対応Finishedメッセージが受信されたら、古いSCTP-AUTHキーが除去されるべきです。
To prevent DTLS from discarding DTLS user messages while it is shutting down, a CloseNotify message MUST only be sent after all outstanding SCTP user messages have been acknowledged by the SCTP peer and MUST NOT still be revoked by the SCTP peer.
それがシャットダウンしている間、DTLSのユーザーメッセージを破棄からDTLSを防ぐために、CloseNotifyメッセージのみをSCTPピアによって承認されているすべての未SCTPユーザメッセージの後に送らなければなりませんし、まだSCTPピアによって取り消されてはなりません。
Prior to processing a received CloseNotify, all other received SCTP user messages that are buffered in the SCTP layer MUST be read and processed by DTLS.
受信CloseNotifyを処理する前に、SCTPレイヤにバッファリングされている他のすべての受信SCTPユーザメッセージが読み取られ、DTLSによって処理されなければなりません。
IANA added a value to the TLS Exporter Label registry as described in [RFC5705]. The label is "EXPORTER_DTLS_OVER_SCTP".
[RFC5705]で説明されるようにIANAは、TLS輸出ラベルレジストリに値を追加しました。ラベルには「EXPORTER_DTLS_OVER_SCTP」です。
The security considerations given in [RFC4347], [RFC4895], and [RFC4960] also apply to this document.
[RFC4347]、[RFC4895]、および[RFC4960]で与えられたセキュリティ上の考慮事項はまた、この文書に適用されます。
It is possible to authenticate DTLS endpoints based on IP addresses in certificates. SCTP associations can use multiple addresses per SCTP endpoint. Therefore, it is possible that DTLS records will be sent from a different IP address than that originally authenticated. This is not a problem provided that no security decisions are made based on that IP address. This is a special case of a general rule: all decisions should be based on the peer's authenticated identity, not on its transport layer identity.
証明書内のIPアドレスに基づいてDTLSエンドポイントを認証することが可能です。 SCTP協会はSCTP端末ごとに複数のアドレスを使用することができます。したがって、DTLSレコードが最初に認証されたものとは異なるIPアドレスから送信される可能性があります。これには、セキュリティの決定はそのIPアドレスに基づいて行われていないことを提供する問題ではありません。これは、一般的なルールの特殊ケースである：すべての決定は、ピアの認証されたアイデンティティのではなく、そのトランスポート層のアイデンティティに基づくべきです。
For each message, the SCTP user also provides a stream identifier, a flag to indicate whether the message is sent ordered or unordered, and a payload protocol identifier. Although DTLS can be used to provide privacy for the actual user message, none of these three are protected by DTLS. They are sent as clear text, because they are part of the SCTP DATA chunk header.
各メッセージのために、SCTPユーザはまた、フラグは、メッセージが順序付きまたは順序なし、ペイロードプロトコル識別子送信されるかどうかを示すために、ストリーム識別子を提供します。 DTLSは、実際のユーザメッセージのプライバシーを提供するために使用することができますが、これら三つのどれもがDTLSにより保護されていません。彼らはSCTPデータチャンクヘッダの一部であるので、彼らは、クリアテキストとして送信されます。
DTLS supports cipher suites that contain a NULL cipher algorithm. Negotiating a NULL cipher algorithm will not provide communications privacy for applications and will not provide privacy for user messages.
DTLSは、NULL暗号化アルゴリズムが含まれている暗号スイートをサポートしています。 NULL暗号化アルゴリズムを交渉することはアプリケーションのための通信プライバシーを提供することはありませんし、ユーザメッセージのプライバシーを提供することはありません。
The authors wish to thank Anna Brunstrom, Lars Eggert, Gorry Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan Lindskog, Daniel Mentz, and Sean Turner for their invaluable comments.
作者は彼らの貴重なコメントをアンナBrunstrom、ラースEggertの、Gorry Fairhurst、イアン・ゴールドバーグ、アルフレッドHoenes、カールステンHohendorf、ステファンLindskog、ダニエルMentz、そしてショーン・ターナーに感謝したいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895] Tuexen、M.、スチュワート、R.、レイ、P.、およびE.レスコラ、 "ストリーム制御伝送プロトコル（SCTP）に対して認証チャンク"、RFC 4895、2007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705]レスコラ、E.、RFC 5705 "トランスポート層セキュリティ（TLS）のための鍵材料輸出"、2010年3月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436] Jungmaier、A.、レスコラ、E.、およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]スチュワート、R.、謝、Q.、Tuexen、M.、丸山、S.、およびM.小塚、 "ストリーム制御伝送プロトコル（SCTP）動的アドレス再構成"、RFC 5061、2007年9月。
Authors' Addresses
著者のアドレス
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのマイケルTuexenミュンスター大学。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
メールアドレス：tuexen@fh-muenster.de
Robin Seggelmann Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのロビンSeggelmannミュンスター大学。 39 48565シュタインフルトドイツ
EMail: seggelmann@fh-muenster.de
メールアドレス：seggelmann@fh-muenster.de
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
エリックレスコラRTFM、Inc.の2064エッジウッドドライブパロアルト、CA 94303 USA
EMail: ekr@networkresonance.com
メールアドレス：ekr@networkresonance.com