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]