draft-ietf-geopriv-dhcp-lbyr-uri-option-09.txt   draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt 
Geopriv WG James Polk Geopriv WG James Polk
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track (PS) Oct 13, 2010 Intended status: Proposed Standard Feb 11, 2011
Expires: April 13, 2011 Expires: August 11, 2011
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-09 draft-ietf-geopriv-dhcp-lbyr-uri-option-10
Abstract Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP) This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends separate transaction by the client or an entity the client sends
this URI to. this URI to.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 13, 2011. This Internet-Draft will expire on August 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the BSD License. warranty as described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Format of the DHCP LuriElement Option . . . . . . . . . . . . 4 2. Format of the DHCP LocationURI Option . . . . . . . . . . . . 4
2.1. Overall Format of LuriElement Option in IPv4 . . . . . 4 2.1. Overall Format of LocationURI Option in IPv4 . . . . . 4
2.2. Overall Format of LuriElement Option in IPv6 . . . . . 5 2.2. Overall Format of LocationURI Option in IPv6 . . . . . 5
2.3. LuriElement Format for both IPv4 and IPv6 . . . . . . . 5 2.3. LocationURI Format for both IPv4 and IPv6 . . . . . . . 5
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 6 3. DHCP Option Operation . . . . . . . . . . . . . . . . . . . . 6
3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8 3.1 Architectural Assumptions . . . . . . . . . . . . . . . . 8
3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8 3.2 Harmful URIs and URLs . . . . . . . . . . . . . . . . . . 8
3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9 3.3 Valid Location URI Schemes or Types . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 50 skipping to change at page 2, line 50
is a Geopriv Target (i.e., the entity whose geolocation is is a Geopriv Target (i.e., the entity whose geolocation is
associated by the location URI). associated by the location URI).
Applications using upper layer protocols within the Target can then Applications using upper layer protocols within the Target can then
choose to deference this location URI and/or transmit the URI to choose to deference this location URI and/or transmit the URI to
another entity as a means of conveying where the Target is located. another entity as a means of conveying where the Target is located.
Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying
a location URI is also described in [ID-SIP-LOC]. Session Initiation a location URI is also described in [ID-SIP-LOC]. Session Initiation
Protocol (SIP) is not the only protocol that can dereference a Protocol (SIP) is not the only protocol that can dereference a
location URI; there is also HTTP-Enabled Location Delivery (HELD) location URI; there is also HTTP-Enabled Location Delivery (HELD)
[ID-HELD-DEREF]. [ID-HELD-DEREF] and HTTP [RFC2616].
Having a location URI has advantages over having a PIDF-LO, Having a location URI has advantages over having a PIDF-LO,
especially when a target's location changes. With a location URI, especially when a target's location changes. With a location URI,
when a target moves, the location URI does not change (at least when a target moves, the location URI does not change (at least
within the same domain). It can still be given out as the reference within the same domain). It can still be given out as the reference
to the Target's current location. The opposite is true if the to the Target's current location. The opposite is true if the
location is conveyed by value in a message. Once the Target moves, location is conveyed by value in a message. Once the Target moves,
the previously given location is no longer valid, and it the Target the previously given location is no longer valid, and if the Target
wants to inform another entity about its location, it has to send wants to inform another entity about its location, it has to send
the PIDF-LO to the location recipient (again). the PIDF-LO to the location recipient (again).
A Location Server (LS) stores the Target's location as a presence A Location Server (LS) stores the Target's location as a presence
document, called a Presence Information Date Format - Location document, called a Presence Information Data Format - Location
Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server
is the entity contacted during the act of dereferencing a Target's is the entity contacted during the act of dereferencing a Target's
location. If the dereferencing entity has permission, defined in location. If the dereferencing entity has permission, defined in
[ID-GEO-POL], the location of the target will be received. The LS [ID-GEO-POL], the location of the target will be received. The LS
will grant permission to location inquires based on the rules will grant permission to location inquires based on the rules
established by a Rule Holder [RFC3693]. The LS has the ability to established by a Rule Holder [RFC3693]. The LS has the ability to
challenge any request for a target's location, thereby providing challenge any request for a target's location, thereby providing
additive security properties before location revelation. 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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
does not scale in certain networks/environments, such as IP-based does not scale in certain networks/environments, such as IP-based
cellular networks, enterprise networks or service provider networks cellular networks, enterprise networks or service provider networks
with mobile endpoints. An 802.11 based access network is one with mobile endpoints. An 802.11 based access network is one
example of this. Constantly updating LCI to endpoints might not example of this. Constantly updating LCI to endpoints might not
scale in mobile (residential or enterprise or municipal) networks in scale in mobile (residential or enterprise or municipal) networks in
which the client is moving through more than one network attachment which the client is moving through more than one network attachment
point, perhaps as a person walks or drives with their client down a point, perhaps as a person walks or drives with their client down a
neighborhood street or apartment complex or a shopping center or neighborhood street or apartment complex or a shopping center or
through a municipality (that has IP connectivity as a service). 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 was 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
having to determine when it has moved far enough to consider asking having to determine when it has moved far enough to consider asking
for a refresh of its location. for a refresh of its location.
In enterprise networks, if a known location is assigned to each In enterprise networks, if a known location is assigned to each
individual Ethernet port in the network, a device that attaches to individual Ethernet port in the network, a device that attaches to
the network a wall-jack (directly associated with a specific the network a wall-jack (directly associated with a specific
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. The location URI points to a PIDF-LO contained on an
via the (logical entity of an) LS has a PIDF-LO to be dereferenced LS. Performing a dereferencing transaction, that Target's PIDF-LO
with a location URI. will be returned. If local configuration has the requirement of
only assigning unique location URIs to each client at the same
If local configuration has the requirement of only assigning unique attachment point to the network (i.e., same RJ-45 jack or same
location URIs to each client, then unique location URIs will be 802.11 Access Point - except when triangulation is used), then
given out, though they will all have the same location at the unique location URIs will be given out, though they will all have
record, relieving the backend Sighter or LS from individually the same location at the record, relieving the backend Sighter or LS
maintaining each location independently. from individually maintaining each location independently.
This Option can be useful in IEEE 802.16e 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 on a
client if there is a router, such as a residential home gateway, router, such as a residential home gateway, such that the router
with the ability to communicate to downstream endpoints as a server. 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 How an LS responds to a dereference request can vary, and a policy
established by a Ruleholder [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
Location Recipient (LR). This document does not provide mechanisms Location Recipient (LR). This document does not provide mechanisms
for the LS to tell the client about policies or for the client to 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 specify a policy for the LS. While an LS should apply an appropriate
access-control policy, clients must assume that the LS will provide access-control policy, clients must assume that the LS will provide
location in response to any request (following the possession model location in response to any request (following the possession model
[RFC5808]). For further discussion of privacy, see the Security [RFC5808]). For further discussion of privacy, see the Security
Considerations. Considerations.
This document IANA registers the new IPv4 and IPv6 DHC Options for a This document IANA-registers the new IPv4 and IPv6 DHCP Options for
location URI. a location URI.
2. Format of the DHCP LuriElement Option 2. Format of the DHCP LocationURI Option
2.1 Overall Format of LuriElement Option in IPv4 2.1 Overall Format of LocationURI Option in IPv4
The LuriElement Option format for IPv4 is as follows: The LocationURI 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 | . | Code XXX | Length=XX | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. LuriElements... ... . LocationURI... ...
. (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 LocationURI 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 URI within the Option. based on the length of the URI within the Option.
LuriElement: see Section 2.3 for details LocationURI: see Section 2.3 for details
2.2 Overall Format of LuriElement Option in IPv6 2.2 Overall Format of LocationURI Option in IPv6
The LuriElement Option format for IPv6 is as follows: The LocationURI 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LuriElements... . | LocationURI... .
. (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 LocationURI 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 length of the URI within the Option. based on the length of the URI within the Option.
LuriElement: see below (Section 2.3 for details). LocationURI: see below (Section 2.3 for details).
2.3 LuriElement Format for both IPv4 and IPv6 2.3 LocationURI Format for both IPv4 and IPv6
The LuriElement, in both DHCPv4 and DHCPv6, have the following The LocationURI, in both DHCPv4 and DHCPv6, have the following
format: format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LuriType | LuriLength | LuriValue ... | LuriType | LuriLength | LuriValue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. LuriElement Format for both IPv4 and IPv6 Figure 3. LocationURI TLV Format for both IPv4 and IPv6
LuriType: A one-byte identifier of the data location value. LuriType: A one-byte identifier of the data location value.
LuriLength: The length, in bytes, of the LuriValue, not including LuriLength: The length of the LuriValue, not including the
the LuriLength field itself, up to a maximum of 255 LuriLength field itself, up to a maximum of 255
bytes. units. The unit of measurement is defined by the
LuriType field definition. The LuriLength itself is
always an integer.
LuriValue: The LuriElement value, as described in detail below. LuriValue: The LocationURI value, as described in detail below.
The LuriValue is always in UTP-8.
The LuriTypes this document defines (and IANA registers) for a point The LuriTypes this document defines (and IANA registers) for a point
are: are:
LuriType=1 Location URI - This is the URI pointing at the LuriType=1 Location URI - This is the URI pointing at the
location record where the PIDF-LO resides which location record where the PIDF-LO resides, which
indicates the location of the Location Target. indicates the location of the Location Target. The
LuriValue of LuriType=1 is always represented in
UTF-8.
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 by the client. this Option by the client. The LuriValue of LuriType=2
is always represented as an integer.
The LuriType=2 (Valid-For) indicates how long, in seconds, the The Valid-For (LuriType=2) indicates how long, in seconds, the
client is to consider this LuriType=1 (location URI) valid client is to consider this location URI (LuriType=1) to be 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 Location URI refresh SHOULD be done LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done
the normal DHCP refresh rate, or necessitated by this timer, perhaps during the normal DHCP refresh rate, or necessitated by this timer,
with the client only requesting this Option be refreshed. perhaps with the client only requesting this Option be refreshed.
If the LuriType=2 (Valid-For) timer is received (solicited or If the Valid-For timer (LuriType=2) is received (solicited or
unsolicited), it is RECOMMENDED that the client refresh the Location unsolicited), it is RECOMMENDED that the client refresh the Location
URI when the (Valid-For) counter value has reaches the halfway URI when the (Valid-For) counter value reaches the halfway point.
point. For example, if 16000 was the initial value of the For example, if 16000 was the initial value of the Valid-For
LuriType=2 (Valid-For) value, when 8000 seconds have passed, the (LuriType=2) 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 Valid-For (LuriType=2) 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 a standards created MUST be done so through IANA registration with a standards
track RFC. track RFC.
3. DHC Option Operation 3. DHCP Option Operation
The [RFC3046] RAIO can be utilized to provide the appropriate The [RFC3046] RAIO can be utilized to provide the appropriate
indication to the DHCP Server where this DISCOVER or REQUEST message indication to the DHCP Server where this DISCOVER or REQUEST message
came from, in order to supply the correct response. came from, in order to supply the correct response.
Caution SHOULD always be used involving the creation of large Caution SHOULD always be used involving the creation of large
Options, meaning that this Option MAY need to be in its own INFORM, Options, meaning that this Option MAY need to be in its own INFORM,
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 LocationURI 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
are to be done, providing no identity information, rather than a are to be done (in which 34LKJH534663J54 is considered to be random
in this example), providing no identity information, rather than a
location URI such as this location URI such as this
sips:aliceisat123mainstalanta@example.com sips:aliceisat123mainstalantageorgiaus@example.com
In the <presence> element of a PIDF-LO document, there is an In the <presence> element of a PIDF-LO document, there is an
'entity' attribute that identities what entity *this* document 'entity' attribute that identities what entity *this* document
(including the associated location) refers to. It is up to the (including the associated location) refers to. It is up to the
PIDF-LO generator, either Location Server or an application in the PIDF-LO generator, either Location Server or an application in the
endpoint, to insert the identity in the 'entity' attribute. This endpoint, to insert the identity in the 'entity' attribute. This
can be seen in [RFC4119]. The entity= discussion is orthogonal to can be seen in [RFC4119]. The entity= discussion is orthogonal to
the identification information contained within the location URI. the identification information contained within the location URI.
This Option is used only for communications between a DHCP client This Option is used only for communications between a DHCP client
and a DHCP server. It can be solicited (requested) by the 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 or it can be pushed by the server without a request for it. DHCP
Options not understood are ignored. A DHCP server supporting this Options not understood MUST be ignored [RFC2131]. A DHCP server
Option might or might not have the location of a client. If a supporting this Option might or might not have the location of a
server does not have a client's location, but needs to provide this client. If a server does not have a client's location, but needs to
Location URI Option to a client (for whatever reason), an LS is provide this Location URI Option to a client (for whatever reason),
contacted. This server-to-LS transaction is not DHCP, therefore it an LS is contacted. This server-to-LS transaction is not DHCP,
is out of scope of this document. 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 The deference of a target's location URI would not involve DHCP, but
an application layer protocol, such as SIP or HTTP, therefore an application layer protocol, such as SIP or HTTP, therefore
dereferencing is out of scope of this document. dereferencing is out of scope of this document.
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. 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 LocationURI
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 access o Any user control (what [RFC3693] calls a 'Ruleholder') for access
to the dereferencing step is assumed to be out of scope of this to the dereferencing step is assumed to be out of scope of this
document. An example authorization policy is in [ID-GEO-POL]. document. An example authorization policy is 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
[RFC5808], describing what is expected in each model of [RFC5808], 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 possession model by default.
possessing the location URI does not give that entity the right An authorization model can be instituted as a matter of local
to view the PIDF-LO of the target whose location is indicated in policy. An authorization model means possessing the location URI
a presence document. The dereference transaction will be, in does not give that entity the right to view the PIDF-LO of the
many environments, challenged by the Location Server. The nature target whose location is indicated in a presence document. The
of this challenge is out of scope of this document. 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 o This document does not prevent some environments from operating
in a possession model, for example - tightly controlled in an authorization model, for example - in less tightly
enterprise networks, but this operation SHOULD NOT be assumed to controlled networks. The costs associated with authorization vs.
exist as a matter of local policy. The costs associated with possession models are discussed in Section 3.3.2 of [RFC5606].
authorization vs. possession models are discussed in Section
3.3.2 of [RFC5606].
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
general-browser to connect to a web page, because they could have general-browser to connect to a web page, because they could have
skipping to change at page 9, line 37 skipping to change at page 9, line 46
4.2 The IPv6 Option-Code for this Option 4.2 The IPv6 Option-Code for this Option
This document IANA registers this IPv6 Option-Code XXX (to be This document IANA registers this IPv6 Option-Code XXX (to be
assigned by IANA once this document becomes an RFC). assigned by IANA once this document becomes an RFC).
4.3 IANA Considerations for Acceptable Location URI Types 4.3 IANA Considerations for Acceptable Location URI Types
IANA is requested to create a new registry for acceptable location IANA is requested to create a new registry for acceptable location
URI types. URI types.
The following 3 URI types are registered by this document: The following 5 URI types are registered by this document:
1. sip: 1. sip:
2. sips: 2. sips:
3. pres: 3. pres:
4. http: 4. http:
5. https: 5. https:
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 DHCP Option need to be created and IANA registered with peer
review and an RFC. review and an RFC.
4.4 IANA Considerations for LuriTypes 4.4 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 |
skipping to change at page 10, line 32 skipping to change at page 10, line 41
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, initially, is a broadcast request (a client looking for a DHCP, initially, is a broadcast request (a client looking for a
server), and a unicast response (answer from a server) type of server), and a unicast response (answer from a server) type of
protocol. It does not provide security at the network layer. protocol. It does not provide security at the network layer.
Instead, it relies on lower-layer security mechanisms. In today's Instead, it relies on lower-layer security mechanisms.
infrastructures, 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 offer layer 2 security mechanisms to prevent a location URI
from being learned by an unauthorized entity.
Once a client has a URI, it needs information on how the location Once a client has a URI, it needs information on how the location
server will control access to dereference requests. A client might server will control access to dereference requests. A client might
treat a tightly access-controlled URI differently from one that can treat a tightly access-controlled URI differently from one that can
be dereferenced by anyone on the Internet (i.e., one following the be dereferenced by anyone on the Internet (i.e., one following the
"possession model"). With the LuriTypes defined in this document, "possession model"). With the LuriTypes defined in this document,
the DHCP option for delivering location URIs can only tell the user 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 how long the URI will be valid. Since the client does not know what
policy will be applied during this validity interval, clients MUST policy will be applied during this validity interval, clients MUST
handle location URIs as if they could be dereferenced by anybody handle location URIs as if they could be dereferenced by anybody
skipping to change at page 11, line 15 skipping to change at page 11, line 19
access to policy information will allow them to make more informed access to policy information will allow them to make more informed
decisions about how to use their location URIs. Allowing users to decisions about how to use their location URIs. Allowing users to
provide policy information to the LS will enable them to tailor provide policy information to the LS will enable them to tailor
access control policies to their needs (within the bounds of policy access control policies to their needs (within the bounds of policy
that the LS will accept). that the LS will accept).
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.
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 (see 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.
When implementing a DHC server that will serve clients across an When implementing a DHCP 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, and for offering the text to incorporate HTTP URIs. To section, and for offering the text to incorporate HTTP URIs. To
Hannes Tschofenig and Ted Hardie for riding me to comply with their Hannes Tschofenig and Ted Hardie for riding me to comply with their
concerns, including a good scrubbing of the nearly final doc. To concerns, including a good scrubbing of the nearly final doc.
Richard Barnes for his guidance with respect to the model used by
this document and fine tuning the security considerations section.
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 12, line 21 skipping to change at page 12, line 24
[RFC3856] J. Rosenberg, "A Presence Event Package for the Session [RFC3856] J. Rosenberg, "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004 Initiation Protocol (SIP)", RFC 3856, August 2004
[RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference [RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010 Mechanism", RFC 5808, May 2010
7.2. Informative References 7.2. Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, J. Peterson, "SIP Location [ID-SIP-LOC] J. Polk, B. Rosen, J. Peterson, "SIP Location
Conveyance", "work in progress", July 2010 Conveyance", "work in progress", Feb 2011
[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
Thomson, M. Dawson, "A Location Dereferencing Protocol Using Thomson, M. Dawson, "A Location Dereferencing Protocol Using
HELD", "work in progress", January 2010 HELD", "work in progress", December 2010
[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
Configuration Information", RFC 3825, July 2004 Configuration Information", RFC 3825, July 2004
[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
[RFC5808] R. Marshall, "Requirements for a Location-by-Reference [RFC5808] R. Marshall, "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010 Mechanism", RFC 5808, May 2010
[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
[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. [ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.
Polk, "Geolocation Policy: A Document Format for Expressing Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information", "work in Privacy Preferences for Location Information", "work in
progress", July 2010 progress", Oct 2010
[RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of [RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of
'retransmission-allowed' for SIP Location Conveyance", 'retransmission-allowed' for SIP Location Conveyance",
August 2009 August 2009
[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616, June 1999 Protocol - HTTP/1.1", RFC 2616, June 1999
[ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location [ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location
Configuration Extensions for Policy Management", "work in Configuration Extensions for Policy Management", "work in
progress", May 2010 progress", January 2011
Authors' Address Authors' Address
James Polk James Polk
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
USA USA
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
 End of changes. 54 change blocks. 
99 lines changed or deleted 103 lines changed or added

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