draft-ietf-geopriv-dhcp-lbyr-uri-option-05.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-06.txt 
Geopriv WG James Polk Geopriv WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track (PS) July 13, 2009 Intended status: Standards Track (PS) Sept 14, 2009
Expires: January 13, 2010 Expires: March 14, 2010
Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
Option for a Location Uniform Resource Identifier (URI) Option for a Location Uniform Resource Identifier (URI)
draft-ietf-geopriv-dhcp-lbyr-uri-option-05 draft-ietf-geopriv-dhcp-lbyr-uri-option-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or made material from IETF Documents or IETF Contributions published or made
publicly available before November 10, 2008. The person(s) publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an material outside the IETF Standards Process. Without obtaining an
skipping to change at page 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2010. This Internet-Draft will expire on March 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
skipping to change at page 2, line 19 skipping to change at page 2, line 19
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Abstract Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the downloading of a Location Uniform Resource Identifier Option for transmitting a client's geolocation Uniform Resource
(URI) of a client, to be dereferenced in a separate transaction. Identifier (URI) of a client, which can be dereferenced in a
Once the location URI is received by an endpoint, it can be separate transaction by the client or an entity the client sends
dereferenced by the client to learn its geographic location, or sent this URI to.
to another entity to learn this client's location.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 5 2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4
2.1. Overall Format of LuriElement Option in IPv4 . . . . . 5 2.1. Overall Format of LuriElement Option in IPv4 . . . . . 5
2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5
2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 6 2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 6
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7 3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 7
3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8
3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 9
3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1. Introduction 1. Introduction
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the downloading of a Location Uniform Resource Identifier Option for transmitting a client's geolocation Uniform Resource
(URI) of a client, to be dereferenced in a separate transaction. Identifier (URI). The DHCP implementation of the client can then
A client, for example, can be a Session Initiation Protocol (SIP) make this location information available to upper layer protocols
User Agent (UA) [RFC3261] (i.e., a Phone). This location URI for their usage. This location URI points a Location Server
points a Location Server [ID-LBYR-REQ] which has the geolocation of [ID-LBYR-REQ] which has the geolocation of the client (through means
the client (through means not defined in this document). not defined in this document). In this scenario, the DHCP client
is a Geopriv Target (i.e., the entity whose geolocation is
associated by the location URI).
The Location Server stores the Target's location a presence Applications using upper layer protocols within the Target can then
document, called a Presence Information Date Format - Location choose to deference this location URI and/or transmit the URI to
Object (PIDF-LO). Once a client attains this location URI, an another entity as a means of conveying where the Target is located.
application on the target can either dereference the URI to receive Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying
its PIDF-LO, or it can convey this location URI instead of conveying a location URI is also described in [ID-SIP-LOC]. Session Initiation
the location value in a message. Having a location URI has Protocol (SIP) is not the only protocol that can dereference a
advantages over having a PIDF-LO, especially when a target's location URI; there is also HTTP-Enabled Location Delivery (HELD)
location changes. With a location URI, when a target moves, the [ID-HELD-DEREF].
location URI does not. It can still be given out as the Target's
location. The opposite is true if the location is conveyed by value
in a message. Once the Target moves, the previously given location
is no longer valid, and it the Target wants to inform another entity
about its location, it has to send the PIDF-LO to the location
recipient (again).
The act of dereferencing location from a location URI is explained Having a location URI has advantages over having a PIDF-LO,
in [ID-SIP-LOC], which shows how a Location Recipient of a location especially when a target's location changes. With a location URI,
URI subscribes to a Location Server to attain the location of the when a target moves, the location URI does not change (at least
Target. If the dereferencer has permission, defined in [ID-GEO-POL], within the same domain). It can still be given out as the reference
the location of the target will be received. The Location Server to the Target's current location. The opposite is true if the
(LS) will grant permission to location inquires based on the rules location is conveyed by value in a message. Once the Target moves,
established by a Rule Holder [RFC3693]. The Location Server has the the previously given location is no longer valid, and it the Target
ability to challenge any request of a target's location, thereby wants to inform another entity about its location, it has to send
providing additive security properties before location revelation. the PIDF-LO to the location recipient (again).
There are use-cases, such as calling the appropriate Pizza Hut A Location Server (LS) stores the Target's location as a presence
without having to look up in a directory which store is closest, document, called a Presence Information Date Format - Location
where a UA knowing its location can call a Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server
main/national/international Pizza Hut number or address and let the is the entity contacted during the act of dereferencing a Target's
UA's location tell Pizza Hut enough information to have them location. If the dereferencing entity has permission, defined in
route/retarget the SIP request to the appropriate store within the [ID-GEO-POL], the location of the target will be received. The LS
Pizza Hut organization to deliver the pizza to the caller's will grant permission to location inquires based on the rules
location. 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 A problem exists within existing RFCs that provide location to the
UA ([RFC3825] and [RFC4776]), these DHCP Options for geolocation UA ([RFC3825] and [RFC4776]). These DHCP Options for geolocation
require an update of the entire location information (LI) every time values require an update of the entire location information (LI)
a client moves. Not all clients will move frequently, but some every time a client moves. Not all clients will move frequently,
will. Refreshing location every time a client moves does not scale but some will. Refreshing location values every time a client moves
in certain networks/environments, such as IP based cellular does not scale in certain networks/environments, such as IP-based
networks, enterprise networks or service provider networks with cellular networks, enterprise networks or service provider networks
mobile endpoints. An 802.11 based access network is one example of with mobile endpoints. An 802.11 based access network is one
this. Constantly updating LCI to endpoints might not scale in mobile example of this. Constantly updating LCI to endpoints might not
(residential or enterprise or municipal) networks in which the scale in mobile (residential or enterprise or municipal) networks in
client is moving through more than one network attachment point, which the client is moving through more than one network attachment
perhaps as a person walks or drives with their endpoint down a point, perhaps as a person walks or drives with their client down a
neighborhood street or apartment complex or a shopping center. neighborhood street or apartment complex or a shopping center or
through a municipality (that has IP connectivity as a service).
If the client were provided a location URI reference to retain and If the client were provided a location URI reference to retain and
hand out when it wants or needs to convey its location (in a 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 protocol other than DHCP), a location URI that would not change as
the client's location changes (within a domain), scaling issues the client's location changes (within a domain), scaling issues
would be significantly reduced to needing an update of the location would be significantly reduced to needing an update of the location
URI only when a client changes administrative domains - which is URI only when a client changes administrative domains - which is
much less often. This delivery of an indirect location has the much less often. This delivery of an indirect location has the
added benefit of not using up valuable or limited bandwidth to the added benefit of not using up valuable or limited bandwidth to the
client with the constant updates. It also relieves the client from client with the constant updates. It also relieves the client from
skipping to change at page 4, line 35 skipping to change at page 4, line 34
Ethernet Switch port) will be associated with a known location via a 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 unique circuit-ID that's used by the RAIO Option defined in RFC 3046
[RFC3046]. This assumes wall-jacks have an updated wiremap [RFC3046]. This assumes wall-jacks have an updated wiremap
database. RFC 3825 and RFC 4776 would return an LCI value of database. RFC 3825 and RFC 4776 would return an LCI value of
location. This document specifies how a location URI is returned location. This document specifies how a location URI is returned
using DHCP. Behind the DHCP server, in the backend of the network, using DHCP. Behind the DHCP server, in the backend of the network,
via the (logical entity of an) LS has a PIDF-LO to be dereferenced via the (logical entity of an) LS has a PIDF-LO to be dereferenced
with a location URI. with a location URI.
If local configuration has the requirement of only assigning unique If local configuration has the requirement of only assigning unique
location URIs to each client, then unique LbyRs will be given out, location URIs to each client, then unique location URIs will be
though they will all have the same location at the record, relieving given out, though they will all have the same location at the
the backend Sighter from individually maintaining each location record, relieving the backend Sighter or LS from individually
independently. maintaining each location independently.
This Option can be useful in WiMAX connected endpoints or IP This Option can be useful in IEEE 802.16e connected endpoints or IP
cellular endpoints. The location URI Option can be configured as a cellular endpoints. The location URI Option can be configured as a
client if there is a router, such as a residential home gateway, client if there is a router, such as a residential home gateway,
with the ability to communicate to downstream endpoints as a server. with the ability to communicate to downstream endpoints as a server.
How an LS challenges a dereference can vary, and a policy How an LS responds to a dereference request can vary, and a policy
established by a rulemaker [RFC3693] for a Location Target as to 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 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 used or how precise the location information is given to a
requestor. All of this is outside the scope of this document (since Location Recipient (LR). All of this is outside the scope of this
this will not be accomplished using DHCP). document (since this will not be accomplished using DHCP).
This document IANA registers the new IPv4 and IPv6 DHC Options for a This document IANA registers the new IPv4 and IPv6 DHC Options for a
location URI. location URI.
2. Format of the DHCP LuriElement Option 2. Format of the DHCP LuriElement Option
2.1 Overall Format of LuriElement Option in IPv4 2.1 Overall Format of LuriElement Option in IPv4
The LuriElement Option format for IPv4 is as follows: The LuriElement Option format for IPv4 is as follows:
0 1 2 3 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 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 | . | Code XXX | Length=XX | Ver | Resv | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. LuriElements... ... . LuriElements... ...
. (see section 2.3 for details) ... . . (see Section 2.3 for details) ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv4 Fields for this LuriElement Option Figure 1. IPv4 Fields for this LuriElement Option
Code XXX: The code for this DHCPv4 option (IANA assigned). Code XXX: The code for this DHCPv4 option (IANA assigned).
Length=XX: The length of this option, counted in bytes - not Length=XX: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change length Option, therefore the length value will change
based on the length of the LbyR within the Option. based on the length of the URI within the Option.
Ver: (4 bits) The version of this Option. This document Ver: (4 bits) The version of this Option. This document
defines version 1 of this Option. defines version 1 of this Option.
Resv: (4 bits) reserved for future use. Resv: (4 bits) reserved for future use.
LuriElement: see section 2.3 for details LuriElement: see Section 2.3 for details
2.2 Overall Format of LuriElement Option in IPv6 2.2 Overall Format of LuriElement Option in IPv6
The LuriElement Option format for IPv6 is as follows: The LuriElement Option format for IPv6 is as follows:
0 1 2 3 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 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 | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Resv | . | Ver | Resv | .
+---------------+ . +---------------+ .
. LuriElements... . . LuriElements... .
. (see section 2.3 for details) . . (see Section 2.3 for details) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 fields of this LuriElement Option Figure 2. IPv6 fields of this LuriElement Option
option-code: The code for this DHCPv6 option (IANA assigned). option-code: The code for this DHCPv6 option (IANA assigned).
option-len: The length of this option, counted in bytes - not option-len: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change length Option, therefore the length value will change
based on the shape within the Option. based on the shape within the Option.
skipping to change at page 6, line 51 skipping to change at page 6, line 50
indicates the location of the Location Target. indicates the location of the Location Target.
LuriType=2 Valid-For - The time, in seconds, this URI is to be LuriType=2 Valid-For - The time, in seconds, this URI is to be
considered Valid for dereferencing. The timer considered Valid for dereferencing. The timer
associated with this LuriType starts upon receipt of associated with this LuriType starts upon receipt of
this Option. this Option.
The LuriType=2 (Valid-For) indicates how long, in seconds, the The LuriType=2 (Valid-For) indicates how long, in seconds, the
client is to consider this LuriType=1 (location URI) valid client is to consider this LuriType=1 (location URI) valid
before performing a refresh of this Option, with a refreshed before performing a refresh of this Option, with a refreshed
LuriType=2 (Valid-For) value. A refresh MAY be done merely at the LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done
normal DHCP refresh rate, or necessitated by this timer, perhaps the normal DHCP refresh rate, or necessitated by this timer, perhaps
with the client only requesting this Option be refreshed. with the client only requesting this Option be refreshed.
It is RECOMMENDED when the counter associated with this LuriType=2 If the LuriType=2 (Valid-For) timer is received (solicited or
(Valid-For) value has passed, the client perform a refresh of this unsolicited), it is RECOMMENDED that the client refresh the Location
Option. For example, if 16000 was the initial value of the URI when the (Valid-For) counter value has reaches the halfway
point. For example, if 16000 was the initial value of the
LuriType=2 (Valid-For) value, when 8000 seconds have passed, the LuriType=2 (Valid-For) value, when 8000 seconds have passed, the
Option SHOULD be refreshed. Option SHOULD be refreshed.
The LuriType=2 (Valid-For) is not mandated for use by this document. The LuriType=2 (Valid-For) is not mandated for use by this document.
However, its presence MUST NOT cause any error in handling the However, its presence MUST NOT cause any error in handling the
location URI (i.e., if not understood, it MUST be ignored). location URI (i.e., if not understood, it MUST be ignored).
This Option format is highly extensible. Additional LuriType types This Option format is highly extensible. Additional LuriType types
created MUST be done so through IANA registration with peer review created MUST be done so through IANA registration with peer review
and an RFC. and an RFC.
skipping to change at page 7, line 39 skipping to change at page 7, line 40
OPTION or ACK message. OPTION or ACK message.
It is RECOMMENDED to avoid building URIs, with any parameters, It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed, per RFC message is larger than 255 bytes, concatenation is allowed, per RFC
3396 [RFC3396]. 3396 [RFC3396].
Per [RFC2131], subsequent LuriElement Options, which are Per [RFC2131], subsequent LuriElement Options, which are
non-concatenated, overwrite the previous value. non-concatenated, overwrite the previous value.
location URIs MUST NOT reveal identity information of the user of Location URIs MUST NOT reveal identity information of the user of
the device, since DHCP is a cleartext delivery protocol. For the device, since DHCP is a cleartext delivery protocol. For
example, location URIs such as example, location URIs such as
sips:34LKJH534663J54@example.com sips:34LKJH534663J54@example.com
SHOULD be done, providing no identity information, rather than a are to be done, providing no identity information, rather than a
location URI such as this location URI such as this
sips:aliceisinatlanta@example.com sips:aliceisat123mainstalanta@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 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 URI within the server. If a server does not have a
client's location, a communication path (or request) to an LS would
be necessary.
Further, any location revelation rules and policies a user has In the <presence> element of a PIDF-LO document, there is an
regarding the treatment of their actual location, and who can 'entity' attribute that identities what entity *this* document
access (what precision of) their location will be done with a (including the associated location) refers to. It is up to the
protocol other than DHCP, and likely will be done before anything PIDF-LO generator, either Location Server or an application in the
other than default authentication and authorization permissions are endpoint, to insert the identity in the 'entity' attribute. This
used when a Location Recipient requests for a Target's location. can be seen in [RFC4119]. The entity= discussion is orthogonal to
the identification information contained within the location URI.
Differentiating clients is done via client identifiers. Therefore, This Option is used only for communications between a DHCP client
in many implementations, each client can be assigned unique location and a DHCP server. It can be solicited (requested) by the client,
URIs, though this is not mandatory. or it can be pushed by the server without a request for it. DHCP
Options not understood are ignored. 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.
Any dereferencing of a client's location URI would not involve DHCP The deference of a target's location URI would not involve DHCP, but
as well, but more likely by an application layer protocol such as an application layer protocol, such as SIP or HTTP, therefore
SIP, through a subscription to the location URI on the LS. The LS dereferencing is out of scope of this document.
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 In the case of residential gateways being DHCP servers, they usually
perform as DHCP clients in a hierarchical fashion up into a service perform as DHCP clients in a hierarchical fashion up into a service
provider's network DHCP server(s), or learn what information to provider's network DHCP server(s), or learn what information to
provide via DHCP to residential clients through a protocol such as provide via DHCP to residential clients through a protocol, such as
PPP. In these cases, the location URI would likely indicate the PPP. In these cases, the location URI would likely indicate the
residence's civic address to all wired or wireless clients within residence's civic address to all wired or wireless clients within
that residence. This is not inconsistent with what's stated above. that residence.
3.1 Architectural Assumptions 3.1 Architectural Assumptions
The following assumptions have been made for use of this LuriElement The following assumptions have been made for use of this LuriElement
Option for a client to learn its location URI (in no particular Option for a client to learn its location URI (in no particular
order): order):
o Any user control (what [RFC3693] calls a 'ruleholder') for the o Any user control (what [RFC3693] calls a 'Ruleholder') for access
parameters and profile options a Location Object will have is out to the dereferencing step is assumed to be out of scope of this
of scope of this document, but assumed to take place via an document. An example authorization policy is in [ID-GEO-POL].
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 o The authorization vs. possession security model can be found in
[ID-LBYR-REQ], describing what is expected in each model of [ID-LBYR-REQ], describing what is expected in each model of
operation. It should be assumed that a location URI attained operation. It should be assumed that a location URI attained
using DHCP will operate under an authorization model. This means using DHCP will operate under an authorization model. This means
possessing the location URI does not give that entity the right possessing the location URI does not give that entity the right
to view the PIDF-LO of the target whose location is indicated in to view the PIDF-LO of the target whose location is indicated in
a presence document. The dereference transaction will be, in a presence document. The dereference transaction will be, in
many environments, challenged by the Location Server. The nature many environments, challenged by the Location Server. The nature
of this challenge is out of scope of this document. of this challenge is out of scope of this document.
o This document does not prevent some environments from operating o This document does not prevent some environments from operating
in a possession model, for example - tightly controlled in a possession model, for example - tightly controlled
enterprise networks, but this operation SHOULD NOT be assumed to enterprise networks, but this operation SHOULD NOT be assumed to
exist as a matter of local policy. The costs associated with exist as a matter of local policy. The costs associated with
authorization vs. possession models are discussed in section authorization vs. possession models are discussed in Section
3.3.2 of [ID-GEO-RA]. 3.3.2 of [ID-GEO-RA].
3.2 Harmful URIs and URLs 3.2 Harmful URIs and URLs
There are, in fact, some types of URIs that are not good to receive, 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 due to security concerns. For example, any URLs that can have
scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web scripts, such as "data:" URLs, and some "HTTP:" URLs that go to web
pages that have scripts. Therefore, pages that have scripts. Therefore,
o URIs received via this Option SHOULD NOT be sent to a o URIs received via this Option SHOULD NOT be sent to a
skipping to change at page 9, line 46 skipping to change at page 9, line 32
3.3 Valid Location URI Schemes or Types 3.3 Valid Location URI Schemes or Types
This section specifies which URI types are acceptable as a location This section specifies which URI types are acceptable as a location
URI scheme (or type) for this DHCP Option: URI scheme (or type) for this DHCP Option:
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
These location URI types are IANA registered in section 4.2 of this These location URI types are IANA registered in Section 4.2 of this
document. document.
4. IANA Considerations 4. IANA Considerations
4.1 The IPv4 Option number for this Option 4.1 The IPv4 Option number for this Option
This document IANA registers this IPv4 Option number XXX (to be This document IANA registers this IPv4 Option number XXX (to be
assigned by IANA once this document becomes an RFC). assigned by IANA once this document becomes an RFC).
4.2 The IPv6 Option-Code for this Option 4.2 The IPv6 Option-Code for this Option
skipping to change at page 10, line 39 skipping to change at page 10, line 23
2. sips: 2. sips:
3. pres: 3. pres:
Any additional location URI types to be defined for use via Any additional location URI types to be defined for use via
this DHC Option need to be created and IANA registered with peer this DHC Option need to be created and IANA registered with peer
review and an RFC. review and an RFC.
4.5 IANA Considerations for LuriTypes 4.5 IANA Considerations for LuriTypes
IANA is requested to create a new registry for acceptable location IANA is requested to create a new registry for acceptable location
types defined in section 3.2 of this document, arranged similar to types defined in Section 3.2 of this document, arranged similar to
this: this:
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| LuriType | Name | Reference | | LuriType | Name | Reference |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| 1 | Location URI | RFC XXXX* | | 1 | Location URI | RFC XXXX* |
| 2 | Valid-For | RFC XXXX* | | 2 | Valid-For | RFC XXXX* |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
* RFC XXXX is to be replaced with this document's RFC-Editor RFC * RFC XXXX is to be replaced with this document's RFC-Editor RFC
skipping to change at page 11, line 16 skipping to change at page 10, line 49
Where critical decisions might be based on the value of this 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 in [RFC3118] SHOULD be used
to protect the integrity of the DHCP options. to protect the integrity of the DHCP options.
A real concern with RFC 3118 it is that not widely deployed because A real concern with RFC 3118 it is that not widely deployed because
it requires pre-shared keys to successfully work (i.e., in the it requires pre-shared keys to successfully work (i.e., in the
client and in the server). Most implementations do not client and in the server). Most implementations do not
accommodate this. accommodate this.
DHCP is a broadcast initially (a client looking for a server), DHCP, initially, is a broadcast request (a client looking for a
unicast response (answer from a server) type of protocol. It is not server), and a unicast response (answer from a server) type of
secure in a practical sense. In today's infrastructures, DHCP will protocol. It is not secure in a practical sense. In today's
be primarily used over a wired, switched Ethernet network, requiring infrastructures, DHCP will be primarily used over a wired, switched
physical access to within a wire to gain access. Further, within an Ethernet network, requiring physical access to within a wire to gain
802.11 wireless network, the 802.11 specs have layer 2 security access. Further, within an 802.11 wireless network, the 802.11
mechanisms in place to help prevent a location URI from being specs offer layer 2 security mechanisms to prevent a location URI
learned by an unauthorized entity. from being learned by an unauthorized entity.
That said, having the location URI does not mean an unauthorized That said, having the location URI does not mean an unauthorized
entity has the location of a client. The location URI still needs entity has the location of a client. The location URI still needs
to be dereferenced to learn the location of the client. This to be dereferenced to learn the location of the client. This
dereferencing function, which is not done using DHCP, is done by dereferencing function, which is not done using DHCP, is done by
requesting the location record at a Location Server, which is a requesting the location record at a Location Server, which can
defined entity built to challenge each request it receives based on challenge each request it receives based on the policy provided by
a joint policy of what is called a rulemaker. The ruleholder, as the Ruleholder. The Ruleholder, as defined in RFC 3693, configures
defined in RFC 3693, configures the authentication and authorization the authentication and authorization policies for the location
policies for the location revelation of a Target. This includes revelation of a Target. This includes giving out more or less
giving out more or less precise location information in a response, precise location information in a response, therefore it can answer
therefore it can answer a bad-hat, but not allow it from learning a bad-hat, but not allow it from learning exactly where a client is.
exactly where a 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 LS, for various
capability or security reasons.
Penetrating an LS is supposed to be hard, and hopefully vendors that Penetrating an LS is supposed to be hard, and hopefully vendors that
implement an LS accomplish this goal. implement 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 URI itself, as stated in the 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 document here (in Section 3), it MUST NOT have any user identifying
information in the URI user-part/string itself. The location URI 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. also needs to 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
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 When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security uncontrolled network, one should consider the potential security
risks therein. risks therein.
6. Acknowledgements 6. Acknowledgements
Thanks to James Winterbottom, Marc Linsner, Roger Marshall and Thanks to James Winterbottom, Marc Linsner, Roger Marshall and
Robert Sparks for their useful comments. And to Lisa Dusseault for Robert Sparks for their useful comments. And to Lisa Dusseault for
her concerns about the types of URIs that can cause harm. To her concerns about the types of URIs that can cause harm. To
Richard Barnes for inspiring a more robust Security Considerations Richard Barnes for inspiring a more robust Security Considerations
section. To Hannes Tschofenig and Ted Hardie for riding me to section. To Hannes Tschofenig and Ted Hardie for riding me to
comply with their concerns. comply with their concerns, including a good scrubbing of the nearly
final doc.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
skipping to change at page 13, line 4 skipping to change at page 12, line 18
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic [RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November Host Configuration Protocol (DHCPv4)", RFC 3396, November
2002 2002
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005 Format", RFC 4119, December 2005
7.2. Informative References 7.2. Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in [ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
Thomson, M. Dawson, "A Location Dereferencing Protocol Using
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, November 2006 Information ", RFC 4776, November 2006
[ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference [ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference
[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
"Geopriv Requirements", RFC 3693, February 2004 "Geopriv Requirements", RFC 3693, February 2004
 End of changes. 41 change blocks. 
164 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/