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.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/