idnits 2.17.1 draft-ietf-geopriv-dhcp-lbyr-uri-option-04.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 (March 9, 2009) is 5526 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 575, 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 (~~), 4 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) March 9, 2009 4 Expires: September 9, 2009 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-04 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 September 9, 2009. 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 the downloading of a Uniform Resource Identifier (URI) 70 pointing to the geolocation record of an endpoint. This URI, called 71 a Location-by-Reference (LbyR), points to a record on a location 72 server which tracks the geolocation of the endpoint. Once 73 downloaded by an endpoint, this LbyR can be forwarded to another 74 entity, to be dereferenced if this entity wants to learn the 75 geolocation of the sender endpoint. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Format of the DHCP LbyrElement Option . . . . . . . . . . . . 5 81 2.1. Overall Format of LbyrElement Option in IPv4 . . . . . 5 82 2.2. Overall Format of LbyrElement Option in IPv6 . . . . . 6 83 2.3. LbyrElement Format for both IPv4 and IPv6 . . . . . . . 6 84 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7 85 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 9 86 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9 87 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 7.2. Informative References . . . . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 1. Introduction 102 This document creates a Dynamic Host Configuration Protocol (DHCP) 103 Option for the downloading of a Uniform Resource Identifier (URI) 104 pointing to the geolocation record of an endpoint. A client, for 105 example, can be a Session Initiation Protocol (SIP) User Agent (UA) 106 [RFC3261] (i.e., a Phone). This URI, called a 107 Location-by-Reference (LbyR), points to a record on a location 108 server [ID-LBYR-REQ] which tracks the geolocation of the endpoint 109 (through means not defined in this document). The LbyR record 110 stores the Geolocation of a Location Target, where the location of 111 the Location Target changing at the record, but not in the URI used 112 to access the record. Once downloaded by an endpoint (the target in 113 this case), this LbyR can be forwarded to another entity, for 114 example, using SIP as defined in [ID-SIP-LOC], to be dereferenced if 115 this second entity wants to learn the geolocation of the Location 116 Target. 118 The act of dereferencing location is explained in [ID-SIP-LOC], 119 which demonstrates how a Location Recipient of an LbyR subscribes to 120 a Location Server to attain the location of the Target. If the 121 dereferencer has permission, defined in [ID-GEO-POL], the location 122 of the target will be returned to the Location Seeker. The Location 123 Server will grant permission to location inquires based on the rules 124 established by a Rule Holder [RFC3693]. The Location Server has the 125 ability to challenge any Location Seeker's request, thereby 126 providing additive security properties to location revelation. 128 Endpoints will require their geographic location for a growing 129 number of services. A popular use-case currently is for emergency 130 services, in which SIP requires its location to be placed in a SIP 131 INVITE request [ID-SIP-LOC] towards a public safety answering point 132 (PSAP), i.e., an emergency response center. The reason for this is 133 twofold: 135 o An emergency services SIP request must be routed/retargeted to the 136 appropriate PSAP that is local to where the calling device is. 138 o The first responders require the UA's location in order to know 139 where to be dispatched to render aid to the caller. 141 Including location in the SIP request is the most efficient means of 142 accomplishing both requirements above. 144 There are other use-cases, such as calling the appropriate Pizza Hut 145 without having to look up in a directory which store is closest. A 146 UA knowing its location can call a main/national/international Pizza 147 Hut number or address and let the UA's location tell Pizza Hut 148 enough information to have them route/retarget the SIP request to 149 the appropriate store within the Pizza Hut organization to deliver 150 the pizza to the caller's location. 152 A problem exists within existing RFCs that provide location to the 153 UA ([RFC3825] and [RFC4776]), these types of DHCP Options for 154 geolocation requires an update of the entire location information 155 (LI)every time a UA moves. Not all UAs will move frequently, but 156 some will. Refreshing location every time a UA moves does not scale 157 in certain networks/environments, such as IP based cellular 158 networks, enterprise networks or service provider networks with 159 mobile endpoints. An 802.11 based access network is one example of 160 this. Constantly updating LI to the endpoints might not scale in 161 mobile (residential or enterprise or municipal) networks in which 162 the UA is moving through more than one network attachment point, 163 perhaps as a person walks or drives with their UA down a 164 neighborhood street or apartment complex or a shopping center. 166 If the UA were provided a URI reference to retain and hand out when 167 it wants or needs to convey its location (in a protocol other than 168 DHCP), a Location URI reference that would not change as the UA's 169 location changes, scaling issues would be significantly reduced to 170 needing an update of the URI only when a client changes 171 administrative domains - which is much less often. This delivery of 172 an indirect location has the added benefit of not using up valuable 173 or limited bandwidth to the UA with the constant updates. It also 174 relieves the UA from having to determine when it has moved far 175 enough to consider asking for a refresh of its location. Many 176 endpoints will not have this ability, so relying on it could prove 177 fruitless. Once the UA has a Location URI, a service provider, 178 however it Sights the Location Target, as described in RFC 3693 179 [RFC3693], would merely update the actual location in the LIS 180 record, i.e., the record the URI points towards. This document does 181 not define how this update is done, as it will not be done with 182 DHCP. 184 In enterprise networks, if a known location is assigned to each 185 individual Ethernet port in the network, a device that attaches to 186 the network a wall-jack (directly associated with a specific 187 Ethernet Switch port) will be associated with a known location via a 188 unique circuit-ID that's used by the RAIO Option defined in RFC 3046 189 [RFC3046]. This assumes wall-jacks have an updated wiremap 190 database. RFC 3825 and RFC 4776 would return an LCI value of 191 location. This document specifies how a Location URI is returned by 192 DHCP. Behind the DHCP server, in the backend of the network, via 193 the (logical entity of a) LIS has a PIDF-LO in each location record 194 a Location URI points to. 196 If an 802.11 Access Port (AP) is at a specific known location within 197 this enterprise network, all wireless Ethernet devices attaching to 198 the network through this AP could be given the same location in 199 their respective location records because the DHCP server would know 200 each device was attaching from a known location, in this case, the 201 same location. This is assuming no 802.11 triangulation is 202 occurring, this would give a more precise location to be placed in 203 the location record (URI) of each device. 205 If local configuration has the requirement of only assigning unique 206 Location URIs to each client, then unique LbyRs will be given out, 207 though they will all have the same location at the record, relieving 208 the backend Sighter from individually maintaining each location 209 independently. 211 This Option can be useful in WiMAX connected endpoints or IP 212 cellular endpoints. The Location URI Option can be configured as a 213 client if it is a router, such as a residential home gateway, with 214 the ability to communicate to downstream endpoints as a server. 216 The means of challenge by any given LIS can vary, and a policy 217 established by a rulemaker [RFC3693] for a Location Target as to 218 what type of challenge(s) are used, how strong a challenge is used 219 or how precise the location information is given to a requestor. All 220 of this is outside the scope of this document (since this will not 221 be accomplished using DHCP). 223 This document IANA registers the new IPv4 and IPv6 DHC Options for a 224 Location URI. 226 2. Format of the DHCP LbyrElement Option 228 2.1 Overall Format of LbyrElement Option in IPv4 230 The LbyrElement Option format for IPv4 is as follows: 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Code XXX | Length=XX | Ver | Resv | . 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 237 . LbyrElements... ... 238 . (see section 2.3 for details) ... . 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 1. IPv4 Fields for this LbyrElement Option 243 Code XXX: The code for this DHCPv4 option (IANA assigned). 245 Length=XX: The length of this option, counted in bytes - not 246 counting the Code and Length bytes. This is a variable 247 length Option, therefore the length value will change 248 based on the length of the LbyR within the Option. 250 Ver: (4 bits) The version of this Option. This will specify 251 version 1. 253 Resv: (4 bits) reserved for future use. 255 LbyrElement: see section 2.3 for details 257 2.2 Overall Format of LbyrElement Option in IPv6 259 The LbyrElement Option format for IPv6 is as follows: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | option-code | option-len | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Ver | Resv | . 267 +---------------+ . 268 . LbyrElements... . 269 . (see section 2.3 for details) . 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2. IPv6 fields of this LbyrElement Option 274 option-code: The code for this DHCPv6 option (IANA assigned). 276 option-len: The length of this option, counted in bytes - not 277 counting the Code and Length bytes. This is a variable 278 length Option, therefore the length value will change 279 based on the shape within the Option. 281 Ver: See above (Section 2.1). This will specify version 1. 283 Resv: See above (Section 2.1). 285 LbyrElement: see below (Section 2.3 for details). 287 2.3 LbyrElement Format for both IPv4 and IPv6 289 The LbyrElement, in both DHCPv4 and DHCPv6, have the following 290 format: 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | LbyrType | LbyrLength | LbyrValue ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3. LbyrElement Format for both IPv4 and IPv6 300 LbyrType: A one-byte identifier of the data location value. 302 LbyrLength: The length, in bytes, of the LbyrValue, not including 303 the LbyrLength field itself, up to a maximum of 255 304 bytes. 306 LbyrValue: The LbyrElement value, as described in detail below. 307 The LbyrValue is always in UTP-8. 309 The LbyrTypes this document defines (and IANA registers) for a point 310 are: 312 LbyrType=1 Location-by-Reference URI - This is the URI pointing 313 at the location record where the PIDF-LO resides which 314 indicates the location of the Location Target. 316 LbyrType=2 Valid-For - The time, in seconds, this URI is to be 317 considered Valid for dereferencing. The timer 318 associated with this LbyrType starts upon receipt of 319 this Option. 321 The LbyrType=2 (Valid-For) indicates how long, in seconds, the 322 client is to consider this LbyrType=1 (Location-by-Reference URI) 323 valid before performing a refresh of this Option, with a refreshed 324 LbyrType=2 (Valid-For) value. A refresh MAY be done merely at the 325 normal DHCP refresh rate, or necessitated by this timer, perhaps 326 with the client only requesting this Option be refreshed. 328 It is RECOMMENDED when the counter associated with this LbyrType=2 329 (Valid-For) value has passed, the client perform a refresh of this 330 Option. For example, if 16000 was the initial value of the 331 LbyrType=2 (Valid-For) value, when 8000 seconds have passed, the 332 Option SHOULD be refreshed. 334 The LbyrType=2 (Valid-For) is not mandated for use by this document. 335 However, its presence MUST NOT cause any error in handling the 336 Location URI (i.e., if not understood, it MUST be ignored). 338 This Option format is highly extensible. Additional LbyrType types 339 created MUST be done so through IANA registration with peer review 340 and an RFC. 342 3. DHC Option Operation 344 The [RFC3046] RAIO MUST be utilized to provide the appropriate 345 indication to the DHCP Server where this DISCOVER or REQUEST message 346 came from, in order to supply the correct response. That said, this 347 Option SHOULD NOT be in a DISCOVER message, because there is zero 348 knowledge by the client of which Server will answer. 350 Caution SHOULD always be used involving the creation of large 351 Options, meaning that this Option MAY need to be in its own INFORM, 352 OPTION or ACK message. 354 It is RECOMMENDED to avoid building URIs, with any parameters, 355 larger than what a single DHCP response can be. However, if a 356 message is larger than 255 bytes, concatenation is allowed, per RFC 357 3396 [RFC3396]. 359 Per [RFC2131], subsequent LbyrElement Options, which are 360 non-concatenated, overwrite the previous value. 362 Location URIs MUST NOT reveal identity information of the user of 363 the device, since DHCP is a cleartext delivery protocol. For 364 example, Location URIs such as 366 sips:34LKJH534663J54@example.com 368 SHOULD be done, providing no identity information, rather than a 369 Location URI such as this 371 sips:aliceisinatlanta@example.com 373 This Option is for only communications between a DHCP client and a 374 DHCP server. It can be solicited (requested) by the client, or it 375 can be pushed by the server without a request for it. DHCP Options 376 not understood are ignored. A DHCP server might or might not have 377 the location of a client, therefore direct knowledge of a 378 Location URI within the server. If a server does not have a 379 client's location, a communication path (or request) to a LIS would 380 be necessary. 382 The LIS function, which is logical, is what creates the LbyR. The 383 coordination between the logical entity of a DHCP server and the 384 logical entity of a LIS as to which circuit-ID gets which 385 Location URI is not done via DHCP, therefore it is not defined 386 here. Further, any location revelation rules and policies a user 387 has regarding the treatment of their actual location, and who can 388 access (what precision of) their location will be done with other 389 than DHCP, and likely will be done before anything other than 390 default authentication and authorization permissions are used when a 391 Location Seeker, as defined in RFC 3693, requests a for a Target's 392 location. 394 Differentiating clients is done via client identifiers. Therefore, 395 in many implementations, each client can be assigned unique LbyRs, 396 though this is not mandatory. 398 Any dereferencing of a client's Location URI would not involve DHCP 399 either, but more likely by an application layer protocol such as 400 SIP, through a subscription to the Location URI on the LIS. The LIS 401 would also handle all authentication and authorization of location 402 requests, which is also not performed with DHCP, therefore not 403 defined here. 405 In the case of residential gateways being DHCP servers, they usually 406 perform as DHCP clients in a hierarchical fashion up into a service 407 provider's network DHCP server(s), or learn what information to 408 provide via DHCP to residential clients through a protocol such as 409 PPP. In these cases, the Location URI would likely indicate the 410 residence's civic address to all wired or wireless clients within 411 that residence. This is not inconsistent with what's stated above. 413 3.1 Architectural Assumptions 415 The following assumptions have been made for use of this LbyrElement 416 Option for a client to learn its Location URI (in no particular 417 order): 419 o Any user control (what Geopriv calls a 'rulemaker') for the 420 parameters and profile options a Location-Object will have is out 421 of scope of this document, but assumed to take place via an 422 external web interface between the user and the LIS (direct or 423 indirect). 425 o Any user attempting to gain access to the information at this URI 426 will be challenged by the LIS, not the DHCP server for 427 credentials and permissions. 429 3.2 Harmful URIs and URLs 431 There are, in fact, some types of URIs that are not good to receive, 432 due to security concerns. For example, any URLs that can have 433 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 434 pages - that have scripts. Therefore, 436 o URIs received via this Option SHOULD NOT be sent to a 437 general-browser to connect to a web page, because they could have 438 harmful scripts. 440 o This Option SHOULD NOT contain "data:" URLs, because they could 441 contain harmful scripts. 443 Instead of listing all the types of URIs and URLs that can be 444 misused or potentially have harmful affects, Section 3.3 IANA 445 registers acceptable Location URI schemes (or types). 447 3.3 Valid Location URI Schemes or Types 449 Therefore, this document specifies which URI types are acceptable as 450 a Location URI scheme (or type): 452 1. sip: 453 2. sips: 454 3. pres: 456 These Location URI types are IANA registered in section 4.2 of this 457 document. 459 4. IANA Considerations 461 4.1 The IPv4 Option number for this Option 463 This document IANA registers this IPv4 Option number XXX (to be 464 assigned by IANA once this document becomes an RFC). 466 4.2 The IPv6 Option-Code for this Option 468 This document IANA registers this IPv6 Option-Code XXX (to be 469 assigned by IANA once this document becomes an RFC). 471 4.3 The Version number for this Option 473 This document IANA registers the version number 1 of this Option. 475 4.4 IANA Considerations for Acceptable Location URI Types 477 IANA is requested to create a new registry for acceptable Location 478 URI types. 480 The following 3 URI types are registered by this document: 482 1. sip: 483 2. sips: 484 3. pres: 486 Any additional Location URI types to be defined for use via 487 this DHC Option need to be created and IANA registered with peer 488 review and an RFC. 490 5. Security Considerations 492 Where critical decisions might be based on the value of this 493 Location URI option, DHCP authentication in [RFC3118] SHOULD be used 494 to protect the integrity of the DHCP options. 496 A real concern with RFC 3118 it is that not widely deployed because 497 it requires keys on both ends of a communication to work (i.e., in 498 the client and in the server). Most implementations do not 499 accommodate this. 501 DHCP is a broadcast initially (a client looking for a server), 502 unicast response (answer from a server) type of protocol. It is not 503 secure in a practical sense. In today's infrastructures, it will be 504 primarily used over a wired, switched Ethernet network, requiring 505 physical access to within a wire to gain access. Further, within an 506 802.11 wireless network, the 802.11 specs have layer 2 security 507 mechanisms in place to help prevent a Location URI from being 508 learned by an unauthorized entity. 510 That said, having the Location URI does not mean this unauthorized 511 entity has the location of a client. The Location URI still needs 512 to be dereferenced to learn the location of the client. This 513 dereferencing function, which is not done using DHCP, is done by 514 requesting the location record at a Location Information Server, or 515 LIS, which is a defined entity built to challenge each request it 516 receives based on a joint policy of what is called a rulemaker. The 517 rulemaker, as defined in RFC 3693, configures the authentication and 518 authorization policies for the location revelation of a Target. 519 This includes giving out more or less precise location information 520 in an answer, therefore it can answer a bad-hat, but not allow it 521 from learning exactly where a user is. The rulemaker, which is a 522 combination of the default rules set up by the location provider and 523 those decided on by the user of the Target device. Likely, the 524 rules the user wants will not be allowed to go past some limits 525 established by the location provider, i.e., the administrator of the 526 LIS, for various capability or security reasons. 528 Penetrating a LIS is supposed to be hard, and hopefully vendors that 529 implement a LIS 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 string itself. The Location URI also must be 534 hard to guess that it belongs to a specific user. There is some 535 debate as to whether this Location URI need be a random alphanumeric 536 string or just unique. If the latter, there is some debate as to 537 the how we define unique. Is that through space as time, as RFC 3261 538 defines a SIP Call-ID needs to be (meaning: never a duplicate, ever, 539 by any device, ever)? Or is it unique to within a specific domain 540 for as long as it is actively assigned to a client (plus some 541 interval). 543 When implementing a DHC server that will serve clients across an 544 uncontrolled network, one should consider the potential security 545 risks therein. 547 6. Acknowledgements 549 Thanks to James Winterbottom, Marc Linsner, Roger Marshall and 550 Robert Sparks for their useful comments. And to Lisa Dusseault for 551 her concerns about the types of URIs that can cause harm. To 552 Richard Barnes for inspiring a more robust Security Considerations 553 section. 555 7. References 557 7.1. Normative References 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 563 3046, January 2001. 565 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 566 March 1997. 568 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 569 Messages", RFC 3118, June 2001. 571 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 572 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 573 Session Initiation Protocol", RFC 3261, May 2002. 575 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 576 Event Notification", RFC 3265, June 2002. 578 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic 579 Host Configuration Protocol (DHCPv4)", RFC 3396, November 580 2002 582 7.2. Informative References 584 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in 585 progress", Mar 2009 587 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 588 Configuration Protocol Option for Coordinate-based Location 589 Configuration Information", RFC 3825, July 2004 591 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 592 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 593 Information ", RFC 4776, November 2006 595 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 596 Mechanism", "work in progress", Feb 2009 598 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 599 "Geopriv Requirements", RFC 3693, February 2004 601 [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. 602 Polk, "Geolocation Policy: A Document Format for Expressing 603 Privacy Preferences for Location Information", "work in 604 progress", Feb 2009 606 Authors' Address 608 James Polk 609 3913 Treemont Circle 610 Colleyville, Texas 76034 611 USA 613 Email: jmpolk@cisco.com