--- 1/draft-ietf-geopriv-dhcp-lbyr-uri-option-02.txt 2008-11-04 03:12:07.000000000 +0100 +++ 2/draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt 2008-11-04 03:12:07.000000000 +0100 @@ -1,19 +1,19 @@ Geopriv WG James Polk Internet-Draft Cisco Systems -Expires: Dec 17, 2008 June 17, 2008 -Intended status: Standards Track (PS) +Intended status: Standards Track (PS) Nov 3, 2008 +Expires: May 3, 2009 Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform Resource Identifier (URI) - draft-ietf-geopriv-dhcp-lbyr-uri-option-02 + draft-ietf-geopriv-dhcp-lbyr-uri-option-03 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 @@ -24,85 +24,84 @@ 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 Dec 17, 2008. + This Internet-Draft will expire on May 3, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document creates a Dynamic Host Configuration Protocol (DHCP) - Option for the Location 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 Location-URI can be - included in a UA's signaling messages to inform other nodes of that - entity's geographic location, once the URI is dereferenced by a - Location Recipient. + Option for the downloading of a Uniform Resource Identifier (URI) + pointing to the geolocation record of an endpoint. This URI, called + a Location-by-Reference (LbyR), points to a record on a location + server which tracks the geolocation of the endpoint. Once + downloaded by an endpoint, this LbyR can be forwarded to another + entity, to be dereferenced if this entity wants to learn the + geolocation of the sender endpoint. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. DHC Location-URI Elements . . . . . . . . . . . . . . . . . . 4 2.1. Elements of the Location Configuration Information . . 5 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 5 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 7 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 7 3.3 Valid Location-URI Schemes or Types . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . . . 10 + Intellectual Property and Copyright Statements . . . . . . . . . 11 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]. 1. Introduction This document creates a Dynamic Host Configuration Protocol (DHCP) - Option for delivery of a client's Location Uniform Resource - Identifier (URI). For example, a client can be a Session Initiation - Protocol (SIP) User Agent (UA) [RFC3261] (i.e., a Phone). This - Location-URI can be included in a UA's signaling messages - [ID-SIP-LOC] to inform remote devices (i.e., other phones or servers - or applications) of that UA's geographic location. This is an - indirect means of passing a Location Target's location to another - entity, called a dereference (of a URI). In other words, if an - entity has the Location URI, it can access the location record at - the server the URI points to, if the requestor has permission to - access it there. Where the location record is will likely be an - entity called a Location Information Server (LIS) [ID-LBYR-REQ], - which stores the locations of many Location Targets, which has the - ability to challenge each dereference request by whatever means it - is capable of, thus providing additive security properties to - location revelation. + Option for the downloading of a Uniform Resource Identifier (URI) + pointing to the geolocation record of an endpoint. A client, for + example, can be a Session Initiation Protocol (SIP) User Agent (UA) + [RFC3261] (i.e., a Phone). This URI, called a + Location-by-Reference (LbyR), points to a record on a location + server [ID-LBYR-REQ] which tracks the geolocation of the endpoint + (through means not defined in this document). The LbyR record + stores the Geolocation of a Location Target. Once downloaded by an + endpoint (the target in this case), this LbyR can be forwarded to + another entity, using SIP as defined in [ID-SIP-LOC], to be + dereferenced if this second entity wants to learn the geolocation of + the Location Target. - A Location Recipient is a device that has received location from - another entity. If this location is delivered by a URI, the URI has - to be dereferenced by the Location Recipient 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. Each of these URI schemes are IANA - registered in Section 5 of this document as valid for use by this + The act of dereferencing location is explained in [ID-SIP-CON], + which demonstrates how a possessor of a LbyR subscribes to a + Location Server to attain the location of the Target. If the + dereferencer has permission, defined in [ID-GEO-POL], the location + of the target will be returned to the Location Seeker. The Location + Server will grant permission to location inquires based on the rules + established by a Rule Holder [RFC3693]. Therefore, the Location + Server has the ability to challenge any location seeker's request, + thus providing additive security properties to location revelation. Option. 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 [ID-SIP-LOC] towards a public safety answering point (PSAP), i.e., an emergency response center. The reason for this is twofold: o An emergency services SIP request must be routed/retargeted to the @@ -195,20 +194,22 @@ 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 | Valid-For | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Location-URI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / .... \ \ .... / + / .... \ + \ .... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. @@ -254,40 +255,44 @@ example, Location URIs such as sips:34LKJH534663J54@example.com should be done, providing no identity information, rather than a Location-URI such as this sips:aliceisinatlanta@example.com This Option is for only communications 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. DHCP Options + DHCP server. It can be solicited (requested) by the client, or it + can be pushed by the server without a request for it. DHCP Options not understood are ignored. A DHCP server might or might not have the location of a client, therefore direct knowledge of a Location-URI within the server. If a server does not have a client's location, a communication path (or request) to a LIS would be necessary. - The LIS function, which is logical, is what creates the URI. The + The LIS function, which is logical, is what creates the LbyR. The coordination between the logical entity of a DHCP server and the logical entity of a LIS as to which circuit-ID gets which Location-URI is not done via DHCP, therefore it is not defined here. Further, any location revelation rules and policies a user has regarding the treatment of their actual location, and who can access (what precision of) their location will be done with other than DHCP, and likely will be done before anything other than default authentication and authorization permissions are used when a Location Seeker, as defined in RFC 3693, requests a for a Target's location. + Differentiating clients is done via client identifiers. Therefore, + in many implementations, each client can be assigned unique LbyRs, + though this is not mandatory. + Any dereferencing of a client's Location-URI would not involve DHCP either, but more likely by an application layer protocol such as SIP, through a subscription to the Location-URI on the LIS. The LIS would also handle all authentication and authorization of location requests, which is also not performed with DHCP, therefore not defined here. In the case of residential gateways being DHCP servers, they usually perform as DHCP clients in a hierarchical fashion up into a service provider's network DHCP server(s), or learn what information to @@ -453,34 +457,38 @@ [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002 7.2. Informative References [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", - draft-ietf-sip-location-conveyance-10.txt, "work in + draft-ietf-sip-location-conveyance-11.txt, "work in [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, November 2006 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference - Mechanism", draft-ietf-geopriv-lbyr-requirements-02.txt, - "work in progress", Feb 08 + Mechanism", draft-ietf-geopriv-lbyr-requirements-04.txt, + "work in progress", Nov 08 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 + [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. + Polk, "Geolocation Policy: A Document Format for Expressing + Privacy Preferences for Location Information", "work in + Authors' Address James Polk 3913 Treemont Circle Colleyville, Texas 76034 USA EMail: jmpolk@cisco.com Full Copyright Statement