Out of Jurisdiction Emergency Routing
draft-winterbottom-ecrit-priv-loc-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | James Winterbottom , Hannes Tschofenig , Laura Liess | ||
| Last updated | 2012-07-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-winterbottom-ecrit-priv-loc-01
ECRIT J. Winterbottom
Internet-Draft CommScope
Intended status: Standards Track H. Tschofenig
Expires: January 17, 2013 Nokia Siemens Networks
L. Liess
Deutsche Telekom
July 16, 2012
Out of Jurisdiction Emergency Routing
draft-winterbottom-ecrit-priv-loc-01.txt
Abstract
Some countries and regions require location information be
constrained to emergency service applications and do not permit
location information to traverse the end-point at all. This document
describes the requirements of these countries and provides a solution
based on an extension to the HELD location protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Winterbottom, et al. Expires January 17, 2013 [Page 1]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5
4. Key Observations . . . . . . . . . . . . . . . . . . . . . . . 6
5. Available Building Blocks . . . . . . . . . . . . . . . . . . 7
6. The Missing Link . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Domain Breakdown . . . . . . . . . . . . . . . . . . . . . 10
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Winterbottom, et al. Expires January 17, 2013 [Page 2]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
1. Introduction and Motivation
The Internet emergency calling architecture specified in
[I-D.ietf-ecrit-phonebcp] describes two main models for emergency
call processing. The first is a device-centric model, where a device
obtains location information using a location configuration protocol,
such a HELD [RFC5985], and then proceeds to determine the address of
the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1
shows this model in a simplified form.
+---Location Request---+
| (1) |
+---+----+ +---V---+
| |<--Location--| LIS |
| Caller | (2) +-------+ +--------+
| | | ESRP/ |
| |----Find Service-------+ | PSAP |
+------^-+ (3) | +--------+
| | +--------V----+ ^
| +-----Service----| LoST Server | |
| (4) +-------------+ +---+---+
+-------------Call Initiation------------>| VSP |
(5) +-------+
Figure 1: Device-Centric Emergency Services Model
With the ever increasing deployment of smart phones and tablet
devices a variation of the device-centric model is the ability to use
location available to the device for routing and then consult a LIS
when location is needed for dispatch. Location can come in various
forms to the device, e.g., from GPS, third party location databases,
as well as IP-to-geolocation services.
The second approach is a softswitch-centric model, where a device
initiates and emergency call and the serving softswitch detects that
the call is an emergency and initiates retrieving the caller's
location from a Location Information Server (LIS) using HELD
[RFC5985] with identity extensions [RFC6155] and then determining the
route to the local PSAP using LoST [RFC5222]. Figure 2 shows the
high-level protocol interactions.
Winterbottom, et al. Expires January 17, 2013 [Page 3]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
+---Location Request---+
| (2) |
+---V---+ |
| LIS | |
+----+--+ +----+----+
| | |
+----Location--->| Soft |
+--------+ (3) | Switch |
| Caller |------Call Initiation------------> | |
+--------+ (1) +-+-^---+-+
+-------------+ | | |
| LoST Server |<-Find Service--+ | |
+------+------+ (4) | |
| | |
+----------Service--------+ |
(5) |
+-----------+ |
| ESRP/PSAP |<------Call----+
+-----------+ (6)
Figure 2: Softswitch-Centric Calling Model
In the softswitch-centric model when a VSP receives an emergency call
it will encounter several difficulties. The first hurdle is for the
VSP to determine the correct LIS to ask for location information.
Having obtained the location, the VSP must then determine the correct
PSAP using a LoST server and this requires wide-spread deployment of
forest guides. This leads to a failure in the softswitch-centric
approach to deliver emergency calls correctly because the VSP is
unable to determine the correct PSAP to route the call to. The
softswitch-centric model should therefore seen only as a transition
architecture towards the end-device model where end devices have not
been upgraded. Software updates of end devices are, however, not a
problem anymore since software updates have to be provided to end
devices on a regular basis to patch security vulnerabilities. Any
service provider that does not have an ability to update devices will
not only put their own customers at risk but also other Internet
users as well since those can become the victims of attacks as well.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443].
Winterbottom, et al. Expires January 17, 2013 [Page 4]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
The term "Access Network Provider" is used as defined in [RFC5687]
and incompasses both the Internet Access Provider (IAP) and Internet
Service Provider (ISP).
3. Problem Description
There is a significant faction in the emergency services and the
regulatory community that do not want to rely on emergency calls
solutions with end-device provided location. This includes location
information that is determined by the network but subsequently
traverses the end-point prior to being delivered to the emergency
organization.
There are two concerns:
Security: One concern is about the possibility of the software of
the end device being able to tamper with location. This can lead
to denial of service attacks against the emergency services
infrastructure. [I-D.ietf-ecrit-trustworthy-location] describes
these concerns in detail.
Privacy: There is the desire to allow location information to be
provided to emergency organizations rather than any other party,
including the end device or a VSP. In the softswitch model the
VSP would have to ask the access provider for location
information. However, the number of VSPs asking for location
information could, at least in theory depending on the scope of
emergency services regulation be very large and is likely to
include VSPs that are located in a jurisdiction that is different
from the one of the access network provider. Allowing VSPs to ask
for location information of end devices at access network
providers in a third party fashion without the ability to present
the user's consent or the emergency service nature calls for
privacy problems. [RFC6155] discusses some of these privacy
challenges as part of the third party requests.
These arguments may, however, also jacked into place to hide another
reason, namely the desire to create an artifical relationship between
the VSP and the access network provider. [RFC6444] provides a
problem description and [I-D.ietf-ecrit-rough-loc] even offers a
solution based on rough location. This solutions, however, requires
the access network provider to compute these rough location shapes.
Countries that have a large number of PSAPs and neither an ESRP nor a
stage-1 PSAP architecture may encounter problems computing these
shapes.
The Internet calling model does not constrain the call to a single
Winterbottom, et al. Expires January 17, 2013 [Page 5]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
jurisdictional boundary nor does it assume that the Voice Service
provider (VSP) role is provided by the access provider. This allows
the VSP to be located anywhere on the Internet without requiring any
association with Internet access providers.
+----------------+ +----------------+ +----------------+
| Jurisdiction 1 | | Jurisdiction 2 | | Jurisdiction 3 |
| | | | | |
| | | | | |
| +--------------+--+----------------+--+--------------+ |
| | EMERGENCY CALL CENTRES | |
| +--------------+--+----------------+--+--------------+ |
| ^ ^ ^ | | | | |
| | | | | | | | |
| +-----+ | | | | +-----+ | | +-----+ |
| | VSP | | +--------| VSP | | | | VSP | |
| +--^--+ | | | +---^-+ | | +-----+ |
| | | | | | | | |
| +--------+-----+--+-------+--------+--+--------------+ |
| | | | | INTERNET | |
| +--------+-----+--+-----+----------+--+--------------+ |
| | | | | | | | |
| +--------+-----+--+-------+--------+--+--------------+ |
| | | | ACCESS | NETWORKS | |
| +--------------+--+-------+--------+--+--------------+ |
| | | | | | | | |
| | | +-------------+ | | |
| | | | | | | | |
| +------------+ | | | | |
| | EMERGENCY | | | | | |
| | CALLS | | | | | |
| +------------+ | | | | |
| +--------+-----+--+-----+----------+--+--------------+ |
| | | | DEVICES | |
| +--------------+--+-----+----------+--+--------------+ |
| | | | | |
+----------------+ +----------------+ +----------------+
e.g US State e.g. Australia e.g. European
Country
Figure 3: Internet Calling Models
4. Key Observations
When these security and privacy requirements are taken into
consideration then the emergency calling architecture and associated
Winterbottom, et al. Expires January 17, 2013 [Page 6]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
procedures described in [I-D.ietf-ecrit-phonebcp] and [RFC6443]
require some adaptation in some configurations to ensure universal
operation. The softswitch model fails to meet the privacy
requirements and the end-device model has to wrangle with security
challenges.
Several observations have been posed thus far:
Problem#1: Rough location information is required to route emergency
calls.
Problem#2: The VSP needs the ability to determine the correct LIS to
retrieve location information.
Problem#3: The VSP needs the ability to contact a LoST server to
acquire routing information from.
Problem#4: The end host does not acquire or convey location to the
emergency network.
Problem#5: Access network provider aim to provide location only to
emergency service authorities.
Problem#6: Precise location information is required to dispatch
first responders.
5. Available Building Blocks
To fulfill A number of building blocks are already available. There
is no need to start from a clean sheet.
Location: Location standards have existed for mobile cellular
networks since the mid to late 1990s, and location standards for
the Internet have existed since the mid to late 2000s. The exact
determination techniques for each access technology are different
but the ability to direct communications across a communications
network is inherenetly premised on being able to reach a specific
device and this requires some knowledge of where the device is
physically located. The term Location Information Server (LIS) is
used to identify the element in an access network responsible for
providing the location of a device in its administrative domain.
LIS service discovery techniques are described in [RFC5986] and
[I-D.ietf-geopriv-res-gw-lis-discovery].
Winterbottom, et al. Expires January 17, 2013 [Page 7]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
Call Routing: The LoST protocol [RFC5222] specifies a means to map
location and service information into a destination URI. Next
generation emergency services architectures and procedures, such
as those defined in [RFC6443], NENA i3, and the EENA NG112
document, use LoST for providing routing to local emergency
service authorities. LoST servers are discovered using DNS
U-NAPTR [RFC4848] to obtain a service URI. The discovered LoST
server services the domain in which the device is resident, or is
able to provide the identity of a LoST server that can service the
request. A access network provider that operates in an area
capable of receiving next generation emergency calls is able to
include a U-NAPTR record in their DNS servers that identifies the
local serving LoST server able to resolve emergency routing
requests.
LIS Discovery: [I-D.ietf-geopriv-res-gw-lis-discovery] provides a
means for discovering a LIS based on the IP address of a device
and this could be used in conjunction with [RFC6155] to provide a
solution to problem 2. The domain name discovered for the LIS
could be reused to discover the correct LoST server to contact
thereby solving problem 3.
6. The Missing Link
Problem 5 does not allow the LIS to provide location information
except to emergency authorities, and while the HELD protocol
[RFC5985] does allow a location URI to be returned to the requesting
entitiy, the LoST protocol [RFC5222] requires a location value and
does not support a location reference.
One possible solution to problem 5 is to extend LoST to support a
location URI in the findService request method. In this case a VSP
would detect that a device was making an emergency call, determine
the correct LIS to contact using
[I-D.ietf-geopriv-res-gw-lis-discovery], contact the LIS using HELD
[RFC5985] using the IP address of the calling device as an identity
extension [RFC6155] and the LIS would respond with a location URI
that requires client-side authentication for dereferencing Using the
LIS domain identifier the VSP would then determine the correct LoST
server and request emergency services using the location URI as the
location reference. The LoST server must have permission to
dereference the location URI, if any form of recurision is
encountered then the URI must be dereferenced multiple times
increasing the likelihood of failure.
An alternative approach is to leave LoST unchanged, but extend the
HELD protocol and requirements of the local LIS. In this solution,
Winterbottom, et al. Expires January 17, 2013 [Page 8]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
when the LIS receives the third-party request, it performs the
necessary LoST request using the location of the device. The LIS
responds with a location URI and the destination URI of the correct
emergency service authority. The Location URI will only yield
location information to the authorized emergency authority. This
solution addresses problem 1 problem 3, problem 4, problem 5.
Problem 2 is solved using a combination of
[I-D.ietf-geopriv-res-gw-lis-discovery] and HELD with identity
extensions.
6.1. Call Flow
1. Device initiates an emergency call to the user's VSP
2. The VSP's proxy detects emergency call and uses IP address to
determine the correct LIS to query using
[I-D.ietf-geopriv-res-gw-lis-discovery].
3. The VSP queries the LIS using HELD and the IP address of the
calling device as an identity extension.
4. The LIS determines the location and uses it request routing
information for the local LoST server.
5. The LIS return a location URI and the local Emergency Service
Routing Proxy (ESRP) URI to the VSP.
6. The VSP follows the guidance from [I-D.ietf-ecrit-phonebcp] and
routes the call to the ESRP.
7. The ESRP authenticates itself with the LIS when it dereferences
the location URI.
8. The returns location information to the ESRP allowing it route
the call to the correct PSAP.
Winterbottom, et al. Expires January 17, 2013 [Page 9]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
+------(2)Find LIS-----+
| |
+---V---+ |
| DNS | |
+----+--+ +----+---------+
| | |
+----LIS URI---->| |
+--------+ | VSP |
| Caller |------(1)-Call Initiation--------> | |
+--------+ +-+--^-------+-+
| | |
+-------------+ | | |
| |<------(3)-locationReq(IP)-------+ | |
| LIS | | |
| |--(5)-locationResp(locURI,EcrfURI)--+ |
+-+--^---+--^-+ |
| | | | +-------------+ |
| | | +-----Service----+ | |
| | | | LoST Server | |
| | +-(4)-Find Service->| | |
| | +-------------+ |
| | |
| | +-----------+ |
| +--(7)-locReq(Auth)--+ | |
| | ESRP/PSAP |<--(6)-Call(locURI)-+
+---(8)-locResp(Loc)--->| |
+-----------+
Figure 4: Modified Softswitch-Centric Emergency Call Flow
6.2. Domain Breakdown
The key advantage of the call flow show in Section 6.1 is that it
separates the entities into two clear groups, those that are inside
the regulatory emergency jurisdiction and those that are in the
Internet. This is evident in Figure 5.
Winterbottom, et al. Expires January 17, 2013 [Page 10]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
+------(2)Find LIS-----+
| |
+---V---+ |
| DNS | |
+----+--+ +----+---------------+
| | |
+----LIS URI---->| |
| VSP |
| |
+-^---+----^-------+-+
I N T E R N E T | | | |
=========================================|===|====|=======|===
LOCAL JURISDICTION | | | |
+--------+ | | | |
| Caller |------(1)-Call Initiation------+ | | |
+--------+ | | |
| | |
+-------------+ | | |
| |<------(3)-locationReq(IP)-----+ | |
| LIS | | |
| |--(5)-locationResp(locURI,EcrfURI)--+ |
+-+--^---+--^-+ |
| | | | +-------------+ |
| | | +-----Service----+ | |
| | | | LoST Server | |
| | +-(4)-Find Service->| | |
| | +-------------+ |
| | |
| | +-----------+ |
| +--(7)-locReq(Auth)--+ | |
| | ESRP/PSAP |<--(6)-Call(locURI)-+
+---(8)-locResp(Loc)--->| |
+-----------+
Figure 5: Emergency Call Domains
7. Privacy Considerations
[[TBD.]]
8. Security Considerations
[[TBD.]]
Winterbottom, et al. Expires January 17, 2013 [Page 11]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
9. IANA Considerations
[[TBD.]]
10. Acknowledgements
We would like to thank Wilfried Lange for sharing his views with us.
We would also like to thank Bruno Chatras for his review comments.
11. References
11.1. Normative References
[I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011.
[I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
Thomson, "A Location Dereferencing Protocol Using HELD",
draft-ietf-geopriv-deref-protocol-07 (work in progress),
July 2012.
[I-D.ietf-geopriv-res-gw-lis-discovery]
Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery using IP address and Reverse DNS",
draft-ietf-geopriv-res-gw-lis-discovery-03 (work in
progress), March 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Winterbottom, et al. Expires January 17, 2013 [Page 12]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
Location Information Server (LIS)", RFC 5986,
September 2010.
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", RFC 6155, March 2011.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, December 2011.
11.2. Informative References
[I-D.ietf-ecrit-rough-loc]
Barnes, R. and M. Lepinski, "Using Imprecise Location for
Emergency Context Resolution",
draft-ietf-ecrit-rough-loc-04 (work in progress),
March 2011.
[I-D.ietf-ecrit-trustworthy-location]
Tschofenig, H., Schulzrinne, H., and B. Aboba,
"Trustworthy Location Information",
draft-ietf-ecrit-trustworthy-location-03 (work in
progress), April 2012.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4079] Peterson, J., "A Presence Architecture for the
Distribution of GEOPRIV Location Objects", RFC 4079,
July 2005.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic
Addresses in the Presence Information Data Format Location
Object (PIDF-LO): Guidelines and IANA Registry
Definition", BCP 154, RFC 5774, March 2010.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and
A. Kuett, "Location Hiding: Problem Statement and
Requirements", RFC 6444, January 2012.
Winterbottom, et al. Expires January 17, 2013 [Page 13]
Internet-Draft Out of Jurisdiction Emergency Routing July 2012
Authors' Addresses
James Winterbottom
CommScope
Suit 1, Level 2
iC Enterprise 1, Innovation Campus
Squires Way
North Wollongong, NSW 2500
AU
Phone: +61 242 212938
Email: james.winterbottom@commscope.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Laura Liess
Deutsche Telekom Networks
Deutsche Telekom Allee 7
Darmstadt, Hessen 64295
Germany
Phone:
Email: L.Liess@telekom.de
URI: http://www.telekom.de
Winterbottom, et al. Expires January 17, 2013 [Page 14]