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
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
用于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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
首次建立会话时，ICE实现通过执行STUN连接检查获得发送的初始同意。本文档介绍了一种新的STUN用法，其中包括请求和
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.
验证远程对等方是否持续同意接收流量的响应消息。该同意书在一段时间后到期，需要不断更新，以确保同意书可以终止。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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需要周期性的keepalive流量来保持NAT绑定的活动状态（参见[RFC5245]和[RFC6263]的第10节），但这些keepalive会作为发送和遗忘的眩晕指示发送，并且不会引起响应。需要响应才能同意继续发送流量。因此，我们需要一个同意新鲜度的请求/响应机制。ICE可用于该机制，因为ICE实现已经需要继续侦听ICE消息，如[RFC5245]第10节所述。发送同意新鲜度的STUN绑定请求也可用于keepalive目的（即，保持NAT绑定活动）。因此，根据[RFC5245]第20.2.3节的规定，在发送同意请求的候选对上不发送专用keepalive（例如，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.
当使用安全实时传输协议（SRTP）时，以下注意事项适用。SRTP使用对称密钥进行加密和认证；也就是说，发送方和接收方都知道密钥。对于两方会话，从单个远程方接收经过身份验证的数据包是数据包来自该方的有力保证。但是，当一个会话涉及两个以上的参与方（所有参与方都知道对方的密钥）时，这些参与方中的任何一方都可能发送（或伪造）数据包。这种共享密钥分发可以通过一些多媒体互联网密钥（MIKEY）[RFC3830]模式、安全描述[RFC4568]和加密密钥传输（EKT）[EKT]实现。因此，在这种共享密钥分发中，接收经认证的SRTP分组不足以验证同意。
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协议的可选扩展；它可以部署在双方通信会话的一端，而不会影响另一方。
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]获得发送流量的初始同意。当候选对进入成功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无法确定发送流量的同意何时结束。本文件描述了发送同意的两种终止方式：同意到期和立即撤销同意，将在以下章节中讨论。
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.
端点不得发送用于建立同意的消息以外的数据，除非接收端点已同意接收数据。允许按照[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确认），但通过TCP连接同意是必要的，因为它可以转换为UDP连接（例如，[RFC6062]）。
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秒后过期。也就是说，如果在30秒内没有从远程对等方的传输地址接收到有效的STUN绑定响应，则端点必须停止该5元组上的传输。同意到期后收到的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倍之间随机进行。实现应设置5秒的默认间隔，从而使检查之间的间隔为4到6秒。实施不得将检查间隔时间设置为小于4秒。此计时器与同意到期超时无关。
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事务标识符。每个具有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.
端点应根据估计的往返时间（RTT）（参见[RFC5389]第7.2.1节），在允许网络延迟变化的情况下，等待其发送的每个请求的绑定响应一段时间。RTT值可以按照[RFC5389]中的说明进行更新。当同意到期时，必须放弃候选对的所有未完成的STUN同意事务。
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事务标识符，因为这会导致对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重启期间继续在先前验证的候选对上发送流量的端点必须继续对该候选对执行同意刷新，如前所述。
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).
虽然TCP提供了一定的保护，免受非路径攻击者（[RFC5961]、[RFC4953]），但攻击者仍有可能通过欺骗ACK导致TCP发送者永久发送。为防止此类攻击，必须对所有传输连接（包括TCP）执行同意检查。这样，欺骗TCP段的非路径攻击者就不能在同意计时器过期（30秒）后导致TCP发送方发送。
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]).
如果端点不发送应用程序数据，则不需要保持同意。但是，端点必须在恢复发送应用程序数据之前重新获得同意。在没有任何数据包的情况下，流的中间盒中的任何绑定都可能过期。此外，一个对等方无法发送对许多协议都是有害的。在没有更好的网络信息的情况下，如果端点需要确保其NAT或防火墙映射不会过期，可以使用keepalive或其他技术（请参阅[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凭据。这意味着需要新的会话或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
通过接收到关闭连接的经过身份验证的消息（例如，传输层安全（TLS）致命警报）或收到有效的
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.
和已验证的STUN响应，错误代码为禁止（403）。但是请注意，同意撤销消息可能会在网络上丢失，因此端点可以重新发送这些消息，或者等待同意过期。
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）并不表示撤销同意。因此，接收未经验证的会话结束消息的端点应继续发送媒体（通过无连接传输）或尝试重新建立连接（通过面向连接的传输），直到同意过期或接收到撤销同意的经过验证的消息。
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.
对于给定的5元组，建议STUN同意检查使用与[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].
本文件描述了一种安全机制，[RFC7350]第4.1节和第4.2节中提到了该机制的详细信息。同意要求[RFC5389]第6节中定义的96位事务ID从间隔0中统一随机选择。。2**96-1，且加密能力强。这是一个足够好的安全措施，可以防止偏离路径的攻击者重播旧的晕眩同意响应。[WebRTC SEC]第3.3节和第4.2节讨论了使用浏览器作为攻击平台来避免攻击的同意验证。
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.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，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>.
[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.，和D.Wing，“安全RTP的加密密钥传输”，正在进行的工作，草稿-ietf-avtcore-srtp-EKT-032014年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.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，DOI 10.17487/RFC3830，2004年8月<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.和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.，和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.和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.和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.和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.，和J.Polk，“用于RTCWeb QoS的DSCP和其他数据包标记”，正在进行的工作，草案-ietf-tsvwg-RTCWeb-QoS-042015年7月。
[WebRTC-SA] Rescorla, E., "WebRTC Security Architecture", Work in Progress, draft-ietf-rtcweb-security-arch-11, March 2015.
[WebRTC SA]Rescorla，E.，“WebRTC安全体系结构”，正在进行的工作，草稿-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的安全注意事项”，正在进行的工作，草稿-ietf-rtcweb-Security-082015年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.
感谢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和Stephen Farrell的宝贵投入和评论。感谢Christer Holmberg做了全面的回顾。
Authors' Addresses
作者地址
Muthu Arul Mozhi Perumal Ericsson Ferns Icon Doddanekundi, Mahadevapura Bangalore, Karnataka 560037 India Email: muthu.arul@gmail.com
Muthu Arul Mozhi Perumal Ericsson蕨类植物图标Doddanekundi，马哈德瓦普拉班加罗尔，卡纳塔克邦560037印度电子邮件：Muthu。arul@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号95134电子邮件：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 Cessna Business Park Sarjapur Marathahalli外环路卡纳塔克邦班加罗尔560103印度电子邮件：rmohanr@cisco.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商业园，卡纳塔克邦班加罗尔外环路Varthur Hobili Sarjapur Marathali 560103印度电子邮件：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号300室94041美国电子邮件：Martin。thomson@gmail.com