IRTF HIP Research Group J. Ahrenholz
Internet-Draft The Boeing Company
Expires: February 26, 2006 August 25, 2005
HIP DHT Interface
draft-ahrenholz-hiprg-dht-00
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 February 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies a common interface for using HIP with a DHT
to provide lookup services.
Ahrenholz Expires February 26, 2006 [Page 1]
Internet-Draft HIP DHT Interface August 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Open DHT interface . . . . . . . . . . . . . . . . . . . . 4
3. HIP lookup services . . . . . . . . . . . . . . . . . . . . . 6
3.1. HIP address lookup . . . . . . . . . . . . . . . . . . . . 6
3.2. HIP HIT lookup . . . . . . . . . . . . . . . . . . . . . . 8
3.3. When to use HIP lookup services . . . . . . . . . . . . . 9
4. Issues with DHT support . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Ahrenholz Expires February 26, 2006 [Page 2]
Internet-Draft HIP DHT Interface August 2005
1. Introduction
The Host Identity Protocol [2] may benefit from a lookup service
based on Distributed Hash Tables (DHTs). The Host Identity namespace
is flat, consisting of public keys, in contrast to the hierarchical
Domain Name System. These keys are hashed to form Host Identity Tags
(HITs) which appear as large random numbers. The current DNS system
does not provide a suitable lookup mechanism for these flat, random
values, and has been heavily optimized for address lookup. DHTs
manage such data well by applying a hash function that distributes
data across a number of servers. DHTs also feature good support for
updating stored values.
One freely available implementation of a DHT is the Bamboo DHT, which
has been deployed on PlanetLab servers to form a free service named
Open DHT. Open DHT is available via the Internet for any program to
store and retrieve arbitrary data. Open DHT uses a well defined XML-
RPC interface, featuring both put and get operations. This document
discusses a common interface for HIP to be used with Open DHT, so
that various HIP implementations may leverage this lookup service in
an interoperable fashion.
Ahrenholz Expires February 26, 2006 [Page 3]
Internet-Draft HIP DHT Interface August 2005
2. The Open DHT interface
Open DHT is a public deployment of Bamboo DHT servers running on 200-
300 PlanetLab nodes. While the Bamboo project provides the actual
software running on the servers, here we will refer only to Open DHT,
which uses a certain defined interface for the XML-RPC calls. One
can run their own Bamboo nodes to set up a private ring of servers,
but here we are interested in providing a service for use with
mutiple, different HIP implementations.
Open DHT was chosen because it is a well-known, publicly available
DHT used within the research community. Its interface features a
simple, standards-based protocol that can be easily implemented by
HIP developers. This document does not aim to dictate that only the
services and servers described here should be used, but is rather
meant to act as a starting point to gain experience with these
services, choosing tools that are readily available.
Open DHT stores values using (hash) keys. Keys are limited to 20
bytes in length, and values can be up to 1024 bytes. Values are
stored for a certain number of seconds, up to a maximum of 604,800
seconds (one week.) See the Open DHT website:
Two RPC operations are supported: put and get. Put is called with
key and value parameters, causing the value to be stored using the
key as its hash index. Get is called with the key parameter, when
you have a key and want to retrieve the value.
The definitions below are taken from
.
Ahrenholz Expires February 26, 2006 [Page 4]
Internet-Draft HIP DHT Interface August 2005
The put operation takes the following arguments:
+----------------+--------------------------------------+
| field | type |
+----------------+--------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| value | byte array, 1024 bytes max. |
| | |
| ttl_sec | four-byte integer, max. value 604800 |
+----------------+--------------------------------------+
The server replies with an integer -- 0 for "success", 1 if it is
"over capacity", and 2 indicating "try again".
The get operation takes the following arguments:
+----------------+---------------------------------------------+
| field | type |
+----------------+---------------------------------------------+
| application | string |
| | |
| client_library | string |
| | |
| key | byte array, 20 bytes max. |
| | |
| maxvals | four-byte singed integer, max. value 2^31-1 |
| | |
| placemark | byte array, 100 bytes max. |
+----------------+---------------------------------------------+
The server replies with an array of values, and a placemark that can
be used for fetching additional values.
This is the basic XML-RPC interface provided by Open DHT. Each
"field" from the above tables are XML tags that enclose their
corresponding values. Below, specific uses for HIP are suggested,
along with values that can be used inside the fields shown above.
Ahrenholz Expires February 26, 2006 [Page 5]
Internet-Draft HIP DHT Interface August 2005
3. HIP lookup services
Here we define two lookup services for use with HIP.
The first is an address lookup service. Before a HIP association can
be initiated (a non-opportunistic initiation), a HIP host needs the
peer's HIT and the current address at which the peer is reachable.
Often the HIT will be pre-configured or available via DNS lookup
using a hostname lookup [3]. With HIP mobility [4], IP addresses may
be used as locators that are subject to change frequently. The Host
Identity and the HIT remain constant and can be used to securely
identify a host, so the HIT makes a good DHT key for storing and
retrieving addresses.
The second service is a HIT lookup service. The need for this arose
when experimenting with an IPv4 implementation that relies on 32-bit
LSIs. When an application attempts to make a connection using the
LSI, the HIP layer needs to somehow translate this LSI into a HIT
before initiating a HIP association. If the LSI is an arbitrary
number (not based on any bits from the HIT) then this LSI-HIT mapping
must be either pre-configured or available through a lookup service
such as this. Also, if the peer address is keyed off the HIT as for
the previously described service, the HIT must be known to obtain a
reachable address for that peer.
Both of these services reduce the amount of pre-configuration
required at each HIP host. For the first service, the address of the
peer does not need to be known ahead of time. For the second
service, only a list of LSIs may need to be configured, the remainder
of peer parameters can be dynamically acquired. They do add an
additional item for configuration -- the DHT server that will be
contacted to service lookup requests.
3.1. HIP address lookup
Functionally, this interface is: addr = get(HIT). Publish and lookup
operations are defined. Given a HIT, a lookup returns the preferred
address of the peer.
Ahrenholz Expires February 26, 2006 [Page 6]
Internet-Draft HIP DHT Interface August 2005
Address publish
+----------------+----------------------------+----------------+
| field | value | data type |
+----------------+----------------------------+----------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | 128-bit HIT | base64 encoded |
| | | |
| value | struct sockaddr | base64 encoded |
| | | |
| ttl_sec | current address lifetime | numeric string |
+----------------+----------------------------+----------------+
Address lookup
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | 128-bit HIT | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
The application and client_library fields are used for logging in
Open DHT. The client_library may vary between different
implementations, specifying the name of the XML-RPC library used or
the application that directly makes XML-RPC calls.
The key for both address publish and lookup is the 128-bits of the
HIT, base64 encoded [1]. The value used in the publish and lookup
response is the struct sockaddr that stores the address in network
byte order, base64 encoded. The struct sockaddr was chosen because
it is a standard interface that includes the address family.
The ttl_sec field used with address publish includes the time-to-
live, the number of seconds for which the entry will be stored by the
DHT, which is set to the number of seconds remaining in the address
lifetime.
Ahrenholz Expires February 26, 2006 [Page 7]
Internet-Draft HIP DHT Interface August 2005
The max_vals and placemark fields used with address lookup are
defined by the get XML-RPC interface. The get needs to know the
maximum number of values to retrieve. The placemark is a value found
in the server reply that causes the get to continue to retrieve
values starting at where it left off.
3.2. HIP HIT lookup
Functionally, this interface is: HIT = get(f(LSI)). The LSI is a
handle to a Host Identity that can be used in socket calls by legacy
applications. The hash key is a function f(LSI). One problem with
LSIs is that they are not unique. We therefore define a "site id" to
identify the site or domain to which the host named by the LSI
belongs. This can be the same string used in the domain part of the
DNS domain name, for example. The assignment of site ids is outside
the scope of this document, but is assumed to be preconfigured among
corresponding hosts at that site, and the concatenation of LSI and
site id is assumed to have site-local scope.
HIT publish
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA1(struct sockaddr LSI|site | base64 encoded |
| | id) | |
| | | |
| value | 128-bit HIT | base64 encoded |
| | | |
| ttl_sec | "604800" (maximum value) | numeric string |
+----------------+---------------------------------+----------------+
Ahrenholz Expires February 26, 2006 [Page 8]
Internet-Draft HIP DHT Interface August 2005
HIT lookup
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA1(struct sockaddr LSI|site | base64 encoded |
| | id) | |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+
The application field is now "hip-hit". The client_library, maxvals,
and placemark fields are the same as described in Section 3.1.
The key is the SHA-1 hash of the concatentation of the LSI with the
site identifier. The LSI is stored in network byte order in struct
sockaddr form, in the same manner as addresses before. This binary
data is then appended with the null-terminated string containing the
site id, and then SHA-1 hashed. If the site id happens to be
numeric, its string representation should be used. The hash is used
due to the 20 byte limitiation on key sizes, allowing for lengthy
site identifiers. The hash is base64 encoded.
The value is the 128-bit HIT, base64 encoded.
The time-to-live is set to its maximum value, under the assumption
that the LSI to HIT mapping is long-lived.
3.3. When to use HIP lookup services
Below are some suggestions of when a HIP implementation may want to
use the HIP lookup services.
When a peer HIT is first configured, an address lookup could be
performed so that an address can be cached and immediately available
for when an association is requested. Implementations might load a
list of peer HITs on startup, resulting in several lookups that can
take some time to complete.
However, cached addresses may quickly become obsolete, depending on
how often the peer changes its preferred address. Performing an
Ahrenholz Expires February 26, 2006 [Page 9]
Internet-Draft HIP DHT Interface August 2005
address lookup before sending the I1 may be needed. At this time the
latency of a lookup may be intolerable, and a lookup could instead be
performed after the I1 retransmission timer fires -- when no R1 reply
has been received -- to detect any change in address.
A HIP host should publish its preferred address upon startup, so
other hosts may determine where it is reachable. Also, when there is
a change in preferred address, usually associated with sending UPDATE
packets with included locator parameters, the host should update its
address with the DHT.
Ahrenholz Expires February 26, 2006 [Page 10]
Internet-Draft HIP DHT Interface August 2005
4. Issues with DHT support
As of this writing, Open DHT did not support a remove operation for
XML-RPC. When no remove is available, each put appends the new value
to any existing values. When performing an address lookup, the last
address in the list should be used and considered to be the current
preferred address. Authenticated puts and removes will be supported
in the future, where a SHA-1 hash of a secret key is included.
Selecting an appropriate DHT server to use is not covered here. If a
particular server becomes unavailable, the connect will timeout and
some server selection algorithm should be performed, such as trying
the next server in a configured list.
Because the put and get calls rely on outside servers located across
the Internet, operations may have a latency involved that should be
considered when using these services with HIP.
Ahrenholz Expires February 26, 2006 [Page 11]
Internet-Draft HIP DHT Interface August 2005
5. Security Considerations
There are two possible attacks on this information exchange between
host and DHT server: attacks on the validity of the information
provided by the DHT to the host (such as a spoofed DHT response) and
attacks on the DHT records themselves (such as polluted records for a
given key).
For the address lookup based on HIT (Section 3.1), the validity of
the DHT response can be checked by an initiating host after the R1
message is received. The Host Identity provided in the R1 can be
hashed to obtain a HIT that can be checked against the original HIT.
However, the Open DHT service does not currently prevent an attacker
from polluting the DHT records for a known HIT, thereby causing a
denial-of-service attack. It is possible for a future DHT
implementation to use HIP signatures to validate put() requests for
HITs, but such an extension is not currently available for Open DHT.
For the HIT lookup based on LSI (Section 3.2), there is not a
corresponding guarantee that the LSI is securely bound to the Host
Identifier. Additional infrastructure (shared secrets between DHT
and hosts, or third-party certificate infrastructure) is likely
needed to secure those records. Such issues are for further study.
Ahrenholz Expires February 26, 2006 [Page 12]
Internet-Draft HIP DHT Interface August 2005
6. IANA Considerations
This document has no actions for IANA.
Ahrenholz Expires February 26, 2006 [Page 13]
Internet-Draft HIP DHT Interface August 2005
7. Acknowledgments
Thanks to Tom Henderson for providing comments. Thanks to Teemu
Koponen for his ideas about adding a site-local identifier to the LSI
DHT key.
8. References
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[2] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03
(work in progress), June 2005.
[3] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
Domain Name System (DNS) Extensions", draft-ietf-hip-dns-02
(work in progress), July 2005.
[4] Nikander, P., "End-Host Mobility and Multihoming with the Host
Identity Protocol", draft-ietf-hip-mm-02 (work in progress),
July 2005.
Ahrenholz Expires February 26, 2006 [Page 14]
Internet-Draft HIP DHT Interface August 2005
Author's Address
Jeff Ahrenholz
The Boeing Company
P.O. Box 3707
Seattle, WA
USA
Email: jeffrey.m.ahrenholz@boeing.com
Ahrenholz Expires February 26, 2006 [Page 15]
Internet-Draft HIP DHT Interface August 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ahrenholz Expires February 26, 2006 [Page 16]