HIP F. Cao
Internet-Draft Cisco Systems
Intended status: Standards Track H. Deng
Expires: April 26, 2009 China Mobile
October 23, 2008
Delivering Geographic Location in Host Identity Protocol (HIP)
draft-cao-hip-geolocation-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 April 26, 2009.
Abstract
This document defines a new parameter for delivering geographic
location in Host Identity Protocol (HIP). For mobile users using
HIP, one generic mechanism is proposed to share or update their geo-
location information with either rendezvous servers or their peers.
In addition, geo-location privacy is also protected with the help of
the ENCRYPTED parameter.
Cao & Deng Expires April 26, 2009 [Page 1]
Internet-Draft HIP Location October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. GEOLOC Parameter . . . . . . . . . . . . . . . . . . . . . 4
3.3. Privacy Protection . . . . . . . . . . . . . . . . . . . . 5
3.4. Request for obtaining geo-location . . . . . . . . . . . . 6
4. Use cases with HIP flows . . . . . . . . . . . . . . . . . . . 7
4.1. Setting up peer connection . . . . . . . . . . . . . . . . 8
4.2. Registration in rendezvous services . . . . . . . . . . . 8
4.3. Distribution from rendezvous servers . . . . . . . . . . . 9
4.4. Updates in peer connections . . . . . . . . . . . . . . . 9
4.5. Updates to rendezvous servers . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informational References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Cao & Deng Expires April 26, 2009 [Page 2]
Internet-Draft HIP Location October 2008
1. Introduction
This document defines a new extension for delivering geographic
location in Host Identity Protocol (HIP) [RFC4423]. For some mobile
users using HIP, their geo-location information can play an important
role for some new location-based services.
For example, if a roaming user using HIP enters into a different
location, his latest geo-location can be shared with his peers for
various services, such as localized advertisements, social
networking, and emergency services.
Another example is that rendezvous server may use geographic
locations of its rendezvous clients for better services.
Additionally, location privacy has been a big concern for many mobile
users, and must be addressed so that such geo-location information
can be securely protected from end to end in HIP.
In this document, a new generic mechanism is proposed to share or
update the geo-location information in HIP. Both the centralized
approach based on rendezvous servers, or the distributed approach
based on the peers, are discussed and demonstrated. Furthermore,
geo-location privacy is also considered with the help of the ENCRPTED
parameter.
2. Terminology
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 RFC 2119.
Host Identity Tag (HIT): the hashed 128-bit value from host
identifier in HIP
Rendezvous Server (RVS): A HIP registrar providing rendezvous
service
Geo-location: Geographic location that may be presented in various
formats, such as civil address, geodetic-2d, and geodetic-3d.
Peer connection: the relationship set up directly between initiator
and responder in HIP.
Location-by-Reference (LbyR): the presentation of location
information is the reference link where the actual value can be
obtained.
Cao & Deng Expires April 26, 2009 [Page 3]
Internet-Draft HIP Location October 2008
Location-by-Value (LbyV): the presentation of location information
is the actual value in one of the known formats describing the
location.
3. Overview
This section gives an overview of the requirements and the mechanisms
for delivering geographic location in HIP. In particular, some
extensions are introduced to carry the geo-location information with
the option of location privacy protection.
3.1. Requirements
Geo-location should be added by following the general HIP parameter
definitions and satisfying the related location privacy guidelines.
The following requirements should be addressed:
o The mechanism must be extensible for carrying current various geo-
location formats and potential future formats
o The distributed model as peer connections must be outlined
o The centralized model as rendezvous services must be outlined
o The security mechanism for protecting geo-location privacy must be
addressed
3.2. GEOLOC Parameter
When the initiator or the responder wants to share its geo-location
with either rendezvous servers or its peers in HIP, the most
efficient mechanism is to use a new geo-location parameter. Inside
such a geo-location extension, the information about geo-location can
be inserted and delivered along with HIP messages.
Similarly, in some centralized scenarios, the rendezvous servers may
also distribute or update the geo-location information about some
registered HIP clients by using this geo-location parameter.
The GEOLOC parameter are defined as follows:
Cao & Deng Expires April 26, 2009 [Page 4]
Internet-Draft HIP Location October 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocationFormat | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| LocationPayload |
| |
| |
| +----------------------+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16 [TBD by IANA]
Length 16 [length in octets, excluding Type, length, padding]
HIT Host Identity Tag
LocationFormat 16 [type of geo-location formats]
LocationPayload the presentation of location in the indicated
format
Figure 1: GEOLOC parameter format
"LocationFormat" specifies the exact format for presenting geo-
location. Note that there are two categories in LocationFormat: one
is LbyV, and the other LbyR.
In order to clarify the difference, the first bit, I, in
LocationFormat is used as the indicator. If I is set to be 0, it
means LbyV is presented. Otherwise, LbyR is presented when I is set
to be 1.
All the current formats for geo-location can be included by assigning
the numbers for them. For example, binay geodetic-3d format defined
in [RFC3825] can be covered. Similarly, PIDF-LO defined in [RFC5139]
can also be covered.
[ TBD ... the enum for location formats ...]
"LocationPayload" will be inserted after "LocationFormat" and
followed by the additional proper padding.
3.3. Privacy Protection
Location privacy is among the top concerns in Location-based
services. Whenever mobile users like to share or receive the
Cao & Deng Expires April 26, 2009 [Page 5]
Internet-Draft HIP Location October 2008
location information, the secure mechanism must be available for
addressing location privacy.
The secure mechanism can be fully built upon another exising HIP
exention, by embedding geo-location GEOLOC into "Encrypted" parameter
in HIP header (See Section 5.2.15 in RFC 5201).
The GEOLOC parameter can be embedded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 641 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV /
/ /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ Encrypted GEOLOC parameter /
/ /
/ +-------------------------------+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Encrypted GEOLOC parameter
"Encrypted GEOLOC parameter" is created by following the procedures
defined in "Encrypted" parameter.
With the help of "Encrypted" parameter, GEOLOC parameter can be fully
protected without any disclosure to other parties that are not
involved in this HIP connection.
3.4. Request for obtaining geo-location
This provides an option for allowing the HIP parties to ask for the
geo-location information of others. Then it is up to location
policies for granting or denying the permission to the requestor.
requestor.
The GEOLOC_REQ parameter is defined as follows:
Cao & Deng Expires April 26, 2009 [Page 6]
Internet-Draft HIP Location October 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocationFormat_NUM | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HIT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocationFormat-1 | ............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .................... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LocationFormat-m | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 16 [TBD by IANA]
Length 16 [length in octets, excluding Type, length, padding]
LocationFormat-NUM 16 [type of geo-location formats]
Figure 3: GEOLOC_REQ parameter format
LocationFormat_NUM lists the number of the preferred geo-location
format(s) when GEOLOC parameters are returned back.
With the help of GEOLOC_REQ parameter, each HIP party can indicate
its interest of acquiring the geo-location information of others.
But the receiver of such a GEOLOC_REQ parameter needs to check the
location policy before granting such a request (To be discussed more
in the following section).
[Open question: how RVS can provide the error codes for GEOLOC_REQ?]
4. Use cases with HIP flows
There are multiple ways to use this new Geo-location parameter in
various scenarios. In this section, some major use cases are
demonstrated, including
o sharing geo-location in setting up peer connections
o carrying geo-location in the registration with rendezvous servers
o distributing geo-location from rendezvous servers
o updating geo-location in peer connections
o updating geo-location to rendezvous servers
Cao & Deng Expires April 26, 2009 [Page 7]
Internet-Draft HIP Location October 2008
4.1. Setting up peer connection
The initiator or the responder can share his geo-location when the
connection is set up.
When location privacy is not needed, the initiator or the responder
can begin sharing its geo-location information as the early as I2 or
R2.
Initiator Responder
I1
---------------------------------->
R1
<----------------------------------
I2: GEOLOC
---------------------------------->
R2: GEOLOC
<----------------------------------
When location privacy is desired, the initiator or the responder must
embed the GEOLOC parameter into Encrypted parameter and then send the
finalized HIP packet in I2 or R2.
4.2. Registration in rendezvous services
Rendezvous clients can inform Rendezvous Server of their geo-
locations during their registrations.
RV Client RVS
I1
---------------------------------->
R1: REG_INFO, GEOLOC_REQ
<----------------------------------
I2: REG_REQ, GEOLOC
---------------------------------->
R2: REG_RES
<----------------------------------
Cao & Deng Expires April 26, 2009 [Page 8]
Internet-Draft HIP Location October 2008
4.3. Distribution from rendezvous servers
RVS can serve as Location Server (LS) (See [RFC3693]) for sharing the
location information with HIP clients, with the help of Rule Holder
(RH) for location policies.
RV Client RVS
....................................
UPDATE: GEOLOC_REQ
---------------------------------->
NOTIFY: GEOLOC
<----------------------------------
4.4. Updates in peer connections
For mobile users, they can update their geo-location when their
positions have been changed.
Initiator Responder
....................................
UPDATE: GEOLOC
---------------------------------->
UPDATE: GEOLOC
<----------------------------------
4.5. Updates to rendezvous servers
For rendevous clients, they can update their rendevous servers with
their latest geo-locations.
RV Client RVS
....................................
UPDATE: GEOLOC
---------------------------------->
It is similar that GEOLOC can be embedded into ENCRYPTED parameter
for location privacy protection.
Cao & Deng Expires April 26, 2009 [Page 9]
Internet-Draft HIP Location October 2008
5. Security Considerations
This document provides the HIP parameters for sharing geo-location
information among HIP parties.
Some existing work on geo-location privacy (see [RFC3693, RFC3694])
should be carefully integrated so that the secure models can help to
address the potential threats.
For example, RVS may include the functions of Location Information
Server (LIS) and the Rule Holder (RH). The desired policies can be
enforced when the geo-location information is exchanged through RVS
among rendezvous clients.
On the other hand, RVS may become the target for disturbing the
desired geo-location services.
The frequency of geo-location updates may also be used by the hackers
as another way for generating DoS attacks.
[More to be added, such as rate limit on control packets with
GEOLOC_REQ, frequency limit on geo-location update, ...]
6. IANA Considerations
This document updates the IANA registry for HIP parameters Types by
assigning new values for the following new HIP parameter types:
o GEOLOC (defined in Overview Section)
o GEOLOC_REQ (defined in Overview Section)
7. Acknowledgments
The editor and the contributors would like to acknowledge the
constructive feedback and input provided by David Ward, Varjonen
Samu, and Suping Zhai.
8. References
8.1. Normative References
[1] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[2] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
Cao & Deng Expires April 26, 2009 [Page 10]
Internet-Draft HIP Location October 2008
[3] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[5] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[6] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for Presence Information Data Format Location Object
(PIDF-LO)", RFC 5139, February 2008.
[7] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
8.2. Informational References
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration
Information", RFC 4776, November 2006.
Authors' Addresses
Feng Cao
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: fcao at cisco dot com
Cao & Deng Expires April 26, 2009 [Page 11]
Internet-Draft HIP Location October 2008
Hui Deng
China Mobile
53A Xibianmennei Ave.
Beijing 100053
China
Email: denghui at chinamobile dot com
Cao & Deng Expires April 26, 2009 [Page 12]
Internet-Draft HIP Location October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Intellectual Property
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. 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.
Cao & Deng Expires April 26, 2009 [Page 13]