idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-18.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 14 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 5, 2013) is 4098 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 informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 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 5, 2013 5 Expires: July 5, 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-18 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), and another Option to explicitly indicate how long 16 that location URI is to be considered valid. This Location URI can 17 then be dereferenced in a separate transaction by the client or sent 18 to another entity and dereferenced to learn physically where the 19 client is located, but only while valid. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 5, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Format of the DHCP LocationURI and Valid-For Options . . . . 4 57 2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4 58 2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5 59 2.3. Overall Format of Valid-For Option in IPv4 . . . . . . 5 60 2.4. Overall Format of Valid-For Option in IPv6 . . . . . . 6 61 2.5. Rules for both LocationURI and Valid-For Options . . . 6 62 3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 8 63 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 9 64 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 10 65 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 10 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 7.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 1. Introduction 80 This document creates a Dynamic Host Configuration Protocol (DHCP) 81 Option for transmitting a client's geolocation Uniform Resource 82 Identifier (URI), and another Option to explicitly indicate how long 83 that location URI is to be considered valid. In this scenario, the 84 DHCP client is a Geopriv Target (i.e., the entity whose geolocation 85 is associated with the location URI). The DHCP implementation of the 86 client can then make this location information available to other 87 applications for their usage. This location URI points to a 88 Location Server [RFC5808] which has the geolocation of the client 89 (e.g., uploaded into a wiremap database when the client attached 90 wall-jack,or by means of 802.11 geolocation mechanisms). 92 Applications within the Target can then choose to dereference this 93 location URI and/or transmit the URI to another entity as a means of 94 conveying where the Target is located. Both Conveying and 95 Dereferencing a location URI is described in [RFC6442]. Session 96 Initiation Protocol (SIP) is not the only protocol that can 97 dereference a location URI; there is also HTTP-Enabled Location 98 Delivery (HELD) [RFC6753] and HTTP [RFC2616]. 100 A Location Server (LS) stores the Target's location as a presence 101 document, called a Presence Information Data Format - Location 102 Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server 103 is the entity contacted during the act of dereferencing a Target's 104 location. If the dereferencing entity has permission, defined in 105 [RFC6772], the location of the target will be received. The LS 106 will grant permission to location inquiries based on the rules 107 established by a Rule Holder [RFC3693]. The LS has the ability to 108 challenge any request for a target's location, thereby providing 109 additive security properties before location revelation. 111 Possessing a location URI has advantages over having a PIDF-LO, 112 especially when a target's location changes. With a location URI, 113 when a target moves, the location URI does not change (at least 114 within the same domain). The location URI can still be given out as 115 the reference to the Target's current location. The opposite is true 116 if the location is conveyed by value in a message. Once the Target 117 moves, the previously given location is no longer valid, and if the 118 Target wants to inform another entity about its location, it has to 119 send the PIDF-LO to the location recipient (again). 121 A problem exists within existing RFCs that provide location to the 122 UA ([RFC6225] and [RFC4776]). Those DHCP Options for geolocation 123 values require an update of the entire location information (LI) 124 every time a client moves. Not all clients will move frequently, 125 but some will. Refreshing location values every time a client moves 126 does not scale in certain networks/environments, such as IP-based 127 cellular networks, enterprise networks or service provider networks 128 with mobile endpoints. An 802.11 based access network is one 129 example of this. Constantly updating Location Configuration 130 Information (LCI) to endpoints might not scale in mobile 131 (residential or enterprise or municipal) networks in which the 132 client is moving through more than one network attachment point, 133 perhaps as a person walks or drives with their client down a 134 neighborhood street or apartment complex or a shopping center or 135 through a municipality (that has IP connectivity as a service). 137 If the client was provided a location URI reference to retain and 138 hand out when it wants or needs to convey its location (in a 139 protocol other than DHCP), a location URI that would not change as 140 the client's location changes (within a domain). Scaling issues 141 would be significantly reduced to needing an update of the location 142 URI only when a client changes administrative domains - which is 143 much less often. This delivery of an indirect location has the 144 added benefit of not using up valuable or limited bandwidth to the 145 client with the constant updates. It also relieves the client from 146 having to determine when it has moved far enough to consider asking 147 for a refresh of its location. 149 In enterprise networks, if a known location is assigned to each 150 individual Ethernet port in the network, a device that attaches to 151 the network, such as a wall-jack (directly associated with a 152 specific Ethernet Switch port) will be associated with a known 153 location via a unique circuit-ID that's used by the Relay Agent 154 Information Option (RAIO) defined in RFC 3046 [RFC3046]. This 155 assumes wall-jacks have an updated wiremap database. RFC 6225 156 [RFC6225] and RFC 4776 [RFC4776] would return an LCI value of 157 location for either IPv4 or IPv6. This document specifies how a 158 location URI is returned using DHCP. The location URI points to a 159 PIDF-LO contained on an LS. Performing a dereferencing transaction, 160 that Target's PIDF-LO will be returned. If local configuration has 161 the requirement of only assigning unique location URIs to each 162 client at the same attachment point to the network (i.e., same RJ-45 163 jack or same 802.11 Access Point - except when triangulation is 164 used), then unique location URIs will be given out. They will all 165 have the same location at the record, relieving the backend Sighter 166 or LS from individually maintaining each location independently. 168 The location URI Option can be useful in IEEE 802.16e connected 169 endpoints or IP cellular endpoints. The location URI Option can be 170 configured on a router, such as a residential home gateway, such 171 that the router receives this Location URI Option as a client with 172 the ability to communicate to downstream endpoints as a server. 174 How an LS responds to a dereference request can vary, and a policy 175 established by a Ruleholder [RFC3693] for a Location Target as to 176 what type of challenge(s) is to be used, how strong a challenge is 177 used or how precise the location information is given to a 178 Location Recipient (LR). This document does not provide mechanisms 179 for the LS to tell the client about policies or for the client to 180 specify a policy for the LS. While an LS should apply an appropriate 181 access-control policy, clients must assume that the LS will provide 182 location in response to any request (following the possession model 183 [RFC5808]). For further discussion of privacy, see the Security 184 Considerations. 186 This document IANA-registers the new IPv4 and IPv6 DHCP Options for 187 a location URI and Valid-For. 189 2. Format of the DHCP LocationURI Option 191 2.1 Overall Format of LocationURI Option in IPv4 193 The LocationURI Option format for IPv4 is as follows: 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Code XXX | Length=XX | ..... 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 ..... LocationURI... ..... 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 ..... | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 1. IPv4 Fields for this LocationURI Option 206 Code XXX: The code for this DHCPv4 option (IANA assigned). 208 Length=XX: The length of this option, counted in bytes - not 209 counting the Code and Length bytes. This is a variable 210 length Option, therefore the length value will change 211 based on the length of the URI within the Option. 213 LocationURI: Location URI - This field, in bytes, is the URI 214 pointing at the location record where the PIDF-LO for 215 the Location Target resides. The LocationURI is always 216 represented in ASCII. 218 2.2 Overall Format of LocationURI Option in IPv6 220 The LocationURI Option format for IPv6 is as follows: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | option-code | option-len | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | LocationURI... ..... 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ..... | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2. IPv6 fields of this LocationURI Option 234 option-code: The code for this DHCPv6 option (IANA assigned). 236 option-len: The length of this option, counted in bytes - not 237 counting the option-code and option-len bytes. This is 238 a variable length Option, therefore the length value 239 will change based on the length of the URI within the 240 Option. 242 LocationURI: see Section 2.1 244 2.3 Overall Format of Valid-For Option in IPv4 246 The Valid-For Option format for IPv4 is as follows: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Code XXX | Valid-For ..... 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 ..... | 255 +-+-+-+-+-+-+-+-+ 257 Figure 1. IPv4 Fields for this Valid-For Option 259 Code XXX: The code for this DHCPv4 option (IANA assigned). 261 Valid-For: Valid-For - The time, in seconds, the LocationURI - 262 received in the same DHCP message - is to be 263 considered valid for dereferencing. The Valid-For is 264 always represented as a four-byte unsigned integer. 266 2.4 Overall Format of Valid-For Option in IPv6 268 The Valid-For Option format for IPv6 is as follows: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | option-code | Valid-For ..... 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ..... Valid-For (Cont'd) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 2. IPv6 fields of this Valid-For Option 280 option-code: The code for this DHCPv6 option (IANA assigned). 282 Valid-For: see Section 2.3 284 2.5 Rules for both LocationURI and Valid-For Options 286 The LocationURI and Valid-For Options have the following 287 rules: 289 o Implementation of the Location URI Option is mandatory on the DHCP 290 server and client, per this specification. 292 o Implementation of the Valid-For Option is OPTIONAL on the DHCP 293 server and client, per this specification. 295 o The Location URI Option MUST be sent from a server, and received 296 by a client with or without an accompanying Valid-For Option. 298 The Valid-For Option offers no meaningful information to a client 299 without an accompanying Location URI Option, and might be 300 misunderstood or misapplied, therefore 302 o The Valid-For Option MUST NOT be sent from a server, and received 303 by a client, without an accompanying Location URI Option. 305 o A client receiving a Valid-For Option without a Location URI 306 Option MUST ignore the Valid-For Option. 308 o The Valid-For Option MUST only be considered in relation to the 309 Location URI Option. It has no other purpose in DHCP then in 310 relation to the Location URI (i.e., there is no other Option in 311 DHCP to which it has meaning). 313 o The Valid-For Option MUST NOT cause any error in handling the 314 Location URI, i.e., if not understood, it MUST be ignored. 316 A client uses the Location URI (value) until the Valid-For value 317 reaches zero. If there is no Valid-For Option value, then the 318 counter did not ever start (a null value), and the client continues 319 to use the Location URI value until given a new Location URI Option 320 (with or without a Valid-For value) which overwrites any previous 321 Location URI and Valid-For Option values. 323 o Servers MUST assume that clients will overwrite any existing, 324 previously sent values of Location URI Option and/or Valid-For 325 Option. 327 o Clients MUST overwrite any existing, previously sent values of 328 Location URI Option and/or Valid-For Option when receiving the 329 next instance of either Option. 331 o If a client receives a new Location URI Option without also 332 receiving a new Valid-For Option - with the previous Valid-For 333 Option timer not reaching zero, the Valid-For timer MUST be set to 334 zero upon reception of this new Location URI Option. 336 The choice of the Valid-For value is a policy decision for the 337 operator of the DHCP server. Like location URIs themselves, it can 338 be statically configured on the DHCP server or provisioned 339 dynamically (via an out-of-band exchange with a Location Information 340 Server) as requests for location URIs are received. 342 o Clients receiving both a Location URI and Valid-For Options start 343 the Valid-For timer upon receipt of the DHCP message containing 344 both Options. 346 o Applications MUST NOT make use of a location URI after it becomes 347 invalid (i.e., after the Valid-For timer expires). 349 The Valid-For timer is used only at the application layer, as an 350 indication of when the URI can be used to access location. It is 351 independent of the DHCP lease timer, and in no way related to the 352 DHCP state machine. 354 o Clients MUST NOT trigger an automatic DHCP refresh on expiry of 355 the Valid-For timer; rather, they SHOULD follow normal DHCP 356 mechanics. 358 Server operators should consider the relation between the Valid-For 359 time and the lease time. Clients typically request a lease refresh 360 when half the lease time is up. If the Valid-For time is less than 361 the typical refresh rate (i.e., half the lease time), then for the 362 remaining interval, clients will run the risk of not having a usable 363 location URI for applications. If the Valid-For time is less than 364 half the typical refresh rate, it is a near certainty clients will 365 not have a usable location URI for the interval between the 366 Valid-For time and the typical refresh time for applications. For 367 example, if a lease is set to 24 hours, the typical refresh request 368 is set to initiate at the 12 hour mark. If the Valid-For timer is 369 set to less than 24 hours, but more than 12 hours (in this example), 370 the client might not be refreshed at the 12 hour mark and runs the 371 risk of not have a location URI for applications that request it. 372 If, on the other hand, the Valid-For timer is less than 12 hours (in 373 this example, which is before a typical client would ask for a 374 refresh, applications will be without a usable location URI until 375 the full refresh has been received. 377 3. DHCP Option Operation 379 The [RFC3046] RAIO can be utilized to provide the appropriate 380 indication to the DHCP Server where this DISCOVER or REQUEST message 381 came from, in order to supply the correct response. 383 Caution SHOULD always be used involving the creation of large 384 Options, meaning that this Option MAY need to be in its own INFORM, 385 OPTION or ACK message. 387 It is RECOMMENDED to avoid building URIs, with any parameters, 388 larger than what a single DHCP response can be. However, if a 389 message is larger than 255 bytes, concatenation is allowed, per RFC 390 3396 [RFC3396]. 392 Per [RFC2131], subsequent LocationURI Options, which are 393 non-concatenated, overwrite the previous value. 395 Location URIs MUST NOT reveal identity information of the user of 396 the device, since DHCP is a cleartext delivery protocol. For 397 example, creating a location URI such as 399 sips:34LKJH534663J54@example.com 401 is better than a location URI such as 403 sips:aliceisat123mainstatlantageorgiaus@example.com 405 The username portion of the first example URI provides no direct 406 identity information (in which 34LKJH534663J54 is considered to be a 407 random number in this example). 409 In the element of a PIDF-LO document, there is an 410 'entity' attribute that identifies what entity *this* presence 411 document (including the associated location) refers to. It is up to 412 the PIDF-LO generator, either Location Server or an application in 413 the endpoint, to insert the identity in the 'entity' attribute. 414 This can be seen in [RFC4119]. The considerations for populating 415 the entity attribute value in a PIDF-LO document are independent 416 from the considerations for avoiding exposing identification 417 information in the username part of a location URI. 419 This Option is used only for communications between a DHCP client 420 and a DHCP server. It can be solicited (requested) by the client, 421 or it can be pushed by the server without a request for it. DHCP 422 Options not understood MUST be ignored [RFC2131]. A DHCP server 423 supporting this Option might or might not have the location of a 424 client. If a server does not have a client's location, but needs to 425 provide this Location URI Option to a client (for whatever reason), 426 an LS is contacted. This server-to-LS transaction is not DHCP, 427 therefore it is out of scope of this document. Note that this 428 server-to-LS transaction could delay the DHCP messaging to the 429 client. If the server fails to have location before it transmits its 430 message to the client, location will not be part of that DHCP 431 message. Any timers involved here are a matter of local 432 configuration. 434 The dereference of a target's location URI would not involve DHCP, 435 but an application layer protocol, such as SIP or HTTP, therefore 436 dereferencing is out of scope of this document. 438 In the case of residential gateways being DHCP servers, they usually 439 perform as DHCP clients in a hierarchical fashion up into a service 440 provider's network DHCP server(s), or learn what information to 441 provide via DHCP to residential clients through a protocol, such as 442 PPP. In these cases, the location URI would likely indicate the 443 residence's civic address to all wired or wireless clients within 444 that residence. 446 3.1 Architectural Assumptions 448 The following assumptions have been made for use of this LocationURI 449 Option for a client to learn its location URI (in no particular 450 order): 452 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 453 to the dereferencing step is assumed to be out of scope of this 454 document. An example authorization policy is in [RFC6772]. 456 o The authorization security model vs. possession security model 457 discussion can be found in [RFC5606], describing what is expected 458 in each model of operation. It should be assumed that a location 459 URI attained using DHCP will operate under an possession model by 460 default. An authorization model can be instituted as a matter of 461 local policy. An authorization model means possessing the 462 location URI does not give that entity the right to view the 463 PIDF-LO of the target whose location is indicated in a presence 464 document. The dereference transaction will be challenged by the 465 Location Server only in an authorization model. The nature of 466 this challenge is out of scope of this document. 468 o This document does not prevent some environments from operating 469 in an authorization model, for example - in less tightly 470 controlled networks. The costs associated with authorization vs. 471 possession models are discussed in Section 3.3.2 of [RFC5606]. 473 3.2 Harmful URIs and URLs 475 There are, in fact, some types of URIs that are not good to receive, 476 due to security concerns. For example, any URLs that can have 477 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 478 pages that have scripts. Therefore, 480 o URIs received via this Option MUST NOT be automatically sent to a 481 general-browser to connect to a web page, because they could have 482 harmful scripts. 484 o This Option MUST NOT contain "data:" URLs, because they could 485 contain harmful scripts. 487 o Section 3.3 IANA registers acceptable location URI schemes (or 488 types) for use by this specification. Clients MUST reject URI 489 schemes not currently registered in IANA. 491 3.3 Valid Location URI Schemes or Types 493 This section specifies which URI types are acceptable as a location 494 URI scheme (or type) for this DHCP Option: 496 1. sip: 497 2. sips: 498 3. pres: 499 4. http: 500 5. https: 502 URIs using the "pres" scheme are dereferenced using the presence 503 event package for SIP [RFC3856], so they will reference a PIDF-LO 504 document when location is available. Responses to requests for URIs 505 with other schemes ("sip", "sips", "http", and "https") MUST have 506 MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS 507 URIs MAY refer to information with MIME type 'application/held+xml', 508 in order to support HELD dereferencing [RFC6753]. Clients can 509 indicate which MIME types they support using the "Accept" header 510 field in SIP [RFC3261] or HTTP [RFC2616]. 512 See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP. 514 It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442 515 [RFC6442] as guidance regarding which Location URI schemes to 516 provide in DHCP. That document discusses what a receiving entity 517 does when receiving a URI scheme that is not understood. Awareness 518 to the two URI types there is important for conveying location, if 519 SIP is used to convey a Location URI provided by DHCP. 521 4. IANA Considerations 523 4.1 The IPv4 Option number for the Location URI Option 525 This document IANA registers the Location URI IPv4 Option number XXX 526 (to be assigned by IANA once this document becomes an RFC). 528 4.2 The IPv6 Option-Code for the Location URI Option 530 This document IANA registers the Location URI IPv6 Option-Code XXX 531 (to be assigned by IANA once this document becomes an RFC). 533 4.3 The IPv4 Option number for the Valid-For Option 535 This document IANA registers the Valid-For IPv4 Option number XXX 536 (to be assigned by IANA once this document becomes an RFC). 538 4.4 The IPv6 Option-Code for the Valid-For Option 540 This document IANA registers the Valid-For IPv6 Option-Code XXX (to 541 be assigned by IANA once this document becomes an RFC). 543 5. Security Considerations 545 Where critical decisions might be based on the value of this 546 location URI option, DHCP authentication as defined in 547 "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host 548 Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used 549 to protect the integrity of the DHCP options. 551 A real concern with RFC 3118 or RFC 3315 is that neither is widely 552 deployed because each requires pre-shared keys to successfully work 553 (i.e., in the client and in the server). Most implementations do 554 not accommodate this. 556 DHCP, initially, is a broadcast request (a client looking for a 557 server), and a unicast response (answer from a server) type of 558 protocol. There is no privacy protection for DHCP messages, an 559 eavesdropper who can monitor the link between the DHCP server and 560 requesting client can discover the Location URI. 562 Once a client has a Location URI, it needs information on how the 563 location server will control access to dereference requests. A 564 client might treat a tightly access-controlled URI differently from 565 one that can be dereferenced by anyone on the Internet (i.e., one 566 following the "possession model"). Since the client does not know 567 what policy will be applied during this validity interval, clients 568 MUST handle location URIs as if they could be dereferenced by 569 anybody until they expire. For example, such open location URIs 570 should only be transmitted in encrypted channels. Nonetheless, 571 location servers SHOULD apply appropriate access control policies, 572 for example by limiting the number of queries that any given client 573 can make, or limiting access to users within an enterprise. 575 Extensions to this option, such as [ID-POLICY-URI] can provide 576 mechanisms for accessing and provisioning policy. Giving users 577 access to policy information will allow them to make more informed 578 decisions about how to use their location URIs. Allowing users to 579 provide policy information to the LS will enable them to tailor 580 access control policies to their needs (within the bounds of policy 581 that the LS will accept). 583 As to the concerns about the location URI itself, as stated in the 584 document (see Section 3), it MUST NOT have any user identifying 585 information in the URI user-part/string itself. The location URI 586 also needs to be hard to guess that it belongs to a specific user. 588 In some cases a DHCP server may be implemented across an 589 uncontrolled network. In those cases, it would be appropriate for a 590 network administrator to perform a threat analysis (see RFC 3552) 591 and take precautions as needed. 593 Link-layer confidentiality and integrity protection may also be 594 employed to reduce the risk of location disclosure and tampering. 596 6. Acknowledgements 598 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 599 Robert Sparks for their useful comments. And to Lisa Dusseault for 600 her concerns about the types of URIs that can cause harm. To 601 Richard Barnes for inspiring a more robust Security Considerations 602 section, and for offering the text to incorporate HTTP URIs. To 603 Hannes Tschofenig and Ted Hardie for riding me to comply with their 604 concerns, including a good scrubbing of the nearly final doc. 606 7. References 608 7.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 614 March 1997. 616 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 617 3046, January 2001. 619 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 620 Messages", RFC 3118, June 2001. 622 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. 623 Carney, "Dynamic Host Configuration Protocol for IPv6 624 (DHCPv6)", RFC 3315, July 2003 626 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 627 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 628 Session Initiation Protocol", RFC 3261, May 2002. 630 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 631 Host Configuration Protocol (DHCPv4)", RFC 3396, November 632 2002 634 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 635 Initiation Protocol (SIP)", RFC 3856, August 2004 637 [RFC3922] P. Saint-Andre, " Mapping the Extensible Messaging and 638 Presence Protocol (XMPP) to Common Presence and Instant 639 Messaging (CPIM)", RFC 3922, October 2004 641 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 642 Format", RFC 4119, December 2005 644 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 645 for the Session Initiation Protocol", RFC 6442, December 646 2011. 648 7.2. Informative References 650 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 651 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 652 Protocol - HTTP/1.1", RFC 2616, June 1999 654 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 655 "Geopriv Requirements", RFC 3693, February 2004 657 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, 658 "Dynamic Host Configuration Protocol Options for 659 Coordinate-Based Location Configuration Information", 660 RFC 6225, July 2011. 662 [RFC4776] H. Schulzrinne, "Dynamic Host Configuration Protocol 663 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 664 Information ", RFC 4776, November 2006 666 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 667 'retransmission-allowed' for SIP Location Conveyance", 668 August 2009 670 [RFC5808] R. Marshall, "Requirements for a Location-by-Reference 671 Mechanism", RFC 5808, May 2010 673 [RFC6753] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson, 674 M. Dawson, "A Location Dereferencing Protocol Using HELD", 675 "work in progress", October 2011 677 [RFC6772] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 678 Polk, "Geolocation Policy: A Document Format for Expressing 679 Privacy Preferences for Location Information", "work in 680 progress", October 2011 682 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 683 Configuration Extensions for Policy Management", "work in 684 progress", November 2011 686 Authors' Address 688 James Polk 689 3913 Treemont Circle 690 Colleyville, Texas 76034 691 USA 693 Email: jmpolk@cisco.com