< draft-ietf-ecrit-unauthenticated-access-07.txt		draft-ietf-ecrit-unauthenticated-access-08.txt >
	ECRIT H. Schulzrinne		ECRIT H. Schulzrinne
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track S. McCann		Intended status: Standards Track S. McCann
	Expires: January 14, 2014 Research in Motion UK Ltd		Expires: April 22, 2014 Research in Motion UK Ltd
	G. Bajko		G. Bajko
	Nokia		Nokia
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		Nokia Solutions and Networks
	D. Kroeselberg		D. Kroeselberg
	Siemens		Siemens
	July 13, 2013		October 19, 2013
	Extensions to the Emergency Services Architecture for dealing with		Extensions to the Emergency Services Architecture for dealing with
	Unauthenticated and Unauthorized Devices		Unauthenticated and Unauthorized Devices
	draft-ietf-ecrit-unauthenticated-access-07.txt		draft-ietf-ecrit-unauthenticated-access-08.txt
	Abstract		Abstract
	The IETF emergency services architecture assumes that the calling		The IETF emergency services architecture assumes that the calling
	device has acquired rights to use the access network or that no		device has acquired rights to use the access network or that no
	authentication is required for the access network, such as for public		authentication is required for the access network, such as for public
	wireless access points. Subsequent protocol interactions, such as		wireless access points. Subsequent protocol interactions, such as
	obtaining location information, learning the address of the Public		obtaining location information, learning the address of the Public
	Safety Answering Point (PSAP) and the emergency call itself are		Safety Answering Point (PSAP) and the emergency call itself are
	largely decoupled from the underlying network access procedures.		largely decoupled from the underlying network access procedures.
	In some cases, however, the device does not have these credentials		In some cases, however, the device does not have these credentials
	for network access, does not have a VoIP service provider, or the		for network access, does not have a VoIP service provider, or the
	credentials have become invalid, e.g., because the user has exhausted		credentials have become invalid, e.g., because the user has exhausted
	their prepaid balance or the account has expired.		their prepaid balance or the account has expired.
			With features provided by the Public Switched Telephone Network
			(PSTN) there is precedence for some of these use cases and the
			transition to IP-based emergency calling creates the desire to
			replicate functionality the PSTN already offers today. For example,
			in many countries persons seeking help are empowered to initiate
			emergency calls without having a Subscriber Identity Module (SIM) in
			their mobile phone.
	This document provides a problem statement, introduces terminology		This document provides a problem statement, introduces terminology
	and describes an extension for the base IETF emergency services		and describes an extension for the base IETF emergency services
	architecture to address these scenarios.		architecture to address these scenarios.
	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 January 14, 2014.		This Internet-Draft will expire on April 22, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 37 ¶
	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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Use Case Categories . . . . . . . . . . . . . . . . . . . . . 5		3. Use Case Categories . . . . . . . . . . . . . . . . . . . . . 5
	4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. ZBP Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. NASP Considerations . . . . . . . . . . . . . . . . . . . . . 11
	5.1. End Host Profile . . . . . . . . . . . . . . . . . . . . 10		5.1. End Host Profile . . . . . . . . . . . . . . . . . . . . 13
	5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 10		5.1.1. LoST Server Discovery . . . . . . . . . . . . . . . . 13
	5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . 10		5.1.2. ESRP Discovery . . . . . . . . . . . . . . . . . . . 13
	5.1.3. Location Determination and Location Configuration . . 10		5.1.3. Location Determination and Location Configuration . . 14
	5.1.4. Emergency Call Identification . . . . . . . . . . . . 10		5.1.4. Emergency Call Identification . . . . . . . . . . . . 14
	5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . 10		5.1.5. SIP Emergency Call Signaling . . . . . . . . . . . . 14
	5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 11		5.1.6. Media . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 11		5.1.7. Testing . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 11		5.2. IAP/ISP Profile . . . . . . . . . . . . . . . . . . . . . 14
	5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . 11		5.2.1. ESRP Discovery . . . . . . . . . . . . . . . . . . . 15
	5.2.2. Location Determination and Location Configuration . . 11		5.2.2. Location Determination and Location Configuration . . 15
	5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . 11		5.3. ESRP Profile . . . . . . . . . . . . . . . . . . . . . . 15
	5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . 11		5.3.1. Emergency Call Routing . . . . . . . . . . . . . . . 15
	5.3.2. Emergency Call Identification . . . . . . . . . . . . 12		5.3.2. Emergency Call Identification . . . . . . . . . . . . 15
	5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . 12		5.3.3. SIP Emergency Call Signaling . . . . . . . . . . . . 15
	6. Lower Layer Considerations for NAA Case . . . . . . . . . . . 12		6. Lower Layer Considerations for NAA Case . . . . . . . . . . . 15
	6.1. Link Layer Emergency Indication . . . . . . . . . . . . . 13		6.1. Link Layer Emergency Indication . . . . . . . . . . . . . 17
	6.2. Securing Network Attachment in NAA Cases . . . . . . . . 14		6.2. Securing Network Attachment in NAA Cases . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . 20
	10.2. Informative References . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	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 older technology. New devices and services are being made		the older 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.
	Roughly speaking, the IETF emergency services architecture (see		Roughly speaking, the IETF emergency services architecture (see
	[RFC6881] and [RFC6443]) divides responsibility for handling		[RFC6881] and [RFC6443]) divides responsibility for handling
	emergency calls between the access network (ISP), the application		emergency calls between the access network (ISP), the application
	service provider (ASP) that may be a VoIP service provider and the		service provider (ASP) that may be a VoIP service provider (VSP) and
	provider of emergency signaling services, the emergency service		the provider of emergency signaling services, the emergency service
	network (ESN). The access network may provide location information		network (ESN). The access network may provide location information
	to end systems, but does not have to provide any ASP signaling		to end systems, but does not have to provide any ASP signaling
	functionality. The emergency caller can reach the ESN either		functionality. The emergency caller can reach the ESN either
	directly or through the ASP's outbound proxy. Any of the three		directly or through the ASP's outbound proxy. Any of the three
	parties can provide the mapping from location to PSAP URI by offering		parties can provide the mapping from location to PSAP URI by offering
	LoST [RFC5222] services.		LoST [RFC5222] services.
	In general, a set of automated configuration mechanisms allows a		In general, a set of automated configuration mechanisms allows a
	device to function in a variety of architectures, without the user		device to function in a variety of architectures, without the user
	being aware of the details on who provides location, mapping services		being aware of the details on who provides location, mapping services
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 7 ¶
	requires that all calls traverse a known set of VSPs, it is		requires that all calls traverse a known set of VSPs, it is
	technically possible to let a caller place an emergency call in the		technically possible to let a caller place an emergency call in the
	ZBP case. We discuss each case in more details in Section 3.		ZBP case. We discuss each case in more details in Section 3.
	Note: At the time of writing there is no regulation in place that		Note: At the time of writing there is no regulation in place that
	demands the functionality described in this memo. SDOs have started		demands the functionality described in this memo. SDOs have started
	their work on this subject in a proactive fashion in the anticipation		their work on this subject in a proactive fashion in the anticipation
	that national regulation will demand it for a subset of network		that national regulation will demand it for a subset of network
	environments.		environments.
	There are also indications that the functionality of unauthenticated		As mentioned in the abstract some of the functionality provided in
	emergency calls (called SIM-less calls) in today's cellular system in		this document is already available in the PSTN. Consequently, there
	certain countries leads to a fair amount of hoax or test calls. This		is real-world experience available and not all of it is positive.
	causes overload situations at PSAPs which is considered harmful to		For example, the functionality of SIM-less calls in today's cellular
	the overall availability and reliability of emergency services.		system has lead to a fair amount of hoax or test calls in certain
			countries. This causes overload situations at PSAPs, which is
			considered harmful to the overall availability and reliability of
			emergency services.
	As an example, Federal Office of Communications (OFCOM, Switzerland)		As an example, Federal Office of Communications (OFCOM,
	provided statistics about emergency (112) calls in Switzerland from		Switzerland) provided statistics about emergency (112) calls in
	Jan. 1997 to Nov. 2001. Switzerland did not offer SIM-less		Switzerland from Jan. 1997 to Nov. 2001. Switzerland did not
	emergency calls except for almost a month in July 2000 where a		offer SIM-less emergency calls except for almost a month in July
	significant increase in hoax and test calls was reported. As a		2000 where a significant increase in hoax and test calls was
	consequence, the functionality was disabled again. More details can		reported. As a consequence, the functionality was disabled again.
	be found in the panel presentations of the 3rd SDO Emergency Services		More details can be found in the panel presentations of the 3rd
	Workshop [esw07].		SDO Emergency Services Workshop [esw07].
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119		and "OPTIONAL" are to be interpreted as described in RFC 2119
	[RFC2119].		[RFC2119].
	This document reuses terminology from [RFC5687] and [RFC5012], namely		This document reuses terminology from [RFC5687] and [RFC5012], namely
	Internet Access Provider (IAP), Internet Service Provider (ISP),		Internet Access Provider (IAP), Internet Service Provider (ISP),
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 45 ¶
	Emergency Service Routing Proxy (ESRP), Public Safety Answering Point		Emergency Service Routing Proxy (ESRP), Public Safety Answering Point
	(PSAP), Location Configuration Server (LCS), (emergency) service dial		(PSAP), Location Configuration Server (LCS), (emergency) service dial
	string, and (emergency) service identifier.		string, and (emergency) service identifier.
	3. Use Case Categories		3. Use Case Categories
	On a very high-level, the steps to be performed by an end host not		On a very high-level, the steps to be performed by an end host not
	being attached to the network and the user starting to make an		being attached to the network and the user starting to make an
	emergency call are the following:		emergency call are the following:
	Link Layer Attachment: Some radio networks have added support for		Link Layer Attachment: Some networks have added support for
	unauthenticated emergency access, some other type of networks		unauthenticated emergency access, some other type of networks
	advertise these capabilities using layer beacons. The end host		advertise these capabilities using layer beacons. The end host
	learns about these unauthenticated emergency services capabilities		learns about these unauthenticated emergency services capabilities
	either from the link layer type or from advertisement.		either from the link layer type or from advertisement.
	The end host uses the link layer specific network attachment		The end host uses the link layer specific network attachment
	procedures defined for unauthenticated network access in order to		procedures defined for unauthenticated network access in order to
	get access to the network.		get access to the network.
	Pre-Emergency Service Configuration: When the link layer network		Pre-Emergency Service Configuration: When the link layer network
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 34 ¶
	| |		| |
	v v		v v
	+-----Y +-----Y		+-----Y +-----Y
	| Done| | Done|		| Done| | Done|
	`...../ `...../		`...../ `...../
	Abbreviations:		Abbreviations:
	LLA: Link Layer Attachment		LLA: Link Layer Attachment
	ES: Emergency Services		ES: Emergency Services
	Figure 1: Flow Diagram		Figure 1: Flow Diagram: NAA, ZBP, and NSAP Scenarios.
			The diagrams below highlight the most important steps for the three
			cases.
			+-----Y
			|Start|
			`...../
			|
			| No
			| credentials
			| for network access
			| available
			v
			..............
			| Idle: Wait |
			| for ES Call|
			| Initiation |
			"------------'
			|
			|
			|
			v
			--
			// --
			/ --
			// Is --
			/ emergency --
			| service | NO +--------+
			| network |------>| Call |
			| attachment | Failed |
			\ possible? / `......./
			\ //
			\\ //
			\ //
			\--/
			|
			| YES
			|
			|
			v
			+------------+
			| Execute |
			| NAA |
			| Procedures |
			+------------+
			|
			| Network
			| attachment
			| in progress
			v
			/--\ Continue
			| | with
			| | application
			\--/ layer interaction
			Figure 2: Flow Diagram: NAA Scenario.
			+-----+
			+------------|Start|-----------------+
			| `...../ |
			v v
			+------------+ +----------------+
			| NAA | | Regular |
			| Procedures | | Network Access |
			+------------+ | Procedures |
			| +----------------+
			| |
			| |
			----------------o--------------------+
			|
			|
			|
			|
			Network
			Attachment
			Completed
			|
			|
			|
			|
			v
			+------------+ +---------+
			| ASP | NO | See |
			| Configured?|----->| main |
			+------------+ | diagram |
			| `......../
			|
			| YES
			|
			v
			//----
			/ --
			// --
			/ - +---------+
			| Authorization| YES | See |
			| for making |------>| main |
			| ES call | | diagram |
			\ with / `......../
			\ VSP/ASP? //
			\\ //
			\ //
			\--/
			|
			| NO
			|
			|
			v
			+------------+
			| Execute |
			| ZBP |
			| Procedures |
			+------------+
			|
			| Call
			| in progress
			|
			v
			+--------+
			| Call |
			Success|
			`......./
			Figure 3: Flow Diagram: ZBP Scenario.
			+-----+
			+------------|Start|-----------------+
			| `...../ |
			v v
			+------------+ +----------------+
			| NAA | | Regular |
			| Procedures | | Network Access |
			+------------+ | Procedures |
			| +----------------+
			| |
			| |
			----------------o--------------------+
			|
			|
			|
			|
			Network
			Attachment
			Completed
			|
			|
			|
			|
			v
			+------------+ +---------+
			| ASP | YES | See |
			| Configured?|----->| main |
			+------------+ | diagram |
			| `......../
			|
			| NO
			|
			v
			+------------+
			| Execute |
			| NASP |
			| Procedures |
			+------------+
			|
			| Call
			| in progress
			|
			v
			+--------+
			| Call |
			Success|
			`......./
			Figure 4: Flow Diagram: NASP Scenario.
	The "No Access Authentication (NAA)" procedures are described in		The "No Access Authentication (NAA)" procedures are described in
	Section 6. The "Zero-balance ASP (ZBP)" procedures are described in		Section 6. The "Zero-balance ASP (ZBP)" procedures are described in
	Section 4. The "No ASP (NASP)" procedures are described in		Section 4. The "No ASP (NASP)" procedures are described in
	Section 5. The Phone BCP procedures are described in [RFC6881]. The		Section 5. The Phone BCP procedures are described in [RFC6881]. The
	"Link Layer Attachment (LLA)" procedures are not described in this		"Link Layer Attachment (LLA)" procedures are not described in this
	document since they are specific to the link layer technology in use.		document since they are specific to the link layer technology in use.
	4. ZBP Considerations		4. ZBP Considerations
	skipping to change at page 8, line 17 ¶		skipping to change at page 12, line 4 ¶
	of the emergency calls and to only permit calls to certain, pre-		of the emergency calls and to only permit calls to certain, pre-
	configured entities (e.g., to local PSAPs). Section 7 discusses this		configured entities (e.g., to local PSAPs). Section 7 discusses this
	topic in more detail.		topic in more detail.
	An ASP without a regulatory requirement to authorize emergency calls		An ASP without a regulatory requirement to authorize emergency calls
	can deny emergency call setup. Where an ASP does not authorize an		can deny emergency call setup. Where an ASP does not authorize an
	emergency call, the caller may be able to fall back to NASP		emergency call, the caller may be able to fall back to NASP
	procedures.		procedures.
	5. NASP Considerations		5. NASP Considerations
	To start the description we consider the sequence of steps that are		To start the description we consider the sequence of steps that are
	executed in an emergency call based on Figure 2.		executed in an emergency call based on Figure 5.
	o As an initial step the devices attaches to the network as shown in		o As an initial step the devices attaches to the network as shown in
	step (1). This step is outside the scope of this section.		step (1). This step is outside the scope of this section.
	o When the link layer network attachment procedure is completed the		o When the link layer network attachment procedure is completed the
	end host learns basic IP configuration information using DHCP from		end host learns basic IP configuration information using DHCP from
	the ISP, as shown in step (2).		the ISP, as shown in step (2).
	o When the IP address configuration is completed then the end host		o When the IP address configuration is completed then the end host
	starts an interaction with the discovered Location Configuration		starts an interaction with the discovered Location Configuration
	skipping to change at page 9, line 6 ¶		skipping to change at page 12, line 41 ¶
	o The ESRP routes the call to the PSAP, as shown in (8), potentially		o The ESRP routes the call to the PSAP, as shown in (8), potentially
	interacting with a LoST server first to determine the route.		interacting with a LoST server first to determine the route.
	o The PSAP evaluates the initial INVITE and aims to complete the		o The PSAP evaluates the initial INVITE and aims to complete the
	call setup.		call setup.
	o Finally, when the call setup is completed media traffic can be		o Finally, when the call setup is completed media traffic can be
	exchanged between the PSAP and the SIP UA.		exchanged between the PSAP and the SIP UA.
	For editorial reasons the end-to-end SIP and media exchange between		For editorial reasons the end-to-end SIP and media exchange between
	the PSAP and SIP UA are not shown in Figure 2.		the PSAP and SIP UA are not shown in Figure 5.
	+-------+		+-------+
	| PSAP |		| PSAP |
	| |		| |
	+-------+		+-------+
	^		^
	| (8)		| (8)
	|		|
	+----------+(7) +----------+		+----------+(7) +----------+
	| LoST |<-->| ESRP |		| LoST |<-->| ESRP |
	skipping to change at page 9, line 49 ¶		skipping to change at page 13, line 36 ¶
	| | | | |		| | | | |
	| | (1)| | |		| | (1)| | |
	| | | | |		| | | | |
	| | | +----+ |		| | | +----+ |
	| | v | |		| | v | |
	| | +----------+ |		| | +----------+ |
	| +->| End |<-------------+		| +->| End |<-------------+
	+___>| Host |		+___>| Host |
	+----------+		+----------+
	Figure 2: Architectural Overview		Figure 5: Architectural Overview
	Note: Figure 2 does not indicate who operates the ESRP and the LoST		Note: Figure 5 does not indicate who operates the ESRP and the LoST
	server. Various deployment options exist.		server. Various deployment options exist.
	5.1. End Host Profile		5.1. End Host Profile
	5.1.1. LoST Server Discovery		5.1.1. LoST Server Discovery
	The end host MUST discover a LoST server [RFC5222] using DHCP		The end host MUST discover a LoST server [RFC5222] using DHCP
	[RFC5223].		[RFC5223].
	5.1.2. ESRP Discovery		5.1.2. ESRP Discovery
	skipping to change at page 10, line 43 ¶		skipping to change at page 14, line 31 ¶
	map a user entered dialstring into this URN scheme. A user may		map a user entered dialstring into this URN scheme. A user may
	"dial" 1-1-2, 9-1-1, etc., but the call would be sent to		"dial" 1-1-2, 9-1-1, etc., but the call would be sent to
	urn:service:sos. This mapping SHOULD be performed at the endpoint		urn:service:sos. This mapping SHOULD be performed at the endpoint
	device.		device.
	End hosts MUST use the Service URN mechanism [RFC5031] to mark calls		End hosts MUST use the Service URN mechanism [RFC5031] to mark calls
	as emergency calls for their home emergency dial string.		as emergency calls for their home emergency dial string.
	5.1.5. SIP Emergency Call Signaling		5.1.5. SIP Emergency Call Signaling
	SIP signaling capabilities [RFC3261] are mandated for end hosts.		SIP signaling capabilities [RFC3261] are REQUIRED for end hosts.
	The initial SIP signaling method is an INVITE. The SIP INVITE		The initial SIP signaling method is an INVITE. The SIP INVITE
	request MUST be constructed according to the requirements in		request MUST be constructed according to the requirements in
	Section 9.2 [RFC6881].		Section 9.2 [RFC6881].
	Regarding callback behavior SIP UAs SHOULD place a globally routable		Regarding callback behavior SIP UAs SHOULD place a globally routable
	URI in a Contact: header.		URI in a Contact: header.
	5.1.6. Media		5.1.6. Media
	skipping to change at page 12, line 12 ¶		skipping to change at page 15, line 42 ¶
	require further interactions with LoST servers but depends on the		require further interactions with LoST servers but depends on the
	specific deployment.		specific deployment.
	5.3.2. Emergency Call Identification		5.3.2. Emergency Call Identification
	The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e.,		The ESRP MUST understand the Service URN mechanism [RFC5031] (i.e.,
	the 'urn:service:sos' tree).		the 'urn:service:sos' tree).
	5.3.3. SIP Emergency Call Signaling		5.3.3. SIP Emergency Call Signaling
	SIP signaling capabilities [RFC3261] are mandated for the ESRP. The		SIP signaling capabilities [RFC3261] are REQUIRED for the ESRP. The
	ESRP MUST process the messages sent by the client, according to		ESRP MUST process the messages sent by the client, according to
	Section 5.1.5.		Section 5.1.5.
	6. Lower Layer Considerations for NAA Case		Furthermore, if a PSAP wants to support NASP calls, then it MUST NOT
			restrict incoming calls to a particular set of ASPs.
	Some radio networks have added support for unauthenticated emergency		6. Lower Layer Considerations for NAA Case
			Some networks have added support for unauthenticated emergency
	access, some other type of networks advertise these capabilities		access, some other type of networks advertise these capabilities
	using layer beacons. The end host learns about these unauthenticated		using layer beacons. The end host learns about these unauthenticated
	emergency services capabilities either from the link layer type or		emergency services capabilities either from the link layer type or
	from advertisement.		from advertisement.
			It is important to highlight that the NAA case is inherently a layer
			2 problem, and the general form of the solution is to provide an
			"emergency only" access type, with appropriate limits/monitoring to
			prevent abuse. The described mechanisms are informative in nature
			since the relationship to the IETF emergency is only indirect, namely
			via some protocols developed within the IETF (e.g., EAP and EAP
			methods) that require extensions to support this functionality.
	This section discusses different methods to indicate an emergency		This section discusses different methods to indicate an emergency
	service request as part of network attachment. It provides some		service request as part of network attachment. It provides some
	general considerations and recommendations that are not specific to		general considerations and recommendations that are not specific to
	the access technology.		the access technology.
	To perform network attachment and get access to the resources		To perform network attachment and get access to the resources
	provided by an IAP/ISP, the end host uses access technology specific		provided by an IAP/ISP, the end host uses access technology specific
	network attachment procedures, including for example network		network attachment procedures, including for example network
	detection and selection, authentication, and authorization. For		detection and selection, authentication, and authorization. For
	initial network attachment of an emergency service requester, the		initial network attachment of an emergency service requester, the
	skipping to change at page 13, line 5 ¶		skipping to change at page 16, line 41 ¶
	Link layer emergency indication: The end host provides an		Link layer emergency indication: The end host provides an
	indication, e.g., an emergency parameter or flag, as part of the		indication, e.g., an emergency parameter or flag, as part of the
	link layer signaling for initial network attachment. Examples		link layer signaling for initial network attachment. Examples
	include an emergency bit signalled in the IEEE 802.16-2009		include an emergency bit signalled in the IEEE 802.16-2009
	wireless link. In IEEE 802.11 WLAN, an emergency support		wireless link. In IEEE 802.11 WLAN, an emergency support
	indicator allows the STA to download before association an NAI		indicator allows the STA to download before association an NAI
	which it can use to request server side authentication only for an		which it can use to request server side authentication only for an
	802.1x network.		802.1x network.
	Higher-layer emergency indication: Typically emergency indication in		Higher-layer emergency indication: Typically, emergency indication
	access authentication. The emergency caller's end host provides		is provided in the network access authentication procedure. The
	an indication as part of the access authentication exchanges. EAP		emergency caller's end host provides an indication as part of the
	based authentication is of particular relevance here. Examples		access authentication exchanges. Authentication via the
	are the EAP NAI decoration used in WiMAX networks and modification		Extensible Authentication Protocol (EAP) [RFC3748] is of
	of the authentication exchange in IEEE 802.11. [nwgstg3].		particular relevance here. Examples are the EAP NAI decoration
			used in WiMAX networks and modification of the authentication
			exchange in IEEE 802.11. [nwgstg3].
	6.1. Link Layer Emergency Indication		6.1. Link Layer Emergency Indication
	In general, link layer emergency indications provide good integration		In general, link layer emergency indications provide good integration
	into the actual network access procedure regarding the enabling of		into the actual network access procedure regarding the enabling of
	means to recognize and prioritize an emergency service request from		means to recognize and prioritize an emergency service request from
	an end host at a very early stage of the network attachment		an end host at a very early stage of the network attachment
	procedure. However, support in end hosts for such methods cannot be		procedure. However, support in end hosts for such methods cannot be
	considered to be commonly available.		considered to be commonly available.
	skipping to change at page 14, line 33 ¶		skipping to change at page 18, line 26 ¶
	a key-generating EAP method (that provides an MSK key to the		a key-generating EAP method (that provides an MSK key to the
	authenticator to bootstrap further key derivation for protecting the		authenticator to bootstrap further key derivation for protecting the
	wireless link).		wireless link).
	The following approaches to match the above can be identified:		The following approaches to match the above can be identified:
	1) Server-only Authentication:		1) Server-only Authentication:
	The device of the emergency service requester performs an EAP		The device of the emergency service requester performs an EAP
	method with the IAP/ISP EAP server that performs server side		method with the IAP/ISP EAP server that performs server side
	authentication only. An example for this is EAP-TLS. This		authentication only. An example for this is EAP-TLS [RFC5216].
	provides a certain level of assurance about the IAP/ISP to the		This provides a certain level of assurance about the IAP/ISP to
	device user. It requires the device to be provisioned with		the device user. It requires the device to be provisioned with
	appropriate trusted root certificates to be able to verify the		appropriate trusted root certificates to be able to verify the
	server certificate of the EAP server (unless this step is		server certificate of the EAP server (unless this step is
	explicitly skipped in the device in case of an emergency service		explicitly skipped in the device in case of an emergency service
	request). This method is used to provide access of devices		request). This method is used to provide access of devices
	without existing credentials to an 802.1x network. The details		without existing credentials to an 802.1x network. The details
	are incorporated into the not yet published 802.11-2011		are incorporated into the not yet published 802.11-2011
	specification.		specification.
	2) Null Authentication:		2) Null Authentication:
	skipping to change at page 16, line 38 ¶		skipping to change at page 20, line 31 ¶
	Parts of this document are derived from [RFC6881]. Participants of		Parts of this document are derived from [RFC6881]. Participants of
	the 2nd and 3rd SDO Emergency Services Workshop provided helpful		the 2nd and 3rd SDO Emergency Services Workshop provided helpful
	input.		input.
	We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc		We would like to thank Richard Barnes, Brian Rosen, James Polk, Marc
	Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT		Linsner, and Martin Thomson for their feedback at the IETF#80 ECRIT
	meeting.		meeting.
	Furthermore, we would like to thank Martin Thomson and Bernard Aboba		Furthermore, we would like to thank Martin Thomson and Bernard Aboba
	for their detailed document review in preparation of the 81st IETF		for their detailed document review in preparation of the 81st IETF
	meeting.		meeting. Alexey Melnikov was the General Area (Gen-Art) reviewer. A
			number of changes to the document had been made in response to the AD
			review by Richard Barnes.
	9. IANA Considerations		9. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for		[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
	skipping to change at page 18, line 19 ¶		skipping to change at page 22, line 15 ¶
	[I-D.winterbottom-geopriv-lis2lis-req]		[I-D.winterbottom-geopriv-lis2lis-req]
	Winterbottom, J. and S. Norreys, "LIS to LIS Protocol		Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
	Requirements", draft-winterbottom-geopriv-lis2lis-req-01		Requirements", draft-winterbottom-geopriv-lis2lis-req-01
	(work in progress), November 2007.		(work in progress), November 2007.
	[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.		[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
	Shanmugam, "Security Threats and Requirements for		Shanmugam, "Security Threats and Requirements for
	Emergency Call Marking and Mapping", RFC 5069, January		Emergency Call Marking and Mapping", RFC 5069, January
	2008.		2008.
			[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
			Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
			3748, June 2004.
			[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
			Authentication Protocol", RFC 5216, March 2008.
	[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,		[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
	Tschofenig, H., and H. Schulzrinne, "An Architecture for		Tschofenig, H., and H. Schulzrinne, "An Architecture for
	Location and Location Privacy in Internet Applications",		Location and Location Privacy in Internet Applications",
	BCP 160, RFC 6280, July 2011.		BCP 160, RFC 6280, July 2011.
	[esw07] , "3rd SDO Emergency Services Workshop,		[esw07] , "3rd SDO Emergency Services Workshop,
	http://www.emergency-services-coordination.info/2007Nov/",		http://www.emergency-services-coordination.info/2007Nov/",
	October 30th - November 1st 2007.		October 30th - November 1st 2007.
	[nwgstg3] , "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network		[nwgstg3] , "WiMAX Forum WMF-T33-001-R015V01, WiMAX Network
	skipping to change at page 19, line 20 ¶		skipping to change at page 23, line 20 ¶
	Phone: +44 1753 667099		Phone: +44 1753 667099
	Email: smccann@rim.com		Email: smccann@rim.com
	URI: http://www.rim.com		URI: http://www.rim.com
	Gabor Bajko		Gabor Bajko
	Nokia		Nokia
	Email: Gabor.Bajko@nokia.com		Email: Gabor.Bajko@nokia.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Solutions and 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
	Dirk Kroeselberg		Dirk Kroeselberg
	Siemens		Siemens
End of changes. 27 change blocks.
	69 lines changed or deleted		273 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/