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/