ECRIT J. Winterbottom
Internet-Draft CommScope
Updates: I-D.ietf.ecrit.phonebcp H. Tschofenig
(if approved) Nokia Siemens Networks
Intended status: Standards Track L. Liess
Expires: April 19, 2013 Deutsche Telekom
October 16, 2012
Out of Jurisdiction Emergency Routing
draft-winterbottom-ecrit-priv-loc-03
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 April 19, 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 April 19, 2013 [Page 1]
Internet-Draft Out of Jurisdiction Emergency Routing October 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. HELD Extensions to Support Emergency Routing Information . . . 11
7.1. HELD Schema Extension . . . . . . . . . . . . . . . . . . 12
7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. URN sub-namespace registration for
'urn:ietf:params:xml:ns:geopriv:held:eri' . . . . . . . . 14
10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Winterbottom, et al. Expires April 19, 2013 [Page 2]
Internet-Draft Out of Jurisdiction Emergency Routing October 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 April 19, 2013 [Page 3]
Internet-Draft Out of Jurisdiction Emergency Routing October 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 [