idnits 2.17.1 draft-winterbottom-ecrit-priv-loc-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 '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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 29, 2014) is 3613 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 (~~), 3 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 (if approved) H. Tschofenig 5 Intended status: Standards Track 6 Expires: November 30, 2014 L. Liess 7 Deutsche Telekom 8 May 29, 2014 10 A Routing Request Extension for the HELD Protocol 11 draft-winterbottom-ecrit-priv-loc-04.txt 13 Abstract 15 In many circumstances public LoST servers or a distributed network of 16 forest guides linking public LoST servers is not available. In such 17 environments the general ECRIT calling models breakdown. However, 18 location servers operating in these areas are often privy to the 19 necessary information to reach emergency and other services. This 20 document describes a solution where by the routing information may be 21 obtained from a location server using a simple extension to the HELD 22 protocol. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 30, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. HELD Schema Extension . . . . . . . . . . . . . . . . . . . . 8 63 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 9.1. URN sub-namespace registration for 68 'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . . . 11 69 9.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 In many circumstances public LoST [RFC5222] servers or a distributed 79 network of forest guides linking public LoST servers is not 80 available. In such environments the general ECRIT calling models 81 breakdown. Location servers operating in these areas are often privy 82 to the necessary information to reach emergency and other services. 83 This document describes how adding an extension to the HELD protocol 84 [RFC5985] can used to extract this information for a location 85 information server in the absence of a LoST server or network of 86 forest guides. 88 2. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. 96 The term "Access Network Provider" is used as defined in [RFC5687] 97 and incompasses both the Internet Access Provider (IAP) and Internet 98 Service Provider (ISP). 100 3. Motivation 102 The Internet emergency calling architecture specified in [RFC6881] 103 describes two main models for emergency call processing. The first 104 is a device-centric model, where a device obtains location 105 information using a location configuration protocol, such a HELD 106 [RFC5985], and then proceeds to determine the address of the next hop 107 closer to the local PSAP using LoST [RFC5222]. Figure 1 shows this 108 model in a simplified form. 110 +---Location Request---+ 111 | (1) | 112 +---+----+ +---V---+ 113 | |<--Location--| LIS | 114 | Caller | (2) +-------+ +--------+ 115 | | | ESRP/ | 116 | |----Find Service-------+ | PSAP | 117 +------^-+ (3) | +--------+ 118 | | +--------V----+ ^ 119 | +-----Service----| LoST Server | | 120 | (4) +-------------+ +---+---+ 121 +-------------Call Initiation------------>| VSP | 122 (5) +-------+ 124 Figure 1: Device-Centric Emergency Services Model 126 The second approach is a softswitch-centric model, where a device 127 initiates and emergency call and the serving softswitch detects that 128 the call is an emergency and initiates retrieving the caller's 129 location from a Location Information Server (LIS) using HELD 130 [RFC5985] with identity extensions [RFC6155] [RFC6915] and then 131 determining the route to the local PSAP using LoST [RFC5222]. 132 Figure 2 shows the high-level protocol interactions. 134 +---Location Request---+ 135 | (2) | 136 +---V---+ | 137 | LIS | | 138 +----+--+ +----+----+ 139 | | | 140 +----Location--->| Soft | 141 +--------+ (3) | Switch | 142 | Caller |------Call Initiation------------> | | 143 +--------+ (1) +-+-^---+-+ 144 +-------------+ | | | 145 | LoST Server |<-Find Service--+ | | 146 +------+------+ (4) | | 147 | | | 148 +----------Service--------+ | 149 (5) | 150 +-----------+ | 151 | ESRP/PSAP |<------Call----+ 152 +-----------+ (6) 154 Figure 2: Softswitch-Centric Calling Model 156 In the softswitch-centric model when a VSP receives an emergency call 157 it performs two tasks. The first task is to determine the correct 158 LIS to ask for location information, this is done using a combination 159 of reverse DNS lookup described in [RFC7216] to acquire the serving 160 domain name and then using [RFC5986] to determine the LIS URI. Once 161 the location is obtained from the LIS, the VSP determines the LoST 162 server associated with the domain serving the caller and queries it 163 for the correct PSAP address. 165 LoST server discovery is a domain based activity, similar to the LIS 166 discovery technique. However, unlike the LIS that is a domain bound 167 service, a LoST server is a geographically bound service. This means 168 that for a domain that spans multiple geographic regions the LoST 169 server determined may not be able to provide a route to the necessary 170 PSAP. When this occurs, the contacted LoST server invokes the help 171 of other LoST servers and this requires the deployment of forest 172 guides. 174 At the time of writing, several countries have expressed their 175 reluctance to deploy public LoST servers. In countries amenable to 176 use of LoST and forest guides no public forest guides have been 177 deployed. There appears little interest from the public sector in 178 establishing a global forest guide network. These issues pose 179 threats to both the device-centric and the softswitch-centric calling 180 approaches in terms of them operating everywhere. 182 The device-centric and softswitch-centric calling models both involve 183 the notion of a LIS bound to the serving access network. In many 184 cases the LIS already knows the destination PSAP address for any 185 given location. In [RFC6881] for example, the LIS validates all 186 civic locations using a location validation procedure. This 187 procedure is the same as a routing request and so the LIS has the 188 resulting the PSAP routing information. In other cases, the LIS 189 knows the correct PSAP for a given location at provisioning time, or 190 the access network might always route to the same emergency provider. 191 Irrespective of the way in which the LIS learns the PSAP address for 192 a location, the LIS will, in a great many cases, have this 193 information. 195 This document specifies an extension to the HELD protocol so that 196 emergency routing information can be requested from the LIS at the 197 same time that location information is requested. The document 198 updates [RFC6881] by requiring devices and softswitches that 199 understand this specification to always request routing information 200 to avoid the risk of query failure where no LoST server or forest 201 guide network is deployed. 203 4. Mechanism 205 The mechanism consists of adding an element to the HELD 206 locationRequest and an element to the locationResponse. The request 207 element indicates that the requestor wants the LIS to provide routing 208 information for the location where the device is. If the LIS 209 understands the routing request and has routing information 210 accessible it provides the information in a routingInformation 211 element included in the locationResponse. How the LIS obtains this 212 information is left to implementation, one possible option is that 213 the LIS acquires it from a LoST server, other possibilities are 214 described in Section 3. 216 A LIS that does not understand the routing request element ignores it 217 and returns location as normal. 219 A LIS that does understand the routing request element but can't 220 obtain routing information returns location as normal. 222 The routing information in the location response consists of one or 223 more service elements which is identified by a service name. The 224 service name is a URI and might contain a general emergency service 225 urn such as urn:service:sos or might contain a specific service urn. 226 For each service name a list of one or more service destinations is 227 provided. Each destination is expressed as a URI and each URI scheme 228 should only appear once in this list. The routing information is 229 intended to be used at the time it is received. To avoid any risks 230 of using stale routing information the value should not be cached by 231 the receiving entity. 233 Reusing the mapping element from the LoST findServiceResponse message 234 to provide the routing information was considered. However, this 235 would have meant that several of the mandatory components in the 236 mapping element would have had to contain ambiguous or misleading 237 values. Specifically, the "source" attribute is required to contain 238 a LoST application unique string for the authoritative server. 239 However, in the situations described in this specification there may 240 not be an authoritative LoST server, so any value put into this 241 attribute would be misleading. In addition to this, routing 242 information received in the manner described in this specification 243 should not be cached by the receiver, so detailing when the routing 244 information expires or was last updated is irrelevant. 246 5. HELD Schema Extension 248 This section describes the schema extension to HELD. 250 251 258 259 260 262 263 264 265 266 268 269 271 272 273 275 276 277 278 279 280 282 284 285 286 287 288 290 292 6. Examples 294 Figure 3 illustrates a example that contains IP 295 flow information in the request. 297 300 303 305 306
192.168.1.1
307 1024 308 309 310
10.0.0.1
311 80 312 313 314 316 Figure 3: Example Location Request. 318 Figure 4 illustrates the message containing two 319 location URIs: a HTTPS and a SIP URI. Additionally, the response 320 contains routing information. 322 323 324 325 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 326 327 328 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 329 330 332 334 335 sip:nypd@example.com 336 sips:nypd@example.com 337 xmpp:nypd@example.com 338 340 341 sip:fd@ny.example.com 342 sips:fd@ny.example.com 343 xmpp:fd@ny.example.com 344 345 347 349 Figure 4: Example Location Response 351 7. Privacy Considerations 353 This document makes no changes that require privacy considerations 354 beyond those already described in [RFC5985] and [RFC6155]. 356 8. Security Considerations 358 This document imposes no additional security considerations beyond 359 those already described in [RFC5985] and [RFC6155]. 361 9. IANA Considerations 363 9.1. URN sub-namespace registration for 364 'urn:ietf:params:xml:ns:geopriv:held:ri' 366 This document calls for IANA to register a new XML namespace, as per 367 the guidelines in [RFC3688]. 369 URI: urn:ietf:params:xml:ns:geopriv:held:ri 371 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 372 James Winterbottom (a.james.winterbottom@gmail.com). 374 XML: 376 BEGIN 377 378 380 381 382 HELD Routing Information Extensions 383 384 385

