draft-ietf-avt-srtp-not-mandatory-03.txt		draft-ietf-avt-srtp-not-mandatory-04.txt
	Network Working Group C. Perkins		Network Working Group C. Perkins
	Internet-Draft University of Glasgow		Internet-Draft University of Glasgow
	Intended status: Informational M. Westerlund		Intended status: Informational M. Westerlund
	Expires: January 14, 2010 Ericsson		Expires: June 25, 2010 Ericsson
	July 13, 2009		December 22, 2009
	Why RTP Does Not Mandate a Single Security Mechanism		Why RTP Does Not Mandate a Single Security Mechanism
	draft-ietf-avt-srtp-not-mandatory-03.txt		draft-ietf-avt-srtp-not-mandatory-04.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2010.		This Internet-Draft will expire on June 25, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	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),
	does not mandate a single media security mechanism.		and the associated RTP control protocol (RTCP), do not mandate a
			single media security mechanism.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3		2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3
	3. Implications for RTP Media Security . . . . . . . . . . . . . 4		3. Implications for RTP Security . . . . . . . . . . . . . . . . 4
	4. Implications for Key Management . . . . . . . . . . . . . . . 5		4. Implications for Key Management . . . . . . . . . . . . . . . 5
	5. On the Requirement for Strong Security in IETF protocols . . . 6		5. On the Requirement for Strong Security in IETF protocols . . . 6
	6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Informative References . . . . . . . . . . . . . . . . . . . . 8		10. Informative References . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Real-time Transport Protocol (RTP) [RFC3550] is widely used for		The Real-time Transport Protocol (RTP) [RFC3550] is widely used for
	voice over IP, Internet television, video conferencing, and various		voice over IP, Internet television, video conferencing, and various
	other real-time and streaming media applications. Despite this, the		other real-time and streaming media applications. Despite this, the
	base RTP specification provides very limited options for media		base RTP specification provides very limited options for media
	security, and defines no standard key exchange mechanism. Rather, a		security, and defines no standard key exchange mechanism. Rather, a
	number of extensions are defined to provide confidentiality and		number of extensions are defined to provide confidentiality and
	authentication of media streams, and to exchange security keys. This		authentication of RTP media streams and RTCP control messages, and to
	memo outlines why it is appropriate that multiple extension		exchange security keys. This memo outlines why it is appropriate
	mechanisms are defined, rather than mandating a single media security		that multiple extension mechanisms are defined, rather than mandating
	and keying mechanism.		a single security and keying mechanism.
	This memo provides information for the community; it does not specify		This memo provides information for the community; it does not specify
	a standard of any kind.		a standard of any kind.
	The structure of this memo is as follows: we begin, in Section 2 by		The structure of this memo is as follows: we begin, in Section 2 by
	describing the scenarios in which RTP is deployed. Following this,		describing the scenarios in which RTP is deployed. Following this,
	Section 3 outlines the implications of this range of scenarios for		Section 3 outlines the implications of this range of scenarios for
	media confidentially and authentication, and Section 4 outlines the		media confidentially and authentication, and Section 4 outlines the
	implications for key exchange. Section 5 outlines how the RTP		implications for key exchange. Section 5 outlines how the RTP
	framework meets the requirement of BCP 61. Section 6 then concludes		framework meets the requirement of BCP 61. Section 6 then concludes
	skipping to change at page 3, line 47		skipping to change at page 3, line 47
	o Point-to-point video conferencing		o Point-to-point video conferencing
	o Centralised group video conferencing with a multipoint conference		o Centralised group video conferencing with a multipoint conference
	unit (MCU)		unit (MCU)
	o Any Source Multicast video conferencing (light-weight sessions;		o Any Source Multicast video conferencing (light-weight sessions;
	Mbone conferencing)		Mbone conferencing)
	o Point-to-point streaming audio and/or video		o Point-to-point streaming audio and/or video
	o Single Source Multicast streaming to large group (IPTV and MBMS		o Source-specific multicast (SSM) streaming to large group (IPTV and
	[MBMS])		3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS])
	o Replicated unicast streaming to a group		o Replicated unicast streaming to a group
	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
	o Streaming real-time sensor data		o Streaming real-time sensor data
	As can be seen, these scenarios vary from point-to-point to very		As can be seen, these scenarios vary from point-to-point to very
	skipping to change at page 4, line 23		skipping to change at page 4, line 23
	low bandwidth (kilobits per second) to very high bandwidth (multiple		low bandwidth (kilobits per second) to very high bandwidth (multiple
	gigabits per second). While most of these applications run over UDP		gigabits per second). While most of these applications run over UDP
	[RFC0768], some use TCP [RFC0793], [RFC4614] or DCCP [RFC4340] as		[RFC0768], some use TCP [RFC0793], [RFC4614] or DCCP [RFC4340] as
	their underlying transport. Some run on highly reliable optical		their underlying transport. Some run on highly reliable optical
	networks, others use low rate unreliable wireless networks. Some		networks, others use low rate unreliable wireless networks. Some
	applications of RTP operate entirely within a single trust domain,		applications of RTP operate entirely within a single trust domain,
	others are inter-domain, with untrusted (and potentially unknown)		others are inter-domain, with untrusted (and potentially unknown)
	users. The range of scenarios is wide, and growing both in number		users. The range of scenarios is wide, and growing both in number
	and in heterogeneity.		and in heterogeneity.
	3. Implications for RTP Media Security		3. Implications for RTP Security
	The wide range of application scenarios where RTP is used has led to		The wide range of application scenarios where RTP is used has led to
	the development of multiple solutions for media security, considering		the development of multiple solutions for securing RTP media streams
	different requirements. Perhaps the most widely applicable of these		and RTCP control messages, considering different requirements.
	solutions is the Secure RTP (SRTP) framework [RFC3711]. This is an		Perhaps the most widely applicable of these solutions is the Secure
	application-level media security solution, encrypting the media		RTP (SRTP) framework [RFC3711]. This is an application-level media
	payload data (but not the RTP headers) to provide some degree of		security solution, encrypting the media payload data (but not the RTP
	confidentiality, and providing optional source origin authentication.		headers) to provide some degree of confidentiality, and providing
	It was carefully designed to be both low overhead, and to support the		optional source origin authentication. It was carefully designed to
	group communication features of RTP, across a range of networks.		be both low overhead, and to support the group communication features
			of RTP, across a range of networks.
	SRTP is not the only media security solution in use, however, and		SRTP is not the only media security solution in use, however, and
	alternatives are more appropriate for some scenarios. For example,		alternatives are more appropriate for some scenarios. For example,
	many client-server streaming media applications can run over a single		many client-server streaming media applications can run over a single
	TCP connection, multiplexing media data with control information on		TCP connection, multiplexing media data with control information on
	that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used		that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used
	example of such a protocol). The natural way to provide media		example of such a protocol). The natural way to provide media
	security for such client-server media applications is to use TLS		security for such client-server media applications is to use TLS
	[RFC5246] to protect the TCP connection, sending the RTP media data		[RFC5246] to protect the TCP connection, sending the RTP media data
	over the TLS connection. Using the SRTP framework in addition to TLS		over the TLS connection. Using the SRTP framework in addition to TLS
	skipping to change at page 5, line 12		skipping to change at page 5, line 13
	network layer, using IPsec. For example, certain 3GPP networks need		network layer, using IPsec. For example, certain 3GPP networks need
	IPsec security associations for other purposes, and can reuse those		IPsec security associations for other purposes, and can reuse those
	to secure the RTP session [3GPP.33.210]. SRTP is, again, unnecessary		to secure the RTP session [3GPP.33.210]. SRTP is, again, unnecessary
	in such environments, and its use would only introduce overhead for		in such environments, and its use would only introduce overhead for
	no gain.		no gain.
	For some applications it is sufficient to protect the RTP payload		For some applications it is sufficient to protect the RTP payload
	data while leaving RTP, transport, and network layer headers		data while leaving RTP, transport, and network layer headers
	unprotected. An example of this is RTP broadcast over DVB-H		unprotected. An example of this is RTP broadcast over DVB-H
	[ETSI.TS.102.474], where one mode of operation uses ISMAcryp		[ETSI.TS.102.474], where one mode of operation uses ISMAcryp
	(http://www.isma.tv) to protect the media data only.		(http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP
			payload data only.
	Finally, the link layer may be secure, and it may be known that the		Finally, the link layer may be secure, and it may be known that the
	RTP media data is constrained to that single link (for example, when		RTP media data is constrained to that single link (for example, when
	operating in a studio environment, with physical link security). An		operating in a studio environment, with physical link security). An
	environment like this is inherently constrained, but might avoid the		environment like this is inherently constrained, but might avoid the
	need for application, transport, or network layer media security.		need for application, transport, or network layer media security.
	All these are application scenarios where RTP has seen commerical		All these are application scenarios where RTP has seen commerical
	deployment. Other use case also exist, with additional requirements.		deployment. Other use case also exist, with additional requirements.
	There is no media security protocol that is appropriate for all these		There is no media security protocol that is appropriate for all these
	skipping to change at page 7, line 46		skipping to change at page 8, line 7
	7. Security Considerations		7. Security Considerations
	This entire memo is about security.		This entire memo is about security.
	8. IANA Considerations		8. IANA Considerations
	No IANA actions are required.		No IANA actions are required.
	9. Acknowledgements		9. Acknowledgements
	Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, and		Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes,
	Martin Ellis for their feedback.		Martin Ellis, and Ali Begen for their feedback.
	10. Informative References		10. Informative References
	[3GPP.33.210]		[3GPP.33.210]
	3GPP, "IP network layer security", 3GPP TS 33.210,		3GPP, "IP network layer security", 3GPP TS 33.210,
	September 2008.		September 2008.
	[ETSI.TS.102.474]		[ETSI.TS.102.474]
	ETSI, "Digital Video Broadcasting (DVB); IP Datacast over		ETSI, "Digital Video Broadcasting (DVB); IP Datacast over
	DVB-H: Service Purchase and Protection", ETSI TS 102 474,		DVB-H: Service Purchase and Protection", ETSI TS 102 474,
End of changes. 12 change blocks.
	26 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/