Geopriv WG                                                   James Polk
Internet-Draft                                            Cisco Systems
Intended status:  Standards Track (PS)                    March 9,                    July 13, 2009
Expires: September 9, 2009 January 13, 2010

        Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
         Option for a Location Uniform Resource Identifier (URI)
              draft-ietf-geopriv-dhcp-lbyr-uri-option-04
              draft-ietf-geopriv-dhcp-lbyr-uri-option-05

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.  This document may contain
   material from IETF Documents or IETF Contributions published or made
   publicly available before November 10, 2008.  The person(s)
   controlling the copyright in some of this material may not have
   granted the IETF Trust the right to allow modifications of such
   material outside the IETF Standards Process.  Without obtaining an
   adequate license from the person(s) controlling the copyright in
   such materials, this document may not be modified outside the IETF
   Standards Process, and derivative works of it may not be created
   outside the IETF Standards Process, except to format it for
   publication as an RFC or to translate it into languages other than
   English.

   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 September 9, 2009. January 13, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

Legal

   This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Abstract

   This document creates a Dynamic Host Configuration Protocol (DHCP)
   Option for the downloading of a Location Uniform Resource Identifier
   (URI)
   pointing to the geolocation record of an endpoint.  This URI, called a Location-by-Reference (LbyR), points client, to be dereferenced in a record on a location
   server which tracks the geolocation of the endpoint. separate transaction.
   Once
   downloaded the location URI is received by an endpoint, this LbyR it can be forwarded
   dereferenced by the client to another
   entity, learn its geographic location, or sent
   to be dereferenced if this another entity wants to learn the
   geolocation of the sender endpoint. this client's location.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Format of the DHCP LbyrElement LuriElement Option . . . . . . . . . . . .  5
       2.1.  Overall Format of LbyrElement LuriElement Option in IPv4  . . . . .  5
       2.2.  Overall Format of LbyrElement LuriElement Option in IPv6  . . . . .  6  5
       2.3.  LbyrElement  LuriElement Format for both IPv4 and IPv6 . . . . . . .  6
   3.  DHC Option Operation  . . . . . . . . . . . . . . . . . . . .  7
       3.1 Architectural Assumptions . . . . . . . . . . . . . . . .  9  8
       3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . .  9
       3.3 Valid Location URI Schemes or Types . . . . . . . . . . .  9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . 10 11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 11 12
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 12
       7.1. Normative References . . . . . . . . . . . . . . . . . . 12
       7.2. Informative References . . . . . . . . . . . . . . . . . 12 13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 13

   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 Location Uniform Resource Identifier
   (URI)
   pointing to the geolocation record of an endpoint. a client, to be dereferenced in a separate transaction.
   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), location URI
   points to a record on a location
   server Location Server [ID-LBYR-REQ] which tracks has the geolocation of
   the endpoint client (through means not defined in this document).

   The LbyR record Location Server stores the Geolocation of Target's location a presence
   document, called a Presence Information Date Format - Location Target, where the
   Object (PIDF-LO).  Once a client attains this location of
   the Location Target changing at URI, an
   application on the record, but not in target can either dereference the URI used to access receive
   its PIDF-LO, or it can convey this location URI instead of conveying
   the record.  Once downloaded by an endpoint (the target location value in
   this case), this LbyR a message.  Having a location URI has
   advantages over having a PIDF-LO, especially when a target's
   location changes.  With a location URI, when a target moves, the
   location URI does not. It can still be forwarded to another entity, for
   example, using SIP given out as defined the Target's
   location. The opposite is true if the location is conveyed by value
   in [ID-SIP-LOC], a message. Once the Target moves, the previously given location
   is no longer valid, and it the Target wants to be dereferenced if
   this second inform another entity wants
   about its location, it has to learn send the geolocation of PIDF-LO to the Location
   Target. location
   recipient (again).

   The act of dereferencing location from a location URI is explained
   in [ID-SIP-LOC], which demonstrates shows how a Location Recipient of an LbyR a location
   URI 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. received.  The Location Server
   (LS) will grant permission to location inquires based on the rules
   established by a Rule Holder [RFC3693].  The Location Server has the
   ability to challenge any Location Seeker's request, request of a target's location, thereby
   providing additive security properties to before location revelation.

   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 closest,
   where 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]), these types of DHCP Options for geolocation requires
   require an update of the entire location information
   (LI)every (LI) every time
   a UA client moves.  Not all UAs clients will move frequently, but some
   will.  Refreshing location every time a UA client 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 LI LCI to the endpoints might not scale in mobile
   (residential or enterprise or municipal) networks in which the UA
   client is moving through more than one network attachment point,
   perhaps as a person walks or drives with their UA endpoint down a
   neighborhood street or apartment complex or a shopping center.

   If the UA client were provided a location URI reference to retain and
   hand out when it wants or needs to convey its location (in a
   protocol other than DHCP), a Location location URI reference that would not change as
   the UA's client's location changes, changes (within a domain), scaling issues
   would be significantly reduced to needing an update of the location
   URI only when a client changes administrative domains - which is
   much less often.  This delivery of an indirect location has the
   added benefit of not using up valuable or limited bandwidth to the UA
   client with the constant updates.  It also relieves the UA client 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 record the URI points towards.  This document does
   not define how this update is done, as it will not be done with
   DHCP.

   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 location URI is returned by
   using 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 Location 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 could 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 (logical entity of an) LS has a more precise location PIDF-LO to be placed in
   the dereferenced
   with a location record (URI) of each device. URI.

   If local configuration has the requirement of only assigning unique
   Location
   location URIs to each client, then unique LbyRs will be given out,
   though they will all have the same location at the record, relieving
   the backend Sighter from individually maintaining each location
   independently.

   This Option can be useful in WiMAX connected endpoints or IP
   cellular endpoints.  The Location location URI Option can be configured as a
   client if it there 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

   How an LS challenges a dereference can vary, and a policy
   established by a rulemaker [RFC3693] for a Location Target as to
   what type of challenge(s) are is to be 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 IPv4 and IPv6 DHC Options for a
   Location
   location URI.

