idnits 2.17.1
draft-irtf-hiprg-dht-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
The DHT server MAY also verify the SIGNATURE and HOST_ID, with some
modifications 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), and the HIT_KEY provided as the lookup
key MUST match this Host Identity according to the ORCHID generation
method defined by [RFC4843]. If either signature or HIT verification
fails, the put MUST not be recorded into the DHT, and the server returns
a failure code. The failure code is an additional return code not
defined by OpenDHT, with a value of 3.
-- The document date (December 14, 2011) is 4510 days in the past. Is this
intentional?
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'CERT' is mentioned on line 552, but not defined
** Obsolete normative reference: RFC 4843 (Obsoleted by RFC 7343)
** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401)
** Obsolete normative reference: RFC 5205 (Obsoleted by RFC 8005)
** Obsolete normative reference: RFC 6253 (Obsoleted by RFC 8002)
-- Obsolete informational reference (is this intentional?): RFC 5204
(Obsoleted by RFC 8004)
-- Obsolete informational reference (is this intentional?): RFC 5206
(Obsoleted by RFC 8046)
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HIP Research Group J. Ahrenholz
3 Internet-Draft The Boeing Company
4 Intended status: Experimental December 14, 2011
5 Expires: June 16, 2012
7 Host Identity Protocol Distributed Hash Table Interface
8 draft-irtf-hiprg-dht-05
10 Abstract
12 This document specifies a common interface for using the Host
13 Identity Protocol (HIP) with a Distributed Hash Table service to
14 provide a name-to-Host-Identity-Tag lookup service and a Host-
15 Identity-Tag-to-address lookup service.
17 Status of this Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on June 16, 2012.
34 Copyright Notice
36 Copyright (c) 2011 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 2. The OpenDHT interface . . . . . . . . . . . . . . . . . . . . 4
53 3. HDRR - the HIP DHT Resource Record . . . . . . . . . . . . . . 7
54 4. HIP lookup services . . . . . . . . . . . . . . . . . . . . . 10
55 4.1. HIP name to HIT lookup . . . . . . . . . . . . . . . . . . 11
56 4.2. HIP address lookup . . . . . . . . . . . . . . . . . . . . 13
57 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 17
58 6. Issues with DHT support . . . . . . . . . . . . . . . . . . . 19
59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
64 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
65 Appendix A. Change Log (to be removed by RFC Editor before
66 publication) . . . . . . . . . . . . . . . . . . . . 25
67 A.1. Changes from hiprg 04 to 05 . . . . . . . . . . . . . . . 25
68 A.2. Changes from hiprg 03 to 04 . . . . . . . . . . . . . . . 25
69 A.3. Changes from hiprg 02 to 03 . . . . . . . . . . . . . . . 25
70 A.4. Changes from hiprg 01 to 02 . . . . . . . . . . . . . . . 25
71 A.5. Changes from hiprg 00 to 01 . . . . . . . . . . . . . . . 25
72 A.6. Changes from Version ahrenholz 06 to hiprg 00 . . . . . . 25
73 A.7. Changes from Version 05 to 06 . . . . . . . . . . . . . . 25
74 A.8. Changes from Version 04 to 05 . . . . . . . . . . . . . . 26
75 A.9. Changes from Version 03 to 04 . . . . . . . . . . . . . . 26
76 A.10. Changes from Version 02 to 03 . . . . . . . . . . . . . . 26
77 A.11. Changes from Version 01 to 02 . . . . . . . . . . . . . . 26
78 A.12. Changes from Version 00 to 01 . . . . . . . . . . . . . . 26
79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
81 1. Introduction
83 The Host Identity Protocol [RFC5201] (HIP) may benefit from a lookup
84 service based on Distributed Hash Tables (DHTs). The Host Identity
85 namespace is flat, consisting of public keys, in contrast to the
86 hierarchical Domain Name System. These keys are hashed and prefixed
87 to form Host Identity Tags (HITs), which appear as large random
88 numbers. As the current DNS system has been heavily optimized for
89 address lookup, it may be worthwhile to experiment with other
90 services such as those defined here. DHTs manage such data well by
91 applying a hash function that distributes data across a number of
92 servers. DHTs are also designed to be updated more frequently than a
93 DNS-based approach. For an alternative method of using HITs to
94 lookup IP addresses using DNS, see [I-D.ponomarev-hip-hit2ip].
96 One freely available implementation of a DHT is the Bamboo DHT, which
97 is Java-based software that has been deployed on PlanetLab servers to
98 form a free service named OpenDHT. OpenDHT was available via the
99 Internet for any program to store and retrieve arbitrary data.
100 OpenDHT used a well defined XML-RPC interface, featuring put, get,
101 and remove operations. OpenLookup, while not implemented as a DHT,
102 is another deployment of open source software compatible with this
103 OpenDHT interface. This document discusses a common way for HIP to
104 use this OpenDHT interface, so that various HIP experimenters may
105 employ lookup services in an interoperable fashion.
107 This document is a product of the HIP research group of the IRTF.
108 The HIP research group reached consensus that this interface
109 specification should be published as an experimental RFC, based on
110 document review by at least six RG members including the chairs, and
111 based on implementation experience. This document is not an IETF
112 product and is not a standard.
114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
116 document are to be interpreted as described in RFC 2119.
118 2. The OpenDHT interface
120 OpenDHT [opendht] was a public deployment of Bamboo DHT servers that
121 ran on about 150 PlanetLab nodes, retired in July 2009. While the
122 Bamboo project provided the actual software running on the servers,
123 here we will refer only to OpenDHT, which uses a certain defined
124 interface for the XML-RPC calls. Another service compatible with
125 this interface is OpenLookup. One can run their own Bamboo nodes to
126 set up a private ring of servers.
128 OpenDHT was chosen because it was a well-known, publicly available
129 DHT used within the research community. Its interface features a
130 simple, standards-based protocol that can be easily implemented by
131 HIP developers. This document does not aim to dictate that only the
132 services and servers described here should be used, but is rather
133 meant to act as a starting point to gain experience with these
134 services, choosing tools that are readily available.
136 OpenDHT stores values and indexes those values by using (hash) keys.
137 Keys are limited to 20 bytes in length, and values can be up to 1024
138 bytes. Values are stored for a certain number of seconds, up to a
139 maximum of 604,800 seconds (one week.) See the OpenDHT website:
140
142 Three RPC operations are supported: put, get, and rm (remove). Put
143 is called with key and value parameters, causing the value to be
144 stored using the key as its hash index. Get is called with the key
145 parameter, when you have a key and want to retrieve the value. Rm is
146 called with a hash of the value to be removed along with a secret
147 value, a hash of which was included in the put operation.
149 The definitions below are taken from the OpenDHT users guide at
150 .
152 The put operation takes the following arguments:
154 +----------------+--------------------------------------+
155 | field | type |
156 +----------------+--------------------------------------+
157 | application | string |
158 | | |
159 | client_library | string |
160 | | |
161 | key | byte array, 20 bytes max. |
162 | | |
163 | value | byte array, 1024 bytes max. |
164 | | |
165 | ttl_sec | four-byte integer, max. value 604800 |
166 | | |
167 | secret_hash | optional SHA-1 hash of secret value |
168 +----------------+--------------------------------------+
170 The server replies with an integer -- 0 for "success", 1 if it is
171 "over capacity", and 2 indicating "try again". The return code 3
172 indicates "failure" and is used for a modified OpenDHT server that
173 performs signature and HIT verification, see Section 3.
175 The get operation takes the following arguments:
177 +----------------+---------------------------------------------+
178 | field | type |
179 +----------------+---------------------------------------------+
180 | application | string |
181 | | |
182 | client_library | string |
183 | | |
184 | key | byte array, 20 bytes max. |
185 | | |
186 | maxvals | four-byte singed integer, max. value 2^31-1 |
187 | | |
188 | placemark | byte array, 100 bytes max. |
189 +----------------+---------------------------------------------+
191 The server replies with an array of values, and a placemark that can
192 be used for fetching additional values.
194 The rm operation takes the following arguments:
196 +----------------+----------------------------------------------+
197 | field | type |
198 +----------------+----------------------------------------------+
199 | application | string |
200 | | |
201 | client_library | string |
202 | | |
203 | key | byte array, 20 bytes max. |
204 | | |
205 | value_hash | SHA-1 hash of value to remove |
206 | | |
207 | ttl_sec | four-byte integer, max. value 604800 |
208 | | |
209 | secret | secret value (SHA-1 of this was used in put) |
210 +----------------+----------------------------------------------+
212 The server replies with an integer -- 0 for "success", 1 if it is
213 "over capacity", and 2 indicating "try again".
215 This is the basic XML-RPC interface provided by OpenDHT. Each
216 "field" from the above tables are XML tags that enclose their
217 corresponding values. The key is a byte array used to index the
218 record for storage and retrieval from the DHT. The value is a byte
219 array of the data being stored in the DHT. The Application and
220 client_library fields are meta-data used only for logging purposes.
221 The ttl_sec field specifies the number of seconds that the DHT should
222 store the value. The secret_hash field allows values to be later
223 removed from the DHT. The maxvals and placemark fields are for
224 retrieving a maximum number of values and for iterating get results.
226 The return code of 0 "success" indicates a successful put or remove
227 operation. The return code of 1 "over capacity" means that a client
228 is using too much storage space on the server. The return value of 2
229 "try again" indicates that the client should retry the put operation
230 because a temporary problem prevented the server from accepting the
231 put.
233 In the sections that follow, specific uses for these DHT operations
234 and their XML fields are suggested for use with HIP.
236 3. HDRR - the HIP DHT Resource Record
238 The two lookup services described in this document use a HIP DHT
239 Resource Record (HDRR) defined in this section. This record is a
240 wrapper around data contained in TLVs, similar to a HIP control
241 packet. The data contained in each HDRR differs between the two
242 services.
244 The HDRR uses the same binary format as HIP packets (defined in
245 [RFC5201].) This packet encoding is used as a convenience, even
246 though this data is actually a resource record stored and retrieved
247 by the DHT servers, not a packet sent on the wire by a HIP protocol
248 daemon. Note that this HDRR format is different than the HIP RR used
249 by the Domain Name System as defined in [RFC5205]. The reason it is
250 different is that it is a different record from a functional point of
251 view: in DNS, the query key is a FQDN, and the return value is a HIT,
252 while here, the query key is a HIT.
254 HIP header values for the HDRR:
256 HIP Header:
257 Packet Type = 20 DHT Resource Record (this value is TBD)
258 SRC HIT = Sender's HIT
259 DST HIT = NULL
261 HDRR used with HIT lookup:
262 HIP ( [CERT] )
264 HDRR used with address lookup:
265 HIP ( LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIGNATURE )
267 The Initiator HIT (Sender's HIT, SRC HIT) MUST be set to the HIT that
268 the host wishes to make available using the lookup service. With the
269 HIT lookup service, this is the main piece of information returned by
270 a get operation. For the address lookup service, this HIT MUST be
271 the same one used to derive the HIT_KEY used as the DHT key. The
272 Responder HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes)
273 since the data is intended for any host.
275 The only other TLV used with the HIT lookup service is an optional
276 CERT parameter containing a certificate for validating the name that
277 is used as the DHT key. The CERT parameter is defined in [RFC6253].
278 The DHT server SHOULD use the certificate to verify that the client
279 is authorized to use the name used for the DHT key, using the hash of
280 the name found in the certificate. The Common Name (CN) field from
281 the distinguished name (DN) of the X.509.v3 certificate MUST be used.
282 Which certificates the server considers trusted is a policy issue.
284 The remaining parameters described here are used with the address
285 lookup service.
287 The LOCATOR parameter contains the addresses that the host wishes to
288 make available using the lookup service. A host MAY publish its
289 current preferred IPv4 and IPv6 locators, for example.
291 The SEQ parameter contains an unsigned 32-bit sequence number, the
292 Update ID. This is typically initialized to zero and incremented by
293 one for each new HDRR that is published by the host. The host SHOULD
294 retain the last Update ID value it used for each HIT across reboots,
295 or perform a self lookup in the DHT. The Update ID value may be
296 retained in the DHT records and will determine the preferred address
297 used by peers.
299 The HOST_ID parameter contains the Host Identity that corresponds
300 with the Sender's HIT. (The encoding of this parameter is defined in
301 section 5.2.8 of [RFC5201].)
303 The HOST_ID parameter and HIP_SIGNATURE parameter MUST be used with
304 the HDRR so that HIP clients receiving the record can validate the
305 sender and the included LOCATOR parameter. The HIT_KEY used for the
306 DHT key will also be verified against the Host Identity.
308 The client that receives the HDRR from the DHT response MUST perform
309 the signature and HIT_KEY verification. If the signature is invalid
310 for the given Host Identity or the HIT_KEY used to retrieve the
311 record does not match the Host Identity, the DHT record retrieved
312 MUST be ignored. Note that for client-only verification the DHT
313 server does not need to be modified
315 The Sender's HIT in the HDRR MUST correspond with the key used for
316 the lookup and Host Identity verification. The Receiver's HIT MUST
317 be NULL (all zeroes) in the HDRR header.
319 When several HDRR records are returned by the server, the client
320 SHOULD pick the most recent record as indicated by the Update ID in
321 the SEQ TLV of the HDRR, and perform verification on that record.
322 The order in which records are returned should not be considered.
324 The DHT server MAY also verify the SIGNATURE and HOST_ID, with some
325 modifications to the Bamboo DHT software and a new return code with
326 the OpenDHT interface. The signature in the put MUST be verified
327 using the given Host Identity (public key), and the HIT_KEY provided
328 as the lookup key MUST match this Host Identity according to the
329 ORCHID generation method defined by [RFC4843]. If either signature
330 or HIT verification fails, the put MUST not be recorded into the DHT,
331 and the server returns a failure code. The failure code is an
332 additional return code not defined by OpenDHT, with a value of 3.
334 This server-side verification of records could introduce a source of
335 a denial of service attack. The server policy could require clients
336 to have an active HIP association. See Section 7 for further
337 discussion.
339 4. HIP lookup services
341 This draft defines a HIT lookup and address lookup service for use
342 with HIP. The HIT lookup uses a text name to discover a peer's HIT.
343 The address lookup uses a peer's HIT to discover its current
344 addresses.
346 The two lookups are defined below. The abbreviated notation refers
347 to the HIP parameter types; for example HIP_SIG is the HIP signature
348 parameter defined by [RFC5201].
350 HDRR([CERT]) = get(SHA-1("name"))
351 HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
353 The HIT lookup service returns the Host Identity Tag of a peer given
354 a name. The name SHOULD be the FQDN, hostname, or some other alias.
355 This HIT is found in the Sender's HIT field of the HDRR. The HIT is
356 the hash of the public-key based Host Identity as described in
357 [RFC5201]. There are no security properties of the name, unlike the
358 HIT. An optional certificate MAY be included in the record, for
359 validating the name, providing some measure of security. Which
360 certificates to consider trusted is a policy issue. This service is
361 intended for use when legacy DNS servers do not support HIP resource
362 records, or when hosts do not have administrative access to publish
363 their own DNS records. Such an unmanaged naming service may help
364 facilitate experimentation.
366 The address lookup returns a locator and other validation data in the
367 HDRR for a given HIT. Before a HIP association can be initiated (not
368 in opportunistic mode), a HIP host needs to know the peer's HIT and
369 the current address at which the peer is reachable. Often the HIT
370 will be pre-configured, available via DNS lookup using a hostname
371 lookup [RFC5205], or retrieved using the HIT lookup service defined
372 in this document. With HIP mobility [RFC5206], IP addresses may be
373 used as locators and may often change. The Host Identity and the HIT
374 remain relatively constant and can be used to securely identify a
375 host, so the HIT serves as a suitable DHT key for storing and
376 retrieving addresses.
378 The address lookup service includes the peer's Host Identity and a
379 signature over the locators. This allows the DHT client or server to
380 validate the address information stored in the DHT.
382 These two separate lookups are defined instead of one because the
383 address record is expected to change more frequently, while the name-
384 to-HIT binding should remain relatively constant. For example, local
385 policy may specify checking the name-to-HIT binding on a daily basis,
386 while the address record is updated hourly for active peers. Also
387 the client and server validation of the two records is different,
388 with the HIT lookup using certificates verifying the name and the
389 address lookup using a signature produced by the bearer of a
390 particular Host Identity/HIT.
392 These services reduce the amount of pre-configuration required at
393 each HIP host. The address of each peer no longer needs to be known
394 ahead of time, if peers also participate by publishing their
395 addresses. If peers choose to publish their HITs with a name, peer
396 HITs also no longer require pre-configuration. However, discovering
397 an available DHT server for servicing these lookups will require some
398 additional configuration.
400 4.1. HIP name to HIT lookup
402 Given the SHA-1 hash of a name, a lookup returns the HIT of the peer.
403 The hash of a name is used because OpenDHT keys are limited to 20
404 bytes, so this allows for longer names. Publish, lookup, and remove
405 operations are defined.
407 HDRR([CERT]) = get(SHA-1("name"))
408 put(SHA-1("name"), HDRR([CERT]), [SHA-1(secret)])
409 rm(SHA-1("name"), SHA-1(HDRR), secret)
411 HIT publish
413 +----------------+----------------------------------------+---------+
414 | field | value | data |
415 | | | type |
416 +----------------+----------------------------------------+---------+
417 | application | "hip-name-hit" | string |
418 | | | |
419 | client_library | (implementation dependent) | string |
420 | | | |
421 | key | SHA-1 hash of a name | base64 |
422 | | | encoded |
423 | | | |
424 | value | HDRR([CERT]), with the HIT to be | base64 |
425 | | published contained in the Sender's | encoded |
426 | | HIT field of the HDRR, and an optional | |
427 | | certificate for validating the name | |
428 | | used as the key | |
429 | | | |
430 | ttl_sec | lifetime for this record, value from | numeric |
431 | | 0-604800 seconds | string |
432 | | | |
433 | secret_hash | optional SHA-1 hash of secret value | base64 |
434 | | | encoded |
435 +----------------+----------------------------------------+---------+
437 HIT lookup
439 +----------------+---------------------------------+----------------+
440 | field | value | data type |
441 +----------------+---------------------------------+----------------+
442 | application | "hip-name-hit" | string |
443 | | | |
444 | client_library | (implementation dependent) | string |
445 | | | |
446 | key | SHA-1 hash of a name | base64 encoded |
447 | | | |
448 | maxvals | (implementation dependent) | numeric string |
449 | | | |
450 | placemark | (NULL, or used from server | base64 encoded |
451 | | reply) | |
452 +----------------+---------------------------------+----------------+
454 HIT remove (optional)
456 +----------------+----------------------------------------+---------+
457 | field | value | data |
458 | | | type |
459 +----------------+----------------------------------------+---------+
460 | application | "hip-name-hit" | string |
461 | | | |
462 | client_library | (implementation dependent) | string |
463 | | | |
464 | key | SHA-1 hash of a name | base64 |
465 | | | encoded |
466 | | | |
467 | value_hash | SHA-1 hash of HDRR (value used during | base64 |
468 | | publish) to remove | encoded |
469 | | | |
470 | ttl_sec | lifetime for the remove should be | numeric |
471 | | greater than or equal to the amount of | string |
472 | | time remaining for the record | |
473 | | | |
474 | secret | secret value (SHA-1 of this was used | base64 |
475 | | in put) | encoded |
476 +----------------+----------------------------------------+---------+
478 The key for both HIT publish and lookup is the SHA-1 hash of the
479 name. The name does not necessarily need to be associated with a
480 valid DNS or host name. It does not need to be related to the Domain
481 Identifier found in HI TLV. OpenDHT limits the keys to 20 bytes in
482 length, so the SHA-1 hash is used to allow arbitrary name lengths.
484 The value used in the publish and lookup response MUST be the base64-
485 encoded HDRR containing the HIT, and MAY include an optional
486 certificate. The HIT MUST be stored in the Sender's HIT field in the
487 HDRR header, and is a 128-bit value than can be identified as a HIT
488 both by its length and by the ORCHID prefix ([RFC4843]) that it
489 starts with.
491 If a certificate is included in this HIT record, the name used for
492 the DHT key MUST be listed in the certificate. The CERT parameter is
493 defined in [RFC6253]. The Common Name (CN) field from the
494 distinguished name (DN) of the X.509.v3 certificate MUST be used.
495 The server can hash this name to verify it matches the DHT key.
497 The ttl_sec field specifies the number of seconds requested by the
498 client that the entry should be stored by the DHT server, which is
499 implementation or policy dependent.
501 The secret_hash is an optional field used with HIT publish if the
502 value will later be removed with an rm operation. It is RECOMMENDED
503 that clients support these rm operations for the values they publish.
504 The secret_hash contains the base64 encoded SHA-1 hash of some secret
505 value known only to the publishing host. A different secret value
506 SHOULD be used for each put because rm requests are visible on the
507 network. The max_vals and placemark fields used with the HIT lookup
508 are defined by the get XML-RPC interface.
510 4.2. HIP address lookup
512 Given a HIT, a lookup returns the IP address of the peer. The
513 address is contained in a LOCATOR TLV inside the HDRR, along with
514 other validation data. This interface has publish, lookup, and
515 remove operations. A summary of these three operations is listed
516 below. The abbreviated notation refers to the HIP parameter types;
517 for example HIP_SIG is the HIP signature parameter defined by
518 [RFC5201]. The details of these DHT operations is then described in
519 greater detail.
521 HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
522 put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
523 [SHA-1(secret)])
524 rm(HIT_KEY, SHA-1(HDRR), secret)
526 The HDRR is defined in Section 3. It contains one or more locators
527 that the peer wants to publish, a sequence number, the peer's Host
528 Identity, an optional certificate, and signature over the contents.
530 The HIT_KEY is the last 100 bits of the HIT appended with 60 zero
531 bits. This is the portion of the HIT used as a DHT key. The last
532 100 bits is used to avoid uneven distribution of the stored values
533 across the DHT servers. The first 28 bits is the HIT's ORCHID Prefix
534 defined by [RFC4843], and this prefix is dropped because it is the
535 same for all HITs, which would cause this uneven distribution. Zero
536 padding is appended to this 100-bit value to fill the length required
537 by the DHT, 160 bits total.
539 Address publish
541 +----------------+----------------------------------------+---------+
542 | field | value | data |
543 | | | type |
544 +----------------+----------------------------------------+---------+
545 | application | "hip-addr" | string |
546 | | | |
547 | client_library | (implementation dependent) | string |
548 | | | |
549 | key | HIT_KEY | base64 |
550 | | | encoded |
551 | | | |
552 | value | HDRR(LOCATOR, SEQ, HOST_ID, [CERT], | base64 |
553 | | HIP_SIG), with the IP address to be | encoded |
554 | | published contained in the LOCATOR TLV | |
555 | | in the HDRR, along with other | |
556 | | validation data | |
557 | | | |
558 | ttl_sec | amount of time HDRR should be valid, | numeric |
559 | | or the lifetime of the preferred | string |
560 | | address, a value from 0-604800 seconds | |
561 | | | |
562 | secret_hash | optional SHA-1 hash of secret value | base64 |
563 | | | encoded |
564 +----------------+----------------------------------------+---------+
565 Address lookup
567 +----------------+---------------------------------+----------------+
568 | field | value | data type |
569 +----------------+---------------------------------+----------------+
570 | application | "hip-addr" | string |
571 | | | |
572 | client_library | (implementation dependent) | string |
573 | | | |
574 | key | HIT_KEY | base64 encoded |
575 | | | |
576 | maxvals | (implementation dependent) | numeric string |
577 | | | |
578 | placemark | (NULL, or used from server | base64 encoded |
579 | | reply) | |
580 +----------------+---------------------------------+----------------+
582 Address remove (optional)
584 +----------------+-------------------------------------+------------+
585 | field | value | data type |
586 +----------------+-------------------------------------+------------+
587 | application | "hip-addr" | string |
588 | | | |
589 | client_library | (implementation dependent) | string |
590 | | | |
591 | key | HIT_KEY | base64 |
592 | | | encoded |
593 | | | |
594 | value_hash | SHA-1 hash of HDRR (value used | base64 |
595 | | during publish) to remove | encoded |
596 | | | |
597 | ttl_sec | old address lifetime | numeric |
598 | | | string |
599 | | | |
600 | secret | secret value (SHA-1 of this was | base64 |
601 | | used in put) | encoded |
602 +----------------+-------------------------------------+------------+
604 The application and client_library fields are used for logging in
605 OpenDHT. The client_library may vary between different
606 implementations, specifying the name of the XML-RPC library used or
607 the application that directly makes XML-RPC calls.
609 The key used with the address lookup and with publishing the address
610 is the HIT_KEY as defined above, 160 bits base64 encoded [RFC2045].
611 The value used in the publish and lookup response is the base64
612 encoded HDRR containing one or more LOCATORs.
614 The ttl_sec field used with address publish indicates the time-to-
615 live. This is the number of seconds for which the entry will be
616 stored by the DHT. The time-to-live SHOULD be set to the number of
617 seconds remaining in the address lifetime.
619 The secret_hash is an optional field that MAY be used with address
620 publish if the value will later be removed with an rm operation. The
621 secret_hash contains the base64 encoded SHA-1 hash of some secret
622 value that MUST be known only to the publishing host. Clients SHOULD
623 include the secret_hash and remove outdated values to reduce the
624 amount of data the peer needs to handle. A different secret value
625 SHOULD be used for each put because rm requests are visible on the
626 network.
628 The max_vals and placemark fields used with address lookup are
629 defined by the get XML-RPC interface. The get operation needs to
630 know the maximum number of values to retrieve. The placemark is a
631 value found in the server reply that causes the get to continue to
632 retrieve values starting at where it left off.
634 5. Use cases
636 Below are some suggestions of when a HIP implementation MAY want to
637 use the HIT and address lookup services.
639 To learn of a peer's HIT, a host might first consult DNS using the
640 peer's hostname if the DNS server supports the HIP Resource Record
641 defined by [RFC5205]. Sometimes hosts do not have administrative
642 authority over their DNS entries and/or the DNS server is not able to
643 support HIP resource records. Hosts may want to associate other non-
644 DNS names with their HITs. For these and other reasons, a host MAY
645 use the HIT publish service defined in Section 4.1. The peer HIT may
646 be learned by performing a DHT lookup of such a name.
648 Once a peer HIT is learned or configured, an address lookup MAY be
649 performed so that the LOCATORs can be cached and immediately
650 available for when an association is requested. Implementations
651 might load a list of peer HITs on startup, resulting in several
652 lookups that can take some time to complete.
654 However, cached LOCATORs may quickly become obsolete, depending on
655 how often the peer changes its preferred address. Performing an
656 address lookup before sending the I1 may be needed. At this time the
657 latency of a lookup may be intolerable, and a lookup could instead be
658 performed after the I1 retransmission timer fires -- when no R1 reply
659 has been received -- to detect any change in address.
661 A HIP host SHOULD publish its preferred LOCATORs upon startup, so
662 other hosts may determine where it is reachable. The host SHOULD
663 periodically refresh its HDRR entry because each entry carries a TTL
664 and will eventually expire. Also, when there is a change in
665 preferred address, usually associated with sending UPDATE packets
666 with included locator parameters, the host SHOULD update its HDRR
667 with the DHT. The old HDRR SHOULD be removed using the rm operation,
668 if a secret value was used in the put.
670 Addresses from the private address space SHOULD NOT be published to
671 the DHT. If the host is located behind a NAT, for example, the host
672 could publish the address of its Rendezvous Server (RVS, from
673 [RFC5204]) to the DHT if that is how it is reachable. In this case
674 however, a peer could instead simply use the RVS field of the NATted
675 host's HIP DNS record, which would eliminate a separate DHT lookup.
677 A HIP host SHOULD also publish its HIT upon startup or whenever a new
678 HIT is configured, for use with the HIT lookup service, if desired.
679 The host SHOULD first check if the name already exists in the DHT by
680 performing a lookup, to avoid interfering with an existing name-to-
681 HIT mapping. The name-to-HIT binding needs to be refreshed
682 periodically before the TTL expires.
684 When publishing data to the DHT server, care should be taken to check
685 the response from the server. The server may respond with an "over
686 capacity" code, indicating that its resources are too burdened to
687 honor the given size and TTL. The host SHOULD then select another
688 server for publishing, or reduce the TTL and retry the put operation.
690 6. Issues with DHT support
692 The DHT put operation does not replace existing values. If a host
693 does not remove its old HDRR before adding another, several entries
694 may be present. A client performing a lookup SHOULD determine the
695 most recent address based on the Update ID from the SEQ TLV of the
696 HDRR. The order of values returned in the server's response may not
697 be guaranteed. Before performing each put a host SHOULD remove its
698 old HDRR data using the rm operation.
700 In the case of the HIT lookup service, there is nothing preventing
701 different hosts from publishing the same name. A lookup performed on
702 this name will return multiple HITs that belong to different devices.
703 The server may enforce a policy that requires clients to include a
704 certificate when publishing a HIT, and only store HITs with a name
705 that has been authorized by some trusted certificate. Otherwise this
706 is an unmanaged free-for-all service, and it is RECOMMENDED that a
707 host simply pick another name.
709 Selecting an appropriate DHT server to use is not covered here. If a
710 particular server becomes unavailable, the connect will timeout and
711 some server selection algorithm SHOULD be performed, such as trying
712 the next server in a configured list. OpenDHT formerly provided a
713 DNS-based anycast service, when one performed a lookup of
714 "opendht.nyuld.net", it returned the two nearest OpenDHT servers.
716 The latency involved with the DHT put and get operations should be
717 considered when using these services with HIP. The calls rely on
718 servers that may be located across the Internet, and may trigger
719 communications between servers that add delay. The DHT operations
720 themselves may be slow to produce a response.
722 The maximum size of 1024 bytes for the value field will limit the
723 maximum size of the Host Identity and certificates that may be used
724 within the HDRR.
726 7. Security Considerations
728 There are two classes of attacks on this information exchange between
729 host and DHT server: attacks on the validity of the information
730 provided by the DHT to the host (such as a spoofed DHT response) and
731 attacks on the DHT records themselves (such as polluted records for a
732 given key). Without the server performing some measure of
733 verification, not much can be done to prevent these attacks.
735 For the HIT lookup based on name (Section 4.1), there are no
736 guarantees on the validity of the HIT. Users concerned with the
737 validity of HITs found in the DHT SHOULD simply exchange HITs out-of-
738 band with peers. Including a signature will not help here because
739 the HIT that identifies the Host Identity for signing is not known
740 ahead of time. A certificate MAY be included with the HIT which
741 guarantees that the name used for the lookup has been authorized by
742 some 3rd party authority. Which certificates are considered trusted
743 is a local policy issue.
745 For the address lookup based on HIT (Section 4.2), the validity of
746 the DHT response MUST be checked with the HOST_ID and SIGNATURE
747 parameters in the HDRR. A HIP initiating host SHOULD also validate
748 the DHT response after the R1 message is received during a HIP
749 exchange. The Host Identity provided in the R1 can be hashed to
750 obtain a HIT that MUST be checked against the original HIT. However,
751 a legacy OpenDHT service without server modifications does not
752 prevent an attacker from polluting the DHT records for a known HIT,
753 thereby causing a denial-of-service attack, since server validation
754 is not performed.
756 Relying solely on client validation may be harmful. An attacker can
757 replay the put packets containing the signed HDRR, possibly causing
758 stale or invalid information to exist in the DHT. If an attacker
759 replays the signed put message and changes some aspect each time, and
760 if the server is not performing signature and HIT validation, there
761 could be a multitude of invalid entries stored in the DHT. When a
762 client retrieves these records it would need to perform signature and
763 HIT verification on each one, which could cause unacceptable amounts
764 of delay or computation.
766 To protect against this type of attack, the DHT server SHOULD perform
767 signature and HIT verification of each put operation as described in
768 Section 3. Another option would be the server running HIP itself and
769 requiring client authentication with a HIP association before
770 accepting HDRR puts. Further validation would be only accepting HIT
771 and address records from the association bound to the same HIT.
773 Performing server-side verification adds to the processing burden of
774 the DHT server and may be a source for a denial-of-service attack.
775 Requiring a HIP association before accepting HDRR puts may help here.
776 The HIT verification is less computationally-intensive by design,
777 using a hash algorithm. Certificate validation (for name lookups)
778 and signature verification (for HDRRs) may cause unacceptable amounts
779 of computation. A server may rate limit the number of puts that it
780 allows.
782 The SHA-1 message digest algorithm is used in two ways in this
783 document, and the security of using this algorithm should be
784 considered within the context of [RFC6194]. The first use is with
785 the OpenDHT put and remove operations, described in Section 2, and
786 the second is to reduce the size of the name string for the HIT
787 lookup service in Section 4.1.
789 The first use is intended to protect the secret values used to store
790 records in the DHT as described by the OpenDHT interface. An
791 attacker would be able to remove a record, after capturing the
792 plaintext put, if a secret value could be found that produces the
793 same secret hash. The purpose of this document is to maintain
794 interoperable compatibility with that interface, which prescribes the
795 use of SHA-1. Future revisions of that interface should consider
796 hash algorithm agility. The OpenDHT FAQ states that future support
797 for other hash algorithms is planned.
799 The second use of the SHA-1 algorithm is to reduce the arbitrarily-
800 sized name strings to fit the fixed OpenDHT key size. No security
801 properties of the SHA-1 algorithm are used in this context.
803 8. IANA Considerations
805 This document defines a new HIP Packet Type, the HIP Distributed Hash
806 Table Resource Record (HDRR). This packet type is defined in
807 Section 3 with a value of 20.
809 9. Acknowledgments
811 Thanks to Tom Henderson, Samu Varjonen, Andrei Gurtov, Miika Komu,
812 Kristian Slavov, Ken Rimey, Ari Keranen, and Martin Stiemerling for
813 providing comments. Samu most notably contributed the resolver
814 packet and its suggested parameters, which became the HDRR here.
816 10. References
818 10.1. Normative References
820 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
821 Extensions (MIME) Part One: Format of Internet Message
822 Bodies", RFC 2045, November 1996.
824 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
825 for Overlay Routable Cryptographic Hash Identifiers
826 (ORCHID)", RFC 4843, April 2007.
828 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
829 "Host Identity Protocol", RFC 5201, April 2008.
831 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
832 (HIP) Domain Name System (DNS) Extensions", RFC 5205,
833 April 2008.
835 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
836 Considerations for the SHA-0 and SHA-1 Message-Digest
837 Algorithms", RFC 6194, March 2011.
839 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
840 Certificates", RFC 6253, May 2011.
842 [opendht] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J.,
843 Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu,
844 "OpenDHT: A Public DHT Service and Its Uses", Proceedings
845 of ACM SIGCOMM 2005, August 2005.
847 10.2. Informative References
849 [I-D.ponomarev-hip-hit2ip]
850 Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags
851 Data in DNS", draft-ponomarev-hip-hit2ip-04 (work in
852 progress), July 2009.
854 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
855 Rendezvous Extension", RFC 5204, April 2008.
857 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
858 Host Mobility and Multihoming with the Host Identity
859 Protocol", RFC 5206, April 2008.
861 Appendix A. Change Log (to be removed by RFC Editor before publication)
863 A.1. Changes from hiprg 04 to 05
865 Revised based on Gen-ART review. Various grammatical updates.
866 Included text in the Security Considerations section referring to RFC
867 6194 and the use of SHA-1 with OpenDHT.
869 A.2. Changes from hiprg 03 to 04
871 Revised based on IRSG review. Swapped sections 3 and 4, moving HDRR
872 introductory text to section 3. Added text on frequency of lookups,
873 server side denial of service, and other suggestions.
875 A.3. Changes from hiprg 02 to 03
877 Organized references into normative and informative. Updated text on
878 RG consensus.
880 A.4. Changes from hiprg 01 to 02
882 Added RFC 2119 terminology phrase in the introduction, and
883 incorporated RFC 2119 keywords throughout the text. Added
884 clarification for the first occurrence of HIP parameter
885 abbreviations. Changed intended status from Informational to
886 Experimental.
888 A.5. Changes from hiprg 00 to 01
890 Incorporated comments from Ari Keranen: added references to CERT
891 draft and RFC 5204. Added clarifications from OpenDHT user's guide.
892 Simplified description of HIT_KEY. Dropped RFC 2119 language. Added
893 IANA considerations. Other minor corrections and clarifications.
895 A.6. Changes from Version ahrenholz 06 to hiprg 00
897 Document name changed to reflect acceptance as a HIPRG document.
898 Text added to introduction about document acceptance.
900 A.7. Changes from Version 05 to 06
902 Use the HDRR format as return values for both services. Added
903 optional certificates for both services. Added text about HIP-aware
904 DHT server that validates HITs/signatures. Added SEQ TLV to HDRR,
905 removed text about ordering. Relaxed statement about DNS and
906 referenced draft-ponomarev-hip-hit2ip. Added text describing why
907 HDRR is different than DNS RR. Added text about handling of source/
908 destination HITs in HDRR. Renamed Section 5 to "Use cases". Added
909 failure code for put. Removed text about servers not honoring TTL.
910 Added text clarifying what OpenLookup is.
912 A.8. Changes from Version 04 to 05
914 Reordered Sections 3.2 and 3.1, since the HIT lookup normally occurs
915 before the address lookup. Added text about why two separate lookups
916 are defined. Added text pertaining to the OpenDHT service retiring.
918 A.9. Changes from Version 03 to 04
920 Revised text about server treatment of TTL.
922 A.10. Changes from Version 02 to 03
924 Added text about TTL expiration, appending zero padding, HIT value
925 usage. Removed text on anonymous bit. Use RFC references.
927 A.11. Changes from Version 01 to 02
929 sockaddr address format changed to use HIP DHT Resource Record
930 containing the HIP LOCATOR format. The HIT prefix is dropped before
931 using it as a key. Separate "secure" service was dropped, and
932 signatures made mandatory. Legacy versus hip-aware DHT servers are
933 distinguished. Text packet examples added.
935 A.12. Changes from Version 00 to 01
937 Removed the HIT lookup service -- using the LSI as a key to return a
938 HIT as the value -- and added a HIT lookup service using names.
940 Added support for OpenDHT remove. Changed all occurrences of "Open
941 DHT" to "OpenDHT".
943 Added the Host Identity and a signature as a secure address lookup
944 service, with text about running a modified OpenDHT server that can
945 verify signed put messages based on Host Identity signatures.
947 Author's Address
949 Jeff Ahrenholz
950 The Boeing Company
951 P.O. Box 3707
952 Seattle, WA
953 USA
955 Email: jeffrey.m.ahrenholz@boeing.com