idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 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 (July 28, 2010) is 5013 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: 'RFC3265' is defined on line 572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Downref: Normative reference to an Informational RFC: RFC 5808 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 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) July 28, 2010 4 Expires: January 28, 2011 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-08 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) of a client, which can be dereferenced in a 15 separate transaction by the client or an entity the client sends 16 this URI to. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 28, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4 60 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 4 61 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 62 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 5 63 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 6 64 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 65 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 66 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 7.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 1. Introduction 81 This document creates a Dynamic Host Configuration Protocol (DHCP) 82 Option for transmitting a client's geolocation Uniform Resource 83 Identifier (URI). The DHCP implementation of the client can then 84 make this location information available to upper layer protocols 85 for their usage. This location URI points a Location Server 86 [ID-LBYR-REQ] which has the geolocation of the client (through means 87 not defined in this document). In this scenario, the DHCP client 88 is a Geopriv Target (i.e., the entity whose geolocation is 89 associated by the location URI). 91 Applications using upper layer protocols within the Target can then 92 choose to deference this location URI and/or transmit the URI to 93 another entity as a means of conveying where the Target is located. 94 Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying 95 a location URI is also described in [ID-SIP-LOC]. Session Initiation 96 Protocol (SIP) is not the only protocol that can dereference a 97 location URI; there is also HTTP-Enabled Location Delivery (HELD) 98 [ID-HELD-DEREF]. 100 Having a location URI has advantages over having a PIDF-LO, 101 especially when a target's location changes. With a location URI, 102 when a target moves, the location URI does not change (at least 103 within the same domain). It can still be given out as the reference 104 to the Target's current location. The opposite is true if the 105 location is conveyed by value in a message. Once the Target moves, 106 the previously given location is no longer valid, and it the Target 107 wants to inform another entity about its location, it has to send 108 the PIDF-LO to the location recipient (again). 110 A Location Server (LS) stores the Target's location as a presence 111 document, called a Presence Information Date Format - Location 112 Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server 113 is the entity contacted during the act of dereferencing a Target's 114 location. If the dereferencing entity has permission, defined in 115 [ID-GEO-POL], the location of the target will be received. The LS 116 will grant permission to location inquires based on the rules 117 established by a Rule Holder [RFC3693]. The LS has the ability to 118 challenge any request for a target's location, thereby providing 119 additive security properties before location revelation. 121 A problem exists within existing RFCs that provide location to the 122 UA ([RFC3825] and [RFC4776]). These 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 LCI to endpoints might not 130 scale in mobile (residential or enterprise or municipal) networks in 131 which the client is moving through more than one network attachment 132 point, perhaps as a person walks or drives with their client down a 133 neighborhood street or apartment complex or a shopping center or 134 through a municipality (that has IP connectivity as a service). 136 If the client were provided a location URI reference to retain and 137 hand out when it wants or needs to convey its location (in a 138 protocol other than DHCP), a location URI that would not change as 139 the client's location changes (within a domain), scaling issues 140 would be significantly reduced to needing an update of the location 141 URI only when a client changes administrative domains - which is 142 much less often. This delivery of an indirect location has the 143 added benefit of not using up valuable or limited bandwidth to the 144 client with the constant updates. It also relieves the client from 145 having to determine when it has moved far enough to consider asking 146 for a refresh of its location. 148 In enterprise networks, if a known location is assigned to each 149 individual Ethernet port in the network, a device that attaches to 150 the network a wall-jack (directly associated with a specific 151 Ethernet Switch port) will be associated with a known location via a 152 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 153 [RFC3046]. This assumes wall-jacks have an updated wiremap 154 database. RFC 3825 and RFC 4776 would return an LCI value of 155 location. This document specifies how a location URI is returned 156 using DHCP. Behind the DHCP server, in the backend of the network, 157 via the (logical entity of an) LS has a PIDF-LO to be dereferenced 158 with a location URI. 160 If local configuration has the requirement of only assigning unique 161 location URIs to each client, then unique location URIs will be 162 given out, though they will all have the same location at the 163 record, relieving the backend Sighter or LS from individually 164 maintaining each location independently. 166 This Option can be useful in IEEE 802.16e connected endpoints or IP 167 cellular endpoints. The location URI Option can be configured as a 168 client if there is a router, such as a residential home gateway, 169 with the ability to communicate to downstream endpoints as a server. 171 How an LS responds to a dereference request can vary, and a policy 172 established by a Ruleholder [RFC3693] for a Location Target as to 173 what type of challenge(s) is to be used, how strong a challenge is 174 used or how precise the location information is given to a 175 Location Recipient (LR). This document does not provide mechanisms 176 for the LS to tell the client about policies or for the client to 177 specify a policy for the LS. While an LS should apply an appropriate 178 access-control policy, clients must assume that the LS will provide 179 location in response to any request (following the possession model 180 [RFC5808]). For further discussion of privacy, see the Security 181 Considerations. 183 This document IANA registers the new IPv4 and IPv6 DHC Options for a 184 location URI. 186 2. Format of the DHCP LuriElement Option 188 2.1 Overall Format of LuriElement Option in IPv4 190 The LuriElement Option format for IPv4 is as follows: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Code XXX | Length=XX | Ver | Resv | . 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 197 . LuriElements... ... 198 . (see Section 2.3 for details) ... . 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1. IPv4 Fields for this LuriElement Option 203 Code XXX: The code for this DHCPv4 option (IANA assigned). 205 Length=XX: The length of this option, counted in bytes - not 206 counting the Code and Length bytes. This is a variable 207 length Option, therefore the length value will change 208 based on the length of the URI within the Option. 210 Ver: (4 bits) The version of this Option. This document 211 defines version 1 of this Option. 213 Resv: (4 bits) reserved for future use. 215 LuriElement: see Section 2.3 for details 217 2.2 Overall Format of LuriElement Option in IPv6 219 The LuriElement Option format for IPv6 is as follows: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | option-code | option-len | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Ver | Resv | . 227 +---------------+ . 228 . LuriElements... . 229 . (see Section 2.3 for details) . 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2. IPv6 fields of this LuriElement 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 Code and Length bytes. This is a variable 238 length Option, therefore the length value will change 239 based on the shape within the Option. 241 Ver: See above (Section 2.1). This will specify version 1. 243 Resv: See above (Section 2.1). 245 LuriElement: see below (Section 2.3 for details). 247 2.3 LuriElement Format for both IPv4 and IPv6 249 The LuriElement, in both DHCPv4 and DHCPv6, have the following 250 format: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | LuriType | LuriLength | LuriValue ... 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Figure 3. LuriElement Format for both IPv4 and IPv6 260 LuriType: A one-byte identifier of the data location value. 262 LuriLength: The length, in bytes, of the LuriValue, not including 263 the LuriLength field itself, up to a maximum of 255 264 bytes. 266 LuriValue: The LuriElement value, as described in detail below. 267 The LuriValue is always in UTP-8. 269 The LuriTypes this document defines (and IANA registers) for a point 270 are: 272 LuriType=1 Location URI - This is the URI pointing at the 273 location record where the PIDF-LO resides which 274 indicates the location of the Location Target. 276 LuriType=2 Valid-For - The time, in seconds, this URI is to be 277 considered Valid for dereferencing. The timer 278 associated with this LuriType starts upon receipt of 279 this Option. 281 The LuriType=2 (Valid-For) indicates how long, in seconds, the 282 client is to consider this LuriType=1 (location URI) valid 283 before performing a refresh of this Option, with a refreshed 284 LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done 285 the normal DHCP refresh rate, or necessitated by this timer, perhaps 286 with the client only requesting this Option be refreshed. 288 If the LuriType=2 (Valid-For) timer is received (solicited or 289 unsolicited), it is RECOMMENDED that the client refresh the Location 290 URI when the (Valid-For) counter value has reaches the halfway 291 point. For example, if 16000 was the initial value of the 292 LuriType=2 (Valid-For) value, when 8000 seconds have passed, the 293 Option SHOULD be refreshed. 295 The LuriType=2 (Valid-For) is not mandated for use by this document. 296 However, its presence MUST NOT cause any error in handling the 297 location URI (i.e., if not understood, it MUST be ignored). 299 This Option format is highly extensible. Additional LuriType types 300 created MUST be done so through IANA registration with peer review 301 and an RFC. 303 3. DHC Option Operation 305 The [RFC3046] RAIO MUST be utilized to provide the appropriate 306 indication to the DHCP Server where this DISCOVER or REQUEST message 307 came from, in order to supply the correct response. That said, this 308 Option SHOULD NOT be in a DISCOVER message, because there is zero 309 knowledge by the client of which Server will answer. 311 Caution SHOULD always be used involving the creation of large 312 Options, meaning that this Option MAY need to be in its own INFORM, 313 OPTION or ACK message. 315 It is RECOMMENDED to avoid building URIs, with any parameters, 316 larger than what a single DHCP response can be. However, if a 317 message is larger than 255 bytes, concatenation is allowed, per RFC 318 3396 [RFC3396]. 320 Per [RFC2131], subsequent LuriElement Options, which are 321 non-concatenated, overwrite the previous value. 323 Location URIs MUST NOT reveal identity information of the user of 324 the device, since DHCP is a cleartext delivery protocol. For 325 example, location URIs such as 327 sips:34LKJH534663J54@example.com 329 are to be done, providing no identity information, rather than a 330 location URI such as this 332 sips:aliceisat123mainstalanta@example.com 334 In the element of a PIDF-LO document, there is an 335 'entity' attribute that identities what entity *this* document 336 (including the associated location) refers to. It is up to the 337 PIDF-LO generator, either Location Server or an application in the 338 endpoint, to insert the identity in the 'entity' attribute. This 339 can be seen in [RFC4119]. The entity= discussion is orthogonal to 340 the identification information contained within the location URI. 342 This Option is used only for communications between a DHCP client 343 and a DHCP server. It can be solicited (requested) by the client, 344 or it can be pushed by the server without a request for it. DHCP 345 Options not understood are ignored. A DHCP server supporting this 346 Option might or might not have the location of a client. If a 347 server does not have a client's location, but needs to provide this 348 Location URI Option to a client (for whatever reason), an LS is 349 contacted. This server-to-LS transaction is not DHCP, therefore it 350 is out of scope of this document. 352 The deference of a target's location URI would not involve DHCP, but 353 an application layer protocol, such as SIP or HTTP, therefore 354 dereferencing is out of scope of this document. 356 In the case of residential gateways being DHCP servers, they usually 357 perform as DHCP clients in a hierarchical fashion up into a service 358 provider's network DHCP server(s), or learn what information to 359 provide via DHCP to residential clients through a protocol, such as 360 PPP. In these cases, the location URI would likely indicate the 361 residence's civic address to all wired or wireless clients within 362 that residence. 364 3.1 Architectural Assumptions 366 The following assumptions have been made for use of this LuriElement 367 Option for a client to learn its location URI (in no particular 368 order): 370 o Any user control (what [RFC3693] calls a 'Ruleholder') for access 371 to the dereferencing step is assumed to be out of scope of this 372 document. An example authorization policy is in [ID-GEO-POL]. 374 o The authorization vs. possession security model can be found in 375 [ID-LBYR-REQ], describing what is expected in each model of 376 operation. It should be assumed that a location URI attained 377 using DHCP will operate under an authorization model. This means 378 possessing the location URI does not give that entity the right 379 to view the PIDF-LO of the target whose location is indicated in 380 a presence document. The dereference transaction will be, in 381 many environments, challenged by the Location Server. The nature 382 of this challenge is out of scope of this document. 384 o This document does not prevent some environments from operating 385 in a possession model, for example - tightly controlled 386 enterprise networks, but this operation SHOULD NOT be assumed to 387 exist as a matter of local policy. The costs associated with 388 authorization vs. possession models are discussed in Section 389 3.3.2 of [RFC5606]. 391 3.2 Harmful URIs and URLs 393 There are, in fact, some types of URIs that are not good to receive, 394 due to security concerns. For example, any URLs that can have 395 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 396 pages that have scripts. Therefore, 398 o URIs received via this Option SHOULD NOT be sent to a 399 general-browser to connect to a web page, because they could have 400 harmful scripts. 402 o This Option SHOULD NOT contain "data:" URLs, because they could 403 contain harmful scripts. 405 Instead of listing all the types of URIs and URLs that can be 406 misused or potentially have harmful affects, Section 3.3 IANA 407 registers acceptable location URI schemes (or types). 409 3.3 Valid Location URI Schemes or Types 411 This section specifies which URI types are acceptable as a location 412 URI scheme (or type) for this DHCP Option: 414 1. sip: 415 2. sips: 416 3. pres: 417 4. http: 418 5. https: 420 URIs using the "pres" scheme are dereferenced using the presence 421 event package for SIP [RFC3856], so they will reference a PIDF-LO 422 document when location is available. Responses to requests for URIs 423 with other schemes ("sip", "sips", "http", and "https") MUST have 424 MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS 425 URIs MAY refer to information with MIME type 'application/held+xml', 426 in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can 427 indicate which MIME types they support using the "Accept" header 428 field in SIP [RFC3261] or HTTP [RFC2616]. 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: 459 4. http: 460 5. https: 462 Any additional location URI types to be defined for use via 463 this DHC Option need to be created and IANA registered with peer 464 review and an RFC. 466 4.5 IANA Considerations for LuriTypes 468 IANA is requested to create a new registry for acceptable location 469 types defined in Section 3.2 of this document, arranged similar to 470 this: 472 +------------+----------------------------------------+-----------+ 473 | LuriType | Name | Reference | 474 +------------+----------------------------------------+-----------+ 475 | 1 | Location URI | RFC XXXX* | 476 | 2 | Valid-For | RFC XXXX* | 477 +------------+----------------------------------------+-----------+ 479 * RFC XXXX is to be replaced with this document's RFC-Editor RFC 480 number. 482 Additions to this list require a standards track RFC. 484 5. Security Considerations 486 Where critical decisions might be based on the value of this 487 location URI option, DHCP authentication in [RFC3118] SHOULD be used 488 to protect the integrity of the DHCP options. 490 A real concern with RFC 3118 it is that not widely deployed because 491 it requires pre-shared keys to successfully work (i.e., in the 492 client and in the server). Most implementations do not 493 accommodate this. 495 DHCP, initially, is a broadcast request (a client looking for a 496 server), and a unicast response (answer from a server) type of 497 protocol. It does not provide security at the network layer. 498 Instead, it relies on lower-layer security mechanisms. In today's 499 infrastructures, DHCP will be primarily used over a wired, switched 500 Ethernet network, requiring physical access to within a wire to gain 501 access. Further, within an 802.11 wireless network, the 802.11 502 specs offer layer 2 security mechanisms to prevent a location URI 503 from being learned by an unauthorized entity. 505 Once a client has a URI, it needs information on how the location 506 server will control access to dereference requests. A client might 507 treat a tightly access-controlled URI differently from one that can 508 be dereferenced by anyone on the Internet (i.e., one following the 509 "possession model"). With the LuriTypes defined in this document, 510 the DHCP option for delivering location URIs can only tell the user 511 how long the URI will be valid. Since the client does not know what 512 policy will be applied during this validity interval, clients MUST 513 handle location URIs as if they could be dereferenced by anybody 514 until they expire. For example, such open location URIs should only 515 be transmitted in encrypted channels. Nonetheless, location servers 516 SHOULD apply appropriate access control policies, for example by 517 limiting the number of queries that any given client can make, or 518 limiting access to users within an enterprise. 520 Extensions to this option, such as [ID-POLICY-URI] can provide 521 mechanisms for accessing and provisioning policy. Giving users 522 access to policy information will allow them to make more informed 523 decisions about how to use their location URIs. Allowing users to 524 provide policy information to the LS will enable them to tailor 525 access control policies to their needs (within the bounds of policy 526 that the LS will accept). 528 Penetrating an LS is supposed to be hard, and hopefully vendors that 529 implement an LS accomplish this goal. 531 As to the concerns about the location URI itself, as stated in the 532 document here (in Section 3), it MUST NOT have any user identifying 533 information in the URI user-part/string itself. The location URI 534 also needs to be hard to guess that it belongs to a specific user. 536 When implementing a DHC server that will serve clients across an 537 uncontrolled network, one should consider the potential security 538 risks therein. 540 6. Acknowledgements 542 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 543 Robert Sparks for their useful comments. And to Lisa Dusseault for 544 her concerns about the types of URIs that can cause harm. To 545 Richard Barnes for inspiring a more robust Security Considerations 546 section, and for offering the text to incorporate HTTP URIs. To 547 Hannes Tschofenig and Ted Hardie for riding me to comply with their 548 concerns, including a good scrubbing of the nearly final doc. To 549 Richard Barnes for his guidance with respect to the model used by 550 this document and fine tuning the security considerations section. 552 7. References 554 7.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 560 3046, January 2001. 562 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 563 March 1997. 565 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 566 Messages", RFC 3118, June 2001. 568 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 569 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 570 Session Initiation Protocol", RFC 3261, May 2002. 572 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 573 Event Notification", RFC 3265, June 2002. 575 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 576 Host Configuration Protocol (DHCPv4)", RFC 3396, November 577 2002 579 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 580 Format", RFC 4119, December 2005 582 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 583 Initiation Protocol (SIP)", RFC 3856, August 2004 585 [RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference 586 Mechanism", RFC 5808, May 2010 588 7.2. Informative References 590 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in 591 progress", Feb 2010 593 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 594 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 595 HELD", "work in progress", January 2010 597 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 598 Configuration Protocol Option for Coordinate-based Location 599 Configuration Information", RFC 3825, July 2004 601 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 602 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 603 Information ", RFC 4776, November 2006 605 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 606 Mechanism", "work in progress", November 2009 608 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 609 "Geopriv Requirements", RFC 3693, February 2004 611 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 612 Polk, "Geolocation Policy: A Document Format for Expressing 613 Privacy Preferences for Location Information", "work in 614 progress", July 2009 616 [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of 617 'retransmission-allowed' for SIP Location Conveyance", 618 August 2009 620 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 621 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 622 Protocol - HTTP/1.1", RFC 2616, June 1999 624 [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location 625 Configuration Extensions for Policy Management", "work in 626 progress", May 2010 628 Authors' Address 630 James Polk 631 3913 Treemont Circle 632 Colleyville, Texas 76034 633 USA 635 Email: jmpolk@cisco.com