idnits 2.17.1 draft-ietf-ecrit-held-routing-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5985, updated by this document, for RFC5378 checks: 2007-06-08) (Using the creation date from RFC6881, updated by this document, for RFC5378 checks: 2006-10-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 9, 2016) is 2992 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft Winterb Consulting Services 4 Updates: 6881, 5985 (if approved) H. Tschofenig 5 Intended status: Standards Track 6 Expires: August 12, 2016 L. Liess 7 Deutsche Telekom 8 February 9, 2016 10 A Routing Request Extension for the HELD Protocol 11 draft-ietf-ecrit-held-routing-05.txt 13 Abstract 15 For cases where location servers have access to emergency routing 16 information they are able to return routing information with the 17 location information if the location request includes a request for 18 the desired routing information. This document specifies an 19 extension to the HELD protocol that updates RFC5985, to support this 20 funciton. Allowing location and routing information to be acquired 21 in a single request response exchange updates RFC6881, as current 22 location acquisition and route determination procedures are separate 23 operations. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 12, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6 63 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7 65 6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 10.1. URN sub-namespace registration for 71 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13 72 10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 12.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 The general ECRIT calling models described in [RFC6443] and 82 [RFC6881]require a local LoST server or network of forest guides in 83 order to determine the address of the PSAP in the best position to 84 handle a call. Networks of forest guides have not materialized and 85 while PSAPs are moving towards IP networks, LoST server deployment is 86 not ubiquitous. Some regions and countries have expressed reluctance 87 to deploy LoST servers making aspects of the current ECRIT 88 architecture hard to realize. 90 Evolving architectures in Europe to address regulatory requirements, 91 such as [M493], couple location and routing information in the access 92 network whilst using a softswitch-centric approach to emergency call 93 processing. This document describes an extension to the HELD 94 protocol [RFC5985] so that a location information server can provide 95 emergency routing information in the absence of a LoST server or 96 network of forest guides. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 The terms Location Information Server (LIS), Emergency Services 105 Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety 106 Answering Point (PSAP) are used as defined in [RFC6443]. 108 The term "Access Network Provider" is used as defined in [RFC5687] 109 and incompasses both the Internet Access Provider (IAP) and Internet 110 Service Provider (ISP). 112 The term "Forest Guide" is used as defined in [RFC5582]. 114 3. Motivation 116 The Internet emergency calling architecture specified in [RFC6881] 117 describes two main models for emergency call processing. The first 118 is a device-centric model, where a device obtains location 119 information using a location configuration protocol, such as HELD 120 [RFC5985], and then proceeds to determine the address of the next hop 121 closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this 122 model in a simplified form. 124 +---Location Request---+ 125 | (1) | 126 +---+----+ +---V---+ 127 | |<--Location--| LIS | 128 | Caller | (2) +-------+ +--------+ 129 | | | ESRP/ | 130 | |----Find Service-------+ | PSAP | 131 +------^-+ (3) | +--------+ 132 | | +--------V----+ ^ 133 | +-----Service----| LoST Server | | 134 | (4) +-------------+ +---+---+ 135 +-------------Call Initiation------------>| VSP | 136 (5) +-------+ 138 Figure 1: Device-Centric Emergency Services Model 140 The second approach is a softswitch-centric model, where a device 141 initiates an emergency call and the serving softswitch detects that 142 the call is an emergency and initiates retrieving the caller's 143 location from a Location Information Server (LIS) using HELD 144 [RFC5985] with identity extensions [RFC6155] [RFC6915] and then 145 determining the route to the local PSAP using LoST [RFC5222]. 146 Figure 2 shows the high-level protocol interactions. 148 +---Location Request---+ 149 | (2) | 150 +---V---+ | 151 | LIS | | 152 +----+--+ +----+----+ 153 | | | 154 +----Location--->| Soft | 155 +--------+ (3) | Switch | 156 | Caller |------Call Initiation------------> | | 157 +--------+ (1) +-+-^---+-+ 158 +-------------+ | | | 159 | LoST Server |<-Find Service--+ | | 160 +------+------+ (4) | | 161 | | | 162 +----------Service--------+ | 163 (5) | 164 +-----------+ | 165 | ESRP/PSAP |<------Call----+ 166 +-----------+ (6) 168 Figure 2: Softswitch-Centric Calling Model 170 In the softswitch-centric model when a VSP receives an emergency call 171 it performs two tasks. The first task is to determine the correct 172 LIS to ask for location information, this is done using a combination 173 of reverse DNS lookup described in [RFC7216] to acquire the serving 174 domain name and then using [RFC5986] to determine the LIS URI. Once 175 the location is obtained from the LIS, the VSP determines the LoST 176 server associated with the domain serving the caller and queries it 177 for the correct PSAP address. 179 LoST server discovery is a domain based activity, similar to the LIS 180 discovery technique. However, unlike the LIS that is a domain bound 181 service, a LoST server is a geographically bound service. This means 182 that for a domain that spans multiple geographic regions the LoST 183 server determined may not be able to provide a route to the necessary 184 PSAP. When this occurs, the contacted LoST server invokes the help 185 of other LoST servers and this requires the deployment of forest 186 guides. 188 At the time of writing, several countries have expressed a reluctance 189 to deploy public LoST servers. In countries amenable to the use of 190 LoST and forest guides no public forest guides have been deployed. 191 There appears little interest from the public sector in establishing 192 a global forest guide network. These issues pose threats to both the 193 device-centric and the softswitch-centric calling approaches in terms 194 of them operating everywhere. 196 The device-centric and softswitch-centric calling models both involve 197 the notion of a LIS bound to the serving access network. In many 198 cases the LIS already knows the destination PSAP URI for any given 199 location. In [RFC6881] for example, the LIS validates civic 200 locations using a location validation procedure based on the LoST 201 protocol [RFC5222]. The LoST validation request is similar to a LoST 202 routing request and provides the LIS with the same PSAP routing 203 information that a routing request would. In other cases, the LIS 204 knows the correct PSAP for a given location at provisioning time, or 205 the access network might always route to the same emergency provider. 206 Irrespective of the way in which the LIS learns the PSAP URI for a 207 location, the LIS will, in a great many cases, already have this 208 information. 210 This document specifies an extension to the HELD protocol so that 211 emergency routing information can be requested from the LIS at the 212 same time that location information is requested. The document 213 updates [RFC6881] by requiring devices and softswitches that 214 understand this specification to always request routing information 215 to avoid the risk of query failure where no LoST server or forest 216 guide network is deployed. 218 3.1. LoST Reuse Considerations 220 The LoST Protocol [RFC5222] defines a element that 221 describes a service region and associated service URLs. Reusing this 222 element from LoST to provide the routing URIs was considered. 223 However, this would have meant that several of the mandatory 224 components in the element would have had to contain 225 ambiguous or misleading values. Specifically, the "source" attribute 226 is required to contain a LoST application unique string for the 227 authoritative server. However, in the situations described in this 228 specification there may not be an authoritative LoST server, so any 229 value put into this attribute would be misleading. In addition to 230 this, routing information received in the manner described in this 231 specification should not be cached by the receiver, so detailing when 232 the routing information expires or was last updated is irrelevant. 234 4. Mechanism 236 The mechanism consists of adding an element to the HELD 237 locationRequest and an element to the locationResponse. 239 The request element indicates that the requestor wants the LIS to 240 provide routing information based on the location of the end-device. 241 If the routing request is sent with no attribute then URIs for 242 urn:service:sos are returned. If the requestor wants routing 243 information for a specific service then they may include an optional 244 service URN. If a service is specified, and the LIS does not 245 understand the requested service then URIs for urn:service:sos are 246 returned. 248 If the LIS understands the routing request and has routing 249 information for the location then it includes the information in a 250 routingInformation element returned in the locationResponse. How the 251 LIS obtains this information is left to implementation. 252 Possibilities are described in Section 3. 254 A LIS that does not understand the routing request element ignores it 255 and returns location as normal. 257 A LIS that does support the routing request element MUST support 258 returning URIs for urn:service:sos and any regionally defined sub- 259 services while following the URN traversal rules defined in 260 [RFC5031]. 262 A LIS that does understand the routing request element but can't 263 obtain any routing information for the end-device's location MUST set 264 the defaultRoute attribute to true and return a default PSAP or 265 gateway URI along with the determined location information in the 266 locationResponse. 268 A LIS that understands the routing request element but not the 269 specified service URN, MUST follow the URN traversal rules defined in 270 [RFC5031]. 272 A LIS that receives a request for emergency routing information that 273 it understands MUST return the correct emergency routing information 274 if it has or is able to acquire the routing information for the 275 location of the target device. 277 The routing information in the location response consists of a 278 service element identified by a service name. The service name is a 279 URN and might contain a general emergency service URN such as 280 urn:service:sos or might contain a specific service URN depending on 281 what was requested and what the LIS is able to provide. A list of 282 one or more service destinations is provided for the service name. 283 Each destination is expressed as a URI and each URI scheme should 284 only appear once in this list. The routing URIs are intended to be 285 used at the time they are received. To avoid any risks of using 286 stale routing URIs the values MUST NOT be cached by the receiving 287 entity. 289 5. Modification to Phone BCP 291 This section describes the normative updates to Phone BCP [RFC6881]. 293 It is important for devices and intermediaries to take all steps 294 possible to ensure that emergency calls are routed to the correct 295 PSAP. An alternative to providing routing information via global 296 forest guides or local LoST servers is for local networks to 297 configure the PSAP address information in the network location 298 server. This specification updates Phone BCP [RFC6881] to provide 299 this option. The update requires devices and intermediaries using 300 the HELD protocol to always include the HELD routing extension. If 301 the LIS is configured with the routing information it can provide it, 302 if it is not then the device or intermediary tries LoST to acquire 303 the PSAP URI. 305 Section 6.5 of [RFC6881] defines "End System Location Configuration". 306 Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the 307 LCP such that "the request MUST include the requestRoutingInformation 308 element". The remainder of the requirement remains unchanged. 310 This document adds a new requirement to Section 7 of [RFC6881]. 312 "ED-51a : Endpoints MUST support the HELD requestRoutingInformation 313 element and be able and be able to interpret and use any routing 314 information returned in the locationResponse." 316 This document adds two new requirements to Section 8 of [RFC6881]. 318 "ED-52a : Endpoints that acquire routing information in a HELD 319 locationResponse SHOULD use this routing information but MAY perform 320 a LoST findService request if they have a location value." 322 "ED-52b : Endpoints that acquire routing information in a HELD 323 locationResponse with a defaultRoute attribute of true MUST perform a 324 LoST findService request if they have a location value. If a route 325 is provided by the LoST server then this route MUST be used, 326 otherwise the routing information provided in the HELD response 327 SHOULD be used." 329 This document amends SP-26 from Section 8 of [RFC6881] such that a 330 LoST mapping need not be requested if non-default routing information 331 is provided in the HELD locationResponse. 333 6. HELD Schema Extension 335 This section describes the schema extension to HELD. 337 338 345 346 347 349 350 352 353 354 355 356 358 361 362 364 366 367 368 369 371 373 374 375 376 377 378 380 381 382 383 384 386 388 7. Examples 390 Figure 3 illustrates a example that contains IP 391 flow information in the request. 393 396 399 401 402
192.0.2.12
403 1024 404 405 406
192.0.2.195
407 80 408 409 410 412 Figure 3: Example Location Request. 414 Figure 4 illustrates the message containing two 415 location URIs: a HTTPS and a SIP URI. Additionally, the response 416 contains routing information. 418 419 420 421 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 422 423 424 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 425 426 428 430 431 sip:112@example.com 432 sips:112@example.com 433 xmpp:112@example.com 434 435 437 439 Figure 4: Example Location Response 441 Figure 5 illustrates the message containing 442 default routing information and an HTTPS location URI. 444 445 446 447 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 448 449 451 453 454 sip:112@example.com 455 sips:112@example.com 456 xmpp:112@example.com 457 458 460 462 Figure 5: Example Location Response with default routing information 464 8. Privacy Considerations 466 This document makes no changes that require privacy considerations 467 beyond those already described in [RFC5985]. It does however extend 468 those described in [RFC6155]. 470 [RFC5985] describes the privacy considerations surrounding the HELD 471 location configuration protocol, and this document makes no specific 472 changes to these considerations. 474 [RFC6155] extends HELD beyond a simple location configuration 475 protocol (LCP) by enabling authorized third-parties to acquire 476 location information and describes the issues in Section 4. The HELD 477 Routing extension supports returning URIs that represent specific 478 services operating in the Target's vicinity. This represents 479 additional information about the Target, as a consequence it is 480 recommended that this option only be used when the LIS returns a 481 location URI, not a location value. 483 9. Security Considerations 485 This document imposes no additional security considerations beyond 486 those already described in [RFC5985] and [RFC6155]. 488 10. IANA Considerations 490 10.1. URN sub-namespace registration for 491 'urn:ietf:params:xml:ns:geopriv:held:ri' 493 This document calls for IANA to register a new XML namespace, as per 494 the guidelines in [RFC3688]. 496 URI: urn:ietf:params:xml:ns:geopriv:held:ri 498 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 499 James Winterbottom (a.james.winterbottom@gmail.com). 501 XML: 503 BEGIN 504 505 507 508 509 HELD Routing Information Extensions 510 511 512

