idnits 2.17.1 draft-polk-geopriv-dhcp-lbyr-uri-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. 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 9 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 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This Option is between a DHCP client and a DHCP server. It may be solicited (requested) by the client, or it may be pushed by the server without a request for it. Options not understood are ignored. The server MAY or MAY NOT have the location of a client within the server. If a server does not have a client's location, a topology of communication to a Location Information Server (LIS) [ID-LBYR-REQ] would be necessary. == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4119' is mentioned on line 136, but not defined == Missing Reference: 'RFC3396' is mentioned on line 219, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-09 -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-01 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv WG James Polk 3 Internet-Draft Cisco Systems 4 Expires: May 18th, 2008 November 18th, 2007 5 Intended status: Standards Track (PS) 7 Dynamic Host Configuration Protocol (DHCP) Option for a 8 Location-by-Reference (LbyR) Uniform Resource Identifier (URI) 9 draft-polk-geopriv-dhcp-lbyr-uri-option-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 18th, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document creates a Dynamic Host Configuration Protocol (DHCP) 43 Option for the Location-by-Reference (LbyR) Uniform Resource 44 Identifier (URI) of an endpoint. For example, an endpoint can be a 45 Session Initiation Protocol (SIP) User Agent (i.e., a phone). This 46 LbyR URI can be included in a UA's messages to inform other nodes of 47 that entity's geographic location, once the URI is dereferenced by a 48 Location Recipient. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions Used in this Document . . . . . . . . . . . 4 54 2. DHC Location URI Elements . . . . . . . . . . . . . . . . . . 4 55 2.1. Elements of the Location Configuration Information . . 4 56 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5 57 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 6 58 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 6 59 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . 8 68 1. Introduction 70 This document creates a Dynamic Host Configuration Protocol (DHCP) 71 Option for delivery of a client's Location-by-Reference (LbyR) 72 Uniform Resource Identifier (URI). For example, a client can be a 73 Session Initiation Protocol (SIP) User Agent (UA) [RFC3261] (i.e., a 74 Phone). This LbyR URI can be included in one UA's messages to 75 informing those remote devices of that UA's geographic location, 76 once the URI is dereferenced by a Location Recipient [ID-SIP-LOC]. A 77 Location Recipient is a device that has received location from 78 another device. If this location is delivered by a URI, the URI has 79 to be dereferenced by the Location Recipient to learn the remote 80 device's geographic location. Dereferencing can be done in SIP by 81 use of the SUBSCRIBE/NOTIFY Methods [RFC3265] to either a sip:, 82 sips: or pres: scheme URI. 84 Endpoints will require their geographic location for a growing 85 number of services. A popular use-case currently is for emergency 86 services, in which SIP requires its location to be placed in a SIP 87 INVITE request message towards a public safety answering point 88 (PSAP), i.e., an emergency response center. The reason for this is 89 twofold: 91 o An emergency services SIP request must be routed/retargeted to the 92 appropriate PSAP that is local to where the calling device is. 94 o The first responders require the UA's location in order to know 95 where to be dispatched to render aid to the caller. 97 There are other use-cases, such as calling the appropriate Pizza Hut 98 without having to look up which store is closest. A UA knowing its 99 location can call a main/national/international Pizza Hut number or 100 address and let the UA's location tell Pizza Hut enough information 101 to have them route/retarget the SIP request to the appropriate store 102 within the Pizza Hut organization to deliver the pizza to the 103 caller's location. 105 A problem exists within existing RFCs that provide location to the 106 UA ([RFC3825] and [RFC4776]) that location has to be updated every 107 time a UA moves. Not all UAs will move frequently, but some will. 108 Refreshing location every time a UA moves does not scale in certain 109 networks/environments, such as enterprise networks or service 110 provider networks with mobile endpoints. An 802.11 based access 111 network is an example of this. This also might not scale in mobile 112 residential networks in which the UA is hopping between more than 113 one network attachment point, perhaps as a person walks with their 114 UA down a neighborhood street or apartment complex. 116 If the UA were provided a URI reference to retain and hand out when 117 it wants to convey its location, one that would not change as the 118 UA's location changes, scaling issues would be significantly 119 reduced. This delivery of an indirect location has the added 120 benefit of not using up valuable or limited bandwidth to the UA 121 with the constant updates. It also relieves the UA from having to 122 determine when it has moved far enough to consider asking for a 123 refresh of its location. Once the UA has a LbyR URI, a service 124 provider would merely update the location at the URI the UA already 125 has. This document does not define how this update is done, as it 126 will likely not be with DHCP. 128 In enterprise networks, a URI can be assigned to individual Ethernet 129 ports because each is assigned a unique circuit-ID that's used by 130 the RAIO Option defined in RFC 3046 [RFC3046]; meaning whatever is 131 attached to a particular port will get the same URI because that 132 device is at a known location (where the cable attached to that port 133 is terminated). This scenario applies to 802.11 Access Points (AP), 134 in which the AP's location is what's fixed and known. The same URI 135 can be given to all devices attached to the same AP. RFC 4119 136 [RFC4119] has the element, which indicates how the endpoint 137 learned its location. In this scenario, the element 138 indicates in the PIDF-LO the UA learned its location through DHCP, 139 thus informing the call taker the UA is within a certain radius of 140 the AP. 142 Just as with residential router/gateways, which can be wired or 143 wireless, in which all devices understanding this Option will be 144 giving the location of the residence. The Option also benefits from 145 the URI not needing identity information to still be useful. 147 APs that triangulate can also have a individual URI downloaded to 148 each endpoint with this Option, for the endpoint to hand out 149 whenever it is configured to. The element would give a 150 different indication in such a case, one that states the location is 151 a triangulation of the UA's specific location, and not that of the 152 AP's. 154 This Option can be useful in WiMAX connected endpoints or IP 155 cellular endpoints. The Location URI Option can be configured as a 156 client if it is a router, such as a residential home gateway, with 157 the ability to communicate to downstream endpoints as a server. 159 This document IANA registers the new DHC Option for a Location URI. 161 1.1 Conventions Used in this Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2. DHC Location URI Elements 169 DHCP is a binary Protocol; URIs are alphanumeric (text) based. 170 There is one byte per URI character. 172 [Editor's question: should UTF-8 vs. UTF-16 be accounted for?] 174 The Location URI Option format is as follows: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Code XXX | Option Length | Valid-For | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Location URI | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 / .... \ 184 \ .... / 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Location URI (cont'd) + 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 2.1. Elements of the Location Configuration Information 191 Code XXX: The code for this DHCP option. 193 Option Length: The length of this option variable. 195 Valid-For: The time, in seconds, this URI is to be considered 196 valid. 198 Location URI: The Location-by-Reference URI for the client 200 The field indicates how long, in seconds, the client is 201 to consider this location URI valid before performing a refresh of 202 this Option, with a new answer. A refresh MAY be done 203 merely at the normal DHCP refresh rate, or necessitated by this 204 timer, perhaps just requesting this Option be refreshed. 206 3. DHC Option Operation 208 The [RFC3046] RAIO MUST be utilized to provide the appropriate 209 indication to the DHCP Server where this DISCOVER or REQUEST message 210 came from, in order to supply the correct response. 212 Caution SHOULD always be used involving the creation of large 213 Options, meaning that this Option MAY need to be in its own INFORM, 214 OPTION or ACK message. 216 It is RECOMMENDED to avoid building URIs, with any parameters, 217 larger than what a single DHCP response can be. However, if a 218 message is larger than 255 bytes, concatenation is allowed, per RFC 219 3396 [RFC3396]. 221 Per [RFC2131], subsequent LbyR URI Options, which are 222 non-concatenated, overwrite the previous value. 224 LbyR URIs MUST NOT reveal identity information of the user of the 225 device, since DHCP is a cleartext delivery protocol. For example, 226 LbyR URIs such as 228 sips:34LKJH534663J54@example.com 230 should be done, providing no identity information, rather than a 231 LbyR URI such as this 233 sips:aliceisinatlanta@example.com 235 This Option is between a DHCP client and a DHCP server. It may be 236 solicited (requested) by the client, or it may be pushed by the 237 server without a request for it. Options not understood are 238 ignored. The server MAY or MAY NOT have the location of a client 239 within the server. If a server does not have a client's location, a 240 topology of communication to a Location Information Server (LIS) 241 [ID-LBYR-REQ] would be necessary. 243 The coordination between the logical entity of a DHCP server and the 244 logical entity of a LIS as to which circuit-ID gets which LbyR URI 245 is not done via DHCP, therefore it is not defined here. Any 246 dereferencing of a client's LbyR URI would not involve DHCP either, 247 but more likely an application layer protocol such as SIP, through a 248 subscription to the LbyR URI on the LIS. The LIS would also handle 249 all authentication and authorization of location requests, which is 250 also not performed with DHCP, therefore not defined here. 252 In the case of residential gateways being DHCP servers, they usually 253 perform as DHCP clients in a hierarchical fashion up into a service 254 provider's network DHCP server(s), or learn what information to 255 provide via DHCP to residential clients through a protocol such as 256 PPP. In these cases, the LbyR URI would likely indicate the 257 residence's civic address to all wired or wireless clients within 258 that residence. This is not inconsistent with what's stated above. 260 3.1 Architectural Assumptions 262 The following assumptions have been made for use of this URI Option 263 for a client to learn it's location URI (in no particular order): 265 o Any user control (what Geopriv calls a 'rulemaker') for the 266 parameters and profile options a Location-Object will have is out 267 of scope of this document, by assumed to take place via something 268 such as a web interface between the user and the LIS (direct or 269 indirect). 271 o Any user attempting to gain access to the information at this URI 272 will be challenged by the LIS, not the DHCP server for 273 credentials and permissions. 275 3.2 Harmful URIs and URLs 277 There are, in fact, some types of URIs that are not good to receive, 278 due to security concerns. For example, any URLs that can have 279 scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web 280 pages - that have scripts. Therefore, 282 o URIs received via this Option SHOULD NOT be sent to a 283 general-browser to connect to a web page, because they could have 284 harmful scripts. 286 o This Option SHOULD NOT contain "data:" URLs, because they could 287 have harmful scripts. 289 This concern will be highlighted more in a future version of this 290 document. 292 4. Acknowledgements 294 Thanks to James Winterbottom for his useful comments. And to Lisa 295 Dusseault for her concerns about the types of URIs that can cause 296 harm. 298 5. IANA Considerations 300 IANA is requested to assigned a DHCP option code of XXX for the 301 Location URI option, defined in Section 2.0 of this document. 303 Any additional Location URI parameters to be defined for use via 304 this DHC Option MUST be done through a Standards Track RFC. 306 6. Security Considerations 308 Where critical decisions might be based on the value of this 309 LbyR URI option, DHCP authentication in [RFC3118] SHOULD be used to 310 protect the integrity of the DHCP options. 312 Since there is no privacy protection for DHCP messages, an 313 eavesdropper who can monitor the link between the DHCP server and 314 requesting client can discover this LbyR URI. Other than capturing 315 the URI, the location of the client benefits from the protection of 316 whatever server challenge mechanisms are available and configured 317 for any device attempting access of the location record that the 318 URI. 320 LbyR URIs need to reduce or eliminate client identity information 321 within the URI itself, because DHCP is a cleartext delivery 322 protocol. 324 When implementing a DHC server that will serve clients across an 325 uncontrolled network, one should consider the potential security 326 risks therein. 328 7. References 330 7.1. Normative References 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 336 3046, January 2001. 338 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 339 March 1997. 341 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 342 Messages", RFC 3118, June 2001. 344 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 345 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 346 Session Initiation Protocol", RFC 3261, May 2002. 348 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 349 Event Notification", RFC 3265, June 2002. 351 7.2. Informative References 353 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", 354 draft-ietf-sip-location-conveyance-09.txt, "work in 355 progress", Nov 2007 357 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 358 Configuration Protocol Option for Coordinate-based Location 359 Configuration Information", RFC 3825, July 2004 361 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 362 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 363 Information ", RFC 4776, November 2006 365 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference 366 Mechanism", draft-ietf-geopriv-lbyr-requirements-01.txt, 367 "work in progress", Oct 07 369 Authors' Address 371 James Polk 372 3913 Treemont Circle 373 Colleyville, Texas 76034 374 USA 376 EMail: jmpolk@cisco.com 378 Full Copyright Statement 380 Copyright (C) The IETF Trust (2007). 382 This document is subject to the rights, licenses and restrictions 383 contained in BCP 78, and except as set forth therein, the authors 384 retain all their rights. 386 This document and the information contained herein are provided on 387 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 388 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 389 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 390 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 391 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 392 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 393 FOR A PARTICULAR PURPOSE. 395 Intellectual Property 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed 399 to pertain to the implementation or use of the technology described 400 in this document or the extent to which any license under such 401 rights might or might not be available; nor does it represent that 402 it has made any independent effort to identify any such rights. 403 Information on the procedures with respect to rights in RFC 404 documents can be found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use 409 of such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository 411 at http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Acknowledgment 421 Funding for the RFC Editor function is provided by the IETF 422 Administrative Support Activity (IASA).