[要約] この文書は、ICE（Interactive Connectivity Establishment）プロトコルを拡張し、TCPベースのメディアストリームの接続候補を交換するための手順を規定しています。NAT越えを必要とするリアルタイム通信において、UDPが利用できない環境下でもTCPを用いて効率的に接続を確立し、最適な通信経路を選択できるようにします。
Internet Engineering Task Force (IETF) J. Rosenberg
Request for Comments: 6544 jdrosen.net
Category: Standards Track A. Keranen
ISSN: 2070-1721 Ericsson
B. B. Lowekamp
Skype
A. B. Roach
Tekelec
March 2012
TCP Candidates with Interactive Connectivity Establishment (ICE)
対話型接続確立（ICE）におけるTCP候補
Abstract
概要
Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream.
対話型接続確立（ICE）は、セッション交渉でオファー／アンサー方式を使うマルチメディア通信プロトコル向けに、NATトラバーサルの仕組みを定義します。ICEは各メディアストリームにトランスポートアドレス候補の集合を提示し、NATのためのセッショントラバーサルユーティリティ（STUN）に基づくピア間接続性チェックで候補を検証します。ICEは候補を記述する一般的な枠組みを提供しますが、これまではUDPベースのメディアストリームだけを規定していました。この仕様はICEをTCPベースのメディアに拡張し、1つのストリームにTCP候補とUDP候補を混在させて提示できるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット標準化過程の文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
この文書はInternet Engineering Task Force（IETF）の成果であり、IETFコミュニティの合意を示しています。公開レビューを経て、Internet Engineering Steering Group（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/rfc6544.
この文書の現在の状態、正誤表、フィードバックの送付方法に関する情報は、http://www.rfc-editor.org/info/rfc6544 で確認できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
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文書に関するIETF Trustの法的規定」（http://trustee.ietf.org/license-info）の対象です。これらの文書には、本書に関する権利と制限が記載されているため、注意して確認してください。本書から抜き出したコードコンポーネントには、Trustの法的規定のセクション4.eに記載されたSimplified BSD Licenseの文面を含める必要があり、そのライセンスに記載されたとおり、保証なしで提供されます。
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 Trustに付与していない可能性があります。該当する著作権者から適切なライセンスを得ない限り、この文書をIETF標準化過程の外で変更したり、その派生物を作成したりすることはできません。ただし、RFCとして公開するための形式調整や、英語以外の言語への翻訳は除きます。
Table of Contents
目次
1. Introduction ....................................................4 2. Terminology .....................................................5 3. Overview of Operation ...........................................5 4. Sending the Initial Offer .......................................7 4.1. Gathering Candidates .......................................7 4.2. Prioritization .............................................8 4.3. Choosing Default Candidates ...............................10 4.4. Lite Implementation Requirements ..........................10 4.5. Encoding the SDP ..........................................11 5. Candidate Collection Techniques ................................12 5.1. Host Candidates ...........................................12 5.2. Server Reflexive Candidates ...............................13 5.3. NAT-Assisted Candidates ...................................13 5.4. UDP-Tunneled Candidates ...................................14 5.5. Relayed Candidates ........................................15 6. Receiving the Initial Offer and Answer .........................15 6.1. Considerations with Two Lite Agents .......................16 6.2. Forming the Check Lists ...................................16 7. Connectivity Checks ............................................17 7.1. STUN Client Procedures ....................................17 7.2. STUN Server Procedures ....................................18 8. Concluding ICE Processing ......................................18 9. Subsequent Offer/Answer Exchanges ..............................18 9.1. Updated Offer .............................................18 9.2. ICE Restarts ..............................................19 10. Media Handling ................................................19 10.1. Sending Media ............................................19 10.2. Receiving Media ..........................................20 11. Connection Management .........................................20 11.1. Connections Formed during Connectivity Checks ............20 11.2. Connections Formed for Gathering Candidates ..............21 12. Security Considerations .......................................22 13. IANA Considerations ...........................................23 14. Acknowledgements ..............................................23 15. References ....................................................23 15.1. Normative References .....................................23 15.2. Informative References ...................................24 Appendix A. Limitations of ICE TCP ...............................26 Appendix B. Implementation Considerations for BSD Sockets ........27 Appendix C. SDP Examples .........................................28
Interactive Connectivity Establishment (ICE) [RFC5245] defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model [RFC3264] of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN) [RFC5389]. However, ICE only defines procedures for UDP-based transport protocols.
There are many reasons why ICE support for TCP is important. First, there are media protocols that only run over TCP. Such protocols are used, for example, for screen sharing and instant messaging [RFC4975]. For these protocols to work in the presence of NAT, unless they define their own NAT traversal mechanisms, ICE support for TCP is needed. In addition, RTP can also run over TCP [RFC4571]. Typically, it is preferable to run RTP over UDP, and not TCP. However, in a variety of network environments, overly restrictive NAT and firewall devices prevent UDP-based communications altogether, but general TCP-based communications are permitted. In such environments, sending RTP over TCP, and thus establishing the media session, may be preferable to having it fail altogether. With this specification, agents can gather UDP and TCP candidates for a media stream, list the UDP ones with higher priority, and then only use the TCP-based ones if the UDP ones fail. This provides a fallback mechanism that allows multimedia communications to be highly reliable.
ICEがTCPに対応することが重要な理由はいくつもあります。まず、TCP上でしか動作しないメディアプロトコルがあります。画面共有やインスタントメッセージング[RFC4975]などがその例です。これらのプロトコルがNAT環境で動作するには、独自のNATトラバーサル機構を定義していない限り、TCP向けのICEが必要です。また、RTPもTCP上で動作できます[RFC4571]。通常はTCPよりUDP上でRTPを動作させる方が望ましいものの、厳しい制限を課すNATやファイアウォールによってUDP通信が全面的に遮断され、一般的なTCP通信は許可されるネットワーク環境もあります。そのような環境では、セッションを完全に失敗させるより、TCPでRTPを送りメディアセッションを確立する方が望ましい場合があります。この仕様により、エージェントは各メディアストリームについてUDP候補とTCP候補を収集し、UDP候補を高い優先度で提示して、UDPが失敗した場合に限りTCP候補を使えます。これにより、マルチメディア通信の高い信頼性を支えるフォールバック機構が得られます。
The usage of RTP over TCP is particularly useful when combined with Traversal Using Relays around NAT (TURN) [RFC5766]. In this case, one of the agents would connect to its TURN server using TCP and obtain a TCP-based relayed candidate. It would offer this to its peer agent as a candidate. The other agent would initiate a TCP connection towards the TURN server. When that connection is established, media can flow over the connections, through the TURN server. The benefit of this usage is that it only requires the agents to make outbound TCP connections to a server on the public network. This kind of operation is broadly interoperable through NAT and firewall devices. Since it is a goal of ICE and this extension to provide highly reliable communications that "just work" in as broad a set of network deployments as possible, this use case is particularly important.
TCP上のRTPは、NAT越えリレー（TURN）[RFC5766]と組み合わせると特に有用です。この場合、一方のエージェントはTCPでTURNサーバーに接続し、TCPベースの中継候補を取得して、相手のエージェントに候補として提示します。もう一方のエージェントはTURNサーバーへのTCP接続を開始します。接続が確立すると、メディアはTURNサーバーを経由して両者の接続間を流れます。この方法では、エージェントがパブリックネットワーク上のサーバーへ送信方向のTCP接続を確立するだけで済みます。この動作は、NATやファイアウォールを越えて広く相互運用できます。ICEとこの拡張の目標は、できるだけ幅広いネットワーク環境で特別な設定なしに高信頼の通信を実現することであり、このユースケースは特に重要です。
This specification extends ICE by defining its usage with TCP candidates. It also defines how ICE can be used with RTP and Secure RTP (SRTP) to provide both TCP and UDP candidates. This specification does so by following the outline of ICE itself and
この仕様はTCP候補でICEを使う方法を定め、ICEを拡張します。また、RTPおよびSecure RTP（SRTP）でICEを使い、TCP候補とUDP候補の両方を提示する方法も定めます。この仕様はICE自体の構成に沿って、TCP候補をサポートするために追加・変更する点を示します。TCP候補でICEを使う方法を定義する本仕様の拡張を除き、ICE [RFC5245]の基本動作は変わりません。
calling out the additions and changes to support TCP candidates in ICE. The base behavior of ICE [RFC5245] remains unchanged except for the extensions in this document that define the usage of ICE with TCP candidates.
氷のTCP候補者をサポートするために追加と変更を呼びかけます。ICE [RFC5245]の基本挙動は、TCP候補との氷の使用を定義するこのドキュメントの拡張機能を除き、変更されていません。
It should be noted that since TCP NAT traversal is more complicated than with UDP, ICE TCP is not generally as efficient as UDP-based ICE. Discussion about this topic can be found in Appendix A.
TCPによるNATトラバーサルはUDPの場合より複雑なため、ICE TCPは一般にUDPベースのICEほど効率的ではありません。この点については付録Aで説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および "OPTIONAL" は、RFC 2119 [RFC2119] で説明されているように解釈されるものとします。
This document uses the same terminology as ICE (see Section 3 of [RFC5245]).
このドキュメントでは、ICEと同じ用語を使用しています（[RFC5245]のセクション3を参照）。
The usage of ICE with TCP is relatively straightforward. This specification mainly deals with how and when connections are opened and how those connections relate to candidate pairs.
ICEをTCPで使う方法は比較的単純です。この仕様では主に、接続をいつ、どのように確立するか、また各接続が候補ペアとどう関係するかを説明します。
When agents perform address allocations to gather TCP-based candidates, three types of candidates can be obtained: active candidates, passive candidates, and simultaneous-open (S-O) candidates. An active candidate is one for which the agent will attempt to open an outbound connection but will not receive incoming connection requests. A passive candidate is one for which the agent will receive incoming connection attempts but not attempt a connection. An S-O candidate is one for which the agent will attempt to open a connection simultaneously with its peer.
エージェントがTCPベースの候補を収集するためにアドレスを割り当てると、アクティブ、パッシブ、同時オープン（S-O）の3種類の候補を取得できます。アクティブ候補では、エージェントは送信方向の接続を開始しますが、着信接続要求は受け付けません。パッシブ候補では、着信接続要求を受け付けますが、自ら接続を開始しません。S-O候補では、相手と同時に接続を開始します。
When gathering candidates from a host interface, the agent typically obtains active, passive, and S-O candidates. Similarly, one can use different techniques for obtaining, e.g., server reflexive, NAT-assisted, tunneled, or relayed candidates of these three types (see Section 5). Connections to servers used for relayed and server reflexive candidates are kept open during ICE processing.
ホストインターフェイスから候補を収集する場合、エージェントは通常、アクティブ、パッシブ、S-Oの各候補を取得します。同様に、サーバー反射型、NAT支援型、トンネル型、中継型の候補についても、これら3種類を取得するための手法があります（セクション5を参照）。中継候補やサーバー反射型候補に使うサーバーへの接続は、ICEの処理中は開いたままにします。
When encoding these candidates into offers and answers, the type of the candidate is signaled. In the case of active candidates, both IP address and port are present, but the port is meaningless (it is there only for making encoding of active candidates consistent with the other candidate types and is ignored by the peer). As a consequence, active candidates do not need to be physically allocated
これらの候補をオファーとアンサーに符号化する際に、候補の種類を通知します。アクティブ候補ではIPアドレスとポートの両方を記載しますが、ポート番号に意味はありません（他の候補種類と符号化形式を統一するためだけに含め、相手側は無視します）。そのため、アクティブ候補はアドレス収集時に実際のポートを割り当てる必要はありません。接続の試行に伴う実際のポート割り当ては、接続性チェック時に行われます。
at the time of address gathering. Rather, the physical allocations, which occur as a consequence of a connection attempt, occur at the time of the connectivity checks.
住所の収集時に。むしろ、接続の試みの結果として発生する物理的割り当ては、接続チェック時に発生します。
When the candidates are paired together, active candidates are always paired with passive, and S-O candidates with each other. When a connectivity check is to be made on a candidate pair, each agent determines whether it is to make a connection attempt for this pair.
候補をペアにする際、アクティブ候補は必ずパッシブ候補と組み合わせ、S-O候補は別のS-O候補と組み合わせます。候補ペアの接続性チェックを行う際、各エージェントはそのペアへの接続を開始するかどうかを判断します。
The actual process of generating connectivity checks, managing the state of the check list, and updating the Valid list works identically for TCP as it does for UDP.
接続性チェックの生成、チェックリスト状態の管理、有効リストの更新は、UDPの場合と同じ手順で行います。
ICE requires an agent to demultiplex STUN and application-layer traffic, since they appear on the same port. This demultiplexing is described in [RFC5245] and is done using the magic cookie and other fields of the message. Stream-oriented transports introduce another wrinkle, since they require a way to frame the connection so that the application and STUN packets can be extracted in order to differentiate STUN packets from application-layer traffic. For this reason, TCP media streams utilizing ICE use the basic framing provided in RFC 4571 [RFC4571], even if the application layer protocol is not RTP.
When Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) is used, they are also run over the RFC 4571 framing shim, while STUN runs outside of the (D)TLS connection. The resulting ICE TCP protocol stack is shown in Figure 1, with (D)TLS on the left side and without it on the right side.
Transport Layer Security（TLS）またはDatagram Transport Layer Security（DTLS）を使う場合も、RFC 4571のフレーミング層の上で実行します。一方、STUNは(D)TLS接続の外側で実行します。図1に、(D)TLSを使う場合（左）と使わない場合（右）のICE TCPプロトコルスタックを示します。
+----------+
| |
| App |
+----------+----------+ +----------+----------+
| | | | | |
| STUN | (D)TLS | | STUN | App |
+----------+----------+ +----------+----------+
| | | |
| RFC 4571 | | RFC 4571 |
+---------------------+ +---------------------+
| | | |
| TCP | | TCP |
+---------------------+ +---------------------+
| | | |
| IP | | IP |
+---------------------+ +---------------------+
Figure 1: ICE TCP Stack with and without (D)TLS
図1：(D)TLSを使用する場合と使用しない場合のICE TCPスタック
The implication of this is that, for any media stream protected by (D)TLS, the agent will first run ICE procedures, exchanging STUN messages. Then, once ICE completes, (D)TLS procedures begin. ICE and (D)TLS are thus "peers" in the protocol stack. The STUN messages are not sent over the (D)TLS connection, even ones sent for the purposes of keepalive in the middle of the media session.
つまり、(D)TLSで保護するメディアストリームでは、まずエージェント同士がICE手順を実行してSTUNメッセージを交換し、ICEの完了後に(D)TLS手順を開始します。したがって、プロトコルスタック上ではICEと(D)TLSは同じ階層に位置します。メディアセッション中のキープアライブ目的で送るものも含め、STUNメッセージを(D)TLS接続上で送信することはありません。
For offerers making use of ICE for TCP streams, the procedures below are used. The main differences compared to UDP candidates are the new methods for gathering candidates, how TCP candidates are prioritized, and how they are encoded in the Session Description Protocol (SDP) offer and answer.
TCPストリームにICEを使うオファー側は、以下の手順に従います。UDP候補を使う場合との主な違いは、候補収集方法、TCP候補の優先順位付け、およびSession Description Protocol（SDP）のオファーとアンサー内での符号化方法です。
Providers of real-time communications services may decide that it is preferable to have no media at all rather than to have media over TCP. To allow for choice, it is RECOMMENDED that it be possible to configure agents to either obtain or not obtain TCP candidates for real-time media.
リアルタイム通信サービスの提供者は、TCP上でメディアを送るより、メディアを一切送らない方がよいと判断することがあります。選択肢を設けるため、リアルタイムメディア用のTCP候補を取得するかどうかをエージェントごとに設定可能にすることが推奨されます (SHOULD)。
Having it be configurable, and then configuring it to be off, is far better than not having the capability at all. An important goal of this specification is to provide a single mechanism that can be used across all types of endpoints. As such, it is preferable to account for provider and network variation through configuration instead of hard-coded limitations in an implementation. Besides, network characteristics and connectivity assumptions can, and will, change over time. Just because an agent is communicating with a server on the public network today doesn't mean that it won't need to communicate with one behind a NAT tomorrow. Just because an agent is behind a NAT with endpoint-independent mapping today doesn't mean that tomorrow it won't pick up its agent and take it to a public network access point where there is a NAT with address- and port-dependent mapping properties or one that only allows outbound TCP. The way to handle these cases and build a reliable system is for agents to implement a diverse set of techniques for allocating addresses, so that at least one of them is almost certainly going to work in any situation. Implementors should consider very carefully any assumptions made about deployments before electing not to implement one of the mechanisms for address allocation. In particular, implementors should consider whether the elements in the system may be mobile and connect through different networks with different connectivity. They should also consider whether endpoints that are under their control, in terms of location and network connectivity, would always be under their control. In environments
設定可能にしたうえで無効に設定できる方が、その機能自体を持たないより望ましいです。この仕様の重要な目標は、あらゆる種類のエンドポイントで使える単一の仕組みを提供することです。そのため、実装に制限をハードコードするのではなく、設定によってプロバイダーやネットワークの違いに対応する方が望ましいです。ネットワーク特性や接続性に関する前提は時間とともに変わります。今日、エージェントがパブリックネットワーク上のサーバーと通信していても、明日はNATの背後にある相手と通信する必要が生じるかもしれません。今日、エンドポイント非依存のマッピングを行うNATの背後にいるエージェントが、明日はアドレス・ポート依存のマッピングを行うNATや、送信方向のTCP接続しか許可しないネットワークにつながることもあります。こうした状況に対処して信頼性の高いシステムを構築するには、エージェントが多様なアドレス割り当て手法を実装し、どの状況でも少なくとも1つが機能する可能性を高める必要があります。アドレス割り当て手法の一部を実装しないと決める前に、実装者は配備環境についての前提を慎重に検討してください。特に、システムの構成要素が移動し、接続性の異なるネットワーク間を移動する可能性を考慮してください。また、場所やネットワーク接続を管理できるエンドポイントが、常にその管理下にあるとは限らないことも考慮してください。
where mobility and user control are possible, a multiplicity of techniques is essential for reliability.
モビリティやユーザーによる管理が可能な環境では、信頼性を確保するために複数の手法が不可欠です。
First, agents SHOULD obtain host candidates as described in Section 5.1. Then, each agent SHOULD "obtain" (allocate a placeholder for) an active host candidate for each component of each TCP-capable media stream on each interface that the host has. The agent does not yet have to actually allocate a port for these candidates, but they are used for the creation of the check lists.
まず、エージェントはセクション5.1の説明に従ってホスト候補を取得すべきです (SHOULD)。次に、各エージェントは、各インターフェイス上のTCP対応メディアストリームごとに、各コンポーネントのアクティブなホスト候補を「取得」（プレースホルダーを割り当て）すべきです (SHOULD)。これらの候補に実際のポートを割り当てる必要はまだありませんが、チェックリストの作成に使用します。
The agent SHOULD then obtain server reflexive, NAT-assisted, and/or UDP-tunneled candidates (see Section 5.2, Section 5.3, and Section 5.4). The mechanisms for establishing these candidates and the number of candidates to collect vary from technique to technique. These considerations are discussed in the relevant sections.
次に、エージェントはサーバー反射型、NAT支援型、および／またはUDPトンネル型の候補を取得すべきです (SHOULD)（セクション5.2、5.3、5.4を参照）。候補の確立方法や収集数は手法ごとに異なり、詳細は該当する節で説明します。
Next, agents SHOULD obtain passive (and possibly S-O) relayed candidates for each component as described in Section 5.5. Each agent SHOULD also allocate a placeholder for an active relayed candidate for each component of each TCP-capable media stream.
続いて、エージェントはセクション5.5の説明に従い、各コンポーネントについてパッシブ（場合によってはS-O）中継候補を取得すべきです (SHOULD)。また、各エージェントはTCP対応メディアストリームの各コンポーネントについて、アクティブ中継候補のプレースホルダーも割り当てるべきです (SHOULD)。
It is highly RECOMMENDED that a host obtains at least one set of host candidates and one set of relayed candidates. Obtaining additional candidates will increase the chance of successfully creating a direct connection.
ホスト候補を少なくとも1組、中継候補を少なくとも1組取得することが強く推奨されます (SHOULD)。候補を追加で取得すると、直接接続の確立に成功する可能性が高まります。
Once the candidates have been obtained, the agent MUST keep the TCP connections open until ICE processing has completed. See Appendix B for important implementation guidelines.
候補を取得した後、ICE処理が完了するまでTCP接続を開いたままにしなければなりません (MUST)。重要な実装指針については付録Bを参照してください。
If a media stream is UDP-based (such as RTP), an agent MAY use an additional host TCP candidate to request a UDP-based candidate from a TURN server (or some other relay with similar functionality). Usage of such UDP candidates follows the procedures defined in ICE for UDP candidates.
メディアストリームがUDPベース（RTPなど）の場合、エージェントは追加のホストTCP候補を使い、TURNサーバー（または同等の機能を持つ別のリレー）にUDP候補を要求してもかまいません (MAY)。このようなUDP候補には、ICEでUDP候補向けに定められた手順を適用します。
Like its UDP counterparts, TCP-based STUN transactions are paced out at one every Ta milliseconds (see Section 16 of [RFC5245]). This pacing refers strictly to STUN transactions (both Binding and Allocate requests). If performance of the transaction requires establishment of a TCP connection, then the connection gets opened when the transaction is performed.
UDPの場合と同様に、TCPベースのSTUNトランザクションはTaミリ秒ごとに1件のペースで実行します（[RFC5245]のセクション16を参照）。このペーシングの対象はSTUNトランザクション（Binding要求とAllocate要求の両方）に限られます。トランザクションの実行にTCP接続の確立が必要な場合は、そのトランザクションを実行する時点で接続を開きます。
The transport protocol itself is a criteria for choosing one candidate over another. If a particular media stream can run over UDP or TCP, the UDP candidates might be preferred over the TCP
候補を選択する際には、トランスポートプロトコルも基準になります。特定のメディアストリームをUDPまたはTCPで送れる場合、UDP候補をTCP候補より優先することがあります。
candidates. This allows ICE to use the lower latency UDP connectivity if it exists but fallback to TCP if UDP doesn't work.
UDPが使える場合、ICEは遅延の小さいUDP接続を利用し、UDPが機能しなければTCPにフォールバックできます。
In Section 4.1.2.1 of [RFC5245], a recommended formula for UDP ICE candidate prioritization is defined. For TCP candidates, the same formula and candidate type preferences SHOULD be used, and the RECOMMENDED type preferences for the new candidate types defined in this document (see Section 5) are 105 for NAT-assisted candidates and 75 for UDP-tunneled candidates.
[RFC5245]のセクション4.1.2.1では、UDP ICE候補の優先度を決める推奨式を定めています。TCP候補にも同じ式と候補種別優先度を使用すべきです (SHOULD)。また、この文書で新たに定める候補種別（セクション5を参照）の推奨優先度は、NAT支援型候補が105、UDPトンネル型候補が75です (SHOULD)。
When both UDP and TCP candidates are offered for the same media stream, and one transport protocol should be preferred over the other, the type preferences for the preferred transport protocol candidates SHOULD be increased and/or the type preferences for the other transport protocol candidates SHOULD be decreased. How much the values should be increased or decreased depends on whether it is more important to choose a certain transport protocol or a certain candidate type. If the candidate type is more important (e.g., even if UDP is preferred, TCP host candidates are preferred over UDP server reflexive candidates) changing type preference values by one for the other transport protocol candidates is enough. On the other hand, if the transport protocol is more important (e.g., any UDP candidate is preferred over any TCP candidate), all the preferred transport protocol candidates SHOULD have type preference higher than the other transport protocol candidates. However, it is RECOMMENDED that the relayed candidates are still preferred lower than the other candidate types. For RTP-based media streams, it is RECOMMENDED that UDP candidates are preferred over TCP candidates.
同じメディアストリームにUDP候補とTCP候補の両方を提示し、一方のトランスポートプロトコルを優先する場合は、優先するプロトコルの候補種別優先度を上げること (SHOULD) と、他方の候補種別優先度を下げること (SHOULD) のいずれか、または両方を行うべきです。どの程度上げ下げするかは、特定のトランスポートプロトコルと候補種別のどちらを優先するかによります。候補種別の方が重要な場合（たとえばUDPを優先しつつ、UDPサーバー反射型候補よりTCPホスト候補を優先する場合）は、他方のプロトコルの候補種別優先度を1だけ変更すれば十分です。一方、トランスポートプロトコルの方が重要な場合（たとえば、すべてのUDP候補をすべてのTCP候補より優先する場合）は、優先するプロトコルの候補すべての候補種別優先度を、他方の候補より高くすべきです (SHOULD)。ただし、中継候補の優先度は、引き続き他の候補種別より低くすることが推奨されます (SHOULD)。RTPベースのメディアストリームでは、TCP候補よりUDP候補を優先することが推奨されます (SHOULD)。
With TCP candidates, the local preference part of the recommended priority formula is updated to also include the directionality (active, passive, or simultaneous-open) of the TCP connection. The RECOMMENDED local preference is then defined as:
TCP候補では、推奨優先度式のローカル優先度にTCP接続の方向（アクティブ、パッシブ、同時オープン）も反映するように変更します。推奨するローカル優先度を次のように定義します (SHOULD)。
local preference = (2^13) * direction-pref + other-pref
The direction-pref MUST be between 0 and 7 (both inclusive), with 7 being the most preferred. The other-pref MUST be between 0 and 8191 (both inclusive), with 8191 being the most preferred. It is RECOMMENDED that the host, UDP-tunneled, and relayed TCP candidates have the direction-pref assigned as follows: 6 for active, 4 for passive, and 2 for S-O. For the NAT-assisted and server reflexive candidates, the RECOMMENDED values are: 6 for S-O, 4 for active, and 2 for passive.
direction-prefは0以上7以下でなければならず (MUST)、7が最も高い優先度です。other-prefは0以上8191以下でなければなりません (MUST)。8191が最も高い優先度です。ホスト、UDPトンネル型、および中継型のTCP候補には、アクティブを6、パッシブを4、S-Oを2としてdirection-prefを割り当てることが推奨されます (SHOULD)。NAT支援型候補とサーバー反射型候補では、S-Oを6、アクティブを4、パッシブを2とすることが推奨されます (SHOULD)。
The preference priorities listed here are simply recommendations that try to strike a balance between success probability and the resulting path's efficiency. Depending on the scenario where ICE TCP is used,
ここに示す優先度は、接続成功率と、確立後の経路効率とのバランスを取るための推奨値です。ICE TCPを使用する状況によっては、
different values may be appropriate. For example, if the overhead of a UDP tunnel is not an issue, those candidates should be prioritized higher since they are likely to have a high success probability. Also, simultaneous-open is prioritized higher than active and passive candidates for NAT-assisted and server reflexive candidates since if TCP S-O is supported by the operating systems of both endpoints, it should work at least as well as the active-passive approach. If an implementation is uncertain whether S-O candidates are supported, it may be reasonable to prioritize them lower. For host, UDP-tunneled, and relayed candidates, the S-O candidates are prioritized lower than active and passive since active-passive candidates should work with them at least as well as the S-O candidates.
別の値が適切な場合があります。たとえば、UDPトンネルのオーバーヘッドが問題にならないなら、成功率が高いと考えられるUDPトンネル候補の優先度を上げます。NAT支援型とサーバー反射型候補では、両エンドポイントのOSがTCP同時オープンに対応していれば、同時オープンはアクティブ／パッシブ方式と同等以上に機能するはずなので、同時オープン候補をより高く優先します。実装がS-O候補への対応を確認できない場合は、優先度を下げてもよいでしょう。ホスト、UDPトンネル型、中継型候補では、アクティブ／パッシブ方式でもS-O方式と同等以上に機能するはずなので、S-O候補の優先度をアクティブ候補とパッシブ候補より低くします。
If any two candidates have the same type-preference and direction-pref, they MUST have a unique other-pref. With this specification, this usually only happens with multi-homed hosts, in which case other-pref is the preference for the particular IP address from which the candidate was obtained. When there is only a single IP address, this value SHOULD be set to the maximum allowed value (8191).
同じtype-prefとdirection-prefを持つ候補が複数ある場合、それぞれ異なるother-prefを割り当てなければなりません (MUST)。この仕様では通常、複数のネットワークインターフェイスを持つホストでのみ該当します。その場合、other-prefは候補の取得元となったIPアドレスに対する優先度です。IPアドレスが1つだけの場合、この値は許容される最大値（8191）に設定すべきです (SHOULD)。
The default candidate is chosen primarily based on the likelihood of it working with a non-ICE peer. When media streams supporting mixed modes (both TCP and UDP) are used with ICE, it is RECOMMENDED that, for real-time streams (such as RTP), the default candidates be UDP-based. However, the default SHOULD NOT be a simultaneous-open candidate.
デフォルト候補は、ICEを使わないピアとの通信が成功する可能性を主な基準として選択します。TCPとUDPの両方に対応するメディアストリームでICEを使う場合、RTPなどのリアルタイムストリームにはUDPベースのデフォルト候補を選ぶことが推奨されます (SHOULD)。ただし、デフォルト候補を同時オープン候補にすべきではありません (SHOULD NOT)。
If a media stream is inherently TCP-based, it is RECOMMENDED for an offering full agent to select an active candidate as the default candidate and use [RFC4145] "setup" attribute value "active". This increases the chances for a successful NAT traversal even without ICE support if the agent is behind a NAT and the peer is not. For the same reason, for a lite agent, it is RECOMMENDED to use a passive candidate and "setup" attribute value "passive" in the offer.
メディアストリームが本質的にTCPベースの場合、完全モードのオファー側はアクティブ候補をデフォルト候補に選び、[RFC4145]の「setup」属性を「active」にすることが推奨されます (SHOULD)。エージェントがNATの背後にあり、ピアがそうでない場合、これによりICEに対応していなくてもNATトラバーサルの成功率が上がります。同じ理由から、ライトモードのエージェントはオファー内でパッシブ候補を使い、「setup」属性を「passive」にすることが推奨されます (SHOULD)。
If an offerer meets the criteria for the lite mode as described in Appendix A of [RFC5245] (i.e., it will always have a public, globally unique IP address), it MAY use the lite mode of ICE for TCP candidates. In the lite mode, for TCP candidates, only passive host candidates are gathered, unless active candidates are needed as the default candidates. Otherwise, the procedures described for lite mode in [RFC5245] also apply to TCP candidates. If UDP and TCP candidates are mixed in a media stream, the mode (lite or full) applies to both UDP and TCP candidates.
オファラーが [RFC5245] の付録Aに記載されているLiteモードの基準を満たす場合（すなわち、常にパブリックでグローバルに一意なIPアドレスを持つ場合）、TCP候補に対してICEのLiteモードを使用してもよいです (MAY)。Liteモードでは、TCP候補について、アクティブ候補がデフォルト候補として必要とされない限り、パッシブホスト候補のみが収集されます。それ以外の場合は、[RFC5245] でLiteモードについて説明されている手順がTCP候補にも適用されます。メディアストリームでUDP候補とTCP候補が混在している場合、そのモード（LiteまたはFull）はUDP候補とTCP候補の双方に適用されます。
TCP-based candidates are encoded into a=candidate lines like the UDP candidates described in [RFC5245]. However, the transport protocol (i.e., value of the transport-extension token defined in [RFC5245], Section 15.1) is set to "TCP" and the connection type (active, passive, or S-O) is encoded using a new extension attribute. With TCP candidates, the candidate-attribute syntax with Augmented BNF [RFC5234] is then:
candidate-attribute = "candidate" ":" foundation SP component-id SP
"TCP" SP
priority SP
connection-address SP
port SP
cand-type
[SP rel-addr]
[SP rel-port]
SP tcp-type-ext
*(SP extension-att-name SP
extension-att-value)
tcp-type-ext = "tcptype" SP tcp-type
tcp-type = "active" / "passive" / "so"
The connection-address encoded into the candidate-attribute for active candidates MUST be set to the IP address that will be used for the attempt, but the port(s) MUST be set to 9 (i.e., Discard). For active relayed candidates, the value for connection-address MUST be identical to the IP address of a passive or simultaneous-open candidate from the same relay server.
アクティブ候補のcandidate-attributeに符号化するconnection-addressは、接続試行に使用するIPアドレスに設定しなければなりません (MUST)。一方、ポート番号は9（Discard）に設定しなければなりません (MUST)。アクティブな中継候補の場合、connection-addressは、同じリレーサーバーから得たパッシブ候補またはS-O候補のIPアドレスと同一でなければなりません (MUST)。
If the default candidate is TCP-based, the agent MUST include the a=setup and a=connection attributes from RFC 4145 [RFC4145], following the procedures defined there as if ICE were not in use. In particular, if an agent is the answerer, the a=setup attribute MUST meet the constraints in RFC 4145 based on the value in the offer.
デフォルト候補がTCPベースの場合、エージェントはICEを使わない場合と同じ手順で、RFC 4145 [RFC4145]のa=setup属性とa=connection属性を含めなければなりません (MUST)。特に、アンサー側のエージェントは、オファー内の値に基づいてRFC 4145の制約を満たすa=setup属性を設定しなければなりません (MUST)。
If an agent is utilizing SRTP [RFC3711], it MAY include a mix of UDP and TCP candidates. If ICE selects a TCP candidate pair, it is RECOMMENDED that the agent still utilizes SRTP but runs it over the connection established by ICE. The alternative, RTP over TLS, breaks RTP header compression and on-path RTP analysis tools and hence SHOULD be avoided. In the case of DTLS-SRTP [RFC5764], the directionality attributes (a=setup) are utilized strictly to determine the direction of the DTLS handshake. Directionality of the TCP connection establishment is determined by the ICE attributes and procedures defined here.
If an agent is securing non-RTP media over TCP/TLS, the SDP MUST be constructed as described in RFC 4572 [RFC4572]. The directionality attributes (a=setup) are utilized strictly to determine the direction of the TLS handshake. Directionality of the TCP connection establishment is determined by the ICE attributes and procedures defined here.
エージェントがTCP/TLS上の非RTPメディアを保護する場合、RFC 4572 [RFC4572]の説明に従ってSDPを構成しなければなりません (MUST)。方向属性（a=setup）はTLSハンドシェイクの方向を決める目的に限って使います。TCP接続確立の方向は、ここで定義するICE属性と手順で決まります。
Examples of SDP offers and answers with ICE TCP extensions are shown in Appendix C.
ICE TCP拡張機能を使用したSDPオファーと回答の例は、付録Cに示されています。
The following sections discuss a number of techniques that can be used to obtain candidates for use with ICE TCP. It is important to note that this list is not intended to be exhaustive, nor is implementation of any specific technique beyond host candidates (Section 5.1) considered mandatory.
以下の節では、ICE TCPで使う候補の取得に利用できるいくつかの手法を説明します。この一覧は網羅的なものではありません。また、ホスト候補（セクション5.1）以外の特定の手法を実装することは必須ではありません。
Implementors are encouraged to implement as many of the following techniques from the following list as is practical, as well as to explore additional NAT-traversal techniques beyond those discussed in this document. However, to get a reasonable success ratio, one SHOULD implement at least one relayed technique (e.g., TURN) and one technique for discovering the address given for the host by a NAT (e.g., STUN).
実装者には、実用上可能な範囲で以下の手法をできるだけ多く実装し、この文書で扱っていないNATトラバーサル手法も検討することを推奨します。十分な接続成功率を得るには、少なくとも1つの中継手法（TURNなど）と、NATがホストに割り当てたアドレスを検出する手法（STUNなど）を実装すべきです (SHOULD)。
To increase the success probability with the techniques described below and to aid with transition to IPv6, implementors SHOULD take particular care to include both IPv4 and IPv6 candidates as part of the process of gathering candidates. If the local network or host does not support IPv6 addressing, then clients SHOULD make use of other techniques, e.g., TURN-IPv6 [RFC6156], Teredo [RFC4380], or SOCKS IPv4-IPv6 gatewaying [RFC3089], for obtaining IPv6 candidates.
While implementations SHOULD support as many techniques as feasible, they SHOULD also consider which of them to use if multiple options are available. Since different candidates are paired with each other, offering a large number of candidates results in a large check list and potentially long-lasting connectivity checks. For example, using multiple NAT-assisted techniques with the same NAT usually results only in redundant candidates. Similarly, using just one of the multiple UDP tunneling or relaying techniques is often enough.
実装では実現可能な限り多くの手法に対応すべきですが (SHOULD)、複数の選択肢が使える場合には、どれを使うかも検討すべきです (SHOULD)。候補は相互にペアになるため、大量の候補を提示するとチェックリストが大きくなり、接続性チェックが長引く可能性があります。たとえば、同じNATに対して複数のNAT支援型手法を使っても、冗長な候補が増えるだけの場合があります。同様に、複数あるUDPトンネル手法や中継手法のうち1つだけで十分な場合もよくあります。
Host candidates are the most simple candidates since they only require opening TCP sockets on the host's interfaces and sending/ receiving connectivity checks from them. However, if the hosts are
ホスト候補は、ホストのインターフェイスでTCPソケットを開き、そこから接続性チェックを送受信するだけでよいため、最も単純な候補です。ただし、ホストが
behind different NATs, host candidates usually fail to work. On the other hand, if there are no NATs between the hosts, host candidates are the most efficient method since they require no additional NAT traversal protocols or techniques.
異なるNATの背後にある場合、ホスト候補では通常接続できません。一方、ホスト間にNATがなければ、追加のNATトラバーサルプロトコルや手法が不要なため、ホスト候補が最も効率的です。
For each TCP-capable media stream the agent wishes to use (including ones like RTP that can be either UDP or TCP), the agent SHOULD obtain two host candidates (each on a different port) for each component of the media stream on each interface that the host has -- one for the simultaneous-open and one for the passive candidate. If an agent is not capable of acting in one of these modes, it would omit those candidates.
エージェントが使用する各TCP対応メディアストリーム（UDPとTCPのいずれでも動作するRTPなどを含む）について、各インターフェイス上の各コンポーネントに、異なるポートを使うホスト候補を2つ取得すべきです (SHOULD)。一方は同時オープン用、もう一方はパッシブ用です。いずれかのモードで動作できないエージェントは、その候補を提示しません。
Server reflexive techniques aim to discover the address a NAT has given for the host by asking that from a server on the other side of the NAT and then creating proper bindings (unless such already exist) on the NATs with connectivity checks sent between the hosts. Success of these techniques depends on the NATs' mapping and filtering behavior [RFC5382] and also on whether the NATs and hosts support the TCP simultaneous-open technique.
サーバー反射型の手法では、NATの外側にあるサーバーに問い合わせてNATがホストに割り当てたアドレスを検出し、ホスト間の接続性チェックを送ってNATに適切なバインディングを作成します（すでに作成済みの場合を除きます）。成功するかどうかは、NATのマッピングとフィルタリングの動作[RFC5382]に加え、NATとホストがTCP同時オープンに対応しているかどうかにも左右されます。
Obtaining server reflexive passive candidates may require initiating connections from host's passive candidates; see Appendix B for implementation details on this. Server reflexive active candidates can be derived from passive or S-O candidates by using the same IP addresses and interfaces as those candidates. It is useful to obtain both server reflexive passive and S-O candidates since which one actually works better depends on the hosts and NATs. Furthermore, some techniques (e.g., TURN relaying) require knowing the IP address of the peer's active candidates beforehand, so active server reflexive candidates are needed for such techniques to function properly.
サーバー反射型のパッシブ候補を取得するには、ホストのパッシブ候補から接続を開始する必要がある場合があります。実装の詳細は付録Bを参照してください。サーバー反射型のアクティブ候補は、パッシブ候補またはS-O候補と同じIPアドレスおよびインターフェイスを使って取得できます。どちらが有効かはホストやNATによって異なるため、サーバー反射型のパッシブ候補とS-O候補の両方を取得すると有用です。さらに、TURN中継など一部の手法では、ピアのアクティブ候補のIPアドレスを事前に知る必要があるため、正常に機能させるにはサーバー反射型のアクティブ候補が必要です。
A widely used protocol for obtaining server reflexive candidates is STUN. Its TCP-specific behavior is described in [RFC5389], Section 7.2.2.
サーバー反射型候補の取得に広く使われるプロトコルはSTUNです。TCP固有の動作については[RFC5389]のセクション7.2.2で説明しています。
NAT-assisted techniques communicate with the NATs directly and, in this way, discover the address that the NAT has given to the host. NAT-assisted techniques also create proper bindings on the NATs. The benefit of these techniques over the server reflexive techniques is that the NATs can adjust their mapping and filtering behavior so that connections can be successfully created. A downside of NAT-assisted techniques is that they commonly allow communicating only with a NAT
NAT支援型の手法ではNATと直接通信し、NATがホストに割り当てたアドレスを検出します。また、NAT上に適切なバインディングを作成します。サーバー反射型の手法と異なり、NAT支援型の手法ではNATのマッピングやフィルタリングの動作を調整して、接続を確立できる場合があります。一方、一般に通信相手として許可されるのは、ホストと
that is in the same subnet as the host and thus often fail in scenarios with multiple layers of NATs. These techniques also rely on NATs supporting the specific protocols and allowing the users to modify their behavior.
同じサブネットにあるNATだけであるため、NATが多段になっている環境では失敗しやすいという欠点があります。また、これらの手法ではNATが特定のプロトコルに対応し、利用者による動作変更を許可している必要があります。
These candidates are encoded in the ICE offer and answer like the server reflexive candidates, but they (commonly) use a higher priority (as described in Section 4.2) and hence are tested before the server reflexive candidates.
これらの候補は、サーバー反射型候補と同様にICEオファーとアンサーに符号化しますが、通常はより高い優先度を使うため（セクション4.2を参照）、サーバー反射型候補より先に検査します。
Currently, the Universal Plug and Play (UPnP) forum's Internet Gateway Device (IGD) protocol [UPnP-IGD] and the NAT Port Mapping Protocol (PMP) [NAT-PMP] are widely supported NAT-assisted techniques. Other known protocols include Port Control Protocol (PCP) [PCP-BASE], SOCKS [RFC1928], Realm Specific IP (RSIP) [RFC3103], and Simple Middlebox Configuration (SIMCO) [RFC4540]. Also, the Middlebox Communications (MIDCOM) MIB [RFC5190] defines a mechanism based on the Simple Network Management Protocol (SNMP) for controlling NATs.
現在広くサポートされているNAT支援型手法には、Universal Plug and Play（UPnP）フォーラムのInternet Gateway Device（IGD）プロトコル[UPnP-IGD]と、NAT Port Mapping Protocol（PMP）[NAT-PMP]があります。ほかに、Port Control Protocol（PCP）[PCP-BASE]、SOCKS [RFC1928]、Realm Specific IP（RSIP）[RFC3103]、Simple Middlebox Configuration（SIMCO）[RFC4540]などがあります。また、Middlebox Communications（MIDCOM）MIB [RFC5190]は、Simple Network Management Protocol（SNMP）に基づいてNATを制御する仕組みを定めています。
UDP-tunneled NAT traversal techniques utilize the fact that UDP NAT traversal is simpler and more efficient than TCP NAT traversal. With these techniques, the TCP packets (or possibly complete IP packets) are encapsulated in UDP packets. Because of the encapsulation, these techniques increase the overhead for the connection and may require support from both of the endpoints, but on the other hand, UDP tunneling commonly results in reliable and fairly simple TCP NAT traversal.
UDPトンネル型のNATトラバーサル手法は、UDPによるNAT越えがTCPより簡単で効率的であることを利用します。これらの手法では、TCPパケット（場合によってはIPパケット全体）をUDPパケットにカプセル化します。カプセル化により接続のオーバーヘッドが増え、両エンドポイントの対応が必要になる場合がありますが、UDPトンネルを使うと一般に、比較的単純で信頼性の高いTCPのNATトラバーサルが可能になります。
UDP-tunneled candidates can be encoded in the ICE offer and answer either as relayed or server reflexive candidates, depending on whether the tunneling protocol utilizes a relay between the hosts. The UDP-tunneled candidates may appear to applications as host candidates from a local pseudo-interface. Treating these candidates as host candidates results in incorrect prioritization and possibly non-optimal candidate selection. Implementations may attempt to detect pseudo-interfaces, e.g., from the address prefix of the interface, but detection details vary from technique to technique.
UDPトンネル型候補は、トンネルプロトコルがホスト間のリレーを使うかどうかに応じて、ICEオファーとアンサーで中継候補またはサーバー反射型候補として符号化できます。UDPトンネル型候補は、ローカルの擬似インターフェイスに由来するホスト候補としてアプリケーションから見える場合があります。これらをホスト候補として扱うと、優先順位付けを誤り、最適でない候補を選ぶ可能性があります。実装は、たとえばインターフェイスのアドレスプレフィックスから擬似インターフェイスを検出してもかまいませんが、検出方法は手法ごとに異なります。
Relaying packets through a relay server is often the NAT traversal technique that has the highest success probability: communicating via a relay that is in the public Internet looks like normal client-server communication for the NATs and is supported in practice by all existing NATs, regardless of their filtering and mapping behavior. However, using a relay has several drawbacks, e.g., it usually results in a sub-optimal path for the packets, the relay needs to exist and it needs to be discovered, the relay is a possible single point of failure, relaying consumes potentially a lot of resources of the relay server, etc. Therefore, relaying is often used as the last resort when no direct path can be created with other NAT traversal techniques.
リレーサーバー経由でパケットを中継する方法は、NATトラバーサルの成功率が最も高いことがよくあります。パブリックインターネット上のリレーを経由する通信は、NATから通常のクライアント／サーバー通信に見えるため、フィルタリングやマッピングの動作によらず、実際には既存のすべてのNATでサポートされています。ただし、リレーにはいくつかの欠点があります。通常、パケット経路が最適でなくなること、リレーの設置と検出が必要なこと、リレーが単一障害点になり得ること、リレーサーバーのリソースを大量に消費する可能性があることなどです。そのため、他のNATトラバーサル手法で直接経路を確立できない場合の最後の手段として使われることがよくあります。
With relayed candidates, the host commonly needs to obtain only a passive candidate since any of the peer's server reflexive (and NAT-assisted if the peer can communicate with the outermost NAT) active candidates should work with the passive relayed candidate. However, if the relay is behind a NAT or a firewall, also using active and S-O candidates will increase success probability.
中継候補の場合、通常、ホストが取得するのはパッシブ候補だけで十分です。ピアのサーバー反射型アクティブ候補（ピアが最外部のNATと通信できる場合はNAT支援型アクティブ候補も）は、パッシブ中継候補と接続できるはずです。ただし、リレーがNATまたはファイアウォールの背後にある場合、アクティブ候補やS-O候補も使うと成功率が上がります。
Relaying protocols capable of relaying TCP connections include TURN TCP [RFC6062] and SOCKS [RFC1928] (which can also be used for IPv4- IPv6 gatewaying [RFC3089]). It is also possible to use a Secure SHell (SSH) [RFC4251] tunnel as a relayed candidate if a suitable server is available and the server permits this.
Handling an ICE offer with TCP candidates works in a similar way as with UDP candidates. First, ICE support is verified (including the check for ice-mismatch described in Section 5.1 of [RFC5245]) and agent roles are determined. Candidates are gathered using the techniques described in Section 5 and prioritized as described in Section 4.2. Default candidates are selected taking into account the considerations in Section 4.3. The SDP answer is encoded as in Section 4.3 of [RFC5245], with the exception of TCP candidates whose encoding is described in Section 4.5.
When the offerer receives the initial answer, it also verifies ICE support and determines its role. If both of the agents use lite implementations, the offerer takes the controlling role and uses the procedures defined in [RFC4145] to select the most preferred candidate pair with a new offer.
オファー側は最初のアンサーを受け取ると、ICEへの対応も確認して自らの役割を決定します。両方のエージェントがライト実装の場合、オファー側は制御側の役割を担い、[RFC4145]で定める手順に従って、新しいオファーで最も優先度の高い候補ペアを選択します。
If both agents are using the lite mode and if the offerer uses the a=setup:active attribute [RFC4145] in the new offer, the offerer MAY initiate the TCP connection on the selected pair in parallel with the new offer to speed up the connection establishment. Consequently, the answerer MUST still accept incoming TCP connections to any of the passive candidates it listed in the answer, from any of the IP addresses the offerer listed in the initial offer.
両方のエージェントがライトモードを使い、オファー側が新しいオファーでa=setup:active属性[RFC4145]を使う場合、接続確立を速めるため、新しいオファーの送信と並行して、選択した候補ペアのTCP接続を開始してもかまいません (MAY)。その場合も、アンサー側は、最初のオファーに記載されたIPアドレスのいずれかから、アンサーに記載したパッシブ候補への着信TCP接続を受け入れなければなりません (MUST)。
If the answerer receives the new offer matching the candidate pair where a connection was already created in parallel with the new offer, it MUST accept the offer and respond to it while keeping the already-created connection. If the connection that was created in parallel with the new offer does not match the candidate pair in the new offer, the connection MUST be closed, and ICE restart SHOULD be performed.
アンサー側が、新しいオファーと並行してすでに確立した接続に対応する候補ペアを含むオファーを受信した場合、その接続を維持したままオファーを受け入れて応答しなければなりません (MUST)。並行して確立した接続が新しいオファーの候補ペアに一致しない場合は、その接続を閉じなければならず (MUST)、ICEを再起動すべきです (SHOULD)。
Since the connection endpoints are not authenticated using the connectivity checks in the scenario where both agents use the lite mode, unless media-level security (e.g., TLS) is used, it is RECOMMENDED to use the full mode instead. For more lite versus full implementation considerations, see Appendix A of [RFC5245].
両エージェントがライトモードの場合、接続エンドポイントは接続性チェックによって認証されません。そのため、メディア層のセキュリティ（TLSなど）を使わない限り、フルモードを使うことが推奨されます (SHOULD)。ライト実装とフル実装に関するその他の考慮事項は、[RFC5245]の付録Aを参照してください。
As with UDP, check lists are formed only by full ICE implementations. When forming candidate pairs, the following types of TCP candidates can be paired with each other:
UDPの場合と同様、チェックリストを作成するのはフルICE実装だけです。候補ペアを作成する際は、以下の種類のTCP候補を互いに組み合わせられます。
Local Remote
Candidate Candidate
---------------------------
tcp-so tcp-so
tcp-active tcp-passive
tcp-passive tcp-active
When the agent prunes the check list, it MUST also remove any pair for which the local candidate is a passive TCP candidate. With pruning, the NAT-assisted candidates are treated like server reflexive candidates if the base is also used as a host candidate.
エージェントがチェックリストを枝刈りする際、ローカル候補がTCPパッシブ候補であるペアも削除しなければなりません (MUST)。枝刈りでは、ベース候補もホスト候補として使われている場合、NAT支援型候補をサーバー反射型候補と同様に扱います。
The remainder of check list processing works in the same way as the UDP case.
チェックリストの残りの処理はUDPの場合と同じです。
The TCP connectivity checks, like with UDP, are generated only by full implementations. The TCP candidate pairs are in the same check list with the UDP candidate pairs, and they are scheduled for connectivity checks, as described in Section 5.8 of [RFC5245], based on the priority order.
UDPの場合と同様、TCP接続性チェックを生成するのはフル実装だけです。TCP候補ペアはUDP候補ペアと同じチェックリストに含まれ、優先順位に従い、[RFC5245]のセクション5.8で説明する方法でチェックを実行します。
When an agent wants to send a TCP-based connectivity check, it first opens a TCP connection, if none yet exists, for the 5-tuple defined by the candidate pair for which the check is to be sent. This connection is opened from the local candidate of the pair to the remote candidate of the pair. If the local candidate is tcp-active, the agent MUST open a connection from the interface associated with that local candidate. This connection SHOULD be opened from an unallocated port. For host candidates, this is readily done by connecting from the local candidate's interface. For relayed, NAT-assisted, and UDP-tunneled candidates, the agent may need to use additional procedures specific to the protocol.
エージェントがTCPベースの接続性チェックを送る場合、まず、そのチェック対象の候補ペアが定める5タプルに対応したTCP接続を開きます（まだ接続がない場合）。接続はペアのローカル候補からリモート候補に向けて開きます。ローカル候補がtcp-activeの場合、エージェントはその候補に関連付けられたインターフェイスから接続を開かなければなりません (MUST)。この接続は未割り当てのポートから開くべきです (SHOULD)。ホスト候補の場合は、ローカル候補のインターフェイスから接続すれば実現できます。中継候補、NAT支援型候補、UDPトンネル型候補では、プロトコル固有の追加手順が必要になることがあります。
Once the connection is established, the agent MUST utilize the shim defined in RFC 4571 [RFC4571] for the duration this connection remains open. The STUN Binding requests and responses are sent on top of this shim, so that the length field defined in RFC 4571 precedes each STUN message. If TLS or DTLS-SRTP is to be utilized for the media session, the TLS or DTLS-SRTP handshakes will take place on top of this shim as well. However, they only start once ICE processing has completed. In essence, the TLS or DTLS-SRTP handshakes are considered a part of the media protocol. STUN is never run within the TLS or DTLS-SRTP session as part of the ICE procedures.
接続が確立したら、接続が開いている間はRFC 4571 [RFC4571]で定義するフレーミング層を使わなければなりません (MUST)。STUN Binding要求と応答はこのフレーミング層上で送るため、各STUNメッセージの前にRFC 4571の長さフィールドが置かれます。メディアセッションの保護にTLSまたはDTLS-SRTPを使う場合、そのハンドシェイクも同じフレーミング層上で行います。ただし、開始するのはICE処理の完了後です。つまり、TLSまたはDTLS-SRTPのハンドシェイクはメディアプロトコルの一部として扱います。ICE手順の一部として、TLSまたはDTLS-SRTPセッション内でSTUNを実行することはありません。
If the TCP connection cannot be established, the check is considered to have failed, and a full-mode agent MUST update the pair state to Failed in the check list. See Section 7.2.2 of [RFC5389] for more details on STUN over TCP.
TCP接続を確立できない場合、そのチェックは失敗とみなします。フルモードのエージェントは、チェックリスト内のペア状態をFailedに更新しなければなりません (MUST)。TCP上のSTUNについて詳しくは[RFC5389]のセクション7.2.2を参照してください。
Once the connection is established, client procedures are identical to those for UDP candidates. However, retransmissions of the STUN connectivity check messages are not needed, since TCP takes care of reliable delivery of the messages. Note also that STUN responses received on an active TCP candidate will typically produce a peer reflexive candidate. If the response to the first connectivity check on the established TCP connection is something other than a STUN
接続が確立した後のクライアント手順はUDP候補の場合と同じです。ただし、TCPがメッセージを確実に届けるため、STUN接続性チェックメッセージを再送する必要はありません。また、アクティブTCP候補で受信したSTUN応答によって、通常はピア反射型候補が生成されます。
message, the remote candidate address apparently was not one of the peer's addresses, and the agent SHOULD close the connection and consider all pairs with that remote candidate as failed.
確立済みTCP接続で最初の接続性チェックに対してSTUN以外のメッセージを受け取った場合、リモート候補アドレスはピアのアドレスではないと考えられます。その場合、エージェントは接続を閉じ、そのリモート候補を含むすべての候補ペアを失敗とみなすべきです (SHOULD)。
An ICE TCP agent, full or lite, MUST be prepared to receive incoming TCP connection requests on the base of any TCP candidate that is simultaneous-open or passive. When the connection request is received, the agent MUST accept it. The agent MUST utilize the framing defined in RFC 4571 [RFC4571] for the lifetime of this connection. Due to this framing, the agent will receive data in discrete frames. Each frame could be media (such as RTP or SRTP), TLS, DTLS, or STUN packets. The STUN packets are extracted as described in Section 10.2.
ICE TCPエージェントはフルモードでもライトモードでも、同時オープンまたはパッシブのTCP候補のベースアドレス宛ての着信TCP接続要求を受信できるようにしておかなければなりません (MUST)。接続要求を受信したら、受け入れなければなりません (MUST)。接続の存続中はRFC 4571 [RFC4571]のフレーミングを使用しなければなりません (MUST)。このフレーミングによってデータは個別のフレームとして届き、各フレームにはメディア（RTPやSRTPなど）、TLS、DTLS、またはSTUNのパケットが含まれる場合があります。STUNパケットの取り出し方はセクション10.2で説明します。
Once the connection is established, STUN server procedures are identical to those for UDP candidates. Note that STUN requests received on a passive TCP candidate will typically produce a remote peer reflexive candidate.
接続確立後のSTUNサーバー手順は、UDP候補の場合と同じです。パッシブTCP候補で受信したSTUN要求によって、通常はリモートのピア反射型候補が生成されます。
If there are TCP candidates for a media stream, a controlling agent MUST use the regular selection algorithm.
メディアストリームにTCP候補が含まれる場合、制御側エージェントは通常の選択アルゴリズムを使用しなければなりません (MUST)。
When ICE processing for a media stream completes, each agent SHOULD close all TCP connections (that were opened due to this ICE session) except the ones between the candidate pairs selected by ICE.
メディアストリームのICE処理が完了したら、各エージェントは、ICEが選択した候補ペア間の接続を除き、このICEセッション中に開いたすべてのTCP接続を閉じるべきです (SHOULD)。
These two rules are related; the closure of connection on completion of ICE implies that a regular selection algorithm has to be used. This is because aggressive selection might cause transient pairs to be selected. Once such a pair is selected, the agents would close the other connections, one of which may be about to be selected as a better choice. This race condition may result in TCP connections being accidentally closed for the pair that ICE selects.
この2つの規則は関連しています。ICE完了時に接続を閉じるには、通常の選択アルゴリズムを使う必要があります。アグレッシブ選択を使うと、一時的な候補ペアが選択される可能性があるためです。そのペアが選ばれると、エージェントは他の接続を閉じますが、その中に、より適切な候補として選択される直前の接続が含まれる可能性があります。この競合状態により、ICEが最終的に選ぶ候補ペアのTCP接続を誤って閉じることがあります。
When an updated offer is generated by the controlling endpoint after the connectivity checks have succeeded, the SDP extensions for connection-oriented media [RFC4145] are used to signal that an existing connection should be used, rather than opening a new one.
接続性チェックの成功後、制御側エンドポイントが更新オファーを生成する際は、接続指向メディア向けSDP拡張[RFC4145]を使い、新しい接続を開くのではなく既存の接続を使うことを通知します。
If an ICE restart occurs for a media stream with TCP candidate pairs that have been selected by ICE, the agents MUST NOT close the connections after the restart. In the offer or answer that causes the restart, an agent MAY include a simultaneous-open candidate whose transport address matches the previously selected candidate. If both agents do this, the result will be a simultaneous-open candidate pair matching an existing TCP connection. In this case, the agents MUST NOT attempt to open a new connection (or start new TLS or DTLS-SRTP procedures). Instead, that existing connection is reused, and STUN checks are performed.
ICEが選択したTCP候補ペアを含むメディアストリームでICEを再起動する場合、エージェントは再起動後も接続を閉じてはなりません (MUST NOT)。再起動を起こすオファーまたはアンサーに、以前選択した候補と同じトランスポートアドレスを持つ同時オープン候補を含めてもかまいません (MAY)。両エージェントがそうすると、既存のTCP接続に対応する同時オープン候補ペアができます。この場合、新しい接続を開いたり、新しいTLSまたはDTLS-SRTP手順を開始したりしてはなりません (MUST NOT)。既存の接続を再利用し、STUNチェックを実行します。
Once the restart completes, if the selected pair does not match the previously selected pair, the TCP connection for the previously selected pair SHOULD be closed by the agent.
再起動の完了後、選択された候補ペアが以前の選択と異なる場合、エージェントは以前のペアのTCP接続を閉じるべきです (SHOULD)。
When sending media, if the selected candidate pair matches an existing TCP connection, that connection MUST be used for sending media.
メディアを送信する際、選択した候補ペアに対応するTCP接続がすでに存在する場合、その接続を使わなければなりません (MUST)。
The framing defined in RFC 4571 MUST be used when sending media. For media streams that are not RTP-based and do not normally use RFC 4571, the agent treats the media stream as a byte stream and assumes that it has its own framing of some sort, if needed. It then takes an arbitrary number of bytes from the byte stream and places that as a payload in the RFC 4571 frames, including the length. Next, the sender checks to see if the resulting set of bytes would be viewed as a STUN packet based on the rules in Sections 6 and 8 of [RFC5389]. This includes a check on the most significant two bits, the magic cookie, the length, and the fingerprint. If, based on those rules, the bytes would be viewed as a STUN message, the sender MUST utilize a different number of bytes so that the length checks will fail. Though it is normally highly unlikely that an arbitrary number of bytes from a byte stream would resemble a STUN packet based on all of the checks, it can happen if the content of the application stream happens to contain a STUN message (for example, a file transfer of logs from a client that includes STUN messages).
メディアの送信にはRFC 4571で定義するフレーミングを使わなければなりません (MUST)。RTPベースではなく通常RFC 4571を使わないメディアストリームでは、エージェントはメディアストリームをバイトストリームとして扱い、必要であれば独自のフレーミングがあるものとします。次にバイトストリームから任意の長さのデータを取り出し、長さフィールドとともにRFC 4571フレームのペイロードに格納します。その後、生成したバイト列が[RFC5389]のセクション6および8の規則に基づいてSTUNパケットと解釈されないか確認します。この確認には、上位2ビット、マジッククッキー、長さ、フィンガープリントの検査が含まれます。STUNメッセージと解釈される場合、長さの検査に失敗するよう、送信者は取り出すバイト数を変えなければなりません (MUST)。任意の長さのバイト列がすべての検査に一致することは通常ほとんどありませんが、アプリケーションデータにSTUNメッセージが含まれる場合（たとえば、STUNメッセージを含むクライアントログのファイル転送時）には起こり得ます。
If TLS or DTLS-SRTP procedures are being utilized to protect the media stream, those procedures start at the point that media is permitted to flow, as defined in the ICE specification [RFC5245]. The TLS or DTLS-SRTP handshakes occur on top of the RFC 4571 shim and
メディアストリームの保護にTLSまたはDTLS-SRTPを使う場合、ICE仕様[RFC5245]でメディアの送信が許可された時点で、これらの手順を開始します。TLSまたはDTLS-SRTPのハンドシェイクはRFC 4571のフレーミング層上で行い、
are considered part of the media stream for the purposes of this specification.
この仕様ではメディアストリームの一部として扱います。
The framing defined in RFC 4571 MUST be used when receiving media. For media streams that are not RTP-based and do not normally use RFC 4571, the agent extracts the payload of each RFC 4571 frame and determines if it is a STUN or an application-layer data based on the procedures in ICE [RFC5245]. If media is being protected with DTLS-SRTP, the DTLS, RTP, and STUN packets are demultiplexed as described in Section 5.1.2 of [RFC5764].
For non-STUN data, the agent appends this to the ongoing byte stream collected from the frames. It then parses the byte stream as if it had been directly received over the TCP connection. This allows for ICE TCP to work without regard to the framing mechanism used by the application-layer protocol.
STUN以外のデータは、エージェントがフレームから収集した進行中のバイトストリームに追加します。その後、TCP接続から直接受信した場合と同様にバイトストリームを解析します。これにより、アプリケーション層プロトコルのフレーミング方式によらずICE TCPを動作させられます。
Once a TCP or TCP/TLS connection is opened by ICE for the purpose of connectivity checks, its life cycle depends on how it is used. If that candidate pair is selected by ICE for usage for media, an agent SHOULD keep the connection open until:
ICEが接続性チェックのためにTCPまたはTCP/TLS接続を開いた場合、その後のライフサイクルは接続の用途によって異なります。ICEがメディア用にその候補ペアを選択した場合、エージェントは次のいずれかが起きるまで接続を開いたままにすべきです (SHOULD)。
o the session terminates,
o セッションが終了する。
o the media stream is removed, or
o メディアストリームが削除されます
o an ICE restart takes place, resulting in the selection of a different candidate pair.
o アイス再起動が行われ、異なる候補ペアが選択されます。
In any of these cases, the agent SHOULD close the connection when that event occurs. This applies to both agents in a session, in which case one of the agents will usually end up closing the connection first.
これらの場合、エージェントはそのイベントが発生したときに接続を閉じるべきです (SHOULD)。これは、セッションの両方のエージェントに適用されます。その場合、エージェントの1人が通常、最初に接続を閉じることになります。
If a connection has been selected by ICE, an agent MAY close it anyway. As described in the next paragraph, this will cause it to be reopened almost immediately, and in the interim, media cannot be sent. Consequently, such closures have a negative effect and are NOT RECOMMENDED. However, there may be cases where an agent needs to close a connection for some reason.
ICEが選択した接続であっても、エージェントは閉じてもかまいません (MAY)。次の段落で説明するとおり、接続はほぼ直ちに再確立されますが、その間はメディアを送信できません。そのため、このように接続を閉じることは不利益をもたらし、推奨されません (SHOULD NOT)。ただし、何らかの理由で接続を閉じる必要がある場合もあります。
If an agent needs to send media on the selected candidate pair, and its TCP connection has closed, then:
エージェントが選択した候補ペアでメディアを送信する必要があり、そのTCP接続が閉じている場合、次のとおりです。
o If the agent's local candidate is tcp-active or tcp-so, it MUST reopen a connection to the remote candidate of the selected pair.
o ローカル候補がtcp-activeまたはtcp-soの場合、エージェントは選択したペアのリモート候補への接続を再び開かなければなりません (MUST)。
o If the agent's local candidate is tcp-passive, the agent MUST await an incoming connection request and, consequently, will not be able to send media until it has been opened.
o ローカル候補がtcp-passiveの場合、エージェントは着信接続要求を待たなければなりません (MUST)。接続が確立するまでメディアを送信できません。
If the TCP connection is established, the framing of RFC 4571 is utilized. If the agent opened the connection and is a full agent, it MUST send a STUN connectivity check. An agent MUST be prepared to receive a connectivity check over a connection it opened or accepted (note that this is true in general; ICE requires that an agent be prepared to receive a connectivity check at any time, even after ICE processing completes). If a full agent receives a connectivity check after re-establishment of the connection, it MUST generate a triggered check over that connection in response if it has not already sent a check. Once an agent has sent a check and received a successful response, the connection is considered Valid, and media can be sent (which includes a TLS or DTLS-SRTP session resumption or restart).
TCP接続が確立すると、RFC 4571のフレーミングを使用します。フルモードのエージェントが接続を開いた場合は、STUN接続性チェックを送信しなければなりません (MUST)。エージェントは、自ら開いた接続でも受け入れた接続でも、接続性チェックを受信できるようにしておかなければなりません (MUST)。一般にICEでは、処理完了後も含め、いつでも接続性チェックを受信できるようにしておく必要があります。接続の再確立後にフルモードのエージェントが接続性チェックを受信し、まだチェックを送信していない場合は、その接続上で応答としてトリガーチェックを生成しなければなりません (MUST)。チェックを送信して成功応答を受信すると、その接続はValidとみなされ、メディアを送信できます（TLSまたはDTLS-SRTPセッションの再開や再ネゴシエーションも含みます）。
If the TCP connection cannot be established, the controlling agent SHOULD restart ICE for this media stream. This will happen in cases where one of the agents is behind a NAT with connection-dependent mapping properties [RFC5382].
TCP接続を確立できない場合、制御側エージェントはこのメディアストリームのICEを再起動すべきです (SHOULD)。これは、一方のエージェントが接続依存マッピングを行うNATの背後にいる場合に起こります[RFC5382]。
If the agent opened a connection to a STUN server, or another similar server, for the purposes of gathering a server reflexive candidate, that connection SHOULD be closed by the client once ICE processing has completed. This happens regardless of whether the candidate learned from the server was selected by ICE.
サーバー反射型候補を収集するためにSTUNサーバーなどへの接続を開いた場合、ICE処理の完了後、クライアントはその接続を閉じるべきです (SHOULD)。この候補をICEが選択したかどうかは問いません。
If the agent opened a connection to a TURN server for the purposes of gathering a relayed candidate, that connection MUST be kept open by the client for the duration of the media session if a relayed candidate from the TURN server was selected by ICE. Otherwise, the connection to the TURN server SHOULD be closed once ICE processing completes.
中継候補の収集のためにTURNサーバーへの接続を開き、そのサーバーの中継候補がICEによって選択された場合、クライアントはメディアセッションの間、その接続を開いたままにしなければなりません (MUST)。それ以外の場合、ICE処理の完了後にTURNサーバーへの接続を閉じるべきです (SHOULD)。
If, despite efforts of the client, a TCP connection to a TURN server fails during the lifetime of the media session utilizing a transport address allocated by that server, the client SHOULD reconnect to the TURN server, obtain a new allocation, and restart ICE for that media
クライアントが対処しても、TURNサーバーが割り当てたトランスポートアドレスを使うメディアセッション中にTURNサーバーへのTCP接続が切断された場合、クライアントはTURNサーバーに再接続し、新しい割り当てを取得して、そのメディアストリームのICEを再起動すべきです (SHOULD)。
stream. Similar measures SHOULD apply also to other types of relaying servers.
他の種類の中継サーバーにも同様の措置を適用すべきです (SHOULD)。
The main threat in ICE is hijacking of connections for the purposes of directing media streams to denial-of-service (DoS) targets or to malicious users. When full implementations are used, ICE TCP prevents that by only using TCP connections that have been validated. Validation requires a STUN transaction to take place over the connection. This transaction cannot complete without both participants knowing a shared secret exchanged in the rendezvous protocol used with ICE, such as SIP [RFC3261]. This shared secret, in turn, is protected by that protocol exchange. In the case of SIP, the usage of the SIP Secure (SIPS) [RFC3261] mechanism is RECOMMENDED. When this is done, an attacker, even if it knows or can guess the port on which an agent is listening for incoming TCP connections, will not be able to open a connection and send media to the agent.
ICEに対する主な脅威は、メディアストリームをサービス拒否（DoS）の標的や悪意ある利用者に向けるために接続を乗っ取ることです。フル実装では、検証済みのTCP接続だけを使うことでICE TCPがこの脅威を防ぎます。検証には接続上でSTUNトランザクションを実行する必要があります。SIP [RFC3261]などICEで使うランデブープロトコルで交換する共有シークレットを双方が知らなければ、このトランザクションは完了しません。この共有シークレットは、そのプロトコル交換によって保護されます。SIPの場合、SIP Secure（SIPS）[RFC3261]機構を使うことが推奨されます (SHOULD)。こうすれば、攻撃者が着信TCP接続を待ち受けるポートを知っている、または推測できても、接続を開いてエージェントにメディアを送ることはできません。
If the rendezvous protocol exchange is compromised, the shared secret can be learned by an attacker, and the attacker may be able to fake the connectivity check validation and open a TCP connection to the target. Hence, using additional security mechanisms (e.g., application-layer security) that mitigate these risks is RECOMMENDED.
ランデブープロトコルの交換が侵害されると、攻撃者が共有シークレットを入手し、接続性チェックの検証を偽装して標的へのTCP接続を開ける可能性があります。そのため、このリスクを軽減する追加のセキュリティ機構（アプリケーション層セキュリティなど）を使うことが推奨されます (SHOULD)。
A STUN amplification attack is described in Section 18.5.2 of [RFC5245]. The same considerations apply to TCP, but the amplification effect with TCP is larger due to need for establishing a TCP connection before any checks are performed. Therefore, an ICE agent SHOULD NOT have more than 5 outstanding TCP connection attempts with the same peer to the same IP address.
STUN増幅攻撃については[RFC5245]のセクション18.5.2で説明しています。同じ考慮事項はTCPにも当てはまりますが、チェックの前にTCP接続を確立する必要があるため、TCPでは増幅効果が大きくなります。したがって、ICEエージェントは、同じピアの同じIPアドレスに対する未完了のTCP接続試行を5件より多く持つべきではありません (SHOULD NOT)。
If both agents use the lite mode, no connectivity checks are sent, and additional procedures (e.g., media-level security) are needed to validate the connection. The lack of connectivity checks is especially problematic if one of the hosts is behind a NAT and has an address from a private address space: the peer may accidentally connect to a host in a different subnet that uses the same private address space. This is one of the reasons why the lite mode is not appropriate for an ICE agent located behind a NAT.
両方のエージェントがライトモードを使う場合、接続性チェックは送信されないため、接続を検証するにはメディア層セキュリティなどの追加手順が必要です。いずれかのホストがNATの背後にあり、プライベートアドレス空間のアドレスを持つ場合、接続性チェックがないことは特に問題です。ピアが、同じプライベートアドレス空間を使う別サブネット上のホストに誤って接続する可能性があります。これが、NATの背後にあるICEエージェントにライトモードが適さない理由の1つです。
A more detailed analysis of different attacks and the various ways ICE prevents them are described in [RFC5245]. Those considerations apply to this specification.
さまざまな攻撃と、それらをICEが防ぐ方法の詳しい分析は[RFC5245]で説明しています。そこに記載された考慮事項は、この仕様にも当てはまります。
IANA has created a new sub-registry "ICE Transport Protocols" in the "Interactive Connectivity Establishment (ICE)" registry for ICE candidate-attribute transport extensions. Initial values are given below; future assignments are to be made through IETF Review or IESG Approval [RFC5226]. Assignments consist of an extension token (as defined in Section 15.1 of [RFC5245]) and a reference to the document defining the extension.
Token Reference
----- ---------
UDP RFC 5245, Section 15.1
TCP RFC 6544, Section 4.5
The authors would like to thank Tim Moore, Saikat Guha, Francois Audet, Roni Even, Simon Perreault, Alfred Heggestad, Hadriel Kaplan, Jonathan Lennox, Flemming Andreasen, Dan Wing, and Vijay Gurbani for the reviews and input on this document. Special thanks to Marc Petit-Huguenin for providing the SDP examples.
著者は、本書のレビューと意見を寄せたTim Moore、Saikat Guha、Francois Audet、Roni Even、Simon Perreault、Alfred Heggestad、Hadriel Kaplan、Jonathan Lennox、Flemming Andreasen、Dan Wing、Vijay Gurbaniに感謝します。SDPの例を提供したMarc Petit-Hugueninにも特に感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[IMC05] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of the 5th ACM SIGCOMM Conference on Internet Measurement, 2005.
[IMC05] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of the 5th ACM SIGCOMM Conference on Internet Measurement, 2005.
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012.
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006.
[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0", RFC 4540, May 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008.
[RFC5190] Quittek, J., Stiemerling, M., and P. Srisuresh, "Definitions of Managed Objects for Middlebox Communication", RFC 5190, March 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010.
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, April 2011.
[UPnP-IGD] Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., Schmitz, M., Siddiqi, W., and M. Blaszczak, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001.
[UPnP-IGD] Warrier, U., Iyer, P., Pennerath, F., Marynissen, G., Schmitz, M., Siddiqi, W., and M. Blaszczak, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001.
Compared to UDP-based ICE, ICE TCP has, in general, lower success probability for enabling connectivity without a relay if both of the hosts are behind a NAT. This happens because many of the currently deployed NATs have endpoint-dependent mapping behavior, or they do not support the flow of TCP handshake packets seen in the case of TCP simultaneous-open, e.g., some NATs do not allow incoming TCP SYN packets from an address where a SYN packet has been sent to recently or the subsequent SYN-ACK is not processed properly.
UDPベースのICEと比べると、両方のホストがNATの背後にある場合、ICE TCPはリレーなしで接続できる成功率が一般に低くなります。これは、現在使われているNATの多くがエンドポイント依存のマッピングを行うか、TCP同時オープン時に見られるTCPハンドシェイクパケットの流れに対応していないためです。たとえば、最近SYNパケットを送った宛先からの着信TCP SYNを許可しないNATや、後続のSYN-ACKを適切に処理しないNATがあります。
It has been reported in [IMC05] that with the population of NATs deployed at the time of the measurements (2005), one of the NAT traversal techniques described here, TCP simultaneous-open, worked in roughly 45% of the cases. Also, not all operating systems implement TCP simultaneous-open properly and thus are not able to use such candidates. However, when more NATs comply with the requirements set by [RFC5382] and operating system TCP stacks are fixed, the success probability of simultaneous-open is likely to increase. Also, it is important to implement additional techniques with higher success ratios, such as Teredo, whose success in different scenarios is described in Figure 1 of [RFC6081].
Finally, it should be noted that implementing various techniques listed in Section 5 should increase the success probability, but many of these techniques require support from the endpoints and/or from some network elements (e.g., from the NATs). Without comprehensive experimental data on how well different techniques are supported, the actual increase of success probability is hard to evaluate.
最後に、セクション5の複数の手法を実装すると接続成功率を高められますが、多くの手法ではエンドポイントやネットワーク要素（NATなど）の対応が必要です。各手法の対応状況を示す包括的な実験データがないため、成功率が実際にどの程度向上するかを評価するのは困難です。
This specification requires unusual handling of TCP connections, the implementation of which is non-trivial in traditional BSD socket APIs.
この仕様ではTCP接続を通常とは異なる方法で扱います。その実装は、従来のBSDソケットAPIでは容易ではありません。
In particular, ICE requires an agent to obtain a local TCP candidate, bound to a local IP and port, then initiate a TCP connection from that local port (e.g., to the STUN server in order to obtain server reflexive candidates, to the TURN server to obtain a relayed candidate, or to the peer as part of a connectivity check), and be prepared to receive incoming TCP connections (for passive and simultaneous-open candidates). A "typical" BSD socket is used either for initiating or receiving connections, and not for both. The code required to allow incoming and outgoing connections on the same local IP and port is non-obvious. The following pseudocode, contributed by Saikat Guha, has been found to work on many platforms:
特にICEでは、エージェントがローカルIPアドレスとポートにバインドしたTCP候補を取得し、そのローカルポートからTCP接続を開始すると同時に、着信TCP接続も受信できるようにする必要があります。接続先には、サーバー反射型候補を得るためのSTUNサーバー、中継候補を得るためのTURNサーバー、接続性チェックの一環として接続するピアなどがあります。着信接続を受け入れる必要があるのは、パッシブ候補と同時オープン候補です。一般的なBSDソケットは接続の開始か受信のどちらかに使い、両方には使いません。同じローカルIPアドレスとポートで着信接続と発信接続を許可するコードは分かりにくいものです。Saikat Guhaが提供した以下の疑似コードは、多くのプラットフォームで動作することが確認されています。
for i in 0 to MAX sock_i = socket() set(sock_i, SO_REUSEADDR) bind(sock_i, local)
0からmax sock_i = socket（）set（sock_i、SO_REUSEADDR）bind（sock_i、local）のiの場合
listen(sock_0) connect(sock_1, stun) connect(sock_2, remote_a) connect(sock_3, remote_b)
聞く（sock_0）connect（sock_1、stun）connect（sock_2、remote_a）connect（sock_3、remote_b）
The key here is that, prior to the listen() call, the full set of sockets that need to be utilized for outgoing connections must be allocated and bound to the local IP address and port. This number, MAX, represents the maximum number of TCP connections to different destinations that might need to be established from the same local candidate. This number can be potentially large for simultaneous-open candidates. If a request forks, ICE procedures may take place with multiple peers. Furthermore, for each peer, connections would need to be established to each passive or simultaneous-open candidate for the same component. If we assume a worst case of 5 forked branches, and for each peer, five simultaneous-open candidates, that results in MAX=25.
ここで重要なのは、listen()を呼び出す前に、発信接続に使うすべてのソケットを割り当て、ローカルIPアドレスとポートにバインドしておくことです。MAXは、同じローカル候補から異なる宛先へ確立する必要があり得るTCP接続数の上限を表します。同時オープン候補では、この数が大きくなる場合があります。要求が複数の分岐先にフォークされると、ICE手順を複数のピアと並行して実行することがあります。さらに各ピアについて、同じコンポーネントの各パッシブ候補または同時オープン候補への接続が必要です。最悪の場合として、要求が5つにフォークされ、各ピアに5つの同時オープン候補があると仮定すると、MAX=25になります。
This section shows two examples of SDP offer and answer when the ICE TCP extension is used. Both examples are based on the simplified topology of Figure 8 in [RFC5245], with the same IP addresses. The examples shown here should be considered strictly informative.
この節では、ICE TCP拡張を使ったSDPのオファーとアンサーの例を2つ示します。両方とも[RFC5245]の図8に示す単純化したトポロジーと同じIPアドレスに基づいています。以下の例は情報提供のみを目的とします。
In the first example, the offer contains only TCP candidates (lines are folded in examples to satisfy RFC formatting rules):
最初の例では、オファーにTCP候補だけを含めています（RFCの書式規則に合わせ、例では行を折り返しています）。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 TCP/RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=setup:active
a=connection:new
a=candidate:1 1 TCP 2128609279 10.0.1.1 9 typ host tcptype active
a=candidate:2 1 TCP 2124414975 10.0.1.1 8998 typ host tcptype passive
a=candidate:3 1 TCP 2120220671 10.0.1.1 8999 typ host tcptype so
a=candidate:4 1 TCP 1688207359 192.0.2.3 9 typ srflx raddr 10.0.1.1
rport 9 tcptype active
a=candidate:5 1 TCP 1684013055 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 tcptype passive
a=candidate:6 1 TCP 1692401663 192.0.2.3 45687 typ srflx raddr
10.0.1.1 rport 8999 tcptype so
The answer to that offer could look like this:
このオファーに対するアンサーは次のようになります。
v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio 3478 TCP/RTP/AVP 0
b=RS:0
b=RR:0
a=setup:passive
a=connection:new
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2128609279 192.0.2.1 9 typ host tcptype active
a=candidate:2 1 TCP 2124414975 192.0.2.1 3478 typ host tcptype passive
a=candidate:3 1 TCP 2120220671 192.0.2.1 3482 typ host tcptype so
In the second example, UDP and TCP media streams are mixed, but S-O candidates are omitted due to hosts not supporting TCP simultaneous-open, and UDP candidates are preferred (but preference order for candidate types is kept the same) by decreasing the TCP candidate type preferences by one (i.e., using type preference 125 for the host candidates and 99 for the server reflexive candidates):
2つ目の例ではUDPとTCPのメディアストリームを混在させています。ホストがTCP同時オープンに対応しないためS-O候補は省略し、TCP候補種別の優先度を1下げることでUDP候補を優先しています（候補種別間の優先順位は維持します。ホスト候補には125、サーバー反射型候補には99の優先度を使います）。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2111832063 10.0.1.1 9 typ host tcptype active
a=candidate:2 1 TCP 2107637759 10.0.1.1 9012 typ host tcptype passive
a=candidate:3 1 TCP 1671430143 192.0.2.3 9 typ srflx raddr 10.0.1.1
rport 9 tcptype active
a=candidate:4 1 TCP 1667235839 192.0.2.3 44642 typ srflx raddr
10.0.1.1 rport 9012 tcptype passive
a=candidate:5 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:6 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
The corresponding answer could look like this:
対応するアンサーは次のようになります。
v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 TCP 2111832063 192.0.2.1 9 typ host tcptype active
a=candidate:2 1 TCP 2107637759 192.0.2.1 3478 typ host tcptype passive
a=candidate:3 1 UDP 2130706431 192.0.2.1 3478 typ host
Authors' Addresses
著者の連絡先
Jonathan Rosenberg jdrosen.net
Jonathan Rosenberg jdrosen.net
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
Ari Keranen Ericsson Hirsalantie 11 02420 Jorvas Finland
EMail: ari.keranen@ericsson.com
Bruce B. Lowekamp Skype
Bruce B. Lowekamp Skype
EMail: bbl@lowekamp.net
Adam Roach Tekelec 17210 Campbell Rd., Suite 250 Dallas, TX 75252 US
Adam Roach Tekelec 17210 Campbell Rd., Suite 250 Dallas, TX 75252 US
EMail: adam@nostrum.com