Additional Element for HELD Routing Information

513

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

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

See RFCXXXX.

517 518 519 END 521 10.2. XML Schema Registration 523 This section registers an XML schema as per the procedures in 524 [RFC3688]. 526 URI: urn:ietf:params:xml:schema:geopriv:held:ri 528 Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), 529 James Winterbottom (a.james.winterbottom@gmail.com). 531 The XML for this schema can be found as the entirety of Section 6 532 of this document. 534 11. Acknowledgements 536 We would like to thank Wilfried Lange for sharing his views with us. 537 We would also like to thank Bruno Chatras for his early review 538 comments and Keith Drage for his more detailed review. Thanks to 539 Roger Marshall and Randy Gellens for their helpful suggestions. 541 12. References 543 12.1. Normative References 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, 547 DOI 10.17487/RFC2119, March 1997, 548 . 550 [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", 551 RFC 5985, DOI 10.17487/RFC5985, September 2010, 552 . 554 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 555 Communications Services in Support of Emergency Calling", 556 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 557 . 559 12.2. Informative References 561 [M493] European Telecommunications Standards Institute, 562 "Functional architecture to support European requirements 563 on emergency caller location determination and transport", 564 ES 203 178, V 1.0.5, December 2014. 566 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 567 DOI 10.17487/RFC3688, January 2004, 568 . 570 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 571 Emergency and Other Well-Known Services", RFC 5031, 572 DOI 10.17487/RFC5031, January 2008, 573 . 575 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 576 Tschofenig, "LoST: A Location-to-Service Translation 577 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 578 . 580 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 581 Framework", RFC 5582, DOI 10.17487/RFC5582, September 582 2009, . 584 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 585 Location Configuration Protocol: Problem Statement and 586 Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010, 587 . 589 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 590 Location Information Server (LIS)", RFC 5986, 591 DOI 10.17487/RFC5986, September 2010, 592 . 594 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 595 Barnes, "Use of Device Identity in HTTP-Enabled Location 596 Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March 597 2011, . 599 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 600 "Framework for Emergency Calling Using Internet 601 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 602 2011, . 604 [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled 605 Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915, 606 April 2013, . 608 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 609 (LIS) Discovery Using IP Addresses and Reverse DNS", 610 RFC 7216, DOI 10.17487/RFC7216, April 2014, 611 . 613 Authors' Addresses 615 James Winterbottom 616 Winterb Consulting Services 617 Gwynneville, NSW 2500 618 AU 620 Phone: +61 448 266004 621 Email: a.james.winterbottom@gmail.com 622 Hannes Tschofenig 623 Halls in Tirol 6060 624 Austria 626 Email: Hannes.Tschofenig@gmx.net 627 URI: http://www.tschofenig.priv.at 629 Laura Liess 630 Deutsche Telekom Networks 631 Deutsche Telekom Allee 7 632 Darmstadt, Hessen 64295 633 Germany 635 Email: L.Liess@telekom.de 636 URI: http://www.telekom.de