--- 1/draft-ietf-geopriv-dhcp-lbyr-uri-option-17.txt 2013-02-06 01:40:52.495707497 +0100 +++ 2/draft-ietf-geopriv-dhcp-lbyr-uri-option-18.txt 2013-02-06 01:40:52.527707823 +0100 @@ -1,19 +1,19 @@ Network WG James Polk Internet-Draft Cisco Systems -Intended status: Proposed Standard Jan 28, 2013 -Expires: June 28, 2013 +Intended status: Proposed Standard Feb 5, 2013 +Expires: July 5, 2013 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) - draft-ietf-geopriv-dhcp-lbyr-uri-option-17 + draft-ietf-geopriv-dhcp-lbyr-uri-option-18 Abstract This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI), and another Option to explicitly indicate how long that location URI is to be considered valid. This Location URI can then be dereferenced in a separate transaction by the client or sent to another entity and dereferenced to learn physically where the client is located, but only while valid. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on June 28, 2013. + This Internet-Draft will expire on July 5, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -77,26 +77,26 @@ 1. Introduction This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI), and another Option to explicitly indicate how long that location URI is to be considered valid. In this scenario, the DHCP client is a Geopriv Target (i.e., the entity whose geolocation is associated with the location URI). The DHCP implementation of the client can then make this location information available to other - applications for their usage. This location URI points a Location - Server [RFC5808] which has the geolocation of the client (e.g., - uploaded into a wiremap database when the client attached wall-jack, - or by means of 802.11 geolocation mechanisms). + applications for their usage. This location URI points to a + Location Server [RFC5808] which has the geolocation of the client + (e.g., uploaded into a wiremap database when the client attached + wall-jack,or by means of 802.11 geolocation mechanisms). - Applications within the Target can then choose to deference this + Applications within the Target can then choose to dereference this location URI and/or transmit the URI to another entity as a means of conveying where the Target is located. Both Conveying and Dereferencing a location URI is described in [RFC6442]. Session Initiation Protocol (SIP) is not the only protocol that can dereference a location URI; there is also HTTP-Enabled Location Delivery (HELD) [RFC6753] and HTTP [RFC2616]. A Location Server (LS) stores the Target's location as a presence document, called a Presence Information Data Format - Location Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server @@ -306,28 +306,40 @@ Option MUST ignore the Valid-For Option. o The Valid-For Option MUST only be considered in relation to the Location URI Option. It has no other purpose in DHCP then in relation to the Location URI (i.e., there is no other Option in DHCP to which it has meaning). o The Valid-For Option MUST NOT cause any error in handling the Location URI, i.e., if not understood, it MUST be ignored. + A client uses the Location URI (value) until the Valid-For value + reaches zero. If there is no Valid-For Option value, then the + counter did not ever start (a null value), and the client continues + to use the Location URI value until given a new Location URI Option + (with or without a Valid-For value) which overwrites any previous + Location URI and Valid-For Option values. + o Servers MUST assume that clients will overwrite any existing, previously sent values of Location URI Option and/or Valid-For Option. o Clients MUST overwrite any existing, previously sent values of Location URI Option and/or Valid-For Option when receiving the next instance of either Option. + o If a client receives a new Location URI Option without also + receiving a new Valid-For Option - with the previous Valid-For + Option timer not reaching zero, the Valid-For timer MUST be set to + zero upon reception of this new Location URI Option. + The choice of the Valid-For value is a policy decision for the operator of the DHCP server. Like location URIs themselves, it can be statically configured on the DHCP server or provisioned dynamically (via an out-of-band exchange with a Location Information Server) as requests for location URIs are received. o Clients receiving both a Location URI and Valid-For Options start the Valid-For timer upon receipt of the DHCP message containing both Options. @@ -412,22 +424,22 @@ client. If a server does not have a client's location, but needs to provide this Location URI Option to a client (for whatever reason), an LS is contacted. This server-to-LS transaction is not DHCP, therefore it is out of scope of this document. Note that this server-to-LS transaction could delay the DHCP messaging to the client. If the server fails to have location before it transmits its message to the client, location will not be part of that DHCP message. Any timers involved here are a matter of local configuration. - The deference of a target's location URI would not involve DHCP, but - an application layer protocol, such as SIP or HTTP, therefore + The dereference of a target's location URI would not involve DHCP, + but an application layer protocol, such as SIP or HTTP, therefore dereferencing is out of scope of this document. 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 provide via DHCP to residential clients through a protocol, such as PPP. In these cases, the location URI would likely indicate the residence's civic address to all wired or wireless clients within that residence. @@ -524,32 +536,35 @@ (to be assigned by IANA once this document becomes an RFC). 4.4 The IPv6 Option-Code for the Valid-For Option This document IANA registers the Valid-For IPv6 Option-Code XXX (to be assigned by IANA once this document becomes an RFC). 5. Security Considerations Where critical decisions might be based on the value of this - location URI option, DHCP authentication in [RFC3118] SHOULD be used + location URI option, DHCP authentication as defined in + "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to protect the integrity of the DHCP options. - A real concern with RFC 3118 is that it is not widely deployed - because it requires pre-shared keys to successfully work (i.e., in - the client and in the server). Most implementations do not - accommodate this. + A real concern with RFC 3118 or RFC 3315 is that neither is widely + deployed because each requires pre-shared keys to successfully work + (i.e., in the client and in the server). Most implementations do + not accommodate this. DHCP, initially, is a broadcast request (a client looking for a server), and a unicast response (answer from a server) type of - protocol. It does not provide security at the network layer. - Instead, it relies on lower-layer security mechanisms. + protocol. There is no privacy protection for DHCP messages, an + eavesdropper who can monitor the link between the DHCP server and + requesting client can discover the Location URI. Once a client has a Location URI, it needs information on how the location server will control access to dereference requests. A client might treat a tightly access-controlled URI differently from one that can be dereferenced by anyone on the Internet (i.e., one following the "possession model"). Since the client does not know what policy will be applied during this validity interval, clients MUST handle location URIs as if they could be dereferenced by anybody until they expire. For example, such open location URIs should only be transmitted in encrypted channels. Nonetheless, @@ -568,20 +583,23 @@ As to the concerns about the location URI itself, as stated in the document (see Section 3), it MUST NOT have any user identifying information in the URI user-part/string itself. The location URI also needs to be hard to guess that it belongs to a specific user. In some cases a DHCP server may be implemented across an uncontrolled network. In those cases, it would be appropriate for a network administrator to perform a threat analysis (see RFC 3552) and take precautions as needed. + Link-layer confidentiality and integrity protection may also be + employed to reduce the risk of location disclosure and tampering. + 6. Acknowledgements Thanks to James Winterbottom, Marc Linsner, Roger Marshall and Robert Sparks for their useful comments. And to Lisa Dusseault for her concerns about the types of URIs that can cause harm. To Richard Barnes for inspiring a more robust Security Considerations section, and for offering the text to incorporate HTTP URIs. To Hannes Tschofenig and Ted Hardie for riding me to comply with their concerns, including a good scrubbing of the nearly final doc. @@ -594,20 +612,24 @@ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. + [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. + Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003 + [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. [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004