ECRIT J. Winterbottom Internet-Draft Winterb Consulting Services Updates: RFC6881 (if approved) H. Tschofenig Intended status: Standards Track Expires: November 30, 2014 L. Liess Deutsche Telekom May 29, 2014 A Routing Request Extension for the HELD Protocol draft-winterbottom-ecrit-priv-loc-04.txt Abstract In many circumstances public LoST servers or a distributed network of forest guides linking public LoST servers is not available. In such environments the general ECRIT calling models breakdown. However, location servers operating in these areas are often privy to the necessary information to reach emergency and other services. This document describes a solution where by the routing information may be obtained from a location server using a simple extension to the HELD 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 November 30, 2014. Copyright Notice Copyright (c) 2014 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 Winterbottom, et al. Expires November 30, 2014 [Page 1] Internet-Draft HELD Routing May 2014 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 11 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Winterbottom, et al. Expires November 30, 2014 [Page 2] Internet-Draft HELD Routing May 2014 1. Introduction In many circumstances public LoST [RFC5222] servers or a distributed network of forest guides linking public LoST servers is not available. In such environments the general ECRIT calling models breakdown. Location servers operating in these areas are often privy to the necessary information to reach emergency and other services. This document describes how adding an extension to the HELD protocol [RFC5985] can used to extract this information for a location information server in the absence of a LoST server or network of forest guides. 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]. The term "Access Network Provider" is used as defined in [RFC5687] and incompasses both the Internet Access Provider (IAP) and Internet Service Provider (ISP). Winterbottom, et al. Expires November 30, 2014 [Page 3] Internet-Draft HELD Routing May 2014 3. Motivation The Internet emergency calling architecture specified in [RFC6881] 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 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] [RFC6915] and then determining the route to the local PSAP using LoST [RFC5222]. Figure 2 shows the high-level protocol interactions. Winterbottom, et al. Expires November 30, 2014 [Page 4] Internet-Draft HELD Routing May 2014 +---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 performs two tasks. The first task is to determine the correct LIS to ask for location information, this is done using a combination of reverse DNS lookup described in [RFC7216] to acquire the serving domain name and then using [RFC5986] to determine the LIS URI. Once the location is obtained from the LIS, the VSP determines the LoST server associated with the domain serving the caller and queries it for the correct PSAP address. LoST server discovery is a domain based activity, similar to the LIS discovery technique. However, unlike the LIS that is a domain bound service, a LoST server is a geographically bound service. This means that for a domain that spans multiple geographic regions the LoST server determined may not be able to provide a route to the necessary PSAP. When this occurs, the contacted LoST server invokes the help of other LoST servers and this requires the deployment of forest guides. At the time of writing, several countries have expressed their reluctance to deploy public LoST servers. In countries amenable to use of LoST and forest guides no public forest guides have been deployed. There appears little interest from the public sector in establishing a global forest guide network. These issues pose threats to both the device-centric and the softswitch-centric calling approaches in terms of them operating everywhere. Winterbottom, et al. Expires November 30, 2014 [Page 5] Internet-Draft HELD Routing May 2014 The device-centric and softswitch-centric calling models both involve the notion of a LIS bound to the serving access network. In many cases the LIS already knows the destination PSAP address for any given location. In [RFC6881] for example, the LIS validates all civic locations using a location validation procedure. This procedure is the same as a routing request and so the LIS has the resulting the PSAP routing information. In other cases, the LIS knows the correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider. Irrespective of the way in which the LIS learns the PSAP address for a location, the LIS will, in a great many cases, have this information. This document specifies an extension to the HELD protocol so that emergency routing information can be requested from the LIS at the same time that location information is requested. The document updates [RFC6881] by requiring devices and softswitches that understand this specification to always request routing information to avoid the risk of query failure where no LoST server or forest guide network is deployed. 4. Mechanism The mechanism consists of adding an element to the HELD locationRequest and an element to the locationResponse. The request element indicates that the requestor wants the LIS to provide routing information for the location where the device is. If the LIS understands the routing request and has routing information accessible it provides the information in a routingInformation element included in the locationResponse. How the LIS obtains this information is left to implementation, one possible option is that the LIS acquires it from a LoST server, other possibilities are described in Section 3. A LIS that does not understand the routing request element ignores it and returns location as normal. A LIS that does understand the routing request element but can't obtain routing information returns location as normal. The routing information in the location response consists of one or more service elements which is identified by a service name. The service name is a URI and might contain a general emergency service urn such as urn:service:sos or might contain a specific service urn. For each service name a list of one or more service destinations is provided. Each destination is expressed as a URI and each URI scheme should only appear once in this list. The routing information is Winterbottom, et al. Expires November 30, 2014 [Page 6] Internet-Draft HELD Routing May 2014 intended to be used at the time it is received. To avoid any risks of using stale routing information the value should not be cached by the receiving entity. Reusing the mapping element from the LoST findServiceResponse message to provide the routing information was considered. However, this would have meant that several of the mandatory components in the mapping element would have had to contain ambiguous or misleading values. Specifically, the "source" attribute is required to contain a LoST application unique string for the authoritative server. However, in the situations described in this specification there may not be an authoritative LoST server, so any value put into this attribute would be misleading. In addition to this, routing information received in the manner described in this specification should not be cached by the receiver, so detailing when the routing information expires or was last updated is irrelevant. Winterbottom, et al. Expires November 30, 2014 [Page 7] Internet-Draft HELD Routing May 2014 5. HELD Schema Extension This section describes the schema extension to HELD. Winterbottom, et al. Expires November 30, 2014 [Page 8] Internet-Draft HELD Routing May 2014 6. Examples Figure 3 illustrates a example that contains IP flow information in the request.
192.168.1.1
1024
10.0.0.1
80 Figure 3: Example Location Request. Winterbottom, et al. Expires November 30, 2014 [Page 9] Internet-Draft HELD Routing May 2014 Figure 4 illustrates the message containing two location URIs: a HTTPS and a SIP URI. Additionally, the response contains routing information. https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com sip:nypd@example.com sips:nypd@example.com xmpp:nypd@example.com sip:fd@ny.example.com sips:fd@ny.example.com xmpp:fd@ny.example.com Figure 4: Example Location Response 7. Privacy Considerations This document makes no changes that require privacy considerations beyond those already described in [RFC5985] and [RFC6155]. 8. Security Considerations This document imposes no additional security considerations beyond those already described in [RFC5985] and [RFC6155]. Winterbottom, et al. Expires November 30, 2014 [Page 10] Internet-Draft HELD Routing May 2014 9. IANA Considerations 9.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:geopriv:held:ri' This document calls for IANA to register a new XML namespace, as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:geopriv:held:ri Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), James Winterbottom (a.james.winterbottom@gmail.com). XML: BEGIN HELD Routing Information Extensions

Additional Element for HELD Routing Information

urn:ietf:params:xml:ns:geopriv:held:ri

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 9.2. XML Schema Registration This section registers an XML schema as per the procedures in [RFC3688]. URI: urn:ietf:params:xml:schema:geopriv:held:ri Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), James Winterbottom (a.james.winterbottom@gmail.com). The XML for this schema can be found as the entirety of Section 5 of this document. Winterbottom, et al. Expires November 30, 2014 [Page 11] Internet-Draft HELD Routing May 2014 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 early review comments and Bernd Henschel for his support. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [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. [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", RFC 6443, December 2011. [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013. 11.2. Informative References [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 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. [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)", RFC 6915, April 2013. Winterbottom, et al. Expires November 30, 2014 [Page 12] Internet-Draft HELD Routing May 2014 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS", RFC 7216, April 2014. Authors' Addresses James Winterbottom Winterb Consulting Services Gwynneville, NSW 2500 AU Phone: +61 448 266004 Email: a.james.winterbottom@gmail.com Hannes Tschofenig Halls in Tirol 6060 Austria Phone: 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 November 30, 2014 [Page 13]