idnits 2.17.1 draft-ietf-ecrit-held-routing-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5985]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2015) is 3061 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: RFC6881, RFC5985 (if approved) H. Tschofenig 5 Intended status: Standards Track 6 Expires: June 11, 2016 L. Liess 7 Deutsche Telekom 8 December 9, 2015 10 A Routing Request Extension for the HELD Protocol 11 draft-ietf-ecrit-held-routing-04.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, updating [RFC5985], to support this 20 funciton. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 11, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6 60 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Modification to Phone BCP . . . . . . . . . . . . . . . . . . 7 62 6. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 63 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 10.1. URN sub-namespace registration for 68 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 13 69 10.2. XML Schema Registration . . . . . . . . . . . . . . . . 13 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 12.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 The general ECRIT calling models described in [RFC6443] and 79 [RFC6881]require a local LoST server or network of forest guides in 80 order to determine the address of the PSAP in the best position to 81 handle a call. Networks of forest guides have not materialized and 82 while PSAPs are moving towards IP networks, LoST server deployment is 83 not ubiquitous. Some regions and countries have expressed reluctance 84 to deploy LoST servers making aspects of the current ECRIT 85 architecture hard to realize. 87 Evolving architectures in Europe to address regulatory requirements, 88 such as [M493], couple location and routing information in the access 89 network whilst using a softswitch-centric approach to emergency call 90 processing. This document describes an extension to the HELD 91 protocol [RFC5985] so that a location information server can provide 92 emergency routing information in the absence of a LoST server or 93 network of forest guides. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 The terms Location Information Server (LIS), Emergency Services 102 Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety 103 Answering Point (PSAP) are used as defined in [RFC6443]. 105 The term "Access Network Provider" is used as defined in [RFC5687] 106 and incompasses both the Internet Access Provider (IAP) and Internet 107 Service Provider (ISP). 109 3. Motivation 111 The Internet emergency calling architecture specified in [RFC6881] 112 describes two main models for emergency call processing. The first 113 is a device-centric model, where a device obtains location 114 information using a location configuration protocol, such as HELD 115 [RFC5985], and then proceeds to determine the address of the next hop 116 closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this 117 model in a simplified form. 119 +---Location Request---+ 120 | (1) | 121 +---+----+ +---V---+ 122 | |<--Location--| LIS | 123 | Caller | (2) +-------+ +--------+ 124 | | | ESRP/ | 125 | |----Find Service-------+ | PSAP | 126 +------^-+ (3) | +--------+ 127 | | +--------V----+ ^ 128 | +-----Service----| LoST Server | | 129 | (4) +-------------+ +---+---+ 130 +-------------Call Initiation------------>| VSP | 131 (5) +-------+ 133 Figure 1: Device-Centric Emergency Services Model 135 The second approach is a softswitch-centric model, where a device 136 initiates an emergency call and the serving softswitch detects that 137 the call is an emergency and initiates retrieving the caller's 138 location from a Location Information Server (LIS) using HELD 139 [RFC5985] with identity extensions [RFC6155] [RFC6915] and then 140 determining the route to the local PSAP using LoST [RFC5222]. 141 Figure 2 shows the high-level protocol interactions. 143 +---Location Request---+ 144 | (2) | 145 +---V---+ | 146 | LIS | | 147 +----+--+ +----+----+ 148 | | | 149 +----Location--->| Soft | 150 +--------+ (3) | Switch | 151 | Caller |------Call Initiation------------> | | 152 +--------+ (1) +-+-^---+-+ 153 +-------------+ | | | 154 | LoST Server |<-Find Service--+ | | 155 +------+------+ (4) | | 156 | | | 157 +----------Service--------+ | 158 (5) | 159 +-----------+ | 160 | ESRP/PSAP |<------Call----+ 161 +-----------+ (6) 163 Figure 2: Softswitch-Centric Calling Model 165 In the softswitch-centric model when a VSP receives an emergency call 166 it performs two tasks. The first task is to determine the correct 167 LIS to ask for location information, this is done using a combination 168 of reverse DNS lookup described in [RFC7216] to acquire the serving 169 domain name and then using [RFC5986] to determine the LIS URI. Once 170 the location is obtained from the LIS, the VSP determines the LoST 171 server associated with the domain serving the caller and queries it 172 for the correct PSAP address. 174 LoST server discovery is a domain based activity, similar to the LIS 175 discovery technique. However, unlike the LIS that is a domain bound 176 service, a LoST server is a geographically bound service. This means 177 that for a domain that spans multiple geographic regions the LoST 178 server determined may not be able to provide a route to the necessary 179 PSAP. When this occurs, the contacted LoST server invokes the help 180 of other LoST servers and this requires the deployment of forest 181 guides. 183 At the time of writing, several countries have expressed a reluctance 184 to deploy public LoST servers. In countries amenable to the use of 185 LoST and forest guides no public forest guides have been deployed. 186 There appears little interest from the public sector in establishing 187 a global forest guide network. These issues pose threats to both the 188 device-centric and the softswitch-centric calling approaches in terms 189 of them operating everywhere. 191 The device-centric and softswitch-centric calling models both involve 192 the notion of a LIS bound to the serving access network. In many 193 cases the LIS already knows the destination PSAP URI for any given 194 location. In [RFC6881] for example, the LIS validates civic 195 locations using a location validation procedure based on the LoST 196 protocol [RFC5222]. The LoST validation request is similar to a LoST 197 routing request and provides the LIS with the same PSAP routing 198 information that a routing request would. In other cases, the LIS 199 knows the correct PSAP for a given location at provisioning time, or 200 the access network might always route to the same emergency provider. 201 Irrespective of the way in which the LIS learns the PSAP URI for a 202 location, the LIS will, in a great many cases, already have this 203 information. 205 This document specifies an extension to the HELD protocol so that 206 emergency routing information can be requested from the LIS at the 207 same time that location information is requested. The document 208 updates [RFC6881] by requiring devices and softswitches that 209 understand this specification to always request routing information 210 to avoid the risk of query failure where no LoST server or forest 211 guide network is deployed. 213 3.1. LoST Reuse Considerations 215 The LoST Protocol [RFC5222] defines a element that 216 describes a service region and associated service URLs. Reusing this 217 element from LoST to provide the routing URIs was considered. 218 However, this would have meant that several of the mandatory 219 components in the element would have had to contain 220 ambiguous or misleading values. Specifically, the "source" attribute 221 is required to contain a LoST application unique string for the 222 authoritative server. However, in the situations described in this 223 specification there may not be an authoritative LoST server, so any 224 value put into this attribute would be misleading. In addition to 225 this, routing information received in the manner described in this 226 specification should not be cached by the receiver, so detailing when 227 the routing information expires or was last updated is irrelevant. 229 4. Mechanism 231 The mechanism consists of adding an element to the HELD 232 locationRequest and an element to the locationResponse. 234 The request element indicates that the requestor wants the LIS to 235 provide routing information based on the location of the end-device. 236 If the routing request is sent with no attribute then URIs for 237 urn:service:sos are returned. If the requestor wants routing 238 information for a specific service then they may include an optional 239 service URN. If a service is specified, and the LIS does not 240 understand the requested service then URIs for urn:service:sos are 241 returned. 243 If the LIS understands the routing request and has routing 244 information for the location then it includes the information in a 245 routingInformation element returned in the locationResponse. How the 246 LIS obtains this information is left to implementation. 247 Possibilities are described in Section 3. 249 A LIS that does not understand the routing request element ignores it 250 and returns location as normal. 252 A LIS that does support the routing request element MUST support 253 returning URIs for urn:service:sos and any regionally defined sub- 254 services while following the URN traversal rules defined in 255 [RFC5031]. 257 A LIS that does understand the routing request element but can't 258 obtain any routing information for the end-device's location MUST set 259 the defaultRoute attribute to true and return a default PSAP or 260 gateway URI along with the determined location information in the 261 locationResponse. 263 A LIS that understands the routing request element but not the 264 specified service URN, MUST follow the URN traversal rules defined in 265 [RFC5031]. 267 A LIS that receives a request for emergency routing information that 268 it understands MUST return the correct emergency routing information 269 if it has or is able to acquire the routing information for the 270 location of the target device. 272 The routing information in the location response consists of a 273 service element identified by a service name. The service name is a 274 urn and might contain a general emergency service urn such as 275 urn:service:sos or might contain a specific service urn depending on 276 what was requested and what the LIS is able to provide. A list of 277 one or more service destinations is provided for the service name. 278 Each destination is expressed as a URI and each URI scheme should 279 only appear once in this list. The routing URIs are intended to be 280 used at the time they are received. To avoid any risks of using 281 stale routing URIs the values MUST NOT be cached by the receiving 282 entity. 284 5. Modification to Phone BCP 286 This section describes the normative updates to Phone BCP [RFC6881]. 288 It is important for devices and intermediaries to take all steps 289 possible to ensure that emergency calls are routed to the correct 290 PSAPS. In absence of global forest guides or local LoST servers and 291 the possibility that the local network may be configured with PSAP 292 address information, this specification updates Phone BCP [RFC6881]. 293 The update requires devices and intermediaries using the HELD 294 protocol to always include the HELD routing extension. If the LIS is 295 configured with the routing information it can provide it, if it is 296 not then the device or intermediary tries LoST to acquire the PSAP 297 URI. 299 Section 6.5 of [RFC6881] defines "End System Location Configuration". 300 Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the 301 LCP such that "the request MUST include the requestRoutingInformation 302 element". The remainder of the requirement remains unchanged. 304 This document adds a new requirement to section 7 of [RFC6881]. 306 "ED-51a : Endpoints MUST support the HELD requestRoutingInformation 307 element and be able and be able to interpret and use any routing 308 information returned in the locationResponse." 310 This document adds two new requirements to section 8 of [RFC6881]. 312 "ED-52a : Endpoints that acquire routing information in a HELD 313 locationResponse SHOULD use this routing information but MAY perform 314 a LoST findService request if they have a location value." 316 "ED-52b : Endpoints that acquire routing information in a HELD 317 locationResponse with a defaultRoute attribute of true MUST perform a 318 LoST findService request if they have a location value. If a route 319 is provided by the LoST server then this route MUST be used, 320 otherwise the routing information provided in the HELD response 321 SHOULD be used." 323 This document amends SP-26 from Section 8 of [RFC6881] such that a 324 LoST mapping need not be requested if non-default routing information 325 is provided in the HELD locationResponse. 327 6. HELD Schema Extension 329 This section describes the schema extension to HELD. 331 332 339 340 341 343 344 346 347 348 349 350 352 354 355 357 359 360 361 362 364 365 366 367 368 369 370 372 373 374 375 376 378 380 7. Examples 382 Figure 3 illustrates a example that contains IP 383 flow information in the request. 385 388 391 393 394
192.168.1.1
395 1024 396 397 398
10.0.0.1
399 80 400 401 402 404 Figure 3: Example Location Request. 406 Figure 4 illustrates the message containing two 407 location URIs: a HTTPS and a SIP URI. Additionally, the response 408 contains routing information. 410 411 412 413 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 414 415 416 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 417 418 420 422 423 sip:112@example.com 424 sips:112@example.com 425 xmpp:112@example.com 426 427 429 431 Figure 4: Example Location Response 433 Figure 5 illustrates the message containing 434 default routing information and an HTTPS location URI. 436 437 438 439 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 440 441 443 445 446 sip:112@example.com 447 sips:112@example.com 448 xmpp:112@example.com 449 450 452 454 Figure 5: Example Location Response with default routing information 456 8. Privacy Considerations 458 This document makes no changes that require privacy considerations 459 beyond those already described in [RFC5687]. It does however extend 460 those described in [RFC6155]. 462 [RFC5687] describes the issues surrounding Layer 7 location 463 configuration protocols, which this document makes no specific 464 changes to. 466 [RFC6155] extends HELD beyond a simple location configuration 467 protocol (LCP) by enabling authorized third-parties to acquire 468 location information and describes the issues in Section 4. The HELD 469 Routing extension supports returning URIs that represent specific 470 services operating in the Target's vicinity. This represents 471 additional information about the Target, as a consequence it is 472 recommended that this option only be used when the LIS returns a 473 location URI, not a location value. 475 9. Security Considerations 477 This document imposes no additional security considerations beyond 478 those already described in [RFC5687] and [RFC6155]. 480 10. IANA Considerations 482 10.1. URN sub-namespace registration for 483 'urn:ietf:params:xml:ns:geopriv:held:ri' 485 This document calls for IANA to register a new XML namespace, as per 486 the guidelines in [RFC3688]. 488 URI: urn:ietf:params:xml:ns:geopriv:held:ri 490 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 491 James Winterbottom (a.james.winterbottom@gmail.com). 493 XML: 495 BEGIN 496 497 499 500 501 HELD Routing Information Extensions 502 503 504

Additional Element for HELD Routing Information

505

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

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

See RFCXXXX.

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