2.  Format of the DHCP LbyrElement LuriElement Option

2.1 Overall Format of LbyrElement LuriElement Option in IPv4

   The LbyrElement LuriElement Option format for IPv4 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    |   Length=XX   |  Ver  | Resv  |               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               .
    .                         LbyrElements...                         LuriElements...                      ...
    .                  (see section 2.3 for details) ...            .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 1. IPv4 Fields for this LbyrElement LuriElement Option

   Code XXX:  The code for this DHCPv4 option (IANA assigned).

   Length=XX: The length of this option, counted in bytes - not
              counting the Code and Length bytes. This is a variable
              length Option, therefore the length value will change
              based on the length of the LbyR within the Option.

   Ver:       (4 bits) The version of this Option. This will specify document
              defines version 1. 1 of this Option.

   Resv:      (4 bits) reserved for future use.

   LbyrElement:

   LuriElement: see section 2.3 for details

2.2 Overall Format of LbyrElement LuriElement Option in IPv6

   The LbyrElement LuriElement Option format for IPv6 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          option-code          |           option-len          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Ver  | Resv  |                                               .
    +---------------+                                               .
    .                        LbyrElements...                        LuriElements...                        .
    .                 (see section 2.3 for details)                 .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2. IPv6 fields of this LbyrElement LuriElement Option

   option-code: The code for this DHCPv6 option (IANA assigned).

   option-len:  The length of this option, counted in bytes - not
                counting the Code and Length bytes. This is a variable
                length Option, therefore the length value will change
                based on the shape within the Option.

   Ver:         See above (Section 2.1). This will specify version 1.

   Resv:        See above (Section 2.1).

   LbyrElement:

   LuriElement: see below (Section 2.3 for details).

