[要約] RFC 6084は、SCTPとDTLSを使用したGISTの一般的なインターネットシグナリングトランスポートに関する仕様です。このRFCの目的は、セキュアなデータ転送と信頼性のあるトランスポートを提供するために、GISTプロトコルをSCTPとDTLSと組み合わせる方法を定義することです。
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)
一般的なインターネットシグナル伝達輸送（GIST）ストリーム制御伝送プロトコル（SCTP）およびデータグラムトランスポートレイヤーセキュリティ（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を介してTCPまたは輸送層セキュリティ（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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6084.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ライセンステキストを含める必要があります。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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モード）操作の最初の仕様で、信頼できるシーケンス配信を提供するバイトストリーム指向のトランスポートプロトコルの上で実行されます。シグナリングメッセージトランスポート用。ただし、シグナル伝達（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:
このドキュメントでは、SCTPの使用をGISTの基礎となる輸送プロトコルとして定義し、GISTメッセージング関連を保護するためのセキュリティメカニズムとしてDTLSの使用を定義し、GISTとNSLPの間のGIST状態のメンテナンスとAPIへの影響について説明します。さらに、このドキュメントでは、SCTPが提供する追加の機能を悪用してGIST Cモードメッセージをより効果的に配信するために、GISTがSCTPを介して輸送され、NSLPによって使用される方法について説明します。すなわち：
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を輸送するSCTP実装は、SCTPユーザーメッセージの断片化のオプションの機能をサポートする必要があります。
Additionally, this document also specifies how to establish GIST security using DTLS for use in combination with, e.g., SCTP and UDP.
さらに、このドキュメントでは、DTLSを使用してGISTセキュリティを確立する方法を指定して、SCTPやUDPなどと組み合わせて使用します。
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]):
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
o MRM-メッセージルーティング方法
o MRI - Message Routing Information
o MRI-メッセージルーティング情報
o SCD - Stack-Configuration-Data
o SCD-Stack-configuration-data
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 Association -2つのSCTPエンドポイントとプロトコル状態情報で構成されるSCTPエンドポイント間のプロトコル関係。協会は、協会のエンドポイントで使用される輸送アドレスによって一意に特定できます。2つのSCTPエンドポイントには、それらの間に1つ以上の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 Stream-一方の単方方向の論理チャネルは、1つから別の関連するSCTPエンドポイントに確立されます。その中には、すべてのユーザーメッセージが順序付けられていない配信サービスに提出されたものを除き、順番に配信されます。
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.
このセクションでは、SCTPをGIST輸送プロトコルとして使用するために、新しいMA-Protocol-IDタイプ「Forwards-SCTP」を定義します。GISTでのDTLの使用は、セクション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プロトコル仕様は、メッセージングアソシエーション、つまりフォワードTCPおよびTLSで使用される2つの可能なプロトコルを定義します。この情報は、スタック構成データ（SCD）[1]の主要な部分です。このセクションでは、別の可能なプロトコルオプションとしてForwards-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:
MA-Protocol-ID「Forwards-SCTP」は、ピア間のSCTPの基本的な使用を示しています。このプロトコルのサポートはオプションです。このプロトコルが提供される場合、MA-Protocol-OptionsデータもSCDオブジェクトに携帯する必要があります。MA-Protocol-Optionsフィールド形式は次のとおりです。
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.
Forwards-SCTPを使用した関連付けは、転送属性の信頼性= trueでメッセージを伝えることができます。SCTPソケットAPI通知[11]で報告できるように、リセットなどのSCTP接続でエラーが発生した場合、GISTは[1]のセクション4.1.2で説明したように、これをNSLPに報告する必要があります。マルチホームシナリオの場合、Gist-over-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と相関的に維持するのではなく、異なるリソース（例：異なるNSLPセッション）に異なるSCTPストリームを使用することができます（これはTCPと相関しています。輸送レベルごとの厳格な（再）順序と信頼性）。ただし、マルチストリーミングの使用には制限があります。SCTP実装がGISTトランスポートに使用される場合、特定のセッションのすべてのGISTメッセージを同じSCTPストリームで送信して、順序配信のNSLP仮定を保証する必要があります。複数のセッションは、ローカルポリシーに基づいて同じ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.
メッセージング協会の再利用の要点の概念は、このドキュメントまたは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実装は、さまざまなNSLPの潜在的なニーズに対応するより柔軟な輸送機能をサポートするために、標準の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.
（部分的に信頼できるセッションとは対照的に）通常信頼できるセッションを使用する場合、ノードが生涯の有効期限が切れる前に最初の送信を送信した場合、メッセージは通常の信頼できるメッセージとして送信する必要があります。混雑のエピソードでは、これは特に残念です。他の（非lifetimeの期限が切れた）メッセージに使用される可能性のある再送信廃棄物帯域幅が浪費されるためです。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とNSLPの間の抽象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.
o API「SendMessage」のタイムアウトパラメーター：[1]によると、このパラメーターは「エラーを示す前にこのメッセージを送信する時間の長さ」を表します。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 「Network -Notification」：[1]によれば、この原始的な「GISTからシグナリングアプリケーションに渡されます。これは、シグナリングアプリケーションに関心のあるネットワークイベントが発生したことを示しています。ここで、SCTPがプライマリパスの障害を検出した場合、GISTは、ネットワークノーティフィスタイプの「ルーティングステータスの変更」を使用してこのプリミティブを呼び出すことにより、このイベントを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のStack Configuration-DataオブジェクトのSCTPプロトコルに使用されるMA-Protocol-Optionsフィールドのビットレベル形式を提供します。
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上の要点は、プライマリパスが機能しなくても、ピア間でNSLPメッセージを配信できるようになります。ただし、基本的なGIST仕様で定義されているメッセージルーティングメソッド（MRMS）の場合、このような機能は使用されているだけです。デフォルトのMRMはパス結合されています。つまり、SCTP協会の主要なパスが失敗している場合、合図されているIPトラフィックでも失敗している可能性が高いことを意味します。したがって、GISTは、ルートの変更に対処するために、とにかくNSISノードに対して代替パスまで更新を実行する必要があります。マルチホームのSCTPアソシエーションの2つのエンドポイント（ただし、それらの間の中間ノードのいずれもありません）がNSIをサポートする場合、SCTPを介したGISTは、GISTがこれらの間に少なくとも1つの代替パスが失敗した場合でもNSLPメッセージを提供するための堅牢な手段を提供します（NSIS対応）マルチホームパスのエンドポイントが利用可能です。さらに、SCTPのマルチホームサポートを使用すると、ROUTの変更を検出するための別のソースを備えた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は複数のセッションによって再利用される可能性があるため、TCPを別のメッセージを削除すると、異なるセッションに属するGISTシグナリングメッセージのトランスポートがブロックされる場合があります。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-Protocol-ID「DTLS」（値4）を指定します。これは、最初にSCTPを介したGISTと併せてデータグラムトランスポートレイヤーチャネルセキュリティの基本的な使用を示します。サーバー（つまり、GIST Transport Receiver）認証と整合性を提供します（null ciphersuiteがCiphersuite交渉中に選択されていない限り）。SCTPでGISTを保護するためにDTLを使用すると、GISTはSCTPとその拡張機能によって提供される機能を活用できます。SCTP上のGISTのDTLSの使用は、[1]で指定されているGISTのTLSに類似しています。ここでは、GISTハンドシェイクフェーズ中のSCTPとDTLSのMA-Protocol-IDの両方を含むスタックプロポザルです。
The usage of DTLS [2] for securing GIST over datagram transport protocols MUST be implemented and SHOULD be used.
データグラムトランスポートプロトコルを介してGISTを保護するためのDTL [2]の使用法を実装する必要があり、使用する必要があります。
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.
DTLを使用したGISTメッセージ関連は、機密性または整合性保護を要求する転送属性を持つメッセージを伝える場合があります。特定のDTLSバージョンはDTLSレイヤー自体内でネゴシエートされますが、実装はDTLS v1.0より前にプロトコルバージョンにネゴシエートしてはならず、両方のピアがサポートする最高のプロトコルバージョンを使用する必要があります。NULL認証と整合性暗号は、DTLをサポートするGISTノードについて交渉してはなりません。機密性の暗号の場合、ノードはnull ciphersuitesをネゴシエートできます。[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]は、アプリケーションがそれを知らなくても接続セキュリティパラメーターが変更できるように、アプリケーションに問題を引き起こす可能性があります。したがって、DTLを超える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.
DTLSにはMA-Protocol-Optionsフィールドは必要ありません。DTLSが実行されている輸送プロトコルの構成情報（例：SCTPポート番号）は、そのプロトコルのMA-Protocol-Optionsによって提供されます。
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を介したDTLでのリプレイ検出をサポートしていませんが、SCTPリプレイ保護メカニズム[6] [8]は、リプレイ攻撃から（DTLSオーバー）SCTPを使用して輸送されるNSISメッセージを保護できるはずです。
According to this specification, IANA has registered the following codepoints (MA-Protocol-IDs) in a registry created by [1]:
この仕様によれば、IANAは[1]によって作成されたレジストリに次のコードポイント（MA-Protocol-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-Protocol-ID「DTLS」は単独では使用されることはなく、常にSTACK提案で指定されたトランスポートプロトコルと組み合わされていることに注意してください。
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.
著者は、ジョン・ラウニー、ジュッカ・マナー、マグナス・ウェスターランド、ショーン・ターナー、ラース・エガート、ジェフリー・ハッツェルマン、ロバート・ハンコック、アンドリュー・マクドナルド、マーティン・スティメールリング、ファン・チュン・クオ、ヤン・デム、ラウリ・リュート、マイケル・トゥクセン、ロランド彼らの有益な提案のために。
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010.
[1] Schulzrinne、H。およびR. Hancock、「Gist：General Internet Signaling Transport」、RFC 5971、2010年10月。
[2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[2] Rescorla、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] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「ストリーム制御伝送プロトコル（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。、およびE. Rescorla、「Stream Control Transmission Protocol（SCTP）のデータグラム輸送層セキュリティ（DTLS）」、RFC 6083、2011年1月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[6] Stewart、R。、「Stream Control Transmission Protocol」、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] Rescorla、E.、Ray、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.、Stewart、R.、Lei、P.、およびE. Rescorla、「Stream Control Transmission Protocol（SCTP）の認証チャンク」、RFC 4895、2007年8月。
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[9] Postel、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] Hancock、R.、Karagiannis、G.、Loughney、J。、およびS. van den Bosch、「Signalingの次のステップ（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] Stewart、R.、Poon、K.、Tuexen、M.、Yasevich、V。、およびP. Lei、「Sockets API拡張機能用API拡張（SCTP）」、2011年1月の作業。
[12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010.
[12] Mather、J.、Bless、R.、Loughney、J。、およびE. Davies、「NSISプロトコルファミリーの使用と拡張」、RFC 5978、2010年10月。
[13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, December 2010.
[13] Stewart、R.、Tuexen、M。、およびI. Ruengeler、「Stream Control Transmission Protocol（SCTP）ネットワークアドレス翻訳」、2010年12月の作業進行中。
Authors' Addresses
著者のアドレス
Xiaoming Fu University of Goettingen Institute of Computer Science Goldschmidtstr. 7 Goettingen 37077 Germany
Xiaoming Fu Goettingen大学コンピューターサイエンスのInstitute Goldschmidtstr。7 Goettingen 37077ドイツ
EMail: fu@cs.uni-goettingen.de
Christian Dickmann University of Goettingen Institute of Computer Science Goldschmidtstr. 7 Goettingen 37077 Germany
クリスチャンディックマンゲッティンゲン大学コンピューターサイエンスのInstitute Goldschmidtstr。7 Goettingen 37077ドイツ
EMail: 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 UK
EMail: jon.crowcroft@cl.cam.ac.uk