Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 5764 Cisco Systems
Category: Standards Track E. Rescorla
ISSN: 2070-1721 RTFM, Inc.
May 2010
Internet Engineering Task Force (IETF) D. McGrew
Request for Comments: 5764 Cisco Systems
Category: Standards Track E. Rescorla
ISSN: 2070-1721 RTFM, Inc.
May 2010
Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
数据报传输层安全性（DTLS）扩展，用于为安全实时传输协议（SRTP）建立密钥
Abstract
摘要
This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present.
本文档描述了数据报传输层安全性（DTLS）扩展，用于为安全RTP（SRTP）和安全RTP控制协议（SRTCP）流建立密钥。DTLS键控发生在媒体路径上，与存在的任何带外信令信道无关。
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/rfc5764.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5764.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4
4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5
4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5
4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7
4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8
4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9
4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12
5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16
6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17
7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17
7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18
7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18
7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19
8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23
Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. Overview of DTLS-SRTP Operation . . . . . . . . . . . . . . . 4
4. DTLS Extensions for SRTP Key Establishment . . . . . . . . . . 5
4.1. The use_srtp Extension . . . . . . . . . . . . . . . . . . 5
4.1.1. use_srtp Extension Definition . . . . . . . . . . . . 7
4.1.2. SRTP Protection Profiles . . . . . . . . . . . . . . . 8
4.1.3. srtp_mki value . . . . . . . . . . . . . . . . . . . . 9
4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Key Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Key Usage Limitations . . . . . . . . . . . . . . . . . . 12
5. Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
5.1. Data Protection . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Transmission . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Reception . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Rehandshake and Rekey . . . . . . . . . . . . . . . . . . 16
6. Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Security of Negotiation . . . . . . . . . . . . . . . . . 17
7.2. Framing Confusion . . . . . . . . . . . . . . . . . . . . 17
7.3. Sequence Number Interactions . . . . . . . . . . . . . . . 18
7.3.1. Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3.2. Renegotiation . . . . . . . . . . . . . . . . . . . . 18
7.4. Decryption Cost . . . . . . . . . . . . . . . . . . . . . 19
8. Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Overview of DTLS . . . . . . . . . . . . . . . . . . 23
Appendix B. Performance of Multiple DTLS Handshakes . . . . . . . 24
The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality, message authentication, and replay protection to RTP data and RTP Control (RTCP) traffic. SRTP does not provide key management functionality, but instead depends on external key management to exchange secret master keys, and to negotiate the algorithms and parameters for use with those keys.
安全RTP（SRTP）配置文件[RFC3711]可以为RTP数据和RTP控制（RTCP）流量提供机密性、消息身份验证和重播保护。SRTP不提供密钥管理功能，而是依赖外部密钥管理来交换密钥主密钥，并协商用于这些密钥的算法和参数。
Datagram Transport Layer Security (DTLS) [RFC4347] is a channel security protocol that offers integrated key management, parameter negotiation, and secure data transfer. Because DTLS data transfer protocol is generic, it is less highly optimized for use with RTP than is SRTP, which has been specifically tuned for that purpose.
数据报传输层安全（DTLS）[RFC4347]是一种通道安全协议，提供集成的密钥管理、参数协商和安全数据传输。因为DTLS数据传输协议是通用的，所以与SRTP相比，它在RTP中使用时的优化程度较低，SRTP专门为此进行了调优。
This document describes DTLS-SRTP, a SRTP extension for DTLS that combines the performance and encryption flexibility benefits of SRTP with the flexibility and convenience of DTLS-integrated key and association management. DTLS-SRTP can be viewed in two equivalent ways: as a new key management method for SRTP, and a new RTP-specific data format for DTLS.
本文档介绍DTLS-SRTP，它是DTLS的SRTP扩展，将SRTP的性能和加密灵活性优势与DTLS集成密钥和关联管理的灵活性和方便性结合在一起。DTLS-SRTP可以用两种等效的方式查看：作为SRTP的新密钥管理方法，以及DTLS的新RTP特定数据格式。
The key points of DTLS-SRTP are that:
DTLS-SRTP的要点是：
o application data is protected using SRTP,
o 应用程序数据使用SRTP进行保护，
o the DTLS handshake is used to establish keying material, algorithms, and parameters for SRTP,
o DTLS握手用于建立SRTP的键控材料、算法和参数，
o a DTLS extension is used to negotiate SRTP algorithms, and
o DTLS扩展用于协商SRTP算法，以及
o other DTLS record-layer content types are protected using the ordinary DTLS record format.
o 其他DTLS记录层内容类型使用普通DTLS记录格式进行保护。
The remainder of this memo is structured as follows. Section 2 describes conventions used to indicate normative requirements. Section 3 provides an overview of DTLS-SRTP operation. Section 4 specifies the DTLS extensions, while Section 5 discusses how RTP and RTCP are transported over a DTLS-SRTP channel. Section 6 describes use with multi-party sessions. Section 7 and Section 9 describe Security and IANA considerations.
本备忘录的其余部分结构如下。第2节描述了用于表示规范性要求的惯例。第3节概述了DTLS-SRTP的操作。第4节指定了DTLS扩展，而第5节讨论了如何通过DTLS-SRTP通道传输RTP和RTCP。第6节介绍了如何使用多方会话。第7节和第9节描述了安全和IANA注意事项。
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]中所述进行解释。
DTLS-SRTP is defined for point-to-point media sessions, in which there are exactly two participants. Each DTLS-SRTP session contains a single DTLS association (called a "connection" in TLS jargon), and either two SRTP contexts (if media traffic is flowing in both directions on the same host/port quartet) or one SRTP context (if media traffic is only flowing in one direction). All SRTP traffic flowing over that pair in a given direction uses a single SRTP context. A single DTLS-SRTP session only protects data carried over a single UDP source and destination port pair.
DTLS-SRTP是为点对点媒体会话定义的，其中正好有两个参与者。每个DTLS-SRTP会话包含一个DTLS关联（在TLS行话中称为“连接”），以及两个SRTP上下文（如果媒体流量在同一主机/端口上双向流动）或一个SRTP上下文（如果媒体流量仅单向流动）。在给定方向上流过该对的所有SRTP流量都使用单个SRTP上下文。单个DTLS-SRTP会话仅保护通过单个UDP源和目标端口对传输的数据。
The general pattern of DTLS-SRTP is as follows. For each RTP or RTCP flow the peers do a DTLS handshake on the same source and destination port pair to establish a DTLS association. Which side is the DTLS client and which side is the DTLS server must be established via some out-of-band mechanism such as SDP. The keying material from that handshake is fed into the SRTP stack. Once that association is established, RTP packets are protected (becoming SRTP) using that keying material.
DTLS-SRTP的一般模式如下所示。对于每个RTP或RTCP流，对等方在同一源和目标端口对上进行DTLS握手，以建立DTLS关联。哪一侧是DTLS客户端，哪一侧是DTLS服务器必须通过一些带外机制（如SDP）建立。来自该握手的键控材料被送入SRTP堆栈。一旦建立了这种关联，RTP数据包将使用该键控材料进行保护（成为SRTP）。
RTP and RTCP traffic is usually sent on two separate UDP ports. When symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions are needed, one for the RTP port, one for the RTCP port. When RTP flows are not symmetric, four unidirectional DTLS-SRTP sessions are needed (for inbound and outbound RTP, and inbound and outbound RTCP).
RTP和RTCP通信通常在两个单独的UDP端口上发送。使用对称RTP[RFC4961]时，需要两个双向DTLS-SRTP会话，一个用于RTP端口，一个用于RTCP端口。当RTP流不对称时，需要四个单向DTLS-SRTP会话（用于入站和出站RTP，以及入站和出站RTCP）。
Symmetric RTP [RFC4961] is the case in which there are two RTP sessions that have their source and destination ports and addresses reversed, in a manner similar to the way that a TCP connection uses its ports. Each participant has an inbound RTP session and an outbound RTP session. When symmetric RTP is used, a single DTLS-SRTP session can protect both of the RTP sessions. It is RECOMMENDED that symmetric RTP be used with DTLS-SRTP.
对称RTP[RFC4961]是指两个RTP会话的源端口和目标端口以及地址发生反转的情况，其方式类似于TCP连接使用其端口的方式。每个参与者都有一个入站RTP会话和一个出站RTP会话。使用对称RTP时，单个DTLS-SRTP会话可以保护两个RTP会话。建议对称RTP与DTLS-SRTP一起使用。
RTP and RTCP traffic MAY be multiplexed on a single UDP port [RFC5761]. In this case, both RTP and RTCP packets may be sent over the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions needed. This improves the cryptographic performance of DTLS, but may cause problems when RTCP and RTP are subject to different network treatment (e.g., for bandwidth reservation or scheduling reasons).
RTP和RTCP通信可在单个UDP端口上多路复用[RFC5761]。在这种情况下，RTP和RTCP数据包都可以通过相同的DTLS-SRTP会话发送，从而将所需的DTLS-SRTP会话数量减半。这提高了DTL的加密性能，但当RTCP和RTP受到不同的网络处理（例如，出于带宽保留或调度原因）时，可能会导致问题。
Between a single pair of participants, there may be multiple media sessions. There MUST be a separate DTLS-SRTP session for each distinct pair of source and destination ports used by a media session (though the sessions can share a single DTLS session and hence amortize the initial public key handshake!).
在一对参与者之间，可能会有多个媒体会话。对于媒体会话使用的每对不同的源端口和目标端口，必须有一个单独的DTLS-SRTP会话（尽管会话可以共享一个DTLS会话，从而分摊初始公钥握手！）。
A DTLS-SRTP session may be indicated by an external signaling protocol like SIP. When the signaling exchange is integrity-protected (e.g., when SIP Identity protection via digital signatures is used), DTLS-SRTP can leverage this integrity guarantee to provide complete security of the media stream. A description of how to indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to authenticate the endpoints using fingerprints can be found in [RFC5763].
DTLS-SRTP会话可由诸如SIP的外部信令协议指示。当信令交换受到完整性保护时（例如，当使用通过数字签名的SIP身份保护时），DTLS-SRTP可以利用该完整性保证来提供媒体流的完全安全性。关于如何在SIP和SDP[RFC4566]中指示DTLS-SRTP会话以及如何使用指纹对端点进行身份验证的说明，请参见[RFC5763]。
In a naive implementation, when there are multiple media sessions, there is a new DTLS session establishment (complete with public key cryptography) for each media channel. For example, a videophone may be sending both an audio stream and a video stream, each of which would use a separate DTLS session establishment exchange, which would proceed in parallel. As an optimization, the DTLS-SRTP implementation SHOULD use the following strategy: a single DTLS association is established, and all other DTLS associations wait until that connection is established before proceeding with their handshakes. This strategy allows the later sessions to use DTLS session resumption, which allows the amortization of the expensive public key cryptography operations over multiple DTLS handshakes.
在一个简单的实现中，当存在多个媒体会话时，每个媒体通道都有一个新的DTLS会话建立（完成公钥加密）。例如，可视电话可以同时发送音频流和视频流，其中每一个都将使用单独的DTLS会话建立交换，这将并行进行。作为一种优化，DTLS-SRTP实现应该使用以下策略：建立一个DTLS关联，所有其他DTLS关联在继续握手之前等待连接建立。此策略允许以后的会话使用DTLS会话恢复，这允许在多次DTLS握手上摊销昂贵的公钥加密操作。
The SRTP keys used to protect packets originated by the client are distinct from the SRTP keys used to protect packets originated by the server. All of the RTP sources originating on the client for the same channel use the same SRTP keys, and similarly, all of the RTP sources originating on the server for the same channel use the same SRTP keys. The SRTP implementation MUST ensure that all of the synchronization source (SSRC) values for all of the RTP sources originating from the same device over the same channel are distinct, in order to avoid the "two-time pad" problem (as described in Section 9.1 of RFC 3711). Note that this is not an issue for separate media streams (on different host/port quartets) that use independent keying material even if an SSRC collision occurs.
用于保护客户端发起的数据包的SRTP密钥与用于保护服务器发起的数据包的SRTP密钥不同。在客户端上为同一信道发起的所有RTP源使用相同的SRTP密钥，同样，在服务器上为同一信道发起的所有RTP源使用相同的SRTP密钥。SRTP实施必须确保来自同一信道上同一设备的所有RTP源的所有同步源（SSRC）值是不同的，以避免“两次pad”问题（如RFC 3711第9.1节所述）。请注意，对于使用独立键控材料的独立媒体流（在不同的主机/端口四重奏上），即使发生SSRC冲突，这也不是问题。
In order to negotiate the use of SRTP data protection, clients include an extension of type "use_srtp" in the DTLS extended client hello. This extension MUST only be used when the data being transported is RTP or RTCP [RFC3550]. The "extension_data" field of this extension contains the list of acceptable SRTP protection profiles, as indicated below.
为了协商SRTP数据保护的使用，客户机在DTLS扩展客户机hello中包括“use_SRTP”类型的扩展。仅当传输的数据为RTP或RTCP[RFC3550]时，才能使用此扩展。此扩展的“扩展数据”字段包含可接受的SRTP保护配置文件列表，如下所示。
Servers that receive an extended hello containing a "use_srtp" extension can agree to use SRTP by including an extension of type "use_srtp", with the chosen protection profile in the extended server hello. This process is shown below.
接收包含“use_srtp”扩展的扩展hello的服务器可以通过在扩展服务器hello中包含类型为“use_srtp”的扩展以及所选的保护配置文件来同意使用srtp。这个过程如下所示。
Client Server
客户端服务器
ClientHello + use_srtp -------->
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
ClientHello + use_srtp -------->
ServerHello + use_srtp
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
SRTP packets <-------> SRTP packets
Note that '*' indicates messages that are not always sent in DTLS. The CertificateRequest, client and server Certificates, and CertificateVerify will be sent in DTLS-SRTP.
请注意，“*”表示并非总是以DTL发送的消息。CertificateRequest、客户端和服务器证书以及CertificateVerify将在DTLS-SRTP中发送。
Once the "use_srtp" extension is negotiated, the RTP or RTCP application data is protected solely using SRTP. Application data is never sent in DTLS record-layer "application_data" packets. Rather, complete RTP or RTCP packets are passed to the DTLS stack, which passes them to the SRTP stack, which protects them appropriately. Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means that RTP and RTCP packets may both be passed to the DTLS stack. Because the DTLS layer does not process the packets, it does not need to distinguish them. The SRTP stack can use the procedures of [RFC5761] to distinguish RTP from RTCP.
一旦协商了“use_srtp”扩展，RTP或RTCP应用程序数据将仅使用srtp进行保护。应用程序数据从不在DTLS记录层“应用程序数据”数据包中发送。相反，完整的RTP或RTCP数据包被传递到DTLS堆栈，DTLS堆栈将它们传递到SRTP堆栈，SRTP堆栈对它们进行适当的保护。请注意，如果使用RTP/RTCP多路复用[RFC5761]，这意味着RTP和RTCP数据包都可以传递到DTLS堆栈。因为DTLS层不处理数据包，所以不需要区分它们。SRTP堆栈可以使用[RFC5761]的过程来区分RTP和RTCP。
When the "use_srtp" extension is in effect, implementations must not place more than one application data "record" per datagram. (This is only meaningful from the perspective of DTLS because SRTP is inherently oriented towards one payload per packet, but this is stated purely for clarification.)
当“use_srtp”扩展生效时，实现不能为每个数据报放置多个应用程序数据“记录”。（这仅从DTL的角度来看是有意义的，因为SRTP本质上是面向每个数据包一个有效负载的，但这只是为了澄清。）
Data other than RTP/RTCP (i.e., TLS control messages) MUST use ordinary DTLS framing and MUST be placed in separate datagrams from SRTP data.
RTP/RTCP以外的数据（即TLS控制消息）必须使用普通DTLS帧，并且必须与SRTP数据放在单独的数据报中。
A DTLS-SRTP handshake establishes one or more SRTP crypto contexts; however, they all have the same SRTP Protection Profile and Master Key Identifier (MKI), if any. MKIs are used solely to distinguish the keying material and protection profiles between distinct handshakes, for instance, due to rekeying. When an MKI is established in a DTLS-SRTP session, it MUST apply for all of the SSRCs within that session -- though a single endpoint may negotiate multiple DTLS-SRTP sessions due, for instance, to forking. (Note that RFC 3711 allows packets within the same session but with different SSRCs to use MKIs differently; in contrast, DTLS-SRTP requires that MKIs and the keys that they are associated with have the same meaning and are uniform across the entire SRTP session.)
DTLS-SRTP握手建立一个或多个SRTP加密上下文；但是，它们都具有相同的SRTP保护配置文件和主密钥标识符（MKI）（如果有的话）。mki仅用于区分不同握手之间的键控材料和保护配置文件，例如，由于重新键控。当在DTLS-SRTP会话中建立MKI时，它必须应用于该会话中的所有SSRC——尽管一个端点可能协商多个DTLS-SRTP会话，例如，由于分叉。（请注意，RFC 3711允许同一会话中但具有不同SSRC的数据包以不同方式使用MKIs；相反，DTLS-SRTP要求MKIs及其关联的密钥具有相同的含义，并且在整个SRTP会话中是统一的。）
The client MUST fill the extension_data field of the "use_srtp" extension with an UseSRTPData value (see Section 9 for the registration):
客户机必须使用UseSRTPData值填写“use_srtp”扩展的extension_数据字段（注册请参见第9节）：
uint8 SRTPProtectionProfile[2];
uint8 SRTPProtectionProfile[2]；
struct {
SRTPProtectionProfiles SRTPProtectionProfiles;
opaque srtp_mki<0..255>;
} UseSRTPData;
struct {
SRTPProtectionProfiles SRTPProtectionProfiles;
opaque srtp_mki<0..255>;
} UseSRTPData;
SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
The SRTPProtectionProfiles list indicates the SRTP protection profiles that the client is willing to support, listed in descending order of preference. The srtp_mki value contains the SRTP Master Key Identifier (MKI) value (if any) that the client will use for his SRTP packets. If this field is of zero length, then no MKI will be used.
SRTPProtectionProfiles列表表示客户端愿意支持的SRTP保护配置文件，按首选项降序列出。srtp_mki值包含客户端将用于其srtp数据包的srtp主密钥标识符（mki）值（如果有）。如果此字段长度为零，则不会使用MKI。
Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>" indicates a variable-length value with a length between 0 and 255 (inclusive). Thus, the MKI may be up to 255 bytes long.
注意：对于那些不熟悉TLS语法的人，“srtp_mki<0..255>”表示长度介于0和255（包括0和255）之间的可变长度值。因此，MKI的长度可能高达255字节。
If the server is willing to accept the use_srtp extension, it MUST respond with its own "use_srtp" extension in the ExtendedServerHello. The extension_data field MUST contain a UseSRTPData value with a single SRTPProtectionProfile value that the server has chosen for use with this connection. The server MUST NOT select a value that the client has not offered. If there is no shared profile, the server SHOULD NOT return the use_srtp extension at which point the connection falls back to the negotiated DTLS cipher suite. If that is not acceptable, the server SHOULD return an appropriate DTLS alert.
如果服务器愿意接受use\u srtp扩展，它必须在ExtendedServerHello中使用自己的“use\u srtp”扩展进行响应。extension_数据字段必须包含一个UseSRTPData值和一个服务器选择用于此连接的SRTPProtectionProfile值。服务器不能选择客户端未提供的值。如果没有共享配置文件，则服务器不应返回use_srtp扩展，此时连接将退回到协商的DTLS密码套件。如果这是不可接受的，服务器应返回适当的DTLS警报。
A DTLS-SRTP SRTP Protection Profile defines the parameters and options that are in effect for the SRTP processing. This document defines the following SRTP protection profiles.
DTLS-SRTP SRTP保护配置文件定义了对SRTP处理有效的参数和选项。本文件定义了以下SRTP保护配置文件。
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80 = {0x00, 0x05};
SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32 = {0x00, 0x06};
The following list indicates the SRTP transform parameters for each protection profile. The parameters cipher_key_length, cipher_salt_length, auth_key_length, and auth_tag_length express the number of bits in the values to which they refer. The maximum_lifetime parameter indicates the maximum number of packets that can be protected with each single set of keys when the parameter profile is in use. All of these parameters apply to both RTP and RTCP, unless the RTCP parameters are separately specified.
下表显示了每个保护配置文件的SRTP转换参数。参数cipher_key_length、cipher_salt_length、auth_key_length和auth_tag_length表示它们所引用的值中的位数。maximum_lifetime参数表示在使用参数配置文件时，每一组密钥可以保护的最大数据包数。所有这些参数均适用于RTP和RTCP，除非单独指定RTCP参数。
All of the crypto algorithms in these profiles are from [RFC3711].
这些配置文件中的所有加密算法均来自[RFC3711]。
SRTP_AES128_CM_HMAC_SHA1_80 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80 SRTP_AES128_CM_HMAC_SHA1_32 cipher: AES_128_CM cipher_key_length: 128 cipher_salt_length: 112 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 32 RTCP auth_tag_length: 80 SRTP_NULL_HMAC_SHA1_80 cipher: NULL cipher_key_length: 0 cipher_salt_length: 0 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 80
SRTP\U AES128\u CM\u HMAC\u SHA1\u 80密码：AES\u 128\u CM密码\u密钥长度：128密码\u salt\u长度：112最大使用寿命：2^31身份验证函数：HMAC-SHA1身份验证密钥长度：160身份验证标签长度：80 SRTP\u AES128\u CM\u HMAC\u SHA1\u 32密码：AES\u 128\u CM密码\u密钥长度：128\u salt\u长度：112最大使用寿命：2^31身份验证函数：HMAC-SHAU密钥：160验证标签长度：32 RTCP验证标签长度：80 SRTP NULL HMAC SHA1 SHAU 80密码：NULL密码密钥长度：0密码密钥长度：0最大生存期：2^31验证函数：HMAC-SHA1验证密钥长度：160验证标签长度：80
SRTP_NULL_HMAC_SHA1_32 cipher: NULL cipher_key_length: 0 cipher_salt_length: 0 maximum_lifetime: 2^31 auth_function: HMAC-SHA1 auth_key_length: 160 auth_tag_length: 32 RTCP auth_tag_length: 80
SRTP_NULL_HMAC_SHA1_32密码：NULL密码_密钥_长度：0密码_盐_长度：0最长生存期：2^31身份验证函数：HMAC-SHA1身份验证密钥_长度：160身份验证标签_长度：32 RTCP身份验证标签_长度：80
With all of these SRTP Parameter profiles, the following SRTP options are in effect:
对于所有这些SRTP参数配置文件，以下SRTP选项有效：
o The TLS PseudoRandom Function (PRF) is used to generate keys to feed into the SRTP Key Derivation Function (KDF). When DTLS 1.2 [DTLS1.2] is in use, the PRF is the one associated with the cipher suite. Note that this specification is compatible with DTLS 1.0 or DTLS 1.2
o TLS伪随机函数（PRF）用于生成密钥，以提供给SRTP密钥派生函数（KDF）。当使用DTLS 1.2[DTLS1.2]时，PRF是与密码套件关联的PRF。请注意，本规范与DTLS 1.0或DTLS 1.2兼容
o The Key Derivation Rate (KDR) is equal to zero. Thus, keys are not re-derived based on the SRTP sequence number.
o 密钥派生率（KDR）等于零。因此，不会基于SRTP序列号重新导出密钥。
o The key derivation procedures from Section 4.3 with the AES-CM PRF from RFC 3711 are used.
o 使用第4.3节中的关键推导程序以及RFC 3711中的AES-CM PRF。
o For all other parameters (in particular, SRTP replay window size and FEC order), the default values are used.
o 对于所有其他参数（特别是SRTP重播窗口大小和FEC顺序），使用默认值。
If values other than the defaults for these parameters are required, they can be enabled by writing a separate specification specifying SDP syntax to signal them.
如果需要这些参数的默认值以外的值，则可以通过编写一个单独的规范来启用这些值，该规范指定SDP语法以向它们发送信号。
Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection Profiles between the DTLS-SRTP session that protects an RTP flow and the DTLS-SRTP session that protects the associated RTCP flow (in those cases in which the RTP and RTCP are not multiplexed over a common port). In particular, identical ciphers SHOULD be used.
使用DTLS-SRTP的应用程序应在保护RTP流的DTLS-SRTP会话和保护相关RTCP流的DTLS-SRTP会话（在RTP和RTCP未通过公共端口多路复用的情况下）之间协调SRTP保护配置文件。特别是，应使用相同的密码。
New SRTPProtectionProfile values must be defined according to the "Specification Required" policy as defined by RFC 5226 [RFC5226]. See Section 9 for IANA Considerations.
新的SRTPProtectionProfile值必须根据RFC 5226[RFC5226]定义的“所需规范”策略定义。IANA注意事项见第9节。
The srtp_mki value MAY be used to indicate the capability and desire to use the SRTP Master Key Identifier (MKI) field in the SRTP and SRTCP packets. The MKI field indicates to an SRTP receiver which key was used to protect the packet that contains that field. The
srtp_mki值可用于指示在srtp和SRTCP分组中使用srtp主密钥标识符（mki）字段的能力和愿望。MKI字段向SRTP接收器指示哪个密钥用于保护包含该字段的数据包。这个
srtp_mki field contains the value of the SRTP MKI which is associated with the SRTP master keys derived from this handshake. Each SRTP session MUST have exactly one master key that is used to protect packets at any given time. The client MUST choose the MKI value so that it is distinct from the last MKI value that was used, and it SHOULD make these values unique for the duration of the TLS session.
srtp_mki字段包含srtp mki的值，该值与由此握手派生的srtp主密钥相关。每个SRTP会话必须正好有一个主密钥，用于在任何给定时间保护数据包。客户机必须选择MKI值，使其与上次使用的MKI值不同，并且应使这些值在TLS会话期间唯一。
Upon receipt of a "use_srtp" extension containing a "srtp_mki" field, the server MUST either (assuming it accepts the extension at all):
在收到包含“srtp_mki”字段的“use_srtp”扩展后，服务器必须（假设它完全接受该扩展）：
1. include a matching "srtp_mki" value in its "use_srtp" extension to indicate that it will make use of the MKI, or 2. return an empty "srtp_mki" value to indicate that it cannot make use of the MKI.
1. 在其“use\u srtp”扩展中包含匹配的“srtp\u mki”值，以指示它将使用mki，或2。返回一个空的“srtp_mki”值，表示它无法使用mki。
If the client detects a nonzero-length MKI in the server's response that is different than the one the client offered, then the client MUST abort the handshake and SHOULD send an invalid_parameter alert. If the client and server agree on an MKI, all SRTP packets protected under the new security parameters MUST contain that MKI.
如果客户端在服务器响应中检测到与客户端提供的响应不同的非零长度MKI，则客户端必须中止握手，并应发送无效的_参数警报。如果客户机和服务器同意MKI，则受新安全参数保护的所有SRTP数据包必须包含该MKI。
Note that any given DTLS-SRTP session only has a single active MKI (if any). Thus, at any given time, a set of endpoints will generally only be using one MKI (the major exception is during rehandshakes).
请注意，任何给定的DTLS-SRTP会话只有一个活动的MKI（如果有）。因此，在任何给定的时间，一组端点通常只使用一个MKI（主要的例外是在重新handshake期间）。
When SRTP mode is in effect, different keys are used for ordinary DTLS record protection and SRTP packet protection. These keys are generated using a TLS exporter [RFC5705] to generate
当SRTP模式生效时，普通DTLS记录保护和SRTP数据包保护使用不同的密钥。这些密钥是使用TLS导出器[RFC5705]生成的
2 * (SRTPSecurityParams.master_key_len + SRTPSecurityParams.master_salt_len) bytes of data
2*（SRTPSecurityParams.master\u key\u len+SRTPSecurityParams.master\u salt\u len）字节的数据
which are assigned as shown below. The per-association context value is empty.
其分配如下所示。每关联上下文值为空。
client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
The exporter label for this usage is "EXTRACTOR-dtls_srtp". (The "EXTRACTOR" prefix is for historical compatibility.)
这种用法的出口商标签是“提取器-dtls\U srtp”。（提取程序前缀用于历史兼容性。）
The four keying material values (the master key and master salt for each direction) are provided as inputs to the SRTP key derivation mechanism, as shown in Figure 1 and detailed below. By default, the
四个键控材质值（每个方向的主键和主盐）作为SRTP键派生机制的输入提供，如图1所示，详情如下。默认情况下
mechanism defined in Section 4.3 of [RFC3711] is used, unless another key derivation mechanism is specified as part of an SRTP Protection Profile.
使用[RFC3711]第4.3节中定义的机制，除非在SRTP保护配置文件中指定了另一种密钥派生机制。
The client_write_SRTP_master_key and client_write_SRTP_master_salt are provided to one invocation of the SRTP key derivation function, to generate the SRTP keys used to encrypt and authenticate packets sent by the client. The server MUST only use these keys to decrypt and to check the authenticity of inbound packets.
客户端写入SRTP主密钥和客户端写入SRTP主密钥用于一次调用SRTP密钥派生函数，以生成用于加密和验证客户端发送的数据包的SRTP密钥。服务器必须仅使用这些密钥来解密和检查入站数据包的真实性。
The server_write_SRTP_master_key and server_write_SRTP_master_salt are provided to one invocation of the SRTP key derivation function, to generate the SRTP keys used to encrypt and authenticate packets sent by the server. The client MUST only use these keys to decrypt and to check the authenticity of inbound packets.
服务器写入SRTP主密钥和服务器写入SRTP主密钥用于一次调用SRTP密钥派生函数，以生成用于加密和验证服务器发送的数据包的SRTP密钥。客户端必须仅使用这些密钥来解密和检查入站数据包的真实性。
TLS master
secret label
| |
v v
+---------------+
| TLS extractor |
+---------------+
| +------+ SRTP
+-> client_write_SRTP_master_key ----+--->| SRTP |-> client
| | +->| KDF | write
| | | +------+ keys
| | |
+-> server_write_SRTP_master_key -- | | +------+ SRTCP
| \ \--->|SRTCP |-> client
| \ +->| KDF | write
| | | +------+ keys
+-> client_write_SRTP_master_salt ---|-+
| |
| | +------+ SRTP
| +--->| SRTP |-> server
+-> server_write_SRTP_master_salt -+-|--->| KDF | write
| | +------+ keys
| |
| | +------+ SRTCP
| +--->|SRTCP |-> server
+----->| KDF | write
+------+ keys
TLS master
secret label
| |
v v
+---------------+
| TLS extractor |
+---------------+
| +------+ SRTP
+-> client_write_SRTP_master_key ----+--->| SRTP |-> client
| | +->| KDF | write
| | | +------+ keys
| | |
+-> server_write_SRTP_master_key -- | | +------+ SRTCP
| \ \--->|SRTCP |-> client
| \ +->| KDF | write
| | | +------+ keys
+-> client_write_SRTP_master_salt ---|-+
| |
| | +------+ SRTP
| +--->| SRTP |-> server
+-> server_write_SRTP_master_salt -+-|--->| KDF | write
| | +------+ keys
| |
| | +------+ SRTCP
| +--->|SRTCP |-> server
+----->| KDF | write
+------+ keys
Figure 1: The derivation of the SRTP keys.
图1:SRTP键的派生。
When both RTCP and RTP use the same source and destination ports, then both the SRTP and SRTCP keys are needed. Otherwise, there are two DTLS-SRTP sessions, one of which protects the RTP packets and one of which protects the RTCP packets; each DTLS-SRTP session protects the part of an SRTP session that passes over a single source/ destination transport address pair, as shown in Figure 2, independent of which SSRCs are used on that pair. When a DTLS-SRTP session is protecting RTP, the SRTCP keys derived from the DTLS handshake are not needed and are discarded. When a DTLS-SRTP session is protecting RTCP, the SRTP keys derived from the DTLS handshake are not needed and are discarded.
当RTCP和RTP使用相同的源端口和目标端口时，则需要SRTP和SRTCP密钥。否则，存在两个DTLS-SRTP会话，其中一个保护RTP数据包，另一个保护RTCP数据包；每个DTLS-SRTP会话保护通过单个源/目标传输地址对的SRTP会话部分，如图2所示，与该对上使用的SSRC无关。当DTLS-SRTP会话保护RTP时，不需要从DTLS握手派生的SRTCP密钥，因此会丢弃这些密钥。当DTLS-SRTP会话正在保护RTCP时，不需要从DTLS握手中派生的SRTP密钥，并将其丢弃。
Client Server
(Sender) (Receiver)
(1) <----- DTLS ------> src/dst = a/b and b/a
------ SRTP ------> src/dst = a/b, uses client write keys
Client Server
(Sender) (Receiver)
(1) <----- DTLS ------> src/dst = a/b and b/a
------ SRTP ------> src/dst = a/b, uses client write keys
(2) <----- DTLS ------> src/dst = c/d and d/c
------ SRTCP -----> src/dst = c/d, uses client write keys
<----- SRTCP ------ src/dst = d/c, uses server write keys
(2) <----- DTLS ------> src/dst = c/d and d/c
------ SRTCP -----> src/dst = c/d, uses client write keys
<----- SRTCP ------ src/dst = d/c, uses server write keys
Figure 2: A DTLS-SRTP session protecting RTP (1) and another one protecting RTCP (2), showing the transport addresses and keys used.
图2:DTLS-SRTP会话保护RTP（1）和另一个保护RTCP（2），显示了使用的传输地址和密钥。
Because of the possibility of packet reordering, DTLS-SRTP implementations SHOULD store multiple SRTP keys sets during a rekey in order to avoid the need for receivers to drop packets for which they lack a key.
由于数据包重新排序的可能性，DTLS-SRTP实现应在重新密钥期间存储多个SRTP密钥集，以避免接收器丢弃缺少密钥的数据包。
The maximum_lifetime parameter in the SRTP protection profile indicates the maximum number of packets that can be protected with each single encryption and authentication key. (Note that, since RTP and RTCP are protected with independent keys, those protocols are counted separately for the purposes of determining when a key has reached the end of its lifetime.) Each profile defines its own limit. When this limit is reached, a new DTLS session SHOULD be used to establish replacement keys, and SRTP implementations MUST NOT use the existing keys for the processing of either outbound or inbound traffic.
SRTP保护配置文件中的maximum_lifetime参数表示每个加密和身份验证密钥可以保护的最大数据包数。（注意，由于RTP和RTCP受独立密钥的保护，因此这些协议被单独计算，以确定密钥何时到达其生命周期的末尾。）每个配置文件定义其自身的限制。当达到此限制时，应使用新的DTLS会话来建立替换密钥，SRTP实现不得将现有密钥用于处理出站或入站流量。
Once the DTLS handshake has completed, the peers can send RTP or RTCP over the newly created channel. We describe the transmission process first followed by the reception process.
DTLS握手完成后，对等方可以通过新创建的通道发送RTP或RTCP。我们首先描述传输过程，然后描述接收过程。
Within each RTP session, SRTP processing MUST NOT take place before the DTLS handshake completes.
在每个RTP会话中，在DTLS握手完成之前不得进行SRTP处理。
DTLS and TLS define a number of record content types. In ordinary TLS/DTLS, all data is protected using the same record encoding and mechanisms. When the mechanism described in this document is in effect, this is modified so that data written by upper-level protocol clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP rather than the standard TLS record encoding.
DTL和TLS定义了许多记录内容类型。在普通TLS/DTL中，所有数据都使用相同的记录编码和机制进行保护。当本文档中描述的机制生效时，将对其进行修改，以使DTLS的上层协议客户端写入的数据假定为RTP/RTP，并使用SRTP而不是标准TLS记录编码进行加密。
When a user of DTLS wishes to send an RTP packet in SRTP mode, it delivers it to the DTLS implementation as an ordinary application data write (e.g., SSL_write()). The DTLS implementation then invokes the processing described in RFC 3711, Sections 3 and 4. The resulting SRTP packet is then sent directly on the wire as a single datagram with no DTLS framing. This provides an encapsulation of the data that conforms to and interoperates with SRTP. Note that the RTP sequence number rather than the DTLS sequence number is used for these packets.
当DTLS用户希望以SRTP模式发送RTP数据包时，它会将其作为普通应用程序数据写入（例如SSL_write（））传递给DTLS实现。然后，DTLS实现调用RFC 3711第3节和第4节中描述的处理。然后，生成的SRTP数据包作为单个数据报直接在线路上发送，无DTLS帧。这提供了符合SRTP并与SRTP互操作的数据封装。请注意，这些数据包使用的是RTP序列号而不是DTLS序列号。
When DTLS-SRTP is used to protect an RTP session, the RTP receiver needs to demultiplex packets that are arriving on the RTP port. Arriving packets may be of types RTP, DTLS, or STUN [RFC5389]. If these are the only types of packets present, the type of a packet can be determined by looking at its first byte.
当DTLS-SRTP用于保护RTP会话时，RTP接收器需要对到达RTP端口的数据包进行解复用。到达的数据包可以是RTP、DTLS或STUN[RFC5389]类型。如果只有这些类型的数据包存在，那么可以通过查看数据包的第一个字节来确定数据包的类型。
The process for demultiplexing a packet is as follows. The receiver looks at the first byte of the packet. If the value of this byte is 0 or 1, then the packet is STUN. If the value is in between 128 and 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and RTP are being multiplexed over the same destination port). If the value is between 20 and 63 (inclusive), the packet is DTLS. This process is summarized in Figure 3.
分组解复用的过程如下所示。接收器查看数据包的第一个字节。如果该字节的值为0或1，则该数据包为STUN。如果该值介于128和191之间（包括128和191），则数据包为RTP（或RTCP，如果RTCP和RTP都在同一目标端口上多路传输）。如果该值介于20和63之间（包括20和63），则数据包为DTLS。图3总结了该过程。
+----------------+
| 127 < B < 192 -+--> forward to RTP
| |
packet --> | 19 < B < 64 -+--> forward to DTLS
| |
| B < 2 -+--> forward to STUN
+----------------+
+----------------+
| 127 < B < 192 -+--> forward to RTP
| |
packet --> | 19 < B < 64 -+--> forward to DTLS
| |
| B < 2 -+--> forward to STUN
+----------------+
Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm. Here the field B denotes the leading byte of the packet.
图3:DTLS-SRTP接收机的数据包解复用算法。这里，字段B表示数据包的前导字节。
If other packet types are to be multiplexed as well, implementors and/or designers SHOULD ensure that they can be demultiplexed from these three packet types.
如果其他包类型也要多路复用，那么实现者和/或设计者应该确保它们可以从这三种包类型中分离出来。
In some cases, there will be multiple DTLS-SRTP associations for a given SRTP endpoint. For instance, if Alice makes a call that is SIP forked to both Bob and Charlie, she will use the same local host/port pair for both of them, as shown in Figure 4, where XXX and YYY represent different DTLS-SRTP associations. (The SSRCs shown are the ones for data flowing to Alice.)
在某些情况下，给定SRTP端点将存在多个DTLS-SRTP关联。例如，如果Alice发出一个SIP分叉的呼叫给Bob和Charlie，她将为他们使用相同的本地主机/端口对，如图4所示，其中XXX和YYY表示不同的DTLS-SRTP关联。（显示的SSRC是用于流向Alice的数据的SSRC。）
Bob (192.0.2.1:6666)
/
/
/ SSRC=1
/ DTLS-SRTP=XXX
/
v
Alice (192.0.2.0:5555)
^
\
\ SSRC=2
\ DTLS-SRTP=YYY
\
\
Charlie (192.0.2.2:6666)
Bob (192.0.2.1:6666)
/
/
/ SSRC=1
/ DTLS-SRTP=XXX
/
v
Alice (192.0.2.0:5555)
^
\
\ SSRC=2
\ DTLS-SRTP=YYY
\
\
Charlie (192.0.2.2:6666)
Figure 4: RTP sessions with SIP forking.
图4：使用SIP分叉的RTP会话。
Because DTLS operates on the host/port quartet, the DTLS association will still complete correctly, with the foreign host/port pair being used, to distinguish the associations. However, in RTP the source host/port is not used and sessions are identified by the destination host/port and the SSRC. Thus, some mechanism is needed to determine which SSRCs correspond to which DTLS associations. The following method SHOULD be used.
由于DTLS在主机/端口四重奏上运行，DTLS关联仍将正确完成，同时使用外部主机/端口对来区分关联。但是，在RTP中不使用源主机/端口，会话由目标主机/端口和SSRC标识。因此，需要某种机制来确定哪些SSRC对应于哪些DTL关联。应使用以下方法。
For each local host/port pair, the DTLS-SRTP implementation maintains a table listing all the SSRCs it knows about and the DTLS-SRTP associations they correspond to. Initially, this table is empty. When an SRTP packet is received for a given RTP endpoint (destination IP/port pair), the following procedure is used:
对于每个本地主机/端口对，DTLS-SRTP实现维护一个表，列出它知道的所有SSRC以及它们对应的DTLS-SRTP关联。最初，这个表是空的。当接收到给定RTP端点（目标IP/端口对）的SRTP数据包时，使用以下过程：
1. If the SSRC is already known for that endpoint, then the corresponding DTLS-SRTP association and its keying material is used to decrypt and verify the packet. 2. If the SSRC is not known, then the receiver tries to decrypt it with the keying material corresponding to each DTLS-SRTP association for that endpoint. 3. If the decryption and verification succeeds (the authentication tag verifies), then an entry is placed in the table mapping the SSRC to that association. 4. If the decryption and verification fails, then the packet is silently discarded. 5. When a DTLS-SRTP association is closed (for instance, because the fork is abandoned), its entries MUST be removed from the mapping table.
1. 如果该端点的SSRC已知，则使用相应的DTLS-SRTP关联及其密钥材料来解密和验证数据包。2.如果SSRC未知，则接收器尝试使用对应于该端点的每个DTLS-SRTP关联的密钥材料对其进行解密。3.如果解密和验证成功（身份验证标签验证），则在将SSRC映射到该关联的表中放置一个条目。4.如果解密和验证失败，则该数据包将被自动丢弃。5.关闭DTLS-SRTP关联时（例如，因为放弃了fork），必须从映射表中删除其条目。
The average cost of this algorithm for a single SSRC is the decryption and verification time of a single packet times the number of valid DTLS-SRTP associations corresponding to a single receiving port on the host. In practice, this means the number of forks; so in the case shown in Figure 4, that would be two. This cost is only incurred once for any given SSRC, since afterwards that SSRC is placed in the map table and looked up immediately. As with normal RTP, this algorithm allows new SSRCs to be introduced by the source at any time. They will automatically be mapped to the correct DTLS association.
对于单个SSRC，该算法的平均成本是单个数据包的解密和验证时间乘以主机上单个接收端口对应的有效DTLS-SRTP关联数。实际上，这意味着叉子的数量；因此，在图4所示的情况下，这将是两个。对于任何给定的SSRC，该成本只发生一次，因为此后SSRC被放置在映射表中并立即查找。与普通RTP一样，该算法允许源随时引入新的SSRC。它们将自动映射到正确的DTLS关联。
Note that this algorithm explicitly allows multiple SSRCs to be sent from the same address/port pair. One way in which this can happen is an RTP translator. This algorithm will automatically assign the SSRCs to the correct associations. Note that because the SRTP packets are cryptographically protected, such a translator must either share keying material with one endpoint or refrain from modifying the packets in a way which would cause the integrity check to fail. This is a general property of SRTP and is not specific to DTLS-SRTP.
请注意，此算法明确允许从同一地址/端口对发送多个SSRC。一种可能发生这种情况的方法是RTP转换器。该算法将自动将SSRC分配给正确的关联。请注意，由于SRTP数据包受加密保护，此类转换器必须与一个端点共享密钥材料，或者避免以可能导致完整性检查失败的方式修改数据包。这是SRTP的一般属性，而不是DTLS-SRTP特有的属性。
There are two error cases that should be considered. First, if an SSRC collision occurs, then only the packets from the first source will be processed. When the packets from the second source arrive, the DTLS association with the first source will be used for decryption and verification, which will fail, and the packet will be discarded. This is consistent with [RFC3550], which permits the
应该考虑两种错误情况。首先，如果发生SSRC冲突，则仅处理来自第一个源的数据包。当来自第二个源的数据包到达时，与第一个源的DTLS关联将用于解密和验证，这将失败，数据包将被丢弃。这与[RFC3550]一致，后者允许
receiver to keep the packets from one source and discard those from the other. Of course the RFC 3550 SSRC collision detection and handling procedures MUST also be followed.
接收方保留来自一个源的数据包，并丢弃来自另一个源的数据包。当然，还必须遵守RFC 3550 SSRC碰撞检测和处理程序。
Second, there may be cases where a malfunctioning source is sending corrupt packets that cannot be decrypted and verified. In this case, the SSRC will never be entered into the mapping table because the decryption and verification always fails. Receivers MAY keep records of unmapped SSRCs that consistently fail decryption and verification and abandon attempts to process them once they reach some limit. That limit MUST be large enough to account for the effects of transmission errors. Entries MUST be pruned from this table when the relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD time out faster than that (we do not offer a hard recommendation but 10 to 30 seconds seems appropriate) in order to allow for the possibility that the peer implementation has been corrected.
第二，可能存在故障源发送无法解密和验证的损坏数据包的情况。在这种情况下，SSRC永远不会被输入到映射表中，因为解密和验证总是失败。接收者可以保留未映射的SSRC的记录，这些SSRC始终无法解密和验证，一旦达到某个限制，接收者就会放弃处理这些SSRC的尝试。该限制必须足够大，以考虑传输错误的影响。当删除相关的SRTP端点（例如，调用结束）时，必须从该表中删除条目，并且超时时间应快于该时间（我们不提供硬性建议，但10到30秒似乎合适），以便允许对等实现被纠正的可能性。
Rekeying in DTLS is accomplished by performing a new handshake over the existing DTLS channel. That is, the handshake messages are protected by the existing DTLS cipher suite. This handshake can be performed in parallel with data transport, so no interruption of the data flow is required. Once the handshake is finished, the newly derived set of keys is used to protect all outbound packets, both DTLS and SRTP.
DTLS中的密钥更新是通过在现有DTLS信道上执行新的握手来完成的。也就是说，握手消息受现有DTLS密码套件的保护。这种握手可以与数据传输并行执行，因此不需要中断数据流。握手完成后，新派生的密钥集将用于保护所有出站数据包，包括DTL和SRTP。
Because of packet reordering, packets protected by the previous set of keys can appear on the wire after the handshake has completed. To compensate for this fact, receivers SHOULD maintain both sets of keys for some time in order to be able to decrypt and verify older packets. The keys should be maintained for the duration of the maximum segment lifetime (MSL).
由于数据包重新排序，在握手完成后，受前一组密钥保护的数据包可能会出现在线路上。为了补偿这一事实，接收方应该在一段时间内维护这两组密钥，以便能够解密和验证较旧的数据包。密钥应在最大段生存期（MSL）内保持。
If an MKI is used, then the receiver should use the corresponding set of keys to process an incoming packet. If no matching MKI is present, the packet MUST be rejected. Otherwise, when a packet arrives after the handshake completed, a receiver SHOULD use the newly derived set of keys to process that packet unless there is an MKI. (If the packet was protected with the older set of keys, this fact will become apparent to the receiver as an authentication failure will occur.) If the authentication check on the packet fails and no MKI is being used, then the receiver MAY process the packet with the older set of keys. If that authentication check indicates that the packet is valid, the packet should be accepted; otherwise, the packet MUST be discarded and rejected.
如果使用MKI，那么接收器应该使用相应的密钥集来处理传入的数据包。如果不存在匹配的MKI，则必须拒绝数据包。否则，当数据包在握手完成后到达时，接收方应使用新派生的密钥集来处理该数据包，除非存在MKI。（如果数据包是用较旧的密钥集保护的，则当认证失败时，这一事实将对接收器变得明显。）如果数据包的认证检查失败且没有使用MKI，则接收器可以用较旧的密钥集处理数据包。如果认证检查表明数据包有效，则应接受该数据包；否则，必须丢弃并拒绝数据包。
Receivers MAY use the SRTP packet sequence number to aid in the selection of keys. After a packet has been received and authenticated with the new key set, any packets with sequence numbers that are greater will also have been protected with the new key set.
接收机可以使用SRTP分组序列号来帮助选择密钥。在接收到数据包并使用新密钥集进行身份验证后，序列号较大的任何数据包也将使用新密钥集进行保护。
Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only to protect unicast RTP sessions. This does not preclude its use with RTP mixers. For example, a conference bridge may use DTLS-SRTP to secure the communication to and from each of the participants in a conference. However, because each flow between an endpoint and a mixer has its own key, the mixer has to decrypt and then reencrypt the traffic for each recipient.
由于DTLS是一种点对点协议，DTLS-SRTP仅用于保护单播RTP会话。这并不排除与RTP混频器一起使用。例如，会议网桥可以使用DTLS-SRTP来保护与会议中的每个参与者之间的通信。但是，由于端点和混合器之间的每个流都有自己的密钥，因此混合器必须解密然后重新加密每个收件人的通信量。
A future specification may describe methods for sharing a single key between multiple DTLS-SRTP associations thus allowing conferencing systems to avoid the decrypt/reencrypt stage. However, any system in which the media is modified (e.g., for level balancing or transcoding) will generally need to be performed on the plaintext and will certainly break the authentication tag, and therefore will require a decrypt/reencrypt stage.
未来的规范可能描述用于在多个DTLS-SRTP关联之间共享单个密钥的方法，从而允许会议系统避免解密/重新加密阶段。然而，任何媒体被修改（例如，为了级别平衡或转码）的系统通常需要在明文上执行，并且肯定会破坏认证标签，因此将需要解密/重新加密阶段。
The use of multiple data protection framings negotiated in the same handshake creates some complexities, which are discussed here.
在同一握手中协商使用多个数据保护框架会造成一些复杂性，本文将对此进行讨论。
One concern here is that attackers might be able to implement a bid-down attack forcing the peers to use ordinary DTLS rather than SRTP. However, because the negotiation of this extension is performed in the DTLS handshake, it is protected by the Finished messages. Therefore, any bid-down attack is automatically detected, which reduces this to a denial-of-service attack -- which can be mounted by any attacker who can control the channel.
这里的一个问题是，攻击者可能会实施向下出价攻击，迫使对等方使用普通DTL而不是SRTP。但是，由于此扩展的协商是在DTLS握手中执行的，因此它受到已完成消息的保护。因此，会自动检测到任何出价下降攻击，从而将其减少为拒绝服务攻击——任何能够控制通道的攻击者都可以发起拒绝服务攻击。
Because two different framing formats are used, there is concern that an attacker could convince the receiver to treat an SRTP-framed RTP packet as a DTLS record (e.g., a handshake message) or vice versa. This attack is prevented by using different keys for Message Authentication Code (MAC) verification for each type of data. Therefore, this type of attack reduces to being able to forge a packet with a valid MAC, which violates a basic security invariant of both DTLS and SRTP.
由于使用了两种不同的帧格式，因此存在这样的问题：攻击者可能会说服接收方将SRTP帧RTP数据包视为DTLS记录（例如，握手消息），反之亦然。通过对每种类型的数据使用不同的密钥进行消息身份验证码（MAC）验证，可以防止这种攻击。因此，这种类型的攻击降低为能够伪造具有有效MAC的数据包，这违反了DTL和SRTP的基本安全不变量。
As an additional defense against injection into the DTLS handshake channel, the DTLS record type is included in the MAC. Therefore, an SRTP record would be treated as an unknown type and ignored. (See Section 6 of [RFC5246].)
作为防止注入DTLS握手信道的额外防御措施，MAC中包括DTLS记录类型。因此，SRTP记录将被视为未知类型并被忽略。（见[RFC5246]第6节）
As described in Section 5.1.1, the SRTP and DTLS sequence number spaces are distinct. This means that it is not possible to unambiguously order a given DTLS control record with respect to an SRTP packet. In general, this is relevant in two situations: alerts and rehandshake.
如第5.1.1节所述，SRTP和DTLS序列号空间是不同的。这意味着不可能针对SRTP数据包对给定的DTLS控制记录进行明确的排序。通常，这与两种情况有关：警报和重新握手。
Because DTLS handshake and change_cipher_spec messages share the same sequence number space as alerts, they can be ordered correctly. Because DTLS alerts are inherently unreliable and SHOULD NOT be generated as a response to data packets, reliable sequencing between SRTP packets and DTLS alerts is not an important feature. However, implementations that wish to use DTLS alerts to signal problems with the SRTP encoding SHOULD simply act on alerts as soon as they are received and assume that they refer to the temporally contiguous stream. Such implementations MUST check for alert retransmission and discard retransmitted alerts to avoid overreacting to replay attacks.
由于DTL握手和更改密码规范消息与警报共享相同的序列号空间，因此它们可以正确排序。由于DTLS警报本质上是不可靠的，不应作为对数据包的响应生成，因此SRTP数据包和DTLS警报之间的可靠排序不是一项重要功能。然而，希望使用DTLS警报来表示SRTP编码问题的实现应该在收到警报后立即对其进行操作，并假设它们指的是时间上连续的流。此类实现必须检查警报重传并丢弃重传的警报，以避免对重播攻击作出过度反应。
Because the rehandshake transition algorithm specified in Section 5.2 requires trying multiple sets of keys if no MKI is used, it slightly weakens the authentication. For instance, if an n-bit MAC is used and k different sets of keys are present, then the MAC is weakened by log_2(k) bits to n - log_2(k). In practice, since the number of keys used will be very small and the MACs in use are typically strong (the default for SRTP is 80 bits), the decrease in security involved here is minimal.
由于第5.2节中指定的rehandshake转换算法在未使用MKI的情况下需要尝试多组密钥，因此会略微削弱身份验证。例如，如果使用一个n位MAC并且存在k组不同的密钥，那么MAC将被log_2（k）位削弱为n-log_2（k）。实际上，由于使用的密钥数量非常少，并且使用的MAC通常很强（SRTP的默认值为80位），因此此处涉及的安全性降低最小。
Another concern here is that this algorithm slightly increases the work factor on the receiver because it needs to attempt multiple validations. However, again, the number of potential keys will be very small (and the attacker cannot force it to be larger) and this technique is already used for rollover counter management, so the authors do not consider this to be a serious flaw.
这里的另一个问题是，该算法略微增加了接收器的工作系数，因为它需要尝试多次验证。然而，同样，潜在密钥的数量将非常小（攻击者不能强迫它更大），并且这种技术已经用于翻转计数器管理，因此作者不认为这是一个严重缺陷。
An attacker can impose computational costs on the receiver by sending superficially valid SRTP packets that do not decrypt correctly. In general, encryption algorithms are so fast that this cost is extremely small compared to the bandwidth consumed. The SSRC-DTLS mapping algorithm described in Section 5.1.2 gives the attacker a slight advantage here because he can force the receiver to do more then one decryption per packet. However, this advantage is modest because the number of decryptions that the receiver does is limited by the number of associations he has corresponding to a given destination host/port, which is typically quite small. For comparison, a single 1024-bit RSA private key operation (the typical minimum cost to establish a DTLS-SRTP association) is hundreds of times as expensive as decrypting an SRTP packet.
攻击者可以通过发送未正确解密的表面有效的SRTP数据包，给接收方带来计算成本。一般来说，加密算法速度非常快，与所消耗的带宽相比，这一成本非常小。第5.1.2节中描述的SSRC-DTLS映射算法在这里为攻击者提供了一点优势，因为他可以强制接收器对每个数据包进行不止一次的解密。然而，这一优势是适度的，因为接收器所做的解密数量受到其与给定目标主机/端口相对应的关联数量的限制，该关联数量通常非常小。相比之下，单个1024位RSA私钥操作（建立DTLS-SRTP关联的典型最低成本）的成本是解密SRTP数据包的数百倍。
Implementations can detect this form of attack by keeping track of the number of SRTP packets that are observed with unknown SSRCs and that fail the authentication tag check. If under such attack, implementations SHOULD prioritize decryption and verification of packets that either have known SSRCs or come from source addresses that match those of peers with which it has DTLS-SRTP associations.
实现可以通过跟踪未知SSRC观察到的且未通过身份验证标记检查的SRTP数据包的数量来检测这种形式的攻击。如果受到这种攻击，实现应该优先解密和验证已知SSRC或来自与DTLS-SRTP关联的对等方的源地址相匹配的源地址的数据包。
This specification defines new tokens to describe the protocol used in SDP media descriptions ("m=" lines and their associated parameters). The new values defined for the proto field are:
本规范定义了新的令牌来描述SDP媒体描述中使用的协议（“m=”行及其相关参数）。为proto字段定义的新值为：
o When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over DTLS with the Datagram Congestion Control Protocol (DCCP), then the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF respectively.
o 当使用数据报拥塞控制协议（DCCP）通过DTLS传输RTP/SAVP或RTP/SAVP[RFC5124]流时，令牌应分别为DCCP/TLS/RTP/SAVP或DCCP/TLS/RTP/SAVP。
o When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF respectively.
o 当使用UDP通过DTLS传输RTP/SAVP或RTP/SAVPF流时，令牌应分别为UDP/TLS/RTP/SAVP或UDP/TLS/RTP/SAVPF。
The "fmt" parameter SHALL be as defined for RTP/SAVP.
“fmt”参数应符合RTP/SAVP的定义。
See [RFC5763] for how to use offer/answer with DTLS-SRTP.
请参阅[RFC5763]了解如何将提供/应答与DTLS-SRTP结合使用。
This document does not specify how to protect RTP data transported over TCP. Potential approaches include carrying the RTP over TLS over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that in this document over TCP, either via TLS or DTLS, with DTLS being used for consistency between reliable and unreliable transports. In
本文档未指定如何保护通过TCP传输的RTP数据。潜在的方法包括通过TCP通过TLS传输RTP（参见[SRTP-NOT-MAND]），或通过TLS或DTL使用类似于本文件中通过TCP传输的机制，DTL用于确保可靠和不可靠传输之间的一致性。在里面
the latter case, it would be necessary to profile DTLS so that fragmentation and retransmissions no longer occurred. In either case, a new document would be required.
在后一种情况下，有必要分析DTL，以便不再发生碎片和重传。无论哪种情况，都需要一份新的文件。
This document adds a new extension for DTLS, in accordance with
[RFC5246]:
enum { use_srtp (14) } ExtensionType;
This document adds a new extension for DTLS, in accordance with
[RFC5246]:
enum { use_srtp (14) } ExtensionType;
This extension MUST only be used with DTLS, and not with TLS [RFC4572], which specifies that TLS can be used over TCP but does not address TCP for RTP/SAVP.
此扩展只能与DTL一起使用，而不能与TLS[RFC4572]一起使用，后者指定TLS可以通过TCP使用，但不能为RTP/SAVP寻址TCP。
Section 4.1.2 requires that all SRTPProtectionProfile values be defined by RFC 5226 "Specification Required". IANA has created a DTLS SRTPProtectionProfile registry initially populated with values from Section 4.1.2 of this document. Future values MUST be allocated via the "Specification Required" profile of [RFC5226].
第4.1.2节要求所有SRTPProtectionProfile值由RFC 5226“所需规范”定义。IANA已创建了DTLS SRTPProtectionProfile注册表，最初使用本文档第4.1.2节中的值填充。未来值必须通过[RFC5226]的“所需规格”配置文件进行分配。
This specification updates the "Session Description Protocol (SDP) Parameters" registry as defined in Section 8.2.2 of [RFC4566]. Specifically, it adds the following values to the table for the "proto" field.
本规范更新了[RFC4566]第8.2.2节中定义的“会话描述协议（SDP）参数”注册表。具体来说，它将以下值添加到“proto”字段的表中。
Type SDP Name Reference
---- ------------------ ---------
proto UDP/TLS/RTP/SAVP [RFC5764]
proto DCCP/TLS/RTP/SAVP [RFC5764]
Type SDP Name Reference
---- ------------------ ---------
proto UDP/TLS/RTP/SAVP [RFC5764]
proto DCCP/TLS/RTP/SAVP [RFC5764]
proto UDP/TLS/RTP/SAVPF [RFC5764]
proto DCCP/TLS/RTP/SAVPF [RFC5764]
proto UDP/TLS/RTP/SAVPF [RFC5764]
proto DCCP/TLS/RTP/SAVPF [RFC5764]
IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS Extractor Label Registry to correspond to this specification.
IANA已在TLS提取器标签注册表中注册“提取器-dtls\U srtp”值，以符合本规范。
Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen, Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing, and Ben Campbell for input, discussions, and guidance. Pasi Eronen provided Figure 1.
特别感谢Flemming Andreasen、Francois Audet、Pasi Eronen、Roni Even、Jason Fischl、Cullen Jennings、Colin Perkins、Dan Wing和Ben Campbell的投入、讨论和指导。Pasi Eronen提供了图1。
[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月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 49612007年7月。
[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月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 57052010年3月。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路传输RTP数据和控制数据包”，RFC 5761，2010年4月。
[DTLS1.2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", Work in Progress, October 2009.
[DTLS1.2]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，正在进行的工作，2009年10月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4572]Lennox，J.，“会话描述协议（SDP）中传输层安全（TLS）协议上的面向连接的媒体传输”，RFC 4572，2006年7月。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 51242008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010.
[RFC5763]Fischl，J.，Tschofenig，H.，和E.Rescorla，“使用数据报传输层安全性（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，2010年5月。
[SRTP-NOT-MAND] Perkins, C. and M. Westerlund, "Why RTP Does Not Mandate a Single Security Mechanism", Work in Progress, January 2010.
[SRTP-NOT-MAND]Perkins，C.和M.Westerlund，“为什么RTP不要求单一安全机制”，正在进行的工作，2010年1月。
This section provides a brief overview of Datagram TLS (DTLS) for those who are not familiar with it. DTLS is a channel security protocol based on the well-known Transport Layer Security (TLS) [RFC5246] protocol. Where TLS depends on a reliable transport channel (typically TCP), DTLS has been adapted to support unreliable transports such as UDP. Otherwise, DTLS is nearly identical to TLS and generally supports the same cryptographic mechanisms.
本节为不熟悉数据报TLS（DTL）的人提供了一个简要概述。DTLS是基于众所周知的传输层安全（TLS）[RFC5246]协议的信道安全协议。当TLS依赖于可靠的传输通道（通常是TCP）时，DTL已被调整为支持不可靠的传输，如UDP。否则，DTLS几乎与TLS相同，并且通常支持相同的加密机制。
Each DTLS association begins with a handshake exchange (shown below) during which the peers authenticate each other and negotiate algorithms, modes, and other parameters and establish shared keying material, as shown below. In order to support unreliable transport, each side maintains retransmission timers to provide reliable delivery of these messages. Once the handshake is completed, encrypted data may be sent.
每个DTLS关联从握手交换（如下所示）开始，在此过程中，对等方相互验证，协商算法、模式和其他参数，并建立共享密钥材料，如下所示。为了支持不可靠的传输，每一方都维护重传计时器以提供这些消息的可靠传递。一旦握手完成，就可以发送加密数据。
Client Server
客户端服务器
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
'*' indicates messages that are not always sent.
“*”表示并非始终发送的邮件。
Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]).
图5：基本DTLS握手交换（在[RFC4347]之后）。
Application data is protected by being sent as a series of DTLS "records". These records are independent and can be processed correctly even in the face of loss or reordering. In DTLS-SRTP, this record protocol is replaced with SRTP [RFC3711]
应用程序数据通过作为一系列DTL“记录”发送而受到保护。这些记录是独立的，即使在丢失或重新排序的情况下也可以正确处理。在DTLS-SRTP中，此记录协议替换为SRTP[RFC3711]
Standard practice for security protocols such as TLS, DTLS, and SSH, which do inline key management, is to create a separate security association for each underlying network channel (TCP connection, UDP host/port quartet, etc.). This has dual advantages of simplicity and independence of the security contexts for each channel.
执行内联密钥管理的安全协议（如TLS、DTLS和SSH）的标准实践是为每个底层网络通道（TCP连接、UDP主机/端口四方等）创建单独的安全关联。这具有简单性和每个通道的安全上下文独立性的双重优势。
Three concerns have been raised about the overhead of this strategy in the context of RTP security. The first concern is the additional performance overhead of doing a separate public key operation for each channel. The conventional procedure here (used in TLS and DTLS) is to establish a master context that can then be used to derive fresh traffic keys for new associations. In TLS/DTLS, this is called "session resumption" and can be transparently negotiated between the peers.
在RTP安全性的背景下，对该策略的开销提出了三个关注点。第一个问题是为每个通道执行单独公钥操作的额外性能开销。这里的常规过程（在TLS和DTL中使用）是建立主上下文，然后可以使用主上下文为新关联派生新的流量密钥。在TLS/DTLS中，这称为“会话恢复”，可以在对等方之间透明地协商。
The second concern is network bandwidth overhead for the establishment of subsequent connections and for rehandshake (for rekeying) for existing connections. In particular, there is a concern that the channels will have very narrow capacity requirements allocated entirely to media that will be overflowed by the rehandshake. Measurements of the size of the rehandshake (with resumption) in TLS indicate that it is about 300-400 bytes if a full selection of cipher suites is offered. (The size of a full handshake is approximately 1-2 kilobytes larger because of the certificate and keying material exchange.)
第二个关注点是建立后续连接和为现有连接重新设置密钥（用于重新设置密钥）的网络带宽开销。尤其值得关注的是，这些频道的容量需求将非常狭窄，完全分配给媒体，而这些媒体将因重新播放而溢出。对TLS中的rehandshake（带恢复）大小的测量表明，如果提供完整的密码套件选择，它大约为300-400字节。（由于证书和密钥交换，完全握手的大小大约要大1-2k字节。）
The third concern is the additional round-trips associated with establishing the second, third, ... channels. In TLS/DTLS, these can all be done in parallel, but in order to take advantage of session resumption they should be done after the first channel is established. For two channels, this provides a ladder diagram something like this (parenthetical numbers are media channel numbers)
第三个问题是与建立第二、第三。。。频道。在TLS/DTL中，这些都可以并行完成，但是为了利用会话恢复，它们应该在建立第一个通道之后完成。对于两个频道，这提供了一个类似这样的梯形图（括号中的数字是媒体频道编号）
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
<- ClientHello (2)
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
<- ClientHello (2)
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Figure 6: Parallel DTLS-SRTP negotiations.
图6：并行DTLS-SRTP协商。
So, there is an additional 1 RTT (round-trip time) after Channel 1 is ready before Channel 2 is ready. If the peers are potentially willing to forego resumption, they can interlace the handshakes, like so:
因此，在通道1准备就绪之后，通道2准备就绪之前，还有一个额外的1 RTT（往返时间）。如果对等方可能愿意放弃恢复，他们可以交错握手，如下所示：
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
<- ClientHello (2)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Alice Bob
-------------------------------------------
<- ClientHello (1)
ServerHello (1) ->
Certificate (1)
ServerHelloDone (1)
<- ClientKeyExchange (1)
ChangeCipherSpec (1)
Finished (1)
<- ClientHello (2)
ChangeCipherSpec (1)->
Finished (1)->
<--- Channel 1 ready
ServerHello (2) ->
ChangeCipherSpec(2)->
Finished(2) ->
<- ChangeCipherSpec (2)
Finished (2)
<--- Channel 2 ready
Figure 7: Interlaced DTLS-SRTP negotiations.
图7：交错DTLS-SRTP协商。
In this case, the channels are ready contemporaneously, but if a message in handshake (1) is lost, then handshake (2) requires either a full rehandshake or that Alice be clever and queue the resumption attempt until the first handshake completes. Note that just dropping the packet works as well, since Bob will retransmit.
在这种情况下，通道同时准备就绪，但如果握手（1）中的消息丢失，则握手（2）需要完全重新握手，或者Alice聪明地等待恢复尝试，直到第一次握手完成。请注意，由于Bob将重新传输数据包，因此丢弃数据包同样有效。
Authors' Addresses
作者地址
David McGrew Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95305 USA
David McGrew思科系统公司，麦卡锡大道510号。美国加利福尼亚州米尔皮塔斯95305
EMail: mcgrew@cisco.com
EMail: mcgrew@cisco.com
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com