2.3 LbyrElement LuriElement Format for both IPv4 and IPv6

   The LbyrElement, LuriElement, in both DHCPv4 and DHCPv6, have the following
   format:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    LbyrType    LuriType    |   LbyrLength   LuriLength   |   LbyrValue   LuriValue                ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3. LbyrElement LuriElement Format for both IPv4 and IPv6

      LbyrType:

      LuriType:   A one-byte identifier of the data location value.

      LbyrLength:

      LuriLength: The length, in bytes, of the LbyrValue, LuriValue, not including
                  the LbyrLength LuriLength field itself, up to a maximum of 255
                  bytes.

      LbyrValue:

      LuriValue:  The LbyrElement LuriElement value, as described in detail below.
                  The LbyrValue LuriValue is always in UTP-8.

   The LbyrTypes LuriTypes this document defines (and IANA registers) for a point
   are:

      LbyrType=1 Location-by-Reference

      LuriType=1 Location URI - This is the URI pointing at the
                 location record where the PIDF-LO resides which
                 indicates the location of the Location Target.

      LbyrType=2

      LuriType=2 Valid-For - The time, in seconds, this URI is to be
                 considered Valid for dereferencing. The timer
                 associated with this LbyrType LuriType starts upon receipt of
                 this Option.

   The LbyrType=2 LuriType=2 (Valid-For) indicates how long, in seconds, the
   client is to consider this LbyrType=1 (Location-by-Reference LuriType=1 (location URI) valid
   before performing a refresh of this Option, with a refreshed
   LbyrType=2
   LuriType=2 (Valid-For) value.  A refresh MAY be done merely at the
   normal DHCP refresh rate, or necessitated by this timer, perhaps
   with the client only requesting this Option be refreshed.

   It is RECOMMENDED when the counter associated with this LbyrType=2 LuriType=2
   (Valid-For) value has passed, the client perform a refresh of this
   Option.  For example, if 16000 was the initial value of the
   LbyrType=2
   LuriType=2 (Valid-For) value, when 8000 seconds have passed, the
   Option SHOULD be refreshed.

   The LbyrType=2 LuriType=2 (Valid-For) is not mandated for use by this document.
   However, its presence MUST NOT cause any error in handling the
   Location
   location URI (i.e., if not understood, it MUST be ignored).

   This Option format is highly extensible. Additional LbyrType LuriType types
   created MUST be done so through IANA registration with peer review
   and an RFC.

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,
   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 LbyrElement LuriElement Options, which are
   non-concatenated, overwrite the previous value.

   Location

   location URIs MUST NOT reveal identity information of the user of
   the device, since DHCP is a cleartext delivery protocol. For
   example, Location location URIs such as

      sips:34LKJH534663J54@example.com

   SHOULD be done, providing no identity information, rather than a
   Location
   location URI such as this

      sips:aliceisinatlanta@example.com

   In the <presence> element of the PIDF-LO there is an entity=
   attribute that identities the target of *this* location.  It is up
   to the PIDF-LO generator, either Location Server or an application
   in the endpoint, to insert the identity in the entity= attribute.
   This can be seen in [RFC4119].  The entity= discussion is orthogonal
   to the identification information contained within the location URI.

   This Option is for only for 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
   location URI within the server.  If a server does not have a
   client's location, a communication path (or request) to a LIS an LS 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 a
   protocol 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, Recipient 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, location
   URIs, though this is not mandatory.

   Any dereferencing of a client's Location location URI would not involve DHCP
   either,
   as well, but more likely by an application layer protocol such as
   SIP, through a subscription to the Location location URI on the LIS. LS. The LIS LS
   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
   provide via DHCP to residential clients through a protocol such as
   PPP.  In these cases, the Location 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 LbyrElement LuriElement
   Option for a client to learn its Location location URI (in no particular
   order):

   o  Any user control (what Geopriv [RFC3693] calls a 'rulemaker') 'ruleholder') for the
      parameters and profile options a Location-Object 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 Location Server
      (direct or indirect).  Some of this is described in [ID-GEO-POL].

   o  The authorization vs. possession security model can be found in
      [ID-LBYR-REQ], describing what is expected in each model of
      operation.  It should be assumed that a location URI attained
      using DHCP will operate under an authorization model. This means
      possessing the location URI does not give that entity the right
      to view the PIDF-LO of the target whose location is indicated in
      a presence document.  The dereference transaction will have be, in
      many environments, challenged by the Location Server.  The nature
      of this challenge 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). document.

   o  Any user attempting to gain access to the information at this URI
      will be challenged by the LIS,  This document does not the DHCP server prevent some environments from operating
      in a possession model, for
      credentials and permissions. example - tightly controlled
      enterprise networks, but this operation SHOULD NOT be assumed to
      exist as a matter of local policy. The costs associated with
      authorization vs. possession models are discussed in section
      3.3.2 of [ID-GEO-RA].

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 location URI schemes (or types).

