idnits 2.17.00 (12 Aug 2021) /tmp/idnits5433/draft-ietf-ecrit-held-routing-03.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 '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 (July 20, 2015) is 2496 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) ** Downref: Normative reference to an Informational RFC: RFC 5687 ** Downref: Normative reference to an Informational RFC: RFC 6443 Summary: 2 errors (**), 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: January 21, 2016 L. Liess 7 Deutsche Telekom 8 July 20, 2015 10 A Routing Request Extension for the HELD Protocol 11 draft-ietf-ecrit-held-routing-03.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 to support this funciton. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 21, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. LoST Reuse Considerations . . . . . . . . . . . . . . . . 6 59 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 7 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 9.1. URN sub-namespace registration for 66 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . 11 67 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 11.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 The general ECRIT calling models described in [RFC6443] and 77 [RFC6881]require a local LoST server or network of forest guides in 78 order to determine the address of the PSAP in the best position to 79 handle a call. Networks of forest guides have not eventuated and 80 while PSAPs are moving towards IP networks, LoST server deployment is 81 not ubiquitous. Some regions and countries have expressed reluctance 82 to deploy LoST servers making aspects of the current ECRIT 83 architecture hard to realize. 85 Evolving architectures in Europe to address regulatory requirements, 86 such as [M493], couple location and routing information in the access 87 network whilst using a softswitch-centric approach to emergency call 88 processing. This document describes adding an extension to the HELD 89 protocol [RFC5985] so that a location information server can provide 90 emergency routing information in the absence of a LoST server or 91 network of forest guides. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. 101 The term "Access Network Provider" is used as defined in [RFC5687] 102 and incompasses both the Internet Access Provider (IAP) and Internet 103 Service Provider (ISP). 105 3. Motivation 107 The Internet emergency calling architecture specified in [RFC6881] 108 describes two main models for emergency call processing. The first 109 is a device-centric model, where a device obtains location 110 information using a location configuration protocol, such a HELD 111 [RFC5985], and then proceeds to determine the address of the next hop 112 closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this 113 model in a simplified form. 115 +---Location Request---+ 116 | (1) | 117 +---+----+ +---V---+ 118 | |<--Location--| LIS | 119 | Caller | (2) +-------+ +--------+ 120 | | | ESRP/ | 121 | |----Find Service-------+ | PSAP | 122 +------^-+ (3) | +--------+ 123 | | +--------V----+ ^ 124 | +-----Service----| LoST Server | | 125 | (4) +-------------+ +---+---+ 126 +-------------Call Initiation------------>| VSP | 127 (5) +-------+ 129 Figure 1: Device-Centric Emergency Services Model 131 The second approach is a softswitch-centric model, where a device 132 initiates an emergency call and the serving softswitch detects that 133 the call is an emergency and initiates retrieving the caller's 134 location from a Location Information Server (LIS) using HELD 135 [RFC5985] with identity extensions [RFC6155] [RFC6915] and then 136 determining the route to the local PSAP using LoST [RFC5222]. 137 Figure 2 shows the high-level protocol interactions. 139 +---Location Request---+ 140 | (2) | 141 +---V---+ | 142 | LIS | | 143 +----+--+ +----+----+ 144 | | | 145 +----Location--->| Soft | 146 +--------+ (3) | Switch | 147 | Caller |------Call Initiation------------> | | 148 +--------+ (1) +-+-^---+-+ 149 +-------------+ | | | 150 | LoST Server |<-Find Service--+ | | 151 +------+------+ (4) | | 152 | | | 153 +----------Service--------+ | 154 (5) | 155 +-----------+ | 156 | ESRP/PSAP |<------Call----+ 157 +-----------+ (6) 159 Figure 2: Softswitch-Centric Calling Model 161 In the softswitch-centric model when a VSP receives an emergency call 162 it performs two tasks. The first task is to determine the correct 163 LIS to ask for location information, this is done using a combination 164 of reverse DNS lookup described in [RFC7216] to acquire the serving 165 domain name and then using [RFC5986] to determine the LIS URI. Once 166 the location is obtained from the LIS, the VSP determines the LoST 167 server associated with the domain serving the caller and queries it 168 for the correct PSAP address. 170 LoST server discovery is a domain based activity, similar to the LIS 171 discovery technique. However, unlike the LIS that is a domain bound 172 service, a LoST server is a geographically bound service. This means 173 that for a domain that spans multiple geographic regions the LoST 174 server determined may not be able to provide a route to the necessary 175 PSAP. When this occurs, the contacted LoST server invokes the help 176 of other LoST servers and this requires the deployment of forest 177 guides. 179 At the time of writing, several countries have expressed a reluctance 180 to deploy public LoST servers. In countries amenable to the use of 181 LoST and forest guides no public forest guides have been deployed. 182 There appears little interest from the public sector in establishing 183 a global forest guide network. These issues pose threats to both the 184 device-centric and the softswitch-centric calling approaches in terms 185 of them operating everywhere. 187 The device-centric and softswitch-centric calling models both involve 188 the notion of a LIS bound to the serving access network. In many 189 cases the LIS already knows the destination PSAP URI for any given 190 location. In [RFC6881] for example, the LIS validates civic 191 locations using a location validation procedure based on the LoST 192 protocol [RFC5222]. The LoST validation request is similar to a LoST 193 routing request and provides the LIS with the same PSAP routing 194 information that a routing request would. In other cases, the LIS 195 knows the correct PSAP for a given location at provisioning time, or 196 the access network might always route to the same emergency provider. 197 Irrespective of the way in which the LIS learns the PSAP URI for a 198 location, the LIS will, in a great many cases, already have this 199 information. 201 This document specifies an extension to the HELD protocol so that 202 emergency routing information can be requested from the LIS at the 203 same time that location information is requested. The document 204 updates [RFC6881] by requiring devices and softswitches that 205 understand this specification to always request routing information 206 to avoid the risk of query failure where no LoST server or forest 207 guide network is deployed. 209 3.1. LoST Reuse Considerations 211 The LoST Protocol [RFC5222] defines a element that 212 describes a service region and associated service URLs. Reusing this 213 element from LoST to provide the routing URIs was considered. 214 However, this would have meant that several of the mandatory 215 components in the element would have had to contain 216 ambiguous or misleading values. Specifically, the "source" attribute 217 is required to contain a LoST application unique string for the 218 authoritative server. However, in the situations described in this 219 specification there may not be an authoritative LoST server, so any 220 value put into this attribute would be misleading. In addition to 221 this, routing information received in the manner described in this 222 specification should not be cached by the receiver, so detailing when 223 the routing information expires or was last updated is irrelevant. 225 4. Mechanism 227 The mechanism consists of adding an element to the HELD 228 locationRequest and an element to the locationResponse. 230 The request element indicates that the requestor wants the LIS to 231 provide routing information based on the location of the end-device. 232 If the routing request is sent with no attribute then URIs for 233 urn:service:sos are returned. If the requestor wants routing 234 information for a specific service then they may include an optional 235 service URN. If a service is specified, and the LIS does not 236 understand the requested service then URIs for urn:service:sos are 237 returned. 239 If the LIS understands the routing request and has routing 240 information for the location then it includes the information in a 241 routingInformation element returned in the locationResponse. How the 242 LIS obtains this information is left to implementation, one possible 243 option is that the LIS acquires it from a LoST server, other 244 possibilities are described in Section 3. 246 A LIS that does not understand the routing request element ignores it 247 and returns location as normal. 249 A LIS that does support the routing request element MUST support 250 returning URIs for urn:service:sos and any regionally defined sub- 251 services while following the URN traversal rules defined in 252 [RFC5031]. 254 A LIS that does understand the routing request element but can't 255 obtain any routing information for the end-device's location MUST 256 only return location information. 258 A LIS that understands the routing request element but not the 259 specified service URN, MUST follow the URN traversal rules defined in 260 [RFC5031]. 262 A LIS that receives a request for emergency routing information that 263 it understands MUST return the correct emergency routing information 264 if it has or is able to acquire the routing information for the 265 location of the target device. 267 The routing information in the location response consists of a 268 service element identified by a service name. The service name is a 269 urn and might contain a general emergency service urn such as 270 urn:service:sos or might contain a specific service urn depending on 271 what was requested and what the LIS is able to provide. A list of 272 one or more service destinations is provided for the service name. 273 Each destination is expressed as a URI and each URI scheme should 274 only appear once in this list. The routing URIs are intended to be 275 used at the time they are received. To avoid any risks of using 276 stale routing URIs the values MUST NOT be cached by the receiving 277 entity. 279 5. HELD Schema Extension 281 This section describes the schema extension to HELD. 283 284 291 292 293 295 296 298 299 300 301 302 304 306 307 309 310 311 313 314 315 316 317 318 319 321 322 323 324 325 327 329 6. Examples 331 Figure 3 illustrates a example that contains IP 332 flow information in the request. 334 337 340 342 343
192.168.1.1
344 1024 345 346 347
10.0.0.1
348 80 349 350 351 353 Figure 3: Example Location Request. 355 Figure 4 illustrates the message containing two 356 location URIs: a HTTPS and a SIP URI. Additionally, the response 357 contains routing information. 359 360 361 362 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 363 364 365 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 366 367 369 371 372 sip:112@example.com 373 sips:112@example.com 374 xmpp:112@example.com 375 376 378 380 Figure 4: Example Location Response 382 7. Privacy Considerations 384 This document makes no changes that require privacy considerations 385 beyond those already described in [RFC5687]. It does however extend 386 those described in [RFC6155]. 388 [RFC5687] describes the issues surrounding Layer 7 location 389 configuration protocols, which this document makes no specific 390 changes to. 392 [RFC6155] extends HELD beyond a simple LCP by enabling authorized 393 third-parties to acquire location information and describes the 394 issues in Section 4. The HELD Routing extension supports returning 395 URIs that represent specific services operating in the Target's 396 vicinity. This represents additional information about the Target, 397 as a consequence it is recommended that this option only be used when 398 a location URI is returned by the LIS. 400 8. Security Considerations 402 This document imposes no additional security considerations beyond 403 those already described in [RFC5687] and [RFC6155]. 405 9. IANA Considerations 407 9.1. URN sub-namespace registration for 408 'urn:ietf:params:xml:ns:geopriv:held:ri' 410 This document calls for IANA to register a new XML namespace, as per 411 the guidelines in [RFC3688]. 413 URI: urn:ietf:params:xml:ns:geopriv:held:ri 415 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 416 James Winterbottom (a.james.winterbottom@gmail.com). 418 XML: 420 BEGIN 421 422 424 425 426 HELD Routing Information Extensions 427 428 429

