RFC 7202

Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution

📅 published April 2014, from ietf

Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution 🎀

RFC 7202, published April 2014, bestie! 🌸 It's an Informational doc (not a Standards Track one), with ISSN 2070-1721. The authors are C. Perkins from the University of Glasgow and M. Westerlund from Ericsson. The title block doesn't list anything it obsoletes or updates, so this one stands on its own. 🦋

Abstract

okay so this memo is all about how to secure real-time multimedia sessions 🎧 It explains why RTP (the Real-time Transport Protocol) and its buddy RTCP (the RTP Control Protocol) don't require one single media security mechanism. 🙈 This matters for anyone designing or reviewing future RTP extensions, because they need to make sure the right security mechanisms are required and that those mechanisms are specified in a way that fits the RTP architecture. ✨

Status of This Memo

this doc is NOT an Internet Standards Track spec, it's just published for info 📚

It's a product of the IETF, it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). 💅 Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious. For the current status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7202. 🔥

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please actually read them, because they explain your rights and restrictions for this doc. 🫶 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, same as the Simplified BSD License says. 💜

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 ✨

okay so RTP [RFC3550] is everywhere 📞 It runs voice over IP, Internet TV, video calls, and loads of other real-time and streaming apps. 🎬 Even so, the base RTP spec only gives you limited options for media security, and it doesn't define a standard key exchange mechanism. Instead, a bunch of extensions exist that can provide confidentiality and authentication for RTP media streams and RTCP messages, and other mechanisms define key exchange protocols. 🔐 This memo explains why it makes sense to have multiple extension mechanisms, instead of forcing every RTP user onto one single security and keying mechanism. 🧚

The IETF policy "Strong Security Requirements for Internet Engineering Task Force Standard Protocols" [RFC3365], aka the so-called "Danvers Doctrine," says 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 RTP let us meet that requirement. BUT, RTP is a protocol framework that fits a huge variety of use cases, so there isn't one security mechanism that works for every scenario. 💀 This memo explains why, and how RTP users can meet the requirement for strong security. 🌸

This doc gives high-level guidance on handling security for the different components in the RTP framework, plus the role the service or app using RTP plays in making sure strong security is actually implemented. 💖 It does NOT give an individual implementer (or even an RTP app specifier) the guidance they'd need to figure out which security mechanism to use. That's not what this doc is for. 🙅‍♀️

A non-exhaustive list of the RTP security options available when this was written is in [RFC7201]. This doc gives an overview of the available RTP solutions and guidance on where each one fits across different application domains. 🦋 It also tries to show what's actually being used, and what's planned, at the time of writing, to help with things like interoperability and how easy implementations are to find. 👑

2. RTP Applications and Deployment Scenarios 🌈

RTP has been used in a seriously wide range of application and deployment scenarios. The list includes, but isn't limited to, the following:

  • Point-to-point voice telephony 📞
  • Point-to-point video conferencing and telepresence 💻
  • Centralized group video conferencing and telepresence, using a Multipoint Conference Unit (MCU) or similar central middlebox 🏢
  • Any Source Multicast (ASM) video conferencing using the lightweight sessions model (e.g., the Mbone conferencing tools) 🎙️
  • Point-to-point streaming audio and/or video (e.g., on-demand TV or movie streaming) 🍿
  • 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]) 📺
  • Replicated unicast streaming to a group of receivers 📡
  • Interconnecting components in music production studios and video editing suites 🎵
  • Interconnecting components of distributed simulation systems 🧪
  • Streaming real-time sensor data (e.g., electronic Very Long Baseline Interferometry (e-VLBI) radio astronomy) 🔭

See how wild the range is? These scenarios go from point-to-point sessions all the way to huge 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. 🔥 Most of these apps run over UDP [RFC0768], but some use TCP [RFC0793] [RFC4614] or the Datagram Congestion Control Protocol (DCCP) [RFC4340] as their transport. 🚀 Some run on highly reliable optical networks, while others use low-rate unreliable wireless networks. 📶 Some RTP apps stay entirely inside a single trust domain, while others run across domains with untrusted (and, in some cases, potentially unknown) users. 👀 The range of scenarios is wide, and it keeps growing in both number and variety. 🌸

3. RTP Media Security 🔐

RTP is used in so many different application scenarios that it has led to several solutions for securing RTP media streams and RTCP control messages, each one built for different requirements. 💜

Probably the most widely applicable of these security options is the Secure RTP (SRTP) framework [RFC3711]. It's an application-level media security solution: it encrypts the media payload data (but not the RTP headers) for confidentiality, and it supports source origin authentication as an option. ✨ SRTP was carefully designed to be low overhead, including operating on links that use RTP header compression, and to support the group communication and third-party performance monitoring features of RTP across a range of networks. 🧚