3.3  Valid Location URI Schemes or Types

   Therefore, this document

   This section specifies which URI types are acceptable as a Location location
   URI scheme (or type): type) for this DHCP Option:

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

   These Location location URI types are IANA registered in section 4.2 of this
   document.

4.  IANA Considerations

4.1 The IPv4 Option number for this Option

   This document IANA registers this IPv4 Option number XXX (to be
   assigned by IANA once this document becomes an RFC).

4.2 The IPv6 Option-Code for this Option

   This document IANA registers this IPv6 Option-Code XXX (to be
   assigned by IANA once this document becomes an RFC).

4.3 The Version number for this Option

   This document IANA registers the version number 1 of this Option.

4.4 IANA Considerations for Acceptable Location URI Types

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

   The following 3 URI types are registered by this document:

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

   Any additional Location location URI types to be defined for use via
   this DHC Option need to be created and IANA registered with peer
   review and an RFC.

4.5 IANA Considerations for LuriTypes

   IANA is requested to create a new registry for acceptable location
   types defined in section 3.2 of this document, arranged similar to
   this:

   +------------+----------------------------------------+-----------+
   |  LuriType  |   Name                                 | Reference |
   +------------+----------------------------------------+-----------+
   |     1      |   Location URI                         | RFC XXXX* |
   |     2      |   Valid-For                            | RFC XXXX* |
   +------------+----------------------------------------+-----------+

    * RFC XXXX is to be replaced with this document's RFC-Editor RFC
      number.

   Additions to this list require a standards track RFC.

5.  Security Considerations

   Where critical decisions might be based on the value of this
   Location
   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 pre-shared keys on both ends of a communication to successfully 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 DHCP 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 location URI from being
   learned by an unauthorized entity.

   That said, having the Location location URI does not mean this an unauthorized
   entity has the location of a client.  The Location 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
   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, ruleholder, 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, a response,
   therefore it can answer a bad-hat, but not allow it from learning
   exactly where a user client 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, LS, for various
   capability or security reasons.

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

   It is envisioned, as stated in the text above, as described both in
   [ID-LBYR-REQ] and [ID-GEO-RA], this Option MUST be assumed to
   operate under an authorization model, vs. a much more open
   possession model.  This model choice is not strictly enforced, but
   implementations (in the text above) have been advised to build with
   this in mind.

   As to the concerns about the Location location URI itself, as stated in the
   document here (in Section 3.), it must not MUST NOT have any user identifying
   information in the URI string user-part/string itself.  The Location location URI
   also must needs to be hard to guess that it belongs to a specific user.
   There is some debate as to whether this Location 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
   and 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.  To Hannes Tschofenig and Ted Hardie for riding me to
   comply with their concerns.

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.

 [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
           Host Configuration Protocol (DHCPv4)", RFC 3396, November
           2002
 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
           Format", RFC 4119, December 2005

7.2.  Informative References

 [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "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
 [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
 [ID-GEO-RA] J. Peterson, T. Hardie, J. Morris, " Implications of
           'retransmission-allowed' for SIP Location Conveyance",

Authors' Address

   James Polk
   3913 Treemont Circle
   Colleyville, Texas 76034
   USA

   Email: jmpolk@cisco.com