< draft-ietf-ecrit-psap-callback-08.txt		draft-ietf-ecrit-psap-callback-09.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: August 29, 2013 Nokia Siemens Networks		Expires: September 20, 2013 Nokia Siemens Networks
	C. Holmberg		C. Holmberg
	Ericsson		Ericsson
	M. Patel		M. Patel
	InterDigital Communications		InterDigital Communications
	February 25, 2013		March 19, 2013
	Public Safety Answering Point (PSAP) Callback		Public Safety Answering Point (PSAP) Callback
	draft-ietf-ecrit-psap-callback-08.txt		draft-ietf-ecrit-psap-callback-09.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. For		that the call taker feels the need for further communication. For
	example, the call may have been dropped by accident without the call		example, the call may have been dropped by accident without the call
	taker having sufficient information about the current situation of a		taker having sufficient information about the current situation of a
	wounded person. A call taker may trigger a callback towards the		wounded person. A call taker may trigger a callback towards the
	emergency caller using the contact information provided with the		emergency caller using the contact information provided with the
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 August 29, 2013.		This Internet-Draft will expire on September 20, 2013.
	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 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12		4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12
	4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 13		5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 13
	5.2. Security Requirements . . . . . . . . . . . . . . . . . . 13		5.2. Security Requirements . . . . . . . . . . . . . . . . . . 13
	5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 13		5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8.2. Informative References . . . . . . . . . . . . . . . . . . 17
	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		An overview of the protocol interactions for emergency calling using
	the IETF emergency services architecture are described in [RFC6444]		the IETF emergency services architecture are described in [RFC6443]
	and [I-D.ietf-ecrit-phonebcp] specifies the technical details. As		and [RFC6881] specifies the technical details. As part of the
	part of the emergency call setup procedure two important identifiers		emergency call setup procedure two important identifiers are conveyed
	are conveyed to the PSAP call taker's user agent, namely the Address-		to the PSAP call taker's user agent, namely the Address-Of-Record
	Of-Record (AoR), and, if available, the Globally Routable User Agent		(AOR), and, if available, the Globally Routable User Agent (UA) URIs
	(UA) URIs (GRUU). RFC 3261 [RFC3261] defines the AoR as:		(GRUU). RFC 3261 [RFC3261] defines the AOR as:
	'An address-of-record (AOR) is a SIP or SIPS URI that points to a		"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		domain with a location service that can map the URI to another URI
	where the user might be available. Typically, the location		where the user might be available. Typically, the location
	service is populated through registrations. An AOR is frequently		service is populated through registrations. An AOR is frequently
	thought of as the "public address" of the user.'		thought of as the "public address" of the user."
	In SIP systems a single user can have a number of user agents		In SIP systems a single user can have a number of user agents
	(handsets, softphones, voicemail accounts, etc.) which are all		(handsets, softphones, voicemail accounts, etc.) which are all
	referenced by the same AOR. There are a number of cases in which it		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		is desirable to have an identifier which addresses a single user
	agent rather than the group of user agents indicated by an AOR. The		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		GRUU is such a unique user-agent identifier, which is still globally
	routable. RFC 5627 [RFC5627] specifies how to obtain and use GRUUs.		routable. RFC 5627 [RFC5627] specifies how to obtain and use GRUUs.
	[I-D.ietf-ecrit-phonebcp] also makes use of the GRUU for emergency		[RFC6881] also makes use of the GRUU for emergency calls.
	calls.
	Regulatory requirements demand that the emergency call setup		Regulatory requirements demand that the emergency call setup
	procedure itself provides enough information to allow the call taker		procedure itself provides enough information to allow the call taker
	to initiate a call back to the emergency caller. This is desirable		to initiate a callback to the emergency caller. This is desirable in
	in those cases where the call got dropped prematurely or when further		those cases where the call got dropped prematurely or when further
	communication need arises. The AoR and the GRUU serve this purpose.		communication need arises. The AOR and the GRUU serve this purpose.
	The communication attempt by the PSAP call taker back to the		The communication attempt by the PSAP call taker back to the
	emergency caller is called 'PSAP callback'.		emergency caller is called 'PSAP callback'.
	A PSAP callback may, however, be blocked by user configured		A PSAP callback may, however, be blocked by user configured
	authorization policies or may be forwarded to an answering machine		authorization policies or may be forwarded to an answering machine
	since SIP entities (SIP proxies as well as the SIP user equipment		since SIP entities (SIP proxies as well as the SIP user equipment
	itself) cannot differentiate the PSAP callback from any other SIP		itself) cannot differentiate the PSAP callback from any other SIP
	call. "Call barring", "do not disturb", or "call diversion"(aka call		call. "Call barring", "do not disturb", or "call diversion"(aka call
	forwarding) are features that prevent delivery of a call. It is		forwarding) are features that prevent delivery of a call. It is
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 21 ¶
	reaches the emergency caller. At the same time a design must deal		reaches the emergency caller. At the same time a design must deal
	with the negative side-effects of allowing certain calls to bypass		with the negative side-effects of allowing certain calls to bypass
	call forwarding or other authorization policies. Ideally, the PSAP		call forwarding or other authorization policies. Ideally, the PSAP
	callback has to relate to an earlier emergency call that was made		callback has to relate to an earlier emergency call that was made
	"not too long ago". An exact time interval is difficult to define in		"not too long ago". An exact time interval is difficult to define in
	a global IETF standard due to the variety of national regulatory		a global IETF standard due to the variety of national regulatory
	requirements.		requirements.
	To nevertheless meet the needs from the emergency services community		To nevertheless meet the needs from the emergency services community
	a basic mechanism for preferential treatment of PSAP callbacks was		a basic mechanism for preferential treatment of PSAP callbacks was
	defined in Section 13 of [RFC6444]. The specification says:		defined in Section 13 of [RFC6443]. The specification says:
	'A UA may be able to determine a PSAP call back by examining the		"A UA may be able to determine a PSAP callback 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 callback 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 even though it requires state to be maintained by the user		implement even though it requires call state to be maintained by the
	agent as well as by SIP intermediaries. Unfortunately, the solution		user agent as well as by SIP intermediaries. Unfortunately, the
	does not work in all deployment scenarios. In Section 3 we describe		solution does not work in all deployment scenarios. In Section 3 we
	cases where the currently standardized approach is insufficient.		describe cases where the currently standardized approach is
			insufficient.
	2. Terminology		2. Terminology
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	Emergency services related terminology is borrowed from [RFC5012].		Emergency services related terminology is borrowed from [RFC5012].
	This includes terminology like emergency caller, user equipment, and		This includes terminology like emergency caller, user equipment, call
	call taker.		taker, Emergency Service Routing Proxy (ESRP), and Public Safety
			Answering Point (PSAP).
	3. Callback Scenarios		3. Callback Scenarios
	This section illustrates a number of scenarios where the currently		This section illustrates a number of scenarios where the currently
	specified solution, as specified in [I-D.ietf-ecrit-phonebcp], for		specified solution, as specified in [RFC6881], for preferential
	preferential treatment of callbacks fails. As explained in Section 1		treatment of callbacks fails. As explained in Section 1 a SIP entity
	a SIP entity examines an incoming PSAP call back by comparing the		examines an incoming PSAP callback by comparing the domain of the
	domain of the PSAP with the destination domain of the emergency call.		PSAP with the destination domain of the emergency call.
	3.1. Routing Asymmetry		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 routed through different SIP entities.		outgoing SIP messaging routed through different SIP entities.
	Figure 1 shows this graphically whereby a VoIP provider uses		Figure 1 shows this graphically whereby a VoIP provider uses
	different SIP proxies for inbound and for outbound call handling.		different SIP proxies for inbound and for outbound call handling.
	Unless they two devices are state synchronized the callback hitting		Unless the two devices are synchronized as to state the callback
	the inbound proxy would get treated like any other call since the		hitting the inbound proxy would get treated like any other call since
	emergency call established state information at the outbound proxy		the emergency call established state information at the outbound
	only.		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 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	+--+-->|Outbound|--+---->v | | +--+---+ |		+--+-->|Outbound|--+---->v | | +--+---+ |
	| |Proxy | | i | | +-+ESRP | |		| |Proxy | | i | | +-+ESRP | |
	| +--------+ | d | | | +------+ |		| +--------+ | d | | | +------+ |
	| | e || | |		| | e || | |
	| | r |+-+ |		| | r |+-+ |
	\ / | |		\ / | |
	`. ,' \ /		`. ,' \ /
	'-------' `. ,'		'-------' `. ,'
	'-------'		'-------'
	Figure 1: Example for Routing Asymmetry		Figure 1: Example for Routing Asymmetry.
	3.2. Multi-Stage Routing		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. In		Figure 2 where routing towards the PSAP occurs in several stages. In
	this scenario we consider a SIP UA that uses LoST to learn the next		this scenario we consider a SIP UA that uses LoST to learn the next
	hop destination closer to the PSAP. This call is then sent to the		hop destination closer to the PSAP. This call is then sent to the
	user's VoIP provider. The user's VoIP provider receives the		user's VoIP provider. The user's VoIP provider receives the
	emergency call and creates state based on the destination domain,		emergency call and creates state based on the destination domain,
	namely state.com. It then routes it to the indicated ESRP. When the		namely state.org. It then routes it to the indicated ESRP. When the
	ESRP receives it it needs to decide what the next hop is to get it		ESRP receives it it needs to decide what the next hop is to get it
	closer to the PSAP. In our example the next hop is the PSAP with the		closer to the PSAP. In our example the next hop is the PSAP with the
	URI psap@town.com.		URI psap@town.com.
	When a callback is sent from psap@town.com towards the emergency		When a callback is sent from psap@town.com towards the emergency
	caller the call will get normal treatment by the VoIP providers		caller the call will get normal treatment by the VoIP providers
	inbound proxy since the domain of the PSAP does not match the stored		inbound proxy since the domain of the PSAP does not match the stored
	state information.		state information.
	,-------.		,-------.
	skipping to change at page 8, line 18 ¶		skipping to change at page 8, line 18 ¶
	| UA |--- esrp1@foobar.com / Emergency \		| UA |--- esrp1@foobar.com / Emergency \
	+----+ \ | Services |		+----+ \ | Services |
	\ ,-------. | Network |		\ ,-------. | Network |
	,' `. | |		,' `. | |
	/ VoIP \ | +------+ |		/ VoIP \ | +------+ |
	( Provider ) | |PSAP | |		( Provider ) | |PSAP | |
	\ / | +--+---+ |		\ / | +--+---+ |
	`. ,' | |		`. ,' | |
	'---+---' | | |		'---+---' | | |
	| |psap@town.com |		| |psap@town.com |
	esrp@state.com | | |		esrp@state.org | | |
	| | | |		| | | |
	| | | |		| | | |
	| | +--+---+ |		| | +--+---+ |
	+------------+---+ESRP | |		+------------+---+ESRP | |
	| +------+ |		| +------+ |
	| |		| |
	\ /		\ /
	`. ,'		`. ,'
	'-------'		'-------'
	Figure 2: Example for Multi-Stage Routing		Figure 2: Example for Multi-Stage Routing.
	3.3. Call Forwarding		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 ESRP 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 police, fire and ambulance networks are part of the		apply when the police, fire and ambulance networks are part of the
	state.org sub-domains (e.g., police.state.org).		state.org sub-domains (e.g., police.state.org).
	Similarly to the previous scenario the problem here is with the wrong		Similarly to the previous scenario the problem here is with the wrong
	state information being established during the emergency call setup		state information being established during the emergency call setup
	procedure. A callback would originate in the police-town.org, fire-		procedure. A callback would originate in the police-town.org, fire-
	town.org or medic-town.org domain whereas the emergency caller's SIP		town.org or medic-town.org domain whereas the emergency caller's SIP
	UA or the VoIP outbound proxy has stored state.org.		UA or the VoIP outbound proxy has stored state.org.
	skipping to change at page 9, line 51 ¶		skipping to change at page 9, line 51 ¶
	| +------+ | | Network | | `~~~~~~~~~~~~~~~		| +------+ | | Network | | `~~~~~~~~~~~~~~~
	| | |medic-town.org | |		| | |medic-town.org | |
	| , | | |		| , | | |
	`~~~~~~~~~~~~~~~ | +------+ | |		`~~~~~~~~~~~~~~~ | +------+ | |
	| |PSAP +----+ +		| |PSAP +----+ +
	| +------+ |		| +------+ |
	| |		| |
	| ,		| ,
	`~~~~~~~~~~~~~~~		`~~~~~~~~~~~~~~~
	Figure 3: Example for Call Forwarding		Figure 3: Example for Call Forwarding.
	3.4. Network-based Service URN Resolution		3.4. Network-based Service URN Resolution
	The IETF emergency services architecture also considers cases where		The IETF emergency services architecture also considers cases where
	the resolution from the Service URN to the PSAP URI does not only		the resolution from the Service URN to the PSAP URI does not only
	happen at the SIP UA itself but at intermediate SIP entities, such as		happen at the SIP UA itself but at intermediate SIP entities, such as
	the user's VoIP provider.		the user's VoIP provider.
	Figure 4 shows this message exchange of the outgoing emergency call		Figure 4 shows this message exchange of the outgoing emergency call
	and the incoming PSAP graphically. While the state information		and the incoming PSAP graphically. While the state information
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 47 ¶
	Invite| | Invite		Invite| | Invite
	from| | to		from| | to
	police.example.com| | urn:service:sos		police.example.com| | urn:service:sos
	V |		V |
	+-------+		+-------+
	| SIP |		| SIP |
	| UA |		| UA |
	| Alice |		| Alice |
	+-------+		+-------+
	Figure 4: Example for Network-based Service URN Resolution		Figure 4: Example for Network-based Service URN Resolution.
	3.5. PSTN Interworking		3.5. PSTN Interworking
	In case an emergency call enters the PSTN, as shown in Figure 5,		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.
	+-----------+		+-----------+
	skipping to change at page 11, line 43 ¶		skipping to change at page 11, line 43 ¶
	| |		| |
	Invite Invite		Invite Invite
	| |		| |
	V |		V |
	+-------+		+-------+
	| SIP |		| SIP |
	| UA |		| UA |
	| Alice |		| Alice |
	+-------+		+-------+
	Figure 5: Example for PSTN Interworking		Figure 5: Example for PSTN Interworking.
	Note: This scenario is considered outside the scope of this document.		Note: This scenario is considered outside the scope of this document.
	The specified solution does not support this use case.		The specified solution does not support this use case.
	4. SIP PSAP Callback Indicator		4. SIP PSAP Callback Indicator
	4.1. General		4.1. General
	This section defines a new header field value, called "psap-		This section defines a new header field value, called "psap-
	callback", for the SIP Priority header field defined in [RFC3261].		callback", for the SIP Priority header field defined in [RFC3261].
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 11 ¶
	priority-value /= "psap-callback"		priority-value /= "psap-callback"
	Figure 6: ABNF		Figure 6: ABNF
	5. Security Considerations		5. Security Considerations
	5.1. Security Threat		5.1. Security Threat
	The PSAP callback functionality described in this document allows		The PSAP callback functionality described in this document allows
	marked calls to bypass blacklists, ignore call forwarding procedures		marked calls to bypass blacklists, ignore call forwarding procedures
	and similar features to contact emergency callers and to raise their		and other similar features used to raise the attention of emergency
	attention. Regarding the latter aspect a callback, if understood by		callers when attempting to contact them. In the case where the SIP
	the SIP UA would allow to override user interface configurations,		Priority header value, 'psap-callback', is supported by the SIP UA,
	such as vibrate-only mode, to alert the caller of the incoming call.		it would override user interface configurations, such as vibrate-only
			mode, to alert the caller of the incoming call.
	5.2. Security Requirements		5.2. Security Requirements
	The requirement is to ensure that the mechanisms described in this		The requirement is to ensure that the mechanisms described in this
	document can not be used for malicious purposes, including		document can not be used for malicious purposes, including
	telemarketing.		telemarketing.
	Furthermore, if the newly defined extension is not recognized, not		Furthermore, if the newly defined extension is not recognized, not
	verified adequately, or not obeyed by SIP intermediaries or SIP		verified adequately, or not obeyed by SIP intermediaries or SIP
	endpoints then it must not lead to a failure of the call handling		endpoints then it must not lead to a failure of the call handling
	procedure. Such call must be treated like a call that does not have		procedure. Such call must be treated like a call that does not have
	any marking attached.		any marking attached.
	5.3. Security Solution		5.3. Security Solution
	Figure 7 shows the architecture that utilizes the identity of the		Figure 7 shows the architecture that utilizes the identity of the
	PSAP to decide whether a preferential treatment of callbacks should		PSAP to decide whether a preferential treatment of callbacks should
	be provided. To make this policy decision the identity of the PSAP		be provided. To make this policy decision, the identity of the PSAP
	is compared with a whitelist of valid PSAPs available to the SIP		is compared with a white list of valid PSAPs available to the SIP
	entity. The identity assurance in SIP can come in different forms,		entity. The identity assurance 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. Also the usage of TLS between		latter on a chain of trust. Also the usage of TLS between
	neighboring SIP entities may provide useful identity information.		neighboring SIP entities may provide useful identity information.
	+----------+		+----------+
	| List of |+		| List of |+
	| valid ||		| valid ||
	| PSAPs ||		| PSAPs ||
	+----------+|		+----------+|
	+----------+		+----------+
	*		*
	* whitelist		* white list
	*		*
	V		V
	Incoming +----------+ Normal		Incoming +----------+ Normal
	SIP Msg | SIP |+ Treatment		SIP Msg | SIP |+ Treatment
	-------------->| Entity ||======================>		-------------->| Entity ||======================>
	+ Identity | ||(if not in whitelist)		+ Identity | ||(if not in white list)
	Info +----------+|		Info +----------+|
	+----------+		+----------+
	||		||
	||		||
	|| Preferential		|| Preferential
	|| Treatment		|| Treatment
	++========================>		++========================>
	(if successfully verified)		(if successfully verified)
	Figure 7: Identity-based Authorization		Figure 7: Identity-based Authorization
	An important aspect from a security point of view is the relationship		An important aspect from a security point of view is the relationship
	between the emergency services network (containing PSAPs) and the VSP		between the emergency services network (containing PSAPs) and the
	(assuming that the emergency call travels via the VSP and not		VoIP provider (assuming that the emergency call travels via the VoIP
	directly between the SIP UA and the PSAP).		provider and not directly between the SIP UA and the PSAP).
	If there is some form of relationship between the emergency services		If there is some form of relationship between the emergency services
	operator and the VSP then the identification of a PSAP call back is		operator and the VoIP provider then the identification of a PSAP
	less problematic than in the case where the two entities have not		callback is less problematic than in the case where the two entities
	entered in some form of relationship that would allow the VSP to		have not entered in some form of relationship that would allow the
	verify whether the marked callback message indeed came from a		VoIP provider to verify whether the marked callback message indeed
	legitimate source.		came from a legitimate source.
	The establishment of a whitelist with PSAP identities maybe be		The establishment of a whitelist with PSAP identities maybe be
	operationally complex. When there is a local relationship between		operationally complex. When there is a local relationship between
	the VSP/ASP and the PSAP then populating the whitelist is fairly		the VoIP provider and the PSAP then populating the whitelist is
	simple. For SIP UAs there is no need to maintain a list of PSAPs.		fairly simple. For SIP UAs there is no need to maintain a list of
	Instead SIP UAs are assumed to trust the correct processing of their		PSAPs. Instead SIP UAs are assumed to trust the correct processing
	VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and,		of their VoIP provider, i.e., the VoIP provider processes the PSAP
	if it cannot be verified, the PSAP callback marking is removed. If		callback marking and, if it cannot be verified, the PSAP callback
	it is left untouched then the SIP UA should assume that it has been		marking is removed. If it is left untouched then the SIP UA should
	verified successfully by the VSP/ASP and it should therefore be		assume that it has been verified successfully by the VoIP provider
	obeyed.		and it should therefore be obeyed.
	6. IANA Considerations		6. IANA Considerations
	This document adds the "psap-callback" value to the SIP Priority		This document adds the "psap-callback" value to the SIP Priority
	header IANA registry allocated by [I-D.ietf-sipcore-priority]. The		header IANA registry allocated by [RFC6878]. The semantic of the
	semantic of the newly defined "psap-callback" value is defined in		newly defined "psap-callback" value is defined in Section 4.
	Section 4.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank members from the ECRIT working group, in		We would like to thank the following persons for their feedback: Paul
	particular Brian Rosen, for their discussions around PSAP callbacks.		Kyzivat, Martin Thomson, Robert Sparks, Keith Drage, Cullen Jennings
	The working group discussed the topic of callbacks at their virtual		Brian Rosen, Martin Dolly, Bernard Aboba, Andrew Allen, Atle Monrad,
	interim meeting in February 2010 and the following persons provided		John-Luc Bakker, John Elwell, Geoff Thompson, Dan Romascanu, James
	valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith		Polk, John Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight,
	Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,		Janet Gunn
	Janet Gunn.
	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.
	We would like to thank the following persons for their feedback on		Finally, we would like to thank the ECRIT working group chairs, Marc
	the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert		Linsner and Roger Marshall, for their support.
	Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly,
	Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John
	Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-sipcore-priority] Roach, A., "IANA Registry for the		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Session Initiation Protocol (SIP)		Requirement Levels", BCP 14, RFC 2119, March 1997.
	"Priority" Header Field",
	draft-ietf-sipcore-priority-00 (work in
	progress), December 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	to Indicate Requirement Levels", BCP 14,		A., Peterson, J., Sparks, R., Handley, M., and E.
	RFC 2119, March 1997.		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[RFC3261] Rosenberg, J., Schulzrinne, H.,		[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
	Camarillo, G., Johnston, A., Peterson,		Extensions to the Session Initiation Protocol (SIP) for
	J., Sparks, R., Handley, M., and E.		Asserted Identity within Trusted Networks", RFC 3325,
	Schooler, "SIP: Session Initiation		November 2002.
	Protocol", RFC 3261, June 2002.
	[RFC3325] Jennings, C., Peterson, J., and M.		[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
	Watson, "Private Extensions to the		RFC 3966, December 2004.
	Session Initiation Protocol (SIP) for
	Asserted Identity within Trusted
	Networks", RFC 3325, November 2002.
	[RFC3966] Schulzrinne, H., "The tel URI for		[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
	Telephone Numbers", RFC 3966,		(IANA) Uniform Resource Identifier (URI) Parameter
	December 2004.		Registry for the Session Initiation Protocol (SIP)",
			BCP 99, RFC 3969, December 2004.
	[RFC3969] Camarillo, G., "The Internet Assigned		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Number Authority (IANA) Uniform Resource		Authenticated Identity Management in the Session
	Identifier (URI) Parameter Registry for		Initiation Protocol (SIP)", RFC 4474, August 2006.
	the Session Initiation Protocol (SIP)",
	BCP 99, RFC 3969, December 2004.
	[RFC4474] Peterson, J. and C. Jennings,		[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
	"Enhancements for Authenticated Identity		Agent URIs (GRUUs) in the Session Initiation Protocol
	Management in the Session Initiation		(SIP)", RFC 5627, October 2009.
	Protocol (SIP)", RFC 4474, August 2006.
	[RFC5627] Rosenberg, J., "Obtaining and Using		[RFC6878] Roach, A., "IANA Registry for the Session Initiation
	Globally Routable User Agent URIs		Protocol (SIP) "Priority" Header Field", RFC 6878,
	(GRUUs) in the Session Initiation		March 2013.
	Protocol (SIP)", RFC 5627, October 2009.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current		[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
	Practice for Communications Services in		"Trait-Based Authorization Requirements for the Session
	support of Emergency Calling",		Initiation Protocol (SIP)", RFC 4484, August 2006.
	draft-ietf-ecrit-phonebcp-20 (work in
	progress), September 2011.
	[RFC4484] Peterson, J., Polk, J., Sicker, D., and		[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
	H. Tschofenig, "Trait-Based		Emergency Context Resolution with Internet Technologies",
	Authorization Requirements for the		RFC 5012, January 2008.
	Session Initiation Protocol (SIP)",
	RFC 4484, August 2006.
	[RFC5012] Schulzrinne, H. and R. Marshall,		[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
	"Requirements for Emergency Context		Emergency and Other Well-Known Services", RFC 5031,
	Resolution with Internet Technologies",		January 2008.
	RFC 5012, January 2008.
	[RFC5031] Schulzrinne, H., "A Uniform Resource		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Name (URN) for Emergency and Other Well-		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	Known Services", RFC 5031, January 2008.
	[RFC5234] Crocker, D. and P. Overell, "Augmented		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	BNF for Syntax Specifications: ABNF",		"Framework for Emergency Calling Using Internet
	STD 68, RFC 5234, January 2008.		Multimedia", RFC 6443, December 2011.
	[RFC6444] Schulzrinne, H., Liess, L., Tschofenig,		[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	H., Stark, B., and A. Kuett, "Location		Communications Services in Support of Emergency Calling",
	Hiding: Problem Statement and		BCP 181, RFC 6881, March 2013.
	Requirements", RFC 6444, January 2012.
	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
End of changes. 51 change blocks.
	148 lines changed or deleted		123 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/