[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

IRTF HIP Research Group                                     J. Ahrenholz
Internet-Draft                                        The Boeing Company
Expires: August 16, 2007                               February 12, 2007


                           HIP DHT Interface
                      draft-ahrenholz-hiprg-dht-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 August 16, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).















Ahrenholz                Expires August 16, 2007                [Page 1]


Internet-Draft              HIP DHT Interface              February 2007


Abstract

   This document specifies a common interface for using HIP with a DHT
   to provide a HIT-to-address lookup service and an unmanaged name-to-
   HIT lookup service.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The OpenDHT interface  . . . . . . . . . . . . . . . . . . . .  4
   3.  HIP lookup services  . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  HIP address lookup . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Secure HIP address lookup  . . . . . . . . . . . . . . . . 10
     3.3.  HIP name to HIT lookup . . . . . . . . . . . . . . . . . . 12
     3.4.  When to use the HIP lookup services  . . . . . . . . . . . 14
   4.  Issues with DHT support  . . . . . . . . . . . . . . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 21
     A.1.  Changes from Version 00 to 01  . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23


























Ahrenholz                Expires August 16, 2007                [Page 2]


Internet-Draft              HIP DHT Interface              February 2007


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
   frequently updating stored values.

   One freely available implementation of a DHT is the Bamboo DHT, which
   is Java-based software that has been deployed on PlanetLab servers to
   form a free service named OpenDHT.  OpenDHT is available via the
   Internet for any program to store and retrieve arbitrary data.
   OpenDHT uses a well defined XML-RPC interface, featuring put, get,
   and remove operations.  This document discusses a common interface
   for HIP to be used with OpenDHT, so that various HIP implementations
   may leverage lookup services in an interoperable fashion.






























Ahrenholz                Expires August 16, 2007                [Page 3]


Internet-Draft              HIP DHT Interface              February 2007


2.  The OpenDHT interface

   OpenDHT is a public deployment of Bamboo DHT servers running on about
   150 PlanetLab nodes.  While the Bamboo project provides the actual
   software running on the servers, here we will refer only to OpenDHT,
   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
   multiple, different HIP implementations.

   OpenDHT 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.

   OpenDHT 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 OpenDHT website:
   <http://www.opendht.org/>

   Three RPC operations are supported: put, get, and rm (remove).  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.  Rm is
   called with a hash of the value to be removed along with a secret
   value, a hash of which was included in the put operation.

   The definitions below are taken from
   <http://opendht.org/users-guide.html>.


















Ahrenholz                Expires August 16, 2007                [Page 4]


Internet-Draft              HIP DHT Interface              February 2007


             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 |
         |                |                                      |
         | secret_hash    | optional SHA-1 hash of secret value  |
         +----------------+--------------------------------------+

     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.












Ahrenholz                Expires August 16, 2007                [Page 5]


Internet-Draft              HIP DHT Interface              February 2007


              The rm operation takes the following arguments:

     +----------------+----------------------------------------------+
     | field          | type                                         |
     +----------------+----------------------------------------------+
     | application    | string                                       |
     |                |                                              |
     | client_library | string                                       |
     |                |                                              |
     | key            | byte array, 20 bytes max.                    |
     |                |                                              |
     | value_hash     | SHA-1 hash of value to remove                |
     |                |                                              |
     | ttl_sec        | four-byte integer, max. value 604800         |
     |                |                                              |
     | secret         | secret value (SHA-1 of this was used in put) |
     +----------------+----------------------------------------------+

     The server replies with an integer -- 0 for "success", 1 if it is
              "over capacity", and 2 indicating "try again".

   This is the basic XML-RPC interface provided by OpenDHT.  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 August 16, 2007                [Page 6]


Internet-Draft              HIP DHT Interface              February 2007


3.  HIP lookup services

   Here we define an address lookup service for use with HIP, and
   provide a second definition that includes Host Identity signatures to
   protect against polluted DHT records.  A HIT lookup service is also
   defined for discovering a peer HIT given a name.

   First is the basic 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 address lookup service is then enhanced by including the peer's
   Host Identity and a signature over the address and a timestamp.  This
   allows the DHT client or server to validate the address information
   stored in the DHT.

   Finally, the HIT lookup service can be used when legacy DNS servers
   do not support HIP resource records, or when hosts do not have
   administrative access to their DNS records.  This unmanaged naming
   service may help facilitate the HIP IRTF experiment.

   These services reduce the amount of pre-configuration required at
   each HIP host.  The address of each peer no longer needs to be known
   ahead of time, if peers also participate by publishing their
   addresses.  If peers choose to publish their HITs with a name, peer
   HITs also no longer need pre-configuration.  However, the DHT server
   that will be contacted to service lookup requests is one additional
   configuration item.

3.1.  HIP address lookup

   Functionally, this interface is: addr = get(HIT).  Publish, lookup,
   and remove operations are defined.  Given a HIT, a lookup returns the
   preferred address of the peer.











Ahrenholz                Expires August 16, 2007                [Page 7]


Internet-Draft              HIP DHT Interface              February 2007


                              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        |
   |                |                                  |               |
   | secret_hash    | optional SHA-1 hash of secret    | base64        |
   |                | value                            | encoded       |
   +----------------+----------------------------------+---------------+

                              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)                          |                |
   +----------------+---------------------------------+----------------+













Ahrenholz                Expires August 16, 2007                [Page 8]


Internet-Draft              HIP DHT Interface              February 2007


                         Address remove (optional)

   +----------------+------------------------------------+-------------+
   | field          | value                              | data type   |
   +----------------+------------------------------------+-------------+
   | application    | "hip-addr"                         | string      |
   |                |                                    |             |
   | client_library | (implementation dependent)         | string      |
   |                |                                    |             |
   | key            | 128-bit HIT                        | base64      |
   |                |                                    | encoded     |
   |                |                                    |             |
   | value_hash     | SHA-1 hash of address value to     | base64      |
   |                | remove                             | encoded     |
   |                |                                    |             |
   | ttl_sec        | old address lifetime               | numeric     |
   |                |                                    | string      |
   |                |                                    |             |
   | secret         | secret value (SHA-1 of this was    | base64      |
   |                | used in put)                       | encoded     |
   +----------------+------------------------------------+-------------+

   The application and client_library fields are used for logging in
   OpenDHT.  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.  Other
   fields in the struct such as flowlabel and port numbers should be
   zeroed and ignored.  The length of the struct may be longer than the
   system's struct sockaddr, if for example the IPv6 struct sockaddr_in6
   is used.

   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.

   The secret_hash is an optional field used with address publish, used
   if the value will later be removed with an rm operation.  The
   secret_hash contains the base64 encoded SHA-1 hash of some secret
   value known only to the publishing host.

   The max_vals and placemark fields used with address lookup are



Ahrenholz                Expires August 16, 2007                [Page 9]


Internet-Draft              HIP DHT Interface              February 2007


   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.  Secure HIP address lookup

   The address lookup interface can be slightly modified to exploit the
   secure properties of the HIT.  Here, the Host Identity, a public key,
   is sent in the put operation, and is used to sign the contents of the
   record.  Now the DHT server and/or the client can verify that the HIT
   and address pair added to the DHT were added by the host possessing
   the private key associated with the given HIT.

   In order for the DHT server to support this HIT verification, the
   standard OpenDHT server would need to be modified.  Users running
   their own server can run the Bamboo DHT software, on which OpenDHT is
   based, with some modifications.  For put operations that include a
   signature, the signature needs to be verified using the given Host
   Identity, and the HIT provided needs to match this Host Identity.  If
   either signature or HIT verification fails, the put is not recorded
   into the DHT.

   The signature is also calculated over a timestamp to prevent replay
   attacks.  When the put message is received, the timestamp from the
   put is compared against the server's current time, and if the
   difference is greater than a certain threshold, the message is
   discarded.  This threshold is a local policy decision; a recommended
   value is 30 seconds.

   The client can perform the same signature and HIT verification.  If
   the signature is invalid for the given Host Identity or the HIT from
   the record does not match the Host Identity, the DHT record retrieved
   must be ignored.  Note that for client-only verification the DHT
   server does not need to be modified, so this would work on the
   existing OpenDHT PlanetLab deployment.  The timestamp is not as
   meaningful when received from the client get request, but the
   timestamp may be compared to the client's current time, to see if it
   exceeds the entry's time-to-live value.

   This interface is: (addr,timestamp,HI,sig) = get(HIT).  Publish,
   lookup, and remove operations are defined.  Given a HIT, a lookup
   returns the preferred address of the peer concatenated with the
   timestamp, Host Identity and a signature over the address and
   timestamp.






Ahrenholz                Expires August 16, 2007               [Page 10]


Internet-Draft              HIP DHT Interface              February 2007


                          Secure address publish

   +----------------+-------------------------------------+------------+
   | field          | value                               | data type  |
   +----------------+-------------------------------------+------------+
   | application    | "hip-secure-addr"                   | string     |
   |                |                                     |            |
   | client_library | (implementation dependent)          | string     |
   |                |                                     |            |
   | key            | 128-bit HIT                         | base64     |
   |                |                                     | encoded    |
   |                |                                     |            |
   | value          | struct sockaddr | timestamp | Host  | base64     |
   |                | Identity | signature                | encoded    |
   |                |                                     |            |
   | ttl_sec        | current address lifetime            | numeric    |
   |                |                                     | string     |
   |                |                                     |            |
   | secret_hash    | optional SHA-1 hash of secret value | base64     |
   |                |                                     | encoded    |
   +----------------+-------------------------------------+------------+

                              Address lookup

   +----------------+---------------------------------+----------------+
   | field          | value                           | data type      |
   +----------------+---------------------------------+----------------+
   | application    | "hip-secure-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)                          |                |
   +----------------+---------------------------------+----------------+













Ahrenholz                Expires August 16, 2007               [Page 11]


Internet-Draft              HIP DHT Interface              February 2007


                     Secure address remove (optional)

   +----------------+-------------------------------------+------------+
   | field          | value                               | data type  |
   +----------------+-------------------------------------+------------+
   | application    | "hip-addr"                          | string     |
   |                |                                     |            |
   | client_library | (implementation dependent)          | string     |
   |                |                                     |            |
   | key            | 128-bit HIT                         | base64     |
   |                |                                     | encoded    |
   |                |                                     |            |
   | value_hash     | SHA-1 hash of                       | base64     |
   |                | (address|timestamp|HI|sig) value to | encoded    |
   |                | remove                              |            |
   |                |                                     |            |
   | ttl_sec        | old address lifetime                | numeric    |
   |                |                                     | string     |
   |                |                                     |            |
   | secret         | secret value (SHA-1 of this was     | base64     |
   |                | used in put)                        | encoded    |
   +----------------+-------------------------------------+------------+

   The three secure address lookup operations put, get, and rm are
   identical to the address lookup operations, except that wherever the
   struct sockaddr (the address) was included before, it is appended
   with the concatenation of a timestamp, the Host Identity (in the
   encoding used in the Host Identity field, from section 5.2.8 of [2])
   and a signature calculated over the struct sockaddr value and the
   timestamp.  In the tables above, "|" signifies concatenation of
   values.  The signature is not computed over the Host Identity or the
   HIT because any change to these values results in validation failure.

   The timestamp is an unsigned 32-bit value representing the number of
   seconds since midnight UTC starting Jan 1, 1970 (standard UNIX time
   format).  Before the client signs the put message, it sets the
   timestamp to the current value of its internal clock.  The timestamp
   is meant to protect against replayed put messages as described above.

3.3.  HIP name to HIT lookup

   Functionally, this interface is: HIT = get(SHA-1(name)), where name
   is any text string defined by a host.  Given the SHA-1 hash of a
   name, a lookup returns the HIT of the peer.  The hash of a name is
   used because OpenDHT keys are limited to 20 bytes, so this allows for
   names longer than 20 bytes.  Publish, lookup, and remove operations
   are defined.




Ahrenholz                Expires August 16, 2007               [Page 12]


Internet-Draft              HIP DHT Interface              February 2007


                                HIT publish

   +----------------+----------------------------------+---------------+
   | field          | value                            | data type     |
   +----------------+----------------------------------+---------------+
   | application    | "hip-name-hit"                   | string        |
   |                |                                  |               |
   | client_library | (implementation dependent)       | string        |
   |                |                                  |               |
   | key            | SHA-1 hash of name               | base64        |
   |                |                                  | encoded       |
   |                |                                  |               |
   | value          | 128-bit HIT                      | base64        |
   |                |                                  | encoded       |
   |                |                                  |               |
   | ttl_sec        | name lifetime                    | numeric       |
   |                |                                  | string        |
   |                |                                  |               |
   | secret_hash    | optional SHA-1 hash of secret    | base64        |
   |                | value                            | encoded       |
   +----------------+----------------------------------+---------------+

                                HIT lookup

   +----------------+---------------------------------+----------------+
   | field          | value                           | data type      |
   +----------------+---------------------------------+----------------+
   | application    | "hip-name-hit"                  | string         |
   |                |                                 |                |
   | client_library | (implementation dependent)      | string         |
   |                |                                 |                |
   | key            | SHA-1 hash of name              | base64 encoded |
   |                |                                 |                |
   | maxvals        | (implementation dependent)      | numeric string |
   |                |                                 |                |
   | placemark      | (NULL, or used from server      | base64 encoded |
   |                | reply)                          |                |
   +----------------+---------------------------------+----------------+













Ahrenholz                Expires August 16, 2007               [Page 13]


Internet-Draft              HIP DHT Interface              February 2007


                           HIT remove (optional)

   +----------------+------------------------------------+-------------+
   | field          | value                              | data type   |
   +----------------+------------------------------------+-------------+
   | application    | "hip-name-hit"                     | string      |
   |                |                                    |             |
   | client_library | (implementation dependent)         | string      |
   |                |                                    |             |
   | key            | SHA-1 hash of name                 | base64      |
   |                |                                    | encoded     |
   |                |                                    |             |
   | value_hash     | SHA-1 hash of address value to     | base64      |
   |                | remove                             | encoded     |
   |                |                                    |             |
   | ttl_sec        | name lifetime                      | numeric     |
   |                |                                    | string      |
   |                |                                    |             |
   | secret         | secret value (SHA-1 of this was    | base64      |
   |                | used in put)                       | encoded     |
   +----------------+------------------------------------+-------------+

   The key for both HIT publish and lookup is the SHA-1 hash of the
   name.  The name does not necessarily need to be associated with a
   valid DNS or host name.  It does not need to be related to the Domain
   Identifier found in HI TLV.  OpenDHT limits the keys to 20 bytes in
   length, so the SHA-1 hash is used to allow arbitrary name lengths.
   The value used in the publish and lookup response is the base64-
   encoded 128-bit HIT.

   The ttl_sec field specifies the number of seconds for which the entry
   will be stored by the DHT, which is implementation dependent.

   The secret_hash is an optional field used with HIT publish if the
   value will later be removed with an rm operation.  The secret_hash
   contains the base64 encoded SHA-1 hash of some secret value known
   only to the publishing host.  The max_vals and placemark fields used
   with the HIT lookup are defined by the get XML-RPC interface.

3.4.  When to use the HIP lookup services

   Below are some suggestions of when a HIP implementation may want to
   use the address and HIT lookup services.

   To learn of a peer's HIT, a host might first consult DNS using the
   peer's hostname if the DNS server supports the HIP Resource Record
   defined by [3].  Sometimes hosts do not have administrative authority
   over their DNS entries and/or the DNS server is not able to support



Ahrenholz                Expires August 16, 2007               [Page 14]


Internet-Draft              HIP DHT Interface              February 2007


   HIP resource records.  Hosts may want to associate other non-DNS
   names with their HITs.  For these and other reasons, a host may use
   the HIT publish service defined in Section 3.3.  The peer HIT may be
   learned by performing a DHT lookup of such a name.

   Once a peer HIT is learned or 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
   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.  The host needs to
   periodically refresh this address entry because each entry carries a
   TTL and will eventually expire.  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.  The old address should be removed using the rm
   operation, if a secret value was used in the put.

   Addresses from the private address space should not be published to
   the DHT.  If the host is located behind a NAT, for example, the host
   could publish the address of its RVS to the DHT if that is how it is
   reachable.  In this case however, a peer could instead simply use the
   RVS field of the NATted host's HIP DNS record, which would eliminate
   a separate DHT lookup.

   A HIP host should also publish its HIT upon startup or whenever a new
   HIT is configured, for use with the HIT lookup service, if desired.
   The host should first check if the name already exists in the DHT by
   performing a lookup, to avoid interfering with an existing name-to-
   HIT mapping.  The name-to-HIT binding needs to be refreshed
   periodically before the TTL expires.











Ahrenholz                Expires August 16, 2007               [Page 15]


Internet-Draft              HIP DHT Interface              February 2007


4.  Issues with DHT support

   Each put operation appends the new value to any existing values.  If
   a host does not remove its old preferred address before adding
   another, several entries may be present.  Therefore when performing
   an address lookup, the last address in the list should be used and
   considered to be the current preferred address.  If performing a
   secure address lookup and several values are returned, the last valid
   address (validated using the signature and the HIT) should be used
   and considered to be the current preferred address.  Before
   performing each put a host should remove its old preferred address
   using the rm operation.

   All HITs carry the same prefix, so using them as a key to a DHT entry
   may cause uneven distribution of the stored values.  After some
   experience is gained utilizing this draft, it may prove beneficial to
   remove the HIT prefix and instead use the lower bits as the key.

   In the case of the HIT lookup service, there is nothing preventing
   different hosts from publishing the same name.  A lookup performed on
   this name will return multiple HITs that belong to different devices.
   This is an unmanaged free-for-all service, so this issue will not be
   solved here; it is recommended that a host simply pick another name.

   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.  OpenDHT does provide a DNS-
   based anycast service, when you perform a lookup of
   "opendht.nyuld.net", it will return the two nearest OpenDHT servers.

   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.

   The maximum size of 1024 bytes for the value field will limit the
   maximum size of the Host Identity that may be used with the secure
   address lookup service.













Ahrenholz                Expires August 16, 2007               [Page 16]


Internet-Draft              HIP DHT Interface              February 2007


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 OpenDHT 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 to implement the use of HIP
   signatures to validate put() requests for HITs as defined in
   Section 3.2.  When server validation of put() requests is not
   possible, such as in the OpenDHT service deployed today, the client
   should validate the record as described in Section 3.2.

   A timestamp is included in Section 3.2 to protect against replayed
   put messages.  Without checking the timestamp, an attacker could re-
   send the signed put message, possibly causing the entry to exist
   beyond its valid lifetime or even after it has been removed.

   Relying solely on client validation may be harmful.  If an attacker
   replays the signed put message and changes some aspect each time, and
   if the server is not performing signature and HIT validation, there
   could be a multitude of invalid entries stored in the DHT.  When a
   client retrieves these records it would need to perform signature and
   HIT verification on each one, which could cause unacceptable amounts
   of delay or computation.

   For the HIT lookup based on name (Section 3.3), there are no
   guarantees on the validity of the HIT.  Users concerned with the
   validity of HITs found in the DHT should simply exchange HITs out-of-
   band with peers.  Including a signature will not help here because
   the HIT that identifies the Host Identity for signing is not known
   ahead of time.












Ahrenholz                Expires August 16, 2007               [Page 17]


Internet-Draft              HIP DHT Interface              February 2007


6.  IANA Considerations

   This document has no actions for IANA.
















































Ahrenholz                Expires August 16, 2007               [Page 18]


Internet-Draft              HIP DHT Interface              February 2007


7.  Acknowledgments

   Thanks to Tom Henderson, Samu Varjonen, Andrei Gurtov, Miika Komu,
   and Kristian Slavov for providing comments.















































Ahrenholz                Expires August 16, 2007               [Page 19]


Internet-Draft              HIP DHT Interface              February 2007


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-06
        (work in progress), June 2006.

   [3]  Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
        Domain Name System (DNS) Extensions", draft-ietf-hip-dns-08
        (work in progress), October 2006.

   [4]  Nikander, P., "End-Host Mobility and Multihoming with the Host
        Identity Protocol", draft-ietf-hip-mm-04 (work in progress),
        June 2006.



































Ahrenholz                Expires August 16, 2007               [Page 20]


Internet-Draft              HIP DHT Interface              February 2007


Appendix A.  Change Log

A.1.  Changes from Version 00 to 01

   Removed the HIT lookup service -- using the LSI as a key to return a
   HIT as the value -- and added a HIT lookup service using names.

   Added support for OpenDHT remove.  Changed all occurrences of "Open
   DHT" to "OpenDHT".

   Added the Host Identity and a signature as a secure address lookup
   service, with text about running a modified OpenDHT server that can
   verify signed put messages based on Host Identity signatures.






































Ahrenholz                Expires August 16, 2007               [Page 21]


Internet-Draft              HIP DHT Interface              February 2007


Author's Address

   Jeff Ahrenholz
   The Boeing Company
   P.O. Box 3707
   Seattle, WA
   USA

   Email: jeffrey.m.ahrenholz@boeing.com










































Ahrenholz                Expires August 16, 2007               [Page 22]


Internet-Draft              HIP DHT Interface              February 2007


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.


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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ahrenholz                Expires August 16, 2007               [Page 23]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/