[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-polk-geopriv-dhcp-lbyr-uri-option) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Geopriv WG                                                   James Polk
Internet-Draft                                            Cisco Systems
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-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
   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 May 3, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document creates a Dynamic Host Configuration Protocol (DHCP)
   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.





Polk                       Expires May 3 2009                  [Page 1]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008


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  . . . . . . . . . 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 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.

   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.



Polk                       Expires May 3 2009                  [Page 2]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

   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
     appropriate PSAP that is local to where the calling device is.

   o The first responders require the UA's location in order to know
     where to be dispatched to render aid to the caller.

   Including location in the SIP request is the most efficient means of
   accomplishing both requirements above.

   There are other use-cases, such as calling the appropriate Pizza Hut
   without having to look up in a directory 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 caller's location.

   A problem exists within existing RFCs that provide location to the
   UA ([RFC3825] and [RFC4776]) that type of location has to be updated
   every time a UA moves.  Not all UAs will move frequently, but some
   will.  Refreshing location every time a UA moves does not scale in
   certain networks/environments, such as IP based cellular networks,
   enterprise networks or service provider networks with mobile
   endpoints.  An 802.11 based access network is one example of this.
   Constantly updating location to endpoints might not scale in mobile
   (residential or enterprise or municipal) networks in which the UA is
   moving through more than one network attachment point, perhaps as a
   person walks or drives with their UA down a neighborhood street or
   apartment complex or a shopping center.

   If the UA were provided a URI reference to retain and hand out when
   it wants or needs to convey its location (in a protocol other than
   DHCP), a Location-URI reference that would not change as the UA'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.  It also relieves the UA from having to determine when it
   has moved far enough to consider asking for a refresh of its
   location.  Many endpoints will not have this ability, so relying on
   it could prove fruitless.  Once the UA has a Location-URI, a service
   provider, however it Sights the Location Target, as described in RFC
   3693 [RFC3693], would merely update the actual location in the LIS
   record, i.e., the URI the UA already points towards.  This document
   does not define how this update is done, as it will not be done with
   DHCP.


Polk                       Expires May 3 2009                  [Page 3]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008


   In enterprise networks, if a known location is assigned to each
   individual Ethernet port in the network, a device that attaches to
   the network a wall-jack (directly associated with a specific
   Ethernet Switch port) will be associated with a known location via a
   unique circuit-ID that's used by the RAIO Option defined in RFC 3046
   [RFC3046].  This assumes wall-jacks have an updated wiremap
   database.  RFC 3825 and RFC 4776 would return an LCI value of
   location.  This document specifies how a Location-URI is returned by
   DHCP.  Behind the DHCP server, in the backend of the network, via
   the (logical entity of a) LIS has a PIDF-LO in each location record
   a URI points to.

   If an 802.11 Access Port (AP) is at a specific known location within
   this enterprise network, all wireless Ethernet devices attaching to
   the network through this AP would be given the same location in
   their respective location records because the DHCP server would know
   each device was attaching from a known location, in this case, the
   same location.  This is assuming no 802.11 triangulation is
   occurring, this would give a more precise location to be placed in
   the location record (URI) of each device.

   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.

   The means of challenge by any given LIS can vary, and a policy
   established by a rulemaker [RFC3693] for a Location Target as to
   what type of challenge(s) are used, how strong a challenge is used
   or how precise the location information is given to a requestor. All
   of this is outside the scope of this document (since this will not
   be accomplished using DHCP).

   This document IANA registers the new DHC Option for a Location URI.


2.  DHC Location-URI Elements

   DHCP is a binary Protocol; URIs are alphanumeric (text) based.
   There is one byte per URI character.













Polk                       Expires May 3 2009                  [Page 4]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

   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 |          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.

   Valid-For:     The time, in seconds, this URI is to be considered
                  Valid for dereferencing.

   Location-URI:  The Location-by-Reference URI for the client

   The <Valid-For> field indicates how long, in seconds, the client is
   to consider this Location-URI valid before performing a refresh of
   this Option, with a refreshed <Valid-For> value.  A refresh MAY be
   done merely at the normal DHCP refresh rate, or necessitated by this
   timer, perhaps with the client just requesting this Option be
   refreshed.

   It is RECOMMENDED when the counter associated with this <valid-for>
   value has passed, the client perform a refresh of this Option.  For
   example, if 600 was the initial value of the <valid-for> field, when
   300 seconds have passed, the Option SHOULD be refreshed.


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.  That said, this
   Option SHOULD NOT be in a DISCOVER message, because there is zero
   knowledge by the client of which Server will answer.

   Caution SHOULD always be used involving the creation of large
   Options, meaning that this Option MAY need to be in its own INFORM,


