< draft-ietf-sip-connect-reuse-00.txt		draft-ietf-sip-connect-reuse-01.txt >
	SIP WG R. Mahy		SIP WG R. Mahy
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Expires: January 30, 2004 Aug 2003		Expires: August 1, 2004 Feb 2004
	Connection Reuse in the Session Initiation Protocol (SIP)		Connection Reuse in the Session Initiation Protocol (SIP)
	draft-ietf-sip-connect-reuse-00.txt		draft-ietf-sip-connect-reuse-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 30 ¶		skipping to change at page 1, line 30 ¶
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 30, 2004.		This Internet-Draft will expire on August 1, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	When SIP entities use a connection oriented protocol to send a		When SIP entities use a connection oriented protocol to send a
	request, they typically originate their connections from an ephemeral		request, they typically originate their connections from an ephemeral
	port. The SIP protocol includes mechanisms which insure that		port. The SIP protocol includes mechanisms which insure that
	responses to a request, and new requests sent in the original		responses to a request, and new requests sent in the original
	direction reuse an existing connection. However, new requests sent		direction reuse an existing connection. However, new requests sent
	in the opposite direction are unlikely to reuse the existing		in the opposite direction are unlikely to reuse the existing
	connection. This frequently causes a pair of SIP entities to use one		connection. This frequently causes a pair of SIP entities to use one
	connection for requests sent in each direction, and can result in		connection for requests sent in each direction, and can result in
	potential scaling and performance problems. This document proposes		potential scaling and performance problems. This document proposes
	requirements and a mechanism which address this deficiency.		requirements and a mechanism which address this deficiency.
	Table of Contents		Table of Contents
	1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction and Problem Statement . . . . . . . . . . . . . . 3		2. Introduction and Problem Statement . . . . . . . . . . . . . . 3
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Overview of Proposed Mechanism . . . . . . . . . . . . . . . . 6		4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1 Authorizing an alias request . . . . . . . . . . . . . . . . . 8		4.1 Authorizing an alias request . . . . . . . . . . . . . . . . . 8
	4.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	Normative References . . . . . . . . . . . . . . . . . . . . . 9		Normative References . . . . . . . . . . . . . . . . . . . . . 11
	Informational References . . . . . . . . . . . . . . . . . . . 10		Informational References . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . 13
	1. Conventions		1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [2].		document are to be interpreted as described in RFC-2119 [2].
	2. Introduction and Problem Statement		2. Introduction and Problem Statement
	SIP [1] entities can communicate using either unreliable/		SIP [1] entities can communicate using either unreliable/
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 23 ¶
	4. A connection sharing mechanism MUST NOT require configuring		4. A connection sharing mechanism MUST NOT require configuring
	ephemeral port numbers in DNS.		ephemeral port numbers in DNS.
	5. A connection sharing mechanism MUST prevent unauthorized		5. A connection sharing mechanism MUST prevent unauthorized
	hijacking of other connections.		hijacking of other connections.
	6. Connection sharing SHOULD persist across SIP transactions and		6. Connection sharing SHOULD persist across SIP transactions and
	dialogs.		dialogs.
	4. Overview of Proposed Mechanism		4. Behavior
	The proposed mechanism uses a new Via header field parameter. The		The proposed mechanism uses a new Via header field parameter. The
	"alias" parameter is included in a Via header field value to indicate		"alias" parameter is included in a Via header field value to indicate
	that the originator of the request wants to create a transport layer		that the originator of the request wants to create a transport layer
	alias, so that the sent-by address becomes mapped to the current		alias, so that the sent-by address becomes mapped to the current
	connection.		connection.
	Assuming the Via header field value shown below from the most recent		Assuming the Via header field value shown below from the most recent
	request arrived over a connection from 60.54.32.1 port 8241:		request arrived over a connection from 10.54.32.1 port 8241:
	Via: SIP/2.0/TLS 60.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias		Via: SIP/2.0/TLS 10.54.32.1:5061;branch=z9hG4bKa7c8dze ;alias
	The transport layer creates an alias, such that any requests going to		The transport layer creates an alias, such that any requests going to
	the "advertised address" (60.54.32.1 port 5061) are instead sent over		the "advertised address" (10.54.32.1 port 5061) are instead sent over
	the existing connection (to the "target" of the alias) which is		the existing connection (to the "target" of the alias) which is
	coming from port 8241. This sharing continues as long as the target		coming from port 8241. This sharing continues as long as the target
	connection stays up. The SIP community recommends that servers keep		connection stays up. The SIP community recommends that servers keep
	connections up unless they need to reclaim resources, and that		connections up unless they need to reclaim resources, and that
	clients keep connections up as long as they are needed. Connection		clients keep connections up as long as they are needed. Connection
	reuse works best when the client and the server maintain their		reuse works best when the client and the server maintain their
	connections for long periods of time. SIP entities therefore SHOULD		connections for long periods of time. SIP entities therefore SHOULD
	NOT drop connections on completion of a transaction or termination of		NOT drop connections on completion of a transaction or termination of
	a dialog.		a dialog.
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 23 ¶
	+-----------+ | Proxy |		+-----------+ | Proxy |
	+-----------+ 8293 5061 | B |		+-----------+ 8293 5061 | B |
	| |<======================>| |		| |<======================>| |
	| Proxy | +-----------+		| Proxy | +-----------+
	| A2 |		| A2 |
	| |		| |
	+-----------+		+-----------+
	For example, on receipt of a message with the topmost Via header		For example, on receipt of a message with the topmost Via header
	shown below, the transport layer creates an alias such that requests		shown below, the transport layer creates an alias such that requests
	going to the advertised address (host-a.atlanta.com) are sent over		going to the advertised address (proxy-farm-a.example.com) are sent
	the target connection (from 60.54.32.1:8241).		over the target connection (from 10.54.32.1:8241).
	Via: SIP/2.0/TLS host-a.atlanta.com;branch=z9hG4bK7c8dze ;alias		Via: SIP/2.0/TLS proxy-farm-a.example.com;branch=z9hG4bK7c8ze;alias
	As a result, this has an important interaction with the DNS		As a result, this has an important interaction with the DNS
	resolution mechanisms for SIP described in RFC3263 [6]. When new		resolution mechanisms for SIP described in RFC3263 [6]. When new
	requests arrive for host-a.atlanta.com, proxy B still needs to		requests arrive for proxy-farm-a.example.com, proxy B still needs to
	perform a DNS NAPTR lookup to select the transport. Once the		perform a DNS NAPTR lookup to select the transport. Once the
	transport is selected, an SRV lookup would ordinarily occur to find		transport is selected, an SRV lookup would ordinarily occur to find
	the appropriate port number. In this case, the transport layer uses a		the appropriate port number. In this case, the transport layer uses a
	connection reuse alias instead of performing the SRV query.		connection reuse alias instead of performing the SRV query.
	Below is a partial DNS zone file for atlanta.com.		Below is a partial DNS zone file for atlanta.com.
	; NAPTR queries for the current domain (atlanta.com)		; NAPTR queries for the current domain (example.com)
	;		;
	; order pref flags service regexp replacement		; order pref flags service regexp replacement
	@ IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.		proxy-farm-a IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.
	; SRV records for the proxy use 5060/5061		; SRV records for the proxy use 5060/5061
	;		;
	;; Priority Weight Port Target		;; Priority Weight Port Target
	_sips._tcp.host-a IN SRV 0 1 5061 host-a1		_sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a1
	_sips._tcp.host-a IN SRV 0 1 5061 host-a2		_sips._tcp.proxy-farm-a IN SRV 0 1 5061 host-a2
	host-a1 IN A 60.54.32.1		host-a1 IN A 10.54.32.1
	host-a2 IN A 60.54.32.2		host-a2 IN A 10.54.32.2
	The existence of an alias parameter is treated as a request which		The existence of an alias parameter is treated as a request which
	asks the transport layer to create an alias (named by the sent-by		asks the transport layer to create an alias (named by the sent-by
	parameter, which could be a hostname) that points to the alias		parameter, which could be a hostname) that points to the alias
	target (the current connection)		target (the current connection)
	This mechanism is fully backwards compatible with existing		This mechanism is fully backwards compatible with existing
	implementations. If the proposed Via parameter is not understood by		implementations. If the proposed Via parameter is not understood by
	the recipient, it will be ignored and the two implementations will		the recipient, it will be ignored and the two implementations will
	revert to current behavior (two connections).		revert to current behavior (two connections).
	skipping to change at page 8, line 31 ¶		skipping to change at page 8, line 31 ¶
	To correctly authorize an alias, both the active connection and the		To correctly authorize an alias, both the active connection and the
	alias need to authenticate using the same credentials. This could be		alias need to authenticate using the same credentials. This could be
	accomplished using one of two mechanisms. The first (and preferred)		accomplished using one of two mechanisms. The first (and preferred)
	mechanism is using TLS mutual authentication, such that the		mechanism is using TLS mutual authentication, such that the
	subjectAltName of the originator certificate corresponds to both the		subjectAltName of the originator certificate corresponds to both the
	current connection and the target address of the alias. The Via		current connection and the target address of the alias. The Via
	sent-by address needs to be within the scope protected by the		sent-by address needs to be within the scope protected by the
	certificate presented by the originator during TLS mutual		certificate presented by the originator during TLS mutual
	authentication and the received IP address needs be a valid IP		authentication and the received IP address needs be a valid IP
	address for the sent-by host or hosts. In other words, the sent-by		address for the sent-by host or hosts. In other words, the sent-by
	address and port combination MUST be resolvable from the		address MUST be resolvable from the subjectAltName of the originator
	subjectAltName of the originator certificate, and the received IP		certificate, and the received IP address MUST be resolvable from the
	address MUST be resolvable from the sent-by address. This is in		sent-by address. This is in addition to other requirements for TLS
	addition to other requirements for TLS authentication and		authentication and authorization discussed in SIP [1] and Locating
	authorization discussed in SIP [1] and Locating SIP Servers [6].		SIP Servers [6].
			Following this logic step-by-step:
			1. Verify that the certificate presented is not expired and is
			rooted in a trusted certificate chain.
			2. Verify that the subjectAltName in the certificate covers the
			"advertised address" (the address in the Via sent-by production).
			If the advertised address and the subjectAltName match exactly
			then the certificate covers the address. Also, use DNS to
			resolve if the advertised name is resolvable from the
			subjectAltName (start by resolving the subjectAltName with first
			NAPTR, next SRV, then finally address records). If any of the
			resolved addresses (port numbers can be ignored in this case)
			matches the advertised address, then the certificate covers the
			address.
			3. Finally, Verify that the advertised address can resolve to the IP
			address over which the connection was received.
			For example, take the example in the previous section of proxy B
			receiving an alias request from host-a2.example.com. Proxy B
			verifies that the presented certificate is valid and trusted. Proxy B
			checks that proxy-farm-a.example.com is both the advertised name and
			the subjectAltName in the certificate. Finally, proxy B verifies
			that this connection is coming from 10.54.32.2, which is one of the
			addresses in DNS for proxy-farm-a.example.com
	The second mechanism is to accept an alias if the target address of		The second mechanism is to accept an alias if the target address of
	the alias is equivalent (using SIP comparison rules) to a valid		the alias is equivalent (using SIP comparison rules) to a valid
	Contact already registered by the same user. This user could be		Contact already registered by the same user. This user could be
	authenticated through any SIP or TLS mechanism (ex: user certificate,		authenticated through any SIP or TLS mechanism (ex: user certificate,
	or Kerberos [10]), but would typically use Digest authentication [5].		or Kerberos [10]), but would typically use Digest authentication [5].
	For example, if Alice registers a Contact of 123.45.67.89:5061, she		For example, if Alice registers a Contact of 198.168.67.89:5061, she
	could inform Proxy 1 of the existence of a connection to her from		could inform Proxy 1 of the existence of a connection to her from
	Proxy 2. This would allow her to preemptively originate TLS		Proxy 2. This would allow her to preemptively originate TLS
	connections, as her user agent may not have access to a site		connections, as her user agent may not have access to a site
	certificate with which to authenticate incoming TLS connections.		certificate with which to authenticate incoming TLS connections.
			The Proxy takes the following steps to authorize these requests:
			1. The Proxy authenticates or authorizes the sender for an otherwise
			ordinary SIP request.
			2. The Proxy looks for any Contacts in the location/registration
			service which have a hostport and transport that matches exactly
			the advertised address.
			3. The Proxy checks if the user who sent the request would be
			authorized to change the Contact found when looking up the
			Contact URI in the location/registration service.
			For example, Alice advertises the address "198.168.67.89:5061" in a
			request sent over a connection from "198.168.67.89:8293" to Proxy 2.
			The Proxy otherwise authenticates Alice's request (for example an
			INVITE request). The Proxy looks up 198.168.67.89:5061 and finds the
			following Contact: "Alice" <sips:reg2@198.168.67.89:5061>. Alice is
			authorized to modify Alice's contact, so Alice is authorized to alias
			an advertised address "reserved" by one of her Contacts. Alice then
			sends another request (this time an OPTIONS request for example) to
			Proxy 1 from "198.168.67.89.8672" with the same Via header. Proxy 1
			similarly authorizes Alice's request and stores the alias. Now if
			either proxy receives a request for 198.168.67.89:5061, it will
			forward the request over the appropriate existing connection with
			Alice.
			Via: SIP/2.0/TLS 198.168.67.89:5061;branch=z9hG4bK7c8dze ;alias
	+-----------+		+-----------+
	| |		| |
	| Proxy |		| Proxy |
	+-----------+ 8672 5061 | 1 |		+-----------+ 8672 5061 | 1 |
	| |----------------------->| |		| |----------------------->| |
	| Alice | +-----------+		| Alice | +-----------+
	| | +-----------+		| | +-----------+
	| |----------------------->| |		| |----------------------->| |
	+-----------+ 8293 5061 | Proxy |		+-----------+ 8293 5061 | Proxy |
	| 2 |		| 2 |
	skipping to change at page 9, line 34 ¶		skipping to change at page 10, line 41 ¶
	5. Security Considerations		5. Security Considerations
	This document presents requirements and a mechanism for reusing		This document presents requirements and a mechanism for reusing
	existing connections easily. Connection reuse presents many		existing connections easily. Connection reuse presents many
	opportunities for abuse and hijacking, but these attacks can be		opportunities for abuse and hijacking, but these attacks can be
	prevented if the guidelines in the authorization section are		prevented if the guidelines in the authorization section are
	followed.		followed.
	6. IANA Considerations		6. IANA Considerations
	This document introduces no additional considerations for IANA.		This document adds a parameter to the SIP header field parameters
			registry:
			Header field in which parameter can appear: Via
			Name of the parameter: alias
			Reference: This document (RFC editor, please replace
			with the RFC number of this document)
	7. Acknowledgments		7. Acknowledgments
	Thanks to Jon Peterson for helpful answers about certificate behavior		Thanks to Jon Peterson for helpful answers about certificate behavior
	with SIP, Jonathan Rosenberg for his initial support of this concept,		with SIP, Jonathan Rosenberg for his initial support of this concept,
	and Cullen Jennings for providing a sounding board for this idea.		and Cullen Jennings for providing a sounding board for this idea.
	Normative References		Normative References
	[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	skipping to change at page 10, line 43 ¶		skipping to change at page 12, line 9 ¶
	Service (V5)", RFC 1510, September 1993.		Service (V5)", RFC 1510, September 1993.
	[11] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,		[11] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
	H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,		H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
	"Stream Control Transmission Protocol", RFC 2960, October 2000.		"Stream Control Transmission Protocol", RFC 2960, October 2000.
	Author's Address		Author's Address
	Rohan Mahy		Rohan Mahy
	Cisco Systems, Inc.		Cisco Systems, Inc.
	101 Cooper Street		5617 Scotts Valley Dr
	Santa Cruz, CA 95060		Scotts Valley, CA 95066
	USA		USA
	EMail: rohan@cisco.com		EMail: rohan@cisco.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	skipping to change at page 11, line 29 ¶		skipping to change at page 13, line 29 ¶
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 23 change blocks.
	37 lines changed or deleted		99 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/