[要約] RFC 7675は、WebRTC接続確立後の通信継続における「同意の新鮮さ（Consent Freshness）」を確認するためのSTUNベースのメカニズムを規定しています。ピアが引き続きパケットの受信を許可していることを定期的に検証し、意図しない宛先へのパケット送信を防止します。セキュリティ攻撃やユーザーのプライバシー保護、およびリソースの無駄な消費を抑えるための重要な制御手段となります。
Internet Engineering Task Force (IETF) M. Perumal
Request for Comments: 7675 Ericsson
Category: Standards Track D. Wing
ISSN: 2070-1721 Cisco Systems, Inc.
R. Ravindranath
T. Reddy
Cisco Systems
M. Thomson
Mozilla
October 2015
Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness
同意の鮮度（Consent Freshness）のためのNAT用セッショントラバーサルユーティリティ（STUN）の使用
Abstract
概要
To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.
ブラウザーなどのWebRTCアプリケーションが不本意な被害者にトラフィックを送信して攻撃を仕掛けないようにするには、リモートエンドポイントから定期的に送信の同意を得る必要があります。
This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.
このドキュメントでは、NAT（STUN）を使用するための新しいセッショントラバーサルユーティリティを使用した同意メカニズムについて説明します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7675.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7675で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Expiration of Consent . . . . . . . . . . . . . . . . . . 5 5.2. Immediate Revocation of Consent . . . . . . . . . . . . . 6 6. DiffServ Treatment for Consent . . . . . . . . . . . . . . . 7 7. DTLS Applicability . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic. Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. This is performed both when the session is first established to the remote peer using Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks, and periodically for the duration of the session using the procedures defined in this document.
ピアへの攻撃を防ぐために、エンドポイントはリモートピアがトラフィックを受信する用意があることを確認する必要があります。 WebRTCなどの展開では、悪意のあるJavaScriptがブラウザを攻撃のプラットフォームとして使用できないようにするために、トラフィックを送信する前にピアの同意を確認する必要があります。これは、インタラクティブ接続確立（ICE）[RFC5245]接続チェックを使用してセッションがリモートピアに最初に確立されるときと、このドキュメントで定義されている手順を使用してセッションの期間中定期的に実行されます。
When a session is first established, ICE implementations obtain an initial consent to send by performing STUN connectivity checks. This document describes a new STUN usage with exchange of request and response messages that verifies the remote peer's ongoing consent to receive traffic. This consent expires after a period of time and needs to be continually renewed, which ensures that consent can be terminated.
セッションが最初に確立されると、ICE実装はSTUN接続性チェックを実行することにより、送信するための初期同意を取得します。このドキュメントでは、トラフィックを受信するためのリモートピアの継続的な同意を確認する要求および応答メッセージの交換を伴う新しいSTUNの使用法について説明します。この同意は一定期間が経過すると期限が切れ、継続的に更新する必要があるため、同意を確実に終了できます。
This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. The consent mechanism does not update the ICE procedures defined in [RFC5245].
このドキュメントは、送信するために取得、維持、および同意を失うために必要なものを定義します。送信の同意は、単一の5タプルに適用されます。同意の変更に対するアプリケーションの反応については、このドキュメントでは説明していません。同意メカニズムは、[RFC5245]で定義されているICE手順を更新しません。
Consent is obtained only by full ICE implementations. An ICE-lite agent (as defined in Section 2.7 of [RFC5245]) does not generate connectivity checks or run the ICE state machine. Hence, an ICE-lite agent does not generate consent checks and will only respond to any checks that it receives. No changes are required to ICE-lite implementations in order to respond to consent checks, as they are processed as normal ICE connectivity checks.
同意は、完全なICE実装によってのみ取得されます。 ICE-liteエージェント（[RFC5245]のセクション2.7で定義）は、接続チェックを生成せず、ICEステートマシンを実行しません。したがって、ICE-liteエージェントは同意チェックを生成せず、受け取ったチェックにのみ応答します。 ICE-liteの実装は、通常のICE接続性チェックとして処理されるため、同意チェックに応答するために変更する必要はありません。
This document defines what it takes to obtain, maintain, and lose consent to send using ICE. Sections 4.4 and 5.3 of [WebRTC-SA] further explain the value of obtaining and maintaining consent.
このドキュメントでは、ICEを使用して送信するために取得、維持、および同意を失うために必要なものを定義します。 [WebRTC-SA]のセクション4.4および5.3は、同意を得て維持することの価値をさらに説明しています。
Other applications that have similar security requirements to verify peer consent before sending non-ICE packets can use the consent mechanism described in this document. The mechanism of how applications are made aware of consent expiration is outside the scope of the document.
ICE以外のパケットを送信する前にピアの同意を確認するための同様のセキュリティ要件を持つ他のアプリケーションは、このドキュメントで説明されている同意メカニズムを使用できます。アプリケーションが同意の期限切れを認識する方法のメカニズムは、ドキュメントの範囲外です。
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] で説明されているように解釈されるものとします。
Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address. Consent is obtained using ICE. Note that this is an application-level consent; no human intervention is involved.
同意：リモートエンドポイントから許可を取得して、ICE以外のトラフィックをリモートトランスポートアドレスに送信するメカニズム。 ICEを使用して同意が得られます。これはアプリケーションレベルの同意であることに注意してください。人間の介入は必要ありません。
Consent Freshness: Maintaining and renewing consent over time.
同意の鮮度：時間の経過に伴う同意の維持と更新。
Transport Address: The remote peer's IP address and UDP or TCP port number.
トランスポートアドレス：リモートピアのIPアドレスとUDPまたはTCPポート番号。
Although ICE requires periodic keepalive traffic to keep NAT bindings alive (see Section 10 of [RFC5245] and also [RFC6263]), those keepalives are sent as STUN Indications that are send-and-forget, and do not evoke a response. A response is necessary for consent to continue sending traffic. Thus, we need a request/response mechanism for consent freshness. ICE can be used for that mechanism because ICE implementations are already required to continue listening for ICE messages, as described in Section 10 of [RFC5245]. STUN binding requests sent for consent freshness also serve the keepalive purpose (i.e., to keep NAT bindings alive). Because of that, dedicated keepalives (e.g., STUN Binding Indications) are not sent on candidate pairs where consent requests are sent, in accordance with Section 20.2.3 of [RFC5245].
ICEでは、NATバインディングを存続させるために定期的なキープアライブトラフィックが必要ですが（[RFC5245]のセクション10と[RFC6263]も参照）、これらのキープアライブは送信と削除のSTUN通知として送信され、応答を引き起こしません。トラフィックの送信を継続するには、同意のための応答が必要です。したがって、同意の鮮度を保つための要求/応答メカニズムが必要です。 [RFC5245]のセクション10で説明されているように、ICE実装はICEメッセージをリッスンし続ける必要があるため、ICEはそのメカニズムに使用できます。同意の鮮度のために送信されたSTUNバインディング要求は、キープアライブの目的にも役立ちます（つまり、NATバインディングを存続させるため）。そのため、[RFC5245]のセクション20.2.3に従って、同意リクエストが送信される候補ペアでは、専用のキープアライブ（STUNバインディング表示など）は送信されません。
When Secure Real-time Transport Protocol (SRTP) is used, the following considerations are applicable. SRTP is encrypted and authenticated with symmetric keys; that is, both sender and receiver know the keys. With two party sessions, receipt of an authenticated packet from the single remote party is a strong assurance the packet came from that party. However, when a session involves more than two parties, all of whom know each other's keys, any of those parties could have sent (or spoofed) the packet. Such shared key distributions are possible with some Multimedia Internet KEYing (MIKEY) [RFC3830] modes, Security Descriptions [RFC4568], and Encrypted Key Transport (EKT) [EKT]. Thus, in such shared keying distributions, receipt of an authenticated SRTP packet is not sufficient to verify consent.
Secure Real-time Transport Protocol (SRTP) を使用する場合、以下の考慮事項が適用されます。SRTP は対称鍵によって暗号化および認証されます。すなわち、送信者と受信者の双方が鍵を把握しています。二者間セッション（2当事者のセッション）の場合、単一の相手方（リモート当事者）から認証済みパケットを受信することは、そのパケットがその相手方から送信されたことの強力な保証となります。しかし、セッションに3者以上の当事者が関与しており、その全員が互いの鍵を知っている場合、それらの当事者の誰でもパケットを送信（または偽造）することが可能になります。このような共有鍵配信は、一部の Multimedia Internet KEYing (MIKEY) [RFC3830] モード、Security Descriptions [RFC4568]、および Encrypted Key Transport (EKT) [EKT] で起こり得ます。したがって、そのような共有鍵配信においては、認証済み SRTP パケットを受信したことだけでは同意（consent）を検証するのに十分ではありません。
The mechanism proposed in the document is an optional extension to the ICE protocol; it can be deployed at one end of the two-party communication session without impact on the other party.
このドキュメントで提案されているメカニズムは、ICEプロトコルのオプションの拡張です。相手に影響を与えることなく、2者間通信セッションの一端に配置できます。
Initial consent to send traffic is obtained using ICE [RFC5245]. An endpoint gains consent to send on a candidate pair when the pair enters the Succeeded ICE state. This document establishes a 30-second expiry time on consent. 30 seconds was chosen to balance the need to minimize the time taken to respond to a loss of consent with the desire to reduce the occurrence of spurious failures.
トラフィックを送信する最初の同意は、ICE [RFC5245]を使用して取得されます。エンドポイントは、ペアがSucceeded ICE状態になると、ペアの候補を送信することに同意します。このドキュメントでは、同意に基づいて30秒の有効期限を設定します。 30秒は、同意の喪失への対応にかかる時間を最小限に抑える必要性と、偽の障害の発生を減らしたいという要望とのバランスを取るために選択されました。
ICE does not identify when consent to send traffic ends. This document describes two ways in which consent to send ends: expiration of consent and immediate revocation of consent, which are discussed in the following sections.
ICEは、トラフィック送信の同意がいつ終了するかを識別しません。このドキュメントでは、送信の同意が終了する2つの方法について説明します。それは、次のセクションで説明する同意の期限切れと即時の失効です。
A full ICE implementation obtains consent to send using ICE. After ICE concludes on a particular candidate pair and whenever the endpoint sends application data on that pair consent is maintained following the procedure described in this document.
完全なICE実装は、ICEを使用して送信することに同意を得ます。 ICEが特定の候補ペアについて結論を出した後、エンドポイントがそのペアに関するアプリケーションデータを送信するたびに、このドキュメントで説明されている手順に従って同意が維持されます。
An endpoint MUST NOT send data other than the messages used to establish consent unless the receiving endpoint has consented to receive data. Connectivity checks that are paced as described in Section 16 of [RFC5245], and responses to connectivity checks are permitted. That is, no application data (e.g., RTP or Datagram Transport Layer Security (DTLS)), can be sent until consent is obtained.
エンドポイントは、受信側のエンドポイントがデータの受信に同意していない限り、同意の確立に使用されたメッセージ以外のデータを送信してはなりません（MUST NOT）。 [RFC5245]のセクション16で説明されているようにペースが調整された接続チェックと、接続チェックへの応答が許可されます。つまり、同意が得られるまで、アプリケーションデータ（RTPやデータグラムトランスポート層セキュリティ（DTLS）など）は送信できません。
Explicit consent to send is obtained and maintained by sending a STUN binding request to the remote peer's transport address and receiving a matching, authenticated, non-error STUN binding response from the remote peer's transport address. These STUN binding requests and responses are authenticated using the same short-term credentials as the initial ICE exchange.
送信の明示的な同意は、リモートピアのトランスポートアドレスにSTUNバインディング要求を送信し、リモートピアのトランスポートアドレスから一致する認証済みのエラーのないSTUNバインディング応答を受信することによって取得および維持されます。これらのSTUNバインディング要求と応答は、最初のICE交換と同じ短期資格情報を使用して認証されます。
Note: Although TCP has its own consent mechanism (TCP acknowledgements), consent is necessary over a TCP connection because it could be translated to a UDP connection (e.g., [RFC6062]).
注：TCPには独自の同意メカニズム（TCP確認応答）がありますが、UDP接続（[RFC6062]など）に変換できるため、TCP接続を介した同意が必要です。
Consent expires after 30 seconds. That is, if a valid STUN binding response has not been received from the remote peer's transport address in 30 seconds, the endpoint MUST cease transmission on that 5-tuple. STUN consent responses received after consent expiry do not re-establish consent and may be discarded or cause an ICMP error.
同意は30秒後に期限切れになります。つまり、有効なSTUNバインディング応答が30秒以内にリモートピアのトランスポートアドレスから受信されなかった場合、エンドポイントはその5タプルでの送信を停止しなければなりません (MUST)。同意の有効期限が切れた後に受け取ったSTUN同意応答は同意を再確立せず、破棄されるか、ICMPエラーを引き起こす可能性があります。
To prevent expiry of consent, a STUN binding request can be sent periodically. To prevent synchronization of consent checks, each interval MUST be randomized from between 0.8 and 1.2 times the basic period. Implementations SHOULD set a default interval of 5 seconds, resulting in a period between checks of 4 to 6 seconds. Implementations MUST NOT set the period between checks to less than 4 seconds. This timer is independent of the consent expiry timeout.
同意の期限切れを防ぐために、STUNバインディング要求を定期的に送信できます。同意チェックの同期を防ぐには、各間隔を基本期間の0.8倍から1.2倍の間でランダム化しなければなりません (MUST)。実装では、デフォルトの間隔を5秒に設定すべきである (SHOULD)ため、チェックの間隔は4〜6秒になります。実装は、チェック間の期間を4秒未満に設定してはなりません（MUST NOT）。このタイマーは、同意期限切れタイムアウトとは無関係です。
Each STUN binding request for consent MUST use a new STUN transaction identifier, as described in Section 6 of [RFC5389]. Each STUN binding request for consent is transmitted once only. A sender therefore cannot assume that it will receive a response for every consent request, and a response might be for a previous request (rather than for the most recently sent request).
[RFC5389]のセクション6で説明されているように、同意のための各STUNバインディングリクエストでは、新しいSTUNトランザクション識別子を使用しなければなりません (MUST)。同意のための各STUNバインディング要求は、一度だけ送信されます。したがって、送信者は、すべての同意要求に対する応答を受信するとは想定できず、応答は（最後に送信された要求ではなく）前の要求に対するものである可能性があります。
An endpoint SHOULD await a binding response for each request it sends for a time based on the estimated round-trip time (RTT) (see Section 7.2.1 of [RFC5389]) with an allowance for variation in network delay. The RTT value can be updated as described in [RFC5389]. All outstanding STUN consent transactions for a candidate pair MUST be discarded when consent expires.
To meet the security needs of consent, an untrusted application (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or control the STUN transaction identifier, because that enables spoofing of STUN responses, falsifying consent.
同意のセキュリティニーズを満たすために、信頼されていないアプリケーション（JavaScriptやシグナリングサーバーなど）は、STUNトランザクションIDを取得または制御できしてはなりません (MUST NOT)。これにより、STUN応答のなりすましが可能になり、同意が偽造されます。
To prevent attacks on the peer during ICE restart, an endpoint that continues to send traffic on the previously validated candidate pair during ICE restart MUST continue to perform consent freshness on that candidate pair as described earlier.
ICEの再起動中のピアへの攻撃を防ぐために、ICEの再起動中に以前に検証された候補ペアにトラフィックを送信し続けるエンドポイントは、前述のようにその候補ペアで同意フレッシュネスを実行し続けなければなりません (MUST)。
While TCP affords some protection from off-path attackers ([RFC5961], [RFC4953]), there is still a risk an attacker could cause a TCP sender to send forever by spoofing ACKs. To prevent such an attack, consent checks MUST be performed over all transport connections, including TCP. In this way, an off-path attacker spoofing TCP segments cannot cause a TCP sender to send once the consent timer expires (30 seconds).
An endpoint does not need to maintain consent if it does not send application data. However, an endpoint MUST regain consent before it resumes sending application data. In the absence of any packets, any bindings in middleboxes for the flow might expire. Furthermore, having one peer unable to send is detrimental to many protocols. Absent better information about the network, if an endpoint needs to ensure its NAT or firewall mappings do not expire, this can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263]).
エンドポイントは、アプリケーションデータを送信しない場合は同意を維持する必要はありません。ただし、エンドポイントは、アプリケーションデータの送信を再開する前に同意を取り戻さなければなりません (MUST)。パケットがまったく流れない場合、そのフローに対するミドルボックス内のバインディングが期限切れになる可能性があります。さらに、一方のピアが送信できない状態は多くのプロトコルにとって有害です。ネットワークに関するより良い情報がない状況で、エンドポイントがNATやファイアウォールのマッピングが期限切れにならないようにする必要がある場合は、キープアライブなどの手法を用いて行うことができます（[RFC5245]のセクション10および[RFC6263]を参照してください）。
After consent is lost, the same ICE credentials MUST NOT be used on the affected 5-tuple again. That means that a new session, or an ICE restart, is needed to obtain consent to send on the affected candidate pair.
同意が失われた後、影響を受けた5タプルで同じICE資格情報を再度使用してはなりません (MUST NOT)。これは、影響を受ける候補ペアを送信するための同意を得るために、新しいセッションまたはICEの再起動が必要であることを意味します。
In some cases, it is useful to signal that consent is terminated rather than relying on a timeout.
場合によっては、タイムアウトに依存するのではなく、同意が終了したことを通知することが役立ちます。
Consent for sending application data is immediately revoked by receipt of an authenticated message that closes the connection (e.g., a Transport Layer Security (TLS) fatal alert) or receipt of a valid and authenticated STUN response with error code Forbidden (403). Note however that consent revocation messages can be lost on the network, so an endpoint could resend these messages, or wait for consent to expire.
アプリケーションデータの送信に対する同意は、接続を閉じる認証済みメッセージ（トランスポート層セキュリティ（TLS）の致命的なアラートなど）の受信、またはエラーコードForbidden（403）の有効で認証済みのSTUN応答の受信によって即座に取り消されます。ただし、同意取り消しメッセージはネットワーク上で失われる可能性があるため、エンドポイントはこれらのメッセージを再送信するか、同意の期限が切れるのを待つ可能性があることに注意してください。
Receipt of an unauthenticated message that closes a connection (e.g., TCP FIN) does not indicate revocation of consent. Thus, an endpoint receiving an unauthenticated end-of-session message SHOULD continue sending media (over connectionless transport) or attempt to re-establish the connection (over connection-oriented transport) until consent expires or it receives an authenticated message revoking consent.
接続を閉じる認証されていないメッセージ（TCP FINなど）を受信しても、同意の取り消しは示されません。したがって、認証されていないセッション終了メッセージを受信するエンドポイントは、同意が期限切れになるか、同意を取り消す認証メッセージを受信するまで、（コネクションレストランスポートを介して）メディアの送信を続行するか、または（コネクション型トランスポートを介して）接続の再確立を試みるべきです (SHOULD)。
Note that an authenticated Secure Real-time Transport Control Protocol (SRTCP) BYE does not terminate consent; it only indicates the associated SRTP source has quit.
認証されたセキュアリアルタイムトランスポートコントロールプロトコル（SRTCP）BYEは同意を終了しないことに注意してください。関連するSRTPソースが終了したことを示すだけです。
It is RECOMMENDED that STUN consent checks use the same Diffserv Codepoint markings as the ICE connectivity checks described in Section 7.1.2.4 of [RFC5245] for a given 5-tuple.
STUN同意チェックでは、特定の5タプルの[RFC5245]のセクション7.1.2.4で説明されているICE接続チェックと同じDiffservコードポイントマーキングを使用することをお勧めします。
Note: It is possible that different Diffserv Codepoints are used by different media over the same transport address [WebRTC-QoS]. Such a case is outside the scope of this document.
注：同じトランスポートアドレス[WebRTC-QoS]を介して、異なるメディアによって異なるDiffservコードポイントが使用される可能性があります。このようなケースは、このドキュメントの範囲外です。
The DTLS applicability is identical to what is described in Section 4.2 of [RFC7350].
DTLSの適用範囲は、[RFC7350]のセクション4.2で説明されているものと同じです。
This document describes a security mechanism, details of which are mentioned in Sections 4.1 and 4.2 of [RFC7350]. Consent requires 96 bits transaction ID defined in Section 6 of [RFC5389] to be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong. This is good enough security against an off-path attacker replaying old STUN consent responses. Consent Verification to avoid attacks using a browser as an attack platform against machines is discussed in Sections 3.3 and 4.2 of [WebRTC-SEC].
The security considerations discussed in [RFC5245] should also be taken into account.
[RFC5245]で説明されているセキュリティの考慮事項も考慮する必要があります。
[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>。
[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., and D. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487/RFC5389、2008年10月、<http://www.rfc-editor.org/info/rfc5389>。
[EKT] Mattsson, J., McGrew, D., and D. Wing, "Encrypted Key Transport for Secure RTP", Work in Progress, draft-ietf-avtcore-srtp-ekt-03, October 2014.
[EKT] Mattsson, J., McGrew, D., and D. Wing、「Secure RTPの暗号化キートランスポート」、Work in Progress、draft-ietf-avtcore-srtp-ekt-03、2014年10月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <http://www.rfc-editor.org/info/rfc3830>.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY：Multimedia Internet KEYing"、RFC 3830、DOI 10.17487/RFC3830、August 2004、<http://www.rfc-editor.org/info/rfc3830>。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <http://www.rfc-editor.org/info/rfc4568>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing、「メディアストリームのセッション記述プロトコル（SDP）セキュリティ記述」、RFC 4568、DOI 10.17487/RFC4568、2006年7月、<http://www.rfc-editor.org/info/rfc4568>。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <http://www.rfc-editor.org/info/rfc4953>.
[RFC4953] Touch, J.、「なりすまし攻撃に対するTCPの防御」、RFC 4953、DOI 10.17487/RFC4953、2007年7月、<http://www.rfc-editor.org/info/rfc4953>。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <http://www.rfc-editor.org/info/rfc5961>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal、「ブラインドインウィンドウ攻撃に対するTCPの堅牢性の向上」、RFC 5961、DOI 10.17487/RFC5961、2010年8月、<http://www.rfc-editor.org/info/rfc5961>。
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010, <http://www.rfc-editor.org/info/rfc6062>.
[RFC6062] Perreault, S., Ed. and J. Rosenberg、「TCP割り当てのためのNAT（TURN）拡張の周りのリレーを使用したトラバーサル」、RFC 6062、DOI 10.17487/RFC6062、2010年11月、<http://www.rfc-editor.org/info/rfc6062>。
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <http://www.rfc-editor.org/info/rfc6263>.
[RFC6263] Marjou, X. and A. Sollaud、「RTP / RTP制御プロトコル（RTCP）フローに関連するNATマッピングを維持するためのアプリケーションメカニズム」、RFC 6263、DOI 10.17487/RFC6263、2011年6月、<http://www.rfc-editor.org/info/rfc6263>。
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <http://www.rfc-editor.org/info/rfc7350>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro、「NATのセッショントラバーサルユーティリティ（STUN）のトランスポートとしてのデータグラムトランスポート層セキュリティ（DTLS）」、RFC 7350、DOI 10.17487/RFC7350、2014年8月、<http://www.rfc-editor.org/info/rfc7350>。
[WebRTC-QoS] Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Polk, "DSCP and other packet markings for RTCWeb QoS", Work in Progress, draft-ietf-tsvwg-rtcweb-qos-04, July 2015.
[WebRTC-QoS] Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Polk、「RTCWeb QoSのDSCPおよびその他のパケットマーキング」、Work in Progress、draft-ietf-tsvwg -rtcweb-qos-04、2015年7月。
[WebRTC-SA] Rescorla, E., "WebRTC Security Architecture", Work in Progress, draft-ietf-rtcweb-security-arch-11, March 2015.
[WebRTC-SA] Rescorla, E.、「WebRTC Security Architecture」、Work in Progress、draft-ietf-rtcweb-security-arch-11、2015年3月。
[WebRTC-SEC] Rescorla, E., "Security Considerations for WebRTC", Work in Progress, draft-ietf-rtcweb-security-08, February 2015.
[WebRTC-SEC] Rescorla, E.、「WebRTCのセキュリティに関する考慮事項」、Work in Progress、draft-ietf-rtcweb-security-08、2015年2月。
Acknowledgements
謝辞
Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus Westerlund, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan Banavi, Christian Groves, Meral Shirazipour, David Black, Barry Leiba, Ben Campbell, and Stephen Farrell for their valuable inputs and comments. Thanks to Christer Holmberg for doing a thorough review.
エリック・レスコーラ、ハラルド・アルヴェストランド、バーナード・アボバ、マグナス・ウェスターランド、カレン・ジェニングス、クリスター・ホルムバーグ、サイモン・ペロー、ポール・キジバット、エミル・イヴォフ、ジョナサン・レノックス、イナキ・バズ・カスティージョ、ラジモハン・バナビ、クリスチャン・グローブス、メラル・シラジプール、デビッド・ブラック、バリー・リー、Ben Campbell、Stephen Farrellの貴重な意見やコメントをお寄せください。徹底的なレビューを行ってくれたChrister Holmbergに感謝します。
Authors' Addresses
著者のアドレス
Muthu Arul Mozhi Perumal Ericsson Ferns Icon Doddanekundi, Mahadevapura Bangalore, Karnataka 560037 India Email: muthu.arul@gmail.com
Mutu Arul Mozhi Perumal Reichsvn Ferns Icon Periyanekundi、Mahadevapur Bangalore、Karnataka ೫೬೦೦೩೭ Indiaメール：muthu.ruul@gmail.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 United States Email: dwing@cisco.com
Dan Wing Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134 United States Email：dwing@cisco.com
Ram Mohan Ravindranath Cisco Systems Cessna Business Park Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India Email: rmohanr@cisco.com
Ram Mohan Ravindranath Cisco Systems Sasna Business Park Sarajpur-Marthahalli Outer Ring Road Bangalore、Karnataka 560103 Indiaメール：ramohaner@scisco.com
Tirumaleswar Reddy Cisco Systems Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com
Tirumaleswar Reddy Cisco Systems Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 Indiaメール：tireddy@cisco.com
Martin Thomson Mozilla 650 Castro Street, Suite 300 Mountain View, California 94041 United States Email: martin.thomson@gmail.com
Martin Thomson Mozilla 650 Castro Street、Suite 300 Mountain View、California 94041 United States Email：martin.thomson@gmail.com