idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Unrecognized Status in 'Intended status: Standards Track (PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sept 14, 2009) is 5611 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3261' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 556, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Geopriv WG James Polk 2 Internet-Draft Cisco Systems 3 Intended status: Standards Track (PS) Sept 14, 2009 4 Expires: March 14, 2010 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-06 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. This document may contain 14 material from IETF Documents or IETF Contributions published or made 15 publicly available before November 10, 2008. The person(s) 16 controlling the copyright in some of this material may not have 17 granted the IETF Trust the right to allow modifications of such 18 material outside the IETF Standards Process. Without obtaining an 19 adequate license from the person(s) controlling the copyright in 20 such materials, this document may not be modified outside the IETF 21 Standards Process, and derivative works of it may not be created 22 outside the IETF Standards Process, except to format it for 23 publication as an RFC or to translate it into languages other than 24 English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 14, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your 53 rights and restrictions with respect to this document. 55 Legal 57 This documents and the information contained therein are provided on 58 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 59 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 60 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 61 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 62 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 63 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 64 FOR A PARTICULAR PURPOSE. 66 Abstract 68 This document creates a Dynamic Host Configuration Protocol (DHCP) 69 Option for transmitting a client's geolocation Uniform Resource 70 Identifier (URI) of a client, which can be dereferenced in a 71 separate transaction by the client or an entity the client sends 72 this URI to. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4 78 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 5 79 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 80 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 6 81 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7 82 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 83 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9 84 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 90 7.2. Informative References . . . . . . . . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 1. Introduction 99 This document creates a Dynamic Host Configuration Protocol (DHCP) 100 Option for transmitting a client's geolocation Uniform Resource 101 Identifier (URI). The DHCP implementation of the client can then 102 make this location information available to upper layer protocols 103 for their usage. This location URI points a Location Server 104 [ID-LBYR-REQ] which has the geolocation of the client (through means 105 not defined in this document). In this scenario, the DHCP client 106 is a Geopriv Target (i.e., the entity whose geolocation is 107 associated by the location URI). 109 Applications using upper layer protocols within the Target can then 110 choose to deference this location URI and/or transmit the URI to 111 another entity as a means of conveying where the Target is located. 112 Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying 113 a location URI is also described in [ID-SIP-LOC]. Session Initiation 114 Protocol (SIP) is not the only protocol that can dereference a 115 location URI; there is also HTTP-Enabled Location Delivery (HELD) 116 [ID-HELD-DEREF]. 118 Having a location URI has advantages over having a PIDF-LO, 119 especially when a target's location changes. With a location URI, 120 when a target moves, the location URI does not change (at least 121 within the same domain). It can still be given out as the reference 122 to the Target's current location. The opposite is true if the 123 location is conveyed by value in a message. Once the Target moves, 124 the previously given location is no longer valid, and it the Target 125 wants to inform another entity about its location, it has to send 126 the PIDF-LO to the location recipient (again). 128 A Location Server (LS) stores the Target's location as a presence 129 document, called a Presence Information Date Format - Location 130 Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server 131 is the entity contacted during the act of dereferencing a Target's 132 location. If the dereferencing entity has permission, defined in 133 [ID-GEO-POL], the location of the target will be received. The LS 134 will grant permission to location inquires based on the rules 135 established by a Rule Holder [RFC3693]. The LS has the ability to 136 challenge any request for a target's location, thereby providing 137 additive security properties before location revelation. 139 A problem exists within existing RFCs that provide location to the 140 UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation 141 values require an update of the entire location information (LI) 142 every time a client moves. Not all clients will move frequently, 143 but some will. Refreshing location values every time a client moves 144 does not scale in certain networks/environments, such as IP-based 145 cellular networks, enterprise networks or service provider networks 146 with mobile endpoints. An 802.11 based access network is one 147 example of this. Constantly updating LCI to endpoints might not 148 scale in mobile (residential or enterprise or municipal) networks in 149 which the client is moving through more than one network attachment 150 point, perhaps as a person walks or drives with their client down a 151 neighborhood street or apartment complex or a shopping center or 152 through a municipality (that has IP connectivity as a service). 154 If the client were provided a location URI reference to retain and 155 hand out when it wants or needs to convey its location (in a 156 protocol other than DHCP), a location URI that would not change as 157 the client's location changes (within a domain), scaling issues 158 would be significantly reduced to needing an update of the location 159 URI only when a client changes administrative domains - which is 160 much less often. This delivery of an indirect location has the 161 added benefit of not using up valuable or limited bandwidth to the 162 client with the constant updates. It also relieves the client from 163 having to determine when it has moved far enough to consider asking 164 for a refresh of its location. 166 In enterprise networks, if a known location is assigned to each 167 individual Ethernet port in the network, a device that attaches to 168 the network a wall-jack (directly associated with a specific 169 Ethernet Switch port) will be associated with a known location via a 170 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 171 [RFC3046]. This assumes wall-jacks have an updated wiremap 172 database. RFC 3825 and RFC 4776 would return an LCI value of 173 location. This document specifies how a location URI is returned 174 using DHCP. Behind the DHCP server, in the backend of the network, 175 via the (logical entity of an) LS has a PIDF-LO to be dereferenced 176 with a location URI. 178 If local configuration has the requirement of only assigning unique 179 location URIs to each client, then unique location URIs will be 180 given out, though they will all have the same location at the 181 record, relieving the backend Sighter or LS from individually 182 maintaining each location independently. 184 This Option can be useful in IEEE 802.16e connected endpoints or IP 185 cellular endpoints. The location URI Option can be configured as a 186 client if there is a router, such as a residential home gateway, 187 with the ability to communicate to downstream endpoints as a server. 189 How an LS responds to a dereference request can vary, and a policy 190 established by a Ruleholder [RFC3693] for a Location Target as to 191 what type of challenge(s) is to be used, how strong a challenge is 192 used or how precise the location information is given to a 193 Location Recipient (LR). All of this is outside the scope of this 194 document (since this will not be accomplished using DHCP). 196 This document IANA registers the new IPv4 and IPv6 DHC Options for a 197 location URI. 199 2. Format of the DHCP LuriElement Option 200 2.1 Overall Format of LuriElement Option in IPv4 202 The LuriElement Option format for IPv4 is as follows: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Code XXX | Length=XX | Ver | Resv | . 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 209 . LuriElements... ... 210 . (see Section 2.3 for details) ... . 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 1. IPv4 Fields for this LuriElement Option 215 Code XXX: The code for this DHCPv4 option (IANA assigned). 217 Length=XX: The length of this option, counted in bytes - not 218 counting the Code and Length bytes. This is a variable 219 length Option, therefore the length value will change 220 based on the length of the URI within the Option. 222 Ver: (4 bits) The version of this Option. This document 223 defines version 1 of this Option. 225 Resv: (4 bits) reserved for future use. 227 LuriElement: see Section 2.3 for details 229 2.2 Overall Format of LuriElement Option in IPv6 231 The LuriElement Option format for IPv6 is as follows: 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | option-code | option-len | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Ver | Resv | . 239 +---------------+ . 240 . LuriElements... . 241 . (see Section 2.3 for details) . 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2. IPv6 fields of this LuriElement Option 246 option-code: The code for this DHCPv6 option (IANA assigned). 248 option-len: The length of this option, counted in bytes - not 249 counting the Code and Length bytes. This is a variable 250 length Option, therefore the length value will change 251 based on the shape within the Option. 253 Ver: See above (Section 2.1). This will specify version 1. 255 Resv: See above (Section 2.1). 257 LuriElement: see below (Section 2.3 for details). 259 2.3 LuriElement Format for both IPv4 and IPv6 261 The LuriElement, in both DHCPv4 and DHCPv6, have the following 262 format: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | LuriType | LuriLength | LuriValue ... 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3. LuriElement Format for both IPv4 and IPv6 272 LuriType: A one-byte identifier of the data location value. 274 LuriLength: The length, in bytes, of the LuriValue, not including 275 the LuriLength field itself, up to a maximum of 255 276 bytes. 278 LuriValue: The LuriElement value, as described in detail below. 279 The LuriValue is always in UTP-8. 281 The LuriTypes this document defines (and IANA registers) for a point 282 are: 284 LuriType=1 Location URI - This is the URI pointing at the 285 location record where the PIDF-LO resides which 286 indicates the location of the Location Target. 288 LuriType=2 Valid-For - The time, in seconds, this URI is to be 289 considered Valid for dereferencing. The timer 290 associated with this LuriType starts upon receipt of 291 this Option. 293 The LuriType=2 (Valid-For) indicates how long, in seconds, the 294 client is to consider this LuriType=1 (location URI) valid 295 before performing a refresh of this Option, with a refreshed 296 LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done 297 the normal DHCP refresh rate, or necessitated by this timer, perhaps 298 with the client only requesting this Option be refreshed. 300 If the LuriType=2 (Valid-For) timer is received (solicited or 301 unsolicited), it is RECOMMENDED that the client refresh the Location 302 URI when the (Valid-For) counter value has reaches the halfway 303 point. For example, if 16000 was the initial value of the 304 LuriType=2 (Valid-For) value, when 8000 seconds have passed, the 305 Option SHOULD be refreshed. 307 The LuriType=2 (Valid-For) is not mandated for use by this document. 308 However, its presence MUST NOT cause any error in handling the 309 location URI (i.e., if not understood, it MUST be ignored). 311 This Option format is highly extensible. Additional LuriType types 312 created MUST be done so through IANA registration with peer review 313 and an RFC. 315 3. DHC Option Operation 317 The [RFC3046] RAIO MUST be utilized to provide the appropriate 318 indication to the DHCP Server where this DISCOVER or REQUEST message 319 came from, in order to supply the correct response. That said, this 320 Option SHOULD NOT be in a DISCOVER message, because there is zero 321 knowledge by the client of which Server will answer. 323 Caution SHOULD always be used involving the creation of large 324 Options, meaning that this Option MAY need to be in its own INFORM, 325 OPTION or ACK message. 327 It is RECOMMENDED to avoid building URIs, with any parameters, 328 larger than what a single DHCP response can be. However, if a 329 message is larger than 255 bytes, concatenation is allowed, per RFC 330 3396 [RFC3396]. 332 Per [RFC2131], subsequent LuriElement Options, which are 333 non-concatenated, overwrite the previous value. 335 Location URIs MUST NOT reveal identity information of the user of 336 the device, since DHCP is a cleartext delivery protocol. For 337 example, location URIs such as 339 sips:34LKJH534663J54@example.com 341 are to be done, providing no identity information, rather than a 342 location URI such as this 344 sips:aliceisat123mainstalanta@example.com 346 In the element of a PIDF-LO document, there is an 347 'entity' attribute that identities what entity *this* document 348 (including the associated location) refers to. It is up to the 349 PIDF-LO generator, either Location Server or an application in the 350 endpoint, to insert the identity in the 'entity' attribute. This 351 can be seen in [RFC4119]. The entity= discussion is orthogonal to 352 the identification information contained within the location URI. 354 This Option is used only for communications between a DHCP client 355 and a DHCP server. It can be solicited (requested) by the client, 356 or it can be pushed by the server without a request for it. DHCP 357 Options not understood are ignored. A DHCP server supporting this 358 Option might or might not have the location of a client. If a 359 server does not have a client's location, but needs to provide this 360 Location URI Option to a client (for whatever reason), an LS is 361 contacted. This server-to-LS transaction is not DHCP, therefore it 362 is out of scope of this document. 364 The deference of a target's location URI would not involve DHCP, but 365 an application layer protocol, such as SIP or HTTP, therefore 366 dereferencing is out of scope of this document. 368 In the case of residential gateways being DHCP servers, they usually 369 perform as DHCP clients in a hierarchical fashion up into a service 370 provider's network DHCP server(s), or learn what information to 371 provide via DHCP to residential clients through a protocol, such as 372 PPP. In these cases, the location URI would likely indicate the 373 residence's civic address to all wired or wireless clients within 374 that residence. 376 3.1 Architectural Assumptions 378 The following assumptions have been made for use of this LuriElement 379 Option for a client to learn its location URI (in no particular 380 order): 382 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 383 to the dereferencing step is assumed to be out of scope of this 384 document. An example authorization policy is in [ID-GEO-POL]. 386 o The authorization vs. possession security model can be found in 387 [ID-LBYR-REQ], describing what is expected in each model of 388 operation. It should be assumed that a location URI attained 389 using DHCP will operate under an authorization model. This means 390 possessing the location URI does not give that entity the right 391 to view the PIDF-LO of the target whose location is indicated in 392 a presence document. The dereference transaction will be, in 393 many environments, challenged by the Location Server. The nature 394 of this challenge is out of scope of this document. 396 o This document does not prevent some environments from operating 397 in a possession model, for example - tightly controlled 398 enterprise networks, but this operation SHOULD NOT be assumed to 399 exist as a matter of local policy. The costs associated with 400 authorization vs. possession models are discussed in Section 401 3.3.2 of [ID-GEO-RA]. 403 3.2 Harmful URIs and URLs 405 There are, in fact, some types of URIs that are not good to receive, 406 due to security concerns. For example, any URLs that can have 407 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 408 pages that have scripts. Therefore, 410 o URIs received via this Option SHOULD NOT be sent to a 411 general-browser to connect to a web page, because they could have 412 harmful scripts. 414 o This Option SHOULD NOT contain "data:" URLs, because they could 415 contain harmful scripts. 417 Instead of listing all the types of URIs and URLs that can be 418 misused or potentially have harmful affects, Section 3.3 IANA 419 registers acceptable location URI schemes (or types). 421 3.3 Valid Location URI Schemes or Types 423 This section specifies which URI types are acceptable as a location 424 URI scheme (or type) for this DHCP Option: 426 1. sip: 427 2. sips: 428 3. pres: 430 These location URI types are IANA registered in Section 4.2 of this 431 document. 433 4. IANA Considerations 435 4.1 The IPv4 Option number for this Option 437 This document IANA registers this IPv4 Option number XXX (to be 438 assigned by IANA once this document becomes an RFC). 440 4.2 The IPv6 Option-Code for this Option 442 This document IANA registers this IPv6 Option-Code XXX (to be 443 assigned by IANA once this document becomes an RFC). 445 4.3 The Version number for this Option 447 This document IANA registers the version number 1 of this Option. 449 4.4 IANA Considerations for Acceptable Location URI Types 451 IANA is requested to create a new registry for acceptable location 452 URI types. 454 The following 3 URI types are registered by this document: 456 1. sip: 457 2. sips: 458 3. pres: 460 Any additional location URI types to be defined for use via 461 this DHC Option need to be created and IANA registered with peer 462 review and an RFC. 464 4.5 IANA Considerations for LuriTypes 466 IANA is requested to create a new registry for acceptable location 467 types defined in Section 3.2 of this document, arranged similar to 468 this: 470 +------------+----------------------------------------+-----------+ 471 | LuriType | Name | Reference | 472 +------------+----------------------------------------+-----------+ 473 | 1 | Location URI | RFC XXXX* | 474 | 2 | Valid-For | RFC XXXX* | 475 +------------+----------------------------------------+-----------+ 477 * RFC XXXX is to be replaced with this document's RFC-Editor RFC 478 number. 480 Additions to this list require a standards track RFC. 482 5. Security Considerations 484 Where critical decisions might be based on the value of this 485 location URI option, DHCP authentication in [RFC3118] SHOULD be used 486 to protect the integrity of the DHCP options. 488 A real concern with RFC 3118 it is that not widely deployed because 489 it requires pre-shared keys to successfully work (i.e., in the 490 client and in the server). Most implementations do not 491 accommodate this. 493 DHCP, initially, is a broadcast request (a client looking for a 494 server), and a unicast response (answer from a server) type of 495 protocol. It is not secure in a practical sense. In today's 496 infrastructures, DHCP will be primarily used over a wired, switched 497 Ethernet network, requiring physical access to within a wire to gain 498 access. Further, within an 802.11 wireless network, the 802.11 499 specs offer layer 2 security mechanisms to prevent a location URI 500 from being learned by an unauthorized entity. 502 That said, having the location URI does not mean an unauthorized 503 entity has the location of a client. The location URI still needs 504 to be dereferenced to learn the location of the client. This 505 dereferencing function, which is not done using DHCP, is done by 506 requesting the location record at a Location Server, which can 507 challenge each request it receives based on the policy provided by 508 the Ruleholder. The Ruleholder, as defined in RFC 3693, configures 509 the authentication and authorization policies for the location 510 revelation of a Target. This includes giving out more or less 511 precise location information in a response, therefore it can answer 512 a bad-hat, but not allow it from learning exactly where a client is. 514 Penetrating an LS is supposed to be hard, and hopefully vendors that 515 implement an LS accomplish this goal. 517 As to the concerns about the location URI itself, as stated in the 518 document here (in Section 3), it MUST NOT have any user identifying 519 information in the URI user-part/string itself. The location URI 520 also needs to be hard to guess that it belongs to a specific user. 522 When implementing a DHC server that will serve clients across an 523 uncontrolled network, one should consider the potential security 524 risks therein. 526 6. Acknowledgements 528 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 529 Robert Sparks for their useful comments. And to Lisa Dusseault for 530 her concerns about the types of URIs that can cause harm. To 531 Richard Barnes for inspiring a more robust Security Considerations 532 section. To Hannes Tschofenig and Ted Hardie for riding me to 533 comply with their concerns, including a good scrubbing of the nearly 534 final doc. 536 7. References 538 7.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 544 3046, January 2001. 546 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 547 March 1997. 549 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 550 Messages", RFC 3118, June 2001. 552 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 553 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 554 Session Initiation Protocol", RFC 3261, May 2002. 556 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 557 Event Notification", RFC 3265, June 2002. 559 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 560 Host Configuration Protocol (DHCPv4)", RFC 3396, November 561 2002 563 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 564 Format", RFC 4119, December 2005 566 7.2. Informative References 568 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in 569 progress", July 2009 571 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 572 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 573 HELD", "work in progress", July 2009 575 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 576 Configuration Protocol Option for Coordinate-based Location 577 Configuration Information", RFC 3825, July 2004 579 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 580 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 581 Information ", RFC 4776, November 2006 583 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 584 Mechanism", "work in progress", Feb 2009 586 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 587 "Geopriv Requirements", RFC 3693, February 2004 589 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 590 Polk, "Geolocation Policy: A Document Format for Expressing 591 Privacy Preferences for Location Information", "work in 592 progress", Feb 2009 594 [ID-GEO-RA] J. Peterson, T. Hardie, J. Morris, " Implications of 595 'retransmission-allowed' for SIP Location Conveyance", 596 "work in progress", March 2009 598 Authors' Address 600 James Polk 601 3913 Treemont Circle 602 Colleyville, Texas 76034 603 USA 605 Email: jmpolk@cisco.com