[要約] RFC 3257は、Stream Control Transmission Protocol（SCTP）の適用性に関する声明であり、SCTPの利点と使用方法について説明しています。このRFCの目的は、SCTPの利用範囲と適用可能性を明確にすることです。
Network Working Group L. Coene
Request for Comments: 3257 Siemens
Category: Informational April 2002
Stream Control Transmission Protocol Applicability Statement
ストリーム制御伝送プロトコル適用性ステートメント
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document describes the applicability of the Stream Control Transmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) & Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP.
このドキュメントでは、Stream Control Transmission Protocol（SCTP）の適用性について説明します。また、SCTPを2つの主要なトランスポートプロトコルであるユーザーデータグラムプロトコル（UDP）と伝送制御プロトコル（TCP）と対比し、SCTPを使用するのが最適な場合とそうでない場合のガイドラインを示します。
Table of contents
目次
1. Introduction .................................................. 2
1.1 Terminology .................................................. 2
2 Transport protocols ............................................ 2
2.1 TCP service model ............................................ 2
2.2 SCTP service model ........................................... 3
2.3 UDP service model ............................................ 4
3 SCTP Multihoming issues ........................................ 4
4 SCTP Network Address Translators (NAT) issues [RFC2663] ........ 5
5 Security Considerations ........................................ 6
5.1 Security issues with TCP ..................................... 6
5.2 Security issues with SCTP .................................... 7
5.3 Security issues with both TCP and SCTP ....................... 8
6 References and related work .................................... 9
7 Acknowledgments ................................................ 10
Appendix A: Major functions provided by SCTP ..................... 11
Editor's Address ................................................. 12
Full Copyright Statement ......................................... 13
1 Introduction
1はじめに
SCTP is a reliable transport protocol [RFC2960], which along with TCP [RFC793], RTP [RFC1889], and UDP [RFC768], provides transport-layer services for upper layer protocols and services. UDP, RTP, TCP, and SCTP are currently the IETF standards-track transport-layer protocols. Each protocol has a domain of applicability and services it provides, albeit with some overlaps.
SCTPは信頼できるトランスポートプロトコル[RFC2960]であり、TCP [RFC793]、RTP [RFC1889]、およびUDP [RFC768]とともに、上位層のプロトコルとサービスにトランスポート層サービスを提供します。 UDP、RTP、TCP、およびSCTPは現在、IETF標準トラックのトランスポート層プロトコルです。各プロトコルには、いくつかの重複はありますが、それが提供する適用性とサービスのドメインがあります。
By clarifying the situations where the functionality of these protocols are applicable, this document can guide implementers and protocol designers in selecting which protocol to use.
これらのプロトコルの機能が適用される状況を明確にすることにより、このドキュメントは、使用するプロトコルを選択する際に実装者とプロトコル設計者をガイドすることができます。
Special attention is given to services SCTP provides which would make a decision to use SCTP the right one.
SCTPを使用するかどうかを決定するSCTPが提供するサービスには、特別な注意が払われています。
Major functions provided by SCTP can be found in Appendix A.
SCTPが提供する主な機能については、付録Aを参照してください。
The following terms are commonly identified in this work:
この作業では、一般的に次の用語が識別されます。
Association: SCTP connection between two endpoints.
関連付け：2つのエンドポイント間のSCTP接続。
Transport address: A combination of IP address and SCTP port number.
トランスポートアドレス：IPアドレスとSCTPポート番号の組み合わせ。
Upper layer: The user of the SCTP protocol, which may be an adaptation layer, a session layer protocol, or the user application directly.
上位層：SCTPプロトコルのユーザー。これは、アダプテーション層、セッション層プロトコル、または直接ユーザーアプリケーションです。
Multihoming: Assigning more than one IP network interface to a single endpoint.
マルチホーミング：1つのエンドポイントに複数のIPネットワークインターフェイスを割り当てます。
2 Transport protocols
2トランスポートプロトコル
TCP is a connection-oriented (a.k.a., session-oriented) transport protocol. This means that it requires both the establishment of a connection prior to the exchange of application data and a connection tear-down to release system resources after the completion of data transfer.
TCPは接続指向（別名、セッション指向）のトランスポートプロトコルです。つまり、アプリケーションデータの交換前に接続を確立することと、データ転送の完了後にシステムリソースを解放するために接続をティアダウンすることが必要です。
TCP is currently the most widely used connection-oriented transport protocol for the Internet.
TCPは現在、インターネットで最も広く使用されている接続指向のトランスポートプロトコルです。
TCP provides the upper layer with the following transport services:
TCPは、上位層に次のトランスポートサービスを提供します。
- data reliability;
- データの信頼性;
- data sequence preservation; and
- データシーケンスの保存;そして
- flow and congestion control.
- フローと輻輳制御。
SCTP is also connection-oriented and provides all the transport services that TCP provides. Many Internet applications therefore should find that either TCP or SCTP will meet their transport requirements. Note, for applications conscious about processing cost, there might be a difference in processing cost associated with running SCTP with only a single ordered stream and one address pair in comparison to running TCP.
SCTPも接続指向であり、TCPが提供するすべてのトランスポートサービスを提供します。したがって、多くのインターネットアプリケーションは、TCPまたはSCTPがトランスポート要件を満たしていることを確認する必要があります。処理コストを意識するアプリケーションの場合、TCPを実行する場合と比較して、単一の順序付けられたストリームと1つのアドレスペアのみを使用するSCTPの実行に関連する処理コストは異なる場合があります。
However, SCTP has some additional capabilities that TCP lacks and This can make SCTP a better choice for some applications and environments:
ただし、SCTPにはTCPにはない追加機能がいくつかあります。これにより、SCTPは一部のアプリケーションおよび環境にとってより良い選択になります。
- multi-streams support:
- マルチストリームのサポート：
SCTP supports the delivery of multiple independent user message streams within a single SCTP association. This capability, when properly used, can alleviate the so-called head-of-line-blocking problem caused by the strict sequence delivery constraint imposed to the user data by TCP.
SCTPは、単一のSCTPアソシエーション内の複数の独立したユーザーメッセージストリームの配信をサポートします。この機能を適切に使用すると、TCPによってユーザーデータに課された厳密なシーケンス配信制約によって引き起こされる、いわゆる行頭ブロッキングの問題が緩和されます。
This can be particularly useful for applications that need to exchange multiple, logically separate message streams between two endpoints.
これは、2つのエンドポイント間で論理的に分離された複数のメッセージストリームを交換する必要があるアプリケーションで特に役立ちます。
- multi-homing support:
- マルチホーミングのサポート：
SCTP provides transparent support for communications between two endpoints of which one or both is multi-homed.
SCTPは、1つまたは両方がマルチホームである2つのエンドポイント間の通信を透過的にサポートします。
SCTP provides monitoring of the reachability of the addresses on the remote endpoint and in the case of failure can transparently failover from the primary address to an alternate address, without upper layer intervention.
SCTPは、リモートエンドポイント上のアドレスの到達可能性の監視を提供し、障害が発生した場合、上位層の介入なしに、プライマリアドレスから代替アドレスに透過的にフェイルオーバーできます。
This capability can be used to build redundant paths between two SCTP endpoints and can be particularly useful for applications that seek transport-level fault tolerance.
この機能は、2つのSCTPエンドポイント間に冗長パスを構築するために使用でき、トランスポートレベルのフォールトトレランスを求めるアプリケーションに特に役立ちます。
Achieving path redundancy between two SCTP endpoints normally requires that the two endpoints being equipped with multiple interfaces assigned with multiple addresses and that routing is configured appropriately (see Section 3).
2つのSCTPエンドポイント間のパスの冗長性を実現するには、通常、2つのエンドポイントに複数のアドレスが割り当てられた複数のインターフェースが装備され、ルーティングが適切に構成されている必要があります（セクション3を参照）。
- preservation of message boundaries:
- メッセージ境界の保持：
SCTP preserves application messages boundaries. This is useful when the application data is not a continuous byte stream but comes in logical chunks that the receiver handles separately.
SCTPはアプリケーションメッセージの境界を保持します。これは、アプリケーションデータが連続したバイトストリームではなく、受信者が個別に処理する論理チャンクに入っている場合に役立ちます。
In contrast, TCP offers a reliable data stream that has no indication of what an application may consider logical chunks of the data.
対照的に、TCPは、アプリケーションがデータの論理チャンクと見なすものを示さない信頼性の高いデータストリームを提供します。
- unordered reliable message delivery:
- 順序付けされていない信頼できるメッセージ配信：
SCTP supports the transportation of user messages that have no application-specified order, yet need guaranteed reliable delivery.
SCTPは、アプリケーションで指定された順序がなく、信頼性の高い配信を保証する必要があるユーザーメッセージの転送をサポートします。
Applications that need to send un-ordered reliable messages or prefer using their own message sequencing and ordering mechanisms may find this SCTP capability useful.
順序付けされていない信頼性のあるメッセージを送信する必要があるアプリケーション、または独自のメッセージシーケンスおよび順序付けメカニズムの使用を好むアプリケーションでは、このSCTP機能が役立つことがあります。
UDP is connectionless. This means that applications that use UDP do not need to perform connection establishment or tear-down.
UDPはコネクションレスです。つまり、UDPを使用するアプリケーションは、接続の確立や破棄を実行する必要がありません。
As transport services to its upper layer, UDP provides only:
上位層へのトランスポートサービスとして、UDPは以下のみを提供します。
- best-effort data delivery, and
- ベストエフォートのデータ配信、および
- preservation of message boundaries.
- メッセージ境界の保持。
Applications that do not require a reliable transfer of more than a packet's worth of data will find UDP adequate. Some transaction-based applications fall into this category.
パケットに相当するデータ以上の信頼できる転送を必要としないアプリケーションは、UDPで十分です。一部のトランザクションベースのアプリケーションはこのカテゴリに分類されます。
3 SCTP Multihoming Issues
3 SCTPマルチホーミングの問題
SCTP provides transport-layer support for multihoming. Multihoming has the potential of providing additional robustness against network failures. In some applications, this may be extremely important, for example, in signaling transport of PSTN signaling messages [RFC2719].
SCTPは、マルチホーミングのトランスポート層サポートを提供します。マルチホーミングには、ネットワーク障害に対する堅牢性を追加できる可能性があります。一部のアプリケーションでは、これは、たとえばPSTNシグナリングメッセージのシグナリングトランスポート[RFC2719]で非常に重要になる場合があります。
It should be noted that SCTP multihoming support only deals with communication between two endpoints of which one or both is assigned with multiple IP addresses on possibly multiple network interfaces. It does NOT deal with communication ends that contain multiple endpoints (i.e., clustered endpoints) that can switch over to an alternate endpoint in case of failure of the original endpoint.
SCTPマルチホーミングサポートは、1つまたは両方に複数のネットワークインターフェイス上の複数のIPアドレスが割り当てられている2つのエンドポイント間の通信のみを処理することに注意してください。元のエンドポイントに障害が発生した場合に代替エンドポイントに切り替えることができる複数のエンドポイント（つまり、クラスター化されたエンドポイント）を含む通信エンドは処理しません。
Generally, for truly fault resilient communication between two end-points, the multihoming feature needs more than one IP network interface for each endpoint. The number of paths used is the minimum of network interfaces used by any of the endpoints. When an endpoint selects its source address, careful consideration must be taken. If the same source address is always used, then it is possible that the endpoint will be subject to the same single point of failure. When the endpoint chooses a source address, it should always select the source address of the packet to correspond to the IP address of the Network interface where the packet will be emitted subject to the binding address constraint. The binding address constraint is, put simply, that the endpoint must never choose a source address that is not part of the association i.e., the peer endpoint must recognize any source address used as being part of the association.
一般に、2つのエンドポイント間の真のフォールトレジリエンシー通信のために、マルチホーミング機能には、各エンドポイントに複数のIPネットワークインターフェイスが必要です。使用されるパスの数は、いずれかのエンドポイントで使用される最小のネットワークインターフェイスです。エンドポイントが送信元アドレスを選択するときは、慎重に検討する必要があります。同じ送信元アドレスが常に使用される場合、エンドポイントが同じ単一障害点の影響を受ける可能性があります。エンドポイントがソースアドレスを選択する場合、バインディングアドレスの制約に従って、パケットが送信されるネットワークインターフェイスのIPアドレスに対応するように、常にパケットのソースアドレスを選択する必要があります。バインディングアドレスの制約は、端的に言えば、エンドポイントがアソシエーションの一部ではないソースアドレスを決して選択してはならないことです。つまり、ピアエンドポイントは、アソシエーションの一部として使用されているソースアドレスを認識しなければなりません。
The availability of the association will benefit greatly from having multiple addresses bound to the association endpoint when the endpoint is on a multi-homed host.
関連付けの可用性は、エンドポイントがマルチホームホスト上にある場合に、関連付けのエンドポイントにバインドされた複数のアドレスを持つことで大きなメリットを得ます。
4 SCTP Network Address Translators (NAT) issues [RFC2663]
4 SCTPネットワークアドレス変換（NAT）の問題[RFC2663]
When two endpoints are to setup an SCTP association and one (or both) of them is behind a NAT (i.e., it does not have any publicly available network addresses), the endpoint(s) behind the NAT should consider one of the following options:
2つのエンドポイントがSCTPアソシエーションをセットアップする予定であり、それらの一方（または両方）がNATの背後にある場合（つまり、パブリックに利用可能なネットワークアドレスがない場合）、NATの背後のエンドポイントは次のオプションのいずれかを考慮する必要があります。 ：
(1) When single homed sessions are to be used, no transport addresses should be sent in the INIT or INIT ACK chunk(Refer to section 3.3 of RFC2960 for chunk definitions). This will force the endpoint that receives this initiation message to use the source address in the IP header as the only destination address for this association. This method can be used for a NAT, but any multi-homing configuration at the endpoint that is behind the NAT will not be visible to its peer, and thus not be taken advantage of. See figure 1.
（1）シングルホームセッションを使用する場合、INITまたはINIT ACKチャンクでトランスポートアドレスを送信しないでください（チャンクの定義については、RFC2960のセクション3.3を参照してください）。これにより、この開始メッセージを受信するエンドポイントは、IPアソシエーションの唯一の宛先アドレスとしてIPヘッダーのソースアドレスを使用するように強制されます。この方法はNATに使用できますが、NATの背後にあるエンドポイントのマルチホーミング構成はピアからは見えないため、利用されません。図1を参照してください。
+-------+ +---------+ *~~~~~~~~~~* +------+
|Host A | | NAT | * Cloud * |Host B|
| 10.2 +--|10.1|2.1 |----|--------------|---------+ 1.2 |
| | | | | * * | |
+-------+ +---------+ *~~~~~~~~~~* +------+
Fig 1: SCTP through NAT without multihoming
図1：マルチホーミングのないNATを介したSCTP
For multihoming the NAT must have a public IP address for each represented internal IP address. The host can preconfigure an IP address that the NAT can substitute, or, the NAT can have internal Application Layer Gateway (ALG) which will intelligently translate the IP addresses in the INIT and INIT ACK chunks. See Figure 2.
マルチホーミングの場合、NATは、表された内部IPアドレスごとにパブリックIPアドレスを持っている必要があります。ホストは、NATが置換できるIPアドレスを事前構成できます。または、NATは内部アプリケーションレイヤーゲートウェイ（ALG）を持つことができ、INITおよびINIT ACKチャンクのIPアドレスをインテリジェントに変換します。図2を参照してください。
If Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per-association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association.
ネットワークアドレスポート変換をマルチホームSCTPエンドポイントで使用する場合、任意のポート変換を関連付けごとに適用して、SCTPエンドポイントが特定の関連付け内のすべてのメッセージに対して同じポート番号を引き続き受信するようにする必要があります。
+-------+ +----------+ *~~~~~~~~~~* +------+
|Host A | | NAT | * Cloud * |Host B|
| 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 |
| 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 |
| | | | * * | |
+-------+ +----------+ *~~~~~~~~~* +------+
Fig 2: SCTP through NAT with multihoming
図2：マルチホーミングを使用したNAT経由のSCTP
(2) Another alternative is to use the hostname feature and DNS to resolve the addresses. The hostname is included in the INIT of the association or in the INIT ACK. The hostname must be resolved by DNS before the association is completely set up. There are special issues regarding NAT and DNS, refer to RFC2694 for details.
（2）別の方法は、ホスト名機能とDNSを使用してアドレスを解決することです。ホスト名は、関連付けのINITまたはINIT ACKに含まれています。アソシエーションが完全にセットアップされる前に、ホスト名はDNSによって解決される必要があります。 NATおよびDNSに関しては特別な問題があります。詳細についてはRFC2694を参照してください。
5 Security Considerations
5セキュリティに関する考慮事項
In this section, some relevant security issues found in the deployment of the connection-oriented transport protocols will be discussed.
このセクションでは、コネクション型トランスポートプロトコルの展開で見つかったいくつかの関連するセキュリティ問題について説明します。
Some TCP implementations have been known to be vulnerable to blind denial of service attacks, i.e., attacks that had been executed by an attacker that could not see most of the traffic to or from the target host.
一部のTCP実装は、ブラインドサービス拒否攻撃、つまりターゲットホストとの間のトラフィックのほとんどを見ることができない攻撃者によって実行された攻撃に対して脆弱であることが知られています。
The attacker would send a large number of connection establishment requests (TCP-SYN packets) to the attacked target, possibly from faked IP source addresses. The attacked host would reply by sending SYN-ACK packets and entering SYN-received state, thereby allocating space for a TCB. At some point the SYN-queue would fill up, (i.e., the number of connections waiting to be established would rise to a limit) and the host under attack would have to start turning down new connection establishment requests.
攻撃者は、おそらく偽のIP送信元アドレスから、攻撃されたターゲットに多数の接続確立要求（TCP-SYNパケット）を送信する可能性があります。攻撃されたホストは、SYN-ACKパケットを送信してSYN-received状態に入り、TCBにスペースを割り当てることによって応答します。ある時点でSYNキューがいっぱいになり（つまり、確立を待機している接続の数が制限に達する）、攻撃を受けているホストは新しい接続確立要求を拒否し始める必要があります。
TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the risk of such blind denial of service attacks. TCP implementations can switch to using this algorithm in times when their SYN-queues are filled up while still fully conforming to the TCP specification [RFC793]. However, use of options such as a window scale [RFC1323], is not possible, then. With the SYN-cookie mechanism, a TCB is only created when the client sends back a valid ACK packet to the server, and the 3-way handshake has thus been successfully completed.
SYN-cookiesアルゴリズムを使用したTCP実装[SYN-COOK]は、そのようなブラインドサービス拒否攻撃のリスクを軽減します。 TCP実装は、TCP仕様[RFC793]に完全に準拠しながら、SYNキューがいっぱいになったときにこのアルゴリズムの使用に切り替えることができます。ただし、ウィンドウスケール[RFC1323]などのオプションを使用することはできません。 SYN-cookieメカニズムを使用すると、クライアントが有効なACKパケットをサーバーに送信したときにのみTCBが作成され、3ウェイハンドシェイクが正常に完了します。
Blind connection forgery is another potential threat to TCP. By guessing valid sequence numbers, an attacker would be able to forge a connection. However, with a secure hashsum algorithm, for some of the current SYN-cookie implementations the likelihood of achieving this attack is on the order of magnitude of 1 in 2^24, i.e., the attacker would have to send 2^24 packets before obtaining one forged connection when SYN-cookies are used.
ブラインド接続偽造は、TCPに対するもう1つの潜在的な脅威です。有効なシーケンス番号を推測することにより、攻撃者は接続を偽造することができます。ただし、安全なハッシュサムアルゴリズムを使用すると、現在の一部のSYN-cookie実装では、この攻撃を達成する可能性は2 ^ 24分の1程度です。つまり、攻撃者は取得する前に2 ^ 24パケットを送信する必要があります。 SYN-Cookieが使用されている場合は1つの偽造接続。
SCTP has been designed with the experiences made with TCP in mind. To make it hard for blind attackers (i.e., attackers that are not man-in-the-middle) to inject forged SCTP datagrams into existing associations, each side of an SCTP association uses a 32 bit value called "Verification Tag" to ensure that a datagram really belongs to the existing association. So in addition to a combination of source and destination transport addresses that belong to an established association, a valid SCTP datagram must also have the correct tag to be accepted by the recipient.
SCTPは、TCPでの経験を考慮して設計されています。ブラインド攻撃者（つまり、中間者ではない攻撃者）が既存のアソシエーションに偽造されたSCTPデータグラムを挿入することを困難にするために、SCTPアソシエーションの各サイドは、「検証タグ」と呼ばれる32ビット値を使用して、データグラムは実際には既存の関連付けに属しています。したがって、確立されたアソシエーションに属する送信元と宛先のトランスポートアドレスの組み合わせに加えて、有効なSCTPデータグラムには、受信者が受け入れる正しいタグも必要です。
Unlike in TCP, usage of cookie in association establishment is made mandatory in SCTP. For the server, a new association is fully established after three messages (containing INIT, INIT-ACK, COOKIE-ECHO chunks) have been exchanged. The cookie is a variable length parameter that contains all relevant data to initialize the TCB on the server side, plus a HMAC used to secure it. This HMAC (MD5 as per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie and a secret, server-owned key.
TCPとは異なり、アソシエーションの確立におけるCookieの使用は、SCTPでは必須になっています。サーバーでは、3つのメッセージ（INIT、INIT-ACK、COOKIE-ECHOチャンクを含む）が交換された後で、新しい関連付けが完全に確立されます。 Cookieは、サーバー側でTCBを初期化するためのすべての関連データと、それを保護するために使用されるHMACを含む可変長パラメーターです。このHMAC（[RFC1321]またはSHA-1 [SHA1]に基づくMD5）は、Cookieとサーバーが所有する秘密鍵を使用して計算されます。
As specifically prescribed for SCTP implementations [RFC2960], additional resources for new associations may only be reserved in case a valid COOKIE-ECHO chunk is received by a client, and the computed HMAC for this new cookie matches that contained in the cookie.
SCTP実装[RFC2960]で具体的に規定されているように、新しいアソシエーションの追加リソースは、有効なCOOKIE-ECHOチャンクがクライアントによって受信され、この新しいCookieの計算されたHMACがCookieに含まれているものと一致する場合にのみ予約できます。
With SCTP the chances of an attacker being able to blindly forge a connection are even lower than in the case of TCP using SYN-cookies, since the attacker would have to guess a correct value for the HMAC contained in the cookie, i.e., lower than 1 in 2^128 which for all practical purposes is negligible.
SCTPでは、攻撃者がSYN-cookieを使用するTCPの場合よりも攻撃者が盲目的に接続を偽造できる可能性が低くなります。これは、攻撃者がcookieに含まれるHMACの正しい値を推測する必要があるためです。 2 ^ 128分の1ですが、実用上は無視できます。
It should be noted that SCTP only tries to increase the availability of a network. SCTP does not contain any protocol mechanisms that are directly related to user message authentication, integrity and confidentiality functions. For such features, it depends on the IPsec protocols and architecture and/or on security features of the application protocols.
SCTPはネットワークの可用性の向上のみを試みることに注意してください。 SCTPには、ユーザーメッセージの認証、整合性、機密性の機能に直接関連するプロトコルメカニズムは含まれていません。そのような機能の場合、それはIPsecプロトコルとアーキテクチャ、および/またはアプリケーションプロトコルのセキュリティ機能に依存します。
Transport Layer security(TLS)[RFC2246] using SCTP must always use in-order streams.
SCTPを使用するトランスポート層セキュリティ（TLS）[RFC2246]は、常に順序どおりのストリームを使用する必要があります。
Currently the IPSEC working group is investigating the support of multi-homing by IPSEC protocols. At the present time to use IPSEC, one must use 2 * N * M security associations if one endpoint uses N addresses and the other M addresses.
現在、IPSECワーキンググループは、IPSECプロトコルによるマルチホーミングのサポートを調査しています。現時点でIPSECを使用するには、1つのエンドポイントがN個のアドレスと他のM個のアドレスを使用する場合、2 * N * Mのセキュリティアソシエーションを使用する必要があります。
It is important to note that neither TCP nor SCTP protect itself from man-in-the-middle attacks where an established session might be hijacked (assuming the attacker can see the traffic from and inject its own packets to either endpoints).
TCPもSCTPも、確立されたセッションがハイジャックされる可能性がある中間者攻撃から自分自身を保護することに注意することが重要です（攻撃者がトラフィックを確認し、自分のパケットをいずれかのエンドポイントに注入できると想定）。
Also, to prevent blind connection/session setup forgery, both TCP implementations supporting SYN-cookies and SCTP implementations rely on a server-known, secret key to protect the HMAC data. It must be ensured that this key is created subject to the recommendations mentioned in [RFC1750].
また、ブラインド接続/セッションセットアップの偽造を防ぐために、SYN-cookieをサポートするTCP実装とSCTP実装の両方が、HMACデータを保護するためにサーバー既知の秘密鍵に依存しています。この鍵は、[RFC1750]で言及されている推奨事項に従って作成されていることを確認する必要があります。
Although SCTP has been designed carefully as to avoid some of the problems that have appeared with TCP, it has as of yet not been widely deployed. It is therefore possible that new security issues will be identified that will have to be addressed in further revisions of [RFC2960].
SCTPは、TCPで発生する問題のいくつかを回避するように注意深く設計されていますが、現時点ではまだ広く展開されていません。したがって、[RFC2960]の今後の改訂で対処する必要がある新しいセキュリティ問題が特定される可能性があります。
6 References and related work
6参考文献と関連研究
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]スチュワート、R。、シェイ、Q。、モーノー、K。、シャープ、C。、シュワルツバウアー、H。、テイラー、T。、リティナ、I。、カラ、M。、チャン、L.、V。 Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[RFC2694] Srisuresh、P.、Tsirtsis、G.、Akkiraju、P。およびA. Heffernan、「ネットワークアドレス変換（DNS_ALG）へのDNS拡張」、RFC 2694、1999年9月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Architectural Framework for Signaling Transport", RFC 2719, October 1999.
[RFC2719] Ong、L.、Rytina、I.、Garcia、M.、Schwarzbauer、H.、Coene、L.、Lin、H.、Juhasz、I.、Holdrege、M。およびC. Sharp、「Architectural Framework for Signaling Transport」、RFC 2719、1999年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。およびD. Borman、「高性能のTCP拡張機能」、RFC 1323、1992年5月。
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, April 1995.
[SHA1] NIST FIPS PUB 180-1、「Secure Hash Standard」、米国連邦情報・技術研究所、米国商務省、1995年4月。
[SYNCOOK] Dan J. Bernstein, SYN cookies, 1997, see also
<http://cr.yp.to/syncookies.html>
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC1889] Schulzrinne、H.、Casner、S.、Frederick、R。およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、RFC 1889、1996年1月。
7 Acknowledgments
7謝辞
This document was initially developed by a design team consisting of Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart, Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas Jungmaier, Gery Verwimp and Lyndon Ong.
このドキュメントは当初、ロードコエネ、ジョンラフニー、ミシェルトゥエセン、ランドールR.スチュワート、チャオビングシェ、マットホールドレゲ、マリアカルメンベリンチョン、アンドレアスジュングマイヤー、ジェリーヴェルムプ、リンドンオングで構成される設計チームによって開発されました。
The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer, J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, T. George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, G. Camarillo, H. Schulzrinne, R. Kantola, J. Rosenberg, R.J. Atkinson, and many others for their invaluable comments.
著者は、レニー・レヴィス、I。リティーナ、HJシュワルツバウアー、JPマーティンフラッティン、T。テイラー、G。サイドボトム、K。モルノー、T。ジョージ、M。スティルマン、N。マキナエ、S。ブラドナー、A。 Mankin、G。Camarillo、H。Schulzrinne、R。Kantola、J。Rosenberg、RJアトキンソン、および他の多くの貴重なコメント。
Appendix A: Major functions provided by SCTP
付録A：SCTPが提供する主な機能
- Reliable Data Transfer
- 信頼できるデータ転送
- Multiple streams to help avoid head-of-line blocking
- 行頭ブロッキングを回避するのに役立つ複数のストリーム
- Ordered and unordered data delivery on a per-stream basis
- ストリームごとの順序付きおよび順序なしのデータ配信
- Bundling and fragmentation of user data
- ユーザーデータのバンドルと断片化
- TCP friendly Congestion and flow control
- TCPフレンドリーな輻輳とフロー制御
- Support continuous monitoring of reachability
- 到達可能性の継続的な監視をサポート
- Graceful termination of association
- アソシエーションの優雅な終了
- Support of multi-homing for added reliability
- 信頼性を高めるためのマルチホーミングのサポート
- Some protection against blind denial-of-service attacks
- ブラインドサービス拒否攻撃に対するある程度の保護
- Some protection against blind masquerade attacks
- ブラインドマスカレード攻撃に対するある程度の保護
8 Editor's Address
8編集者のアドレス
Lode Coene Siemens Atea Atealaan 34 B-2200 Herentals Belgium
Lode Coene Siemens Atea Atealaan 34 B-2200 Herentalsベルギー
Phone: +32-14-252081
EMail: lode.coene@siemens.atea.be
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。