SRTP isn't the only media security solution for RTP, though. Alternatives can be a better fit in some scenarios, maybe because they integrate more easily with other parts of the whole system. 🫶 Also, SRTP doesn't address every possible security requirement, so other solutions are needed where SRTP isn't suitable. 🙈 For example, ISMACryp payload-level confidentiality [ISMACryp2] suits some types of streaming video apps, but it isn't suitable for voice telephony, and it uses features that SRTP doesn't provide. 🎬

The range of available RTP security options, and where each one applies, is outlined in [RFC7201]. At the time of writing, there's no single media security protocol that works for every environment where RTP is used. 💅 Multiple RTP media security protocols are expected to stay in wide use for the foreseeable future. 👑

4. RTP Session Establishment and Key Management 🗝️

There's a whole range of protocols for RTP session establishment and key exchange, matching the wide variety of RTP use cases. 🌈 They split into two categories: those that operate in band on the media path, and those that are out of band and run as part of the session establishment signaling channel. 📡 The requirements for these two classes are different, and a wide range of solutions has been developed in this space. 🦋

If you want a more detailed survey of requirements for media security management protocols, check [RFC5479]. As that memo shows, the range of use cases is huge, and there's no single key management protocol that fits every scenario. 😭 The solutions have also been diversified by infrastructure elements, like authentication systems, that are tied to the key management. 🔑 The most important and widely used keying options for RTP sessions at the time of writing are described in [RFC7201]. ✨

5. On the Requirement for Strong Security in Framework Protocols ✨

okay bestie, so the IETF has this rule that every protocol needs a strong, mandatory-to-implement security solution [RFC3365] 🔒 and honestly? iconic. it's what keeps the whole internet safe and makes sure every implementation can talk to the others securely 💅. BUT framework protocols are kind of the main character problem here 😭, because they get used by SO many different kinds of apps in SO many different environments. the security needs for each use case are different, and implementations built for different environments usually aren't expected to interwork anyway.

RTP is the perfect example of a framework protocol with wide applicability 🎀. the huge range of scenarios in Section 2 shows exactly why it's messy to mandate one security mechanism for something like this. would it be amazing if one media security solution AND one key management solution could work for all of those scenarios? yes 😍. but the authors don't know of any such solution, and they think it's unlikely one will ever show up 🥲. part of the reason is that apps in different domains aren't meant to interwork, so nobody has a reason to build one shared mechanism. the real kicker, though, is that security requirements vary wildly between usage scenarios, and a mechanism that's perfect in one scenario just doesn't work for some other scenarios 💀.

For a framework protocol, the only sensible way to meet the strong security requirement of [RFC3365] looks like building and using security building blocks for the basic services: confidentiality, integrity protection, authorization, authentication, and so on 🧩. when new uses for the framework pop up, they need to be studied to figure out whether the existing building blocks can do the job, or whether new ones need to be developed 🔍.

So when you're thinking about the strong, mandatory-to-implement security mechanism for one specific class of applications, you have to consider which security building blocks need to be integrated, or whether new mechanisms need defining to deal with whatever is new about that class of application 🧠. to maximize interoperability, it's important that common media security and key management mechanisms get defined for classes of application with similar requirements 🫶. the IETF needs to take part in choosing these security building blocks for each class of application that uses the protocol framework and is expected to interoperate, in cases where the IETF has the right knowledge of that class of application 👑.

6. Securing the RTP Framework 🌸

the IETF requires that protocols specify mandatory-to-implement (MTI) strong security [RFC3365], and that applies to the specification of each interoperable class of application that makes use of RTP 🔐. but RTP is a framework protocol, so everything we just said in Section 5 applies here too 🙈. given how varied the classes of application using RTP are, and how many security mechanisms are currently available (as described in [RFC7201]), no one set of MTI security options can realistically be specified for all classes of RTP application 💀.

documents that define an interoperable class of applications using RTP are subject to [RFC3365], so they need to specify MTI security mechanisms. this is because those specifications fully define interoperable applications that use RTP 📋. examples of these documents being developed in the IETF at the time of writing are "WebRTC Security Architecture" [WebRTC-SEC] and "Real Time Streaming Protocol 2.0 (RTSP)" [RTSP] ✨. a similar document is also expected for voice-over-IP applications using SIP and RTP 📞.

