Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 7350 Jive Communications
Updates: 5389, 5928 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 August 2014
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 7350 Jive Communications
Updates: 5389, 5928 G. Salgueiro
Category: Standards Track Cisco Systems
ISSN: 2070-1721 August 2014
Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)
数据报传输层安全性（DTLS）作为NAT（STUN）会话遍历实用程序的传输
Abstract
摘要
This document specifies the usage of Datagram Transport Layer Security (DTLS) as a transport protocol for Session Traversal Utilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT (TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928.
本文档指定了数据报传输层安全性（DTLS）作为NAT（STUN）会话遍历实用程序的传输协议的用法。它提供了关于何时以及如何在当前标准化的眩晕使用中使用DTL的指导。它还规定了使用中继NAT（TURN）URI对STUN和遍历的修改，以及对TURN解析机制的修改，以促进STUN解析，并将URI转换为支持DTL作为传输协议的STUN和TURN服务器的IP地址和端口。本文件更新了RFCs 5389和5928。
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/rfc7350.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7350.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3
4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4
4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 5
4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5
4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5
4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 6
4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 6
4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6
4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 7
4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. S-NAPTR Application Protocol Tag . . . . . . . . . . . . 9
6.2. Service Name and Transport Protocol Port Number . . . . . 9
6.2.1. The "stuns" Service Name . . . . . . . . . . . . . . 10
6.2.2. The "turns" Service Name . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3
4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4
4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 5
4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5
4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5
4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 6
4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 6
4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6
4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 7
4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. S-NAPTR Application Protocol Tag . . . . . . . . . . . . 9
6.2. Service Name and Transport Protocol Port Number . . . . . 9
6.2.1. The "stuns" Service Name . . . . . . . . . . . . . . 10
6.2.2. The "turns" Service Name . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
STUN [RFC5389] defines Transport Layer Security (TLS) over TCP (simply referred to as TLS [RFC5246]) as the transport for STUN due to additional security advantages it offers over plain UDP or TCP transport. But, TCP (and thus TLS-over-TCP) is not an optimal transport when STUN is used for its originally intended purpose, which is to support multimedia sessions. This is a well documented and understood transport limitation for real-time communications.
STUN[RFC5389]将TCP上的传输层安全性（TLS）（简称TLS[RFC5246]）定义为STUN的传输，因为它比普通UDP或TCP传输提供了更多的安全优势。但是，当STUN用于其最初的预期目的（即支持多媒体会话）时，TCP（以及TCP上的TLS）并不是最佳传输。这是一个很好的记录和理解的实时通信传输限制。
DTLS-over-UDP (referred to in this document as simply DTLS [RFC6347]) offers the same security advantages as TLS-over-TCP, but without the undesirable concerns.
UDP上的DTLS（在本文档中简称为DTLS[RFC6347]）提供了与TCP上的TLS相同的安全优势，但没有不必要的顾虑。
The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "must" or "Must"), they have their usual English meanings, and are not to be interpreted as RFC 2119 key words.
当本文件中的关键词“必须”、“不得”、“必需”、“可能”和“可选”出现在所有大写字母中时，应按照[RFC2119]中所述进行解释。如果这些词不在所有大写字母中（如“必须”或“必须”），则它们具有其通常的英语含义，且不得解释为RFC 2119关键词。
STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This document adds DTLS as a valid transport for STUN.
STUN[RFC5389]定义了三种传输：UDP、TCP和TLS。本文档将DTL添加为STUN的有效传输。
STUN over DTLS MUST use the same retransmission rules as STUN over UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use the same rules that are described in Section 7.2.2 of [RFC5389] to verify the server identity. Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, implementations of STUN over DTLS, and deployed clients and servers, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and MAY support other cipher suites. Perfect Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS cipher suites. Cipher suites with known weaknesses, such as those based on (single) DES and RC4, MUST NOT be used. Implementations MUST disable TLS-level compression. The same rules established in Section 7.2.2 of [RFC5389] for keeping open and closing TCP/TLS connections MUST be used as well for DTLS associations.
DTLS上的STUN必须使用与UDP上的STUN相同的重传规则（如[RFC5389]第7.2.1节所述）。它还必须使用[RFC5389]第7.2.2节中描述的相同规则来验证服务器标识。与TLS_RSA_WITH_AES_128_CBC_SHA（STUN over TLS的默认密码套件）不同，STUN over DTL的实现以及部署的客户端和服务器必须支持TLS_DHE_RSA_WITH_AES_128_GCM_SHA256和TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，并且可能支持其他密码套件。完美前向保密（PFS）密码套件必须优先于非PFS密码套件。不得使用具有已知弱点的密码套件，例如基于（单一）DES和RC4的密码套件。实现必须禁用TLS级压缩。[RFC5389]第7.2.2节中建立的保持打开和关闭TCP/TLS连接的相同规则也必须用于DTLS关联。
In addition to the path MTU rules described in Section 7.1 of [RFC5389], if the path MTU is unknown, the actual STUN message needs to be adjusted to take into account the size of the (13-byte) DTLS Record header, the MAC size, and the padding size.
除了[RFC5389]第7.1节中描述的路径MTU规则外，如果路径MTU未知，则需要调整实际STUN消息，以考虑（13字节）DTLS记录头的大小、MAC大小和填充大小。
By default, STUN over DTLS MUST use port 5349, the same port number as STUN over TLS. However, the Service Record (SRV) procedures can be implemented to use a different port (as described in Section 9 of [RFC5389]). When using SRV records, the service name MUST be set to "stuns" and the protocol name to "udp".
默认情况下，DTLS上的STUN必须使用端口5349，端口号与TLS上的STUN相同。但是，服务记录（SRV）程序可以使用不同的端口（如[RFC5389]第9节所述）。使用SRV记录时，服务名称必须设置为“stuns”，协议名称必须设置为“udp”。
Classic STUN [RFC3489] (which was obsoleted by [RFC5389]) defines only UDP as a transport, and DTLS MUST NOT be used. Any STUN request or indication without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST always result in an error.
经典STUN[RFC3489]（已被[RFC5389]淘汰）仅将UDP定义为传输，并且不能使用DTL。DTLS上任何未使用magic cookie（参见[RFC5389]第6节）的眩晕请求或指示必须始终导致错误。
Section 7.2 of [RFC5389] states that STUN usages must specify which transport protocol is used. The following sections discuss if and how the existing STUN usages are used with DTLS as the transport. Future STUN usages MUST take into account DTLS as a transport and discuss its applicability. In all cases, new STUN usages MUST explicitly state if implementing the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347] is mandatory.
[RFC5389]第7.2节规定，STUN使用必须指定使用哪种传输协议。以下各节将讨论现有STUN使用是否以及如何与DTL一起用作传输。未来的STUN使用必须考虑DTLS作为一种传输方式，并讨论其适用性。在所有情况下，新的STUN使用必须明确说明是否必须实施[RFC6347]第4.2.1节所述的拒绝服务对策。
As stated by Section 13 of [RFC5389], "...TLS provides minimal security benefits..." for this particular STUN usage. DTLS will also similarly offer only limited benefit. This is because the only mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED-ADDRESS, which is already known by an on-path attacker, since it is the same as the source address and port of the STUN request. On the other hand, using TLS/DTLS will prevent an active attacker to inject XOR-MAPPED-ADDRESS in responses. The TLS/DTLS transport will also protect the SOFTWARE attribute, which can be used to find vulnerabilities in STUN implementations.
如[RFC5389]第13节所述，“……TLS为这种特殊的STUN使用提供了最低限度的安全效益……”。DTL同样也只能提供有限的好处。这是因为TLS/DTLS保护的唯一强制属性是XOR-MAPPED-ADDRESS，路径上的攻击者已经知道该属性，因为它与STUN请求的源地址和端口相同。另一方面，使用TLS/DTLS将防止主动攻击者在响应中注入XOR-MAPPED-ADDRESS。TLS/DTLS传输还将保护软件属性，该属性可用于查找STUN实现中的漏洞。
Regardless, this usage is rarely used by itself, since using TURN [RFC5766] with Interactive Connectivity Establishment (ICE) [RFC5245] is generally indispensable, and TURN provides the same NAT Discovery feature as part of an allocation creation. In fact, with ICE, the NAT Discovery usage is only used when there is no longer any resource available for new allocations in the TURN server.
无论如何，这种用法本身很少使用，因为将TURN[RFC5766]与交互式连接建立（ICE）[RFC5245]结合使用通常是必不可少的，TURN提供了与分配创建相同的NAT发现功能。事实上，对于ICE，只有当TURN服务器中不再有任何可用于新分配的资源时，才会使用NAT发现。
A STUN server implementing the NAT Discovery usage and using DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347].
实施NAT发现使用和使用DTL的STUN服务器必须实施[RFC6347]第4.2.1节所述的拒绝服务对策。
This document does not make any changes to the syntax of a STUN URI [RFC7064]. As indicated in Section 3.2 of [RFC7064], secure transports like STUN over TLS, and now STUN over DTLS, MUST use the "stuns" URI scheme.
本文档不对STUN URI[RFC7064]的语法进行任何更改。如[RFC7064]第3.2节所述，TLS上的STUN和DTLS上的STUN等安全传输必须使用“stuns”URI方案。
The <host> value MUST be used when using the rules in Section 7.2.2 of [RFC5389] to verify the server identity. A STUN URI containing an IP address MUST be rejected, unless the domain name is provided by the same mechanism that provided the STUN URI, and that domain name can be passed to the verification code.
使用[RFC5389]第7.2.2节中的规则验证服务器标识时，必须使用<host>值。必须拒绝包含IP地址的STUN URI，除非域名由提供STUN URI的相同机制提供，并且该域名可以传递给验证代码。
Using DTLS would hide the USERNAME, PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING attributes. But, because MESSAGE-INTEGRITY protects the entire STUN response using a password that is known only by looking at the Session Description Protocol (SDP) exchanged, it is not possible for an attacker that does not have access to this SDP to inject an incorrect XOR-MAPPED-ADDRESS, which would subsequently be used as a peer reflexive candidate.
使用DTL将隐藏用户名、优先级、使用候选、ICE控制和ICE控制属性。但是，由于消息完整性使用仅通过查看交换的会话描述协议（SDP）才知道的密码来保护整个STUN响应，因此无法访问该SDP的攻击者不可能注入错误的XOR映射地址，该地址随后将用作对等自反候选地址。
Adding DTLS on top of the connectivity check would delay, and consequently impair, the ICE process. Adding additional round trips to ICE is undesirable, so much that there is a proposal ([ICE-DTLS]) to use the DTLS handshake used by the WebRTC Secure Real-time Transport Protocol (SRTP) streams as a replacement for the connectivity checks.
在连接性检查之上添加DTL将延迟ICE过程，从而损害ICE过程。向ICE添加额外的往返是不可取的，因此有人建议（[ICE-DTLS]）使用WebRTC安全实时传输协议（SRTP）流使用的DTLS握手来替代连接检查。
STUN URIs are not used with this usage.
此用法中不使用STUN URI。
When STUN Binding Indications are being used for media keep-alive (described in Section 10 of [RFC5245]), it runs alongside an RTP or RTP Control Protocol (RTCP) session. It is possible to send these media keep-alive packets inside a separately negotiated non-SRTP DTLS session if DTLS-SRTP [RFC5764] is used, but that would add overhead, with minimal security benefit.
当STUN绑定指示用于介质保持活动（如[RFC5245]第10节所述）时，它与RTP或RTP控制协议（RTCP）会话一起运行。如果使用DTLS-SRTP[RFC5764]，则可以在单独协商的非SRTP DTLS会话中发送这些媒体保持活动的数据包，但这会增加开销，且安全效益最小。
STUN URIs are not used with this usage.
此用法中不使用STUN URI。
The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow. This flow would be protected if a SIP over DTLS transport mechanism is implemented (such as described in [SIP-DTLS]).
SIP保持活动（如[RFC5626]所述）在SIP流中运行。如果实现了SIP over DTLS传输机制（如[SIP-DTLS]中所述），则该流将受到保护。
STUN URIs are not used with this usage.
此用法中不使用STUN URI。
The NAT Behavior Discovery usage is Experimental and to date has never been effectively deployed. Despite this, using DTLS would add the same security properties as for the NAT Discovery usage (Section 4.1).
NAT行为发现的使用是实验性的，到目前为止还没有得到有效的部署。尽管如此，使用DTL将添加与NAT发现使用相同的安全属性（第4.1节）。
The STUN URI can be used to access the NAT Discovery feature of a NAT Behavior Discovery server, but accessing the full features would require definition of a "stun-behaviors:" URI, which is out of scope for this document.
STUN URI可用于访问NAT行为发现服务器的NAT发现功能，但访问完整功能需要定义“STUN行为：”URI，这超出了本文档的范围。
A STUN server implementing the NAT Behavior Discovery usage and using DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347].
实施NAT行为发现使用和使用DTL的STUN服务器必须实施[RFC6347]第4.2.1节所述的拒绝服务对策。
TURN [RFC5766] defines three combinations of transports/allocations: UDP/UDP, TCP/UDP, and TLS/UDP. This document adds DTLS/UDP as a valid combination. A TURN server using DTLS MUST implement the denial-of-service countermeasure described in Section 4.2.1 of [RFC6347].
TURN[RFC5766]定义了三种传输/分配组合：UDP/UDP、TCP/UDP和TLS/UDP。本文档将DTLS/UDP添加为有效组合。使用DTL的TURN服务器必须实施[RFC6347]第4.2.1节所述的拒绝服务对策。
[RFC6062] states that TCP allocations cannot be obtained using a UDP association between client and server. The fact that DTLS uses UDP implies that TCP allocations MUST NOT be obtained using a DTLS association between client and server.
[RFC6062]指出，无法使用客户端和服务器之间的UDP关联获得TCP分配。DTLS使用UDP这一事实意味着不能使用客户端和服务器之间的DTLS关联来获得TCP分配。
By default, TURN over DTLS uses port 5349, the same port number as TURN over TLS. However, the SRV procedures can be implemented to use a different port (as described in Section 6 of [RFC5766]). When using SRV records, the service name MUST be set to "turns" and the protocol name to "udp".
默认情况下，移交DTLS使用端口5349，端口号与移交TLS相同。但是，SRV程序可以使用不同的端口（如[RFC5766]第6节所述）。使用SRV记录时，服务名称必须设置为“turns”，协议名称必须设置为“udp”。
This document does not make any changes to the syntax of a TURN URI [RFC7065]. As indicated in Section 3 of [RFC7065], secure transports like TURN over TLS, and now TURN over DTLS, MUST use the "turns" URI scheme. When using the "turns" URI scheme to designate TURN over DTLS, the transport value of the TURN URI, if set, MUST be "udp".
本文档不对TURN URI[RFC7065]的语法进行任何更改。如[RFC7065]第3节所述，安全传输，如翻转TLS和现在翻转DTL，必须使用“翻转”URI方案。当使用“turns”URI方案来指定翻转DTL时，翻转URI的传输值（如果设置）必须为“udp”。
The <host> value MUST be used when using the rules in Section 7.2.2 of [RFC5389] to verify the server identity. A TURN URI containing an IP address MUST be rejected, unless the domain is provided by the same mechanism that provided the TURN URI, and that domain name can be passed to the verification code.
使用[RFC5389]第7.2.2节中的规则验证服务器标识时，必须使用<host>值。必须拒绝包含IP地址的TURN URI，除非域由提供TURN URI的相同机制提供，并且该域名可以传递给验证代码。
This document defines a new Straightforward-Naming Authority Pointer (S-NAPTR) application protocol tag: "turn.dtls".
本文档定义了一个新的简单命名机构指针（S-NAPTR）应用程序协议标记：“turn.dtls”。
The <transport> component, as provisioned or resulting from the parsing of a TURN URI, is passed without modification to the TURN resolution mechanism defined in Section 3 of [RFC5928], but with the following alterations to that algorithm:
提供的<transport>组件或由回合URI解析产生的<transport>组件在不修改[RFC5928]第3节中定义的回合解析机制的情况下传递，但对该算法进行以下修改：
o The acceptable values for the transport name are extended with the addition of "dtls".
o 传输名称的可接受值通过添加“DTL”进行扩展。
o The acceptable values in the ordered list of supported TURN transports is extended with the addition of "Datagram Transport Layer Security (DTLS)".
o 通过添加“数据报传输层安全性（DTLS）”，扩展了受支持TURN传输的有序列表中的可接受值。
o The resolution algorithm check rules list is extended with the addition of the following step:
o 通过添加以下步骤扩展解析算法检查规则列表：
If <secure> is true and <transport> is defined as "udp" but the list of TURN transports supported by the application does not contain DTLS, then the resolution MUST stop with an error.
如果<secure>为true且<transport>定义为“udp”，但应用程序支持的TURN传输列表不包含DTL，则解析必须停止并出现错误。
o The 5th rule of the resolution algorithm check rules list is modified to read like this:
o 解析算法检查规则列表的第5条规则修改如下：
If <secure> is true and <transport> is not defined but the list of TURN transports supported by the application does not contain TLS or DTLS, then the resolution MUST stop with an error.
如果<secure>为true且未定义<transport>，但应用程序支持的转弯传输列表不包含TLS或DTL，则解析必须以错误停止。
o Table 1 is modified to add the following line:
o 修改表1以添加以下行：
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| true | "udp" | DTLS |
+----------+-------------+----------------+
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| true | "udp" | DTLS |
+----------+-------------+----------------+
o In step 1 of the resolution algorithm, the default port for DTLS is 5349.
o 在解析算法的步骤1中，DTLS的默认端口是5349。
o In step 4 of the resolution algorithm, the following is added to the list of conversions between the filtered list of TURN transports supported by the application and application protocol tags:
o 在解析算法的步骤4中，将以下内容添加到应用程序和应用程序协议标签支持的已过滤转弯传输列表之间的转换列表中：
"turn.dtls" is used if the TURN transport is DTLS.
如果turn传输为dtls，则使用“turn.dtls”。
Note that using the resolution mechanism in [RFC5928] does not imply that additional round trips to the DNS server will be needed (e.g., the TURN client will start immediately if the TURN URI contains an IP address).
请注意，使用[RFC5928]中的解析机制并不意味着需要到DNS服务器的额外往返（例如，如果TURN URI包含IP地址，TURN客户端将立即启动）。
STUN over DTLS as a STUN transport does not introduce any specific security considerations beyond those for STUN over TLS detailed in [RFC5389].
作为STUN传输，DTLS上的STUN不会引入任何特定的安全注意事项，除了[RFC5389]中详述的TLS上的STUN之外。
The usage of "udp" as a transport parameter with the "stuns" URI scheme does not introduce any specific security issues beyond those discussed in [RFC7064].
在“stuns”URI方案中使用“udp”作为传输参数，除了[RFC7064]中讨论的安全问题外，不会引入任何特定的安全问题。
TURN over DTLS as a TURN transport does not introduce any specific security considerations beyond those for TURN over TLS detailed in [RFC5766].
除了[RFC5766]中详细说明的转换TL外，作为转换传输的转换DTL不会引入任何特定的安全注意事项。
The usage of "udp" as a transport parameter with the "turns" URI scheme does not introduce any specific security issues beyond those discussed in [RFC7065].
将“udp”用作“turns”URI方案的传输参数不会引入任何超出[RFC7065]中讨论的特定安全问题。
The new S-NAPTR application protocol tag defined in this document as well as the modifications this document makes to the TURN resolution mechanism described in [RFC5928] do not introduce any additional security considerations beyond those outlined in [RFC5928].
本文件中定义的新S-NAPTR应用协议标签以及本文件对[RFC5928]中描述的转向解析机制所做的修改不会引入[RFC5928]中所述之外的任何其他安全注意事项。
This specification contains the registration information for one S-NAPTR application protocol tag in the "Straightforward-NAPTR (S-NAPTR) Parameters" registry under "S-NAPTR Application Protocol Tags" (in accordance with [RFC3958]).
本规范包含“S-NAPTR应用协议标签”下“直接NAPTR（S-NAPTR）参数”注册表中一个S-NAPTR应用协议标签的注册信息（根据[RFC3958]）。
Application Protocol Tag: turn.dtls
Intended Usage: See Section 4.6.2
Interoperability considerations: N/A
Security considerations: See Section 5
Relevant publications: This document
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
Application Protocol Tag: turn.dtls
Intended Usage: See Section 4.6.2
Interoperability considerations: N/A
Security considerations: See Section 5
Relevant publications: This document
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
This specification contains the registration information for two Service Name and Transport Protocol Port Numbers in the "Service Names and Transport Protocol Port Numbers/Service Name and Transport Protocol Port Number" registry (in accordance with [RFC6335]).
本规范包含“服务名称和传输协议端口号/服务名称和传输协议端口号”注册表中两个服务名称和传输协议端口号的注册信息（根据[RFC6335]）。
IANA has modified the following entry in the registry "Service Names and Transport Protocol Port Numbers/Service Name and Transport Protocol Port Number":
IANA已修改注册表中的以下条目“服务名称和传输协议端口号/服务名称和传输协议端口号”：
Service Name: stuns PortNumber: 5349 Transport Protocol: udp Description: Reserved for a future enhancement of STUN Assignee: Contact: Reference: RFC 5389
服务名称：stuns端口号：5349传输协议：udp描述：保留用于STUN的未来增强受让人：联系人：参考：RFC 5389
So that it contains the following:
使其包含以下内容：
Service Name: stuns Port Number: 5349 Transport Protocol: udp Description: STUN over DTLS Assignee: IESG Contact: IETF Chair <chair@ietf.org> Reference: RFC 7350 Assignment Notes: This service name was initially created by RFC 5389.
服务名称：STUN端口号：5349传输协议：udp描述：DTLS上的STUN受让人：IESG联系人：IETF主席<chair@ietf.org>参考：RFC 7350分配说明：此服务名称最初由RFC 5389创建。
IANA has modified the following entry in the registry "Service Names and Transport Protocol Port Numbers/Service Name and Transport Protocol Port Number":
IANA已修改注册表中的以下条目“服务名称和传输协议端口号/服务名称和传输协议端口号”：
Service Name: turns Port Number: 5349 Transport Protocol: udp Description: Reserved for a future enhancement of TURN Assignee: Contact: Reference: RFC 5766
服务名称：turns端口号：5349传输协议：udp描述：保留用于TURN的未来增强受让人：联系人：参考：RFC 5766
So that it contains the following:
使其包含以下内容：
Service Name: turns Port Number: 5349 Transport Protocol: udp Description: TURN over DTLS Assignee: IESG Contact: IETF Chair <chair@ietf.org> Reference: RFC 7350 Assignment Notes: This service name was initially created by RFC 5766.
服务名称：翻转端口号：5349传输协议：udp描述：翻转DTLS受让人：IESG联系人：IETF主席<chair@ietf.org>参考：RFC 7350分配说明：此服务名称最初由RFC 5766创建。
Thanks to Alan Johnston, Oleg Moskalenko, Simon Perreault, Thomas Stach, Simon Josefsson, Roni Even, Kathleen Moriarty, Benoit Claise, Martin Stiemerling, Jari Arkko, and Stephen Farrell for the comments, suggestions, and questions that helped improve this document.
感谢Alan Johnston、Oleg Moskalenko、Simon Perreault、Thomas Stach、Simon Josefsson、Roni Even、Kathleen Moriarty、Benoit Claise、Martin Stieemerling、Jari Arkko和Stephen Farrell的评论、建议和问题，帮助改进了本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，2010年5月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, August 2010.
[RFC5928]Petit Huguenin，M.“使用NAT（转弯）解析机制周围的中继进行遍历”，RFC 59282010年8月。
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010.
[RFC6062]Perreault，S.和J.Rosenberg，“围绕TCP分配的NAT（TURN）扩展使用中继进行遍历”，RFC 6062，2010年11月。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 63352011年8月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-Huguenin, "URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol", RFC 7064, November 2013.
[RFC7064]Nandakumar，S.，Salgueiro，G.，Jones，P.，和M.Petit Huguenin，“NAT（STUN）协议会话遍历实用程序的URI方案”，RFC 7064，2013年11月。
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. Jones, "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", RFC 7065, November 2013.
[RFC7065]Petit Huguenin，M.，Nandakumar，S.，Salgueiro，G.，和P.Jones，“使用NAT（TURN）统一资源标识符周围的中继进行遍历”，RFC 7065，2013年11月。
[ICE-DTLS] Thomson, M., "Using Datagram Transport Layer Security (DTLS) For Interactivity Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS", Work in Progress, March 2012.
[ICE-DTLS]Thomson，M.，“使用数据报传输层安全性（DTLS）进行交互连接建立（ICE）连接检查：ICE-DTLS”，正在进行的工作，2012年3月。
[SIP-DTLS] Jennings, C. and N. Modadugu, "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", Work in Progress, October 2007.
[SIP-DTLS]Jennings，C.和N.Modadugu，“数据报传输层安全（DTLS）上的会话启动协议（SIP）”，正在进行的工作，2007年10月。
Table 1 shows how the <secure>, <port>, and <transport> components are populated for a TURN URI that uses DTLS as its transport. For all these examples, the <host> component is populated with "example.net".
表1显示了如何为使用DTL作为传输的TURN URI填充<secure>、<port>和<transport>组件。对于所有这些示例，<host>组件都填充了“example.net”。
+---------------------------------+----------+--------+-------------+
| URI | <secure> | <port> | <transport> |
+---------------------------------+----------+--------+-------------+
| turns:example.net?transport=udp | true | | DTLS |
+---------------------------------+----------+--------+-------------+
+---------------------------------+----------+--------+-------------+
| URI | <secure> | <port> | <transport> |
+---------------------------------+----------+--------+-------------+
| turns:example.net?transport=udp | true | | DTLS |
+---------------------------------+----------+--------+-------------+
Table 1
表1
With the DNS Resource Records (RRs) in Figure 1 and an ordered TURN transport list of {DTLS, TLS, TCP, UDP}, the resolution algorithm will convert the TURN URI "turns:example.net" to the ordered list of IP address, port, and protocol tuples in Table 2.
使用图1中的DNS资源记录（RRs）和{DTLS、TLS、TCP、UDP}的有序TURN传输列表，解析算法将TURN URI“turns:example.net”转换为表2中IP地址、端口和协议元组的有序列表。
example.net. IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net. IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.
例如.net。在NAPTR 100 10“中继：turn.udp:turn.dtls”数据报.example.net中。在NAPTR 200 10“中继：turn.tcp:turn.tls”stream.example.net中。
datagram.example.net. IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. IN NAPTR 200 10 S RELAY:turn.dtls "" _turns._udp.example.net.
datagram.example.net。在NAPTR 100 10 S中继中：turn.udp”“\u turn.\u udp.example.net。在NAPTR 200 10 S中继中：turn.dtls”“\u turns.\u udp.example.net。
stream.example.net. IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net.
stream.example.net。在NAPTR 100 10 S中继中：turn.tcp”“\u turn.\u tcp.example.net。在NAPTR 200 10中，继电器：turn.tls“”A.example.net。
_turn._udp.example.net. IN SRV 0 0 3478 a.example.net.
_turn._udp.example.net。在SRV 0 3478 a.example.net中。
_turn._tcp.example.net. IN SRV 0 0 5000 a.example.net.
_turn.\u tcp.example.net。在SRV 0 0 5000 a.example.net中。
_turns._udp.example.net. IN SRV 0 0 5349 a.example.net.
_转身。_udp.example.net。在SRV05349a.example.net中。
a.example.net. IN A 192.0.2.1
a、 例如.net。在192.0.2.1中
Figure 1
图1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | DTLS | 192.0.2.1 | 5349 |
| 2 | TLS | 192.0.2.1 | 5349 |
+-------+----------+------------+------+
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | DTLS | 192.0.2.1 | 5349 |
| 2 | TLS | 192.0.2.1 | 5349 |
+-------+----------+------------+------+
Table 2
表2
Authors' Addresses
作者地址
Marc Petit-Huguenin Jive Communications 1275 West 1600 North, Suite 100 Orem, UT 84057 USA
Marc Petit Huguein Jive Communications 1275西1600北，奥勒姆100号套房，美国犹他州84057
EMail: marcph@getjive.com
EMail: marcph@getjive.com
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Gonzalo Salgueiro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: gsalguei@cisco.com
EMail: gsalguei@cisco.com