Network WG James Polk
Internet-Draft Cisco Systems
Intended status: Proposed Standard Mar 12, 2012
Expires: Sept 12, 2012
Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6Option for a Location Uniform Resource Identifier (URI)draft-ietf-geopriv-dhcp-lbyr-uri-option-14
Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource
Identifier (URI). 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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 September 12, 2012.
Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Polk Expires Sept 12, 2012 [Page 1]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
location is conveyed by value in a message. Once the Target moves,
the previously given location is no longer valid, and if the Target
wants to inform another entity about its location, it has to send
the PIDF-LO to the location recipient (again).
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
is the entity contacted during the act of dereferencing a Target's
location. If the dereferencing entity has permission, defined in
[ID-GEO-POL], the location of the target will be received. The LS
will grant permission to location inquires based on the rules
established by a Rule Holder [RFC3693]. The LS has the ability to
challenge any request for a target's location, thereby providing
additive security properties before location revelation.
A problem exists within existing RFCs that provide location to the
UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation
values require an update of the entire location information (LI)
every time a client moves. Not all clients will move frequently,
but some will. Refreshing location values every time a 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 LCI to endpoints might not
scale in mobile (residential or enterprise or municipal) networks in
which the client is moving through more than one network attachment
point, perhaps as a person walks or drives with their client down a
neighborhood street or apartment complex or a shopping center or
through a municipality (that has IP connectivity as a service).
If the client was 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 URI that would not change as
the client's location 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
client with the constant updates. It also relieves the client from
having to determine when it has moved far enough to consider asking
for a refresh of its location.
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
using DHCP. The location URI points to a PIDF-LO contained on an
Polk Expires Sept 12, 2012 [Page 3]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
LS. Performing a dereferencing transaction, that Target's PIDF-LO
will be returned. If local configuration has the requirement of
only assigning unique location URIs to each client at the same
attachment point to the network (i.e., same RJ-45 jack or same
802.11 Access Point - except when triangulation is used), then
unique location URIs will be given out, though they will all have
the same location at the record, relieving the backend Sighter or LS
from individually maintaining each location independently.
This Option can be useful in IEEE 802.16e connected endpoints or IP
cellular endpoints. The location URI Option can be configured on a
router, such as a residential home gateway, such that the router
receives this Location URI Option as a client with the ability to
communicate to downstream endpoints as a server.
How an LS responds to a dereference request can vary, and a policy
established by a Ruleholder [RFC3693] for a Location Target as to
what type of challenge(s) is to be used, how strong a challenge is
used or how precise the location information is given to a
Location Recipient (LR). This document does not provide mechanisms
for the LS to tell the client about policies or for the client to
specify a policy for the LS. While an LS should apply an appropriate
access-control policy, clients must assume that the LS will provide
location in response to any request (following the possession model
[RFC5808]). For further discussion of privacy, see the Security
Considerations.
This document IANA-registers the new IPv4 and IPv6 DHCP Options for
a location URI.
2. Format of the DHCP LocationURI Option2.1 Overall Format of LocationURI Option in IPv4
The LocationURI 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 | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. LocationURI... ...
. (see Section 2.3 for details) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv4 Fields for this LocationURI Option
Code XXX: The code for this DHCPv4 option (IANA assigned).
Length=XX: The length of this option, counted in bytes - not
Polk Expires Sept 12, 2012 [Page 4]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
always a one-byte unsigned integer.
LuriValue: The LocationURI value, as described in detail below.
The LuriTypes this document defines for a point are:
LuriType=1 Location URI - This field, in bytes, is the URI
pointing at the location record where the PIDF-LO for
the Location Target resides. The LuriValue of
LuriType=1 is always represented in UTF-8.
LuriType=2 Valid-For - The time, in seconds, this URI is to be
considered Valid for dereferencing. The timer
associated with this LuriType starts upon receipt of
this Option by the client. The LuriValue of LuriType=2
is always represented as a four-byte unsigned integer.
The Valid-For (LuriType=2) indicates how long, in seconds, the
client is to consider this location URI (LuriType=1) valid.
Applications MUST NOT make use of a location URI after it becomes
invalid (i.e., after the Valid-For timer expires).
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.
The Valid-For timer is used only at the application layer, as an
indication of when the URI can be used to access location. It is
independent of the DHCP lease timer, and in no way related to the
DHCP state machine. Clients MUST NOT trigger an automatic DHCP
refresh on expiry of the Valid-For timer; rather, they should follow
normal DCHP mechanics.
Server operators should consider the relation between the Valid-For
time and the lease time. Clients typically request a lease refresh
when half the lease time is up. If the Valid-For time is less than
the typical refresh rate (i.e., half the lease time), then for the
remaining interval, clients will run the risk of not having a usable
location URI for applications. If the Valid-For time is less than
half the typical refresh rate, it is a near certainty clients will
not have a usable location URI for the interval between the
Valid-For time and the typical refresh time for applications.
For example, if a lease is set to 24 hours, the typical refresh
request is set to initiate at the 12 hour mark. If the Valid-For
timer is set to less than 24 hours, but more than 12 hours (in this
example), the client might not be refreshed at the 12 hour mark and
runs the risk of not have a location URI for applications that
request it. If, on the other hand, the Valid-For timer is less than
12 hours (in this example, which is before a typical client would
Polk Expires Sept 12, 2012 [Page 6]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
ask for a refresh, applications will be without a usable location
URI until the full refresh has been received.
It should be expected that clients will overwrite any previous
Option values when receiving a new instance of that Option number.
The Valid-For (LuriType=2) offers no meaningful information without
an accompanying Location URI (LuriType=1), therefore a Valid-For
(LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
The Valid-For (LuriType=2) is not mandated for use by this document.
However, its presence MUST NOT cause any error in handling the
location URI (i.e., if not understood, it MUST be ignored).
This Option format is highly extensible. Additional LuriType types
created MUST be done so through IANA registration with a standards
track RFC.
3. DHCP Option Operation
The [RFC3046] RAIO can 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, per RFC3396 [RFC3396].
Per [RFC2131], subsequent LocationURI 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, creating a location URI such as
sips:34LKJH534663J54@example.com
is better than a location URI such as
sips:aliceisat123mainstalantageorgiaus@example.com
The username portion of the first example URI provides no direct
identity information (in which 34LKJH534663J54 is considered to be a
random number in this example).
In the <presence> element of a PIDF-LO document, there is an
Polk Expires Sept 12, 2012 [Page 7]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
'entity' attribute that identities what entity *this* document
(including the associated location) refers to. 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 considerations for populating the
entity attribute value in a PIDF-LO document are independent from
the considerations for avoiding exposing identification information
in the username part of a location URI.
This Option is used 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 MUST be ignored [RFC2131]. A DHCP server
supporting this Option might or might not have the location of a
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
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.
3.1 Architectural Assumptions
The following assumptions have been made for use of this LocationURI
Option for a client to learn its location URI (in no particular
order):
o Any user control (what [RFC3693] calls a 'Ruleholder') for access
to the dereferencing step is assumed to be out of scope of this
document. An example authorization policy is in [ID-GEO-POL].
o The authorization vs. possession security model can be found in
[RFC5808], describing what is expected in each model of
operation. It should be assumed that a location URI attained
using DHCP will operate under an possession model by default.
Polk Expires Sept 12, 2012 [Page 8]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
An authorization model can be instituted as a matter of local
policy. An authorization model 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 be challenged by the Location Server
only in an authorization model. The nature of this challenge is
out of scope of this document.
o This document does not prevent some environments from operating
in an authorization model, for example - in less tightly
controlled networks. The costs associated with authorization vs.
possession models are discussed in Section 3.3.2 of [RFC5606].
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 MUST NOT be automatically sent to a
general-browser to connect to a web page, because they could have
harmful scripts.
o This Option MUST 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
This section specifies which URI types are acceptable as a location
URI scheme (or type) for this DHCP Option:
1. sip:
2. sips:
3. pres:
4. http:
5. https:
URIs using the "pres" scheme are dereferenced using the presence
event package for SIP [RFC3856], so they will reference a PIDF-LO
document when location is available. Responses to requests for URIs
with other schemes ("sip", "sips", "http", and "https") MUST have
MIME type 'application/pidf+xml'. Alternatively, HTTP and HTTPS
URIs MAY refer to information with MIME type 'application/held+xml',
in order to support HELD dereferencing [ID-HELD-DEREF]. Clients can
indicate which MIME types they support using the "Accept" header
Polk Expires Sept 12, 2012 [Page 9]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
field in SIP [RFC3261] or HTTP [RFC2616].
See RFC 3922 [RFC3922] for using the pres: URI with XMPP.
It is RECOMMENDED that implementers follow Section 4.6 of RFC 6442
[RFC6442] as guidance regarding which Location URI schemes to
provide in DHCP. That document discusses what a receiving entity
does when receiving a URI scheme that is not understood. Awareness
to the two URI types there is important for conveying location, if
SIP is used to convey a Location URI provided by DHCP.
4. IANA Considerations4.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 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 registry require 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
Polk Expires Sept 12, 2012 [Page 10]

Internet-Draft Geopriv DHCP Location URI Option Mar 2012
it 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.
Once a client has a 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"). With the LuriTypes defined in this document,
the DHCP option for delivering location URIs can only tell the user
how long the URI will be valid. 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, location servers
SHOULD apply appropriate access control policies, for example by
limiting the number of queries that any given client can make, or
limiting access to users within an enterprise.
Extensions to this option, such as [ID-POLICY-URI] can provide
mechanisms for accessing and provisioning policy. Giving users
access to policy information will allow them to make more informed
decisions about how to use their location URIs. Allowing users to
provide policy information to the LS will enable them to tailor
access control policies to their needs (within the bounds of policy
that the LS will accept).
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.
When implementing a DHCP 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, 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.
Polk Expires Sept 12, 2012 [Page 11]