idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-19.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (Feb 25, 2013) is 4076 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk 3 Internet-Draft Cisco Systems 4 Intended status: Proposed Standard Feb 25, 2013 5 Expires: Aug 25, 2013 7 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 8 Option for a Location Uniform Resource Identifier (URI) 9 draft-ietf-geopriv-dhcp-lbyr-uri-option-19 11 Abstract 13 This document creates a Dynamic Host Configuration Protocol (DHCP) 14 Option for transmitting a client's geolocation Uniform Resource 15 Identifier (URI). This Location URI can then be dereferenced in a 16 separate transaction by the client or sent to another entity and 17 dereferenced to learn physically where the client is located, but 18 only while valid. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 25, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. DHCP LocationURI Option Format and Rules .. . . . . . . . . . 4 56 2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4 57 2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5 58 2.3. Rules for both LocationURI and Valid-For Options . . . 6 59 3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 7 60 4. Architectural Assumptions . . . . . . . . . . . . . . . . . . 8 61 4.1 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 62 4.2 Valid Location URI Schemes or Types . . . . . . . . . . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 71 1. Introduction 73 This document creates a Dynamic Host Configuration Protocol (DHCP) 74 Option for transmitting a client's geolocation Uniform Resource 75 Identifier (URI) [RFC3986]. In this scenario, the DHCP client is a 76 Geopriv Target (i.e., the entity whose geolocation is associated 77 with the location URI). The DHCP implementation of the client can 78 then make this location information available to other applications 79 for their usage. This location URI points to a Location Server 80 [RFC5808] which has the geolocation of the client (e.g., previously 81 uploaded into a wiremap database then the client attaches to a known 82 wall-jack, or by means of 802.11 geolocation mechanisms). 84 Applications within the Target can then choose to dereference this 85 location URI and/or transmit the URI to another entity as a means of 86 conveying where the Target is located. Both Conveying and 87 Dereferencing a location URI is described in [RFC6442]. Session 88 Initiation Protocol (SIP) [RFC3261] is not the only protocol that 89 can dereference a location URI; there is also HTTP-Enabled Location 90 Delivery (HELD) [RFC6753] and HTTP [RFC2616]. 92 A Location Server (LS) stores the Target's location as a presence 93 document, called a Presence Information Data Format - Location 94 Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server 95 is the entity contacted during the act of dereferencing a Target's 96 location. If the dereferencing entity has permission, defined in 97 [RFC6772], the location of the target will be received. The LS 98 will grant permission to location inquiries based on the rules 99 established by a Rule Holder [RFC3693]. The LS has the ability to 100 challenge any request for a target's location, thereby providing 101 additive security properties before location revelation. 103 Possessing a location URI has advantages over having a PIDF-LO, 104 especially when a target's location changes. With a location URI, 105 when a target moves, the location URI does not change (at least 106 within the same domain). The location URI can still be given out as 107 the reference to the Target's current location. The opposite is true 108 if the location is conveyed by value in a message. Once the Target 109 moves, the previously given location is no longer valid, and if the 110 Target wants to inform another entity about its location, it has to 111 send the PIDF-LO to the location recipient (again). 113 A problem exists within existing RFCs that provide location to the 114 UA ([RFC6225] and [RFC4776]). Those DHCP Options for geolocation 115 values require an update of the entire location information (LI) 116 every time a client moves. Not all clients will move frequently, 117 but some will. Refreshing location values every time a client moves 118 does not scale in certain networks/environments, such as IP-based 119 cellular networks, enterprise networks or service provider networks 120 with mobile endpoints. An 802.11 based access network is one 121 example of this. Constantly updating Location Configuration 122 Information (LCI) to endpoints might not scale in mobile 123 (residential or enterprise or municipal) networks in which the 124 client is moving through more than one network attachment point, 125 perhaps as a person walks or drives with their client down a 126 neighborhood street or apartment complex or a shopping center or 127 through a municipality (that has IP connectivity as a service). 129 If the client was provided a location URI reference to retain and 130 hand out when it wants or needs to convey its location (in a 131 protocol other than DHCP), a location URI that would not change as 132 the client's location changes (within a domain). Scaling issues 133 would be significantly reduced to needing an update of the location 134 URI only when a client changes administrative domains - which is 135 much less often. This delivery of an indirect location has the 136 added benefit of not using up valuable or limited bandwidth to the 137 client with the constant updates. It also relieves the client from 138 having to determine when it has moved far enough to consider asking 139 for a refresh of its location. 141 In enterprise networks, if a known location is assigned to each 142 individual Ethernet port in the network, a device that attaches to 143 the network, such as a wall-jack (directly associated with a 144 specific Ethernet Switch port) will be associated with a known 145 location via a unique circuit-ID that's used by the Relay Agent 146 Information Option (RAIO) defined in RFC 3046 [RFC3046]. This 147 assumes wall-jacks have an updated wiremap database. RFC 6225 148 [RFC6225] and RFC 4776 [RFC4776] would return an LCI value of 149 location for either IPv4 or IPv6. This document specifies how a 150 location URI is returned using DHCP. The location URI points to a 151 PIDF-LO contained on an LS. Performing a dereferencing transaction, 152 that Target's PIDF-LO will be returned. If local configuration has 153 the requirement of only assigning unique location URIs to each 154 client at the same attachment point to the network (i.e., same RJ-45 155 jack or same 802.11 Access Point - except when triangulation is 156 used), then unique location URIs will be given out. They will all 157 have the same location at the record, relieving the backend Sighter 158 or LS from individually maintaining each location independently. 160 The location URI Option can be useful in IEEE 802.16e connected 161 endpoints or IP cellular endpoints. The location URI Option can be 162 configured on a router, such as a residential home gateway, such 163 that the router receives this Location URI Option as a client with 164 the ability to communicate to downstream endpoints as a server. 166 How an LS responds to a dereference request can vary, and a policy 167 established by a Ruleholder [RFC3693] for a Location Target as to 168 what type of challenge(s) is to be used, how strong a challenge is 169 used or how precise the location information is given to a 170 Location Recipient (LR). This document does not provide mechanisms 171 for the LS to tell the client about policies or for the client to 172 specify a policy for the LS. While an LS should apply an appropriate 173 access-control policy, clients must assume that the LS will provide 174 location in response to any request (following the possession model 175 [RFC5808]). For further discussion of privacy, see the Security 176 Considerations. 178 This document IANA-registers the new IPv4 and IPv6 DHCP Options for 179 a location URI and Valid-For. 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 2. Format of the DHCP LocationURI Option 187 2.1 Overall Format of LocationURI Option in IPv4 189 The LocationURI Option format for IPv4 is as follows: 191 0 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Code XXX | Length=XX | Valid-For ..... 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 ..... Valid-For (Cont'd) | LocationURI... ..... 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 ..... | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1. IPv4 Fields for this LocationURI Option 203 Code XXX: The code for this DHCPv4 option (IANA assigned). 205 Length=XX: The length of this option, counted in bytes - not 206 counting the Code and Length bytes. This is a variable 207 length Option, therefore the length value will change 208 based on the length of the URI within the Option. 210 Valid-For: The time, in seconds, the LocationURI is to be 211 considered valid for dereferencing. The Valid-For is 212 always represented as a four-byte unsigned integer. 214 LocationURI: Location URI - This field, in bytes, is the URI 215 pointing at the location record where the PIDF-LO for 216 the Location Target resides. The LocationURI is always 217 represented in ASCII. 219 2.2 Overall Format of LocationURI Option in IPv6 221 The LocationURI Option format for IPv6 is as follows: 223 0 1 2 3 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | option-code | option-len | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Valid-For | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | LocationURI... ..... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 ..... | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2. IPv6 fields of this LocationURI Option 237 option-code: The code for this DHCPv6 option (IANA assigned). 239 option-len: The length of this option, counted in bytes - not 240 counting the option-code and option-len bytes. This is 241 a variable length Option, therefore the length value 242 will change based on the length of the URI within the 243 Option. 245 Valid-For: see Section 2.1 247 LocationURI: see Section 2.1 249 2.3 Rules for the LocationURI Option 251 The LocationURI Option has the following rules: 253 o Implementation of the Location URI Option is REQUIRED on the DHCP 254 server and client. 256 o Clients SHOULD be expected to have to request the Location URI 257 Option from servers. Although local policy can have servers 258 perform an unsolicited push of a Location URI Option to a client. 260 Applications on a client can use the Location URI (value) until the 261 Valid-For value reaches zero. If there is no Valid-For Option value, 262 then the counter did not ever start (a null value), and applications 263 on a client continue to use the Location URI value until given a new 264 Location URI Option (with or without a Valid-For value) which 265 overwrites any previous Location URI and Valid-For Option values. 267 o A Location URI Option with a non-zero Valid-For field MUST NOT 268 transmit the Location URI once the Valid-For field counts down to 269 zero. 271 o A received Location URI Option containing all zeros in the 272 Valid-For field means that Location URI has no lifetime, and not 273 "no lifetime left". All zeros in the Valid-For field equates to a 274 null value. 276 o Receipt of the Location URI Option containing all zeros in the 277 Valid-For field MUST NOT cause any error in handling the Location 278 URI. 280 o When the Valid-For timer reaches zero, the client MUST purge any 281 location URI received via DHCP from its memory. 283 The choice of the Valid-For value is a policy decision for the 284 operator of the DHCP server. Like location URIs themselves, it can 285 be statically configured on the DHCP server or provisioned 286 dynamically (via an out-of-band exchange with a Location Information 287 Server) as requests for location URIs are received. 289 o Clients receiving a Location URI Option start the Valid-For timer 290 upon receipt of the DHCP message containing the Option. 292 o Clients MUST NOT trigger an automatic DHCP refresh on expiry of 293 the Valid-For timer; rather, they MUST follow normal DHCP 294 mechanics. 296 If the Valid-For timer is set to expire before the lease refresh, 297 the client will not have the ability to hand out its location until 298 the lease refresh, inadvertently allowing a gap of coverage. If the 299 Valid-For timer is set to expire after the lease refresh, some 300 wayward application on the client can divulge that location URI 301 after it is no longer valid, meaning the location could be stale or 302 just plain wrong. 304 o Servers SHOULD set the Valid-For timer to that of the lease 305 refresh, or bad things can happen. 307 3. DHCP Option Operation 309 The [RFC3046] RAIO can be utilized to provide the appropriate 310 indication to the DHCP Server where this DISCOVER or REQUEST message 311 came from, in order to supply the correct response. 313 Caution SHOULD always be used involving the creation of large 314 Options, meaning that this Option may need to be in its own INFORM, 315 OPTION or ACK message. DHCP messages are limited in size, and long 316 URIs will require the use of multiple messages and concatenation 317 [RFC3396]. It is, therefore, best to limit the total length of a 318 URI, including any parameters, to 220 bytes. 320 Location URIs MUST NOT reveal identity information of the user of 321 the device, since DHCP is a cleartext delivery protocol. For 322 example, creating a location URI such as 324 sips:34LKJH534663J54@example.com 326 is better than a location URI such as 328 sips:aliceisat123mainstatlantageorgiaus@example.com 330 The username portion of the first example URI provides no direct 331 identity information (in which 34LKJH534663J54 is considered to be a 332 random number in this example). 334 In the element of a PIDF-LO document, there is an 335 'entity' attribute that identifies what entity *this* presence 336 document (including the associated location) refers to. It is up to 337 the PIDF-LO generator, either Location Server or an application in 338 the endpoint, to insert the identity in the 'entity' attribute. 339 This can be seen in [RFC4119]. The considerations for populating 340 the entity attribute value in a PIDF-LO document are independent 341 from the considerations for avoiding exposing identification 342 information in the username part of a location URI. 344 This Option is used only for communications between a DHCP client 345 and a DHCP server. It can be solicited (requested) by the client, 346 or it can be pushed by the server without a request for it. DHCP 347 Options not understood MUST be ignored [RFC2131]. A DHCP server 348 supporting this Option might or might not have the location of a 349 client. If a server does not have a client's location, but needs to 350 provide this Location URI Option to a client (for whatever reason), 351 an LS is contacted. This server-to-LS transaction is not DHCP, 352 therefore it is out of scope of this document. Note that this 353 server-to-LS transaction could delay the DHCP messaging to the 354 client. If the server fails to have location before it transmits its 355 message to the client, location will not be part of that DHCP 356 message. Any timers involved here are a matter of local 357 configuration. 359 The dereference of a target's location URI would not involve DHCP, 360 but an application layer protocol, such as SIP or HTTP, therefore 361 dereferencing is out of scope of this document. 363 In the case of residential gateways being DHCP servers, they usually 364 perform as DHCP clients in a hierarchical fashion up into a service 365 provider's network DHCP server(s), or learn what information to 366 provide via DHCP to residential clients through a protocol, such as 367 PPP. In these cases, the location URI would likely indicate the 368 residence's civic address to all wired or wireless clients within 369 that residence. 371 4. Architectural Assumptions 373 The following assumptions are made once the client has obtained a 374 location URI, and not about DHCP operation specifics (in no 375 particular order): 377 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 378 to the dereferencing step is assumed to be out of scope of this 379 document. An example authorization policy is in [RFC6772]. 381 o The authorization security model vs. possession security model 382 discussion can be found in [RFC5606], describing what is expected 383 in each model of operation. It should be assumed that a location 384 URI attained using DHCP will operate under a possession model by 385 default. An authorization model can be instituted as a matter of 386 local policy. An authorization model means possessing the 387 location URI does not give that entity the right to view the 388 PIDF-LO of the target whose location is indicated in a presence 389 document. The dereference transaction will be challenged by the 390 Location Server only in an authorization model. The nature of 391 this challenge is out of scope of this document. 393 o This document does not prevent some environments from operating 394 in an authorization model, for example - in less tightly 395 controlled networks. The costs associated with authorization vs. 396 possession models are discussed in Section 3.3.2 of [RFC5606]. 398 4.1 Harmful URIs and URLs 400 There are, in fact, some types of URIs that are not good to receive, 401 due to security concerns. For example, any URLs that can have 402 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 403 pages that have scripts. Therefore, 405 o URIs received via this Option SHOULD NOT be automatically sent to 406 a general-browser to connect to a web page, because they could 407 have harmful scripts, unless 408 o the browser has been set up to defend against harmful scripts, 410 or 412 o the browser does not run scripts automatically. 414 o This Option MUST NOT contain "data:" URLs [RFC2397], because they 415 could contain harmful scripts. 417 4.2 Valid Location URI Schemes or Types 419 URIs carried by this DHCP Option MUST have one of the following URI 420 schemes: 422 1. sip: 423 2. sips: 424 3. pres: 425 4. http: 426 5. https: 428 URIs using the "pres" scheme are dereferenced using the presence 429 event package for SIP [RFC3856], so they will reference a PIDF-LO 430 document when location is available. Responses to requests for URIs 431 with other schemes ("sip", "sips", "http", and "https") MUST have 432 media type 'application/pidf+xml'[RFC4119]. Alternatively, HTTP and 433 HTTPS URIs MAY refer to information with media type 434 'application/held+xml', in order to support HELD dereferencing 435 [RFC6753]. Clients can indicate which media types they support 436 using the "Accept" header field in SIP [RFC3261] or HTTP [RFC2616]. 438 See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP. 440 It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442 441 [RFC6442] as guidance regarding which Location URI schemes to 442 provide in DHCP. That document discusses what a receiving entity 443 does when receiving a URI scheme that is not understood. Awareness 444 to the two URI types there is important for conveying location, if 445 SIP is used to convey a Location URI provided by DHCP. 447 5. IANA Considerations 449 5.1 The IPv4 Option number for the Location URI Option 451 This document IANA registers the DHCP Location URI Option Number in 452 the BOOTP Vendor Extensions and DHCP Options subregistry of the 453 Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol 454 (BOOTP) Parameters registry located. 456 Data 457 Tag Name Length Meaning Reference 458 ---- ---- ------ ------- --------- 459 XXX LocationURI N GeoLocation URI [this document] 461 The authors have no preference at this time on what number IANA 462 chooses. 464 5.2 The IPv6 Option-Code for the Location URI Option 466 This document IANA registers the DHCPv6 Option Code in the DHCP 467 Option Codes subregistry of the Dynamic Host Configuration Protocol 468 for IPv6 (DHCPv6) registry. 470 Value Description Reference 471 ---- ------------------ ---------- 472 XX OPTION_GEOLOCATION_URI [this document] 474 The authors have no preference at this time on what number IANA 475 chooses. 477 5.3 Valid Location URI Schemes 479 This document creates a new IANA registry (Valid Location URI 480 Schemes) of acceptable location URI schemes (or types) for this DHCP 481 Location URI Option of the Dynamic Host Configuration Protocol 482 (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry. 484 Initial values are given below; new assignments are to be made 485 following the "IETF Review" policies [RFC5226]. 487 "Valid Location URI Schemes" 489 Location 490 URI Scheme Reference 491 ---------- --------- 492 sip: [this document] 493 sips: [this document] 494 pres: [this document] 495 http: [this document] 496 https: [this document] 498 6. Security Considerations 500 Where critical decisions might be based on the value of this 501 location URI option, DHCP authentication as defined in 502 "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host 503 Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used 504 to protect the integrity of the DHCP options. 506 A real concern with RFC 3118 or RFC 3315 is that neither is widely 507 deployed because each requires pre-shared keys to successfully work 508 (i.e., in the client and in the server). Most implementations do 509 not accommodate this. 511 DHCP, initially, is a broadcast request (a client looking for a 512 server), and a unicast response (answer from a server) type of 513 protocol. There is no privacy protection for DHCP messages, an 514 eavesdropper who can monitor the link between the DHCP server and 515 requesting client can discover the Location URI. 517 Once a client has a Location URI, it needs information on how the 518 location server will control access to dereference requests. A 519 client might treat a tightly access-controlled URI differently from 520 one that can be dereferenced by anyone on the Internet (i.e., one 521 following the "possession model"). Since the client does not know 522 what policy will be applied during this validity interval, clients 523 MUST handle location URIs as if they could be dereferenced by 524 anybody until they expire. For example, such open location URIs 525 should only be transmitted in encrypted channels. Nonetheless, 526 location servers SHOULD apply appropriate access control policies, 527 for example by limiting the number of queries that any given client 528 can make, or limiting access to users within an enterprise. 530 Extensions to this option, such as [ID-POLICY-URI] can provide 531 mechanisms for accessing and provisioning policy. Giving users 532 access to policy information will allow them to make more informed 533 decisions about how to use their location URIs. Allowing users to 534 provide policy information to the LS will enable them to tailor 535 access control policies to their needs (within the bounds of policy 536 that the LS will accept). 538 As to the concerns about the location URI itself, as stated in the 539 document (see Section 3), it MUST NOT have any user identifying 540 information in the URI user-part/string itself. The location URI 541 also needs to be hard to guess that it belongs to a specific user. 543 In some cases a DHCP server may be implemented across an 544 uncontrolled network. In those cases, it would be appropriate for a 545 network administrator to perform a threat analysis (see RFC 3552) 546 and take precautions as needed. 548 Link-layer confidentiality and integrity protection may also be 549 employed to reduce the risk of location disclosure and tampering. 551 7. Acknowledgements 553 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 554 Robert Sparks for their useful comments. And to Lisa Dusseault for 555 her concerns about the types of URIs that can cause harm. To 556 Richard Barnes for inspiring a more robust Security Considerations 557 section, and for offering the text to incorporate HTTP URIs. To 558 Hannes Tschofenig and Ted Hardie for riding me to comply with their 559 concerns, including a good scrubbing of the nearly final doc. 561 8. References 563 8.1. Normative References 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 569 March 1997. 571 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 572 3046, January 2001. 574 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 575 Messages", RFC 3118, June 2001. 577 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. 578 Carney, "Dynamic Host Configuration Protocol for IPv6 579 (DHCPv6)", RFC 3315, July 2003 581 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 582 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 583 Session Initiation Protocol", RFC 3261, May 2002. 585 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 586 Host Configuration Protocol (DHCPv4)", RFC 3396, November 587 2002 589 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 590 Initiation Protocol (SIP)", RFC 3856, August 2004 592 [RFC3922] P. Saint-Andre, " Mapping the Extensible Messaging and 593 Presence Protocol (XMPP) to Common Presence and Instant 594 Messaging (CPIM)", RFC 3922, October 2004 596 [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 597 Identifier (URI): Generic Syntax", RFC 3986, January 2005 599 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 600 Format", RFC 4119, December 2005 602 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 603 Considerations Section in RFCs", RFC 5226, May 2008 605 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 606 for the Session Initiation Protocol", RFC 6442, December 607 2011. 609 [RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, 610 M. Dawson, "A Location Dereferencing Protocol Using HELD", 611 October 2012 613 8.2. Informative References 615 [RFC2397] L. Masinter, "The "data" URL scheme", RFC 2397, August 1998 617 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 618 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 619 Protocol - HTTP/1.1", RFC 2616, June 1999 621 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 622 "Geopriv Requirements", RFC 3693, February 2004 624 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, 625 "Dynamic Host Configuration Protocol Options for 626 Coordinate-Based Location Configuration Information", 627 RFC 6225, July 2011. 629 [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol 630 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 631 Information ", RFC 4776, November 2006 633 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 634 'retransmission-allowed' for SIP Location Conveyance", 635 August 2009 637 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference 638 Mechanism", RFC 5808, May 2010 640 [RFC6772] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 641 Polk, "Geolocation Policy: A Document Format for Expressing 642 Privacy Preferences for Location Information", January 2013 644 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 645 Configuration Extensions for Policy Management", "work in 646 progress", November 2011 648 Authors' Address 650 James Polk 651 3913 Treemont Circle 652 Colleyville, Texas 76034 653 USA 655 Email: jmpolk@cisco.com