Geopriv WG James Polk Internet-Draft Cisco Systems Intended status: Standards Track July 9th, 2007 Expires: January 9th, 2008 Dynamic Host Configuration Protocol (DHCP) Option for a Location-by-Reference (LbyR) Uniform Resource Identifier (URI) draft-polk-geopriv-dhcp-lbyr-uri-option-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 9th, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document creates a Dynamic Host Configuration Protocol (DHCP) Option for the Location-by-Reference (LbyR) Uniform Resource Identifier (URI) of an endpoint. For example, an endpoint can be a Session Initiation Protocol (SIP) User Agent, i.e., a phone. This LbyR URI can be included in a UA's messages to inform other nodes of that UA's geographic location, once the URI is dereferenced by a Location Recipient. Polk Expires Jan 2008 [Page 1] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in this Document . . . . . . . . . . . 3 2. DHC Location URI Elements . . . . . . . . . . . . . . . . . . 3 2.1. Elements of the Location Configuration Information . . 4 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 4 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . 6 1. Introduction This document creates a Dynamic Host Configuration Protocol (DHCP) Option for delivery of a client's Location-by-Reference (LbyR) Uniform Resource Identifier (URI). For example, a client can be a Session Initiation Protocol (SIP) User Agent (UA) [RFC3261], i.e., a phone. This LbyR URI can be included in one UA's messages to informing those remote devices of that UA's geographic location, once the URI is dereferenced by a Location Recipient [ID-SIP-LOC]. A Location Recipient is a device that has received location from another device. If this location is delivered by a URI, the URI has to be dereferenced to learn the remote device's geographic location. Dereferencing can be done in SIP by use of the SUBSCRIBE/NOTIFY Methods [RFC3265] to either a sip:, sips: or pres: scheme URI. Endpoints will require their geographic location for a growing number of services. A popular use-case currently is for emergency services, in which SIP requires its location to be placed in a SIP INVITE request message towards a public safety answering point (PSAP). The reason for this is twofold: o An emergency services SIP request must be routed/retargeted to the appropriate PSAP that is local to where the PSAP is. o The first responders require the UA's location in order to know where to go to render aid to the caller. There are other use-cases, such as calling the appropriate Pizza Hut without having to look up which store is closest. A UA knowing its location can call a main/national/international Pizza Hut number or address and let the UA's location tell Pizza Hut enough information to have them route/retarget the SIP request to the appropriate store within the Pizza Hut organization to deliver the pizza to the Polk Expires Jan 2008 [Page 2] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 caller. A problem exists within existing RFCs that provide location to the UA, [RFC3825] and [RFC4776], that location has to be updated every time a UA moves. This does not scale in certain networks/environments, such as enterprise networks or service provider networks with mobile endpoints. An 802.11 based access network is an example of this. This also might not scale in mobile residential networks in which the UA is hopping between more than one network attachment point, perhaps as a person walks with their UA down a neighborhood street or apartment complex. If the UA were provided a URI reference to retain and hand out when it wants to convey its location, one that would not change as the UAC's location changes, scaling issues would be significantly reduced. This delivery of an indirect location has the added benefit of not using up valuable or limited bandwidth to the UA with the constant updates. A service provider would merely update what location is at the URI the UA already has, with this new DHCP Option. In enterprise networks, a URI can be assigned to individual Ethernet ports; meaning whatever is attached to a particular port will get the same URI because that device is at a known location. This scenario applies to 802.11 Access Points (AP), in which the AP's location is what's known. The same URI can be given to all devices attached to the same AP. Just as with residential router/gateways, which can be wired or wireless, in which all devices understanding this Option will be giving the location of the residence. The Option also benefits from the URI not needing identity information to still be useful. APs that triangulate can also have a individual URI downloaded to each endpoint with this Option, for the endpoint to hand out whenever it is configured to in whatever protocol it is capable of. This Option can be useful in WiMAX connected endpoints or IP cellular endpoints. The Location URI Option can be configured as a client if it is a router, such as a residential home gateway, with the ability to communicate to downstream endpoints as a server. This document IANA registers the new DHC Option for a Location URI. 1.1 Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Polk Expires Jan 2008 [Page 3] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 2. DHC Location URI Elements DHCP is a binary Protocol; URIs are alphanumeric (text) based. There is one byte per URI character. [Editor's question: should UTF-8 vs. UTF-16 be accounted for?] The Location URI Option format is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code XXX | Option Length | Location URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location URI (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / .... \ \ .... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location URI (cont'd) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. Elements of the Location Configuration Information Code XXX: The code for this DHCP option. Option Length: The length of this option variable. Location URI: The Location URI There are no additional fields within this Option, as the value of the URI is contained within the URI field, including all URI parameters and (what could become another protocol's) header parameters. 3. DHC Option Operation The [RFC3046] RAIO MUST be utilized to provide the appropriate indication to the DHCP Server where this DISCOVER or REQUEST message came from, in order to supply the correct response. Caution SHOULD always be used involving the creation of large Options, meaning that this Option MAY need to be in its own INFORM, OPTION or ACK message. It is RECOMMENDED to avoid building URIs, with any parameters, larger than what a single DHCP response can be. However, if a message is larger than 255 bytes, concatenation is allowed to be used [RFC3396]. Polk Expires Jan 2008 [Page 4] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 Per [RFC2131], subsequent LbyR URI Options, which are non-concatenated, overwrite the previous value. LbyR URIs SHOULD NOT reveal identity information of the user of the device, since DHCP is a cleartext delivery protocol. [Editor's question: can the above SHOULD NOT be a MUST NOT?] 3.1 Architectural Assumptions The following assumptions have been made for use of this URI Option for a client to learn it's location URI (in no particular order): o The DHCP Server communicates with the Location Information Server (LIS), which likely stores the location information for URIs. This exchange can be any number of protocols (SOAP, HTTP, FTP, SIP, etc) on a per request-basis/log-on, or in bulk. o A URI is assigned to a Ethernet Switch, router or home gateway port - such that the location does not change without administrative controls. This allows any device to attach to the network from a particular port to have the same location URI given to them, because that device is in the same location. o The population of the database of Ethernet Switch, router or home gateway port, in the LIS is done administratively, and outside the scope of this document. o A DHCP Server is not expected to deliver location URIs with this option outside of the DHCP Server's policy domain. Most likely this is within a company's network, or a region of a network for SPs. o Any user control (what Geopriv calls a 'rulemaker') for the parameters and profile options a Location-Object will have is out of scope of this document, by assumed to take place via something such as a web interface between the user and the LIS (direct or indirect). o Any user attempting to gain access to the information at this URI will be challenged by the server for credentials and permissions. 4. Acknowledgements Thanks to James Winterbottom for his useful comments. 5. IANA Considerations IANA is requested to assigned a DHCP option code of XXX for the Polk Expires Jan 2008 [Page 5] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 Location URI option, defined in Section 2.0 of this document. Any additional Location URI parameters to be defined for use via this DHC Option MUST be done through a Standards Track RFC. 6. Security Considerations Where critical decisions might be based on the value of this LbyR URI option, DHCP authentication in [RFC3118] SHOULD be used to protect the integrity of the DHCP options. Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the DHCP server and requesting client can discover this LbyR URI. Other than capturing the URI, the location of the client benefits from the protection of whatever server challenge mechanisms are available and configured for any device attempting access of the location record that the URI. LbyR URIs need to reduce or eliminate client identity information within the URI itself, because DHCP is a cleartext delivery protocol. When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks therein. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Polk Expires Jan 2008 [Page 6] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 7.2. Informative References [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-ietf-sip-location-conveyance-07.txt, "work in progress", Feb 2007 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, November 2006 Authors' Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA EMail: jmpolk@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Polk Expires Jan 2008 [Page 7] Internet-Draft Geopriv DHCP LbyR URI Option July 2007 Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires Jan 2008 [Page 8]