[要約] RFC 8155は、TURNサーバーの自動検出に関する規格であり、NATの周りをリレーするためのトラバーサルを可能にします。その目的は、クライアントがTURNサーバーを自動的に検出し、通信の信頼性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) P. Patil
Request for Comments: 8155 T. Reddy
Updates: 5766 Cisco
Category: Standards Track D. Wing
ISSN: 2070-1721 April 2017
Traversal Using Relays around NAT (TURN) Server Auto Discovery
NATのリレーを使用したトラバーサル（TURN）サーバーの自動検出
Abstract
概要
Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.
NATのリレーを使用する現在のトラバーサル（TURN）サーバー検出メカニズムは比較的静的であり、明示的な構成に制限されています。これらは通常、アプリケーションまたはTURNサービスプロバイダーの管理下にあり、企業、ISP、またはクライアントが配置されているネットワークではありません。独自のTURNサーバーを提供することを望む企業とISPは、TURNクライアントが最小限の構成で、または構成なしで使用できる自動検出メカニズムを必要とします。このドキュメントでは、TURNサーバー検出のための3つのそのようなメカニズムについて説明します。
This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.
このドキュメントでは、RFC 5766を更新して、特定の場合に相互認証の要件を緩和しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8155.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8155で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 4
4. Discovery Using Service Resolution . . . . . . . . . . . . . 5
4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. From Own Identity . . . . . . . . . . . . . . . . . . 6
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery Using Anycast . . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP Addresses . . . . . . . . . . . 8
7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
8.2. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 12
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 12
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
TURN [RFC5766] is a protocol that is often used to improve the connectivity of Peer-to-Peer (P2P) applications (as defined in Section 2.7 of [RFC5128]). TURN allows a connection to be established when one or both sides are incapable of a direct P2P connection. It is an important building block for interactive, real-time communication using audio, video, collaboration, etc.
TURN [RFC5766]は、ピアツーピア（P2P）アプリケーションの接続性を改善するためによく使用されるプロトコルです（[RFC5128]のセクション2.7で定義）。 TURNを使用すると、片側または両側で直接P2P接続ができない場合に接続を確立できます。これは、オーディオ、ビデオ、コラボレーションなどを使用したインタラクティブなリアルタイムコミュニケーションのための重要なビルディングブロックです。
While TURN services are extensively used today, the means to automatically discover TURN servers do not exist. TURN clients are usually explicitly configured with a well-known TURN server. To allow TURN applications to operate seamlessly across different types of networks and encourage the use of TURN without the need for manual configuration, it is important that there exist an auto-discovery mechanism for TURN services. Web Real-Time Communication (WebRTC) [WebRTC-Overview] usages and related extensions, which are mostly based on web applications, need TURN server discovery mechanisms.
TURNサービスは今日広く使用されていますが、TURNサーバーを自動的に検出する手段はありません。 TURNクライアントは通常、既知のTURNサーバーで明示的に構成されます。 TURNアプリケーションがさまざまなタイプのネットワーク間でシームレスに動作し、手動で構成する必要なくTURNの使用を促進できるようにするには、TURNサービスの自動検出メカニズムが存在することが重要です。 Webリアルタイム通信（WebRTC）[WebRTCの概要]の使用法および関連する拡張機能は、主にWebアプリケーションに基づいているため、TURNサーバー検出メカニズムが必要です。
This document describes three discovery mechanisms, so as to maximize the opportunity for discovery, based on the network in which the TURN client finds itself. The three discovery mechanisms are:
このドキュメントでは、TURNクライアントが自分自身を見つけるネットワークに基づいて、発見の機会を最大化する3つの発見メカニズムについて説明します。 3つの検出メカニズムは次のとおりです。
o A resolution mechanism based on Straightforward-Naming Authority Pointer (S-NAPTR) resource records in the Domain Name System (DNS). [RFC5928] describes details on retrieving a list of server transport addresses from the DNS that can be used to create a TURN allocation.
o ドメインネームシステム（DNS）のStraight-Naming Authority Pointer（S-NAPTR）リソースレコードに基づく解決メカニズム。 [RFC5928]は、TURN割り当ての作成に使用できるDNSからサーバートランスポートアドレスのリストを取得する方法の詳細を説明しています。
o DNS Service Discovery.
o DNSサービス検出。
o A mechanism based on an anycast address for TURN.
o TURNのエニーキャストアドレスに基づくメカニズム。
In general, if a client wishes to communicate using one of its interfaces using a specific IP address family, it SHOULD query the TURN server(s) that has been discovered for that specific interface and address family. How to select an interface and IP address family is out of the scope of this document.
一般に、クライアントが特定のIPアドレスファミリを使用してそのインターフェイスの1つを使用して通信する場合は、その特定のインターフェイスおよびアドレスファミリに対して検出されたTURNサーバーにクエリを実行する必要があります。インターフェイスとIPアドレスファミリの選択方法は、このドキュメントの範囲外です。
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 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
TURN clients, by default, discover TURN server(s) by means of local or manual TURN configuration (i.e., TURN servers configured at the system level). Configuration discovered from an application, e.g., a JavaScript-specified TURN server for Web Real-Time Communication (WebRTC) [WebRTC-Overview] usages and related extensions, is considered a local configuration. An implementation may give the user an opportunity (e.g., by means of configuration file options or menu items) to specify a TURN server for each address family. A client can choose auto-discovery in the absence of local configuration, if local configuration doesn't work or in addition to local configuration. This document does not offer a recommendation on server selection.
TURNクライアントは、デフォルトで、ローカルまたは手動のTURN構成（つまり、システムレベルで構成されたTURNサーバー）によってTURNサーバーを検出します。アプリケーションから発見された構成、たとえば、Webリアルタイム通信（WebRTC）[WebRTC-Overview]の使用法と関連する拡張機能用のJavaScript指定のTURNサーバーは、ローカル構成と見なされます。実装は、ユーザーに（たとえば、構成ファイルオプションまたはメニュー項目を使用して）各アドレスファミリのTURNサーバーを指定する機会を与えることができます。クライアントは、ローカル構成が機能しない場合、またはローカル構成に加えて、ローカル構成がない場合に自動検出を選択できます。このドキュメントでは、サーバーの選択に関する推奨事項は提供していません。
A TURN client that implements the auto-discovery algorithm, to discover TURN servers in the attached network, uses the following mechanisms for discovery:
自動検出アルゴリズムを実装するTURNクライアントは、接続されたネットワークでTURNサーバーを検出するために、次のメカニズムを使用して検出します。
o Service Resolution: The TURN client attempts to perform TURN service resolution using the host's DNS domain.
o サービス解決：TURNクライアントは、ホストのDNSドメインを使用してTURNサービス解決を実行しようとします。
o DNS SD: DNS Service Discovery.
o DNS SD：DNSサービス検出。
o Anycast: Send TURN Allocation request to the assigned TURN anycast request for each combination of interface and address family.
o エニーキャスト：インターフェイスとアドレスファミリの組み合わせごとに、割り当てられたTURNエニーキャスト要求にTURN Allocation要求を送信します。
Not all TURN servers may be discovered using NAPTR records or DNS SD. Similarly, not all TURN servers may support anycast. For best results, a client SHOULD implement all the discovery mechanisms described above.
すべてのTURNサーバーがNAPTRレコードまたはDNS SDを使用して検出されるとは限りません。同様に、すべてのTURNサーバーがエニーキャストをサポートしているわけではありません。最良の結果を得るには、クライアントは上記のすべての検出メカニズムを実装する必要があります（SHOULD）。
The document does not prescribe a strict order that a client must follow for discovery. An implementation may choose to perform all the above steps in parallel for discovery OR choose to follow any desired order and stop the discovery procedure if a mechanism succeeds.
このドキュメントは、クライアントが発見のために従わなければならない厳密な順序を規定していません。実装では、上記のすべてのステップを並行してディスカバリーに実行するか、メカニズムが成功した場合は任意の順序に従ってディスカバリー手順を停止することを選択できます。
On hosts with more than one interface or address family (IPv4/v6), the TURN server discovery procedure has to be performed for each combination of interface and address family. A client MAY choose to perform the discovery procedure only for a desired interface/address combination if the client does not wish to discover a TURN server for all combinations of interface and address family.
複数のインターフェイスまたはアドレスファミリ（IPv4 / v6）を持つホストでは、インターフェイスとアドレスファミリの組み合わせごとにTURNサーバーの検出手順を実行する必要があります。クライアントは、インターフェイスとアドレスファミリのすべての組み合わせに対してTURNサーバーを検出したくない場合、目的のインターフェイスとアドレスの組み合わせに対してのみ検出手順を実行することを選択できます（MAY）。
This mechanism is performed in two steps:
このメカニズムは2つのステップで実行されます。
1. A DNS domain name is retrieved for each combination of interface and address family.
1. インターフェイスとアドレスファミリの組み合わせごとにDNSドメイン名が取得されます。
2. Retrieved DNS domain names are then used for S-NAPTR lookups as per [RFC5928]. Further DNS lookups may be necessary to determine TURN server IP address(es).
2. 取得されたDNSドメイン名は、[RFC5928]に従ってS-NAPTRルックアップに使用されます。 TURNサーバーのIPアドレスを特定するには、さらにDNSルックアップが必要になる場合があります。
A client has to determine the domain in which it is located. The following sections provide two possible mechanisms to learn the domain name, but other means of retrieving domain names may be used, which are outside the scope of this document, e.g., local configuration.
クライアントは、それが置かれているドメインを判別する必要があります。次のセクションでは、ドメイン名を学習するための2つの可能なメカニズムを提供しますが、ドメイン名を取得する他の手段を使用することもできます。これは、このドキュメントの範囲外です（ローカル構成など）。
Implementations may allow the user to specify a default name that is used if no specific name has been configured.
実装では、特定の名前が構成されていない場合に使用されるデフォルト名をユーザーが指定できるようにする場合があります。
DHCP can be used to determine the domain name related to an interface's point of network attachment. Network operators may provide the domain name to be used for service discovery within an access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define DHCP IPv4 and IPv6 access network domain name options, OPTION_V4_ACCESS_DOMAIN and OPTION_V6_ACCESS_DOMAIN respectively, to identify a domain name that is suitable for service discovery within the access network.
DHCPを使用して、インターフェースのネットワーク接続ポイントに関連するドメイン名を判別できます。ネットワークオペレータは、DHCPを使用してアクセスネットワーク内でサービスを検出するために使用するドメイン名を提供する場合があります。 [RFC5986]のセクション3.2と3.3は、DHCP IPv4およびIPv6アクセスネットワークのドメイン名オプション、それぞれOPTION_V4_ACCESS_DOMAINおよびOPTION_V6_ACCESS_DOMAINを定義して、アクセスネットワーク内でのサービス検出に適したドメイン名を識別します。
For IPv4, the discovery procedure MUST request the access network domain name option in a Parameter Request List option, as described in [RFC2131]. [RFC2132] defines the DHCP IPv4 domain name option; while this option is less suitable, a client MAY request it if the access network domain name defined in [RFC5986] is not available.
IPv4の場合、[RFC2131]で説明されているように、発見手順はパラメータ要求リストオプションのアクセスネットワークドメイン名オプションを要求する必要があります。 [RFC2132]は、DHCP IPv4ドメイン名オプションを定義します。このオプションはあまり適切ではありませんが、[RFC5986]で定義されているアクセスネットワークドメイン名が利用できない場合、クライアントはそれを要求できます（MAY）。
For IPv6, the discovery procedure MUST request the access network domain name option in an Options Request Option (ORO) within an Information-request message, as described in [RFC3315].
IPv6の場合、[RFC3315]で説明されているように、検出手順は情報要求メッセージ内のオプション要求オプション（ORO）でアクセスネットワークドメイン名オプションを要求する必要があります。
If neither option can be retrieved, the procedure fails for this interface. If a result can be retrieved, it will be used as an input for S-NAPTR resolution.
どちらのオプションも取得できない場合、このインターフェースの手順は失敗します。結果を取得できる場合は、S-NAPTR解決の入力として使用されます。
For a TURN client with an understanding of the protocol mechanics of calling applications, the client may wish to extract the domain name from its own identity, i.e, the canonical identifier used to reach the user.
アプリケーションの呼び出しのプロトコルメカニズムを理解しているTURNクライアントの場合、クライアントは独自のID、つまりユーザーに到達するために使用される正規の識別子からドメイン名を抽出することができます。
Example:
例：
SIP : 'sip:alice@example.com'
Bare JID : 'alice@example.com'
email : 'alice@example.com'
'example.com' is retrieved from the above examples.
上記の例から「example.com」が取得されます。
A client may support multiple users, potentially with different domains, or a single user utilizing different domains for different services. The means to choose and extract the domain name may be different based on the type of identifier, service being used, etc., which are outside the scope of this document.
クライアントは、異なるドメインを持つ可能性のある複数のユーザー、または異なるサービスに対して異なるドメインを使用する単一のユーザーをサポートする場合があります。ドメイン名を選択して抽出する方法は、このドキュメントの範囲外である識別子のタイプ、使用されているサービスなどに基づいて異なる場合があります。
Once the TURN discovery procedure has retrieved domain names, the resolution mechanism described in [RFC5928] is followed. An S-NAPTR lookup with the 'RELAY' application service and the desired protocol tag is made to obtain the information necessary to connect to the authoritative TURN server within the given domain.
TURN検出手順がドメイン名を取得すると、[RFC5928]で説明されている解決メカニズムに従います。 「RELAY」アプリケーションサービスと目的のプロトコルタグを使用したS-NAPTRルックアップは、特定のドメイン内の信頼できるTURNサーバーに接続するために必要な情報を取得するために行われます。
If no TURN-specific S-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If more domain names are known, the discovery procedure may perform the corresponding S-NAPTR lookups immediately. However, before retrying a lookup that has failed, a client must wait a time period that is appropriate for the encountered error (NXDOMAIN, timeout, etc.).
TURN固有のS-NAPTRレコードを取得できない場合、このドメイン名（および対応するインターフェイスとIPプロトコルバージョン）の検出手順は失敗します。より多くのドメイン名がわかっている場合、検出手順は対応するS-NAPTRルックアップをすぐに実行する場合があります。ただし、失敗した検索を再試行する前に、クライアントは発生したエラー（NXDOMAIN、タイムアウトなど）に適した時間待機する必要があります。
DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS (mDNS) [RFC6762] provide generic solutions for discovering services available in a local network. DNS-SD/mDNS define a set of naming rules for certain DNS record types that they use for advertising and discovering services.
DNSベースのサービス検出（DNS-SD）[RFC6763]およびマルチキャストDNS（mDNS）[RFC6762]は、ローカルネットワークで利用可能なサービスを検出するための一般的なソリューションを提供します。 DNS-SD / mDNSは、サービスのアドバタイズおよび検出に使用する特定のDNSレコードタイプの一連の命名規則を定義します。
Section 4.1 of [RFC6763] specifies that a service instance name in DNS-SD has the following structure:
[RFC6763]のセクション4.1は、DNS-SDのサービスインスタンス名が次の構造を持つことを指定しています。
<Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS sub-domain where the service instance is registered. It may be "local.", indicating the mDNS local domain, or it may be a conventional domain name such as "example.com.". The <Service> portion of the TURN service instance name MUST be "_turn._udp" or "_turn._tcp" or "_turns._udp" or "_turns._tcp", as introduced in [RFC5766].
<ドメイン>部分は、サービスインスタンスが登録されているDNSサブドメインを指定します。これは、mDNSローカルドメインを示す「ローカル」の場合と、「example.com。」などの従来のドメイン名の場合があります。 [RFC5766]で紹介されているように、TURNサービスインスタンス名の<Service>部分は、「_ turn._udp」または「_turn._tcp」または「_turns._udp」または「_turns._tcp」である必要があります。
A TURN client can proactively discover TURN servers being advertised in the site by multicasting a PTR query to one or all of the following:
TURNクライアントは、PTRクエリを以下の1つまたはすべてにマルチキャストすることにより、サイトでアドバタイズされているTURNサーバーをプロアクティブに検出できます。
o "_turn._udp.local."
o 「_turn._udp.local」
o "_turn._tcp.local"
o 「_turn._tcp.local」
o "_turns._udp.local."
o 「_turns._udp.local」
o "_turns._tcp.local"
o 「_turns._tcp.local」
A TURN server can send out gratuitous multicast DNS answer packets whenever it starts up, wakes from sleep, or detects a change in network configuration. TURN clients receive these gratuitous packets and cache information contained in it.
TURNサーバーは、起動したり、スリープから復帰したり、ネットワーク構成の変更を検出したりするたびに、不要なマルチキャストDNS応答パケットを送信できます。 TURNクライアントは、これらの不要なパケットとそれに含まれるキャッシュ情報を受信します。
IP anycast can also be used for TURN service discovery. A packet sent to an anycast address is delivered to the "topologically nearest" network interface with the anycast address. Using the TURN anycast address, the only two things that need to be deployed in the network for discovery are the two things that actually use TURN.
IPエニーキャストは、TURNサービスの検出にも使用できます。エニーキャストアドレスに送信されたパケットは、エニーキャストアドレスを持つ「トポロジー的に最も近い」ネットワークインターフェイスに配信されます。 TURNエニーキャストアドレスを使用する場合、ディスカバリのためにネットワークに導入する必要があるのは、実際にTURNを使用する2つだけです。
When a client requires TURN services, it sends a TURN Allocation request to the assigned anycast address. A TURN anycast server performs checks 1 through 7 discussed in Section 6.2 of [RFC5766]. If all checks pass, the TURN anycast server MUST respond with a 300 (Try Alternate) error as described in Section 2.9 of [RFC5766]; the response contains the TURN unicast address in the ALTERNATE-SERVER attribute. For subsequent communication with the TURN server, the client uses the responding server's unicast address. This has to be done because two packets addressed to an anycast address may reach two different anycast servers. The client, thus, also needs to ensure that the initial request fits in a single packet. An implementation may choose to send out every new TURN Allocation request to the anycast address to discover the closest and the most optimal unicast address for the TURN server.
クライアントはTURNサービスが必要な場合、割り当てられたエニーキャストアドレスにTURN Allocationリクエストを送信します。 TURNエニーキャストサーバーは、[RFC5766]のセクション6.2で説明されているチェック1〜7を実行します。すべてのチェックに合格した場合、TURNエニーキャストサーバーは、[RFC5766]のセクション2.9で説明されているように、300（代替試行）エラーで応答する必要があります。応答のALTERNATE-SERVER属性にTURNユニキャストアドレスが含まれています。その後のTURNサーバーとの通信では、クライアントは応答サーバーのユニキャストアドレスを使用します。エニーキャストアドレス宛ての2つのパケットが2つの異なるエニーキャストサーバーに到達する可能性があるため、これを行う必要があります。したがって、クライアントも最初のリクエストが単一のパケットに収まるようにする必要があります。実装は、すべての新しいTURN Allocationリクエストをエニーキャストアドレスに送信して、TURNサーバーに最も近い最適なユニキャストアドレスを発見することを選択できます。
A change of IP address on an interface may invalidate the result of the TURN server discovery procedure. For instance, if the IP address assigned to a mobile host changes due to host mobility, it may be required to re-run the TURN server discovery procedure without relying on earlier gained information. New requests should be made to the newly learned TURN servers that were learned after TURN the discovery was re-run. However, if an earlier learned TURN server is still accessible using the new IP address, procedures described for mobility using TURN defined in [RFC8016] can be used for ongoing streams.
インターフェイスのIPアドレスを変更すると、TURNサーバーの検出手順の結果が無効になる場合があります。たとえば、モバイルホストに割り当てられたIPアドレスがホストモビリティのために変更された場合、以前に取得した情報に依存せずにTURNサーバー検出手順を再実行する必要がある場合があります。 TURNの後にディスカバリーが再実行されたときに学習された、新しく学習されたTURNサーバーに対して新しい要求を行う必要があります。ただし、新しいIPアドレスを使用して以前に学習したTURNサーバーに引き続きアクセスできる場合は、[RFC8016]で定義されているTURNを使用したモビリティについて説明されている手順を進行中のストリームに使用できます。
WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms described in this specification as an enterprise/gateway or access network server, in accordance with Recursively Encapsulated TURN [RETURN].
WebRTCエンドポイントは、この仕様で説明されているメカニズムを通じて発見されたTURNサーバーを、再帰的にカプセル化されたTURN [RETURN]に従って、エンタープライズ/ゲートウェイまたはアクセスネットワークサーバーとして扱う必要があります。
IANA has assigned a single IPv4 address from the 192.0.0.0/24 prefix and registered it in the "IANA IPv4 Special-Purpose Address Registry" [RFC6890].
IANAは192.0.0.0/24プレフィックスから単一のIPv4アドレスを割り当て、それを「IANA IPv4特殊目的アドレスレジストリ」[RFC6890]に登録しました。
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 192.0.0.10/32 |
| Name | Traversal Using Relays around NAT Anycast |
| RFC | RFC 8155 |
| Allocation Date | 2017-02 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
IANA has assigned a single IPv6 address from the 2001:0000::/23 prefix and registered it in the "IANA IPv6 Special-Purpose Address Registry" [RFC6890].
IANAは2001：0000 :: / 23プレフィックスから単一のIPv6アドレスを割り当て、「IANA IPv6特殊目的アドレスレジストリ」[RFC6890]に登録しました。
+----------------------+-------------------------------------------+
| Attribute | Value |
+----------------------+-------------------------------------------+
| Address Block | 2001:1::2/128 |
| Name | Traversal Using Relays around NAT Anycast |
| RFC | RFC 8155 |
| Allocation Date | 2017-02 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+-------------------------------------------+
Use of Session Traversal Utilities for NAT (STUN) [RFC5389] authentication is OPTIONAL for TURN servers provided by the local network or by the access network. A network-provided TURN server MAY be configured to accept Allocation requests without STUN authentication, and a TURN client MAY be configured to accept Allocation success responses without STUN authentication from a network-provided TURN server.
NAT（STUN）のセッショントラバーサルユーティリティの使用[RFC5389]ローカルネットワークまたはアクセスネットワークによって提供されるTURNサーバーの認証はオプションです。ネットワーク提供のTURNサーバーは、STUN認証なしで割り当て要求を受け入れるように構成できます。また、TURNクライアントは、ネットワーク提供のTURNサーバーからのSTUN認証なしで割り当て成功応答を受け入れるように構成できます（MAY）。
Making STUN authentication optional is a downgrade of a MUST level requirement defined in [RFC5766]. The downgrade allows TURN servers provided by the local or access network to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication. The intention in such deployments is to provide TURN services to all users in the local or access network. However, this opens up a TURN server to a variety of attacks described in Section 17 of [RFC5766]. A TURN server in such cases must be configured to only process STUN requests from the trusted local network or subscribers of the access network. Operational measures must be taken in order to protect the TURN server; some of these measures include, but are not limited to, access control by means of access lists, firewalls, subscriber quota limits, ingress filtering, etc.
STUN認証をオプションにすることは、[RFC5766]で定義されたMUSTレベル要件のダウングレードです。ダウングレードにより、ローカルネットワークまたはアクセスネットワークによって提供されるTURNサーバーは、STUN認証の長期的な資格情報を必ずしも持っていないネットワーク内の新しいユーザーやゲストユーザーからの割り当て要求を受け入れることができます。このような展開の目的は、ローカルネットワークまたはアクセスネットワークのすべてのユーザーにTURNサービスを提供することです。ただし、これにより、[RFC5766]のセクション17で説明されているさまざまな攻撃に対してTURNサーバーが開かれます。このような場合のTURNサーバーは、信頼できるローカルネットワークまたはアクセスネットワークのサブスクライバーからのSTUN要求のみを処理するように構成する必要があります。 TURNサーバーを保護するために、運用上の対策を講じる必要があります。これらの対策の一部には、アクセスリストによるアクセス制御、ファイアウォール、サブスクライバークォータ制限、入力フィルタリングなどが含まれますが、これらに限定されません。
A TURN client in the absence of the STUN long-term credential mechanism [RFC5389] or the STUN Extension for Third-Party Authorization [RFC7635] MUST use (D)TLS unless it trusts the network infrastructure to defend against attacks discussed in [RFC5766]. It is RECOMMENDED that the TURN client use one of the following techniques with (D)TLS to validate the TURN server:
STUN長期クレデンシャルメカニズム[RFC5389]またはサードパーティ認証用のSTUN拡張[RFC7635]がない場合のTURNクライアントは、[RFC5766]で説明されている攻撃を防御するためにネットワークインフラストラクチャを信頼しない限り、（D）TLSを使用する必要があります。 。 TURNクライアントは、（D）TLSで次のいずれかの手法を使用してTURNサーバーを検証することをお勧めします。
o For certificate-based authentication, a pre-populated trust anchor store [RFC6024] allows a TURN client to perform path validation for the server certificate obtained during the (D)TLS handshake. If the client used a domain name to discover the TURN server, that domain name also provides a mechanism for validation of the TURN server. The client MUST use the rules and guidelines given in Section 6 of [RFC6125] to validate the TURN server identity.
o 証明書ベースの認証の場合、事前入力されたトラストアンカーストア[RFC6024]を使用すると、TURNクライアントは（D）TLSハンドシェイク中に取得したサーバー証明書のパス検証を実行できます。クライアントがドメイン名を使用してTURNサーバーを検出した場合、そのドメイン名はTURNサーバーの検証メカニズムも提供します。クライアントは、[RFC6125]のセクション6に記載されているルールとガイドラインを使用して、TURNサーバーのIDを検証する必要があります。
o Certification authorities that issue TURN server certificates SHOULD support the CN-ID, DNS-ID, SRV-ID, and URI-ID identifier types. TURN service providers SHOULD prefer the use of DNS-ID, SRV-ID, and URI-ID over CN-ID identifier types in certificate requests (as described in Section 2.3 from [RFC6125]) and the wildcard character '*' SHOULD NOT be included in the presented identifier.
o TURNサーバー証明書を発行する認証局は、CN-ID、DNS-ID、SRV-ID、およびURI-ID識別子タイプをサポートする必要があります（SHOULD）。 TURNサービスプロバイダーは、証明書リクエストのCN-ID識別子タイプ（[RFC6125]のセクション2.3で説明）よりもDNS-ID、SRV-ID、およびURI-IDの使用を推奨し、ワイルドカード文字 '*'は推奨されません。提示された識別子に含まれています。
o For TURN servers that don't have a certificate trust chain (e.g., because they are on a home network or a corporate network), a configured list of TURN servers can contain the Subject Public Key Info (SPKI) fingerprint of the TURN servers. The public key is used for the same reasons HTTP pinning [RFC7469] uses the public key.
o 証明書信頼チェーンを持たないTURNサーバーの場合（たとえば、ホームネットワークまたは企業ネットワーク上にあるため）、構成されたTURNサーバーのリストには、TURNサーバーのサブジェクト公開キー情報（SPKI）フィンガープリントを含めることができます。公開鍵は、HTTPピン留め[RFC7469]が公開鍵を使用するのと同じ理由で使用されます。
o Raw public key-based authentication, as defined in [RFC7250], could also be used to authenticate a TURN server.
o [RFC7250]で定義されている生の公開鍵ベースの認証は、TURNサーバーの認証にも使用できます。
An auto-discovered TURN server is considered to be only as trusted as the path between the client and the TURN server. In order to safely use auto-discovered TURN servers for sessions with 'strict privacy' requirements, the user needs to be able to define privacy criteria (e.g., a trusted list of servers, networks, or domains) that are considered acceptable for such traffic. Any discovered TURN server outside the criteria is considered untrusted and therefore MUST NOT be used for privacy-sensitive communication.
自動検出されたTURNサーバーは、クライアントとTURNサーバー間のパスと同じくらい信頼できると見なされます。自動検出されたTURNサーバーを「厳格なプライバシー」要件のあるセッションで安全に使用するには、ユーザーは、そのようなトラフィックに受け入れられると見なされるプライバシー基準（サーバー、ネットワーク、またはドメインの信頼できるリストなど）を定義できる必要があります。 。基準外で発見されたTURNサーバーは信頼できないと見なされるため、プライバシーに配慮した通信に使用してはなりません。
In some auto-discovery scenarios, it might not be possible for the TURN client to use (D)TLS authentication to validate the TURN server. However, fallback to clear text in such cases could leave the TURN client open to on-path injection of spoofed TURN messages. A TURN client could fall back to encryption-only (D)TLS when (D)TLS authentication is not available but MUST NOT fall back without explicit administrator choice. Another reason to fall back to encryption-only is for privacy, which is analogous to SMTP opportunistic encryption [RFC7435] where one does not require privacy but one desires privacy when possible.
一部の自動検出シナリオでは、TURNクライアントが（D）TLS認証を使用してTURNサーバーを検証できない場合があります。ただし、このような場合にクリアテキストにフォールバックすると、TURNクライアントが偽のTURNメッセージをパス上に挿入する可能性があります。 （D）TLS認証が利用できない場合、TURNクライアントは暗号化のみの（D）TLSにフォールバックできますが、明示的な管理者の選択なしにフォールバックしてはなりません。暗号化のみにフォールバックするもう1つの理由はプライバシーです。これは、SMTPオポチュニスティック暗号化[RFC7435]に似ていますが、プライバシーは必要ありませんが、可能な場合はプライバシーを求めます。
In order to allow the TURN client to fall back to (D)TLS as described above, a TURN server that does not require either STUN long-term authentication [RFC5389] or STUN Extension for Third Party Authorization [RFC7635] MUST support (D)TLS and, if the network infrastructure is capable of defending against attacks discussed in [RFC5766], then the TURN server MAY allow fallback to clear text.
上記のようにTURNクライアントが（D）TLSにフォールバックできるようにするには、STUN長期認証[RFC5389]またはサードパーティ認証用のSTUN拡張[RFC7635]を必要としないTURNサーバーが（D）をサポートする必要がありますTLSと、ネットワークインフラストラクチャが[RFC5766]で説明されている攻撃を防御できる場合、TURNサーバーはフォールバックでクリアテキストを許可できます（MAY）。
A TURN client could fall back to clear text if it does not support unauthenticated (D)TLS but MUST NOT fall back without explicit administrator choice. Fallback to clear text is NOT RECOMMENDED because it makes the client more susceptible to man-in-the-middle attacks and on-path packet injection.
TURNクライアントは、非認証（D）TLSをサポートしていない場合はクリアテキストにフォールバックできますが、管理者が明示的に選択しない限りフォールバックしてはなりません。クリアテキストへのフォールバックは、クライアントが中間者攻撃やパス上のパケットインジェクションの影響を受けやすくなるため、推奨されません。
The primary attack against the methods described in this document is one that would lead to impersonation of a TURN server. An attacker could attempt to compromise the S-NAPTR resolution. Security considerations described in [RFC5928] are applicable here as well.
このドキュメントで説明されている方法に対する主な攻撃は、TURNサーバーの偽装につながる攻撃です。攻撃者はS-NAPTRの解像度を危うくする可能性があります。 [RFC5928]で説明されているセキュリティの考慮事項は、ここでも適用されます。
In addition to considerations related to S-NAPTR, it is important to recognize that the output of this is entirely dependent on its input. An attacker who can control the domain name can also control the final result. Because more than one method can be used to determine the domain name, a host implementation needs to consider attacks against each of the methods that are used.
S-NAPTRに関連する考慮事項に加えて、これの出力はその入力に完全に依存していることを認識することが重要です。ドメイン名を制御できる攻撃者は、最終結果も制御できます。ドメイン名の決定には複数の方法を使用できるため、ホストの実装では、使用する各方法に対する攻撃を考慮する必要があります。
If DHCP is used, the integrity of DHCP options is limited by the security of the channel over which they are provided. Physical security and separation of DHCP messages from other packets are commonplace methods that can reduce the possibility of attack within an access network; alternatively, DHCP authentication [RFC3188] can provide a degree of protection against modification. When using DHCP discovery, clients are encouraged to use unicast DHCP INFORM queries instead of broadcast queries, which are more easily spoofed in insecure networks.
DHCPを使用する場合、DHCPオプションの整合性は、それらが提供されるチャネルのセキュリティによって制限されます。物理的なセキュリティと他のパケットからのDHCPメッセージの分離は、アクセスネットワーク内での攻撃の可能性を減らすことができる一般的な方法です。あるいは、DHCP認証[RFC3188]は、変更に対するある程度の保護を提供できます。 DHCP検出を使用する場合、クライアントはブロードキャストクエリの代わりにユニキャストDHCP INFORMクエリを使用することをお勧めします。これは、安全でないネットワークでより簡単にスプーフィングされます。
Since DNS-SD is just a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC) [RFC4033] should be used where the authenticity of information is important. For DNS updates, secure updates [RFC2136] [RFC3007] should generally be used to control which clients have permission to update DNS records.
DNS-SDは、既存のDNSシステムでレコードに名前を付けて使用する方法の仕様にすぎないため、DNSクエリとDNS更新にすでに適用されているものに加えて、特定の追加のセキュリティ要件はありません。 DNSクエリの場合、情報の信頼性が重要な場合は、DNSセキュリティ拡張機能（DNSSEC）[RFC4033]を使用する必要があります。 DNS更新の場合、安全な更新[RFC2136] [RFC3007]を使用して、DNSレコードを更新する権限を持つクライアントを制御する必要があります。
For mDNS, in addition to what has been described above, a principal security threat is a security threat inherent to IP multicast routing and any application that runs on it. A rogue system can advertise that it is a TURN server. Discovery of such rogue systems as TURN servers, in itself, is not a security threat if there is a means for the TURN client to authenticate and authorize the discovered TURN servers.
mDNSの場合、上記で説明したものに加えて、主要なセキュリティの脅威は、IPマルチキャストルーティングおよびその上で実行されるすべてのアプリケーションに固有のセキュリティの脅威です。不正なシステムは、それがTURNサーバーであることを通知できます。 TURNサーバーなどの不正なシステムの発見自体は、発見されたTURNサーバーをTURNクライアントが認証および承認する手段があれば、セキュリティ上の脅威にはなりません。
In a network without any TURN server that is aware of the TURN anycast address, outgoing TURN requests could leak out onto the external Internet, possibly revealing information.
TURNエニーキャストアドレスを認識するTURNサーバーのないネットワークでは、発信TURN要求が外部インターネットに漏出し、情報が漏洩する可能性があります。
Using an IANA-assigned well-known TURN anycast address enables border gateways to block such outgoing packets. In the default-free zone, routers should be configured to drop such packets. Such configuration can occur naturally via BGP messages advertising that no route exists to said address.
IANAが割り当てた既知のTURNエニーキャストアドレスを使用すると、境界ゲートウェイがこのような発信パケットをブロックできます。デフォルトのフリーゾーンでは、このようなパケットをドロップするようにルーターを構成する必要があります。そのような構成は、そのアドレスへのルートが存在しないことを通知するBGPメッセージを介して自然に発生する可能性があります。
Sensitive clients that do not wish to leak information about their presence can set an IP TTL on their TURN requests that limits how far they can travel into the public Internet.
自分の存在に関する情報を漏らしたくない機密性の高いクライアントは、TURNリクエストにIP TTLを設定して、公衆インターネットに到達できる距離を制限できます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<http://www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、DOI 10.17487 / RFC2136、April 1997 、<http://www.rfc-editor.org/info/rfc2136>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <http://www.rfc-editor.org/info/rfc3007>.
[RFC3007] Wellington、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、DOI 10.17487 / RFC3007、2000年11月、<http://www.rfc-editor.org/info/rfc3007>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Securityの紹介と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<http： //www.rfc-editor.org/info/rfc4033>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[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, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, DOI 10.17487/RFC5928, August 2010, <http://www.rfc-editor.org/info/rfc5928>.
[RFC5928] Petit-Huguenin、M。、「NAT（TURN）解決メカニズムの周りのリレーを使用したトラバーサル」、RFC 5928、DOI 10.17487 / RFC5928、2010年8月、<http://www.rfc-editor.org/info/rfc5928 >。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, DOI 10.17487/RFC5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986] Thomson、M。およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、DOI 10.17487 / RFC5986、2010年9月、<http://www.rfc-editor.org/info/ rfc5986>。
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <http://www.rfc-editor.org/info/rfc6024>.
[RFC6024] Reddy、R。およびC. Wallace、「Trust Anchor Management Requirements」、RFC 6024、DOI 10.17487 / RFC6024、2010年10月、<http://www.rfc-editor.org/info/rfc6024>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<http://www.rfc-editor.org/info/rfc6762>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、< http://www.rfc-editor.org/info/rfc6890>。
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7250] Wouters、P.、Ed。、Tschofenig、H.、Ed。、Gilmore、J.、Weiler、S.、and T. Kivinen、 "Using Raw Public Keys in Transport Layer Security（TLS）and Datagram Transport Layerセキュリティ（DTLS）」、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<http://www.rfc-editor.org/info/rfc7250>。
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <http://www.rfc-editor.org/info/rfc7635>.
[RFC7635] Reddy、T.、Patil、P.、Ravindranath、R。、およびJ. Uberti、「サードパーティ認証のためのNAT（STUN）拡張用のセッショントラバーサルユーティリティ」、RFC 7635、DOI 10.17487 / RFC7635、2015年8月、<http://www.rfc-editor.org/info/rfc7635>。
[RETURN] Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC", Work in Progress, draft-ietf-rtcweb-return-02, March 2017.
[RETURN] Schwartz、B.、J。Uberti、「WebRTCの接続性とプライバシーのための再帰的にカプセル化されたTURN（RETURN）」、作業中、draft-ietf-rtcweb-return-02、2017年3月。
[RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC3188] Hakala、J。、「Using National Bibliography Numbers as Uniform Resource Names」、RFC 3188、DOI 10.17487 / RFC3188、2001年10月、<http://www.rfc-editor.org/info/rfc3188>。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC5128] Srisuresh、P.、Ford、B。、およびD. Kegel、「State of Peer-to-Peer（P2P）Communication through Network Address Translators（NATs）」、RFC 5128、DOI 10.17487 / RFC5128、2008年3月、 <http://www.rfc-editor.org/info/rfc5128>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7469] Evans、C.、Palmer、C。、およびR. Sleevi、「HTTPの公開キー固定拡張機能」、RFC 7469、DOI 10.17487 / RFC7469、2015年4月、<http://www.rfc-editor.org / info / rfc7469>。
[RFC8016] Reddy, T., Wing, D., Patil, P., and P. Martinsen, "Mobility with Traversal Using Relays around NAT (TURN)", RFC 8016, DOI 10.17487/RFC8016, November 2016, <http://www.rfc-editor.org/info/rfc8016>.
[RFC8016] Reddy、T.、Wing、D.、Patil、P。、およびP. Martinsen、「NAT（TURN）のリレーを使用したトラバーサルによるモビリティ」、RFC 8016、DOI 10.17487 / RFC8016、2016年11月、<http： //www.rfc-editor.org/info/rfc8016>。
[WebRTC-Overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", Work in Progress, draft-ietf-rtcweb-overview-18, March 2017.
[WebRTC-Overview] Alvestrand、H。、「Overview：Real Time Protocols for Browser-based Applications」、Work in Progress、draft-ietf-rtcweb-overview-18、2017年3月。
Acknowledgements
謝辞
The authors would like to thank Simon Perrault, Paul Kyzivat, Troy Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl, Brian Weis, Ralph Dromes, Ben Campbell, Suresh Krishnan, and Brandon Williams for their review and valuable comments. Thanks to Adam Roach for his detailed review and suggesting DNS Service Discovery as an additional discovery mechanism.
著者らは、レビューと貴重なコメントを提供してくれたSimon Perrault、Paul Kyzivat、Troy Shields、Eduardo Gueiros、Ted Hardie、Bernard Aboba、Karl Stahl、Brian Weis、Ralph Dromes、Ben Campbell、Suresh Krishnan、Brandon Williamsに感謝します。詳細なレビューを行い、追加の検出メカニズムとしてDNSサービス検出を提案してくれたAdam Roachに感謝します。
Authors' Addresses
著者のアドレス
Prashanth Patil Cisco Systems, Inc.
Prashanth Patil Cisco Systems、Inc.
Email: praspati@cisco.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems、Inc. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 India
Email: tireddy@cisco.com
Dan Wing United States America
ダンウィングアメリカ合衆国アメリカ
Email: dwing-ietf@fuggles.com