Polk                       Expires May 3 2009                  [Page 5]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

   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, per RFC
   3396 [RFC3396].

   Per [RFC2131], subsequent Location-URI Options, which are
   non-concatenated, overwrite the previous value.

   Location URIs MUST NOT reveal identity information of the user of
   the device, since DHCP is a cleartext delivery protocol. For
   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 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 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.


Polk                       Expires May 3 2009                  [Page 6]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

   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.  This is not inconsistent with what's stated above.


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  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, but assumed to take place via an
      external 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 LIS, not the DHCP server for
      credentials and permissions.


3.2 Harmful URIs and URLs

   There are, in fact, some types of URIs that are not good to receive,
   due to security concerns.  For example, any URLs that can have
   scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web
   pages - that have scripts.  Therefore,

   o URIs received via this Option SHOULD NOT be sent to a
     general-browser to connect to a web page, because they could have
     harmful scripts.

   o This Option SHOULD NOT contain "data:" URLs, because they could
     contain harmful scripts.

   Instead of listing all the types of URIs and URLs that can be
   misused or potentially have harmful affects, Section 3.3 IANA
   registers acceptable Location-URI schemes (or types).


3.3  Valid Location-URI Schemes or Types

   Therefore, this document specifies which URI types are acceptable as
   a Location-URI scheme (or type):

   1. sip:
   2. sips:
   3. pres:


Polk                       Expires May 3 2009                  [Page 7]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

   These Location-URI types are IANA registered in section 4.2 of this
   document.
4.  IANA Considerations

4.1  IANA Considerations for DHCP Option Numbering

   IANA is requested to assigned a DHCP option code of XXX for the
   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.


4.2 IANA Considerations for Acceptable Location-URI Types

   IANA is requested to create a new registry for acceptable Location
   URI types.

   The following 3 URI types are registered by this document:

   1. sip:
   2. sips:
   3. pres:

   Any additional Location-URI types to be defined for use via
   this DHC Option MUST be done through a Standards Track 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
   to protect the integrity of the DHCP options.

   A real concern with RFC 3118 it is that not widely deployed because
   it requires keys on both ends of a communication to work (i.e., in
   the client and in the server).  Most implementations do not
   accommodate this.

   DHCP is a broadcast initially (a client looking for a server),
   unicast response (answer from a server) type of protocol.  It is not
   secure in a practical sense.  In today's infrastructures, it will be
   primarily used over a wired, switched Ethernet network, requiring
   physical access to within a wire to gain access.  Further, within an
   802.11 wireless network, the 802.11 specs have layer 2 security
   mechanisms in place to help prevent a Location-URI from being
   learned by an unauthorized entity.

   That said, having the Location-URI does not mean this unauthorized
   entity has the location of a client.  The Location-URI still needs
   to be dereferenced to learn the location of the client.  This
   dereferencing function, which is not done using DHCP, is done by


Polk                       Expires May 3 2009                  [Page 8]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

   requesting the location record at a Location Information Server, or
   LIS, which is a defined entity built to challenge each request it
   receives based on a joint policy of what is called a rulemaker.  The
   rulemaker, as defined in RFC 3693, configures the authentication and
   authorization policies for the location revelation of a Target.
   This includes giving out more or less precise location information
   in an answer, therefore it can answer a bad-hat, but not allow it
   from learning exactly where a user is.  The rulemaker, which is a
   combination of the default rules set up by the location provider and
   those decided on by the user of the Target device.  Likely, the
   rules the user wants will not be allowed to go past some limits
   established by the location provider, i.e., the administrator of the
   LIS, for various capability or security reasons.

   Penetrating a LIS is supposed to be hard, and hopefully vendors that
   implement a LIS accomplish this goal.

   As to the concerns about the Location-URI itself, as stated in the
   document here (in Section 3.), it must not have any user identifying
   information in the URI string itself.  The Location-URI also must be
   hard to guess that it belongs to a specific user.  There is some
   debate as to whether this Location-URI need be a random alphanumeric
   string or just unique.  If the latter, there is some debate as to
   the how we define unique. Is that through space as time, as RFC 3261
   defines a SIP Call-ID needs to be (meaning: never a duplicate, ever,
   by any device, ever)? Or is it unique to within a specific domain
   for as long as it is actively assigned to a client (plus some
   interval).

   When implementing a DHC server that will serve clients across an
   uncontrolled network, one should consider the potential security
   risks therein.


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.


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.


Polk                       Expires May 3 2009                  [Page 9]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008

 [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.

 [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-11.txt, "work in
           progress", Oct 2008

 [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

 [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference
           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
           progress", Oct 2008

Authors' Address

   James Polk
   3913 Treemont Circle
   Colleyville, Texas 76034
   USA

   EMail: jmpolk@cisco.com


Polk                       Expires May 3 2009                 [Page 10]

Internet-Draft      Geopriv DHCP Location-URI Option           Nov 2008



Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.


Intellectual Property

   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.
   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 May 3 2009                 [Page 11]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/