Additional Element for HELD Routing Information

386

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

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

See RFCXXXX.

390 391 392 END 394 9.2. XML Schema Registration 396 This section registers an XML schema as per the procedures in 397 [RFC3688]. 399 URI: urn:ietf:params:xml:schema:geopriv:held:ri 401 Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), 402 James Winterbottom (a.james.winterbottom@gmail.com). 404 The XML for this schema can be found as the entirety of Section 5 405 of this document. 407 10. Acknowledgements 409 We would like to thank Wilfried Lange for sharing his views with us. 410 We would also like to thank Bruno Chatras for his early review 411 comments and Bernd Henschel for his support. 413 11. References 415 11.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 421 January 2004. 423 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 424 Tschofenig, "LoST: A Location-to-Service Translation 425 Protocol", RFC 5222, August 2008. 427 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 428 Location Configuration Protocol: Problem Statement and 429 Requirements", RFC 5687, March 2010. 431 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 432 RFC 5985, September 2010. 434 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 435 "Framework for Emergency Calling Using Internet 436 Multimedia", RFC 6443, December 2011. 438 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 439 Communications Services in Support of Emergency Calling", 440 BCP 181, RFC 6881, March 2013. 442 11.2. Informative References 444 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 445 Location Information Server (LIS)", RFC 5986, 446 September 2010. 448 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 449 Barnes, "Use of Device Identity in HTTP-Enabled Location 450 Delivery (HELD)", RFC 6155, March 2011. 452 [RFC6915] Bellis, R., "Flow Identity Extension for HTTP-Enabled 453 Location Delivery (HELD)", RFC 6915, April 2013. 455 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 456 (LIS) Discovery Using IP Addresses and Reverse DNS", 457 RFC 7216, April 2014. 459 Authors' Addresses 461 James Winterbottom 462 Winterb Consulting Services 463 Gwynneville, NSW 2500 464 AU 466 Phone: +61 448 266004 467 Email: a.james.winterbottom@gmail.com 469 Hannes Tschofenig 470 Halls in Tirol 6060 471 Austria 473 Phone: 474 Email: Hannes.Tschofenig@gmx.net 475 URI: http://www.tschofenig.priv.at 477 Laura Liess 478 Deutsche Telekom Networks 479 Deutsche Telekom Allee 7 480 Darmstadt, Hessen 64295 481 Germany 483 Phone: 484 Email: L.Liess@telekom.de 485 URI: http://www.telekom.de