idnits 2.17.1 draft-hardie-ecrit-lost-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 26, 2006) is 6633 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) == Unused Reference: '1' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 388, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 408, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 412, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-03) exists of draft-taylor-ecrit-security-threats-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ecrit-requirements (ref. '5') -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft Qualcomm, Inc. 4 Expires: August 30, 2006 A. Newton 5 Verisign, Inc. 6 H. Schulzrinne 7 Columbia U. 8 H. Tschofenig 9 Siemens 10 February 26, 2006 12 LoST: A Location-to-Service Translation Protocol 13 draft-hardie-ecrit-lost-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 30, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes an XML-based protocol for mapping service 47 identifiers and geospatial or civic location information to service 48 contact URIs. In particular, it can be used to determine the 49 location-appropriate PSAP for emergency services. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Server Discovery . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Service Types . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 7. Deployment Methods . . . . . . . . . . . . . . . . . . . . . 11 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 61 9. Security Considerations . . . . . . . . . . . . . . . . . . 14 62 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 15 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 11.1 Normative References . . . . . . . . . . . . . . . . . . 16 65 11.2 Informative References . . . . . . . . . . . . . . . . . 16 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 67 Intellectual Property and Copyright Statements . . . . . . . 18 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [3]. 75 2. Introduction 77 This document describes a protocol for mapping a service identifier 78 and location information compatible with PIDF-LO [9] to one or more 79 service contact URIs. These URIs may have any reasonable scheme, 80 including sip, xmpp, and tel. While the initial focus is on 81 providing mapping functions for emergency services, it is likely that 82 the protocol is applicable to any service URN. For example, in the 83 United States, the "2-1-1" and "3-1-1" services follow a similar 84 location-to-service behavior as emergency services. 86 This document names this protocol usage "LoST" for Location-to- 87 Service Translation Protocol. The features of LoST are: 89 o Supports queries using civic as well as geospatial location 90 information. 92 o Can be used in both recursive and iterative resolution. 94 o Can be used for civic address validation. 96 o A hierarchical deployment of mapping servers is independent of 97 civic location labels. 99 o Can indicate errors in the location data to facilitate debugging 100 and proper user feedback while simultaneously providing best- 101 effort answers. 103 o Mapping can be based on either civic or geospatial location 104 information, with no performance penalty for either. 106 o Service regions can overlap. 108 o Satisfies the requirements [5] for mapping protocols. 110 o Minimizes round trips by caching individual mappings as well as 111 coverage regions ("hinting"). Unless otherwise desired, there is 112 only one message exchange (roundtrip delay) between the client 113 requesting a mapping and the designated resolver. This also 114 facilitates reuse of TLS or other secure transport association 115 across multiple queries. 117 This document focuses on the description of the protocol between the 118 mapping client (seeker or resolver) and the mapping server (resolver 119 or other servers). The relationship between other functions, such as 120 discovery of mapping servers, data replication and the overall 121 mapping server architecture in general, will be described in a 122 separate document. [10] is a first attempt to describe such a mapping 123 server architecture. 125 3. Usage 127 The client queries a server, indicating the desired service and the 128 location object. If the query succeeds, the server returns a result 129 that includes one or more URIs for reaching the appropriate service 130 for the location indicated. Depending on the query, the result may 131 contain a region where the same mapping would apply, a reference to 132 another server to which the client should send a query, and error 133 messages indicating problems with interpretation of location 134 information. The combination of these components are left to the 135 needs and policy of the jurisdiction where the server is being 136 operated. 138 The interaction between the client and server is triggered by four 139 types of events: 141 1. When the client starts up and/or attaches to a new network 142 location. 144 2. When the client detects that its location has changed 145 sufficiently that it is outside the bounds of the region returned 146 in an earlier query. 148 3. When cached mapping information has expired. 150 4. When calling for a particular service. During such calls, a 151 client MAY request a short response that contains only the 152 mapping data, omitting region information. The use of a 153 different transport protocol is TBD. 155 Cached answers are expected to be used by clients only after failing 156 to accomplish a location-to-URI mapping at call time. Cache entries 157 may expire according to their time-to-live value, or they may become 158 invalid if the location of the caller's device moves outside the 159 boundary limits of the cache entry. Boundaries for cache entries may 160 be set in both geospatial and civic terms. 162 4. Server Discovery 164 There are likely to be a variety of ways that clients can discover 165 appropriate LoST servers, including DHCP, SIP device configuration, 166 or DNS records for their signaling protocol domain, e.g., the AOR 167 domain for SIP. The appropriate server depends on, among other 168 considerations, who operates LoST services, including the Internet 169 Service Provider (ISP), Voice Service Provider (VSP), or the user's 170 home domain. In each case, the host name returned may be resolved 171 using DDDS methods. [Details TBD.] 173 5. Service Types 175 The type of service desired is specified by the element. 176 The emergency identifiers listed in the registry established with [6] 177 will be used in this document. 179 If a more specific service is requested but does not exist, 180 information for the more generic service SHOULD be returned. For 181 example, a request for urn:service:sos.fire might return 182 urn:service:sos in the United States since citizens in that country 183 reach the fire department through the common emergency service. 185 6. Example 187 After performing link layer attachment and end host performs stateful 188 address autoconfiguration (in our example) using DHCP. DHCP provides 189 the end host with civic location information (encoded in UTF-8 190 format): 192 +--------+---------------+ 193 | CAtype | CAvalue | 194 +--------+---------------+ 195 | 0 | US | 196 | 1 | New York | 197 | 3 | New York | 198 | 6 | Broadway | 199 | 22 | Suite 75 | 200 | 24 | 10027-0401 | 201 +--------+---------------+ 203 Figure 1: DHCP Civic Information Example 205 Additionally, DHCP provides information about the LoST server that 206 can be contacted. An additional step of indirection is possible, for 207 example by having DHCP return a domain name that has to be resolved 208 to one or more IP addresses hosting LoST servers. 210 Both at attachment time and call time, the client places a LoST 211 request, including its civic location and the desired service. A 212 snippet of the request that omits encapsulating protocol information 213 and namespace declarations is shown below: 215 216 217 recurse 218 urn:service:sos 219 220 221 US 222 New York 223 New York 224 Broadway 225 123 226 Suite 75 227 10027-0401 228 229 230 231 233 Since the contacted LoST server has the requested information 234 available the following response is returned. The response 235 indicates, as a human readable display string that the 'New York City 236 Police Department' is responsible for the given geographical area. 237 The indicated URI allows the user to start communication using SIP or 238 XMPP. The 'civicMatch' elements indicates which parts of the civic 239 address were matched successfully. Other parts of the address, here, 240 the suite number, were ignored and not validated. The region part of 241 the response indicates that all of New York City would result in the 242 same response. The dialstring element indicates that the service can 243 be reached via the dial string 9-1-1. A snippet of the response is 244 shown below, omitting namespace details and protocol wrappers: 246 247 248 urn:service:sos 249 New York City Police Department 250 sip:nypd@example.com xmpp:nypd@example.com 251 252 253 254 US 255 New York 256 New York 257 Broadway 258 123 259 10027-0401 260 261 262 263 264 265 266 US 267 New York 268 New York 269 270 271 272 911 273 274 276 7. Deployment Methods 278 Because services for emergency contact resolution may differ 279 depending on local or service needs, this document only specifies the 280 "wire format" for LoST services and explicitly leaves open the 281 possibility for many different types of deployment. 283 For instance: 285 During discovery, a client may be directed to issue all queries to 286 an LoST service completely authoritative for a given jursidiction. 288 A client may be directed to issue queries to an LoST server that 289 acts as a reflector. In such a case, the LoST server analyzes the 290 query to determine the best server to wich to refer the client. 292 Or the client may be directed to a server that performs further 293 resolution on behalf of the client. 295 A LoST service may also be represented by multiple LoST servers, 296 either grouped together or at multiple network locations. Using 297 S-NAPTR [11], clients may be given a list of multiple servers to 298 which queries can be sent for a single service. 300 For instance, the service at emergency.example.com may advertise LoST 301 service at local1.emergency.example.com, 302 local2.emergency.example.com, and master.emergency.example.com. Each 303 server may given a different preference. In this case, 'local1' and 304 'local2' may be given a lower preference (more preferred) than 305 'master', which might be a busier server or located further away. 307 +-----------+ pref 10 +-----------+ 308 | |-------------------->+ | 309 | client |------ | local1 | 310 | |--- \ | | 311 +-----------+ \ \ +-----------+ 312 \ \ 313 \ \ +-----------+ 314 \ \ pref 10 | | 315 \ --------->| local2 | 316 \ | | 317 \ +-----------+ 318 \ 319 \ +-----------+ 320 \ pref 20 | | 321 ------------------------->| master | 322 | | 323 +-----------+ 325 8. IANA Considerations 327 TBD, such as namespace registrations. 329 9. Security Considerations 331 There are multiple threats to the overall system of which service 332 mapping forms a part. An attacker that can obtain service contact 333 URIs can use those URIs to attempt to disrupt those services. An 334 attacker that can prevent the lookup of contact URIs can impair the 335 reachability of such services. An attacker that can eavesdrop on the 336 communication requesting this lookup can surmise the existence of an 337 emergency and possibly its nature, and may be able to use this to 338 launch a physical attack on the caller. 340 To avoid that an attacker can modify the query or its result, LoST 341 RECOMMENDS the use of channel security, such as TLS. 343 A more detailed description of threats and security requirements are 344 provided in [4]. 346 [Editor's Note: A future version of this document will describe the 347 countermeasures based on the security requirements outlined in [4].] 349 10. Open Issues 351 A number of open issues have been identified that are not yet 352 addressed by this draft version: 354 o The transport mechanism, such as "plain" HTTP or SOAP. 356 o The appropriate transport protocols beyond TLS/TCP, such as 357 whether UDP is to be supported. 359 o LoST service operators may determine which transfer protocol most 360 meets their needs, and advertise their availability using the DNS 361 DDDS application S-NAPTR [11]. The aspect of service discovery 362 and load balancing needs to be described. 364 o Error conditions and codes. 366 o The inclusion of dial string information. 368 o The name 'LoST' is a placeholder before a better name is found. 370 o An internationalization considerations section is needed. 372 o The XML schema's are not yet provided. 374 o Full-fletched examples are missing. 376 o The security consideration section is incomplete. 378 o The IANA consideration section is missing. 380 11. References 382 11.1 Normative References 384 [1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", 385 W3C XML Schema, October 2000, 386 . 388 [2] World Wide Web Consortium, "XML Schema Part 1: Structures", 389 W3C XML Schema, October 2000, 390 . 392 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 393 Levels", RFC 2119, BCP 14, March 1997. 395 [4] Schulzrinne, H., "Security Threats and Requirements for 396 Emergency Calling", draft-taylor-ecrit-security-threats-01 (work 397 in progress), December 2005. 399 [5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 400 Context Resolution with Internet Technologies", 401 draft-ietf-ecrit-requirements-03 (work in progress), 402 February 2006. 404 [6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", 405 draft-schulzrinne-sipping-service-01 (work in progress), 406 October 2005. 408 [7] Mealling, M., "The IETF XML Registry", 409 draft-mealling-iana-xmlns-registry-03 (work in progress), 410 November 2001. 412 [8] OpenGIS, "Open Geography Markup Language (GML) Implementation 413 Specification", OGC OGC 02-023r4, January 2003. 415 [9] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 416 RFC 4119, December 2005. 418 11.2 Informative References 420 [10] Schulzrinne, H., "Location-to-URL Mapping Architecture and 421 Framework", draft-schulzrinne-ecrit-mapping-arch-00 (work in 422 progress), October 2005. 424 [11] Daigle, L. and A. Newton, "Domain-Based Application Service 425 Location Using SRV RRs and the Dynamic Delegation Discovery 426 Service (DDDS)", RFC 3958, January 2005. 428 Authors' Addresses 430 Ted Hardie 431 Qualcomm, Inc. 433 Andrew Newton 434 Verisign, Inc. 436 Henning Schulzrinne 437 Columbia University 438 Department of Computer Science 439 450 Computer Science Building 440 New York, NY 10027 441 US 443 Phone: +1 212 939 7004 444 Email: hgs+ecrit@cs.columbia.edu 445 URI: http://www.cs.columbia.edu 447 Hannes Tschofenig 448 Siemens 449 Otto-Hahn-Ring 6 450 Munich, Bavaria 81739 451 Germany 453 Email: Hannes.Tschofenig@siemens.com 454 URI: http://www.tschofenig.com 456 Intellectual Property Statement 458 The IETF takes no position regarding the validity or scope of any 459 Intellectual Property Rights or other rights that might be claimed to 460 pertain to the implementation or use of the technology described in 461 this document or the extent to which any license under such rights 462 might or might not be available; nor does it represent that it has 463 made any independent effort to identify any such rights. Information 464 on the procedures with respect to rights in RFC documents can be 465 found in BCP 78 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of an 469 attempt made to obtain a general license or permission for the use of 470 such proprietary rights by implementers or users of this 471 specification can be obtained from the IETF on-line IPR repository at 472 http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights that may cover technology that may be required to implement 477 this standard. Please address the information to the IETF at 478 ietf-ipr@ietf.org. 480 Disclaimer of Validity 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 485 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 486 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 487 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 Copyright Statement 492 Copyright (C) The Internet Society (2006). This document is subject 493 to the rights, licenses and restrictions contained in BCP 78, and 494 except as set forth therein, the authors retain all their rights. 496 Acknowledgment 498 Funding for the RFC Editor function is currently provided by the 499 Internet Society.