From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7840.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc7840.txt (limited to 'doc/rfc/rfc7840.txt') diff --git a/doc/rfc/rfc7840.txt b/doc/rfc/rfc7840.txt new file mode 100644 index 0000000..fdf9e9a --- /dev/null +++ b/doc/rfc/rfc7840.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Winterbottom +Request for Comments: 7840 Winterb Consulting Services +Updates: 5985, 6881 H. Tschofenig +Category: Standards Track +ISSN: 2070-1721 L. Liess + Deutsche Telekom + May 2016 + + + A Routing Request Extension for + the HTTP-Enabled Location Delivery (HELD) Protocol + +Abstract + + For cases where location servers have access to emergency routing + information, they are able to return routing information with the + location information if the location request includes a request for + the desired routing information. This document specifies an + extension to the HTTP-Enabled Location Delivery (HELD) protocol that + updates RFC 5985 to support this function. Allowing location and + routing information to be acquired in a single request response + exchange updates RFC 6881, as current location acquisition and route + determination procedures are separate operations. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7840. + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 1] + +RFC 7840 HELD Routing May 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6 + 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7 + 6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. URN Sub-Namespace Registration for + 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13 + 10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 11.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 2] + +RFC 7840 HELD Routing May 2016 + + +1. Introduction + + The general Emergency Context Resolution with Internet Technology + (ECRIT) calling models described in [RFC6443] and [RFC6881] require a + local Location-to-Service Translation (LoST) server or network of + forest guides in order to determine the address of the Public Safety + Answering Point (PSAP) in the best position to handle a call. + Networks of forest guides have not materialized and while PSAPs are + moving towards IP networks, LoST server deployment is not ubiquitous. + Some regions and countries have expressed reluctance to deploy LoST + servers making aspects of the current ECRIT architecture hard to + realize. + + To address regulatory requirements, such as [M493], evolving + architectures in Europe couple location and routing information in + the access network while using a softswitch-centric approach to + emergency call processing. This document describes an extension to + the HELD protocol [RFC5985], so that a location information server + can provide emergency routing information 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 "Location Information Server (LIS)", "Emergency Services + Routing Proxy (ESRP)", "Voice Service Provider (VSP)", and "Public + Safety Answering Point (PSAP)" are used as defined in [RFC6443]. + + The term "Access Network Provider" is used as defined in [RFC5687] + and encompasses both the Internet Access Provider (IAP) and Internet + Service Provider (ISP). + + The term "forest guide" is used as defined in [RFC5582]. + +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 as 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. + + + + + +Winterbottom, et al. Standards Track [Page 3] + +RFC 7840 HELD Routing May 2016 + + + +---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 an emergency call, and the serving softswitch detects that + the call is an emergency and initiates retrieving the caller's + location from a LIS using HELD [RFC5985] with identity extensions + [RFC6155] [RFC6915] and then determines the route to the local PSAP + using LoST [RFC5222]. Figure 2 shows the high-level protocol + interactions. + + +---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 + + + + + + +Winterbottom, et al. Standards Track [Page 4] + +RFC 7840 HELD Routing May 2016 + + + 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 a reluctance + to deploy public LoST servers. In countries amenable to the use of + LoST and forest guides, no public forest guides have been deployed. + There appears to be little interest from the public sector in + establishing a global forest-guide network. These issues pose + threats to the ability of both the device-centric and the softswitch- + centric calling approaches to operate everywhere. + + 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 URI for any given + location. In [RFC6881], for example, the LIS validates civic + locations using a location validation procedure based on the LoST + protocol [RFC5222]. The LoST validation request is similar to a LoST + routing request and provides the LIS with the same PSAP routing + information that a routing request would. 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 URI for a + location, the LIS will, in a great many cases, already 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. This 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. + + + + +Winterbottom, et al. Standards Track [Page 5] + +RFC 7840 HELD Routing May 2016 + + +3.1. LoST Reuse Considerations + + The LoST protocol [RFC5222] defines a element that + describes a service region and associated service URLs. Reusing this + element from LoST to provide the routing URIs was considered. + However, this would have meant that several of the mandatory + components in the 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. + +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 based on the location of the end device. + If the routing request is sent with no attribute, then URIs for + urn:service:sos are returned. If the requestor wants routing + information for a specific service, then they may include an optional + service URN. This service MUST exist in the IANA "Service URN + Labels" repository created by [RFC5031]. If a service is specified, + and the LIS does not understand the requested service, then URIs for + urn:service:sos are returned. + + If the LIS understands the routing request and has routing + information for the location, then it includes the information in a + routingInformation element returned in the locationResponse. How the + LIS obtains this information is left to implementation. + Possibilities are described in Section 3. + + A LIS that does not understand the routing request element ignores it + and returns the location information in the normal manner. + + A LIS that does support the routing request element MUST support + returning URIs for urn:service:sos and any regionally defined sub- + services while following the URN traversal rules defined in + [RFC5031]. + + + + + + + +Winterbottom, et al. Standards Track [Page 6] + +RFC 7840 HELD Routing May 2016 + + + A LIS that does understand the routing request element but can't + obtain any routing information for the end-device's location MUST set + the defaultRoute attribute to "true" and return a default PSAP or + gateway URI along with the determined location information in the + locationResponse. + + A LIS that understands the routing request element but not the + specified service URN MUST follow the URN traversal rules defined in + [RFC5031]. + + A LIS that receives a request for emergency routing information that + it understands MUST return the correct emergency routing information + if it has or is able to acquire the routing information for the + location of the target device. + + The routing information in the location response consists of a + service element identified by a service name. The service name is a + URN and might contain a general emergency service URN such as + urn:service:sos or a specific service URN depending on what was + requested and what the LIS is able to provide. A list of one or more + service destinations is provided for the service name. Each + destination is expressed as a URI, and each URI scheme should only + appear once in this list. The routing URIs are intended to be used + at the time they are received. To avoid any risks of using stale + routing URIs, the values MUST NOT be cached by the receiving entity. + +5. Modification to Phone BCP + + This section describes the normative updates to Phone BCP [RFC6881]. + + It is important for devices and intermediaries to take all steps + possible to ensure that emergency calls are routed to the correct + PSAP. An alternative to providing routing information via global + forest guides or local LoST servers is for local networks to + configure the PSAP address information in the network location + server. This specification updates Phone BCP [RFC6881] to provide + this option. The update requires devices and intermediaries using + the HELD protocol to always include the HELD routing extension. If + the LIS is configured with the routing information, it can provide + it; if it is not, then the device or intermediary tries LoST to + acquire the PSAP URI. + + Section 6.5 of [RFC6881] defines "End System Location Configuration". + Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the + Location Configuration Protocol (LCP) such that "the request MUST + include the requestRoutingInformation element." The remainder of the + requirement remains unchanged. + + + + +Winterbottom, et al. Standards Track [Page 7] + +RFC 7840 HELD Routing May 2016 + + + This document adds a new requirement to Section 7 of [RFC6881]. + + "ED-51a : Endpoints MUST support the HELD requestRoutingInformation + element and be able to interpret and use any routing information + returned in the locationResponse." + + This document adds two new requirements to Section 8 of [RFC6881]. + + "ED-52a : Endpoints that acquire routing information in a HELD + locationResponse SHOULD use this routing information but MAY perform + a LoST findService request if they have a location value." + + "ED-52b : Endpoints that acquire routing information in a HELD + locationResponse with a defaultRoute attribute of "true" MUST perform + a LoST findService request if they have a location value. If a route + is provided by the LoST server, then this route MUST be used, + otherwise the routing information provided in the HELD response + SHOULD be used." + + This document amends SP-26 from Section 8 of [RFC6881] such that a + LoST mapping need not be requested if non-default routing information + is provided in the HELD locationResponse. + +6. HELD Schema Extension + + This section describes the schema extension to HELD. + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 8] + +RFC 7840 HELD Routing May 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 9] + +RFC 7840 HELD Routing May 2016 + + +7. Examples + + Figure 3 illustrates a example that contains IP + flow information in the request. + + + + + + + +
192.0.2.12
+ 1024 + + +
192.0.2.195
+ 80 + + + + + Figure 3: Example Location Request + + + + + + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 10] + +RFC 7840 HELD Routing May 2016 + + + Figure 4 illustrates the message containing two + location URIs: an HTTPS and a SIP URI. Additionally, the response + contains routing information. + + + + + https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o + + + sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com + + + + + + sip:112@example.com + sips:112@example.com + xmpp:112@example.com + + + + + + Figure 4: Example Location Response + + + + + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 11] + +RFC 7840 HELD Routing May 2016 + + + Figure 5 illustrates the message containing + default routing information and an HTTPS location URI. + + + + + https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o + + + + + + sip:112@example.com + sips:112@example.com + xmpp:112@example.com + + + + + + Figure 5: Example Location Response with Default Routing Information + +8. Privacy Considerations + + This document makes no changes that require privacy considerations + beyond those already described in [RFC5985]. It does, however, + extend those described in [RFC6155]. + + [RFC5985] describes the privacy considerations surrounding the HELD + location configuration protocol, and this document makes no specific + changes to these considerations. + + [RFC6155] extends HELD beyond a simple LCP by enabling authorized + third parties to acquire location information and describing the + issues in Section 4. The HELD routing extension supports returning + URIs that represent specific services operating in the Target's + vicinity. This represents additional information about the Target; + as a consequence, it is recommended that this option only be used + when the LIS returns a location URI, not a location value. + +9. Security Considerations + + This document imposes no additional security considerations beyond + those already described in [RFC5985] and [RFC6155]. + + + + + + +Winterbottom, et al. Standards Track [Page 12] + +RFC 7840 HELD Routing May 2016 + + +10. IANA Considerations + +10.1. URN Sub-Namespace Registration for + 'urn:ietf:params:xml:ns:geopriv:held:ri' + + Per this document, IANA has registered a new XML namespace, following + 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

