Internet Engineering Task Force (IETF) X. Fu
Request for Comments: 6084 C. Dickmann
Category: Experimental University of Goettingen
ISSN: 2070-1721 J. Crowcroft
University of Cambridge
January 2011
General Internet Signaling Transport (GIST)
over Stream Control Transmission Protocol (SCTP)
and Datagram Transport Layer Security (DTLS)
Abstract
抽象
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS).
一般的なインターネットシグナリングトランスポート（GIST）プロトコルは、現在の接続モード動作のためにTCP上のTCPまたはTransport Layer Security（TLS）を使用しています。この文書では、ストリーム制御伝送プロトコル（SCTP）およびデータグラムトランスポート層セキュリティ（DTLS）を超えるGISTの使用方法について説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6084.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6084で取得することができます。
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ライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Association Setup . . . . . . . . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multihoming Support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming Support in SCTP . . . . . . . . . . . . . . . . 8
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
This document describes the usage of the General Internet Signaling Transport (GIST) protocol [1] and Datagram Transport Layer Security (DTLS) [2].
この文書は、一般的なインターネットシグナリングトランスポート（GIST）プロトコルの使用法を説明し、[1]とデータグラムトランスポート層セキュリティ（DTLS）[2]。
GIST, in its initial specification for Connection mode (C-mode) operation, runs on top of a byte-stream-oriented transport protocol providing a reliable, in-sequence delivery, i.e., using the Transmission Control Protocol (TCP) [9] for signaling message transport. However, some Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] context information has a definite lifetime; therefore, the GIST transport protocol could benefit from flexible retransmission, so stale NSLP messages that are held up by congestion can be dropped. Together with the head-of-line blocking and multihoming issues with TCP, these considerations argue that implementations of GIST should support SCTP as an optional transport protocol for GIST. Like TCP, SCTP supports reliability, congestion control, and fragmentation. Unlike TCP, SCTP provides a number of functions that are desirable for signaling transport, such as multiple streams and multiple IP addresses for path failure recovery. Furthermore, SCTP offers an advantage of message-oriented transport instead of using the byte-stream-oriented TCP where the framing mechanisms must be provided separately. In addition, its Partial Reliability extension (PR-SCTP) [3] supports partial retransmission based on a programmable retransmission timer. Furthermore, DTLS provides a viable solution for securing SCTP [4], which allows SCTP to use almost all of its transport features and its extensions.
GISTは、接続モード（Cモード）動作のための初期仕様で、伝送制御プロトコル（TCP）を使用して、信頼性の高い、インシーケンス送達、すなわちを提供するバイトストリーム指向のトランスポートプロトコルの上で動作する[9]メッセージトランスポートに信号を送るため。しかし、いくつかのシグナル伝達における次のステップ（NSIS）シグナリング層プロトコル（NSLP）[10]コンテキスト情報は、明確な寿命を有します。従って、GISTトランスポート・プロトコルは、可撓性の再送信から利益を得ることができるので、渋滞によってアップ保持されている失効NSLPメッセージは破棄することができます。一緒にTCPとヘッドオブラインブロッキングとマルチホーミング問題と、これらの考慮事項は、GISTの実装はGISTのための任意のトランスポートプロトコルとしてSCTPをサポートしなければならないと主張しています。 TCPのように、SCTPは、信頼性、輻輳制御、および断片化をサポートしています。 TCPとは異なり、SCTPは、複数のストリームとパス障害回復のための複数のIPアドレスなどの輸送をシグナリングするために望ましい多数の機能を提供します。また、SCTPは、フレーミング機構を別途設けなければならないバイトストリーム指向のTCPを使用する代わりに、メッセージ指向の輸送の利点を提供します。また、その部分の信頼性延長（PR-SCTP）[3]プログラマブル再送タイマに基づいて部分的に再送信をサポートしています。また、DTLSは、SCTPは、ほぼすべての輸送機能とその拡張のを使用することを可能にする[4] SCTPを固定するための実行可能な解決策を提供します。
This document defines the use of SCTP as the underlying transport protocol for GIST and the use of DTLS as a security mechanism for protecting GIST Messaging Associations and discusses the implications on GIST state maintenance and API between GIST and NSLPs. Furthermore, this document describes how GIST is transported over SCTP and used by NSLPs in order to exploit the additional capabilities offered by SCTP to deliver GIST C-mode messages more effectively. More specifically:
この文書では、GISTのための基礎となるトランスポートプロトコル及びGISTメッセージング関連付けを保護するためのセキュリティ機構としてDTLSの使用としてSCTPの使用を定義し、GISTとNSLPs間GIST状態の維持及びAPIに影響を論じています。さらに、この文書は、GISTはSCTP上で転送し、より効果的にGIST Cモードメッセージを配信するためにSCTPによって提供される追加機能を利用するためにNSLPsで使用されている方法を説明します。すなわち：
o How to use the multiple streams feature of SCTP.
O SCTPの複数のストリーム機能を使用する方法。
o How to use the PR-SCTP extension of SCTP.
O SCTPのPR-SCTP拡張を使用する方法。
o How to take advantage of the multihoming support of SCTP.
O SCTPのマルチホーミングサポートを利用する方法。
GIST over SCTP as described in this document does not require any changes to the high-level operation and structure of GIST. However, adding new transport options requires additional interface code and configuration support to allow applications to exploit the additional transport when appropriate. In addition, SCTP implementations to transport GIST MUST support the optional feature of fragmentation of SCTP user messages.
この文書に記載されているようにSCTP上GISTはGISTの高レベルの操作及び構造の変更を必要としません。しかし、新しいトランスポートオプションを追加するときに適切なアプリケーションが追加の輸送を活用できるようにするために、追加のインターフェイスのコードと構成のサポートが必要です。また、GISTを搬送するSCTP実装はSCTPユーザメッセージのフラグメンテーションのオプション機能をサポートしなければなりません。
Additionally, this document also specifies how to establish GIST security using DTLS for use in combination with, e.g., SCTP and UDP.
また、この文書はまた、例えば、SCTPおよびUDPと組み合わせて使用するためDTLSを使用してGISTのセキュリティを確立する方法を指定します。
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 [5]. Other terminologies and abbreviations used in this document are taken from related specifications ([1], [2], [3], [6]):
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[5]で説明されるように解釈されます。本書で使用される他の用語と略語は関連する仕様から取られる（[1]、[2]、[3]、[6]）。
o SCTP - Stream Control Transmission Protocol
OのSCTP - ストリーム制御伝送プロトコル
o PR-SCTP - SCTP Partial Reliability Extension
O PR-SCTP - SCTP部分的な信頼性の拡張
o MRM - Message Routing Method
MRM O - メッセージのルーティング方法
o MRI - Message Routing Information
O MRI - メッセージルーティング情報
o SCD - Stack-Configuration-Data
O SCD - スタックの構成 - データ
o Messaging Association (MA) - A single connection between two explicitly identified GIST adjacent peers, i.e., between a given signaling source and destination address. A messaging association may use a transport protocol; if security protection is required, it may use a specific network layer security association, or use a transport layer security association internally. A messaging association is bidirectional: signaling messages can be sent over it in either direction, referring to flows of either direction.
Oメッセージング・アソシエーション（MA） - 2つの明示的に識別GIST隣接ピア間の単一の接続、すなわち、所与の信号ソースと宛先アドレスとの間。メッセージング・アソシエーションは、トランスポートプロトコルを使用してもよいです。セキュリティ保護が必要な場合、それは特定のネットワーク層セキュリティアソシエーションを使用し、または内部トランスポート層セキュリティアソシエーションを使用することができます。メッセージング・アソシエーションは、双方向である：シグナリングメッセージは、いずれかの方向の流れを参照し、いずれかの方向にそれを介して送信することができます。
o SCTP Association - A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time.
O SCTPアソシエーション - SCTPエンドポイント間プロトコル関係は二つのSCTPエンドポイントおよびプロトコル状態情報からなります。関連付けは一意に関連して、エンドポイントによって使用されるトランスポート・アドレスによって同定することができます。二つのSCTPエンドポイントは、任意の時点で、それらの間に複数のSCTPアソシエーションを持ってはいけません。
o Stream - A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service.
Oストリーム - すべてのユーザーメッセージが順不同配信サービスに提出されるものを除いて配列で配信される内の別の関連SCTPエンドポイント、1つの確立された一方向の論理チャネル。
This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for using SCTP as the GIST transport protocol. The use of DTLS in GIST is defined in Section 7.
このセクションでは、GISTのトランスポートプロトコルとしてSCTPを使用するため、「フォワード・SCTP」、新たなMA-プロトコルIDのタイプを定義します。 GISTでのDTLSの使用はセクション7で定義されています。
The basic GIST protocol specification defines two possible protocols to be used in Messaging Associations, namely Forwards-TCP and TLS. This information is a main part of the Stack Configuration Data (SCD) [1]. This section adds Forwards-SCTP (value 3) as another possible protocol option. In Forwards-SCTP, analog to Forwards-TCP, connections between peers are opened in the forwards direction, from the querying node, towards the responder.
基本的なGISTプロトコル仕様は、メッセージ関連付けに使用される2つの可能なプロトコル、即ち転送し、TCPとTLSを定義します。この情報は、スタック構成データ（SCD）の主要部である[1]。このセクションでは、別の可能なプロトコルオプションとして転送し、SCTP（値3）を加算します。フォワード-SCTP、転送し、TCPアナログにおいて、ピア間の接続がレスポンダに向かって、クエリノードから、前方方向に開口しています。
The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP between peers. Support for this protocol is OPTIONAL. If this protocol is offered, MA-protocol-options data MUST also be carried in the SCD object. The MA-protocol-options field formats are:
「フォワード-SCTP」MA-プロトコル-IDは、ピア間のSCTPの基本的な使用を示しています。このプロトコルのサポートはオプションです。このプロトコルが提供される場合、MA-プロトコルオプションデータは、SCDのオブジェクトに実行されなければなりません。 MA-プロトコル・オプション・フィールドの形式は次のとおりです。
o in a Query: no information apart from the field header.
クエリ中のO：フィールドヘッダから離れない情報。
o in a Response: 2-byte port number at which the connection will be accepted, followed by 2 pad bytes.
応答中のO 2つのパッドバイトが続く接続が受け入れられるれる2バイトのポート番号、。
The connection is opened in the forwards direction, from the querying node towards the responder. The querying node MAY use any source address and source port. The destination for establishing the message association MUST be derived from information in the Response: the address from the interface-address in the Network-Layer-Information object and the port from the SCD object as described above.
接続がレスポンダに向かってクエリノードから、前方方向に開口しています。クエリノードは、任意の送信元アドレスと送信元ポートを使用するかもしれません。メッセージ・アソシエーションを確立するための宛先は、応答内の情報から導出されなければならない：ネットワークレイヤ情報オブジェクトとSCDオブジェクトからポートのインターフェイスアドレスからのアドレスは、上述のように。
Associations using Forwards-SCTP can carry messages with the transfer attribute Reliable=True. If an error occurs on the SCTP connection such as a reset, as can be reported by an SCTP socket API notification [11], GIST MUST report this to NSLPs as discussed in Section 4.1.2 of [1]. For the multihoming scenario, when a destination address of a GIST-over-SCTP peer encounters a change, the SCTP API will notify GIST about the availability of different SCTP endpoint addresses and the possible change of the primary path.
転送にメッセージを伝えることができます転送し-SCTPを使用して関連付けをTrue =信頼性の高い属性。エラーは、リセットとしてSCTP接続上で発生した場合はSCTPソケットAPI通知[11]によって報告することができるように、[1]のセクション4.1.2で説明したように、GISTはNSLPsに報告しなければなりません。 GISTオーバーSCTPピアの宛先アドレスが変化を検出したときマルチホーミングシナリオでは、SCTP APIは異なるSCTPエンドポイントアドレスの可用性とプライマリパスの可能な変化についてGISTを通知します。
As SCTP provides additional functionality over TCP, this section discusses the implications of using GIST over SCTP on GIST state maintenance.
SCTPは、TCP上の追加機能を提供するように、このセクションでは、GISTの状態の維持にSCTP上GISTを使用することの意味を説明します。
While SCTP defines unidirectional streams, for the purpose of this document, the concept of a bidirectional stream is used. Implementations MUST establish both downstream and upstream (unidirectional) SCTP streams and use the same stream identifier in both directions. Thus, the two unidirectional streams (in opposite directions) form a bidirectional stream.
SCTPは、一方向の流れを定義しますが、このドキュメントの目的のために、双方向ストリームの概念が使用されています。実装は、両方のダウンストリーム及びアップストリーム（一方向）SCTPストリームを確立し、両方向に同じストリーム識別子を使用しなければなりません。したがって、（反対方向に）2つの単方向ストリームは、双方向ストリームを形成します。
Due to the multi-streaming support of SCTP, it is possible to use different SCTP streams for different resources (e.g., different NSLP sessions), rather than maintaining all messages along the same transport connection/association in a correlated fashion as TCP (which imposes strict (re)ordering and reliability per transport level). However, there are limitations to the use of multi-streaming. When an SCTP implementation is used for GIST transport, all GIST messages for a particular session MUST be sent over the same SCTP stream to assure the NSLP assumption of in-order delivery. Multiple sessions MAY share the same SCTP stream based on local policy.
SCTPのマルチストリーミングをサポートし、課した（むしろTCPとして相関様式で同じトランスポート接続/アソシエーションに沿ってすべてのメッセージを維持するよりも、異なるリソースに対して異なるSCTPストリーム（例えば、異なるNSLPセッション）を、使用することが可能です厳密な（再）順序とトランスポートレベルごとに信頼度）。しかし、マルチストリーミングを使用するには限界があります。 SCTP実装はGISTの輸送のために使用される場合、特定のセッションのすべてのGISTメッセージは、順序配信のNSLPの仮定を保証するために、同一のSCTPストリームを介して送信されなければなりません。複数のセッションは、ローカルポリシーに基づいて、同じSCTPストリームを共有することがあります。
The GIST concept of Messaging Association re-use is not affected by this document or the use of SCTP. All rules defined in the GIST specification remain valid in the context of GIST over SCTP.
メッセージング協会再利用のGISTの概念は、この文書またはSCTPの使用に影響されません。 GISTの仕様で定義されたすべてのルールがSCTPを超えるGISTのコンテキストで有効なまま。
A variant of SCTP, PR-SCTP [3] provides a "timed reliability" service, which would be particularly useful for delivering GIST Connection mode messages. It allows the user to specify, on a per-message basis, the rules governing how persistent the transport service should be in attempting to send the message to the receiver. Because of the chunk bundling function of SCTP, reliable and partially reliable messages can be multiplexed over a single PR-SCTP association. Therefore, an SCTP implementation for GIST transport SHOULD attempt to establish a PR-SCTP association using "timed reliability" service instead of a standard SCTP association, if available, to support more flexible transport features for potential needs of different NSLPs.
SCTPの変異体、PR-SCTP [3] GIST接続モードメッセージを送達するために特に有用であろう「時限信頼」サービスを提供します。これは、メッセージごとに、ユーザーが指定することができ、輸送サービスが受信者にメッセージを送信しようとする中でどうあるべきか、永続規定する規則。そのためSCTPのチャンク束ねる機能で、信頼性が高く、部分的に信頼性の高いメッセージは、単一のPR-SCTPアソシエーション上で多重化することができます。したがって、GISTの輸送のためのSCTPの実装が可能な場合は、別のNSLPsの潜在的なニーズに、より柔軟な輸送機能をサポートするために、代わりに標準のSCTP協会の「時限信頼性」のサービスを利用してPR-SCTPアソシエーションを確立しようとすべきです。
When using a normally reliable session (as opposed to a partially reliable session), if a node has sent the first transmission before the lifetime expires, then the message MUST be sent as a normal reliable message. During episodes of congestion, this is particularly unfortunate, as retransmission wastes bandwidth that could have been used for other (non-lifetime expired) messages. The "timed reliability" service in PR-SCTP eliminates this issue and is hence RECOMMENDED to be used for GIST over PR-SCTP.
通常、信頼できるセッションを（部分的に信頼できるセッションとは対照的に）使用する場合、寿命が満了する前に、ノードは、第1の送信を送信した場合、そのメッセージは、通常の信頼性のあるメッセージとして送信しなければなりません。混雑のエピソードの間に、これは他の（非存続期間の期限が切れ）のメッセージのために使用されている可能性が再送廃棄物の帯域幅として、特に残念なことです。 PR-SCTPにおける「時限式の信頼性」のサービスは、この問題を排除し、したがって、PR-SCTPを超えるGISTのために使用されることをお勧めします。
The GIST specification defines an abstract API between GIST and NSLPs. While this document does not change the API itself, the semantics of some parameters have slightly different interpretations in the context of SCTP. This section only lists those primitives and parameters that need special consideration when used in the context of SCTP. The relevant primitives from [1] are as follows:
GIST仕様は、GISTとNSLPs間の抽象APIを定義します。このドキュメントでは、API自体は変更されませんが、いくつかのパラメータの意味は、SCTPの文脈では、わずかに異なる解釈を持っています。このセクションではSCTPのコンテキストで使用された場合、特別な配慮を必要とするプリミティブとパラメータを示します。次のように[1]から関連するプリミティブは、次のとおり
o The Timeout parameter in API "SendMessage": According to [1], this parameter represents the "length of time GIST should attempt to send this message before indicating an error". When used with PR-SCTP, this parameter is used as the timeout for the "timed reliability" service of PR-SCTP.
API「のSendMessage」におけるタイムアウトパラメータ○：[1]によれば、このパラメータが「エラーを示す前に、このメッセージを送信しようとする時間のGISTの長さ」を表します。 PR-SCTPを使用した場合、このパラメータは、PR-SCTPの「時限信頼性」サービスのタイムアウトとして使用されています。
o "NetworkNotification": According to [1], this primitive "is passed from GIST to a signalling application. It indicates that a network event of possible interest to the signalling application occurred". Here, if SCTP detects a failure of the primary path, GIST SHOULD also indicate this event to the NSLP by calling this primitive with Network-Notification-Type "Routing Status Change". This notification should be done even if SCTP was able to retain an open connection to the peer due to its multihoming capabilities.
O「NetworkNotification」は：[1]によれば、このプリミティブは、「シグナリングアプリケーションにGISTから渡され、それがシグナリングアプリケーションへの可能な関心のネットワークイベントが発生したことを示しています。」。 SCTPは、プライマリパスの障害を検出した場合ここでは、GISTはまた、「ステータス変更をルーティング」ネットワーク-notification-typeにして、このプリミティブを呼び出すことにより、NSLPにこのイベントを示すべきです。この通知は、SCTPは、そのマルチホーミング機能にピアへのオープン接続を維持することができた場合にも行われるべきです。
This section provides the bit-level format for the MA-protocol-options field that is used for SCTP protocol in the Stack-Configuration-Data object of GIST.
このセクションでは、GISTのスタック構成、データオブジェクト内のSCTPプロトコルのために使用されるMA-プロトコルオプションフィールドのビット・レベル・フォーマットを提供します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SCTP port number | Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCTP port number = Port number at which the responder will accept SCTP connections
SCTPポート番号=レスポンダがSCTP接続を受け入れるポート番号
The SCTP port number is only supplied if sent by the responder.
応答者によって送られた場合はSCTPポート番号のみが供給されています。
In general, the multihoming support of SCTP can be used to improve fault-tolerance in case of a path or link failure. Thus, GIST over SCTP would be able to deliver NSLP messages between peers even if the primary path is not working anymore. However, for the Message Routing Methods (MRMs) defined in the basic GIST specification, such a feature is only of limited use. The default MRM is path-coupled, which means that if the primary path is failing for the SCTP association, it most likely is also failing for the IP traffic that is signaled for. Thus, GIST would need to perform a refresh to the NSIS nodes to the alternative path anyway to cope with the route change. When the two endpoints of a multihomed SCTP association (but none of the intermediate nodes between them) support NSIS, GIST over SCTP provides a robust means for GIST to deliver NSLP messages even when the primary path fails but at least one alternative path between these (NSIS-enabled) endpoints of the multihomed path is available. Additionally, the use of the multihoming support of SCTP provides GIST and the NSLP with another source to detect route changes. Furthermore, for the time between detection of the route change and recovering from it, the alternative path offered by SCTP can be used by the NSLP to make the transition more smoothly. Finally, future MRMs might have different properties and therefore benefit from multihoming more broadly.
一般的に、SCTPのマルチホーミング支援は、パスまたはリンク障害が発生した場合にフォールトトレランスを向上させるために使用することができます。このように、SCTPを超えるGISTは、プライマリパスはもう働いていない場合でも、ピア間NSLPメッセージを配信することができるだろう。しかし、基本的なGIST仕様で定義されたメッセージルーティング方法（のMRM）のために、そのような機能は、制限された使用です。デフォルトMRMは、パス結合、プライマリパスがSCTPアソシエーションに失敗している場合は、それが最も可能性の高いもの合図をしているIPトラフィックに失敗していることを意味しています。したがって、GISTは、ルート変更に対応するために、とにかく代替パスにNSISノードにリフレッシュを実行する必要があります。マルチホームのSCTPアソシエーション（それらの間の中間ノードのいずれも）の2つのエンドポイントは、NSISをサポートする場合、SCTP上GISTは、プライマリパスに障害が発生した場合でもNSLPメッセージを配信するGISTが、これらの間に少なくとも1つの代替経路（のためのロバストな手段を提供しますNSIS対応）マルチホームパスのエンドポイントが利用可能です。また、SCTPのマルチホーミング支援の使用は、ルート変更を検出するための別のソースとGIST及びNSLPを提供します。また、経路変更を検出し、そこから回復するまでの時間のために、SCTPによって提供される代替パスをより円滑遷移するNSLPによって使用することができます。最後に、将来のMRMは、異なる特性を持っているため、より広くマルチホーミングの恩恵を受ける可能性があります。
Streaming support in SCTP is advantageous for GIST. It allows better parallel processing, in particular by avoiding the head-of-line blocking issue in TCP. Since a single GIST MA may be reused by multiple sessions, using TCP as the transport for GIST signaling messages belonging to different sessions may be blocked if another message is dropped. In the case of SCTP, this can be avoided, as different sessions having different requirements can belong to different streams; thus, a message loss or reordering in a stream will only affect the delivery of messages within that particular stream, and not any other streams.
SCTPでのサポートをストリーミングすることはGISTのために有利です。これは、TCPでのヘッドオブラインブロッキングの問題を回避することにより、特に優れた並列処理を可能にします。単一GISTのMAので、別のメッセージが廃棄された場合にブロックされることができる異なるセッションに属するGISTシグナリングメッセージのためのトランスポートとしてTCPを使用して、複数のセッションで再利用することができます。 SCTPの場合、これは、異なるストリームに属することができ、さまざまな要件を有する異なるセッションとして、回避することができます。従って、ストリーム内のメッセージ損失または再順序付けは、その特定のストリーム内のメッセージではなく、任意の他のストリームの配信に影響を与えます。
NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and the GIST extensibility capabilities defined in [12]. This specification does not define NAT traversal procedures for GIST over SCTP, although an approach for SCTP NAT traversal is described in [13].
SCTP上GISTのNATトラバーサルは、[1]のセクション7.2及び[12]で定義されたGISTの拡張機能に従います。 SCTP NATトラバーサルのためのアプローチは、[13]に記載されているが、この明細書は、SCTP上GISTのNATトラバーサル手順を定義していません。
This section specifies a new MA-Protocol-ID "DTLS" (value 4) for the use of DTLS in GIST, which denotes a basic use of datagram transport layer channel security, initially in conjunction with GIST over SCTP. It provides server (i.e., GIST transport receiver) authentication and integrity (as long as the NULL ciphersuite is not selected during ciphersuite negotiation), as well as optionally replay protection for control packets. The use of DTLS for securing GIST over SCTP allows GIST to take the advantage of features provided by SCTP and its extensions. The usage of DTLS for GIST over SCTP is similar to TLS for GIST as specified in [1], where a stack-proposal containing both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase.
このセクションでは、GISTでDTLSを使用するための新たなMA-プロトコルID「DTLS」（値4）を指定し、最初にSCTP上GISTと連動して、データグラムトランスポート層セキュリティチャネルの基本的な使用を示しています。これは、サーバー（即ち、GIST搬送受信機）認証および完全性（あればNULLの暗号スイートを暗号スイートネゴシエーション時に選択されないように）、ならびに制御パケットのための必要に応じて再生保護を提供します。 SCTP上GISTを確保するためのDTLSを使用することは、GISTはSCTPおよびその拡張によって提供される機能を利用することができます。スタック提案はGISTハンドシェークフェーズ中にSCTP及びDTLSの両方MA-プロトコルIDを含むSCTP上GISTためDTLSの使用[1]で指定されるようにGISTためにTLSと同様です。
The usage of DTLS [2] for securing GIST over datagram transport protocols MUST be implemented and SHOULD be used.
データグラムトランスポートプロトコル上GISTを確保するための[2] DTLSの使用を実装する必要があり、使用されるべきです。
GIST message associations using DTLS may carry messages with transfer attributes requesting confidentiality or integrity protection. The specific DTLS version will be negotiated within the DTLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to DTLS v1.0 and MUST use the highest protocol version supported by both peers. NULL authentication and integrity ciphers MUST NOT be negotiated for GIST nodes supporting DTLS. For confidentiality ciphers, nodes can negotiate the NULL ciphersuites. The same rules for negotiating TLS ciphersuites as specified in Section 5.7.3 of [1] apply.
DTLSを使用したGISTメッセージ団体は、機密性や完全性の保護を要求して転送属性を持つメッセージを運ぶことができます。特定DTLSバージョンはDTLS層自体内でネゴシエートされますが、実装はDTLS v1.0の前にプロトコルバージョンに交渉してはいけませんし、両方のピアによってサポートされる最も高いプロトコルバージョンを使用しなければなりません。 NULL認証と完全性暗号はDTLSをサポートGISTノードについて交渉してはいけません。機密暗号の場合、ノードは、NULL暗号スイートを交渉することができます。 [1]適用のセクション5.7.3で指定されたTLS暗号スイートを交渉するための同じ規則。
DTLS renegotiation [7] may cause problems for applications such that connection security parameters can change without the application knowing it. Hence, it is RECOMMENDED that renegotiation be disabled for GIST over DTLS.
DTLSの再ネゴシエーションは、[7]接続のセキュリティパラメータがそれを知っアプリケーションなしに変更することができるように、アプリケーションで問題が発生することがあります。したがって、再交渉がDTLSを超えるGISTのために無効にすることをお勧めします。
No MA-protocol-options field is required for DTLS. The configuration information for the transport protocol over which DTLS is running (e.g., SCTP port number) is provided by the MA-protocol-options for that protocol.
いいえMA-プロトコル・オプション・フィールドは、DTLSのために必要とされません。 DTLSが実行されている上にトランスポートプロトコル（例えば、SCTPポート番号）の設定情報は、そのプロトコルのMA-プロトコルオプションによって提供されます。
The security considerations of [1], [6], and [2] apply. Additionally, although [4] does not support replay detection in DTLS over SCTP, the SCTP replay protection mechanisms [6] [8] should be able to protect NSIS messages transported using GIST over (DTLS over) SCTP from replay attacks.
セキュリティの考慮事項[1]、[6]及び[2]を適用します。 [4] SCTP上DTLSでリプレイ検出をサポートしていないが、さらに、SCTPリプレイ保護メカニズムは、[6] [8]リプレイ攻撃から（DTLS上）SCTP上GISTを用いて搬送NSISメッセージを保護することができなければなりません。
According to this specification, IANA has registered the following codepoints (MA-Protocol-IDs) in a registry created by [1]:
この仕様によれば、IANA [1]によって作成されたレジストリの次のコードポイント（MA-プロトコルID）を登録しています。
+---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction |
| | |
| 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+
Note that MA-Protocol-ID "DTLS" is never used alone but always coupled with a transport protocol specified in the stack proposal.
MA-プロトコル-ID「DTLSは」単独で使用しないが、常にスタックの提案で指定されたトランスポートプロトコルと結合しないことに注意してください。
The authors would like to thank John Loughney, Jukka Manner, Magnus Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their helpful suggestions.
著者はジョンLoughney、ユッカマナー、マグヌスウェスター、ショーン・ターナー、ラースEggertの、ジェフリーHutzelman、ロバート・ハンコック、アンドリュー・マクドナルド、マーティンStiemerling、牙 - チョン・クオ、ヤンDemter、ラウリLiuhto、マイケルTuexen、およびローランド祝福に感謝したいと思います彼らの有益な提案のため。
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[1] Schulzrinneと、H.とR.ハンコック、 "GIST：一般的なインターネットシグナリング交通"、RFC 5971、2010年10月。
[2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[2]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[3]スチュワート、R.、Ramalho、M.、謝、Q.、Tuexen、M.、およびP.コンラッド、 "ストリーム制御伝送プロトコル（SCTP）部分的な信頼性拡張"、RFC 3758、2004年5月。
[4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011.
[4] Tuexen、M.、Seggelmann、R.、および、RFC 6083、2011年1月 "ストリーム制御伝送プロトコル（SCTP）のためのデータグラムトランスポート層セキュリティ（DTLS）" E.レスコラ、。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[6]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[7]レスコラ、E.、レイ、M.、Dispensa、S.、およびN. Oskov、 "トランスポート層セキュリティ（TLS）再ネゴシエーション指示拡張子"、RFC 5746、2010年2月。
[8] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[8] Tuexen、M.、スチュワート、R.、レイ、P.、およびE.レスコラ、 "ストリーム制御伝送プロトコル（SCTP）に対して認証チャンク"、RFC 4895、2007年8月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
[10]ハンコック、R.、Karagiannis、G.、Loughney、J.、およびS.ヴァンデンボッシュ、 "シグナル伝達における次のステップ（NSIS）：フレームワーク"、RFC 4080、2005年6月。
[11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, January 2011.
[11]スチュワート、R.、プーン、K.、Tuexen、M.、Yasevich、V.、およびP.レイ、進歩、2011年1月の作業 "ストリーム制御伝送プロトコル（SCTP）のためのソケットAPIの拡張機能"。
[12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
2010年10月、RFC 5978 "NSISプロトコルファミリを使用し、拡張" [12]ようにして、J.、ブレス、R.、Loughney、J.、およびE.デイヴィス、。
[13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, December 2010.
[13]スチュワート、R.、Tuexen、M.、およびI. Ruengeler、 "ストリーム制御伝送プロトコル（SCTP）ネットワークアドレス変換"、進歩、2010年12月ワーク。
Authors' Addresses
著者のアドレス
Xiaoming Fu University of Goettingen Institute of Computer Science Goldschmidtstr. 7 Goettingen 37077 Germany
コンピュータサイエンスGoldschmidtstrのゲッティンゲン大学の暁明フー大学。 7ゲッティンゲン37077ドイツ
EMail: fu@cs.uni-goettingen.de
メールアドレス：fu@cs.uni-goettingen.de
Christian Dickmann University of Goettingen Institute of Computer Science Goldschmidtstr. 7 Goettingen 37077 Germany
コンピュータサイエンスGoldschmidtstrのゲッティンゲン大学のクリスチャンDickmann大学。 7ゲッティンゲン37077ドイツ
EMail: mail@christian-dickmann.de
メールアドレス：mail@christian-dickmann.de
Jon Crowcroft University of Cambridge Computer Laboratory William Gates Building 15 JJ Thomson Avenue Cambridge CB3 0FD UK
ケンブリッジ大学コンピュータ研究所のジョン・クロークロフト大学ウィリアム・ゲイツビル15 JJトムソンアベニューケンブリッジCB3 0FD英国
EMail: jon.crowcroft@cl.cam.ac.uk
メールアドレス：jon.crowcroft@cl.cam.ac.uk