[要約] RFC 8016は、NATの周りでリレーを使用したトラバーサル可能なモビリティに関するものであり、NATトラバーサルをサポートするTURNプロトコルについての要約と目的を提供しています。
Internet Engineering Task Force (IETF) T. Reddy
Request for Comments: 8016 Cisco
Category: Standards Track D. Wing
ISSN: 2070-1721
P. Patil
P. Martinsen
Cisco
November 2016
Mobility with Traversal Using Relays around NAT (TURN)
NAT周りのリレーを使用したトラバーサルによるモビリティ（TURN）
Abstract
概要
It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.
モビリティイベント中にIPアドレスを変更することによって引き起こされるトラフィックの中断を最小限に抑えることが望ましいです。中断を最小限に抑えるメカニズムの1つは、短いネットワークパスをモビリティイベントに公開して、ローカルネットワーク要素のみが変更されたIPアドレスを認識し、リモートピアが変更されたIPアドレスを認識しないようにすることです。
This document provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes.
このドキュメントでは、NAT（TURN）のリレーを使用したトラバーサルを使用したIPアドレスモビリティソリューションを提供します。これは、クライアントのIPアドレスが変更されたときに、クライアントがTURNサーバー上の割り当てを保持できるようにすることで実現されます。
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/rfc8016.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8016で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Mobility Using TURN . . . . . . . . . . . . . . . . . . . . . 4
3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 5
3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 5
3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 6
3.1.3. Receiving an Allocate Success Response . . . . . . . 6
3.1.4. Receiving an Allocate Error Response . . . . . . . . 7
3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 7
3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 7
3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 7
3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 9
3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 9
3.4. New STUN Error Response Code . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example of Ticket Construction . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
When moving between networks, the endpoint's IP address can change or, due to NAT, the endpoint's public IP address can change. Such a change of IP address breaks upper-layer protocols such as TCP and RTP. Various techniques exist to prevent this breakage, all tied to making the endpoint's IP address static (e.g., Mobile IP, Proxy Mobile IP, Locator/ID Separation Protocol (LISP)). Other techniques exist, which make the change in IP address agnostic to the upper-layer protocol (e.g., Stream Control Transmission Protocol (SCTP)). The mechanism described in this document is in that last category.
ネットワーク間を移動する場合、エンドポイントのIPアドレスが変更される可能性があります。NATにより、エンドポイントのパブリックIPアドレスが変更される可能性があります。このようなIPアドレスの変更は、TCPやRTPなどの上位層プロトコルを破壊します。この破損を防ぐためのさまざまな手法が存在し、すべてエンドポイントのIPアドレスを静的にすることに関連しています（たとえば、モバイルIP、プロキシモバイルIP、ロケーター/ ID分離プロトコル（LISP））。上位層プロトコルにとらわれないIPアドレスの変更を行う他の手法が存在します（たとえば、ストリーム制御伝送プロトコル（SCTP））。このドキュメントで説明されているメカニズムは、最後のカテゴリにあります。
A server using Traversal Using Relays around NAT (TURN) [RFC5766] relays media packets and is used for a variety of purposes, including overcoming NAT and firewall traversal issues. The existing TURN specification does not permit a TURN client to reuse an allocation across client IP address changes. Due to this, when the IP address of the client changes, the TURN client has to request a new allocation, create permissions for the remote peer, create channels, etc. In addition, the client has to re-establish communication with its signaling server and send an updated offer to the remote peer conveying the newly relayed candidate address. Then, the remote side has to re-gather all candidates and signal them to the client, and the endpoints have to perform Interactive Connectivity Establishment (ICE) [RFC5245] checks. If the ICE continuous nomination procedure [NOMBIS] is used, then the newly relayed candidate address would have to be "trickled" (i.e., incrementally provisioned as described in [TRICKLE-SIP]), and ICE checks would have to be performed according to [TRICKLE-ICE] by the endpoints to nominate pairs for selection by ICE.
NATのリレーを使用したトラバーサル（TURN）[RFC5766]を使用するサーバーは、メディアパケットをリレーし、NATやファイアウォールトラバーサルの問題の克服など、さまざまな目的で使用されます。既存のTURN仕様では、TURNクライアントがクライアントIPアドレスの変更全体で割り当てを再利用することを許可していません。このため、クライアントのIPアドレスが変更されると、TURNクライアントは新しい割り当てを要求し、リモートピアのアクセス許可を作成し、チャネルを作成する必要があります。さらに、クライアントはシグナリングサーバーとの通信を再確立する必要があります新しく中継された候補アドレスを伝える更新されたオファーをリモートピアに送信します。次に、リモート側はすべての候補を再収集してクライアントに通知する必要があり、エンドポイントはInteractive Connectivity Establishment（ICE）[RFC5245]チェックを実行する必要があります。 ICE継続指名手順[NOMBIS]を使用する場合、新しくリレーされた候補アドレスを「だまし」（つまり、[TRICKLE-SIP]で説明されているように増分的にプロビジョニング）する必要があり、ICEのチェックは次のように実行する必要があります。 [TRICKLE-ICE]エンドポイントによって、ICEによる選択のためにペアを指定します。
This specification describes a mechanism to seamlessly reuse allocations across client IP address changes without any of the hassles described above. A critical benefit of this technique is that the remote peer does not have to support mobility or deal with any of the address changes. The client, which is subject to IP address changes, does all the work. The mobility technique works across and between network types (e.g., between 3G and wired Internet access), so long as the client can still access the TURN server. The technique should also work seamlessly when (D)TLS is used as a transport protocol for Session Traversal Utilities for NAT (STUN) [RFC5389]. When there is a change in IP address, the client uses (D)TLS Session Resumption without Server-Side State as described in [RFC5077] to resume secure communication with the TURN server, using the changed client IP address.
この仕様では、上記の手間をかけずに、クライアントIPアドレスの変更全体で割り当てをシームレスに再利用するメカニズムについて説明します。この手法の重要な利点は、リモートピアがモビリティをサポートしたり、アドレスの変更を処理したりする必要がないことです。 IPアドレスの変更の影響を受けるクライアントがすべての作業を行います。モビリティ技術は、クライアントがTURNサーバーに引き続きアクセスできる限り、ネットワークタイプ全体およびネットワークタイプ間（たとえば、3Gと有線インターネットアクセス間）で機能します。 （D）TLSがセッショントラバーサルユーティリティ（NAT用）（STUN）[RFC5389]のトランスポートプロトコルとして使用されている場合も、この手法はシームレスに機能するはずです。 [RFC5077]で説明されているように、IPアドレスが変更されると、クライアントは（D）TLSセッション再開をサーバー側状態なしで使用して、変更されたクライアントIPアドレスを使用してTURNサーバーとの安全な通信を再開します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses terminology defined in [RFC5245] and the following additional terminology:
このドキュメントでは、[RFC5245]で定義されている用語と、次の追加の用語を使用しています。
Break Before Make: The old communication path is broken ("break") before new communication can be created ("make"). Such changes typically occur because a network's physical cable is disconnected, radio transmission is turned off, or a client moves out of radio range.
Make before Make：新しい通信を作成（「make」）する前に、古い通信パスを切断（「break」）します。このような変化は通常、ネットワークの物理ケーブルが切断されているか、無線伝送がオフになっているか、クライアントが無線範囲外に移動したために発生します。
Make Before Break: A new communication path is created ("make") before the old communication path is broken ("break"). Such changes typically occur because a network is reconnected with a physical cable, radio transmission is turned on, or a client moves into radio range.
Make Before Break：古い通信パスが切断される（ "break"）前に、新しい通信パスが作成されます（ "make"）。このような変更は通常、ネットワークが物理ケーブルで再接続されたか、無線伝送がオンになったか、またはクライアントが無線範囲に移動したために発生します。
To achieve mobility, a TURN client should be able to retain an allocation on the TURN server across changes in the client IP address as a consequence of movement to other networks.
モビリティを実現するには、TURNクライアントは、他のネットワークへの移動の結果としてクライアントのIPアドレスが変更されても、TURNサーバーの割り当てを保持できる必要があります。
When the client sends the initial Allocate request to the TURN server, it will include a new STUN attribute MOBILITY-TICKET (with zero length value), which indicates that the client is capable of mobility and desires a ticket. The TURN server provisions a ticket that is sent inside the new STUN attribute MOBILITY-TICKET in the Allocate success response to the client. The ticket will be used by the client when it wants to refresh the allocation but with a new client IP address and port. This ensures that an allocation can only be refreshed by the same client that allocated the relayed transport address. When a client's IP address changes due to mobility, it presents the previously obtained ticket in a Refresh request to the TURN server. If the ticket is found to be valid, the TURN server will retain the same relayed address/port for the new IP address/port allowing the client to continue using previous channel bindings -- thus, the TURN client does not need to obtain new channel bindings. Any data from the external peer will be delivered by the TURN server to this new IP address/port of the client. The TURN client will continue to send application data to its peers using the previously allocated channelBind Requests.
クライアントが最初の割り当て要求をTURNサーバーに送信すると、新しいSTUN属性MOBILITY-TICKET（長さの値がゼロ）が含まれます。これは、クライアントがモビリティに対応しており、チケットを要求していることを示します。 TURNサーバーは、クライアントへのAllocate成功応答の新しいSTUN属性MOBILITY-TICKET内で送信されるチケットをプロビジョニングします。チケットは、クライアントが割り当てを更新するときに新しいクライアントIPアドレスとポートを使用するときに使用されます。これにより、リレーされたトランスポートアドレスを割り当てた同じクライアントのみが割り当てを更新できるようになります。モビリティのためにクライアントのIPアドレスが変更されると、以前に取得したチケットがリフレッシュリクエストでTURNサーバーに提示されます。チケットが有効であることが判明した場合、TURNサーバーは新しいIPアドレス/ポートに対して同じ中継アドレス/ポートを保持するため、クライアントは以前のチャネルバインディングを引き続き使用できます-したがって、TURNクライアントは新しいチャネルを取得する必要がありませんバインディング。外部ピアからのデータはすべて、TURNサーバーによってクライアントのこの新しいIPアドレス/ポートに配信されます。 TURNクライアントは、以前に割り当てられたchannelBindリクエストを使用して、引き続きピアにアプリケーションデータを送信します。
TURN TURN Peer
client server A
|-- Allocate request --------------->| |
| + MOBILITY-TICKET (length=0) | |
| | |
|<--------------- Allocate failure --| |
| (401 Unauthorized) | |
| | |
|-- Allocate request --------------->| |
| + MOBILITY-TICKET (length=0) | |
| | |
|<---------- Allocate success resp --| |
| + MOBILITY-TICKET | |
... ... ...
(changes IP address)
| | |
|-- Refresh request ---------------->| |
| + MOBILITY-TICKET | |
| | |
|<----------- Refresh success resp --| |
| + MOBILITY-TICKET | |
| | |
Figure 1: Mobility Using TURN
図1：TURNを使用したモビリティ
In Figure 1, the client sends an Allocate request with a MOBILITY-TICKET attribute to the server without credentials. Since the server requires that all requests be authenticated using STUN's long-term credential mechanism, the server rejects the request with a 401 (Unauthorized) error code. The client then tries again, this time including credentials (not shown). This time, the server accepts the Allocate request and returns an Allocate success response and a ticket inside the MOBILITY-TICKET attribute. Sometime later, the client IP address changes, and the client decides to refresh the allocation, and thus sends a Refresh request to the server with a MOBILITY-TICKET attribute containing the ticket it received from the server. The refresh is accepted, and the server replies with a Refresh success response and a new ticket inside the MOBILITY-TICKET attribute.
図1では、クライアントは、MOBILITY-TICKET属性を含む割り当て要求を、資格情報なしでサーバーに送信します。サーバーはすべての要求がSTUNの長期資格情報メカニズムを使用して認証されることを要求するので、サーバーは401（無許可）エラーコードで要求を拒否します。次にクライアントは再試行しますが、今回は資格情報（図には示されていません）が含まれます。今回は、サーバーがAllocateリクエストを受け入れ、MOBILITY-TICKET属性内のAllocate成功レスポンスとチケットを返します。しばらくすると、クライアントのIPアドレスが変更され、クライアントは割り当てを更新することを決定し、サーバーから受信したチケットを含むMOBILITY-TICKET属性を指定してサーバーに更新要求を送信します。更新が受け入れられ、サーバーは更新成功応答とMOBILITY-TICKET属性内の新しいチケットで応答します。
In addition to the process described in Section 6.1 of [RFC5766], the client includes the MOBILITY-TICKET attribute with a length of zero. This indicates that the client is a mobile node and wants a ticket.
[RFC5766]のセクション6.1で説明されているプロセスに加えて、クライアントには長さがゼロのMOBILITY-TICKET属性が含まれています。これは、クライアントがモバイルノードであり、チケットを必要としていることを示します。
In addition to the process described in Section 6.2 of [RFC5766], the server does the following:
[RFC5766]のセクション6.2で説明されているプロセスに加えて、サーバーは次のことを行います。
If the MOBILITY-TICKET attribute is included, and has a length of zero, but TURN session mobility is forbidden by local policy, the server will reject the request with the new error code 405 (Mobility Forbidden). If the MOBILITY-TICKET attribute is included and has a non-zero length, then the server will generate an error response with an error code of 400 (Bad Request). Following the rules specified in [RFC5389], if the server does not understand the MOBILITY-TICKET attribute, it ignores the attribute.
MOBILITY-TICKET属性が含まれていて、長さがゼロであるが、ターンセッションモビリティがローカルポリシーによって禁止されている場合、サーバーは新しいエラーコード405（モビリティ禁止）で要求を拒否します。 MOBILITY-TICKET属性が含まれていて、長さがゼロでない場合、サーバーはエラーコード400（Bad Request）のエラー応答を生成します。 [RFC5389]で指定されたルールに従って、サーバーがMOBILITY-TICKET属性を理解しない場合、その属性は無視されます。
If the server can successfully process the request and create an allocation, the server replies with a success response that includes a STUN MOBILITY-TICKET attribute. The TURN server can store system-internal data in the ticket that is encrypted by a key known only to the TURN server and sends the ticket in the STUN MOBILITY-TICKET attribute as part of the Allocate success response. An example of ticket construction is discussed in Appendix A. The ticket is opaque to the client, so the structure is not subject to interoperability concerns, and implementations may diverge from this format. The client could be roaming across networks with a different path MTU and from one address family to another (e.g., IPv6 to IPv4). The TURN server to support mobility must assume that the path MTU is unknown and use a ticket length in accordance with the published guidance on STUN UDP fragmentation (Section 7.1 of [RFC5389]).
サーバーが要求を正常に処理して割り当てを作成できる場合、サーバーはSTUN MOBILITY-TICKET属性を含む成功応答で応答します。 TURNサーバーは、システム内部データをチケットに保存できます。このチケットは、TURNサーバーだけが知っているキーによって暗号化され、Allocate成功応答の一部としてSTUN MOBILITY-TICKET属性でチケットを送信します。チケットの構成の例については、付録Aで説明します。チケットはクライアントに対して不透明であるため、構造は相互運用性の問題の影響を受けず、実装はこの形式と異なる場合があります。クライアントは、パスMTUが異なり、アドレスファミリ間で（たとえば、IPv6からIPv4へ）ネットワーク間をローミングしている可能性があります。モビリティをサポートするTURNサーバーは、パスMTUが不明であると想定し、STUN UDPフラグメンテーションに関する公開ガイダンス（[RFC5389]のセクション7.1）に従ってチケット長を使用する必要があります。
Note: There is no guarantee that the fields in the ticket are going to be decodable to a client, and therefore attempts by a client to examine the ticket are unlikely to be useful.
注：チケットのフィールドがクライアントでデコード可能であるという保証はないため、クライアントがチケットを調べようとしても役に立たない可能性があります。
In addition to the process described in Section 6.3 of [RFC5766], the client will store the MOBILITY-TICKET attribute, if present, from the response. This attribute will be presented by the client to the server during a subsequent Refresh request to aid mobility.
[RFC5766]のセクション6.3で説明されているプロセスに加えて、クライアントはMOBILITY-TICKET属性が存在する場合、応答からそれを保存します。この属性は、モビリティを支援するために、後続のリフレッシュ要求中にクライアントによってサーバーに提示されます。
If the client receives an Allocate error response with error code 405 (Mobility Forbidden), the error is processed as follows:
クライアントがエラーコード405（移動禁止）の割り当てエラー応答を受信した場合、エラーは次のように処理されます。
405 (Mobility Forbidden): The request is valid, but the server is refusing to perform it, likely due to administrative restrictions. The client considers the current transaction as having failed.
405（Mobility Forbidden）：要求は有効ですが、管理上の制限が原因で、サーバーが要求を拒否しています。クライアントは、現在のトランザクションが失敗したと見なします。
The client can notify the user or operator. The client SHOULD NOT retry sending the Allocate request containing the MOBILITY-TICKET with this server until it believes the problem has been fixed.
クライアントはユーザーまたはオペレーターに通知できます。クライアントは、問題が修正されたと確信するまで、このサーバーでMOBILITY-TICKETを含むAllocateリクエストの送信を再試行すべきではありません。
All other error responses must be handled as described in [RFC5766].
他のすべてのエラー応答は、[RFC5766]で説明されているように処理する必要があります。
If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it sends a Refresh request as described in Section 7.1 of [RFC5766]. If the client's IP address or source port has changed and the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET attribute received in the Allocate success response in the Refresh request. If there has been no IP address or source port number change, the client MUST NOT include a MOBILITY-TICKET attribute, as this would be rejected by the server and the client would need to retransmit the Refresh request without the MOBILITY-TICKET attribute.
クライアントが既存の割り当てを更新して有効期限までの時間を更新するか、既存の割り当てを削除する場合は、[RFC5766]のセクション7.1で説明されているように、更新リクエストを送信します。クライアントのIPアドレスまたは送信元ポートが変更され、クライアントが既存の割り当てを保持したい場合、クライアントはリフレッシュ要求のAllocate成功応答で受信したMOBILITY-TICKET属性を含めます。 IPアドレスまたは送信元ポート番号が変更されていない場合、クライアントはMOBILITY-TICKET属性を含めてはなりません。これはサーバーによって拒否され、クライアントはMOBILITY-TICKET属性なしで更新要求を再送信する必要があるためです。
In addition to the process described in Section 7.2 of [RFC5766], the server does the following:
[RFC5766]のセクション7.2で説明されているプロセスに加えて、サーバーは次のことを行います。
If the STUN MOBILITY-TICKET attribute is included in the Refresh request, and the server configuration changed to forbid mobility or the server transparently fails over to another server instance that forbids mobility, then the server rejects the Refresh request with a 405 (Mobility Forbidden) error and the client starts afresh with a new allocation.
STUN MOBILITY-TICKET属性が更新要求に含まれ、サーバー構成がモビリティを禁止するように変更された場合、またはサーバーがモビリティを禁止する別のサーバーインスタンスに透過的にフェイルオーバーした場合、サーバーは405（モビリティ禁止）で更新要求を拒否します。エラーが発生し、クライアントは新しい割り当てで新たに開始します。
If the STUN MOBILITY-TICKET attribute is included in the Refresh request, then the server will not retrieve the 5-tuple from the packet to identify an associated allocation. Instead, the TURN server will decrypt the received ticket, verify the ticket's validity, and retrieve the 5-tuple allocation using the ticket. If this 5-tuple obtained does not identify an existing allocation, then the server MUST reject the request with a 437 (Allocation Mismatch) error. If the ticket is invalid, then the server MUST reject the request with a 400 (Bad Request) error.
STUN MOBILITY-TICKET属性がリフレッシュ要求に含まれている場合、サーバーはパケットから5タプルを取得して関連する割り当てを識別しません。代わりに、TURNサーバーは受信したチケットを復号化し、チケットの有効性を確認し、チケットを使用して5タプル割り当てを取得します。取得したこの5タプルが既存の割り当てを識別しない場合、サーバーは437（割り当て不一致）エラーで要求を拒否する必要があります。チケットが無効な場合、サーバーは400（Bad Request）エラーでリクエストを拒否する必要があります。
If the source IP address and port of the Refresh request with the STUN MOBILITY-TICKET attribute is the same as the stored 5-tuple allocation, then the TURN server rejects the request with a 400 (Bad Request) error. If the source IP address and port of the Refresh request is different from the stored 5-tuple allocation, the TURN server proceeds with a MESSAGE-INTEGRITY validation to identify that it is the same user that had previously created the TURN allocation. If the above check is not successful, then the server MUST reject the request with a 441 (Wrong Credentials) error.
STUN MOBILITY-TICKET属性を指定した更新リクエストのソースIPアドレスとポートが、保存されている5タプル割り当てと同じである場合、TURNサーバーはリクエストを400（不正なリクエスト）エラーで拒否します。更新要求のソースIPアドレスとポートが、保存されている5タプル割り当てと異なる場合、TURNサーバーはMESSAGE-INTEGRITY検証を続行して、それが以前にTURN割り当てを作成したユーザーと同じであることを識別します。上記のチェックが成功しない場合、サーバーは441（間違った資格情報）エラーでリクエストを拒否する必要があります。
If all of the above checks pass, the TURN server understands that the client either has moved to a new network and acquired a new IP address (Break Before Make) or is in the process of switching to a new interface (Make Before Break). The source IP address of the request could be either the host transport address or the server-reflexive transport address. The server then updates its state data with the new client IP address and port but does not discard the old 5-tuple from its state data. The TURN server calculates the ticket with the new 5-tuple and sends the new ticket in the STUN MOBILITY-TICKET attribute as part of Refresh success response. The new ticket sent in the refresh response MUST be different from the old ticket.
上記のすべてのチェックに合格した場合、TURNサーバーは、クライアントが新しいネットワークに移動して新しいIPアドレスを取得したか（Break Before Make）、または新しいインターフェイスに切り替えている（Make Before Break）ことを理解しています。要求のソースIPアドレスは、ホストトランスポートアドレスまたはサーバー再帰トランスポートアドレスのいずれかです。その後、サーバーはその状態データを新しいクライアントIPアドレスとポートで更新しますが、状態データから古い5タプルを破棄しません。 TURNサーバーは新しい5タプルでチケットを計算し、リフレッシュ成功応答の一部としてSTUN MOBILITY-TICKET属性で新しいチケットを送信します。更新応答で送信される新しいチケットは、古いチケットとは異なる必要があります。
The TURN server MUST continue receiving and processing data on the old 5-tuple and MUST continue transmitting data on the old-5 tuple until it receives a Send Indication or ChannelData message from the client on the new 5-tuple or a message from the client to close the old connection (e.g., a TLS fatal alert or TCP RST). After receiving any of those messages, a TURN server discards the old ticket and the old 5-tuple associated with the old ticket from its state data. Data sent by the client to the peer is accepted on the new 5-tuple and data received from the peer is forwarded to the new 5-tuple. If the refresh request containing the MOBILITY-TICKET attribute does not succeed (e.g., the packet is lost if the request is sent over UDP, or the server is unable to fulfill the request), then the client can continue to exchange data on the old 5-tuple until it receives the Refresh success response.
TURNサーバーは、古い5タプルでデータの受信と処理を継続する必要があり、新しい5タプルでクライアントから送信表示またはChannelDataメッセージを受信するか、クライアントからメッセージを受信するまで、古い5タプルでデータを送信し続ける必要があります。古い接続を閉じます（たとえば、TLSの致命的なアラートまたはTCP RST）。これらのメッセージのいずれかを受信した後、TURNサーバーは、古いチケットと、古いチケットに関連付けられた古い5タプルをその状態データから破棄します。クライアントからピアに送信されたデータは新しい5タプルで受け入れられ、ピアから受信したデータは新しい5タプルに転送されます。 MOBILITY-TICKET属性を含む更新要求が成功しない場合（たとえば、要求がUDP経由で送信されるとパケットが失われるか、サーバーが要求を実行できない場合）、クライアントは引き続き古いデータを交換できます。更新成功応答を受信するまで5タプル。
The old ticket can only be used for the purposes of retransmission. If the client wants to refresh its allocation with a new server-reflexive transport address, it MUST use the new ticket. If the TURN server has not received a Refresh request with the STUN MOBILITY-TICKET attribute but receives Send indications or ChannelData messages from a client, the TURN server MAY discard or queue those Send indications or ChannelData messages (at its discretion). Thus, it is RECOMMENDED that the client avoid transmitting a Send indication or ChannelData message until it has received an acknowledgement for the Refresh request with the STUN MOBILITY-TICKET attribute.
古いチケットは再送信の目的でのみ使用できます。クライアントが新しいサーバー再帰トランスポートアドレスで割り当てを更新する場合は、新しいチケットを使用する必要があります。 TURNサーバーがSTUN MOBILITY-TICKET属性を含む更新要求を受信していないが、クライアントから送信指示またはChannelDataメッセージを受信した場合、TURNサーバーは、それらの送信指示またはChannelDataメッセージを破棄またはキューに入れます（その裁量で）。したがって、クライアントがSTUN MOBILITY-TICKET属性を指定したリフレッシュ要求の確認応答を受信するまで、送信表示またはChannelDataメッセージの送信を回避することをお勧めします。
To accommodate the potential loss of Refresh responses, a server must retain the old STUN MOBILITY-TICKET attribute for a period of at least 30 seconds to be able to recognize a retransmission of the Refresh request with the old STUN MOBILITY-TICKET attribute from the client.
リフレッシュ応答の潜在的な損失に対応するには、サーバーが古いSTUN MOBILITY-TICKET属性を少なくとも30秒間保持して、クライアントからの古いSTUN MOBILITY-TICKET属性を持つリフレッシュ要求の再送信を認識できるようにする必要があります。 。
In addition to the process described in Section 7.3 of [RFC5766], the client will store the MOBILITY-TICKET attribute, if present, from the response. This attribute will be presented by the client to the server during a subsequent Refresh request to aid mobility.
[RFC5766]のセクション7.3で説明されているプロセスに加えて、クライアントはMOBILITY-TICKET属性が存在する場合、応答からそれを保存します。この属性は、モビリティを支援するために、後続のリフレッシュ要求中にクライアントによってサーバーに提示されます。
This attribute is used to retain an allocation on the TURN server. It is exchanged between the client and server to aid mobility. The value of the MOBILITY-TICKET is encrypted and is of variable length.
この属性は、TURNサーバーでの割り当てを保持するために使用されます。モビリティを支援するために、クライアントとサーバー間で交換されます。 MOBILITY-TICKETの値は暗号化され、可変長です。
This document defines the following new error response code:
このドキュメントでは、次の新しいエラー応答コードを定義しています。
405 (Mobility Forbidden): Mobility request was valid but cannot be performed due to administrative or similar restrictions.
405（Mobility Forbidden）：モビリティリクエストは有効でしたが、管理上の制限または同様の制限により実行できません。
IANA has added the following attribute to the "STUN Attributes" registry [IANA-STUN]:
IANAは、「STUN属性」レジストリに次の属性を追加しました[IANA-STUN]：
o MOBILITY-TICKET (0x8030, in the comprehension-optional range)
o MOBILITY-TICKET（0x8030、内包オプション範囲）
Also, IANA has added a new STUN error code "Mobility Forbidden" with the value 405 to the "STUN Error Codes" registry [IANA-STUN].
また、IANAは、値が405の新しいSTUNエラーコード「Mobility Forbidden」を「STUNエラーコード」レジストリ[IANA-STUN]に追加しました。
The TURN server MUST always ensure that the ticket is authenticated and encrypted using strong cryptographic algorithms to prevent modification or eavesdropping by an attacker. The ticket MUST be constructed such that it has strong entropy to ensure that nothing can be gleaned by looking at the ticket alone.
TURNサーバーは、強力な暗号化アルゴリズムを使用してチケットが認証および暗号化されていることを常に確認して、攻撃者による変更または盗聴を防止する必要があります。チケットは、チケットだけを見ても何も収集できないことを確実にするために、強いエントロピーを持つように構築する必要があります。
An attacker monitoring the traffic between the TURN client and server can impersonate the client and refresh the allocation using the ticket issued to the client with the attacker's IP address and port. The TURN client and server MUST use the STUN long-term credential mechanism [RFC5389], the STUN Extension for Third-Party Authorization [RFC7635], or a (D)TLS connection to prevent malicious users from impersonating the client. With any of those three mechanisms, when the server receives the Refresh request with the STUN MOBILITY-TICKET attribute from the client, it identifies that it is indeed the same client but with a new IP address and port using the ticket it had previously issued to refresh the allocation. If (D)TLS is not used or the (D)TLS handshake fails, and authentication also fails, then the TURN client and server MUST fail and not proceed with TURN mobility.
TURNクライアントとサーバー間のトラフィックを監視する攻撃者は、クライアントになりすまし、攻撃者のIPアドレスとポートを使用してクライアントに発行されたチケットを使用して割り当てを更新できます。 TURNクライアントとサーバーは、悪意のあるユーザーがクライアントになりすますことを防ぐために、STUN長期資格情報メカニズム[RFC5389]、サードパーティ認証用のSTUN拡張[RFC7635]、または（D）TLS接続を使用する必要があります。これら3つのメカニズムのいずれかを使用して、サーバーがクライアントからSTUN MOBILITY-TICKET属性を含む更新要求を受信すると、実際には同じクライアントであるが、以前に発行したチケットを使用する新しいIPアドレスとポートを備えていることを識別します割り当てを更新します。 （D）TLSが使用されていないか、（D）TLSハンドシェイクが失敗し、認証も失敗した場合、TURNクライアントとサーバーは失敗し、TURNモビリティを続行しないでください。
Security considerations described in [RFC5766] are also applicable to this mechanism.
[RFC5766]で説明されているセキュリティの考慮事項は、このメカニズムにも適用できます。
[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>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without server-Side State」、RFC 5077、DOI 10.17487 / RFC5077、January 2008、 <http://www.rfc-editor.org/info/rfc5077>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[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>。
[IANA-STUN] IANA, "Session Traversal Utilities for NAT (STUN) Parameters", <http://www.iana.org/assignments/stun-parameters>.
[IANA-STUN] IANA、「NAT（STUN）パラメータのセッショントラバーサルユーティリティ」、<http://www.iana.org/assignments/stun-parameters>。
[NOMBIS] Uberti, J. and J. Lennox, "Improvements to ICE Candidate Nomination", Work in Progress, draft-uberti-mmusic-nombis-00, March 2015.
[NOMBIS] Uberti、J.およびJ. Lennox、「Improvements to ICE Candidate Nomination」、Work in Progress、draft-uberti-mmusic-nombis-00、2015年3月。
[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>。
[TRICKLE-ICE] Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Work in Progress, draft-ietf-ice-trickle-04, September 2016.
[TRICKLE-ICE] Ivov、E.、Rescorla、E.、Uberti、J。、およびP. Saint-Andre、「Trickle ICE：Incremental Provisioning of Candidates for the Interactive Connectivity Establishment（ICE）Protocol」、Work in Progress、 draft-ietf-ice-trickle-04、2016年9月。
[TRICKLE-SIP] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A Session Initiation Protocol (SIP) usage for Trickle ICE", Work in Progress, draft-ietf-mmusic-trickle-ice-sip-06, October 2016.
[TRICKLE-SIP] Ivov、E.、Stach、T.、Marocco、E。、およびC. Holmberg、「トリクルICEのセッション開始プロトコル（SIP）の使用法」、作業中、draft-ietf-mmusic-trickle -ice-sip-06、2016年10月。
The TURN server uses two different keys: one 128-bit key for Advance Encryption Standard (AES) in Cipher Block Chaining (CBC) mode (AES_128_CBC) and a 256-bit key for HMAC-SHA-256-128 for integrity protection. The ticket can be structured as follows:
TURNサーバーは2つの異なるキーを使用します。暗号ブロックチェーン（CBC）モードのAdvance Encryption Standard（AES）モード（AES_128_CBC）用の128ビットキーと、整合性保護のためのHMAC-SHA-256-128用の256ビットキーです。チケットは次のように構成できます。
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[16];
} ticket;
Figure 2: Ticket Format
図2：チケットの形式
Here, key_name serves to identify a particular set of keys used to protect the ticket. It enables the TURN server to easily recognize tickets it has issued. The key_name should be randomly generated to avoid collisions between servers. One possibility is to generate new random keys and key_name every time the server is started.
ここで、key_nameは、チケットの保護に使用される特定のキーのセットを識別するのに役立ちます。これにより、TURNサーバーは発行したチケットを簡単に認識できます。サーバー間の衝突を避けるために、key_nameはランダムに生成する必要があります。 1つの可能性は、サーバーが起動するたびに新しいランダムキーとkey_nameを生成することです。
The TURN state information (which is either self-contained or a handle) in encrypted_state is encrypted using 128-bit AES in CBC mode with the given Initialization Vector (IV). The Message Authentication Code (MAC) is calculated using HMAC-SHA-256-128 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable length).
encrypted_stateのTURN状態情報（自己完結型またはハンドル）は、指定された初期化ベクトル（IV）でCBCモードの128ビットAESを使用して暗号化されます。メッセージ認証コード（MAC）は、key_name（16オクテット）およびIV（16オクテット）でHMAC-SHA-256-128を使用して計算され、続いて、encrypted_stateフィールドの長さ（2オクテット）とその内容（可変長）が続きます。
Acknowledgements
謝辞
Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, Emil Ivov, Oleg Moskalenko, Dave Waltermire, Pete Resnick, Antoni Przygienda, Alissa Cooper, Ben Campbell, Suresh Krishnan, Mirja Kuehlewind, Jonathan Lennox, and Brandon Williams for review and comments.
Alfred Heggestad、Lishitao、Suzing Zhou、Martin Thomson、Emil Ivov、Oleg Moskalenko、Dave Waltermire、Pete Resnick、Antoni Przygienda、Alissa Cooper、Ben Campbell、Suresh Krishnan、Mirja Kuehlewind、Jonathan Lennox、そしてBrandon Williamsのコメントに感謝します。 。
Authors' Addresses
著者のアドレス
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
ダンウイング|
Email: dwing-ietf@fuggles.com
Prashanth Patil Cisco Systems, Inc. Bangalore India
Prashanth Patil Cisco Systems、Inc.バンガロールインド
Email: praspati@cisco.com
Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens vei 22 Lysaker, Akershus 1325 Norway
Paal-Erik Martinsen Cisco Systems、Inc. Philip Pedersens vei 22 Lysaker、Akershus 1325 Norway
Email: palmarti@cisco.com