+

See + RFC 7840.

+ + + END + +10.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). + + XML: The XML for this schema can be found as the entirety of + Section 6 of this document. + + + + + + + +Winterbottom, et al. Standards Track [Page 13] + +RFC 7840 HELD Routing May 2016 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", + RFC 5985, DOI 10.17487/RFC5985, September 2010, + . + + [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for + Communications Services in Support of Emergency Calling", + BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, + . + +11.2. Informative References + + [M493] European Telecommunications Standards Institute, + "Functional architecture to support European requirements + on emergency caller location determination and transport", + ES 203 178, V1.1.1, February 2015. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for + Emergency and Other Well-Known Services", RFC 5031, + DOI 10.17487/RFC5031, January 2008, + . + + [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. + Tschofenig, "LoST: A Location-to-Service Translation + Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, + . + + [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and + Framework", RFC 5582, DOI 10.17487/RFC5582, September + 2009, . + + [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 + Location Configuration Protocol: Problem Statement and + Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010, + . + + + + +Winterbottom, et al. Standards Track [Page 14] + +RFC 7840 HELD Routing May 2016 + + + [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local + Location Information Server (LIS)", RFC 5986, + DOI 10.17487/RFC5986, September 2010, + . + + [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. + Barnes, "Use of Device Identity in HTTP-Enabled Location + Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March + 2011, . + + [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, + "Framework for Emergency Calling Using Internet + Multimedia", RFC 6443, DOI 10.17487/RFC6443, December + 2011, . + + [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled + Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915, + April 2013, . + + [RFC7216] Thomson, M. and R. Bellis, "Location Information Server + (LIS) Discovery Using IP Addresses and Reverse DNS", + RFC 7216, DOI 10.17487/RFC7216, April 2014, + . + +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 Keith Drage for his more detailed review. Thanks to + Roger Marshall and Randy Gellens for their helpful suggestions. + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 15] + +RFC 7840 HELD Routing May 2016 + + +Authors' Addresses + + James Winterbottom + Winterb Consulting Services + Gwynneville, NSW 2500 + Australia + + Phone: +61 448 266004 + Email: a.james.winterbottom@gmail.com + + + Hannes Tschofenig + Hall in Tirol 6060 + Austria + + Email: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + Laura Liess + Deutsche Telekom Networks + Deutsche Telekom Allee 7 + Darmstadt, Hessen 64295 + Germany + + Email: L.Liess@telekom.de + URI: http://www.telekom.de + + + + + + + + + + + + + + + + + + + + + + + + +Winterbottom, et al. Standards Track [Page 16] + -- cgit v1.2.3