the RTP framework has several extension points 🧩. some extensions can change the behavior of the protocol so much that applications using them form their own separate interoperable class, different from the ones that haven't been extended 🦋. other extension points are defined so they can be used (largely) independently of the class of applications using RTP. two important extension points that are independent of the class of application are RTP payload formats and RTP profiles 💖.

an RTP payload format defines how the output of a media codec can be used with RTP. at the time of writing, there are over 70 RTP payload formats defined in published RFCs, with more in development 🤯. it's appropriate for an RTP payload format to discuss the specific security implications of using that media codec with RTP 🔍. BUT an RTP payload format doesn't specify an interoperable class of applications that use RTP, because in the vast majority of cases a media codec and its payload format can be used with lots of different classes of application 🙅‍♀️. so an RTP payload format is neither secure in itself nor something [RFC3365] applies to. future RTP payload format specifications need to say this explicitly and include a reference to this memo for explanation 📝. it's also not appropriate for an RTP payload format to mandate the use of SRTP [RFC3711], or any other security building blocks, since that payload format might be used by different classes of application that have different security requirements 🚫.

RTP profiles are larger extensions that adapt the RTP framework for use with particular classes of application 🎀. in some cases, those classes might share common security requirements, so 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 profile) 🔐. in other cases, an RTP profile is applicable to such a wide range of applications that it wouldn't make sense for it to mandate particular security building blocks (the RTP/AVPF profile [RFC4585] is an example of this, 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 for all implementations of that profile. however, there's no expectation that all RTP profiles will mandate particular security solutions 🤷‍♀️. RTP profiles that don't specify an interoperable usage for a particular class of RTP applications are neither secure in themselves nor something [RFC3365] applies to. any future RTP profiles in this category need to say this explicitly, with justification, and include a reference to this memo 📚.

7. Conclusions 👑

the RTP framework gets used in a wide range of scenarios with no common security requirements, so neither SRTP [RFC3711] nor any other single media security solution or keying mechanism can be mandated for all uses of RTP 🙅‍♀️. without one common security solution, it's important to figure out which mechanisms can provide strong, interoperable security for each different scenario where RTP applications are used 🔍. this takes analysis of each class of application to work out its security requirements for the scenarios it'll be used in, followed by picking MTI security building blocks for that class, including the desired RTP traffic protection and key management 🧠. a non-exhaustive list of the RTP security options available at the time of writing is outlined in [RFC7201] 📜. each class of application is expected to be supported by a memo describing which security options are mandatory to implement for that usage scenario 💅.

8. Security Considerations 🔒

okay this section is short but it's giving EVERYTHING 😭. this entire memo is about mandatory-to-implement security. the whole point is that security isn't an afterthought for RTP. it's the core of how every interoperable class of application has to be secured, so please take it seriously 🫶💀.

9. Acknowledgements 💖

huge 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 🥹✨.

10. Informative References 📚

[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>.

[RFC0768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.

[RFC0793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.

[RFC3365]    Schiller, J., "Strong Security Requirements for Internet
             Engineering Task Force Standard Protocols", BCP 61, RFC
             3365, August 2002.

[RFC3550]    Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.

[RFC3711]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
             K.  Norrman, "The Secure Real-time Transport Protocol
             (SRTP)", RFC 3711, March 2004.

[RFC4340]    Kohler, E., Handley, M., and S. Floyd, "Datagram
             Congestion Control Protocol (DCCP)", RFC 4340, March
             2006.

[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.

[RFC4614]    Duke, M., Braden, R., Eddy, W., and E. Blanton, "A
             Roadmap for Transmission Control Protocol (TCP)
             Specification Documents", RFC 4614, September 2006.

[RFC5479]    Wing, D., Fries, S., Tschofenig, H., and F. Audet,
             "Requirements and Analysis of Media Security Management
             Protocols", RFC 5479, April 2009.

[RFC7201]    Westerlund, M. and C. Perkins, "Options for Securing RTP
             Sessions", RFC 7201, April 2014.

[RTSP]       Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
             and M. Stiemerling, "Real Time Streaming Protocol 2.0
             (RTSP)", Work in Progress, February 2014.

[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>.

[WebRTC-SEC] Rescorla, E., "WebRTC Security Architecture", Work in
             Progress, February 2014.

Authors' Addresses 🦋

Colin Perkins
University of Glasgow
School of Computing Science
Glasgow  G12 8QQ
United Kingdom

EMail: csp@csperkins.org
URI:   http://csperkins.org/


Magnus Westerlund
Ericsson
Farogatan 6
Kista  SE-164 80
Sweden

EMail: magnus.westerlund@ericsson.com
📦 where this page comes from