< draft-ietf-straw-b2bua-dtls-srtp-11.txt		draft-ietf-straw-b2bua-dtls-srtp-12.txt >
	STRAW R. Ravindranath		STRAW R. Ravindranath
	Internet-Draft T. Reddy		Internet-Draft T. Reddy
	Intended status: Standards Track G. Salgueiro		Intended status: Standards Track G. Salgueiro
	Expires: September 8, 2016 Cisco		Expires: October 1, 2016 Cisco
	V. Pascual		V. Pascual
	Quobis		Oracle
	Parthasarathi. Ravindran		Parthasarathi. Ravindran
	Nokia Networks		Nokia Networks
	March 7, 2016		March 30, 2016
	DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back		DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
	User Agents (B2BUAs)		User Agents (B2BUAs)
	draft-ietf-straw-b2bua-dtls-srtp-11		draft-ietf-straw-b2bua-dtls-srtp-12
	Abstract		Abstract
	Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA)		Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA)
	exist on the signaling and media paths between the endpoints. This		exist on the signaling and media paths between the endpoints. This
	document describes the behavior of B2BUAs when Secure Real-time		document describes the behavior of B2BUAs when Secure Real-time
	Transport (SRTP) security context is set up with the Datagram		Transport (SRTP) security context is set up with the Datagram
	Transport Layer Security (DTLS) protocol.		Transport Layer Security (DTLS) protocol.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 September 8, 2016.		This Internet-Draft will expire on October 1, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 25 ¶		skipping to change at page 3, line 25 ¶
	referred to as media plane B2BUAs. [RFC7092] describes two different		referred to as media plane B2BUAs. [RFC7092] describes two different
	categories of media plane B2BUAs, according to the level of		categories of media plane B2BUAs, according to the level of
	activities performed on the media plane.		activities performed on the media plane.
	When B2BUAs are present in a call between two SIP User Agents (UAs)		When B2BUAs are present in a call between two SIP User Agents (UAs)
	they often make end-to-end DTLS-SRTP sessions impossible. End-to-end		they often make end-to-end DTLS-SRTP sessions impossible. End-to-end
	DTLS-SRTP session means that man-in-middle devices cannot break the		DTLS-SRTP session means that man-in-middle devices cannot break the
	DTLS-SRTP session between the endpoints. In other words, the man-in-		DTLS-SRTP session between the endpoints. In other words, the man-in-
	middle device cannot create a separate DTLS-SRTP session between the		middle device cannot create a separate DTLS-SRTP session between the
	client and the middle device, on one side, and the middle device and		client and the middle device, on one side, and the middle device and
	the remote peer on the other side. However, there are certain B2BUAs		the remote peer on the other side. B2BUAs may be deployed for
	that are typically deployed for address hiding or media latching, as		address hiding or media latching [RFC7362], although TURN (and ICE)
	described in [RFC7362], and such B2BUAs are able to perform their		is expected to be used more often for this purpose as it provides
			better security properties. Such B2BUAs are able to perform their
	functions without requiring termination of DTLS-SRTP sessions i.e.		functions without requiring termination of DTLS-SRTP sessions i.e.
	these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.		these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.
	1.2. Goals and Scope of this Document		1.2. Goals and Scope of this Document
	A B2BUA could be deployed for address hiding or media latching, as		A B2BUA could be deployed for address hiding or media latching, as
	described in [RFC7362]. Such B2BUAs only terminate the media plane		described in [RFC7362]. Such B2BUAs only terminate the media plane
	at the IP and transport (UDP/TCP) layers and may inspect the RTP		at the IP and transport (UDP/TCP) layers and may inspect the RTP
	headers or RTP Control Protocol (RTCP) packets. The goal of this		headers or RTP Control Protocol (RTCP) packets. The goal of this
	specification is to provide guidance on how such B2BUAs function		specification is to provide guidance on how such B2BUAs function
	without breaking the end-to-end DTLS-SRTP session. A B2BUA could		without breaking the end-to-end DTLS-SRTP session. A B2BUA could
	also terminate the media or modify the RTP headers or RTP Control		also terminate the media or modify the RTP headers or RTP Control
	Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-		Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-
	SRTP. Those B2BUAs terminating DTLS-SRTP sessions are outside the		SRTP. The recommendations made in this document are not expected to
	scope of this document.		be applied by B2BUAs terminating DTLS-SRTP sessions given deployment
			reality.
	This specification assumes that a B2BUA is not providing identity		This specification assumes that a B2BUA is not providing identity
	assurance and is not authorized to terminate the DTLS-SRTP session.		assurance and is not authorized to terminate the DTLS-SRTP session.
	A B2BUA that provides identity assurance on behalf of endpoints		A B2BUA that provides identity assurance on behalf of endpoints
	behind it can modify any portion of SIP and SDP before it generates		behind it can modify any portion of SIP and SDP before it generates
	the identity signature. As the B2BUA is generating the identity		the identity signature. As the B2BUA is generating the identity
	signature it is not possible to detect if a B2BUA has terminated the		signature it is not possible to detect if a B2BUA has terminated the
	DTLS-SRTP session. B2BUAs providing identity assurance and		DTLS-SRTP session. B2BUAs providing identity assurance and
	terminating DTLS-SRTP session are out of scope of this document.		terminating DTLS-SRTP session are out of scope of this document.
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 29 ¶
	that it does not modify any of the headers used to construct the		that it does not modify any of the headers used to construct the
	identity signature.		identity signature.
	4. Both media relays and media-aware relays MUST NOT modify the		4. Both media relays and media-aware relays MUST NOT modify the
	authenticated portion of RTP and RTCP packets, and MUST NOT		authenticated portion of RTP and RTCP packets, and MUST NOT
	modify the authentication tag in the RTP and RTCP packets.		modify the authentication tag in the RTP and RTCP packets.
	4. Signaling Plane B2BUA Handling of DTLS-SRTP		4. Signaling Plane B2BUA Handling of DTLS-SRTP
	Section 3.1 of [RFC7092] describes different categories of signaling		Section 3.1 of [RFC7092] describes different categories of signaling
	plane B2BUAs. This section explains the impact these B2BUAs can have		plane B2BUAs. This section explains how these B2BUAs are expected to
	on end-to-end DTLS-SRTP sessions.		comply with the recommendations in Section 3.
	4.1. Proxy-B2BUAs		4.1. Proxy-B2BUAs
	Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only		Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only
	the Via and Record-Route SIP headers. These B2BUAs can continue to		the Via and Record-Route SIP headers. These B2BUAs can continue to
	perform their function and still allow end-to-end DTLS-SRTP sessions		perform their function and still allow end-to-end DTLS-SRTP sessions
	since it does not modify any of the headers used to construct the		since it does not modify any of the headers used to construct the
	identity signature.		identity signature.
	4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs		4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 9 ¶
	B2BUA can modify the Contact URI. Such B2BUAs are likely to violate		B2BUA can modify the Contact URI. Such B2BUAs are likely to violate
	rule 2 or rule 3 in Section 3. Depending upon the application		rule 2 or rule 3 in Section 3. Depending upon the application
	requirements, such a B2BUA may be able to limit modification of		requirements, such a B2BUA may be able to limit modification of
	header fields to those allowed to be modified by [RFC4474] or		header fields to those allowed to be modified by [RFC4474] or
	[I-D.ietf-stir-rfc4474bis].		[I-D.ietf-stir-rfc4474bis].
	5. Media Plane B2BUA Handling of DTLS-SRTP		5. Media Plane B2BUA Handling of DTLS-SRTP
	5.1. General		5.1. General
	This section describes the DTLS-SRTP handling by the different types		This section describes how the different types of media plane B2BUAs
	of media plane B2BUAs defined in [RFC7092].		defined in [RFC7092] are expected to comply with the recommendations
			in Section 3.
	5.1.1. Media Relay		5.1.1. Media Relay
	A media relay, as defined in Section 3.2.1 of [RFC7092], from an		A media relay, as defined in Section 3.2.1 of [RFC7092], from an
	application layer point-of-view, forwards all packets it receives on		application layer point-of-view, forwards all packets it receives on
	a negotiated connection, without inspecting or modifying the packet		a negotiated connection, without inspecting or modifying the packet
	contents. A media relay only modifies the transport layer (UDP/TCP)		contents. A media relay only modifies the transport layer (UDP/TCP)
	and IP headers.		and IP headers.
	A media relay B2BUA, as described in Section 3, forwards the		A media relay B2BUA follows the rule 1 mentioned in Section 3 and
	certificate fingerprint and SDP setup attribute it receives from one		forwards the certificate fingerprint and SDP setup attribute it
	endpoint unmodified towards the other endpoint and vice-versa. The		receives from one endpoint unmodified towards the other endpoint and
	example below shows a SIP call establishment flow, with both SIP		vice-versa. The example below shows a SIP call establishment flow,
	endpoints (user agents) using DTLS-SRTP, and a media relay B2BUA.		with both SIP endpoints (user agents) using DTLS-SRTP, and a media
			relay B2BUA.
	+-------+ +------------------+ +-----+		+-------+ +------------------+ +-----+
	| Alice | | MediaRelay B2BUA | | Bob |		| Alice | | MediaRelay B2BUA | | Bob |
	+-------+ +------------------+ +-----+		+-------+ +------------------+ +-----+
	|(1) INVITE | (3)INVITE |		|(1) INVITE | (3)INVITE |
	| a=setup:actpass | a=setup:actpass |		| a=setup:actpass | a=setup:actpass |
	| a=fingerprint1 | a=fingerprint1 |		| a=fingerprint1 | a=fingerprint1 |
	| (alice's IP/port) | (B2BUAs IP/port) |		| (alice's IP/port) | (B2BUAs IP/port) |
	|------------------------>|-------------------------->|		|------------------------>|-------------------------->|
	| | |		| | |
	skipping to change at page 11, line 49 ¶		skipping to change at page 11, line 49 ¶
	[I-D.ietf-avtext-rtp-grouping-taxonomy]		[I-D.ietf-avtext-rtp-grouping-taxonomy]
	Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and		Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
	B. Burman, "A Taxonomy of Semantics and Mechanisms for		B. Burman, "A Taxonomy of Semantics and Mechanisms for
	Real-Time Transport Protocol (RTP) Sources", draft-ietf-		Real-Time Transport Protocol (RTP) Sources", draft-ietf-
	avtext-rtp-grouping-taxonomy-08 (work in progress), July		avtext-rtp-grouping-taxonomy-08 (work in progress), July
	2015.		2015.
	[I-D.ietf-stir-rfc4474bis]		[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-07		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-08
	(work in progress), February 2016.		(work in progress), March 2016.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.		<http://www.rfc-editor.org/info/rfc3261>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,		Initiation Protocol (SIP)", RFC 4474,
	skipping to change at page 13, line 22 ¶		skipping to change at page 13, line 22 ¶
	Gonzalo Salgueiro		Gonzalo Salgueiro
	Cisco Systems, Inc.		Cisco Systems, Inc.
	7200-12 Kit Creek Road		7200-12 Kit Creek Road
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Email: gsalguei@cisco.com		Email: gsalguei@cisco.com
	Victor Pascual		Victor Pascual
	Quobis		Oracle
			Barcelona, Spain
	Email: victor.pascual.avila@gmail.com		Email: victor.pascual.avila@oracle.com
	Parthasarathi Ravindran		Parthasarathi Ravindran
	Nokia Networks		Nokia Networks
	Bangalore, Karnataka		Bangalore, Karnataka
	India		India
	Email: partha@parthasarathi.co.in		Email: partha@parthasarathi.co.in
End of changes. 13 change blocks.
	23 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/