Geopriv WG James Polk
Internet-Draft Cisco Systems
Intended status: Standards Track July 9th, 2007
Expires: January 9th, 2008
Dynamic Host Configuration Protocol (DHCP) Option for a
Location-by-Reference (LbyR) Uniform Resource Identifier (URI)
draft-polk-geopriv-dhcp-lbyr-uri-option-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9th, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for the Location-by-Reference (LbyR) Uniform Resource
Identifier (URI) of an endpoint. For example, an endpoint can be a
Session Initiation Protocol (SIP) User Agent, i.e., a phone. This
LbyR URI can be included in a UA's messages to inform other nodes of
that UA's geographic location, once the URI is dereferenced by a
Location Recipient.
Polk Expires Jan 2008 [Page 1]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in this Document . . . . . . . . . . . 3
2. DHC Location URI Elements . . . . . . . . . . . . . . . . . . 3
2.1. Elements of the Location Configuration Information . . 4
3. DHC Option Operation . . . . . . . . . . . . . . . . . . . . 4
3.1 Architectural Assumptions . . . . . . . . . . . . . . . .
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . 6
1. Introduction
This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for delivery of a client's Location-by-Reference (LbyR)
Uniform Resource Identifier (URI). For example, a client can be a
Session Initiation Protocol (SIP) User Agent (UA) [RFC3261], i.e., a
phone. This LbyR URI can be included in one UA's messages to
informing those remote devices of that UA's geographic location,
once the URI is dereferenced by a Location Recipient [ID-SIP-LOC]. A
Location Recipient is a device that has received location from
another device. If this location is delivered by a URI, the URI has
to be dereferenced to learn the remote device's geographic location.
Dereferencing can be done in SIP by use of the SUBSCRIBE/NOTIFY
Methods [RFC3265] to either a sip:, sips: or pres: scheme URI.
Endpoints will require their geographic location for a growing
number of services. A popular use-case currently is for emergency
services, in which SIP requires its location to be placed in a SIP
INVITE request message towards a public safety answering point
(PSAP). The reason for this is twofold:
o An emergency services SIP request must be routed/retargeted to the
appropriate PSAP that is local to where the PSAP is.
o The first responders require the UA's location in order to know
where to go to render aid to the caller.
There are other use-cases, such as calling the appropriate Pizza Hut
without having to look up which store is closest. A UA knowing its
location can call a main/national/international Pizza Hut number or
address and let the UA's location tell Pizza Hut enough information
to have them route/retarget the SIP request to the appropriate store
within the Pizza Hut organization to deliver the pizza to the
Polk Expires Jan 2008 [Page 2]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
caller.
A problem exists within existing RFCs that provide location to the
UA, [RFC3825] and [RFC4776], that location has to be updated every
time a UA moves. This does not scale in certain
networks/environments, such as enterprise networks or service
provider networks with mobile endpoints. An 802.11 based access
network is an example of this. This also might not scale in mobile
residential networks in which the UA is hopping between more than
one network attachment point, perhaps as a person walks with their
UA down a neighborhood street or apartment complex.
If the UA were provided a URI reference to retain and hand out when
it wants to convey its location, one that would not change as the
UAC's location changes, scaling issues would be significantly
reduced. This delivery of an indirect location has the added
benefit of not using up valuable or limited bandwidth to the UA
with the constant updates. A service provider would merely update
what location is at the URI the UA already has, with this new DHCP
Option.
In enterprise networks, a URI can be assigned to individual Ethernet
ports; meaning whatever is attached to a particular port will get
the same URI because that device is at a known location. This
scenario applies to 802.11 Access Points (AP), in which the AP's
location is what's known. The same URI can be given to all devices
attached to the same AP. Just as with residential router/gateways,
which can be wired or wireless, in which all devices understanding
this Option will be giving the location of the residence. The Option
also benefits from the URI not needing identity information to still
be useful.
APs that triangulate can also have a individual URI downloaded to
each endpoint with this Option, for the endpoint to hand out
whenever it is configured to in whatever protocol it is capable of.
This Option can be useful in WiMAX connected endpoints or IP
cellular endpoints. The Location URI Option can be configured as a
client if it is a router, such as a residential home gateway, with
the ability to communicate to downstream endpoints as a server.
This document IANA registers the new DHC Option for a Location URI.
1.1 Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Polk Expires Jan 2008 [Page 3]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
2. DHC Location URI Elements
DHCP is a binary Protocol; URIs are alphanumeric (text) based.
There is one byte per URI character.
[Editor's question: should UTF-8 vs. UTF-16 be accounted for?]
The Location URI Option format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code XXX | Option Length | Location URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location URI (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ .... \
\ .... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location URI (cont'd) +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Elements of the Location Configuration Information
Code XXX: The code for this DHCP option.
Option Length: The length of this option variable.
Location URI: The Location URI
There are no additional fields within this Option, as the value of
the URI is contained within the URI field, including all URI
parameters and (what could become another protocol's) header
parameters.
3. DHC Option Operation
The [RFC3046] RAIO MUST be utilized to provide the appropriate
indication to the DHCP Server where this DISCOVER or REQUEST message
came from, in order to supply the correct response.
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 to be
used [RFC3396].
Polk Expires Jan 2008 [Page 4]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
Per [RFC2131], subsequent LbyR URI Options, which are
non-concatenated, overwrite the previous value.
LbyR URIs SHOULD NOT reveal identity information of the user of the
device, since DHCP is a cleartext delivery protocol.
[Editor's question: can the above SHOULD NOT be a MUST NOT?]
3.1 Architectural Assumptions
The following assumptions have been made for use of this URI Option
for a client to learn it's location URI (in no particular order):
o The DHCP Server communicates with the Location Information Server
(LIS), which likely stores the location information for URIs.
This exchange can be any number of protocols (SOAP, HTTP, FTP,
SIP, etc) on a per request-basis/log-on, or in bulk.
o A URI is assigned to a Ethernet Switch, router or home gateway
port - such that the location does not change without
administrative controls. This allows any device to attach to the
network from a particular port to have the same location URI
given to them, because that device is in the same location.
o The population of the database of Ethernet Switch, router or home
gateway port, in the LIS is done administratively, and outside
the scope of this document.
o A DHCP Server is not expected to deliver location URIs with this
option outside of the DHCP Server's policy domain. Most likely
this is within a company's network, or a region of a network for
SPs.
o Any user control (what Geopriv calls a 'rulemaker') for the
parameters and profile options a Location-Object will have is out
of scope of this document, by assumed to take place via something
such as a web interface between the user and the LIS (direct or
indirect).
o Any user attempting to gain access to the information at this URI
will be challenged by the server for credentials and permissions.
4. Acknowledgements
Thanks to James Winterbottom for his useful comments.
5. IANA Considerations
IANA is requested to assigned a DHCP option code of XXX for the
Polk Expires Jan 2008 [Page 5]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
Location URI option, defined in Section 2.0 of this document.
Any additional Location URI parameters to be defined for use via
this DHC Option MUST be done through a Standards Track RFC.
6. Security Considerations
Where critical decisions might be based on the value of this
LbyR URI option, DHCP authentication in [RFC3118] SHOULD be used to
protect the integrity of the DHCP options.
Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and
requesting client can discover this LbyR URI. Other than capturing
the URI, the location of the client benefits from the protection of
whatever server challenge mechanisms are available and configured
for any device attempting access of the location record that the
URI.
LbyR URIs need to reduce or eliminate client identity information
within the URI itself, because DHCP is a cleartext delivery
protocol.
When implementing a DHC server that will serve clients across an
uncontrolled network, one should consider the potential security
risks therein.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
Polk Expires Jan 2008 [Page 6]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
7.2. Informative References
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance",
draft-ietf-sip-location-conveyance-07.txt, "work in
progress", Feb 2007
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
Information ", RFC 4776, November 2006
Authors' Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
EMail: jmpolk@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Polk Expires Jan 2008 [Page 7]
Internet-Draft Geopriv DHCP LbyR URI Option July 2007
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Polk Expires Jan 2008 [Page 8]