Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 7202 University of Glasgow
Category: Informational M. Westerlund
ISSN: 2070-1721 Ericsson
April 2014
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 7202 University of Glasgow
Category: Informational M. Westerlund
ISSN: 2070-1721 Ericsson
April 2014
Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution
保护RTP框架：为什么RTP不要求单一媒体安全解决方案
Abstract
摘要
This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol (RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture.
本备忘录讨论了确保实时多媒体会话安全的问题。它还解释了为什么实时传输协议（RTP）和相关的RTP控制协议（RTCP）不要求单一的媒体安全机制。这与未来RTP扩展的设计人员和审查人员相关，以确保授权使用适当的安全机制，并以符合RTP体系结构的方式指定任何此类机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7202.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7202.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3
3. RTP Media Security . . . . . . . . . . . . . . . . . . . . . 4
4. RTP Session Establishment and Key Management . . . . . . . . 5
5. On the Requirement for Strong Security in Framework Protocols 5
6. Securing the RTP Framework . . . . . . . . . . . . . . . . . 6
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3
3. RTP Media Security . . . . . . . . . . . . . . . . . . . . . 4
4. RTP Session Establishment and Key Management . . . . . . . . 5
5. On the Requirement for Strong Security in Framework Protocols 5
6. Securing the RTP Framework . . . . . . . . . . . . . . . . . 6
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . . 8
The Real-time Transport Protocol (RTP) [RFC3550] is widely used for voice over IP, Internet television, video conferencing, and other real-time and streaming media applications. Despite this use, the basic RTP specification provides only limited options for media security and defines no standard key exchange mechanism. Rather, a number of extensions are defined that can provide confidentiality and authentication of RTP media streams and RTP Control Protocol (RTCP) messages. Other mechanisms define key exchange protocols. This memo outlines why it is appropriate that multiple extension mechanisms are defined rather than mandating a single security and keying mechanism for all users of RTP.
实时传输协议（RTP）[RFC3550]广泛用于IP语音、互联网电视、视频会议以及其他实时和流媒体应用。尽管如此，基本RTP规范只提供了有限的媒体安全选项，并且没有定义标准的密钥交换机制。相反，定义了许多扩展，可以提供RTP媒体流和RTP控制协议（RTCP）消息的机密性和身份验证。其他机制定义密钥交换协议。本备忘录概述了为什么定义多个扩展机制而不是为RTP的所有用户指定单一的安全和密钥机制是合适的。
The IETF policy "Strong Security Requirements for Internet Engineering Task Force Standard Protocols" [RFC3365] (the so-called "Danvers Doctrine") states that "we MUST implement strong security in all protocols to provide for the all too frequent day when the protocol comes into widespread use in the global Internet". The security mechanisms defined for use with RTP allow these requirements
IETF政策“互联网工程任务组标准协议的强大安全要求”[RFC3365]（所谓的“丹弗斯原则”）规定，“我们必须在所有协议中实施强大的安全性，以应对协议在全球互联网中广泛使用的那一天”。定义用于RTP的安全机制允许这些要求
to be met. However, since RTP is a protocol framework that is suitable for a wide variety of use cases, there is no single security mechanism that is suitable for every scenario. This memo outlines why this is the case and discusses how users of RTP can meet the requirement for strong security.
有待满足。然而，由于RTP是一个协议框架，适用于各种各样的用例，因此没有一种安全机制适用于每种场景。本备忘录概述了这种情况的原因，并讨论了RTP用户如何满足强安全性的要求。
This document provides high-level guidance on how to handle security issues for the various types of components within the RTP framework as well as the role of the service or application using RTP to ensure strong security is implemented. This document does not provide the guidance that an individual implementer, or even specifier of an RTP application, really can use to determine what security mechanism they need to use; that is not intended with this document.
本文档提供了关于如何处理RTP框架内各种类型组件的安全问题的高级指导，以及使用RTP的服务或应用程序的角色，以确保实现强大的安全性。本文档不提供单个实现者，甚至RTP应用程序的说明符，真正可以用来确定他们需要使用什么安全机制的指导；这不是本文件的目的。
A non-exhaustive list of the RTP security options available at the time of this writing is outlined in [RFC7201]. This document gives an overview of the available RTP solutions and provides guidance on their applicability for different application domains. It also attempts to provide an indication of actual and intended usage at the time of writing as additional input to help with considerations such as interoperability, availability of implementations, etc.
[RFC7201]概述了撰写本文时可用的RTP安全选项的非详尽列表。本文档概述了可用的RTP解决方案，并就其在不同应用领域的适用性提供了指导。它还试图在撰写本文时提供实际和预期用途的指示，作为额外的输入，以帮助考虑互操作性、实现的可用性等问题。
The range of application and deployment scenarios where RTP has been used includes, but is not limited to, the following:
使用RTP的应用和部署场景范围包括但不限于以下内容：
o Point-to-point voice telephony;
o 点对点语音电话；
o Point-to-point video conferencing and telepresence;
o 点对点视频会议和远程呈现；
o Centralized group video conferencing and telepresence, using a Multipoint Conference Unit (MCU) or similar central middlebox;
o 使用多点会议单元（MCU）或类似中央中间盒的集中式群组视频会议和远程呈现；
o Any Source Multicast (ASM) video conferencing using the lightweight sessions model (e.g., the Mbone conferencing tools);
o 使用轻量级会话模型（如Mbone会议工具）的任何源多播（ASM）视频会议；
o Point-to-point streaming audio and/or video (e.g., on-demand TV or movie streaming);
o 点对点流媒体音频和/或视频（例如，点播电视或电影流媒体）；
o Source-Specific Multicast (SSM) streaming to large receiver groups (e.g., IPTV streaming by residential ISPs or the Third Generation Partnership Project (3GPP) Multimedia/Broadcast Multicast Service [T3GPP.26.346]);
o 源特定多播（SSM）流到大型接收组（例如，住宅ISP的IPTV流或第三代合作伙伴项目（3GPP）多媒体/广播多播服务[T3GPP.26.346]）；
o Replicated unicast streaming to a group of receivers;
o 复制到一组接收器的单播流；
o Interconnecting components in music production studios and video editing suites;
o 音乐制作工作室和视频编辑套件中的互连组件；
o Interconnecting components of distributed simulation systems; and
o 分布式仿真系统的互连组件；和
o Streaming real-time sensor data (e.g., electronic Very Long Baseline Interferometry (e-VLBI) radio astronomy).
o 实时传感器数据流（例如电子甚长基线干涉测量（e-VLBI）射电天文学）。
As can be seen, these scenarios vary from point-to-point sessions to very large multicast groups, from interactive to non-interactive, and from low bandwidth (kilobits per second) telephony to high bandwidth (multiple gigabits per second) video and data streaming. While most of these applications run over UDP [RFC0768], some use TCP [RFC0793] [RFC4614] or the Datagram Congestion Control Protocol (DCCP) [RFC4340] as their underlying transport. Some run on highly reliable optical networks, while others use low-rate unreliable wireless networks. Some applications of RTP operate entirely within a single trust domain, while others run interdomain with untrusted (and, in some cases, potentially unknown) users. The range of scenarios is wide and growing both in number and in heterogeneity.
可以看出，这些场景各不相同，从点对点会话到非常大的多播组，从交互式到非交互式，从低带宽（千比特每秒）电话到高带宽（千比特每秒）视频和数据流。虽然大多数应用程序都在UDP[RFC0768]上运行，但有些应用程序使用TCP[RFC0793][RFC4614]或数据报拥塞控制协议（DCCP）[RFC4340]作为其底层传输。一些运行在高度可靠的光网络上，而另一些使用低速率不可靠的无线网络。RTP的一些应用程序完全在一个信任域内运行，而其他应用程序则在域间运行不受信任（在某些情况下，可能是未知的）用户。情景的范围很广，并且在数量和异质性方面都在增长。
The wide range of application scenarios where RTP is used has led to the development of multiple solutions for securing RTP media streams and RTCP control messages, considering different requirements.
考虑到不同的需求，使用RTP的广泛应用场景导致了多种解决方案的开发，用于保护RTP媒体流和RTCP控制消息。
Perhaps the most widely applicable of these security options is the Secure RTP (SRTP) framework [RFC3711]. This is an application-level media security solution, encrypting the media payload data (but not the RTP headers) to provide confidentiality and supporting source origin authentication as an option. SRTP was carefully designed to be low overhead, including operating on links subject to RTP header compression, and to support the group communication and third-party performance monitoring features of RTP across a range of networks.
也许这些安全选项中应用最广泛的是安全RTP（SRTP）框架[RFC3711]。这是一个应用程序级媒体安全解决方案，加密媒体有效负载数据（但不加密RTP报头）以提供机密性，并作为一个选项支持源站身份验证。SRTP被精心设计为低开销，包括在受到RTP报头压缩的链路上操作，并支持RTP在一系列网络中的组通信和第三方性能监控功能。
SRTP is not the only media security solution for RTP, however, and alternatives can be more appropriate in some scenarios, perhaps due to ease of integration with other parts of the complete system. In addition, SRTP does not address all possible security requirements, and other solutions are needed in cases where SRTP is not suitable. For example, ISMACryp payload-level confidentiality [ISMACryp2] is appropriate for some types of streaming video application, but is not suitable for voice telephony, and uses features that are not provided by SRTP.
然而，SRTP并不是RTP的唯一媒体安全解决方案，在某些情况下，替代方案可能更合适，可能是因为易于与整个系统的其他部分集成。此外，SRTP不能满足所有可能的安全需求，在SRTP不适用的情况下，需要其他解决方案。例如，ISMACryp有效负载级别机密性[ISMACryp2]适用于某些类型的流式视频应用程序，但不适用于语音电话，并使用SRTP未提供的功能。
The range of available RTP security options, and their applicability to different scenarios, is outlined in [RFC7201]. At the time of this writing, there is no media security protocol that is appropriate for all the environments where RTP is used. Multiple RTP media security protocols are expected to remain in wide use for the foreseeable future.
[RFC7201]概述了可用RTP安全选项的范围及其对不同场景的适用性。在撰写本文时，没有适用于使用RTP的所有环境的媒体安全协议。在可预见的未来，多种RTP媒体安全协议有望继续广泛使用。
A range of different protocols for RTP session establishment and key exchange exist, matching the diverse range of use cases for the RTP framework. These mechanisms can be split into two categories: those that operate in band on the media path and those that are out of band and operate as part of the session establishment signaling channel. The requirements for these two classes of solutions are different, and a wide range of solutions have been developed in this space.
存在一系列不同的RTP会话建立和密钥交换协议，与RTP框架的不同用例相匹配。这些机制可分为两类：在媒体路径上带内运行的机制和带外作为会话建立信令信道一部分运行的机制。这两类解决方案的要求是不同的，在这一领域开发了广泛的解决方案。
A more-detailed survey of requirements for media security management protocols can be found in [RFC5479]. As can be seen from that memo, the range of use cases is wide, and there is no single key management protocol that is appropriate for all scenarios. The solutions have been further diversified by the existence of infrastructure elements, such as authentication systems, that are tied to the key management. The most important and widely used keying options for RTP sessions at the time of this writing are described in [RFC7201].
有关介质安全管理协议要求的更详细调查，请参见[RFC5479]。从该备忘录中可以看出，用例的范围很广，并且没有适用于所有场景的单一密钥管理协议。由于存在与密钥管理相关的基础设施元素，如身份验证系统，解决方案进一步多样化。[RFC7201]中描述了撰写本文时RTP会话最重要和最广泛使用的键控选项。
The IETF requires that all protocols provide a strong, mandatory-to-implement security solution [RFC3365]. This is essential for the overall security of the Internet to ensure that all implementations of a protocol can interoperate in a secure way. Framework protocols offer a challenge for this mandate, however, since they are designed to be used by different classes of applications in a wide range of different environments. The different use cases for the framework have different security requirements, and implementations designed for different environments are generally not expected to interwork.
IETF要求所有协议都提供一个强大的强制安全解决方案[RFC3365]。这对于互联网的整体安全至关重要，以确保协议的所有实现都能以安全的方式进行互操作。然而，框架协议对这项任务提出了挑战，因为它们被设计用于各种不同环境中的不同类别的应用程序。该框架的不同用例具有不同的安全性要求，并且为不同环境设计的实现通常不会相互作用。
RTP is an example of a framework protocol with wide applicability. The wide range of scenarios described in Section 2 show the issues that arise in mandating a single security mechanism for this type of framework. It would be desirable if a single media security solution, and a single key management solution, could be developed that is suitable for applications across this range of use scenarios. The authors are not aware of any such solution, however, and believe it is unlikely that any such solution will be developed. In part, this is because applications in the different domains are not intended to interwork, so there is no incentive to develop a single
RTP是具有广泛适用性的框架协议的一个示例。第2节中描述的各种场景显示了为此类框架指定单一安全机制时出现的问题。如果能够开发出一个单一的媒体安全解决方案和一个单一的密钥管理解决方案，并且适用于这种使用场景范围内的应用程序，这将是理想的。然而，作者不知道有任何这样的解决方案，并且认为不太可能开发出任何这样的解决方案。在某种程度上，这是因为不同领域中的应用程序不打算互通，因此没有开发单一应用程序的动机
mechanism. More importantly, though, the security requirements for the different usage scenarios vary widely, and an appropriate security mechanism in one scenario simply does not work for some other scenarios.
机械装置但是，更重要的是，不同使用场景的安全性要求差异很大，一个场景中的适当安全机制根本不适用于其他一些场景。
For a framework protocol, it appears that the only sensible solution to the strong security requirement of [RFC3365] is to develop and use building blocks for the basic security services of confidentiality, integrity protection, authorization, authentication, and so on. When new uses for the framework protocol arise, they need to be studied to determine if the existing security building blocks can satisfy the requirements, or if new building blocks need to be developed.
对于一个框架协议，似乎对[RFC3365]强大的安全需求唯一合理的解决方案是为保密性、完整性保护、授权、身份验证等基本安全服务开发和使用构建块。当框架协议出现新用途时，需要对其进行研究，以确定现有的安全构建块是否能够满足要求，或者是否需要开发新的构建块。
Therefore, when considering the strong and mandatory-to-implement security mechanism for a specific class of applications, one has to consider what security building blocks need to be integrated, or if any new mechanisms need to be defined to address specific issues relating to this new class of application. To maximize interoperability, it is important that common media security and key management mechanisms are defined for classes of application with similar requirements. The IETF needs to participate in this selection of security building blocks for each class of applications that use the protocol framework and are expected to interoperate, in cases where the IETF has the appropriate knowledge of the class of applications.
因此，当考虑到对特定应用程序实施安全机制的强大和强制时，必须考虑安全构建块需要集成什么，或者是否需要定义任何新机制来解决与此新类应用有关的特定问题。为了最大限度地提高互操作性，必须为具有类似需求的应用程序类定义通用的媒体安全和密钥管理机制。IETF需要参与选择使用协议框架的每类应用程序的安全构建块，并且在IETF具备该类应用程序的适当知识的情况下，IETF需要参与互操作。
The IETF requires that protocols specify mandatory-to-implement (MTI) strong security [RFC3365]. This applies to the specification of each interoperable class of application that makes use of RTP. However, RTP is a framework protocol, so the arguments made in Section 5 also apply. Given the variability of the classes of application that use RTP, and the variety of the currently available security mechanisms described in [RFC7201], no one set of MTI security options can realistically be specified that apply to all classes of RTP applications.
IETF要求协议规定强制实施（MTI）强安全[RFC3365]。这适用于使用RTP的每个可互操作应用程序类的规范。然而，RTP是一个框架协议，因此第5节中的参数也适用。考虑到使用RTP的应用程序类别的多样性，以及[RFC7201]中描述的当前可用安全机制的多样性，无法实际指定适用于所有RTP应用程序类别的一组MTI安全选项。
Documents that define an interoperable class of applications using RTP are subject to [RFC3365], and thus need to specify MTI security mechanisms. This is because such specifications do fully specify interoperable applications that use RTP. Examples of such documents under development in the IETF at the time of this writing are "WebRTC Security Architecture" [WebRTC-SEC] and "Real Time Streaming Protocol 2.0 (RTSP)" [RTSP]. It is also expected that a similar document will be produced for voice-over-IP applications using SIP and RTP.
使用RTP定义可互操作应用程序类的文档受[RFC3365]约束，因此需要指定MTI安全机制。这是因为这些规范确实完全指定了使用RTP的可互操作应用程序。撰写本文时，IETF正在开发的此类文件的示例有“WebRTC安全体系结构”[WebRTC SEC]和“实时流协议2.0（RTSP）”[RTSP]。预计还将为使用SIP和RTP的IP语音应用程序生成类似的文档。
The RTP framework includes several extension points. Some extensions can significantly change the behavior of the protocol to the extent that applications using the extension form a separate interoperable class of applications to those that have not been extended. Other extension points are defined in such a manner that they can be used (largely) independently of the class of applications using RTP. Two important extension points that are independent of the class of applications are RTP payload formats and RTP profiles.
RTP框架包括几个扩展点。一些扩展可以显著地改变协议的行为，以至于使用扩展的应用程序形成一个独立的可互操作的应用程序类，而不是那些尚未扩展的应用程序。其他扩展点的定义方式是，它们可以（很大程度上）独立于使用RTP的应用程序类使用。独立于应用程序类别的两个重要扩展点是RTP有效负载格式和RTP概要文件。
An RTP payload format defines how the output of a media codec can be used with RTP. At the time of this writing, there are over 70 RTP payload formats defined in published RFCs, with more in development. It is appropriate for an RTP payload format to discuss the specific security implications of using that media codec with RTP. However, an RTP payload format does not specify an interoperable class of applications that use RTP since, in the vast majority of cases, a media codec and its associated RTP payload format can be used with many different classes of application. As such, an RTP payload format is neither secure in itself nor something to which [RFC3365] applies. Future RTP payload format specifications need to explicitly state this and include a reference to this memo for explanation. It is not appropriate for an RTP payload format to mandate the use of SRTP [RFC3711], or any other security building blocks, since that RTP payload format might be used by different classes of application that use RTP and that have different security requirements.
RTP有效负载格式定义了媒体编解码器的输出如何与RTP一起使用。在撰写本文时，在已发布的RFC中定义了70多种RTP有效负载格式，还有更多正在开发中。对于RTP有效负载格式，讨论将该媒体编解码器与RTP一起使用的特定安全含义是合适的。然而，RTP有效载荷格式并不指定使用RTP的可互操作应用程序类别，因为在绝大多数情况下，媒体编解码器及其相关RTP有效载荷格式可用于许多不同类别的应用程序。因此，RTP有效负载格式本身既不安全，也不适用于[RFC3365]的内容。未来的RTP有效负载格式规范需要明确说明这一点，并包括对本备忘录的参考以进行解释。RTP有效负载格式不适合强制使用SRTP[RFC3711]或任何其他安全构建块，因为RTP有效负载格式可能由使用RTP且具有不同安全要求的不同类别的应用程序使用。
RTP profiles are larger extensions that adapt the RTP framework for use with particular classes of application. In some cases, those classes of application might share common security requirements so that it could make sense for an RTP profile to mandate particular security options and building blocks (the RTP/SAVP profile [RFC3711] is an example of this type of RTP profile). In other cases, though, an RTP profile is applicable to such a wide range of applications that it would not make sense for that profile to mandate particular security building blocks be used (the RTP/AVPF profile [RFC4585] is an example of this type of RTP profile, since it provides building blocks that can be used in different styles of application). A new RTP profile specification needs to discuss whether or not it makes sense to mandate particular security building blocks that need to be used with all implementations of that profile; however, there is no expectation that all RTP profiles will mandate particular security solutions. RTP profiles that do not specify an interoperable usage for a particular class of RTP applications are neither secure in themselves nor something to which [RFC3365] applies; any future RTP profiles in this category need to explicitly state this with justification and include a reference to this memo.
RTP概要文件是更大的扩展，它使RTP框架适应于特定的应用程序类。在某些情况下，这些应用程序类别可能共享公共安全需求，因此RTP配置文件授权特定的安全选项和构建块是有意义的（RTP/SAVP配置文件[RFC3711]就是此类RTP配置文件的一个示例）。然而，在其他情况下，RTP配置文件适用于如此广泛的应用，以至于该配置文件要求使用特定的安全构建块是没有意义的（RTP/AVPF配置文件[RFC4585]是这种类型的RTP概要文件的一个示例，因为它提供了可以在不同应用程序样式中使用的构建块）。一个新的RTP概要文件规范需要讨论强制要求特定的安全构建块（需要与该概要文件的所有实现一起使用）是否有意义；然而，并不期望所有RTP配置文件都会要求特定的安全解决方案。未为特定类别的RTP应用程序指定可互操作用法的RTP配置文件本身既不安全，也不适用于[RFC3365]的内容；该类别中的任何未来RTP概要文件都需要明确说明这一点，并说明理由，并包括对本备忘录的引用。
The RTP framework is used in a wide range of different scenarios with no common security requirements. Accordingly, neither SRTP [RFC3711] nor any other single media security solution or keying mechanism can be mandated for all uses of RTP. In the absence of a single common security solution, it is important to consider what mechanisms can be used to provide strong and interoperable security for each different scenario where RTP applications are used. This will require analysis of each class of application to determine the security requirements for the scenarios in which they are to be used, followed by the selection of MTI security building blocks for that class of application, including the desired RTP traffic protection and key management. A non-exhaustive list of the RTP security options available at the time of this writing is outlined in [RFC7201]. It is expected that each class of application will be supported by a memo describing what security options are mandatory to implement for that usage scenario.
RTP框架用于各种不同的场景，没有共同的安全需求。因此，SRTP[RFC3711]或任何其他单一媒体安全解决方案或密钥机制都不能强制用于RTP的所有用途。在缺少单一的公共安全解决方案的情况下，重要的是考虑使用什么机制来为使用RTP应用的每个不同场景提供强的和互操作的安全性。这将需要对每类应用程序进行分析，以确定其使用场景的安全要求，然后为该类应用程序选择MTI安全构建块，包括所需的RTP流量保护和密钥管理。[RFC7201]概述了撰写本文时可用的RTP安全选项的非详尽列表。预计每一类应用程序都将得到一份备忘录的支持，该备忘录描述了针对该使用场景必须实施的安全选项。
This entire memo is about mandatory-to-implement security.
这整个备忘录是关于强制实施安全性的。
Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, Martin Ellis, Ali Begen, Keith Drage, Ray van Brandenburg, Stephen Farrell, Sean Turner, John Mattsson, and Benoit Claise for their feedback.
感谢拉尔夫·布洛姆、汉内斯·茨霍芬尼、丹·约克、阿尔弗雷德·霍恩斯、马丁·埃利斯、阿里·贝根、基思·德拉格、雷·范·勃兰登堡、斯蒂芬·法雷尔、肖恩·特纳、约翰·马特森和贝诺特·克莱斯的反馈。
[ISMACryp2] Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication Version 2.0", November 2007, <http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/ isma_easpec2.0.pdf>.
[ISMACryp2]互联网流媒体联盟（ISMA），“ISMA加密和认证版本2.0”，2007年11月<http://www.oipf.tv/images/site/DOCS/mpegif/ISMA/ isma_easpec2.0.pdf>。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365]Schiller，J.“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，2002年8月。
[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月。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 45852006年7月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]Duke，M.，Braden，R.，Eddy，W.，和E.Blanton，“传输控制协议（TCP）规范文件路线图”，RFC 46142006年9月。
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, April 2009.
[RFC5479]Wing，D.，Fries，S.，Tschofenig，H.，和F.Audet，“媒体安全管理协议的要求和分析”，RFC 5479，2009年4月。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, April 2014.
[RFC7201]Westerlund，M.和C.Perkins，“保护RTP会话的选项”，RFC 7201，2014年4月。
[RTSP] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, "Real Time Streaming Protocol 2.0 (RTSP)", Work in Progress, February 2014.
[RTSP]Schulzrinne，H.，Rao，A.，Lanphier，R.，Westerlund，M.，和M.Stiemerling，“实时流协议2.0（RTSP）”，正在进行的工作，2014年2月。
[T3GPP.26.346] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013, <http://www.3gpp.org/ftp/Specs/html-info/26346.htm>.
[T3GPP.26.346]3GPP，“多媒体广播/多播服务（MBMS）；协议和编解码器”，3GPP TS 26.346 10.7.012013年3月<http://www.3gpp.org/ftp/Specs/html-info/26346.htm>.
[WebRTC-SEC] Rescorla, E., "WebRTC Security Architecture", Work in Progress, February 2014.
[WebRTC SEC]Rescorla，E.，“WebRTC安全架构”，正在进行的工作，2014年2月。
Authors' Addresses
作者地址
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
柯林帕金斯格拉斯哥大学计算科学学院格拉斯哥G128QQ英国
EMail: csp@csperkins.org
URI: http://csperkins.org/
EMail: csp@csperkins.org
URI: http://csperkins.org/
Magnus Westerlund Ericsson Farogatan 6 Kista SE-164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6 Kista SE-164 80瑞典
EMail: magnus.westerlund@ericsson.com
EMail: magnus.westerlund@ericsson.com