idnits 2.17.1 draft-ahrenholz-hiprg-dht-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 499: '...hing host. Clients SHOULD include the...' RFC 2119 keyword, line 541: '...'s HIT, DST HIT) MUST be NULL (all zer...' RFC 2119 keyword, line 570: '..._SIGNATURE parameter MUST be used with...' RFC 2119 keyword, line 575: '...DRR from the DHT response MUST perform...' RFC 2119 keyword, line 579: '... MUST be ignored. Note that for cli...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2009) is 5281 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERT' is mentioned on line 534, 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 5206 (Obsoleted by RFC 8046) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF HIP Research Group J. Ahrenholz 3 Internet-Draft The Boeing Company 4 Intended status: Informational November 9, 2009 5 Expires: May 13, 2010 7 HIP DHT Interface 8 draft-ahrenholz-hiprg-dht-06 10 Abstract 12 This document specifies a common interface for using HIP with a 13 Distributed Hash Table service to provide a name-to-HIT lookup 14 service and a HIT-to-address lookup service. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 13, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. The OpenDHT interface . . . . . . . . . . . . . . . . . . . . 4 70 3. HIP lookup services . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. HIP name to HIT lookup . . . . . . . . . . . . . . . . . . 8 72 3.2. HIP address lookup . . . . . . . . . . . . . . . . . . . . 10 73 4. HDRR - the HIP DHT Resource Record . . . . . . . . . . . . . . 14 74 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6. Issues with DHT support . . . . . . . . . . . . . . . . . . . 18 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 81 A.1. Changes from Version 05 to 06 . . . . . . . . . . . . . . 23 82 A.2. Changes from Version 04 to 05 . . . . . . . . . . . . . . 23 83 A.3. Changes from Version 03 to 04 . . . . . . . . . . . . . . 23 84 A.4. Changes from Version 02 to 03 . . . . . . . . . . . . . . 23 85 A.5. Changes from Version 01 to 02 . . . . . . . . . . . . . . 23 86 A.6. Changes from Version 00 to 01 . . . . . . . . . . . . . . 23 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 The Host Identity Protocol [RFC5201] may benefit from a lookup 92 service based on Distributed Hash Tables (DHTs). The Host Identity 93 namespace is flat, consisting of public keys, in contrast to the 94 hierarchical Domain Name System. These keys are hashed and prefixed 95 to form Host Identity Tags (HITs) which appear as large random 96 numbers. As the current DNS system has been heavily optimized for 97 address lookup, it may be worthwhile to experiment with other 98 services such as those defined here. DHTs manage such data well by 99 applying a hash function that distributes data across a number of 100 servers. DHTs are also designed to support frequently updating 101 stored values. For an alternative method of using HITs to lookup IP 102 addresses using DNS, see [I-D.ponomarev-hip-hit2ip]. 104 One freely available implementation of a DHT is the Bamboo DHT, which 105 is Java-based software that has been deployed on PlanetLab servers to 106 form a free service named OpenDHT. OpenDHT was available via the 107 Internet for any program to store and retrieve arbitrary data. 108 OpenDHT used a well defined XML-RPC interface, featuring put, get, 109 and remove operations. OpenLookup, while not implemented as a DHT, 110 is another deployment of open source software compatible with this 111 OpenDHT interface. This document discusses a common way for HIP to 112 use this OpenDHT interface, so that various HIP experimenters may 113 employ lookup services in an interoperable fashion. 115 2. The OpenDHT interface 117 OpenDHT was a public deployment of Bamboo DHT servers that ran on 118 about 150 PlanetLab nodes, retired in July 2009. While the Bamboo 119 project provides the actual software running on the servers, here we 120 will refer only to OpenDHT, which uses a certain defined interface 121 for the XML-RPC calls. Another service compatible with this 122 interface is OpenLookup. One can run their own Bamboo nodes to set 123 up a private ring of servers. 125 OpenDHT was chosen because it was a well-known, publicly available 126 DHT used within the research community. Its interface features a 127 simple, standards-based protocol that can be easily implemented by 128 HIP developers. This document does not aim to dictate that only the 129 services and servers described here should be used, but is rather 130 meant to act as a starting point to gain experience with these 131 services, choosing tools that are readily available. 133 OpenDHT stores values using (hash) keys. Keys are limited to 20 134 bytes in length, and values can be up to 1024 bytes. Values are 135 stored for a certain number of seconds, up to a maximum of 604,800 136 seconds (one week.) See the OpenDHT website: 137 139 Three RPC operations are supported: put, get, and rm (remove). Put 140 is called with key and value parameters, causing the value to be 141 stored using the key as its hash index. Get is called with the key 142 parameter, when you have a key and want to retrieve the value. Rm is 143 called with a hash of the value to be removed along with a secret 144 value, a hash of which was included in the put operation. 146 The definitions below are taken from 147 . 149 The put operation takes the following arguments: 151 +----------------+--------------------------------------+ 152 | field | type | 153 +----------------+--------------------------------------+ 154 | application | string | 155 | | | 156 | client_library | string | 157 | | | 158 | key | byte array, 20 bytes max. | 159 | | | 160 | value | byte array, 1024 bytes max. | 161 | | | 162 | ttl_sec | four-byte integer, max. value 604800 | 163 | | | 164 | secret_hash | optional SHA-1 hash of secret value | 165 +----------------+--------------------------------------+ 167 The server replies with an integer -- 0 for "success", 1 if it is 168 "over capacity", and 2 indicating "try again". The return code 3 169 indicates "failure" and is used for a modified OpenDHT server that 170 performs signature and HIT verification. 172 The get operation takes the following arguments: 174 +----------------+---------------------------------------------+ 175 | field | type | 176 +----------------+---------------------------------------------+ 177 | application | string | 178 | | | 179 | client_library | string | 180 | | | 181 | key | byte array, 20 bytes max. | 182 | | | 183 | maxvals | four-byte singed integer, max. value 2^31-1 | 184 | | | 185 | placemark | byte array, 100 bytes max. | 186 +----------------+---------------------------------------------+ 188 The server replies with an array of values, and a placemark that can 189 be used for fetching additional values. 191 The rm operation takes the following arguments: 193 +----------------+----------------------------------------------+ 194 | field | type | 195 +----------------+----------------------------------------------+ 196 | application | string | 197 | | | 198 | client_library | string | 199 | | | 200 | key | byte array, 20 bytes max. | 201 | | | 202 | value_hash | SHA-1 hash of value to remove | 203 | | | 204 | ttl_sec | four-byte integer, max. value 604800 | 205 | | | 206 | secret | secret value (SHA-1 of this was used in put) | 207 +----------------+----------------------------------------------+ 209 The server replies with an integer -- 0 for "success", 1 if it is 210 "over capacity", and 2 indicating "try again". 212 This is the basic XML-RPC interface provided by OpenDHT. Each 213 "field" from the above tables are XML tags that enclose their 214 corresponding values. Below, specific uses for HIP are suggested, 215 along with values that can be used inside the fields shown above. 217 3. HIP lookup services 219 This draft defines a HIT lookup and address lookup service for use 220 with HIP. The HIT lookup uses a text name to discover a peer's HIT. 221 The address lookup uses a peer's HIT to discover its current 222 addresses. 224 The two lookups are defined below: 226 HDRR([CERT]) = get(SHA-1("name")) 227 HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY) 229 Both services use a HIP DHT Resource Record (HDRR) described in 230 Section 4. This is a wrapper around data contained in TLVs, similar 231 to a HIP control packet. The data contained in each HDRR differs 232 between the two services. 234 The HIT lookup service returns the Host Identity Tag of a peer given 235 a name. The name could be the FQDN, hostname, or some other alias. 236 This HIT is found in the Sender's HIT field of the HDRR. The HIT is 237 the hash of the public-key based Host Identity as described in 238 [RFC5201]. There are no security properties of the name, unlike the 239 HIT. An optional certificate may be included in the record, for 240 validating the name, providing some measure of security. Which 241 certificates to consider trusted is a policy issue. This service is 242 intended for use when legacy DNS servers do not support HIP resource 243 records, or when hosts do not have administrative access to publish 244 their own DNS records. Such an unmanaged naming service may help 245 facilitate experimentation. 247 The address lookup returns a locator and other validation data in the 248 HDRR for a given HIT. Before a HIP association can be initiated (not 249 in opportunistic mode), a HIP host needs to know the peer's HIT and 250 the current address at which the peer is reachable. Often the HIT 251 will be pre-configured, available via DNS lookup using a hostname 252 lookup [RFC5205], or retrieved using the HIT lookup service defined 253 in this document. With HIP mobility [RFC5206], IP addresses may be 254 used as locators and may often change. The Host Identity and the HIT 255 remain relatively constant and can be used to securely identify a 256 host, so the HIT serves as a suitable DHT key for storing and 257 retrieving addresses. 259 The address lookup service includes the peer's Host Identity and a 260 signature over the locators. This allows the DHT client or server to 261 validate the address information stored in the DHT. 263 These two separate lookups are defined instead of one because the 264 address record is expected to change more frequently, while the name- 265 to-HIT binding should remain relatively constant. Also the client 266 and server validation of the two records is different, with the HIT 267 lookup using certificates verifying the name and the address lookup 268 using a signature produced by the bearer of a particular Host 269 Identity/HIT. 271 These services reduce the amount of pre-configuration required at 272 each HIP host. The address of each peer no longer needs to be known 273 ahead of time, if peers also participate by publishing their 274 addresses. If peers choose to publish their HITs with a name, peer 275 HITs also no longer require pre-configuration. However, discovering 276 an available DHT server for servicing these lookups will require some 277 additional configuration. 279 3.1. HIP name to HIT lookup 281 Given the SHA-1 hash of a name, a lookup returns the HIT of the peer. 282 The hash of a name is used because OpenDHT keys are limited to 20 283 bytes, so this allows for longer names. Publish, lookup, and remove 284 operations are defined. 286 HDRR([CERT]) = get(SHA-1("name")) 287 put(SHA-1("name", HDRR([CERT]), [SHA-1(secret)]) 288 rm(SHA-1("name", SHA-1(HDRR), secret) 290 HIT publish 292 +----------------+----------------------------------------+---------+ 293 | field | value | data | 294 | | | type | 295 +----------------+----------------------------------------+---------+ 296 | application | "hip-name-hit" | string | 297 | | | | 298 | client_library | (implementation dependent) | string | 299 | | | | 300 | key | SHA-1 hash of a name | base64 | 301 | | | encoded | 302 | | | | 303 | value | HDRR([CERT]), with the HIT to be | base64 | 304 | | published contained in the Sender's | encoded | 305 | | HIT field of the HDRR, and an optional | | 306 | | certificate for validating the name | | 307 | | used as the key | | 308 | | | | 309 | ttl_sec | lifetime for this record, value from | numeric | 310 | | 0-604800 seconds | string | 311 | | | | 312 | secret_hash | optional SHA-1 hash of secret value | base64 | 313 | | | encoded | 314 +----------------+----------------------------------------+---------+ 316 HIT lookup 318 +----------------+---------------------------------+----------------+ 319 | field | value | data type | 320 +----------------+---------------------------------+----------------+ 321 | application | "hip-name-hit" | string | 322 | | | | 323 | client_library | (implementation dependent) | string | 324 | | | | 325 | key | SHA-1 hash of a name | base64 encoded | 326 | | | | 327 | maxvals | (implementation dependent) | numeric string | 328 | | | | 329 | placemark | (NULL, or used from server | base64 encoded | 330 | | reply) | | 331 +----------------+---------------------------------+----------------+ 333 HIT remove (optional) 335 +----------------+----------------------------------------+---------+ 336 | field | value | data | 337 | | | type | 338 +----------------+----------------------------------------+---------+ 339 | application | "hip-name-hit" | string | 340 | | | | 341 | client_library | (implementation dependent) | string | 342 | | | | 343 | key | SHA-1 hash of a name | base64 | 344 | | | encoded | 345 | | | | 346 | value_hash | SHA-1 hash of HDRR (value used during | base64 | 347 | | publish) to remove | encoded | 348 | | | | 349 | ttl_sec | lifetime for the remove should be | numeric | 350 | | greater than or equal to the amount of | string | 351 | | time remaining for the record | | 352 | | | | 353 | secret | secret value (SHA-1 of this was used | base64 | 354 | | in put) | encoded | 355 +----------------+----------------------------------------+---------+ 357 The key for both HIT publish and lookup is the SHA-1 hash of the 358 name. The name does not necessarily need to be associated with a 359 valid DNS or host name. It does not need to be related to the Domain 360 Identifier found in HI TLV. OpenDHT limits the keys to 20 bytes in 361 length, so the SHA-1 hash is used to allow arbitrary name lengths. 363 The value used in the publish and lookup response is the base64- 364 encoded HDRR containing the HIT, and an optional certificate. The 365 HIT is stored in the Sender's HIT field in the HDRR header, and is a 366 128-bit value than can be identified as a HIT both by its length and 367 by the ORCHID prefix ([RFC4843]) that it starts with. 369 If a certificate is included in this HIT record, the name used for 370 the DHT key should be listed in the certificate. The server can hash 371 this name to verify it matches the DHT key. 373 The ttl_sec field specifies the number of seconds requested by the 374 client that the entry should be stored by the DHT server, which is 375 implementation dependent. 377 The secret_hash is an optional field used with HIT publish if the 378 value will later be removed with an rm operation. It is recommended 379 that clients support these rm operations for the values they publish. 380 The secret_hash contains the base64 encoded SHA-1 hash of some secret 381 value known only to the publishing host. A different secret value 382 should be used for each put because rm requests are visible on the 383 network. The max_vals and placemark fields used with the HIT lookup 384 are defined by the get XML-RPC interface. 386 3.2. HIP address lookup 388 Given a HIT, a lookup returns the IP address of the peer. The 389 address is contained in a LOCATOR TLV inside the HDRR, along with 390 other validation data. This interface has publish, lookup, and 391 remove operations. 393 HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY) 394 put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG), 395 [SHA-1(secret)]) 396 rm(HIT_KEY, SHA-1(HDRR), secret) 398 The HDRR is defined in Section 4. It contains one or more locators 399 that the peer wants to publish, a sequence number, the peer's Host 400 Identity, an optional certificate, and signature over the contents. 402 The HIT_KEY is a portion of the HIT used as a DHT key. [RFC4843] 403 defines the HIT as a Prefix concatenated with 100 bits of hash: 405 Input := any bitstring 406 Hash Input := Context ID | Input 407 Hash := Hash_function( Hash Input ) 408 ORCHID := Prefix | Encode_100( Hash ) 410 The HIT_KEY is the Encode_100( Hash ) portion of the above 411 definition. Zero padding is appended to this 100-bit value to fill 412 the length required by the DHT, 160 bits total. The HIT's ORCHID 413 Prefix is dropped because this would cause uneven distribution of the 414 stored values across the DHT servers. 416 Address publish 418 +----------------+----------------------------------------+---------+ 419 | field | value | data | 420 | | | type | 421 +----------------+----------------------------------------+---------+ 422 | application | "hip-addr" | string | 423 | | | | 424 | client_library | (implementation dependent) | string | 425 | | | | 426 | key | 100-bit HIT_KEY | base64 | 427 | | | encoded | 428 | | | | 429 | value | HDRR(LOCATOR, SEQ, HOST_ID, [CERT], | base64 | 430 | | HIP_SIG), with the IP address to be | encoded | 431 | | pusblished contained in the LOCATOR | | 432 | | TLV in the HDRR, along with other | | 433 | | validation data | | 434 | | | | 435 | ttl_sec | amount of time HDRR should be valid, | numeric | 436 | | or the lifetime of the preferred | string | 437 | | address, a value from 0-604800 seconds | | 438 | | | | 439 | secret_hash | optional SHA-1 hash of secret value | base64 | 440 | | | encoded | 441 +----------------+----------------------------------------+---------+ 442 Address lookup 444 +----------------+---------------------------------+----------------+ 445 | field | value | data type | 446 +----------------+---------------------------------+----------------+ 447 | application | "hip-addr" | string | 448 | | | | 449 | client_library | (implementation dependent) | string | 450 | | | | 451 | key | 100-bit HIT_KEY | base64 encoded | 452 | | | | 453 | maxvals | (implementation dependent) | numeric string | 454 | | | | 455 | placemark | (NULL, or used from server | base64 encoded | 456 | | reply) | | 457 +----------------+---------------------------------+----------------+ 459 Address remove (optional) 461 +----------------+-------------------------------------+------------+ 462 | field | value | data type | 463 +----------------+-------------------------------------+------------+ 464 | application | "hip-addr" | string | 465 | | | | 466 | client_library | (implementation dependent) | string | 467 | | | | 468 | key | 100-bit HIT_KEY | base64 | 469 | | | encoded | 470 | | | | 471 | value_hash | SHA-1 hash of HDRR (value used | base64 | 472 | | during publish) to remove | encoded | 473 | | | | 474 | ttl_sec | old address lifetime | numeric | 475 | | | string | 476 | | | | 477 | secret | secret value (SHA-1 of this was | base64 | 478 | | used in put) | encoded | 479 +----------------+-------------------------------------+------------+ 481 The application and client_library fields are used for logging in 482 OpenDHT. The client_library may vary between different 483 implementations, specifying the name of the XML-RPC library used or 484 the application that directly makes XML-RPC calls. 486 The key for both address publish and lookup is the 100-bits of the 487 HIT_KEY as defined above, plus 60-bits of zero padding, base64 488 encoded [RFC2045]. The value used in the publish and lookup response 489 is the base64 encoded HDRR containing one or more LOCATORs. 491 The ttl_sec field used with address publish includes the time-to- 492 live, the number of seconds for which the entry will be stored by the 493 DHT, which is set to the number of seconds remaining in the address 494 lifetime. 496 The secret_hash is an optional field used with address publish, used 497 if the value will later be removed with an rm operation. The 498 secret_hash contains the base64 encoded SHA-1 hash of some secret 499 value known only to the publishing host. Clients SHOULD include the 500 secret_hash and remove outdated values to reduce the amount of data 501 the peer needs to handle. A different secret value should be used 502 for each put because rm requests are visible on the network. 504 The max_vals and placemark fields used with address lookup are 505 defined by the get XML-RPC interface. The get operation needs to 506 know the maximum number of values to retrieve. The placemark is a 507 value found in the server reply that causes the get to continue to 508 retrieve values starting at where it left off. 510 4. HDRR - the HIP DHT Resource Record 512 The HIP DHT Resource Record uses the same binary format as HIP 513 packets (defined in [RFC5201].) This packet encoding is used as a 514 convenience, even though this data is actually a resource record 515 stored and retrieved by the DHT servers, not a packet sent on the 516 wire by a HIP protocol daemon. Note that this HDRR format is 517 different than the HIP RR used by the Domain Name System as defined 518 in [RFC5205]. The reason it is different is that it is a different 519 record from a functional point of view: in DNS, the query key is a 520 FQDN, and the return value is a HIT, while here, the query key is a 521 HIT. 523 HIP header values for the HDRR: 525 HIP Header: 526 Packet Type = 20 DHT Resource Record (this value is TBD) 527 SRC HIT = Sender's HIT 528 DST HIT = NULL 530 HDRR used with HIT lookup: 531 HIP ( [CERT] ) 533 HDRR used with address lookup: 534 HIP ( LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIGNATURE ) 536 The Initiator HIT (Sender's HIT, SRC HIT) is set to the HIT that the 537 host wishes to make available using the lookup service. With the HIT 538 lookup service, this is the main piece of information returned by a 539 get operation. For the address lookup service, this HIT is the same 540 one used to derive the HIT_KEY used as the DHT key. The Responder 541 HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes) since the 542 data is intended for any host. 544 The only other TLV used with the HIT lookup service is an optional 545 CERT parameter containing a certificate for validating the name that 546 is used as the DHT key. The DHT server can use the certificate to 547 verify that the client is authorized to use the name used for the DHT 548 key, using the hash of the name found in the certificate. Which 549 certificates the server considers trusted is a policy issue. 551 The remaining parameters described here are used with the address 552 lookup service. 554 The LOCATOR parameter contains the addresses that the host wishes to 555 make available using the lookup service. A host may publish its 556 current preferred IPv4 and IPv6 locators, for example. 558 The SEQ parameter contains an unsigned 32-bit sequence number, the 559 Update ID. This is typically initialized to zero and incremented by 560 one for each new HDRR that is published by the host. The host should 561 retain the last Update ID value it used for each HIT across reboots, 562 or perform a self lookup in the DHT, since that number may be 563 retained in the DHT records and will determine the preferred address 564 used by peers. 566 The HOST_ID parameter contains the Host Identity that corresponds 567 with the Sender's HIT. (The encoding of this parameter is defined in 568 section 5.2.8 of [RFC5201].) 570 The HOST_ID parameter and HIP_SIGNATURE parameter MUST be used with 571 the HDRR so that HIP clients receiving the record can validate the 572 sender and the included LOCATOR parameter. The HIT_KEY used for the 573 DHT key will also be verified against the Host Identity. 575 The client that receives the HDRR from the DHT response MUST perform 576 the signature and HIT_KEY verification. If the signature is invalid 577 for the given Host Identity or the HIT_KEY used to retrieve the 578 record does not match the Host Identity, the DHT record retrieved 579 MUST be ignored. Note that for client-only verification the DHT 580 server does not need to be modified 582 The Sender's HIT in the HDRR should correspond with the key used for 583 the lookup and Host Identity verfication. The Receiver's HIT should 584 be NULL (all zeroes) in the HDRR header. 586 When several HDRR records are returned by the server, the client 587 should pick the most recent record as indicated by the Update ID in 588 the SEQ TLV of the HDRR, and perform verification on that record. 589 The order in which records are returned should not be considered. 591 The DHT server can also verify the SIGNATURE and HOST_ID, with some 592 modifications to the Bamboo DHT software and a new return code with 593 the OpenDHT interface. The signature in the put needs to be verified 594 using the given Host Identity (public key), and the HIT_KEY provided 595 as the lookup key needs to match this Host Identity according to the 596 ORCHID generation method defined by [RFC4843]. If either signature 597 or HIT verification fails, the put is not recorded into the DHT, and 598 the server returns a failure code. The failure code is an additional 599 return code not defined by OpenDHT, with a value of 3. 601 5. Use cases 603 Below are some suggestions of when a HIP implementation may want to 604 use the HIT and address lookup services. 606 To learn of a peer's HIT, a host might first consult DNS using the 607 peer's hostname if the DNS server supports the HIP Resource Record 608 defined by [RFC5205]. Sometimes hosts do not have administrative 609 authority over their DNS entries and/or the DNS server is not able to 610 support HIP resource records. Hosts may want to associate other non- 611 DNS names with their HITs. For these and other reasons, a host may 612 use the HIT publish service defined in Section 3.1. The peer HIT may 613 be learned by performing a DHT lookup of such a name. 615 Once a peer HIT is learned or configured, an address lookup could be 616 performed so that the LOCATORs can be cached and immediately 617 available for when an association is requested. Implementations 618 might load a list of peer HITs on startup, resulting in several 619 lookups that can take some time to complete. 621 However, cached LOCATORs may quickly become obsolete, depending on 622 how often the peer changes its preferred address. Performing an 623 address lookup before sending the I1 may be needed. At this time the 624 latency of a lookup may be intolerable, and a lookup could instead be 625 performed after the I1 retransmission timer fires -- when no R1 reply 626 has been received -- to detect any change in address. 628 A HIP host should publish its preferred LOCATORs upon startup, so 629 other hosts may determine where it is reachable. The host needs to 630 periodically refresh its HDRR entry because each entry carries a TTL 631 and will eventually expire. Also, when there is a change in 632 preferred address, usually associated with sending UPDATE packets 633 with included locator parameters, the host should update its HDRR 634 with the DHT. The old HDRR should be removed using the rm operation, 635 if a secret value was used in the put. 637 Addresses from the private address space should not be published to 638 the DHT. If the host is located behind a NAT, for example, the host 639 could publish the address of its RVS to the DHT if that is how it is 640 reachable. In this case however, a peer could instead simply use the 641 RVS field of the NATted host's HIP DNS record, which would eliminate 642 a separate DHT lookup. 644 A HIP host should also publish its HIT upon startup or whenever a new 645 HIT is configured, for use with the HIT lookup service, if desired. 646 The host should first check if the name already exists in the DHT by 647 performing a lookup, to avoid interfering with an existing name-to- 648 HIT mapping. The name-to-HIT binding needs to be refreshed 649 periodically before the TTL expires. 651 When publishing data to the DHT server, care should be taken to check 652 the response from the server. The server may respond with an "over 653 capacity" code, indicating that its resources are too burdened to 654 honor the given size and TTL. The host should then select another 655 server for publishing, or reduce the TTL and retry the put operation. 657 6. Issues with DHT support 659 The DHT put operation does not replace existing values. If a host 660 does not remove its old HDRR before adding another, several entries 661 may be present. A client performing a lookup should determine the 662 most recent address based on the Update ID from the SEQ TLV of the 663 HDRR. The order of values returned in the server's response may not 664 be guaranteed. Before performing each put a host should remove its 665 old HDRR data using the rm operation. 667 In the case of the HIT lookup service, there is nothing preventing 668 different hosts from publishing the same name. A lookup performed on 669 this name will return multiple HITs that belong to different devices. 670 The server may enforce a policy that requires clients to include a 671 certificate when publishing a HIT, and only store HITs with a name 672 that has been authorized by some trusted certificate. Otherwise this 673 is an unmanaged free-for-all service, and it is recommended that a 674 host simply pick another name. 676 Selecting an appropriate DHT server to use is not covered here. If a 677 particular server becomes unavailable, the connect will timeout and 678 some server selection algorithm should be performed, such as trying 679 the next server in a configured list. OpenDHT formerly provided a 680 DNS-based anycast service, when you performed a lookup of 681 "opendht.nyuld.net", it returned the two nearest OpenDHT servers. 683 Because the put and get calls rely on outside servers located across 684 the Internet, operations may have a latency involved that should be 685 considered when using these services with HIP. 687 The maximum size of 1024 bytes for the value field will limit the 688 maximum size of the Host Identity and certificates that may be used 689 within the HDRR. 691 7. Security Considerations 693 There are two classes of attacks on this information exchange between 694 host and DHT server: attacks on the validity of the information 695 provided by the DHT to the host (such as a spoofed DHT response) and 696 attacks on the DHT records themselves (such as polluted records for a 697 given key). Without the server performing some measure of 698 verification, not much can be done to prevent these attacks. 700 For the HIT lookup based on name (Section 3.1), there are no 701 guarantees on the validity of the HIT. Users concerned with the 702 validity of HITs found in the DHT should simply exchange HITs out-of- 703 band with peers. Including a signature will not help here because 704 the HIT that identifies the Host Identity for signing is not known 705 ahead of time. A certificate may be included with the HIT which 706 guarantees that the name used for the lookup has been authorized by 707 some 3rd party authority. Which certificates are considered trusted 708 is a local policy issue. 710 For the address lookup based on HIT (Section 3.2), the validity of 711 the DHT response can be checked with the HOST_ID and SIGNATURE 712 parameters in the HDRR. A HIP initiating host can also validate the 713 DHT response after the R1 message is received during a HIP exchange. 714 The Host Identity provided in the R1 can be hashed to obtain a HIT 715 that can be checked against the original HIT. However, a legacy 716 OpenDHT service without server modifications does prevent an attacker 717 from polluting the DHT records for a known HIT, thereby causing a 718 denial-of-service attack, since server validation is not performed. 720 Relying solely on client validation may be harmful. An attacker can 721 replay the put packets containing the signed HDRR, possibly causing 722 stale or invalid information to exist in the DHT. If an attacker 723 replays the signed put message and changes some aspect each time, and 724 if the server is not performing signature and HIT validation, there 725 could be a multitude of invalid entries stored in the DHT. When a 726 client retrieves these records it would need to perform signature and 727 HIT verification on each one, which could cause unacceptable amounts 728 of delay or computation. 730 To protect against this type of attack, the DHT server should perform 731 signature and HIT verification of each put operation as described in 732 Section 4. Another option would be the server running HIP itself and 733 requiring client authentication with a HIP association before 734 accepting HDRR puts. Further validation would be only accepting HIT 735 and address records from the association bound to the same HIT. 737 8. IANA Considerations 739 This document has no actions for IANA. 741 9. Acknowledgments 743 Thanks to Tom Henderson, Samu Varjonen, Andrei Gurtov, Miika Komu, 744 Kristian Slavov, and Ken Rimey for providing comments. Samu most 745 notably contributed the resolver packet and its suggested parameters, 746 which became the HDRR here. 748 10. References 750 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 751 Extensions (MIME) Part One: Format of Internet Message 752 Bodies", RFC 2045, November 1996. 754 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 755 for Overlay Routable Cryptographic Hash Identifiers 756 (ORCHID)", RFC 4843, April 2007. 758 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 759 "Host Identity Protocol", RFC 5201, April 2008. 761 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 762 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 763 April 2008. 765 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 766 Host Mobility and Multihoming with the Host Identity 767 Protocol", RFC 5206, April 2008. 769 [I-D.ponomarev-hip-hit2ip] 770 Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags 771 Data in DNS", draft-ponomarev-hip-hit2ip-04 (work in 772 progress), July 2009. 774 Appendix A. Change Log 776 A.1. Changes from Version 05 to 06 778 Use the HDRR format as return values for both services. Added 779 optional certificates for both services. Added text about HIP-aware 780 DHT server that validates HITs/signatures. Added SEQ TLV to HDRR, 781 removed text about ordering. Relaxed statement about DNS and 782 referenced draft-ponomarev-hip-hit2ip. Added text describing why 783 HDRR is different than DNS RR. Added text about handling of source/ 784 destination HITs in HDRR. Renamed Section 5 to "Use cases". Added 785 failure code for put. Removed text about servers not honoring TTL. 786 Added text clarifying what OpenLookup is. 788 A.2. Changes from Version 04 to 05 790 Reordered Sections 3.2 and 3.1, since the HIT lookup normally occurs 791 before the address lookup. Added text about why two separate lookups 792 are defined. Added text pertaining to the OpenDHT service retiring. 794 A.3. Changes from Version 03 to 04 796 Revised text about server treatment of TTL. 798 A.4. Changes from Version 02 to 03 800 Added text about TTL expiration, appending zero padding, HIT value 801 usage. Removed text on anonymous bit. Use RFC references. 803 A.5. Changes from Version 01 to 02 805 sockaddr address format changed to use HIP DHT Resource Record 806 containing the HIP LOCATOR format. The HIT prefix is dropped before 807 using it as a key. Separate "secure" service was dropped, and 808 signatures made mandatory. Legacy versus hip-aware DHT servers are 809 distinguished. Text packet examples added. 811 A.6. Changes from Version 00 to 01 813 Removed the HIT lookup service -- using the LSI as a key to return a 814 HIT as the value -- and added a HIT lookup service using names. 816 Added support for OpenDHT remove. Changed all occurrences of "Open 817 DHT" to "OpenDHT". 819 Added the Host Identity and a signature as a secure address lookup 820 service, with text about running a modified OpenDHT server that can 821 verify signed put messages based on Host Identity signatures. 823 Author's Address 825 Jeff Ahrenholz 826 The Boeing Company 827 P.O. Box 3707 828 Seattle, WA 829 USA 831 Email: jeffrey.m.ahrenholz@boeing.com