idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 513. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 519. 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 Copyright Line does not match the current year == Line 190 has weird spacing: '...ication model...' == Line 191 has weird spacing: '...ference proto...' -- 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 (October 11, 2007) is 6042 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-02 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-05 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-01 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-08 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GeoPriv R. Marshall, Ed. 3 Internet-Draft TCS 4 Intended status: Informational October 11, 2007 5 Expires: April 13, 2008 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 13, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines terminology and provides requirements relating 42 to Location-by-Reference approach to handling location information 43 within signaling and other Internet messaging. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 8 53 5.1. Requirements for a Location Configuration Protocol . . . 8 54 5.2. Requirements for a Location Dereference Protocol . . . . 9 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 57 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 61 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 Intellectual Property and Copyright Statements . . . . . . . . . . 17 65 1. Introduction 67 Location-based services rely on ready access to location information, 68 which can be through a direct or indirect mechanism. While there is 69 already a direct mechanism which exists to provide location as part 70 of the SIP signaling protocol, an alternative mechanism has been 71 developed for handling location indirectly, via a location reference, 72 a reference which points to the actual location information. This 73 reference is called the location URI, and is used by the mechanism we 74 call Location-by-Reference, or LbyR. 76 Each of the actions by which a location URI can be used is 77 represented by specific individual protocol. For example, a Location 78 Configuration Protocol, is used by a device or middlebox to acquire a 79 location which already exists (examples of this protocol include 80 DHCP, LLDP-MED, and HELD [I-D.ietf-geopriv-http-location-delivery]). 81 The location configuration protocol problem statement and 82 requirements document can be found in [I-D.ietf-geopriv-l7-lcp-ps]. 83 The action of conveying a location URI along from node to node 84 according to specific rules in SIP, for example, is known as a 85 conveyance protocol. A location dereferencing protocol, is used by a 86 client to resolve a location URI in exchange for location information 87 from a dereference server (e.g., a LIS). 89 The structure of this document first defines terminology, or points 90 to the appropriate draft where defined, in Section 3. Then a short 91 discussion on the basic elements which show LbyR. This section on 92 actors, Section 4 includes a basic model, and describes the steps 93 which the LbyR mechanism takes. 95 Requirements are outlined separately for location configuration, 96 Section 5.1, followed by those for a dereferencing protocol, 97 Section 5.2. 99 Location-by-Value, called LbyV, in contrast to LbyR, is a direct 100 location conveyance approach and includes the location object, e.g., 101 a PIDF-LO [RFC4119] in the SIP signaling. Location conveyance is out 102 of scope for this document (see [I-D.ietf-sip-location-conveyance] 103 for an explanation of conveyance of location including both LbyR and 104 LbyV scenarios. 106 Location determination, which may include the processes of manual 107 provisioning, automated measurements, or location transformations, 108 (e.g., geo-coding), are beyond the scope of this document. 110 A detailed discussion of Identity information related to the caller, 111 subscriber, or device, as associated to location or location URI, is 112 also out of scope. 114 2. Requirements Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 3. Terminology 122 This document reuses the terminology of [RFC3693], such as Location 123 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 124 Location Generator (LG), Location Object (LO), and Using Protocol: 126 3.1. Terms 128 Location-by-Value (LbyV): The mechanism of representing location 129 either in configuration or conveyance protocols, (i.e., the actual 130 included location value). 132 Location-by-Reference (LbyR): The mechanism of representing location 133 either in configuration, conveyance, or in dereferencing protocols 134 as an identifier which refers to a fully specified location, 135 (i.e., a pointer to the actual location value). 137 Location Configuration Protocol: A protocol which is used by a 138 client to acquire either location or a location URI from a 139 location configuration server, based on information unique to the 140 client. 142 Location Dereference Protocol: A protocol which is used by a client 143 to query a location dereference server, based on location URI 144 input and which returns location information. 146 Location URI: An identifier which serves as a pointer to a location 147 record on a remote host (e.g., LIS). Used within an Location-by- 148 Reference mechanism, a location URI is provided by a location 149 configuration server, and is used as input by a dereference 150 protocol to retrieve location from a dereference server. 152 4. Basic Actors 154 In mobile wireless networks it is not efficient for the end host to 155 periodically query the LIS for up-to-date location information. This 156 is especially the case when power is a constraint or a location 157 update is not immediately needed. Furthermore, the end host might 158 want to delegate the task of retrieving and publishing location 159 information to a third party, such as to a presence server. Finally, 160 in some deployments, the network operator may not want to make 161 location information widely available. 163 These use scenarios motivated the introduction of the LbyR concept. 164 Depending on the type of reference, such as HTTP/HTTPS or SIP 165 Presence URI, different operations can be performed. While an HTTP/ 166 HTTPS URI can be resolved to location information, a SIP Presence URI 167 provides further benefits from the SUBSCRIBE/NOTIFY concept that can 168 additionally be combined with location filters 169 [I-D.ietf-geopriv-loc-filters]. 171 +-----------+ Geopriv +-----------+ 172 | | Location | Location | 173 | LIS +---------------+ Recipient | 174 | | Dereference | | 175 +-----+-----+ Protocol (3) +----+------+ 176 | -- 177 | Geopriv -- 178 | Location -- 179 | Configuration -- 180 | Protocol -- 181 | (1) -- Geopriv 182 | -- Using Protocol 183 | -- (e.g., SIP) 184 +-----+-----+ -- (2) 185 | Target / |-- 186 | End Host + 187 | | 188 +-----------+ 190 Figure 1: Shows the assumed communication model for both a layer 7 191 location configuration protocol and a dereference protocol: 193 Note that there is no requirement for using the same protocol in (1) 194 and (3). 196 The following list describes the location subscription approach: 198 1. The end host discovers the LIS. 200 2. The target (end host) sends a request to the LIS asking for a 201 location URI, as shown in (1) of Figure 1. 203 3. The LIS responds to the request and includes a location object 204 along with a subscription URI. 206 4. The Target puts the subscription URI into a SIP message and 207 forwards it to a Location Recipient via a using protocol, as shown in 208 (2) of Figure 1. The Location Recipient subscribes to the obtained 209 subscription URI (see (3) of Figure 1) and potentially uses a 210 location filter (see [I-D.ietf-geopriv-loc-filters]) to limit the 211 notification rate. 213 5. If the Target moves outside a certain area, indicated by a 214 location filter, the Location Recipient will receive a notification. 216 Note that the Target may also act in the role of the Location 217 Recipient whereby it would subscribe to its own location information. 218 For example, the Target obtains a subscription URI from the Geopriv 219 L7 Location Configuration Protocol. It subscribes to the URI in 220 order to obtain its current location information. A service boundary 221 indicates the bounded extent up to which the device can move without 222 the need to have an updated location, since a re-query with any 223 location within the boundary would result in the same answer returned 224 from a location-based service. 226 For LbyR, the LIS needs to maintain a list of randomized location 227 URIs for each host, timing out each of these URIs after the reference 228 expires. Location URIs need to expire to prevent the recipient of 229 such a URI from being able to (in some cases) permanently track a 230 host. Furthermore, an expiration mechanism also offers garbage 231 collection capability for the LIS. 233 Location URIs must be designed to prevent adversaries from obtaining 234 a known Target's location. There are at least two approaches: The 235 location URI contains a random component which helps obscure 236 sequential updates to location, yet still allows any holder of the 237 location URI to obtain location information. Alternatively, the 238 location URI can remain public and the LIS performs access control 239 via a separate authentication mechanism, such as HTTP digest or TLS 240 client side authentication, when resolving the reference to a 241 location object. 243 5. High-Level Requirements 245 This document outlines only requirements for an LbyR mechanism which 246 is used by two different protocols, a location configuration 247 protocol, and a location dereferencing protocol. Each of these 248 protocols has its own unique client and server interactions, and the 249 requirements here are not intended to state what a client or server 250 is expected to do, but rather which requirements must be met by 251 either the configuration or dereferencing protocol itself. 253 5.1. Requirements for a Location Configuration Protocol 255 Below, we summarize high-level design requirements needed for a 256 location-by-reference mechanism as used within the location 257 configuration protocol. 259 C1. Location URI support: The configuration protocol MUST support a 260 location reference in URI form. 262 Motivation: It is helpful to have a consistent form of key for the 263 LbyR mechanism. 265 C2. Location URI expiration: The lifetime of a location URI SHOULD 266 be indicated. 268 Motivation: Location URIs are not intended to represent a location 269 forever, and the identifier eventually may need to be recycled, or 270 may be subject to a specific window of validity, after which the 271 location reference fails to yield a location, or the location is 272 determined to be kept confidential. 274 C3. Location URI cancellation: The location configuration protocol 275 SHOULD support the ability to request a cancellation of a specific 276 location URI. 278 Motivation: If the client determines that in its best interest to 279 destroy the ability for a location URI to effectively be used to 280 dereference a location, then there should be a way to nullify the 281 location URI. 283 C4. Random Generated: The location URI MUST be hard to guess, i.e., 284 it MUST contain a cryptographically random component. 286 Motivation: There is some benefit to the client if the location 287 URI is generated in an obscured manner so that its sequence, for 288 example in the case of a client's location update, can't be easy 289 guessed. 291 C5. Identity Protection: The location URI MUST NOT contain any 292 information that identifies the user, device or address of record 293 within the URI form. 295 Motivation: It is important to protect caller identity or contact 296 address from being included in the form of the location URI itself 297 when it is generated. 299 C6. Reuse indicator: There SHOULD be a way to allow a client to 300 control whether a location URI can be resolved once or multiple 301 times. 303 Motivation: The client requesting a location URI may request a 304 location URI which has a 'one-time-use' only characteristic, as 305 opposed to a location URI having multiple reuse capability. 307 C7. Location timestamp: There SHOULD be a way to allow a client to 308 determine whether the dereferenced location information refers to 309 the location of the Target at the time when the location URI was 310 created or when it was dereferenced. 312 Motivation: It is important to distinguish between an original and 313 an updated location. 315 5.2. Requirements for a Location Dereference Protocol 317 Below, we summarize high-level design requirements needed for a 318 location-by-reference mechanism as used within the location 319 dereference protocol. 321 D1. Location URI support: The location dereference protocol MUST 322 support a location reference in URI form. 324 Motivation: It is required that there be consistency of use 325 between location URI formats used in an configuration protocol and 326 those used by a dereference protocol. 328 D2. Location URI expiration status: The location dereference 329 protocol MUST support a message indicating that for a location URI 330 which is no longer valid, that the location URI has expired. 332 Motivation: Location URIs are expected to expire, based on 333 location configuration protocol parameters, and it is therefore 334 useful to convey the expired status of the location URI in the 335 location dereference protocol. 337 D3. Authentication: The location dereference protocol MUST support 338 either client-side and server-side authentication. 340 Motivation: It is reasonable to expect implementations of 341 authentication to vary. Some implementations may choose to 342 implement both client-side and server-side authentication, might 343 implement one only, or may implement neither. 345 D4. Dereferenced Location Form: The dereferenced location MUST 346 result in a well-formed PIDF-LO. 348 Motivation: This is in order to ensure that adequate privacy rules 349 can be adhered to, since the PIDF-LO format comprises the 350 necessary structures to maintain location privacy. 352 D5. Repeated use: The location dereference protocol MUST support the 353 ability for the same location URI to be resolved more than once, 354 based on server settings and configuration server parameters. 356 Motivation: According to configuration server parameters, it may 357 be necessary to have a limit on the number of dereferencing 358 attempts. 360 6. Security Considerations 362 The LbyR mechanism currently addresses security issues as follows. 364 A location URI, regardless of its randomized construction, if 365 public, implies no safeguard against anyone being able to 366 dereference and get the location. The randomization of a location 367 URI in its naming does help prevent some potential guessing, 368 according to some defined pattern. In the instance of one-time- 369 use location URIs, which function similarly to a pawn ticket, the 370 argument can be made that with a pawn ticket, possession implies 371 permission, and location URIs which are public are protected only 372 by privacy rules enforced at the dereference server. 374 Additional security issues will be discussed in the geopriv draft, 375 draft-barnes-geopriv-lo-sec-00.txt. 377 7. IANA Considerations 379 This document does not require actions by the IANA. 381 8. Acknowledgements 383 We would like to thank the IETF GEOPRIV working group chairs, Andy 384 Newton, Allison Mankin and Randall Gellens, for creating the design 385 team which initiated this requirements work. We'd also like to thank 386 those design team participants for their inputs, comments, and 387 reviews. The design team included the following folks: Richard 388 Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted Hardie; 389 Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin; Roger 390 Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; 391 John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes 392 Tschofenig; Martin Thomson; and James Winterbottom. 394 9. References 396 9.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 9.2. Informative References 403 [I-D.ietf-geopriv-http-location-delivery] 404 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 405 "HTTP Enabled Location Delivery (HELD)", 406 draft-ietf-geopriv-http-location-delivery-02 (work in 407 progress), September 2007. 409 [I-D.ietf-geopriv-l7-lcp-ps] 410 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 411 Location Configuration Protocol; Problem Statement and 412 Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in 413 progress), September 2007. 415 [I-D.ietf-geopriv-loc-filters] 416 Mahy, R., "A Document Format for Filtering and Reporting 417 Location Notications in the Presence Information Document 418 Format Location Object (PIDF-LO)", 419 draft-ietf-geopriv-loc-filters-01 (work in progress), 420 March 2007. 422 [I-D.ietf-sip-location-conveyance] 423 Polk, J. and B. Rosen, "Location Conveyance for the 424 Session Initiation Protocol", 425 draft-ietf-sip-location-conveyance-08 (work in progress), 426 July 2007. 428 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 429 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 431 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 432 Format", RFC 4119, December 2005. 434 Appendix A. Change log 436 Changes to this draft in comparison to the -00 version: 438 1. Shortened Abstract and Introduction. 440 2. LDP term gone. Expansion of Location Dereferencing Protocol, 441 deletion of "LDP" acronym throughout, since LDP stands for Label 442 Distribution Protocol elsewhere in the IETF. 444 3. LCP term is also gone. LCP is used as Link Control Protocol 445 elsewhere (IETF). 447 4. Reduced the number of terms in the doc. Referenced other drafts 448 or RFCs for repeated terms. 450 5. Requirement C2. changed to indicate that the URI has a lifetime. 452 6. C3. Softened by changing from a MUST to a SHOULD. 454 7. C6. Reworded for clarity. 456 8. C7. Changed the MUST to a SHOULD to reflect a more appropriate 457 level. 459 9. D6. Replaced the text to make it clearer. 461 10. D7. Deleted the requirement since it wasn't an appropriate task 462 for the protocol. 464 11. Referenced Richard's security document 466 12. Cleaned up some text. 468 Author's Address 470 Roger Marshall (editor) 471 TeleCommunication Systems, Inc. 472 2401 Elliott Avenue 473 2nd Floor 474 Seattle, WA 98121 475 US 477 Phone: +1 206 792 2424 478 Email: rmarshall@telecomsys.com 479 URI: http://www.telecomsys.com 481 Full Copyright Statement 483 Copyright (C) The IETF Trust (2007). 485 This document is subject to the rights, licenses and restrictions 486 contained in BCP 78, and except as set forth therein, the authors 487 retain all their rights. 489 This document and the information contained herein are provided on an 490 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 491 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 492 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 493 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 494 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Intellectual Property 499 The IETF takes no position regarding the validity or scope of any 500 Intellectual Property Rights or other rights that might be claimed to 501 pertain to the implementation or use of the technology described in 502 this document or the extent to which any license under such rights 503 might or might not be available; nor does it represent that it has 504 made any independent effort to identify any such rights. Information 505 on the procedures with respect to rights in RFC documents can be 506 found in BCP 78 and BCP 79. 508 Copies of IPR disclosures made to the IETF Secretariat and any 509 assurances of licenses to be made available, or the result of an 510 attempt made to obtain a general license or permission for the use of 511 such proprietary rights by implementers or users of this 512 specification can be obtained from the IETF on-line IPR repository at 513 http://www.ietf.org/ipr. 515 The IETF invites any interested party to bring to its attention any 516 copyrights, patents or patent applications, or other proprietary 517 rights that may cover technology that may be required to implement 518 this standard. Please address the information to the IETF at 519 ietf-ipr@ietf.org. 521 Acknowledgment 523 Funding for the RFC Editor function is provided by the IETF 524 Administrative Support Activity (IASA).