Additional Element for HELD Routing Information

430

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

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

See RFCXXXX.

434 435 436 END 438 9.2. XML Schema Registration 440 This section registers an XML schema as per the procedures in 441 [RFC3688]. 443 URI: urn:ietf:params:xml:schema:geopriv:held:ri 445 Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), 446 James Winterbottom (a.james.winterbottom@gmail.com). 448 The XML for this schema can be found as the entirety of Section 5 449 of this document. 451 10. Acknowledgements 453 We would like to thank Wilfried Lange for sharing his views with us. 454 We would also like to thank Bruno Chatras for his early review 455 comments and Keith Drage ofr his more detailed review. Thanks to 456 Roger Marshall and Randy Gellens for their helpful suggestions. 458 11. References 460 11.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, 464 DOI 10.17487/RFC2119, March 1997, 465 . 467 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 468 DOI 10.17487/RFC3688, January 2004, 469 . 471 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 472 Emergency and Other Well-Known Services", RFC 5031, 473 DOI 10.17487/RFC5031, January 2008, 474 . 476 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 477 Tschofenig, "LoST: A Location-to-Service Translation 478 Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, 479 . 481 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 482 Location Configuration Protocol: Problem Statement and 483 Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010, 484 . 486 [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", 487 RFC 5985, DOI 10.17487/RFC5985, September 2010, 488 . 490 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 491 "Framework for Emergency Calling Using Internet 492 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 493 2011, . 495 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 496 Communications Services in Support of Emergency Calling", 497 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 498 . 500 11.2. Informative References 502 [M493] European Telecommunications Standards Institute, 503 "Functional architecture to support European requirements 504 on emergency caller location determination and transport", 505 ES 203 178, V 1.0.5, December 2014. 507 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 508 Location Information Server (LIS)", RFC 5986, 509 DOI 10.17487/RFC5986, September 2010, 510 . 512 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 513 Barnes, "Use of Device Identity in HTTP-Enabled Location 514 Delivery (HELD)", RFC 6155, DOI 10.17487/RFC6155, March 515 2011, . 517 [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled 518 Location Delivery (HELD)", RFC 6915, DOI 10.17487/RFC6915, 519 April 2013, . 521 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 522 (LIS) Discovery Using IP Addresses and Reverse DNS", 523 RFC 7216, DOI 10.17487/RFC7216, April 2014, 524 . 526 Authors' Addresses 528 James Winterbottom 529 Winterb Consulting Services 530 Gwynneville, NSW 2500 531 AU 533 Phone: +61 448 266004 534 Email: a.james.winterbottom@gmail.com 536 Hannes Tschofenig 537 Halls in Tirol 6060 538 Austria 540 Email: Hannes.Tschofenig@gmx.net 541 URI: http://www.tschofenig.priv.at 542 Laura Liess 543 Deutsche Telekom Networks 544 Deutsche Telekom Allee 7 545 Darmstadt, Hessen 64295 546 Germany 548 Email: L.Liess@telekom.de 549 URI: http://www.telekom.de