< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/