idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-14.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 (Mar 12, 2012) is 4422 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 5808 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network WG James Polk 2 Internet-Draft Cisco Systems 3 Intended status: Proposed Standard Mar 12, 2012 4 Expires: Sept 12, 2012 6 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 7 Option for a Location Uniform Resource Identifier (URI) 8 draft-ietf-geopriv-dhcp-lbyr-uri-option-14 10 Abstract 12 This document creates a Dynamic Host Configuration Protocol (DHCP) 13 Option for transmitting a client's geolocation Uniform Resource 14 Identifier (URI). This Location URI can then be dereferenced in a 15 separate transaction by the client or sent to another entity and 16 dereferenced to learn physically where the client is located. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Format of the DHCP LocationURI Option . . . . . . . . . . . . 4 54 2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4 55 2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5 56 2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5 57 3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6 58 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 59 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 60 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 7.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 1. Introduction 75 This document creates a Dynamic Host Configuration Protocol (DHCP) 76 Option for transmitting a client's geolocation Uniform Resource 77 Identifier (URI). The DHCP implementation of the client can then 78 make this location information available to upper layer protocols 79 for their usage. This location URI points a Location Server 80 [RFC5808] which has the geolocation of the client (through means 81 not defined in this document). In this scenario, the DHCP client 82 is a Geopriv Target (i.e., the entity whose geolocation is 83 associated with the location URI). 85 Applications using upper layer protocols within the Target can then 86 choose to deference this location URI and/or transmit the URI to 87 another entity as a means of conveying where the Target is located. 88 Dereferencing a location URI is described in [RFC6442]. Conveying 89 a location URI is also described in [RFC6442]. Session Initiation 90 Protocol (SIP) is not the only protocol that can dereference a 91 location URI; there is also HTTP-Enabled Location Delivery (HELD) 92 [ID-HELD-DEREF] and HTTP [RFC2616]. 94 Having a location URI has advantages over having a PIDF-LO, 95 especially when a target's location changes. With a location URI, 96 when a target moves, the location URI does not change (at least 97 within the same domain). It can still be given out as the reference 98 to the Target's current location. The opposite is true if the 99 location is conveyed by value in a message. Once the Target moves, 100 the previously given location is no longer valid, and if the Target 101 wants to inform another entity about its location, it has to send 102 the PIDF-LO to the location recipient (again). 104 A Location Server (LS) stores the Target's location as a presence 105 document, called a Presence Information Data Format - Location 106 Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server 107 is the entity contacted during the act of dereferencing a Target's 108 location. If the dereferencing entity has permission, defined in 109 [ID-GEO-POL], the location of the target will be received. The LS 110 will grant permission to location inquires based on the rules 111 established by a Rule Holder [RFC3693]. The LS has the ability to 112 challenge any request for a target's location, thereby providing 113 additive security properties before location revelation. 115 A problem exists within existing RFCs that provide location to the 116 UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation 117 values require an update of the entire location information (LI) 118 every time a client moves. Not all clients will move frequently, 119 but some will. Refreshing location values every time a client moves 120 does not scale in certain networks/environments, such as IP-based 121 cellular networks, enterprise networks or service provider networks 122 with mobile endpoints. An 802.11 based access network is one 123 example of this. Constantly updating LCI to endpoints might not 124 scale in mobile (residential or enterprise or municipal) networks in 125 which the client is moving through more than one network attachment 126 point, perhaps as a person walks or drives with their client down a 127 neighborhood street or apartment complex or a shopping center or 128 through a municipality (that has IP connectivity as a service). 130 If the client was provided a location URI reference to retain and 131 hand out when it wants or needs to convey its location (in a 132 protocol other than DHCP), a location URI that would not change as 133 the client's location changes (within a domain), scaling issues 134 would be significantly reduced to needing an update of the location 135 URI only when a client changes administrative domains - which is 136 much less often. This delivery of an indirect location has the 137 added benefit of not using up valuable or limited bandwidth to the 138 client with the constant updates. It also relieves the client from 139 having to determine when it has moved far enough to consider asking 140 for a refresh of its location. 142 In enterprise networks, if a known location is assigned to each 143 individual Ethernet port in the network, a device that attaches to 144 the network a wall-jack (directly associated with a specific 145 Ethernet Switch port) will be associated with a known location via a 146 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 147 [RFC3046]. This assumes wall-jacks have an updated wiremap 148 database. RFC 3825 and RFC 4776 would return an LCI value of 149 location. This document specifies how a location URI is returned 150 using DHCP. The location URI points to a PIDF-LO contained on an 151 LS. Performing a dereferencing transaction, that Target's PIDF-LO 152 will be returned. If local configuration has the requirement of 153 only assigning unique location URIs to each client at the same 154 attachment point to the network (i.e., same RJ-45 jack or same 155 802.11 Access Point - except when triangulation is used), then 156 unique location URIs will be given out, though they will all have 157 the same location at the record, relieving the backend Sighter or LS 158 from individually maintaining each location independently. 160 This Option can be useful in IEEE 802.16e connected endpoints or IP 161 cellular endpoints. The location URI Option can be configured on a 162 router, such as a residential home gateway, such that the router 163 receives this Location URI Option as a client with the ability to 164 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. 181 2. Format of the DHCP LocationURI Option 183 2.1 Overall Format of LocationURI Option in IPv4 185 The LocationURI Option format for IPv4 is as follows: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Code XXX | Length=XX | . 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 192 . LocationURI... ... 193 . (see Section 2.3 for details) ... | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1. IPv4 Fields for this LocationURI Option 198 Code XXX: The code for this DHCPv4 option (IANA assigned). 200 Length=XX: The length of this option, counted in bytes - not 201 counting the Code and Length bytes. This is a variable 202 length Option, therefore the length value will change 203 based on the length of the URI within the Option. 205 LocationURI: see Section 2.3 for details 207 2.2 Overall Format of LocationURI Option in IPv6 209 The LocationURI Option format for IPv6 is as follows: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | option-code | option-len | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | LocationURI... . 217 . (see Section 2.3 for details) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2. IPv6 fields of this LocationURI Option 222 option-code: The code for this DHCPv6 option (IANA assigned). 224 option-len: The length of this option, counted in bytes - not 225 counting the Code and Length bytes. This is a variable 226 length Option, therefore the length value will change 227 based on the length of the URI within the Option. 229 LocationURI: see below (Section 2.3 for details). 231 2.3 LocationURI Format for both IPv4 and IPv6 233 The LocationURI, in both DHCPv4 and DHCPv6, have the following 234 format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | LuriType | LuriLength | LuriValue ... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 3. LocationURI TLV Format for both IPv4 and IPv6 244 LuriType: A one-byte identifier of the data location value. 246 LuriLength: The length of the LuriValue, not including the 247 LuriLength field itself, up to a maximum of 255 248 units. The unit of measurement is defined by the 249 LuriType field definition. The LuriLength itself is 250 always a one-byte unsigned integer. 252 LuriValue: The LocationURI value, as described in detail below. 254 The LuriTypes this document defines for a point are: 256 LuriType=1 Location URI - This field, in bytes, is the URI 257 pointing at the location record where the PIDF-LO for 258 the Location Target resides. The LuriValue of 259 LuriType=1 is always represented in UTF-8. 261 LuriType=2 Valid-For - The time, in seconds, this URI is to be 262 considered Valid for dereferencing. The timer 263 associated with this LuriType starts upon receipt of 264 this Option by the client. The LuriValue of LuriType=2 265 is always represented as a four-byte unsigned integer. 267 The Valid-For (LuriType=2) indicates how long, in seconds, the 268 client is to consider this location URI (LuriType=1) valid. 269 Applications MUST NOT make use of a location URI after it becomes 270 invalid (i.e., after the Valid-For timer expires). 272 The choice of the Valid-For value is a policy decision for the 273 operator of the DHCP server. Like location URIs themselves, it can 274 be statically configured on the DHCP server or provisioned 275 dynamically (via an out-of-band exchange with a Location Information 276 Server) as requests for location URIs are received. 278 The Valid-For timer is used only at the application layer, as an 279 indication of when the URI can be used to access location. It is 280 independent of the DHCP lease timer, and in no way related to the 281 DHCP state machine. Clients MUST NOT trigger an automatic DHCP 282 refresh on expiry of the Valid-For timer; rather, they should follow 283 normal DCHP mechanics. 285 Server operators should consider the relation between the Valid-For 286 time and the lease time. Clients typically request a lease refresh 287 when half the lease time is up. If the Valid-For time is less than 288 the typical refresh rate (i.e., half the lease time), then for the 289 remaining interval, clients will run the risk of not having a usable 290 location URI for applications. If the Valid-For time is less than 291 half the typical refresh rate, it is a near certainty clients will 292 not have a usable location URI for the interval between the 293 Valid-For time and the typical refresh time for applications. 295 For example, if a lease is set to 24 hours, the typical refresh 296 request is set to initiate at the 12 hour mark. If the Valid-For 297 timer is set to less than 24 hours, but more than 12 hours (in this 298 example), the client might not be refreshed at the 12 hour mark and 299 runs the risk of not have a location URI for applications that 300 request it. If, on the other hand, the Valid-For timer is less than 301 12 hours (in this example, which is before a typical client would 302 ask for a refresh, applications will be without a usable location 303 URI until the full refresh has been received. 305 It should be expected that clients will overwrite any previous 306 Option values when receiving a new instance of that Option number. 308 The Valid-For (LuriType=2) offers no meaningful information without 309 an accompanying Location URI (LuriType=1), therefore a Valid-For 310 (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1). 312 The Valid-For (LuriType=2) is not mandated for use by this document. 313 However, its presence MUST NOT cause any error in handling the 314 location URI (i.e., if not understood, it MUST be ignored). 316 This Option format is highly extensible. Additional LuriType types 317 created MUST be done so through IANA registration with a standards 318 track RFC. 320 3. DHCP Option Operation 322 The [RFC3046] RAIO can be utilized to provide the appropriate 323 indication to the DHCP Server where this DISCOVER or REQUEST message 324 came from, in order to supply the correct response. 326 Caution SHOULD always be used involving the creation of large 327 Options, meaning that this Option MAY need to be in its own INFORM, 328 OPTION or ACK message. 330 It is RECOMMENDED to avoid building URIs, with any parameters, 331 larger than what a single DHCP response can be. However, if a 332 message is larger than 255 bytes, concatenation is allowed, per RFC 333 3396 [RFC3396]. 335 Per [RFC2131], subsequent LocationURI Options, which are 336 non-concatenated, overwrite the previous value. 338 Location URIs MUST NOT reveal identity information of the user of 339 the device, since DHCP is a cleartext delivery protocol. For 340 example, creating a location URI such as 342 sips:34LKJH534663J54@example.com 344 is better than a location URI such as 346 sips:aliceisat123mainstalantageorgiaus@example.com 348 The username portion of the first example URI provides no direct 349 identity information (in which 34LKJH534663J54 is considered to be a 350 random number in this example). 352 In the element of a PIDF-LO document, there is an 353 'entity' attribute that identities what entity *this* document 354 (including the associated location) refers to. It is up to the 355 PIDF-LO generator, either Location Server or an application in the 356 endpoint, to insert the identity in the 'entity' attribute. This 357 can be seen in [RFC4119]. The considerations for populating the 358 entity attribute value in a PIDF-LO document are independent from 359 the considerations for avoiding exposing identification information 360 in the username part of a location URI. 362 This Option is used only for communications between a DHCP client 363 and a DHCP server. It can be solicited (requested) by the client, 364 or it can be pushed by the server without a request for it. DHCP 365 Options not understood MUST be ignored [RFC2131]. A DHCP server 366 supporting this Option might or might not have the location of a 367 client. If a server does not have a client's location, but needs to 368 provide this Location URI Option to a client (for whatever reason), 369 an LS is contacted. This server-to-LS transaction is not DHCP, 370 therefore it is out of scope of this document. Note that this 371 server-to-LS transaction could delay the DHCP messaging to the 372 client. If the server fails to have location before it transmits its 373 message to the client, location will not be part of that DHCP 374 message. Any timers involved here are a matter of local 375 configuration. 377 The deference of a target's location URI would not involve DHCP, but 378 an application layer protocol, such as SIP or HTTP, therefore 379 dereferencing is out of scope of this document. 381 In the case of residential gateways being DHCP servers, they usually 382 perform as DHCP clients in a hierarchical fashion up into a service 383 provider's network DHCP server(s), or learn what information to 384 provide via DHCP to residential clients through a protocol, such as 385 PPP. In these cases, the location URI would likely indicate the 386 residence's civic address to all wired or wireless clients within 387 that residence. 389 3.1 Architectural Assumptions 391 The following assumptions have been made for use of this LocationURI 392 Option for a client to learn its location URI (in no particular 393 order): 395 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 396 to the dereferencing step is assumed to be out of scope of this 397 document. An example authorization policy is in [ID-GEO-POL]. 399 o The authorization vs. possession security model can be found in 400 [RFC5808], describing what is expected in each model of 401 operation. It should be assumed that a location URI attained 402 using DHCP will operate under an possession model by default. 404 An authorization model can be instituted as a matter of local 405 policy. An authorization model means possessing the location URI 406 does not give that entity the right to view the PIDF-LO of the 407 target whose location is indicated in a presence document. The 408 dereference transaction will be challenged by the Location Server 409 only in an authorization model. The nature of this challenge is 410 out of scope of this document. 412 o This document does not prevent some environments from operating 413 in an authorization model, for example - in less tightly 414 controlled networks. The costs associated with authorization vs. 415 possession models are discussed in Section 3.3.2 of [RFC5606]. 417 3.2 Harmful URIs and URLs 419 There are, in fact, some types of URIs that are not good to receive, 420 due to security concerns. For example, any URLs that can have 421 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 422 pages that have scripts. Therefore, 424 o URIs received via this Option MUST NOT be automatically sent to a 425 general-browser to connect to a web page, because they could have 426 harmful scripts. 428 o This Option MUST NOT contain "data:" URLs, because they could 429 contain harmful scripts. 431 Instead of listing all the types of URIs and URLs that can be 432 misused or potentially have harmful affects, Section 3.3 IANA 433 registers acceptable location URI schemes (or types). 435 3.3 Valid Location URI Schemes or Types 437 This section specifies which URI types are acceptable as a location 438 URI scheme (or type) for this DHCP Option: 440 1. sip: 441 2. sips: 442 3. pres: 443 4. http: 444 5. https: 446 URIs using the "pres" scheme are dereferenced using the presence 447 event package for SIP [RFC3856], so they will reference a PIDF-LO 448 document when location is available. Responses to requests for URIs 449 with other schemes ("sip", "sips", "http", and "https") MUST have 450 MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS 451 URIs MAY refer to information with MIME type 'application/held+xml', 452 in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can 453 indicate which MIME types they support using the "Accept" header 454 field in SIP [RFC3261] or HTTP [RFC2616]. 456 See RFC 3922 [RFC3922] for using the pres: URI with XMPP. 458 It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442 459 [RFC6442] as guidance regarding which Location URI schemes to 460 provide in DHCP. That document discusses what a receiving entity 461 does when receiving a URI scheme that is not understood. Awareness 462 to the two URI types there is important for conveying location, if 463 SIP is used to convey a Location URI provided by DHCP. 465 4. IANA Considerations 467 4.1 The IPv4 Option number for this Option 469 This document IANA registers this IPv4 Option number XXX (to be 470 assigned by IANA once this document becomes an RFC). 472 4.2 The IPv6 Option-Code for this Option 474 This document IANA registers this IPv6 Option-Code XXX (to be 475 assigned by IANA once this document becomes an RFC). 477 4.3 IANA Considerations for LuriTypes 479 IANA is requested to create a new registry for acceptable location 480 types defined in Section 3.2 of this document, arranged similar to 481 this: 483 +------------+----------------------------------------+-----------+ 484 | LuriType | Name | Reference | 485 +------------+----------------------------------------+-----------+ 486 | 1 | Location URI | RFC XXXX* | 487 | 2 | Valid-For | RFC XXXX* | 488 +------------+----------------------------------------+-----------+ 490 * RFC XXXX is to be replaced with this document's RFC-Editor RFC 491 number. 493 Additions to this registry require a standards track RFC. 495 5. Security Considerations 497 Where critical decisions might be based on the value of this 498 location URI option, DHCP authentication in [RFC3118] SHOULD be used 499 to protect the integrity of the DHCP options. 501 A real concern with RFC 3118 it is that not widely deployed because 502 it requires pre-shared keys to successfully work (i.e., in the 503 client and in the server). Most implementations do not 504 accommodate this. 506 DHCP, initially, is a broadcast request (a client looking for a 507 server), and a unicast response (answer from a server) type of 508 protocol. It does not provide security at the network layer. 509 Instead, it relies on lower-layer security mechanisms. 511 Once a client has a URI, it needs information on how the location 512 server will control access to dereference requests. A client might 513 treat a tightly access-controlled URI differently from one that can 514 be dereferenced by anyone on the Internet (i.e., one following the 515 "possession model"). With the LuriTypes defined in this document, 516 the DHCP option for delivering location URIs can only tell the user 517 how long the URI will be valid. Since the client does not know what 518 policy will be applied during this validity interval, clients MUST 519 handle location URIs as if they could be dereferenced by anybody 520 until they expire. For example, such open location URIs should only 521 be transmitted in encrypted channels. Nonetheless, location servers 522 SHOULD apply appropriate access control policies, for example by 523 limiting the number of queries that any given client can make, or 524 limiting access to users within an enterprise. 526 Extensions to this option, such as [ID-POLICY-URI] can provide 527 mechanisms for accessing and provisioning policy. Giving users 528 access to policy information will allow them to make more informed 529 decisions about how to use their location URIs. Allowing users to 530 provide policy information to the LS will enable them to tailor 531 access control policies to their needs (within the bounds of policy 532 that the LS will accept). 534 As to the concerns about the location URI itself, as stated in the 535 document (see Section 3), it MUST NOT have any user identifying 536 information in the URI user-part/string itself. The location URI 537 also needs to be hard to guess that it belongs to a specific user. 539 When implementing a DHCP server that will serve clients across an 540 uncontrolled network, one should consider the potential security 541 risks therein. 543 6. Acknowledgements 545 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 546 Robert Sparks for their useful comments. And to Lisa Dusseault for 547 her concerns about the types of URIs that can cause harm. To 548 Richard Barnes for inspiring a more robust Security Considerations 549 section, and for offering the text to incorporate HTTP URIs. To 550 Hannes Tschofenig and Ted Hardie for riding me to comply with their 551 concerns, including a good scrubbing of the nearly final doc. 553 7. References 555 7.1. Normative References 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, March 1997. 560 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 561 March 1997. 563 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 564 3046, January 2001. 566 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 567 Messages", RFC 3118, June 2001. 569 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 570 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 571 Session Initiation Protocol", RFC 3261, May 2002. 573 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 574 Host Configuration Protocol (DHCPv4)", RFC 3396, November 575 2002 577 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 578 Initiation Protocol (SIP)", RFC 3856, August 2004 580 [RFC3922] P. Saint-Andre, " Mapping the Extensible Messaging and 581 Presence Protocol (XMPP) to Common Presence and Instant 582 Messaging (CPIM)", RFC 3922, October 2004 584 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 585 Format", RFC 4119, December 2005 587 [RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference 588 Mechanism", RFC 5808, May 2010 590 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 591 for the Session Initiation Protocol", RFC 6442, December 592 2011. 594 7.2. Informative References 596 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 597 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 598 Protocol - HTTP/1.1", RFC 2616, June 1999 600 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 601 "Geopriv Requirements", RFC 3693, February 2004 603 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 604 Configuration Protocol Option for Coordinate-based Location 605 Configuration Information", RFC 3825, July 2004 607 [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol 608 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 609 Information ", RFC 4776, November 2006 611 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 612 'retransmission-allowed' for SIP Location Conveyance", 613 August 2009 615 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference 616 Mechanism", RFC 5808, May 2010 618 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 619 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 620 HELD", "work in progress", October 2011 622 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 623 Polk, "Geolocation Policy: A Document Format for Expressing 624 Privacy Preferences for Location Information", "work in 625 progress", October 2011 627 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 628 Configuration Extensions for Policy Management", "work in 629 progress", November 2011 631 Authors' Address 633 James Polk 634 3913 Treemont Circle 635 Colleyville, Texas 76034 636 USA 638 Email: jmpolk@cisco.com