< draft-ietf-ecrit-psap-callback-02.txt		draft-ietf-ecrit-psap-callback-03.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Informational H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: May 9, 2011 Nokia Siemens Networks		Expires: April 29, 2012 Nokia Siemens Networks
			C. Holmberg
			Ericsson
	M. Patel		M. Patel
	InterDigital Communications		InterDigital Communications
	November 5, 2010		October 27, 2011
	Public Safety Answering Point (PSAP) Callbacks		Public Safety Answering Point (PSAP) Callback
	draft-ietf-ecrit-psap-callback-02.txt		draft-ietf-ecrit-psap-callback-03.txt
	Abstract		Abstract
	After an emergency call is completed (either prematurely terminated		After an emergency call is completed (either prematurely terminated
	by the emergency caller or normally by the call-taker) it is possible		by the emergency caller or normally by the call-taker) it is possible
	that the call-taker feels the need for further communication or for a		that the call-taker feels the need for further communication. For
	clarification. For example, the call may have been dropped by		example, the call may have been dropped by accident without the call-
	accident without the call-taker having sufficient information about		taker having sufficient information about the current situation of a
	the current situation of a wounded person. A call-taker may trigger		wounded person. A call-taker may trigger a callback towards the
	a callback towards the emergency caller using the contact information		emergency caller using the contact information provided with the
	provided with the initial emergency call. This callback could, under		initial emergency call. This callback could, under certain
	certain circumstances, then be treated like any other call and as a		circumstances, be treated like any other call and as a consequence it
	consequence, it may get blocked by authorization policies or may get		may get blocked by authorization policies or may get forwarded to an
	forwarded to an answering machine.		answering machine.
	The IETF emergency services architecture addresses callbacks in a		The IETF emergency services architecture offers capabilities to allow
	limited fashion and thereby covers a couple of scenarios. This		callbask to bypass authorization policies to reach the caller without
	document discusses some shortcomings and illustrates an extension.		unnecessary delays. However, the mechanism specified prior to this
			document supports only limited scenarios. This document discusses
			some shortcomings, presents additional scenarios where better-than-
			normal call treatment behavior would be desirable, and specifies a
			protocol solution.
	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.
	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 May 9, 2011.		This Internet-Draft will expire on April 29, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the
			Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Multi-Stage Resolution . . . . . . . . . . . . . . . . . . 4		3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 5		3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 6
	1.4. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 7		3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 7
	1.5. Network-based Service URN Resolution . . . . . . . . . . . 7		3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 8
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4. Network-based Service URN Resolution . . . . . . . . . . . 10
	3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 11
	4. Callback Marking . . . . . . . . . . . . . . . . . . . . . . . 12		4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Tel URI . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	4.2. SIP URI . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . . 17		8.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19		Appendix A. Alternative Solutions Considered . . . . . . . . . . 19
			A.1. Identity-based Authorization . . . . . . . . . . . . . . . 19
			A.2. Trait-based Authorization . . . . . . . . . . . . . . . . 20
			A.3. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Summoning police, the fire department or an ambulance in emergencies		Summoning police, the fire department or an ambulance in emergencies
	is one of the fundamental and most-valued functions of the telephone.		is one of the fundamental and most-valued functions of the telephone.
	As telephone functionality moves from circuit-switched telephony to		As telephone functionality moves from circuit-switched telephony to
	Internet telephony, its users rightfully expect that this core		Internet telephony, its users rightfully expect that this core
	functionality will continue to work at least as well as it has for		functionality will continue to work at least as well as it has for
	the legacy technology. New devices and services are being made		the legacy technology. New devices and services are being made
	available that could be used to make a request for help, which are		available that could be used to make a request for help, which are
	not traditional telephones, and users are increasingly expecting them		not traditional telephones, and users are increasingly expecting them
	to be used to place emergency calls.		to be used to place emergency calls.
			An overview of the protocol interactions for emergency calling using
			the IETF emergency services architecture are described in
			[I-D.ietf-ecrit-framework] and [I-D.ietf-ecrit-phonebcp] specifies
			the technical details. As part of the emergency call setup procedure
			two important identifiers are conveyed to the PSAP call-taker's user
			agent, namely the Address-Of-Record (AoR), and the Globally Routable
			User Agent (UA) URIs (GRUU). RFC 3261 [RFC3261] defines the AoR as:
			An address-of-record (AOR) is a SIP or SIPS URI that points to a
			domain with a location service that can map the URI to another URI
			where the user might be available. Typically, the location
			service is populated through registrations. An AOR is frequently
			thought of as the "public address" of the user.
			In SIP systems a single user can have a number of user agents
			(handsets, softphones, voicemail accounts, etc.) which are all
			referenced by the same AOR. There are a number of cases in which it
			is desirable to have an identifier which addresses a single user
			agent rather than the group of user agents indicated by an AOR. The
			GRUU is such a unique user- agent identifier, which is still globally
			routable. [RFC5627] specifies how to obtain and use GRUUs.
	Regulatory requirements demand that the emergency call itself		Regulatory requirements demand that the emergency call itself
	provides enough information to allow the call-taker to initiate a		provides enough information to allow the call-taker to initiate a
	call back to the emergency caller in case the call dropped or to		call back to the emergency caller in case the call dropped or to
	interact with the emergency caller in case of further questions.		interact with the emergency caller in case of further questions. The
	Such a call, referred as PSAP callback subsequently in this document,		AoR and the GRUU serve this purpose. The communication attempt by
	may, however, be blocked or forwarded to an answering machine as SIP		the PSAP call-taker back to the emergency caller is called 'PSAP
	entities (SIP proxies as well as the SIP UA itself) cannot associate		callback'.
	the potential importantance of the call based on the SIP signaling.
	Note that the authors are, however, not aware of regulatory		A PSAP callback may, however, be blocked by user configured whitelis
	requirements for providing preferential treatment of callbacks		or may be forwarded to an answering machine as SIP entities (SIP
	initiated by the call-taker at the PSAP towards the emergency		proxies as well as the SIP UA itself) cannot differentiate the
	caller.		callback from any other SIP call establishing attempt from the SIP
			signaling message.
	Section 10 of [I-D.ietf-ecrit-framework] discusses the identifiers		While there are no regulatory requirements at the time of writing of
	required for callbacks, namely AOR URI and a globally routable URI in		this specification there is the believe that PSAP callbacks have to
	a Contact: header. Section 13 of [I-D.ietf-ecrit-framework] provides		be treated in such a way that they reach the emergency caller. For
	the following guidance regarding callback handling:		this purpose guidance for PSAP callback handling has been provided in
			Section 13 of [I-D.ietf-ecrit-framework]:
	A UA may be able to determine a PSAP call back by examining the		A UA may be able to determine a PSAP call back by examining the
	domain of incoming calls after placing an emergency call and		domain of incoming calls after placing an emergency call and
	comparing that to the domain of the answering PSAP from the		comparing that to the domain of the answering PSAP from the
	emergency call. Any call from the same domain and directed to the		emergency call. Any call from the same domain and directed to the
	supplied Contact header or AoR after an emergency call should be		supplied Contact header or AoR after an emergency call should be
	accepted as a call-back from the PSAP if it occurs within a		accepted as a callback from the PSAP if it occurs within a
	reasonable time after an emergency call was placed.		reasonable time after an emergency call was placed.
	This approach mimics a stateful packet filtering firewall and is		This approach mimics a stateful packet filtering firewall and is
	indeed helpful in a number of cases. It is also relatively simple to		indeed helpful in a number of cases. It is also relatively simple to
	implement. Below, we discuss a few cases where this approach fails.		implement. Unfortunately, it does not work in all SIP deployment
			scenarios. In Section 3 we describe scenarios where the currently
			standardized approach is insufficient. In Section 4 a solution is
			described.
	1.1. Routing Asymmetry		2. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			Emergency services related terminology is borrowed from [RFC5012].
			3. Callback Scenarios
			This section illustrates a number of scenarios where the currently
			specified solution, as specified in [I-D.ietf-ecrit-phonebcp], for
			preferential treatment of callbacks fails. As explained in Section 1
			a SIP entity examines an incoming PSAP call back by comparing the
			domain of the PSAP with the destination domain of the emergency call.
			3.1. Routing Asymmetry
	In some deployment environments it is common to have incoming and		In some deployment environments it is common to have incoming and
	outgoing SIP messaging to use different routes.		outgoing SIP messaging routed through different SIP entities.
			Figure 1 shows this graphically whereby a VoIP provider uses
			different SIP proxies for inbound and for outbound call handling.
			Unless they two devices are state synchronized the callback hitting
			the inbound proxy would get treated like any other call since the
			emergency call established state information at the outbound proxy
			only.
	,-------.		,-------.
	,' `.		,' `.
	,-------. / Emergency \		,-------. / Emergency \
	,' `. | Services |		,' `. | Services |
	/ VoIP \ I | Network |		/ VoIP \ I | Network |
	| Provider | n | |		| Provider | n | |
	| | t | |		| | t | |
	| | e | |		| | e | |
	| +-------+ | r | |		| +-------+ | r | |
	skipping to change at page 4, line 37 ¶		skipping to change at page 7, line 37 ¶
	| +--------+ | d | | | +------+ |		| +--------+ | d | | | +------+ |
	| | e || | |		| | e || | |
	| | r |+-+ |		| | r |+-+ |
	\ / | |		\ / | |
	`. ,' \ /		`. ,' \ /
	'-------' `. ,'		'-------' `. ,'
	'-------'		'-------'
	Figure 1: Example for Routing Asymmetry		Figure 1: Example for Routing Asymmetry
	1.2. Multi-Stage Resolution		3.2. Multi-Stage Routing
	Consider the following emergency call routing scenario shown in		Consider the following emergency call routing scenario shown in
	Figure 2 where routing towards the PSAP occurs in several stages. An		Figure 2 where routing towards the PSAP occurs in several stages. In
	emergency call uses a SIP UA that does not run LoST on the end point.		this scenario we consider a SIP UA that uses LoST to learn the next
	Hence, the call is marked with the 'urn:service:sos' Service URN		hop destination closer to the PSAP. This call is then sent to the
	[RFC5031]. The user's VoIP provider receives the emergency call and		user's VoIP provider. The user's VoIP provider receives the
	determines where to route it. Local configuration or a LoST lookup		emergency call and creates state based on the destination domain,
	might, in our example, reveal that emergency calls are routed via a		namely state.com. It then routes it to the indicated ESRP. When the
	dedicated provider FooBar and targeted to a specific entity, referred		ESRP receives it it needs to decide what the next hop is to get it
	as esrp1@foobar.com. FooBar does not handle emergency calls itself		closer to the PSAP. In our example the next hop is the PSAP with the
	but performs another resolution step to let calls enter the emergency		URI psap@town.com.
	services network and in this case another resolution step takes place
	and esrp-a@esinet.org is determined as the recipient, pointing to an
	edge device at the IP-based emergency services network. Inside the
	emergency services there might be more sophisticated routing taking
	place somewhat depending on the existing structure of the emergency
	services infrastructure.
	,-------.		When a callback is sent from psap@town.com towards the emergency
	+----+ ,' `.		caller the call will get normal treatment by the VoIP providers
	| UA |--- urn:service:sos / Emergency \		inbound proxy since the domain of the PSAP does not match the stored
	+----+ \ | Services |		state information.
	\ ,-------. | Network |
	,' `. | |
	/ VoIP \ | |
	( Provider ) | |
	\ / | |
	`. ,' | |
	'---+---' | +------+ |
	| | |PSAP | |
	esrp1@foobar.com | +--+---+ |
	| | | |
	| | | |
	,---+---. | | |
	,' `. | | |
	/ Provider \ | | |
	+ FooBar ) | | |
	\ / | | |
	`. ,' | +--+---+ |
	'---+---' | +-+ESRP | |
	| | | +------+ |
	| | | |
	+------------+-+ |
	esrp-a@esinet.org | |
	\ /
	`. ,'
	'-------'
	Figure 2: Example for Multi-Stage Resolution		,-------.
			+----+ ,' `.
			| UA |--- esrp1@foobar.com / Emergency \
			+----+ \ | Services |
			\ ,-------. | Network |
			,' `. | |
			/ VoIP \ | +------+ |
			( Provider ) | |PSAP | |
			\ / | +--+---+ |
			`. ,' | |
			'---+---' | | |
			| |psap@town.com |
			esrp@state.com | | |
			| | | |
			| | | |
			| | +--+---+ |
			+------------+---+ESRP | |
			| +------+ |
			| |
			\ /
			`. ,'
			'-------'
	1.3. Call Forwarding		Figure 2: Example for Multi-Stage Routing
			3.3. Call Forwarding
	Imagine the following case where an emergency call enters an		Imagine the following case where an emergency call enters an
	emergency network (state.org) via an ERSP but then gets forwarded to		emergency network (state.org) via an ERSP but then gets forwarded to
	a different emergency services network (in our example to police-		a different emergency services network (in our example to police-
	town.org, fire-town.org or medic-town.org). The same considerations		town.org, fire-town.org or medic-town.org). The same considerations
	apply when the the police, fire and ambulance networks are part of		apply when the the police, fire and ambulance networks are part of
	the state.org sub-domains (e.g., police.state.org).		the state.org sub-domains (e.g., police.state.org).
			Similarly to the previous scenario the problem here is with the wrong
			state information being established during the emergency call setup
			procedure. A callback would originate in the police-town.org, fire-
			town.org or medic-town.org domain whereas the emergency caller's SIP
			UA or the VoIP outbound proxy has stored state.org.
	,-------.		,-------.
	,' `.		,' `.
	/ Emergency \		/ Emergency \
	| Services |		| Services |
	| Network |		| Network |
	| (state.org) |		| (state.org) |
	| |		| |
	| |		| |
	| +------+ |		| +------+ |
	| |PSAP +--+ |		| |PSAP +--+ |
	skipping to change at page 7, line 5 ¶		skipping to change at page 10, line 5 ¶
	| , | | |		| , | | |
	`~~~~~~~~~~~~~~~ | +------+ | |		`~~~~~~~~~~~~~~~ | +------+ | |
	| |PSAP +----+ +		| |PSAP +----+ +
	| +------+ |		| +------+ |
	| |		| |
	| ,		| ,
	`~~~~~~~~~~~~~~~		`~~~~~~~~~~~~~~~
	Figure 3: Example for Call Forwarding		Figure 3: Example for Call Forwarding
	1.4. PSTN Interworking		3.4. Network-based Service URN Resolution
	In case an emergency call enters the PSTN, as shown in Figure 4,		The IETF emergency services architecture also considers cases where
			the resolution from the Service URN to the PSAP URI does not only
			happen at the SIP UA itself but at intermedidate SIP entities, such
			as the user's VoIP provider.
			Figure 4 shows this message exchange of the outgoing emergency call
			and the incoming PSAP graphically. While the state information
			stored at the VoIP provider is correct the state allocated at the SIP
			UA is not.
			,-------.
			,' `.
			/ Emergency \
			| Services |
			| Network |
			|police-town.org|
			| |
			| +------+ | Invite to police.example.com
			| |PSAP +<---+------------------------+
			| | +----+------------------+ ^
			| +------+ |Invite from | |
			| ,police.example.com| |
			`~~~~~~~~~~~~~~~ v |
			+--------+ ++-----+-+
			| | query |VoIP |
			| LoST |<-----------------------|Service |
			| Server | police.example.com |Provider|
			| |----------------------->| |
			+--------+ +--------+
			| ^
			Invite| | Invite
			from| | to
			police.example.com| | urn:service:sos
			V |
			+-------+
			| SIP |
			| UA |
			| Alice |
			+-------+
			Figure 4: Example for Network-based Service URN Resolution
			3.5. PSTN Interworking
			In case an emergency call enters the PSTN, as shown in Figure 5,
	there is no guarantee that the callback some time later does leave		there is no guarantee that the callback some time later does leave
	the same PSTN/VoIP gateway or that the same end point identifier is		the same PSTN/VoIP gateway or that the same end point identifier is
	used in the forward as well as in the backward direction making it		used in the forward as well as in the backward direction making it
	difficult to reliably detect PSAP callbacks.		difficult to reliably detect PSAP callbacks.
	+-----------+		+-----------+
	| PSTN |-------------+		| PSTN |-------------+
	| Calltaker | |		| Calltaker | |
	| Bob |<--------+ |		| Bob |<--------+ |
	+-----------+ | v		+-----------+ | v
	skipping to change at page 7, line 43 ¶		skipping to change at page 11, line 43 ¶
	| |		| |
	Invite Invite		Invite Invite
	| |		| |
	V |		V |
	+-------+		+-------+
	| SIP |		| SIP |
	| UA |		| UA |
	| Alice |		| Alice |
	+-------+		+-------+
	Figure 4: Example for PSTN Interworking		Figure 5: Example for PSTN Interworking
	1.5. Network-based Service URN Resolution		Note: This scenario is considered outside the scope of this document.
			The specified solution does not support this use case.
	The mechanism described in [I-D.ietf-ecrit-framework] assumes that		4. Specification
	all devices at the call signaling path store information about the
	domain of the communication recipient. This is necessary to match
	the stored domain name against the domain of the sender when an
	incoming call arrives.
	However, the IETF emergency services architecture also considers		[Editor's Note: The solution approach described in
	those cases where the resolution from the Service URN to the PSAP URI		[I-D.holmberg-emergency-callback-id] will be discussed at the IETF#82
	happens somewhere in the network rather than immediately at the end		ECRIT meeting and at the ECRIT mailing list and will be incorporated
	point itself. In such a case, the end device is therefore not able		here if agreed by the working group.]
	to match the domain of the sender with any information from the
	outgoing emergency call.
	Figure 5 shows this message exchange graphically.		5. Security Considerations
	,-------.		[Editor's Note: Instead of an abstract security description text will
	,' `.		be provided with the solution description.]
	/ Emergency \
	| Services |
	| Network |
	|police-town.org|
	| |
	| +------+ | Invite to police.example.com
	| |PSAP +<---+------------------------+
	| | +----+------------------+ ^
	| +------+ |Invite from | |
	| ,police.example.com| |
	`~~~~~~~~~~~~~~~ v |
	+--------+ ++-----+-+
	| | query |VoIP |
	| LoST |<-----------------------|Service |
	| Server | police.example.com |Provider|
	| |----------------------->| |
	+--------+ +--------+
	| ^
	Invite| | Invite
	from| | to
	police.example.com| | urn:service:sos
	V |
	+-------+
	| SIP |
	| UA |
	| Alice |
	+-------+
	Figure 5: Example for Network-based Service URN Resolution		6. IANA Considerations
	2. Terminology		[Editor's Note: IANA consideration text will be added once an
			agreement on the solution has been reached.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		7. Acknowledgements
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	Emergency services related terminology is borrowed from [RFC5012].		We would like to thank members from the ECRIT working group, in
			particular Brian Rosen, for their discussions around PSAP callbacks.
			The working group discussed the topic of callbacks at their virtual
			interim meeting in February 2010 and the following persons provided
			valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith
			Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,
			Janet Gunn.
	3. Architecture		At IETF#81 a small group of people got to together to continue the
			discussions started at the working group meeting to explore a GRUU-
			based solution approach. Martin Thomson, Marc Linsner, Andrew Allen,
			Brian Rosen, Martin Dolly, and Atle Monrad participated at this side-
			meeting.
	Section 4 describes how to mark a call as a callback. However, the		Finally, we would like to thank Cullen Jennings for his discussion
	pure emergency service callback marking is insufficient since it		input. He was the first to propose a "token-based" solution.
	lacks any built-in security mechanism. Fortunately, available SIP
	security techniques for the purpose of authorization can be re-used,		8. References
	as described in the rest of the section.
			8.1. Normative References
			[RFC2119] Bradner, S., "Key words for use
			in RFCs to Indicate Requirement
			Levels", BCP 14, RFC 2119,
			March 1997.
			[RFC3261] Rosenberg, J., Schulzrinne, H.,
			Camarillo, G., Johnston, A.,
			Peterson, J., Sparks, R.,
			Handley, M., and E. Schooler,
			"SIP: Session Initiation
			Protocol", RFC 3261, June 2002.
			[RFC3325] Jennings, C., Peterson, J., and
			M. Watson, "Private Extensions
			to the Session Initiation
			Protocol (SIP) for Asserted
			Identity within Trusted
			Networks", RFC 3325,
			November 2002.
			[RFC3966] Schulzrinne, H., "The tel URI
			for Telephone Numbers",
			RFC 3966, December 2004.
			[RFC3969] Camarillo, G., "The Internet
			Assigned Number Authority
			(IANA) Uniform Resource
			Identifier (URI) Parameter
			Registry for the Session
			Initiation Protocol (SIP)",
			BCP 99, RFC 3969,
			December 2004.
			[RFC4474] Peterson, J. and C. Jennings,
			"Enhancements for Authenticated
			Identity Management in the
			Session Initiation Protocol
			(SIP)", RFC 4474, August 2006.
			[RFC5341] Jennings, C. and V. Gurbani,
			"The Internet Assigned Number
			Authority (IANA) tel Uniform
			Resource Identifier (URI)
			Parameter Registry",
			September 2008.
			[RFC5627] Rosenberg, J., "Obtaining and
			Using Globally Routable User
			Agent URIs (GRUUs) in the
			Session Initiation Protocol
			(SIP)", RFC 5627, October 2009.
			8.2. Informative References
			[I-D.holmberg-emergency-callback-id] Holmberg, C., "Session
			Initiation Protocol (SIP)
			emergency call back
			identification", draft-
			holmberg-emergency-callback-id-
			00 (work in progress),
			October 2011.
			[I-D.ietf-ecrit-framework] Rosen, B., Schulzrinne, H.,
			Polk, J., and A. Newton,
			"Framework for Emergency
			Calling using Internet
			Multimedia",
			draft-ietf-ecrit-framework-13
			(work in progress),
			September 2011.
			[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best
			Current Practice for
			Communications Services in
			support of Emergency Calling",
			draft-ietf-ecrit-phonebcp-20
			(work in progress),
			September 2011.
			[I-D.ietf-sip-saml] Tschofenig, H., Hodges, J.,
			Peterson, J., Polk, J., and D.
			Sicker, "SIP SAML Profile and
			Binding",
			draft-ietf-sip-saml-08 (work in
			progress), October 2010.
			[RFC4484] Peterson, J., Polk, J., Sicker,
			D., and H. Tschofenig, "Trait-
			Based Authorization
			Requirements for the Session
			Initiation Protocol (SIP)",
			RFC 4484, August 2006.
			[RFC5012] Schulzrinne, H. and R.
			Marshall, "Requirements for
			Emergency Context Resolution
			with Internet Technologies",
			RFC 5012, January 2008.
			[RFC5031] Schulzrinne, H., "A Uniform
			Resource Name (URN) for
			Emergency and Other Well-Known
			Services", RFC 5031,
			January 2008.
			[RFC5234] Crocker, D. and P. Overell,
			"Augmented BNF for Syntax
			Specifications: ABNF", STD 68,
			RFC 5234, January 2008.
			Appendix A. Alternative Solutions Considered
			In an attempt to describe the problem and to explore solution
			approaches the working group had also investigated alternative
			approaches. We document them here for completeness. The solutions
			fall into three categories: (1) Identity-based authorization, (2)
			Trait-based authorization, and (3) Call Marking. Even though these
			solutions are not mutually exclusive we describe them in separate
			sub-sections.
			Beyond the disadvantages listed in each solution category none of
			them provides the emergency caller with the ability to restrict
			preferential PSAP callback handling to those cases where an earlier
			emergency call was initiated.
			A.1. Identity-based Authorization
	In Figure 6 an interaction is presented that allows a SIP entity to		In Figure 6 an interaction is presented that allows a SIP entity to
	make a policy decision whether to bypass installed authorization		make a policy decision whether to bypass installed authorization
	policies and thereby providing preferential treatment. To make this		policies and thereby providing preferential treatment. To make this
	decision the sender's identity is compared with a whitelist of valid		decision the sender's identity is compared with a whitelist of valid
	PSAPs. The identity assurances in SIP can come in different forms,		PSAPs. The identity assurances in SIP can come in different forms,
	such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].		such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].
	The former technique relies on a cryptographic assurance and the		The former technique relies on a cryptographic assurance and the
	latter on a chain of trust.		latter on a chain of trust.
	skipping to change at page 10, line 47 ¶		skipping to change at page 20, line 30 ¶
	+----------+		+----------+
	||		||
	||		||
	|| Preferential		|| Preferential
	|| Treatment		|| Treatment
	++=============>		++=============>
	(in whitelist)		(in whitelist)
	Figure 6: Identity-based Authorization		Figure 6: Identity-based Authorization
	The establishment of a whitelist with PSAP identities is		This approach was not chosen because the establishment of a whitelist
	operationally complex and does not easily scale world wide. When		containing PSAP identities is operationally complex and does not
	there is a local relationship between the VSP/ASP and the PSAP then		easily scale world wide. Only when there is a local relationship
	populating the whitelist is far simpler.		between the VSP/ASP and the PSAP then populating the whitelist is far
			simpler. This would, however, constrain the applicability of the
			mechanism considerably.
			A.2. Trait-based Authorization
	An alternative approach to an identity based authorization model is		An alternative approach to an identity based authorization model is
	outlined in Figure 7. In fact, RFC 4484 [RFC4484] already		outlined in Figure 7. In fact, RFC 4484 [RFC4484] illustrates a
	illustrated the basic requirements for this technique.		related emergency service use case.
	+----------+		+----------+
	| List of |+		| List of |+
	| trust ||		| trust ||
	| anchor ||		| anchor ||
	+----------+|		+----------+|
	+----------+		+----------+
	*		*
	*		*
	*		*
	skipping to change at page 12, line 5 ¶		skipping to change at page 21, line 41 ¶
	In a trait-based authorization scenario an incoming SIP message		In a trait-based authorization scenario an incoming SIP message
	contains a form of trait, i.e. some form of assertion. The assertion		contains a form of trait, i.e. some form of assertion. The assertion
	contains an indication that the sending party has the role of a PSAP		contains an indication that the sending party has the role of a PSAP
	(or similar emergency services entity). The assertion is either		(or similar emergency services entity). The assertion is either
	cryptographically protected to enable end-to-end verification or an		cryptographically protected to enable end-to-end verification or an
	chain of trust security model has to be assumed. In Figure 7 we		chain of trust security model has to be assumed. In Figure 7 we
	assume an end-to-end security model where trust anchors are		assume an end-to-end security model where trust anchors are
	provisioned to ensure the ability for a SIP entity to verify the		provisioned to ensure the ability for a SIP entity to verify the
	received assertion.		received assertion.
	4. Callback Marking		This solution was not chosen because trait-based authorization never
			got deployed in SIP. Furthermore, in order to ensure that the
	The callback marking is represented as URI parameter for an URI		assertions are properly protected it is necessary to digitally sign,
	scheme. The ABNF [RFC5234] syntax is shown below.		which requires some form of public key infrastructure for usage with
			emergency services. Finally, there need to be some policies in place
	4.1. Tel URI		that define which entities are allowed to obtain various roles.
			These policies and procedures do not exist today.
	The 'par' production is defined in RFC 3966 [RFC3966]. The "/="
	syntax indicates an extension of the production on the left-hand
	side:
	par /= callback
	callback = callback-tag "=" callback-value
	callback-tag = "callback"
	callback-value = "normal" / "test" /
	The semantics of the callback values are described below:
	normal: This represents an normal PSAP callback.
	test: This is a test callback.
	An example of the "callback" parameter is given below:
	P-Asserted-Identity: <tel:+17005554141;callback=test>
	4.2. SIP URI
	The 'uri-parameter' production is defined in RFC 3966 [RFC3261]. The
	"/=" syntax indicates an extension of the production on the left-hand
	side:
	uri-parameter =/ callback
	callback = callback-tag "=" callback-value
	callback-tag = "callback"
	callback-value = "normal" / "test" /
	The semantics of the callback values are described below:
	normal: This represents an normal PSAP callback.
	test: This is a test callback.
	An example of the "callback" parameter is given below:
	P-Asserted-Identity: <sip:psap@example.com;callback=normal>
	5. Security Considerations
	This document defines a callback marking scheme using URI parameters
	and illustrates how to handle authorization for preferential
	treatment. The URI parameter that is included for a URI MUST be used
	in concert with either the PAI [RFC3325] or the SIP Identity
	[RFC4474] header. A pure From header does not provide security
	assurance that the calling party is indeed a PSAP.
	An important aspect from a security point of view is the relationship
	between the emergency services network and the VSP (assuming that the
	emergency call travels via the VSP and not directly between the SIP
	UA and the PSAP). If there is some form of relationship between the
	emergency services operator and the VSP then the identification of a
	PSAP call back is less problematic than in the case where the two
	entities have not entered in some form of relationship that would
	allow the VSP to verify whether the marked callback message indeed
	came from a legitimate source.
	The main attack surface can be seen in the usage of PSAP callback
	marking to bypass blacklists, ignore call forwarding procedures and
	similar features to interact with users and to get their attention.
	For example, using PSAP callback marking devices would be able to
	recognize these types of incoming messages leading to the device
	overriding user interface configurations, such as vibrate-only mode.
	As such, the requirement is to ensure that the mechanisms described
	in this document can not be used for malicious purposes, including
	SPIT.
	A SIP entity MAY treat the call as a normal incoming call if it
	considers the request with the included URI parameter to be
	fraudulent, i.e. if it does not recognize the originator, or the
	domain from where the call originated from as being trusted/owned by
	a PSAP. It is NOT RECOMMENDED to drop a call that is marked as PSAP
	callback in such a case since this may severely impact the ability
	for calltakers at PSAPs to contact emergency callers.
	6. IANA Considerations
	This document extends the registry of URI parameters for SIP, as
	defined in RFC 3969 [RFC3969]. A new SIP URI parameter is defined in
	this document as follows:
	Parameter Name: callback
	Predefined Values: Yes
	Reference: This document
	This document extends the registry of Tel URI parameters for SIP, as
	defined in RFC 5341[RFC5341]. A new Tel URI parameter is defined in
	this document as follows:
	Parameter Name: callback
	Predefined Values: Yes
	Reference: This document
	7. Acknowledgements
	We would like to thank members from the ECRIT working group, in
	particular Brian Rosen, for their discussions around PSAP callbacks.
	The working group discussed the topic of callbacks at their virtual
	interim meeting in February 2010 and the following persons provided
	valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith
	Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,
	Janet Gunn.
	8. References
	8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.
	[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
	Extensions to the Session Initiation Protocol (SIP) for
	Asserted Identity within Trusted Networks", RFC 3325,
	November 2002.
	[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
	RFC 3966, December 2004.
	[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
	(IANA) Uniform Resource Identifier (URI) Parameter
	Registry for the Session Initiation Protocol (SIP)",
	BCP 99, RFC 3969, December 2004.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.
	[RFC5341] Jennings, C. and V. Gurbani, "The Internet Assigned Number
	Authority (IANA) tel Uniform Resource Identifier (URI)
	Parameter Registry", September 2008.
	8.2. Informative References
	[I-D.ietf-ecrit-framework]
	Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling using Internet
	Multimedia", draft-ietf-ecrit-framework-12 (work in
	progress), October 2010.
	[I-D.ietf-sip-saml]
	Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D.
	Sicker, "SIP SAML Profile and Binding",
	draft-ietf-sip-saml-08 (work in progress), October 2010.
	[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
	"Trait-Based Authorization Requirements for the Session
	Initiation Protocol (SIP)", RFC 4484, August 2006.
	[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for		A.3. Call Marking
	Emergency Context Resolution with Internet Technologies",
	RFC 5012, January 2008.
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for		Call marking allows the PSAP to place a non-cryptographic label on
	Emergency and Other Well-Known Services", RFC 5031,		outgoing calls that gives, when received by a SIP entity,
	January 2008.		preferential treatment for these callbacks.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		When used in isolation this mechanism introduces considerable denial
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		of service attacks due to the ability to bypass any authorization
			policies and could be utilized to distribute unwanted traffic.
	Authors' Addresses		Authors' Addresses
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+ecrit@cs.columbia.edu		EMail: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		EMail: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
			Christer Holmberg
			Ericsson
			Hirsalantie 11
			Jorvas 02420
			Finland
			EMail: christer.holmberg@ericsson.com
	Milan Patel		Milan Patel
	InterDigital Communications		InterDigital Communications
	Email: Milan.Patel@interdigital.com		EMail: Milan.Patel@interdigital.com
End of changes. 48 change blocks.
	344 lines changed or deleted		394 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/