Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
Expires: August 29, 2006 A. Newton
Verisign, Inc.
H. Schulzrinne
Columbia U.
H. Tschofenig
Siemens
February 25, 2006
An Emergency Service Mapping Protocol (ESMP)
draft-hardie-ecrit-esmp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes an XML-based protocol for passing location
information to a server that returns emergency service contact URIs.
It is intended to fit within a larger framework of standards.
Hardie, et al. Expires August 29, 2006 [Page 1]
Internet-Draft ESMP February 2006
Specifically, it presumes the existence of a URI scheme appropriate
for signalling that emergency service is required and distinguishing
among emergency services if appropriate. It also presumes that an
entity requesting this response will be able to handle the URIs
returned as input to appropriate handlers.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. A Simple Example . . . . . . . . . . . . . . . . . . . . . 6
2.4. Deployment Methods . . . . . . . . . . . . . . . . . . . . 7
3. Service Types . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Hardie, et al. Expires August 29, 2006 [Page 2]
Internet-Draft ESMP February 2006
1. Requirements notation
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 [3].
Hardie, et al. Expires August 29, 2006 [Page 3]
Internet-Draft ESMP February 2006
2. Introduction
This document describes a protocol for taking location information
compatible with PIDF-LO [9] and passing it to a mapping server using
an XML schema specific to the task of returning emergency service
contact URIs. These URIs may be of multiple forms, including sip,
xmpp, and tel, and multiple URIs may be returned to a single query.
It is a feature of the overall system of which this forms a part that
multiple entities may request the lookup and perform the substitution
of the emergency service contact URI.
This document names this protocol usage "ESMP" for Emergency Service
Mapping Protocol (ESMP). The features of ESMP are:
o Supports queries using civic as well as geospatial location
information.
o Can be used in both recursive and iterative resolution.
o Through the re-use of an existing protocol, contains search-
oriented directory semantics.
o Can be used for civic address validation.
o A hierarchical deployment of mapping servers is independent of
civic location labels.
o Can communicate erroneous requests to facillitate debugging and
proper user feedback while simultaneously providing best-effort
answers.
o Mapping can be based on either civic or geospatial location
information, with no performance penalty for either.
o Service regions can overlap.
o Satisfies the requirements [5] for mapping protocols.
o Minimizes round trips by caching individual mappings as well as
coverage regions ("hinting"). Unless otherwise desired, there is
only one message exchange (roundtrip delay) between the ESRP or
end system requesting a mapping (i.e., mapping client) and the
designated resolver. This also facilitates reuse of TLS or other
secure transport association across multiple queries.
This document focuses on the description of the mapping client to
mapping server protocol. The bigger picture concerning the
relationship between other documents, such as discovery of mapping
Hardie, et al. Expires August 29, 2006 [Page 4]
Internet-Draft ESMP February 2006
servers, database replication and the overall mapping server
architecture in general, will be described in a separate document.
[10] is a first attempt to describe such a mapping server
architecture.
2.1. Usage
The intended usage of this protocol is a simple client query to a
server that yields a result. The result may contain a URI for a
single contact method or URIs for multiple contact methods, a
reference to another server to which the client should send a query,
and error messages indicating problems with interpretation of
location information. The combination of these components are left
to the needs and policy of the jurisdiction where the server is being
operated.
The interaction between the client and server happen in two ways:
1. During client attachment to a network and at cache expiration or
invalidation, the client will send its location to a server over
TCP, optionally tunneled inside of TLS. The server response will
contain the URIs of the most appropriate PSAP and may contain
information relevant for maintaining those URIs in a client-side
cache.
2. At emergency call time, the client will send it location to a
server over UDP to verify as quickly as possible the correct URIs
with which to contact a PSAP. The XML in this exchange will be a
proper subset of of the XML sent over TCP but designed to be
compact so that it may fit within one Internet packet for
transmission and reception.
Cached answers are expected to be used by clients only after failing
to accomplish a location-to-URI mapping at emergency call time.
Cache entries may expire according to a time-to-live value, or they
may become invalid if the location of the caller's device moves
outside the boundary limits of the cache entry. Boundaries for cache
entries may be set in both geospatial and civic terms.
2.2. Discovery
Discovery of ESMP services is to be provided by network elements
local to the client, hopefully via the same mechanisms providing
clients with location information. For instance, clients may obtain
their location information via DHCP using optional civic or location
request methods. Therefore, DHCP could also be used to provide
clients a reference to the most appropriate ESMP server.
Hardie, et al. Expires August 29, 2006 [Page 5]
Internet-Draft ESMP February 2006
2.3. A Simple Example
After performing link layer attachment and end host performs stateful
address autoconfiguration (in our example) using DHCP. DHCP provides
the end host with civic location information (encoded in UTF-8
format):
+--------+---------------+
| CAtype | CAvalue |
+--------+---------------+
| 0 | US |
| 1 | New York |
| 3 | New Yor |
| 6 | Broadway |
| 22 | Suite 75 |
| 24 | 10027-0401 |
+--------+---------------+
Figure 1: DHCP Civic Example
Additionally, DHCP provides information about the ESMP server that
has to be contacted. An additional step of indirection is possible,
for example by referring to a domain name that has to be resolved to
one or multiple IP addresses referring to ESMP servers).
When the user wants to make an emergency call (seeking for help from
the police) the following protocol interaction takes place. The
client encapsulates the received civic location information into XML
and puts it into a message. A code snippet of the search query is
shown below.
C:
C:
C:
C: US
C: New York
C: New York
C: Broadway
C: 123
C: Suite 75
C: 10027-0401
C:
C:
C: urn:service:sos.police
C:
Hardie, et al. Expires August 29, 2006 [Page 6]
Internet-Draft ESMP February 2006
C:
Since the contacted ESMP server has the requested information
available the following response message is returned. The response
indicates, as a human readable display string that the 'New York City
Police Department' is responsible for the given geographical area.
The indicated URI allows the user to start SIP based communication.
A code snippet of the response is shown below:
S:
S:
S:
S: New York City Police Department
S:
S: urn:service:sos.police
S:
S: sip:nypd@example.com
S: xmpp:nypd@example.com
S:
S:
S:
2.4. Deployment Methods
Because services for emergency contact resolution may differ
depending jurisdiction need, this document only specifies the "wire
format" for ESMP services and explicitly leaves open the possibility
for many different types of deployment.
For instance:
During discovery, a client may be directed to issue all queries to
an ESMP service completely authoritative for a given jursidiction.
A client may be directed to issue queries to an ESMP server that
acts as a reflector. In such a case, the ESMP server analyzes the
query to determine the best server to wich to refer the client.
Or the client may be directed to a server that performs further
resolution on behalf of the client.
An ESMP service may also be represented by multiple ESMP servers,
either grouped together or at multiple network locations. Using
S-NAPTR [11], clients may be given a list of multiple servers to
which queries can be sent for a single service.
Hardie, et al. Expires August 29, 2006 [Page 7]
Internet-Draft ESMP February 2006
For instance, the service at emergency.example.com may advertise ESMP
service at local1.emergency.example.com,
local2.emergency.example.com, and master.emergency.example.com. Each
server may given a different preference. In this case, 'local1' and
'local2' may be given a lower preference (more preferred) than
'master', which might be a busier server or located further away.
+-----------+ pref 10 +-----------+
| |-------------------->+ |
| client |------ | local1 |
| |--- \ | |
+-----------+ \ \ +-----------+
\ \
\ \ +-----------+
\ \ pref 10 | |
\ --------->| local2 |
\ | |
\ +-----------+
\
\ +-----------+
\ pref 20 | |
------------------------->| master |
| |
+-----------+
Hardie, et al. Expires August 29, 2006 [Page 8]
Internet-Draft ESMP February 2006
3. Service Types
Types of emergency service are specified by the element.
The emergency identifiers listed in the registry established with [6]
will be used in this document.
This information is provided as a hint from the client to the server
and is not intended to produce no results should the
element not be given or if its specified type is not available. In
other words, servers MUST ignore this information if it would cause
no result to be returned.
Hardie, et al. Expires August 29, 2006 [Page 9]
Internet-Draft ESMP February 2006
4. Security Considerations
There are multiple threats to the overall system of which this forms
a part. An attacker that can obtain emergency service contact URIs
can use those URIs to attempt to disrupt emergency services. An
attacker that can prevent the lookup of contact URIs can hinder the
request of emergency services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this as a
springboard to a physical attack.
A more detailed description of threats and security requirements are
provided in [4].
[Editor's Note: A future version of this document will describe the
countermeasures based on the security requirements outlined in [4].]
Hardie, et al. Expires August 29, 2006 [Page 10]
Internet-Draft ESMP February 2006
5. Open Issues
A number of open issues have been identified that are not yet
addressed by this draft version:
o ESMP service operators may determine which transfer protocol most
meets their needs, and advertise their availability using the DNS
DDDS application S-NAPTR [11]. The aspect of service discovery
and load balancing needs to be described.
o The name 'ESMP' is a placeholder before a better name is found.
o An internationalization considerations section is needed.
o The XML schema's are not yet provided.
o Full-fletched examples are missing.
o The security consideration section is incomplete.
o The IANA consideration section is missing.
Hardie, et al. Expires August 29, 2006 [Page 11]
Internet-Draft ESMP February 2006
6. References
6.1. Normative References
[1] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
W3C XML Schema, October 2000,
.
[2] World Wide Web Consortium, "XML Schema Part 1: Structures",
W3C XML Schema, October 2000,
.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[4] Schulzrinne, H., "Security Threats and Requirements for
Emergency Calling", draft-taylor-ecrit-security-threats-01 (work
in progress), December 2005.
[5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-03 (work in progress),
February 2006.
[6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-schulzrinne-sipping-service-01 (work in progress),
October 2005.
[7] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03 (work in progress),
November 2001.
[8] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003.
[9] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004.
6.2. Informative References
[10] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-schulzrinne-ecrit-mapping-arch-00 (work in
progress), October 2005.
[11] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
Hardie, et al. Expires August 29, 2006 [Page 12]
Internet-Draft ESMP February 2006
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
Andrew Newton
Verisign, Inc.
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Hardie, et al. Expires August 29, 2006 [Page 13]
Internet-Draft ESMP February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hardie, et al. Expires August 29, 2006 [Page 14]