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