draft-ietf-avt-srtp-not-mandatory-13.txt | draft-ietf-avt-srtp-not-mandatory-14.txt | |||
---|---|---|---|---|
Network Working Group C.S. Perkins | Network Working Group C.S. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational M. Westerlund | Intended status: Informational M. Westerlund | |||
Expires: November 07, 2013 Ericsson | Expires: April 18, 2014 Ericsson | |||
May 06, 2013 | October 15, 2013 | |||
Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | |||
Media Security Solution | Media Security Solution | |||
draft-ietf-avt-srtp-not-mandatory-13.txt | draft-ietf-avt-srtp-not-mandatory-14.txt | |||
Abstract | Abstract | |||
This memo discusses the problem of securing real-time multimedia | This memo discusses the problem of securing real-time multimedia | |||
sessions, and explains why the Real-time Transport Protocol (RTP), | sessions, and explains why the Real-time Transport Protocol (RTP), | |||
and the associated RTP control protocol (RTCP), do not mandate a | and the associated RTP Control Protocol (RTCP), do not mandate a | |||
single media security mechanism. Guidelines for designers and | single media security mechanism. Guidelines for designers and | |||
reviewers of future RTP extensions are provided, to ensure that | reviewers of future RTP extensions are provided, to ensure that | |||
appropriate security mechanisms are mandated, and that any such | appropriate security mechanisms are mandated, and that any such | |||
mechanisms are specified in a manner that conforms with the RTP | mechanisms are specified in a manner that conforms with the RTP | |||
architecture. | architecture. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on November 07, 2013. | This Internet-Draft will expire on April 18, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 16 ¶ | skipping to change at page 3, line 16 ¶ | |||
future RTP-related work in the IETF. It does not specify a standard | future RTP-related work in the IETF. It does not specify a standard | |||
of any kind. | of any kind. | |||
2. RTP Applications and Deployment Scenarios | 2. RTP Applications and Deployment Scenarios | |||
The range of application and deployment scenarios where RTP has been | The range of application and deployment scenarios where RTP has been | |||
used includes, but is not limited to, the following: | used includes, but is not limited to, the following: | |||
o Point-to-point voice telephony; | o Point-to-point voice telephony; | |||
o Point-to-point video conferencing and telepresence | o Point-to-point video conferencing and telepresence; | |||
o Centralised group video conferencing and telepresence, using a | o Centralised group video conferencing and telepresence, using a | |||
multipoint conference unit (MCU) or similar central middlebox | Multipoint Conference Unit (MCU) or similar central middlebox; | |||
o Any Source Multicast video (ASM) conferencing using the light- | o Any Source Multicast (ASM) video conferencing using the light- | |||
weight sessions model (e.g., the Mbone conferencing tools) | weight sessions model (e.g., the Mbone conferencing tools); | |||
o Point-to-point streaming audio and/or video (e.g., on-demand TV or | o Point-to-point streaming audio and/or video (e.g., on-demand TV or | |||
movie streaming) | movie streaming); | |||
o Source-specific multicast (SSM) streaming to large receiver groups | o Source-Specific Multicast (SSM) streaming to large receiver groups | |||
(e.g., IPTV streaming by residential ISPs, or the 3GPP Multimedia | (e.g., IPTV streaming by residential ISPs, or the 3GPP Multimedia | |||
Broadcast Multicast Service [MBMS]) | Broadcast Multicast Service [MBMS]); | |||
o Replicated unicast streaming to a group of receivers | o Replicated unicast streaming to a group of receivers; | |||
o Interconnecting components in music production studios and video | o Interconnecting components in music production studios and video | |||
editing suites | editing suites; | |||
o Interconnecting components of distributed simulation systems | o Interconnecting components of distributed simulation systems; and | |||
o Streaming real-time sensor data (e.g., e-VLBI radio astronomy) | o Streaming real-time sensor data (e.g., e-VLBI radio astronomy). | |||
As can be seen, these scenarios vary from point-to-point sessions to | As can be seen, these scenarios vary from point-to-point sessions to | |||
very large multicast groups, from interactive to non-interactive, and | very large multicast groups, from interactive to non-interactive, and | |||
from low bandwidth (kilobits per second) telephony to high bandwidth | from low bandwidth (kilobits per second) telephony to high bandwidth | |||
(multiple gigabits per second) video and data streaming. While most | (multiple gigabits per second) video and data streaming. While most | |||
of these applications run over UDP [RFC0768], some use TCP [RFC0793], | of these applications run over UDP [RFC0768], some use TCP [RFC0793], | |||
[RFC4614] or DCCP [RFC4340] as their underlying transport. Some run | [RFC4614] or DCCP [RFC4340] as their underlying transport. Some run | |||
on highly reliable optical networks, others use low rate unreliable | on highly reliable optical networks, others use low rate unreliable | |||
wireless networks. Some applications of RTP operate entirely within | wireless networks. Some applications of RTP operate entirely within | |||
a single trust domain, others run inter-domain, with untrusted (and, | a single trust domain, others run inter-domain, with untrusted (and, | |||
skipping to change at page 6, line 37 ¶ | skipping to change at page 6, line 37 ¶ | |||
Real Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis]. | Real Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis]. | |||
It is also expected that a similar document will be produced for | It is also expected that a similar document will be produced for | |||
voice-over-IP applications using SIP and RTP. | voice-over-IP applications using SIP and RTP. | |||
The RTP framework includes several extension points. Some extensions | The RTP framework includes several extension points. Some extensions | |||
can significantly change the behaviour of the protocol, to the extent | can significantly change the behaviour of the protocol, to the extent | |||
that applications using the extension form a separate interoperable | that applications using the extension form a separate interoperable | |||
class of applications to those that have not been extended. Other | class of applications to those that have not been extended. Other | |||
extension points are defined in such a manner that they can be used | extension points are defined in such a manner that they can be used | |||
(largely) independently of the class of applications using RTP. Two | (largely) independently of the class of applications using RTP. Two | |||
important extension points that are can be independent of the class | important extension points that are independent of the class of | |||
of applications are RTP Payload Formats and RTP Profiles. | applications are RTP Payload Formats and RTP Profiles. | |||
An RTP Payload Format defines how the output of a media codec can be | 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 | used with RTP. At the time of this writing, there are over 70 RTP | |||
Payload Formats defined in published RFCs, with more in development. | Payload Formats defined in published RFCs, with more in development. | |||
It is appropriate for an RTP payload format to discuss the specific | It is appropriate for an RTP Payload Format to discuss the specific | |||
security implications of using that media codec with RTP. However, | security implications of using that media codec with RTP. However, | |||
an RTP payload format does not specify an interoperable class of | an RTP Payload Format does not specify an interoperable class of | |||
applications that use RTP since, in the vast majority of cases, a | applications that use RTP since, in the vast majority of cases, a | |||
media codec and it's associated RTP payload format can be used with | media codec and its associated RTP Payload Format can be used with | |||
many different classes of application. As such, an RTP payload | many different classes of application. As such, an RTP Payload | |||
format is neither secure in itself, nor something to which [RFC3365] | Format is neither secure in itself, nor something to which [RFC3365] | |||
applies. Future RTP payload format specifications need to explicitly | applies. Future RTP Payload Format specifications need to explicitly | |||
state this, and include a reference to this memo for explanation. It | 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 | is not appropriate for an RTP Payload Format to mandate the use of | |||
SRTP [RFC3711], or any other security building blocks, since that RTP | SRTP [RFC3711], or any other security building blocks, since that RTP | |||
payload format might be used by different classes of application that | Payload Format might be used by different classes of application that | |||
use RTP, and that have different security requirements. | use RTP, and that have different security requirements. | |||
RTP profiles are larger extensions that adapt the RTP framework for | RTP Profiles are larger extensions that adapt the RTP framework for | |||
use with particular classes of application. In some cases, those | use with particular classes of application. In some cases, those | |||
classes of application might share common security requirements so | classes of application might share common security requirements so | |||
that it could make sense for an RTP profile to mandate particular | that it could make sense for an RTP Profile to mandate particular | |||
security options and building blocks (the RTP/SAVP profile [RFC3711] | security options and building blocks (the RTP/SAVP profile [RFC3711] | |||
is an example of this type of RTP profile). In other cases, though, | 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 | an RTP profile is applicable to such a wide range of applications | |||
that it would not make sense for that profile to mandate particular | that it would not make sense for that profile to mandate particular | |||
security building blocks be used (the RTP/AVPF profile [RFC4585] is | security building blocks be used (the RTP/AVPF profile [RFC4585] is | |||
an example of this type of RTP profile, since it provides building | an example of this type of RTP Profile, since it provides building | |||
blocks that can be used in different styles of application). A new | blocks that can be used in different styles of application). A new | |||
RTP profile specification needs to discuss whether, or not, it makes | RTP Profile specification needs to discuss whether, or not, it makes | |||
sense to mandate particular security building blocks that need to be | sense to mandate particular security building blocks that need to be | |||
used with all implementations of that profile; however, there is no | used with all implementations of that profile; however, there is no | |||
expectation that all RTP profiles will mandate particular security | expectation that all RTP Profiles will mandate particular security | |||
solutions. RTP profiles that do not specify an interoperable usage | solutions. RTP Profiles that do not specify an interoperable usage | |||
for a particular class of RTP applications are neither secure in | for a particular class of RTP applications are neither secure in | |||
themselves, nor something to which [RFC3365] applies; any future RTP | themselves, nor something to which [RFC3365] applies; any future RTP | |||
profiles in this category need to explicitly state this with | Profiles in this category need to explicitly state this with | |||
justification, and include a reference to this memo. | justification, and include a reference to this memo. | |||
7. Conclusions | 7. Conclusions | |||
The RTP framework is used in a wide range of different scenarios, | The RTP framework is used in a wide range of different scenarios, | |||
with no common security requirements. Accordingly, neither SRTP | with no common security requirements. Accordingly, neither SRTP | |||
[RFC3711], nor any other single media security solution or keying | [RFC3711], nor any other single media security solution or keying | |||
mechanism, can be mandated for all uses of RTP. In the absence of a | mechanism, can be mandated for all uses of RTP. In the absence of a | |||
single common security solution, it is important to consider what | single common security solution, it is important to consider what | |||
mechanisms can be used to provide strong and interoperable security | mechanisms can be used to provide strong and interoperable security | |||
skipping to change at page 8, line 14 ¶ | skipping to change at page 8, line 14 ¶ | |||
This entire memo is about security. | This entire memo is about security. | |||
9. IANA Considerations | 9. IANA Considerations | |||
None. | None. | |||
10. Acknowledgements | 10. Acknowledgements | |||
Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, | Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, | |||
Martin Ellis, Ali Begen, Keith Drage, Ray van Brandenburg, Stephen | Martin Ellis, Ali Begen, Keith Drage, Ray van Brandenburg, Stephen | |||
Farrell, and Sean Turner for their feedback. | Farrell, Sean Turner, and John Mattsson for their feedback. | |||
11. Informative References | 11. Informative References | |||
[I-D.ietf-avtcore-rtp-security-options] | [I-D.ietf-avtcore-rtp-security-options] | |||
Westerlund, M. and C. Perkins, "Options for Securing RTP | Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Sessions", draft-ietf-avtcore-rtp-security-options-03 | Sessions", draft-ietf-avtcore-rtp-security-options-07 | |||
(work in progress), May 2013. | (work in progress), October 2013. | |||
[I-D.ietf-mmusic-rfc2326bis] | [I-D.ietf-mmusic-rfc2326bis] | |||
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | |||
and M. Stiemerling, "Real Time Streaming Protocol 2.0 | and M. Stiemerling, "Real Time Streaming Protocol 2.0 | |||
(RTSP)", draft-ietf-mmusic-rfc2326bis-34 (work in | (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in | |||
progress), April 2013. | progress), October 2013. | |||
[I-D.ietf-rtcweb-security-arch] | [I-D.ietf-rtcweb-security-arch] | |||
Rescorla, E., "RTCWEB Security Architecture", draft-ietf- | Rescorla, E., "WebRTC Security Architecture", draft-ietf- | |||
rtcweb-security-arch-06 (work in progress), January 2013. | rtcweb-security-arch-07 (work in progress), July 2013. | |||
[ISMACrypt2] | [ISMACrypt2] | |||
Internet Streaming Media Alliance (ISMA), , "ISMA | Internet Streaming Media Alliance (ISMA), , "ISMA | |||
Encryption and Authentication, Version 2.0 release | Encryption and Authentication, Version 2.0 release | |||
version", November 2007. | version", November 2007. | |||
[MBMS] 3GPP, , "Multimedia Broadcast/Multicast Service (MBMS); | [MBMS] 3GPP, , "Multimedia Broadcast/Multicast Service (MBMS); | |||
Protocols and codecs TS 26.346", . | Protocols and codecs TS 26.346", . | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
skipping to change at page 9, line 38 ¶ | skipping to change at page 9, line 38 ¶ | |||
Authors' Addresses | Authors' Addresses | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
URI: http://csperkins.org/ | ||||
Magnus Westerlund | Magnus Westerlund | |||
Ericsson | Ericsson | |||
Farogatan 6 | Farogatan 6 | |||
Kista SE-164 80 | Kista SE-164 80 | |||
Sweden | Sweden | |||
Email: magnus.westerlund@ericsson.com | Email: magnus.westerlund@ericsson.com | |||
End of changes. 32 change blocks. | ||||
41 lines changed or deleted | 42 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |