RFC 6537
Host Identity Protocol Distributed Hash Table Interface
Host Identity Protocol Distributed Hash Table Interface 🎀
Okay bestie, here's the title block tea ☕. This is an Experimental doc from the Internet Research Task Force (IRTF), written by J. Ahrenholz at The Boeing Company. It's dated February 2012 and has ISSN 2070-1721. It doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract 💖
This doc lays out a shared interface so the Host Identity Protocol (HIP) can use a Distributed Hash Table (DHT) service for two kinds of lookups: a name-to-Host-Identity-Tag lookup and a Host-Identity-Tag-to-address lookup. It's giving organized ✨.
Status of This Memo 📝
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪.
This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development activities. Those results might not be suitable for deployment, so be careful 🙈. This RFC represents the consensus of the HIP Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6537. 🔗
Copyright Notice ©️
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Read the fine print, babe 📜.
Table of Contents 🗂️
1. Introduction ....................................................2
2. The OpenDHT Interface ...........................................3
3. HDRR - The HIP DHT Resource Record ..............................6
4. HIP Lookup Services .............................................8
4.1. HIP Name to HIT Lookup .....................................9
4.2. HIP Address Lookup ........................................12
5. Use Cases ......................................................15
6. Issues with DHT Support ........................................16
7. Security Considerations ........................................17
8. IANA Considerations ............................................18
9. Acknowledgments ................................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................191. Introduction ✨
Okay so HIP ([RFC5201]) might benefit from a lookup service built on Distributed Hash Tables (DHTs), and this is giving main character energy 💅. The Host Identity namespace is flat and made of public keys, which is different from the hierarchical Domain Name System (DNS). Those keys get hashed and prefixed to form Host Identity Tags (HITs), which look like big random numbers 🎲.
Since the current DNS has been super optimized for address lookup, it's worth experimenting with other services like the ones defined here 🧪. DHTs handle this kind of data really well by using a hash function that spreads data across a bunch of servers. They're also designed to be updated more often than a DNS-based approach. If you want a different way of using HITs to look up IP addresses through DNS, check out [HIT2IP] 🔍.
One freely available DHT implementation is the Bamboo DHT. It's Java-based software that got deployed on PlanetLab servers to form a free service called OpenDHT. OpenDHT was available on the Internet for any program to store and retrieve arbitrary data 🌐. It used a well-defined Extensible Markup Language-Remote Procedure Calling (XML-RPC) interface with put, get, and remove operations. OpenLookup isn't implemented as a DHT, but it's another deployment of open source software that's compatible with this OpenDHT interface 🧚. This document talks about a shared way for HIP to use this OpenDHT interface, so various HIP experimenters can use lookup services in an interoperable way. Iconic, honestly 👑.
This document is a product of the HIP research group (RG) of the IRTF. The HIP research group reached consensus that this interface specification should be published as an Experimental RFC. That was based on document review by at least six RG members, including the chairs, and on implementation experience 🫶. This document is not an IETF product and is not a standard.
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] 📖.
2. The OpenDHT Interface 🍓
OpenDHT [OPENDHT] was a public deployment of Bamboo DHT servers. It ran on about 150 PlanetLab nodes and was retired in July 2009 🪦. The Bamboo project provided the actual software running on the servers, but here we'll only talk about OpenDHT, which uses a certain defined interface for the XML-RPC calls. Another service that's compatible with this interface is OpenLookup. You can also run your own Bamboo nodes to set up a private ring of servers 💜.
OpenDHT was chosen because it was a well-known, publicly available DHT used within the research community 🌸. Its interface features a simple, standards-based protocol that HIP developers can easily implement. This document doesn't aim to dictate that only the services and servers described here should be used. It's more of a starting point to gain experience with these services, picking tools that are readily available 🛠️.
OpenDHT stores values and indexes those 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.) For more info, 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, which causes 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 that secret was included in the put operation 🔑.
The definitions below are taken from the OpenDHT users guide at <http://opendht.org/users-guide.html>.
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 return code 3 indicates "failure" and is used for a modified OpenDHT server that performs signature and HIT verification, see Section 3 📦.
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 🧺.
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 OpenDHT provides. Each "field" from the tables above is an XML tag that encloses its corresponding value. The key is a byte array used to index the record for storage and retrieval from the DHT. The value is a byte array of the data being stored in the DHT. The application and client_library fields are metadata used only for logging purposes. The ttl_sec field specifies the number of seconds that the DHT should store the value. The secret_hash field allows values to be removed from the DHT later. The maxvals and placemark fields are for retrieving a maximum number of values and for iterating get results 🎀.
The return code of 0 "success" indicates a successful put or remove operation. The return code of 1 "over capacity" means that a client is using too much storage space on the server. The return value of 2 "try again" indicates that the client should retry the put operation, because a temporary problem prevented the server from accepting the put 🔁.
In the sections that follow, specific uses for these DHT operations and their XML fields are suggested for use with HIP ✨.
3. HDRR - The HIP DHT Resource Record ✨
okay so both of the lookup services in this doc run on something called a HIP DHT Resource Record (HDRR), and this section is all about it 💅 It's basically a wrapper around TLVs, which is giving HIP control packet energy. What's inside each HDRR is different for the two services.
The HDRR uses the exact same binary format as HIP packets (defined in [RFC5201].) It's a convenience thing 🫶 Even though it's actually a resource record that the DHT servers store and fetch, not a packet a HIP daemon sends over the wire. Also, this is NOT the same as the HIP RR that DNS uses, which is defined in [RFC5205]. It's a whole different record functionally 💀 In DNS, you query with a Fully Qualified Domain Name (FQDN) and get back a HIT, but here you query with a HIT.
Here are the HIP header values for the HDRR:
HIP Header:
Packet Type = 20 DHT Resource Record
SRC HIT = Sender's HIT
DST HIT = NULL
HDRR used with HIT lookup:
HIP ( [CERT] )
HDRR used with address lookup:
HIP ( LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIGNATURE )The Initiator HIT (Sender's HIT, SRC HIT) MUST be set to the HIT the host wants to make available through the lookup service 🦋 For the HIT lookup service, that's the main thing you get back from a get operation. For the address lookup service, this HIT MUST be the same one used to derive the HIT_KEY that serves as the DHT key. The Responder HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes) because the data is meant for any host 🌸
The only other TLV used with the HIT lookup service is an optional CERT parameter. It holds a certificate for validating the name used as the DHT key. The CERT parameter is defined in [RFC6253]. The DHT server SHOULD use that certificate to check that the client is allowed to use the name for the DHT key, by using the hash of the name found in the certificate. The Common Name (CN) field from the Distinguished Name (DN) of the X.509.v3 certificate MUST be used. Which certificates count as trusted is a local policy issue 👑
The rest of the parameters here are for the address lookup service.
The LOCATOR parameter has the addresses the host wants to make available through the lookup service. A host MAY publish its current preferred IPv4 and IPv6 locators, for example 🧚
The SEQ parameter holds an unsigned 32-bit sequence number, which is the Update ID. It's usually initialized to zero and goes up by one for each new HDRR the host publishes 📈 The host SHOULD keep the last Update ID it used for each HIT across reboots, or do a self lookup in the DHT instead. The Update ID may be kept in the DHT records, and it decides which address peers prefer ✨
The HOST_ID parameter holds the Host Identity that matches the Sender's HIT. (Its encoding is defined in Section 5.2.8 of [RFC5201].)
The HOST_ID parameter and HIP_SIGNATURE parameter MUST be used with the HDRR so that HIP clients who receive the record can validate the sender and the LOCATOR parameter they included 🔐 The HIT_KEY used for the DHT key gets checked against the Host Identity too.
The client that gets the HDRR back from the DHT response MUST do the signature and HIT_KEY verification 💖 If the signature is invalid for the given Host Identity, or the HIT_KEY used to retrieve the record doesn't match the Host Identity, the retrieved DHT record MUST be ignored. Also, for client-only verification, the DHT server doesn't need to be modified at all 🙈
The Sender's HIT in the HDRR MUST match the key used for the lookup and for the Host Identity verification. The Receiver's HIT MUST be NULL (all zeroes) in the HDRR header.
When the server returns several HDRR records, the client SHOULD pick the most recent one, going by the Update ID in the SEQ TLV of the HDRR, and verify that one 🍓 The order the records come back in should not be considered.
The DHT server MAY also verify the SIGNATURE and HOST_ID. That takes some changes to the Bamboo DHT software and a new return code with the OpenDHT interface 🛠️ The signature in the put MUST be verified using the given Host Identity (public key). The HIT_KEY provided as the lookup key MUST match that Host Identity according to the Overlay Routable Cryptographic Hash Identifiers (ORCHID) generation method defined by [RFC4843]. If either the signature or the HIT verification fails, the put MUST not be recorded into the DHT, and the server returns a failure code. That failure code isn't defined by OpenDHT. It's an extra return code with a value of 3.
⚠️ Heads up bestie: this server-side verification of records could open up a denial-of-service attack. The server policy could require clients to have an active HIP association to help with that. See Section 7 for the full tea 🫣
4. HIP Lookup Services 🌈
This document defines a HIT lookup service and an address lookup service for use with HIP 💜 The HIT lookup uses a text name to find a peer's HIT. The address lookup uses a peer's HIT to find its current addresses.
Here are the two lookups. The abbreviated notation refers to the HIP parameter types. For example, HIP_SIG is the HIP signature parameter defined by [RFC5201].
HDRR([CERT]) = get(SHA-1("name"))
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)The HIT lookup service returns the Host Identity Tag of a peer when you give it a name 🎀 The name SHOULD be the FQDN, the hostname, or some other alias. The HIT you're after is in the Sender's HIT field of the HDRR. The HIT is the hash of the public-key-based Host Identity, as described in [RFC5201]. The name has no security properties, unlike the HIT 🙅♀️ An optional certificate MAY be included in the record to validate the name, which gives some level of security. Which certificates count as trusted is a local policy issue. This service is meant for when legacy DNS servers don't support HIP resource records, or when hosts don't have admin access to publish their own DNS records. An unmanaged naming service like this may help with experimentation 🧪
The address lookup returns a locator and other validation data in the HDRR for a given HIT. Before a HIP association can be started (not in opportunistic mode), a HIP host needs to know the peer's HIT and the current address where the peer can be reached 📍 The HIT is often pre-configured, available through DNS lookup using a hostname lookup [RFC5205], or retrieved with the HIT lookup service defined in this document. With HIP mobility [RFC5206], IP addresses may be used as locators and they may change a lot. The Host Identity and the HIT stay pretty constant and can be used to securely identify a host, so the HIT is a great DHT key for storing and retrieving addresses 🦋
The address lookup service includes the peer's Host Identity and a signature over the locators. That lets the DHT client or server validate the address info stored in the DHT ✅
There are two separate lookups instead of one because the address record is expected to change more often, while the name-to-HIT binding should stay pretty stable. For example, local policy might check the name-to-HIT binding daily, while the address record gets updated hourly for active peers ⏰ Also, the client and server validation for the two records is different. The HIT lookup uses certificates to verify the name, and the address lookup uses a signature made by the holder of a particular Host Identity/HIT 🔑
These services cut down on the pre-configuration each HIP host needs 🥹 A peer's address doesn't have to be known ahead of time, as long as peers also publish their addresses. If peers choose to publish their HITs with a name, peer HITs don't need pre-configuration either. Finding an available DHT server to handle these lookups will still take some extra configuration, though 💅
4.1. HIP Name to HIT Lookup ✨
okay so bestie, here's the move: give a lookup the SHA-1 hash of a name and it hands you back the HIT of the peer 🦋 we hash the name because OpenDHT keys are capped at 20 bytes, and hashing lets longer names slide right in 💅 publish, lookup, and remove ops are all below, iykyk
HDRR([CERT]) = get(SHA-1("name"))
put(SHA-1("name"), HDRR([CERT]), [SHA-1(secret)])
rm(SHA-1("name"), SHA-1(HDRR), secret)HIT publish 🌸
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value | HDRR([CERT]), with the HIT to be | base64 |
| | published contained in the Sender's | encoded |
| | HIT field of the HDRR, and an optional | |
| | certificate for validating the name | |
| | used as the key | |
| | | |
| ttl_sec | lifetime for this record, value from | numeric |
| | 0-604800 seconds | string |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+HIT lookup 🧚
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+HIT remove (optional) 💜
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-name-hit" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | SHA-1 hash of a name | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used during | base64 |
| | publish) to remove | encoded |
| | | |
| ttl_sec | lifetime for the remove should be | numeric |
| | greater than or equal to the amount of | string |
| | time remaining for the record | |
| | | |
| secret | secret value (SHA-1 of this was used | base64 |
| | in put) | encoded |
+----------------+----------------------------------------+---------+The key for both HIT publish and lookup is the SHA-1 hash of the name, so no drama there ✨ the name doesn't have to be tied to a real DNS or host name, and it doesn't need to match the Domain Identifier in the HI TLV either 🎀 OpenDHT caps keys at 20 bytes, so SHA-1 is how we fit arbitrary name lengths in 🫶
The value in the publish and lookup response MUST be the base64-encoded HDRR containing the HIT, and it MAY include an optional certificate 💖 the HIT MUST be stored in the Sender's HIT field in the HDRR header. It's a 128-bit value, and you can spot it as a HIT by its length and by the ORCHID prefix [RFC4843] it starts with 🌈
If a certificate is included in this HIT record, the name used for the DHT key MUST be listed in the certificate, no exceptions bestie 🙈 the CERT parameter is defined in [RFC6253]. The Common Name (CN) field from the Distinguished Name (DN) of the X.509.v3 certificate MUST be used, and the server can hash that name to check it matches the DHT key ✨
The ttl_sec field is how many seconds the client asks the DHT server to keep the entry, and whether that actually happens is implementation or policy dependent 🍓
The secret_hash is an optional field for HIT publish, and it's only needed if the value will later get removed with an rm operation 💅 it is RECOMMENDED that clients support these rm operations for the values they publish, so you can clean up after yourself 🧹 the secret_hash holds the base64-encoded SHA-1 hash of some secret value that only the publishing host knows. A different secret value SHOULD be used for each put, because rm requests are visible on the network, and nobody needs to see your secrets 👀 the max_vals and placemark fields used with the HIT lookup are defined by the get XML-RPC interface 🦋
4.2. HIP Address Lookup ✨
okay so bestie, this one is giving "hand me a HIT and I'll tell you where the peer lives" 🗺️🫶 Given a HIT, a lookup returns the IP address of the peer. That address sits in a LOCATOR TLV inside the HDRR, tucked in with other validation data 🎀. This interface has publish, lookup, and remove operations, and here's a summary of all three. The abbreviated names are HIP parameter types, so HIP_SIG is the HIP signature parameter defined by [RFC5201] 🧚. The detailed version of these DHT operations comes right after 💅
HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
[SHA-1(secret)])
rm(HIT_KEY, SHA-1(HDRR), secret)The HDRR is defined in Section 3 and it's literally the main character here 👑 It holds one or more locators the peer wants to publish, a sequence number, the peer's Host Identity, an optional certificate, and a signature over all of it 🔥
The HIT_KEY is made from the last 100 bits of the HIT with 60 zero bits stuck on the end 🌸 That's the part of the HIT that gets used as the DHT key. Why the last 100 bits? To avoid uneven distribution of stored values across the DHT servers 🍓 The HIT's ORCHID Prefix (defined by [RFC4843]) is the first 28 bits, and it gets dropped, because it's the same for every HIT. Keeping it would cause exactly that uneven distribution 🙈 Zero padding then fills the 100-bit value out to the 160 bits the DHT needs 💜
Address publish
+----------------+----------------------------------------+---------+
| field | value | data |
| | | type |
+----------------+----------------------------------------+---------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value | HDRR(LOCATOR, SEQ, HOST_ID, [CERT], | base64 |
| | HIP_SIG), with the IP address to be | encoded |
| | published contained in the LOCATOR TLV | |
| | in the HDRR, along with other | |
| | validation data | |
| | | |
| ttl_sec | amount of time HDRR should be valid, | numeric |
| | or the lifetime of the preferred | string |
| | address, a value from 0-604800 seconds | |
| | | |
| secret_hash | optional SHA-1 hash of secret value | base64 |
| | | encoded |
+----------------+----------------------------------------+---------+Address lookup
+----------------+---------------------------------+----------------+
| field | value | data type |
+----------------+---------------------------------+----------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 encoded |
| | | |
| maxvals | (implementation dependent) | numeric string |
| | | |
| placemark | (NULL, or used from server | base64 encoded |
| | reply) | |
+----------------+---------------------------------+----------------+Address remove (optional)
+----------------+-------------------------------------+------------+
| field | value | data type |
+----------------+-------------------------------------+------------+
| application | "hip-addr" | string |
| | | |
| client_library | (implementation dependent) | string |
| | | |
| key | HIT_KEY | base64 |
| | | encoded |
| | | |
| value_hash | SHA-1 hash of HDRR (value used | base64 |
| | during publish) to 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 there for logging in OpenDHT 📝 client_library can differ between implementations. It names the XML-RPC library being used, or the app that makes the XML-RPC calls directly ✨
For both the address lookup and the publish, the key is the HIT_KEY from above, 160 bits base64 encoded [RFC2045] 🔑 The value in the publish and in the lookup response is the base64-encoded HDRR, which has one or more LOCATORs in it 💖
ttl_sec on the publish side is the time-to-live (TTL), meaning how many seconds the DHT will keep the entry 🕰️ The TTL SHOULD be set to the number of seconds remaining in the address lifetime 💅
secret_hash is optional. It MAY be used on publish if the value will be removed later with an rm operation 🫣 It holds the base64-encoded SHA-1 hash of some secret value, and that secret MUST be known only to the publishing host 🤫 Clients SHOULD include the secret_hash and remove outdated values, so the peer has less data to handle 🧹 Also, a different secret value SHOULD be used for each put, because rm requests are visible on the network 👀
On the lookup side, max_vals and placemark are defined by the get XML-RPC interface. get needs to know the maximum number of values to retrieve 🔢 The placemark is a value found in the server reply that tells get to pick up where it left off 🔖
5. Use Cases ✨
Here are some suggestions for when a HIP implementation MAY want to use the HIT and address lookup services 🦋
To learn a peer's HIT, a host might first ask DNS using the peer's hostname, but only if the DNS server supports the HIP resource record defined by [RFC5205] 🌐 Sometimes hosts don't have administrative authority over their DNS entries, or the DNS server just can't support HIP resource records 😭 Hosts may also want to link other non-DNS names to their HITs. For these reasons and more, a host MAY use the HIT publish service defined in Section 4.1 🎀 The peer's HIT can then be learned by doing a DHT lookup of that name 🧚
Once a peer HIT is learned or configured, an address lookup MAY be performed so the LOCATORs can be cached and ready to go when an association is requested ⚡ Implementations might load a list of peer HITs on startup, which means several lookups that can take a little while to finish 🐢
Cached LOCATORs can go stale fast, though, depending on how often the peer changes its preferred address 🫠 Doing an address lookup before sending the I1 may be needed. But the lookup latency might be intolerable at that point, so a lookup could instead happen after the I1 retransmission timer fires (when no R1 reply has arrived) to catch any address change 👑
A HIP host SHOULD publish its preferred LOCATORs on startup, so other hosts can figure out where it's reachable 🗺️ The host SHOULD refresh its HDRR entry periodically, because every entry carries a TTL and will eventually expire ⏳ And when the preferred address changes, which usually comes with sending UPDATE packets that include locator parameters, the host SHOULD update its HDRR in the DHT 💫 The old HDRR SHOULD be removed with 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 behind a NAT, for example, it could publish the address of its Rendezvous Server (RVS, from [RFC5204]) to the DHT, if that's how it can be reached 🛰️ In that case though, a peer could just use the RVS field of the NATed host's HIP DNS record instead, which skips a separate DHT lookup 🧠
A HIP host SHOULD also publish its HIT on startup or whenever a new HIT gets configured, for use with the HIT lookup service, if it wants to 💖 The host SHOULD first check whether the name already exists in the DHT by doing a lookup, so it doesn't mess with an existing name-to-HIT mapping 🙈 The name-to-HIT binding needs refreshing periodically, before the TTL runs out ⏰
When publishing to a DHT server, take care to check the server's response 👀 The server may respond with an "over capacity" code, which means its resources are too burdened to honor the given size and TTL 🥵 The host SHOULD then pick another server for publishing, or reduce the TTL and retry the put operation 🔁✨
6. Issues with DHT Support ✨
okay so the DHT put is lowkey a drama queen 🙄 because it does not replace existing values. If a host doesn't clean up its old HDRR before adding a new one, you can end up with several entries hanging around 💀. A client doing a lookup SHOULD figure out the most recent address using the Update ID from the SEQ TLV of the HDRR 🔍. The order of values in the server's response may not be guaranteed, so it's giving chaos 🌀. Before every put, a host SHOULD clear its old HDRR data using the rm operation 🧹.
With the HIT lookup service, nothing stops different hosts from publishing the same name 👯. That means one lookup can return multiple HITs belonging to different devices 🙃. The server may enforce a policy that requires clients to include a certificate when publishing a HIT, and only store HITs whose name has been authorized by some trusted certificate. Otherwise it's an unmanaged free-for-all, and it is RECOMMENDED that a host simply pick another name 🎀.
Picking which DHT server to use isn't covered here 🤷♀️. If a server becomes unavailable, the connect will timeout, and some server selection algorithm SHOULD be performed, like trying the next server in a configured list. OpenDHT used to have a DNS-based anycast service: looking up opendht.nyuld.net gave you the two nearest OpenDHT servers 🌍.
The latency with the DHT put and get operations should be considered when using these services with HIP ⏳. The calls rely on servers that may be located across the Internet, and they may trigger server-to-server chatter that adds delay. The DHT operations themselves may also be slow to produce a response 😴.
The maximum size of 1024 bytes for the value field limits how big the Host Identity and certificates in the HDRR can be 📏.
7. Security Considerations 💀🔐
okay this one is serious bestie, so let's get into it 🕵️♀️. There are two classes of attacks on this info exchange between the host and the DHT server. The first is attacks on the validity of what the DHT tells the host, like a spoofed DHT response 😱. The second is attacks on the DHT records themselves, like polluted records for a given key 🫠. Without the server doing some measure of verification, not much can be done to stop these 🥲.
For the HIT lookup based on a name (Section 4.1), there are no guarantees on the validity of the HIT 🙅♀️. Users who are concerned about HITs found in the DHT SHOULD simply exchange HITs out-of-band with their peers 🤝. Including a signature won't help here, because the HIT that identifies the Host Identity for signing isn't known ahead of time 🤔. A certificate MAY be included with the HIT, which guarantees that the name used for the lookup has been authorized by some third-party authority 📜. Which certificates are considered trusted is a local policy issue.
For the address lookup based on HIT (Section 4.2), the validity of the DHT response MUST be checked with the HOST_ID and SIGNATURE parameters in the HDRR 🔐. A HIP initiating host SHOULD also validate the DHT response after the R1 message is received during a HIP exchange 🔁. The Host Identity provided in the R1 can be hashed to obtain a HIT, and that HIT MUST be checked against the original HIT ✅. However, a legacy OpenDHT service without server modifications doesn't prevent an attacker from polluting the DHT records for a known HIT. That can cause a denial-of-service attack, since server validation isn't performed 🚨.
Relying solely on client validation may be harmful 💔. An attacker can replay the put packets containing the signed HDRR, possibly leaving stale or invalid information in the DHT. If an attacker replays the signed put message and changes some aspect each time, and the server isn't performing signature and HIT validation, there could be a multitude of invalid entries stored 🗑️. 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 🥵.
To protect against this type of attack, the DHT server SHOULD perform signature and HIT verification of each put operation, as described in Section 3 🛡️. Another option is for the server to run HIP itself and require client authentication with a HIP association before accepting HDRR puts. Further validation would be only accepting HIT and address records from the association bound to the same HIT 💅.
Performing server-side verification adds to the processing burden of the DHT server and may be a source for a denial-of-service attack 😬. Requiring a HIP association before accepting HDRR puts may help here. HIT verification is less computationally intensive by design, since it uses a hash algorithm. Certificate validation (for name lookups) and signature verification (for HDRRs) may cause unacceptable amounts of computation. A server may rate limit the number of puts that it allows 🚦.
The SHA-1 message digest algorithm is used in two ways in this document, and the security of using this algorithm should be considered within the context of [RFC6194] 🧐. The first use is with the OpenDHT put and remove operations, described in Section 2. The second is to reduce the size of the name string for the HIT lookup service in Section 4.1.
The first use is meant to protect the secret values used to store records in the DHT, as described by the OpenDHT interface 🔒. An attacker would be able to remove a record, after capturing the plaintext put, if a secret value could be found that produces the same secret hash 😈. The purpose of this document is to maintain interoperable compatibility with that interface, which prescribes the use of SHA-1. Future revisions of that interface should consider hash algorithm agility 🔄. The OpenDHT FAQ states that future support for other hash algorithms is planned.
The second use of the SHA-1 algorithm is to reduce the arbitrarily sized name strings to fit the fixed OpenDHT key size. No security properties of the SHA-1 algorithm are used in this context 🙏.
8. IANA Considerations 🏷️
This document defines a new HIP Packet Type, the "HIP Distributed Hash Table Resource Record (HDRR)". This packet type is defined in Section 3 with a value of 20 🎉.
9. Acknowledgments 💜
Thanks to Tom Henderson, Samu Varjonen, Andrei Gurtov, Miika Komu, Kristian Slavov, Ken Rimey, Ari Keranen, and Martin Stiemerling for providing comments 🫶. Samu most notably contributed the resolver packet and its suggested parameters, which became the HDRR here 👑.
10. References 📚
10.1. Normative References
- [OPENDHT] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stocia, I., and H. Yu, "OpenDHT: A Public DHT Service and Its Uses", Proceedings of ACM SIGCOMM 2005, August 2005.
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
- [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
- [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008.
- [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
- [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
10.2. Informative References
- [HIT2IP] Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags Data in DNS", Work in Progress, July 2009.
- [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008.
- [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
Author's Address 🦋
Jeff Ahrenholz
The Boeing Company
P.O. Box 3707
Seattle, WA
USA
EMail: jeffrey.m.ahrenholz@boeing.com📦 where this page comes from
- ietf: rfc6537 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms