idnits 2.17.1 draft-ietf-hip-dns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1046. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1052. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 682 has weird spacing: '...lic Key are...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 971, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 978, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1000, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (ref. '3') (Obsoleted by RFC 2535) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '7') ** Obsolete normative reference: RFC 3548 (ref. '8') (Obsoleted by RFC 4648) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '11') == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-02 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '12') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '13') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '14') -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '16') (Obsoleted by RFC 5226) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Nikander 3 Internet-Draft Ericsson Research Nomadic Lab 4 Expires: January 14, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 July 11, 2005 8 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 9 draft-ietf-hip-dns-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies two new resource records (RRs) for the Domain 43 Name System (DNS), and how to use them with the Host Identity 44 Protocol (HIP). These RRs allow a HIP node to store in the DNS its 45 Host Identity (HI, the public component of the node public-private 46 key pair), Host Identity Tag (HIT, a truncated hash of its public 47 key), and the Domain Name or IP addresses of its Rendezvous Servers 48 (RVS). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this document . . . . . . . . . . . . . . 6 54 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1 Simple static singly homed end-host . . . . . . . . . . . 8 56 3.2 Mobile end-host . . . . . . . . . . . . . . . . . . . . . 9 57 3.3 Mixed Scenario . . . . . . . . . . . . . . . . . . . . . . 10 58 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 12 59 4.1 Storing HI and HIT in DNS . . . . . . . . . . . . . . . . 12 60 4.1.1 Different types of HITs . . . . . . . . . . . . . . . 12 61 4.2 Storing Rendezvous Servers in the DNS . . . . . . . . . . 13 62 4.3 Initiating connections based on DNS names . . . . . . . . 13 63 5. Storage Format . . . . . . . . . . . . . . . . . . . . . . . . 14 64 5.1 HIPHI RDATA format . . . . . . . . . . . . . . . . . . . . 14 65 5.1.1 HIT type format . . . . . . . . . . . . . . . . . . . 14 66 5.1.2 HIT algorithm format . . . . . . . . . . . . . . . . . 14 67 5.1.3 PK algorithm format . . . . . . . . . . . . . . . . . 15 68 5.1.4 HIT format . . . . . . . . . . . . . . . . . . . . . . 15 69 5.1.5 Public key format . . . . . . . . . . . . . . . . . . 15 70 5.2 HIPRVS RDATA format . . . . . . . . . . . . . . . . . . . 16 71 5.2.1 Preference format . . . . . . . . . . . . . . . . . . 16 72 5.2.2 Rendezvous server type format . . . . . . . . . . . . 16 73 5.2.3 Rendezvous server format . . . . . . . . . . . . . . . 17 74 6. Presentation Format . . . . . . . . . . . . . . . . . . . . . 18 75 6.1 HIPHI Representation . . . . . . . . . . . . . . . . . . . 18 76 6.2 HIPRVS Representation . . . . . . . . . . . . . . . . . . 18 77 6.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 7. Retrieving Multiple HITs and IPs from the DNS . . . . . . . . 20 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 8.1 Attacker tampering with an unsecure HIPHI RR . . . . . . . 21 81 8.2 Attacker tampering with an unsecure HIPRVS RR . . . . . . 21 82 8.3 Opportunistic HIP . . . . . . . . . . . . . . . . . . . . 22 83 8.4 Unpublished Initiator HI . . . . . . . . . . . . . . . . . 22 84 8.5 Hash and HITs Collisions . . . . . . . . . . . . . . . . . 22 85 8.6 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 11.1 Normative references . . . . . . . . . . . . . . . . . . . 26 90 11.2 Informative references . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 92 Intellectual Property and Copyright Statements . . . . . . . . 28 94 1. Introduction 96 This document specifies two new resource records (RRs) for the Domain 97 Name System (DNS) [1], and how to use them with the Host Identity 98 Protocol (HIP) [11]. These RRs allow a HIP node to store in the DNS 99 its Host Identity (HI, the public component of the node public- 100 private key pair), Host Identity Tag (HIT, a truncated hash of its 101 HI), and the Domain Name or IP addresses of its Rendezvous Servers 102 (RVS) [14]. 104 The current Internet architecture defines two global namespaces: IP 105 addresses and domain names. The Domain Name System provides a two 106 way lookup between these two namespaces. The HIP architecture [12] 107 defines a new third namespace, called the Host Identity Namespace. 108 This namespace is composed of Host Identifiers (HI) of HIP nodes. 109 The Host Identity Tag (HIT) is one representation of an HI. This 110 representation is obtained by taking the output of a secure hash 111 function applied to the HI, truncated to the IPv6 address size. HITs 112 are supposed to be used in the place of IP addresses within most ULPs 113 and applications. 115 The Host Identity Protocol [11] allows two HIP nodes to establish 116 together a HIP Association. A HIP association is bound to the nodes 117 HIs rather than to their IP address(es). 119 A HIP node establish a HIP association by initiating a 4 way 120 handshake where two parties, the Initiatior and Responder, exchange 121 the I1, I2, R1 and R2 HIP packets (see section 5.3 of [11]) 123 +-----+ +-----+ 124 | |-------I1------>| | 125 | I |<------R1-------| R | 126 | |-------I2------>| | 127 | |<------R2-------| | 128 +-----+ +-----+ 130 Although a HIP node can initiate HIP communication 131 "opportunistically", i.e., without a priori knowledge of its peer's 132 HI, doing so exposes both endpoints to Man-in-the-Middle attacks on 133 the HIP handshake and its cryptographic protocol. Hence, there is a 134 desire to gain knowledge of peers' HI before applications and ULPs 135 initiate communication. Because many applications use the Domain 136 Name System [1] to name nodes, DNS is a straightforward way to 137 provision nodes with the HIP informations (i.e. HI and possibly RVS) 138 of nodes named in the DNS tree, without introducing or relying on an 139 additional piece of infrastructure. Note that without DNSSEC [3] the 140 Man-in-the-Middle attack evocated before has moved from the 141 opportunistic HIP handshake to the DNS name resolution; See also 142 Section 8. 144 The proposed HIP multi-homing mechanisms [13] allow a node to 145 dynamically change its set of underlying IP addresses while 146 maintaining IPsec SA and transport layer session survivability. The 147 HIP rendezvous extensions [14] proposal allows a HIP node to maintain 148 HIP reachability while it is changing its current location (the node 149 IP address(es)). This rendezvous service is provided by a third 150 party, the node's Rendezvous Server (RVS). 152 +-----+ 153 +--I1--->| RVS |---I1--+ 154 | +-----+ | 155 | v 156 +-----+ +-----+ 157 | |<------R1-------| | 158 | I |-------I2------>| R | 159 | |<------R2-------| | 160 +-----+ +-----+ 162 An initiator (I) willing to establish a HIP association with a 163 responder (R) would typically initiate a HIP exchange by sending an 164 I1 towards the RVS IP address rather than towards the responder IP 165 address. Then, the RVS, noticing that the receiver HIT is not its 166 own, but the HIT of a HIP node registered for the rendezvous Service, 167 would relay the I1 to the responder. Typically the responder would 168 then complete the exchange without further assistance from the RVS by 169 sending an R1 directly to the initiator IP address. 171 Currently, most of the Internet applications that need to communicate 172 with a remote host first translate a domain name (often obtained via 173 user input) into one or more IP address(es). This step occurs prior 174 to communication with the remote host, and relies on a DNS lookup. 176 With HIP, IP addresses are expected to be used mostly for on-the-wire 177 communication between end hosts, while most ULPs and applications 178 uses HIs or HITs instead (ICMP might be an example of an ULP not 179 using them). Consequently, we need a means to translate a domain 180 name into an HI. Using the DNS for this translation is pretty 181 straightforward: We define a new HIPHI (HIP HI) resource record. 182 Upon query by an application or ULP for a FQDN -> IP lookup, the 183 resolver would then additionally perform an FQDN -> HI lookup, and 184 use it to construct the resulting HI -> IP mapping (which is internal 185 to the HIP layer). The HIP layer uses the HI -> IP mapping to 186 translate HIs and their local representations (HITs, IPv4 and IPv6- 187 compatible LSIs) into IP addresses and vice versa. 189 This draft introduces the following new DNS Resource Records: 191 - HIPHI, for storing Host Identifiers and Host Identity Tags 193 - HIPRVS, for storing rendezvous server information 195 2. Conventions used in this document 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in RFC2119 [4]. 201 3. Usage Scenarios 203 In this section, we briefly introduce a number of usage scenarios 204 where the DNS is useful with the Host Identity Protocol. 206 With HIP, most application and ULPs are unaware of the IP addresses 207 used to carry packets on the wire. Consequently, a HIP node could 208 take advantage of having multiple IP addresses for fail-over, 209 redundancy, mobility, or renumbering, in a manner which is 210 transparent to most ULPs and applications (because they are bound to 211 HIs, hence they are agnostic to these IP address changes). 213 In these situations, a node wishing to be reachable by reference to 214 its FQDN should store the following informations in the DNS: 216 o A set of IP address(es) through A and AAAA RRs. 218 o A Host Identity (HI) and/or Host Identity Tag (HIT) through HIPHI 219 RRs. 221 o An IP address or DNS name of its Rendezvous Server(s) (RVS) 222 through HIPRVS RRs. 224 When a HIP node wants to initiate a communication with another HIP 225 node, it first needs to perform a HIP base exchange to set-up a HIP 226 association towards its peer. Although such an exchange can be 227 initiated opportunistically, i.e., without a priori knowledge of the 228 responder's HI, by doing so both nodes knowingly risk man-in-the- 229 middle attacks on the HIP exchange. To prevent these attacks, it is 230 recommended that the initiator first obtain the HI of the responder, 231 and then initiate the exchange. This can be done, for example, 232 through manual configuration or DNS lookups. Hence, a new HIPHI RR 233 is introduced. 235 When a HIP node is frequently changing its IP address(es), the 236 dynamic DNS update latency may prevent it from publishing its new IP 237 address(es) in the DNS. For solving this problem, the HIP 238 architecture introduces Rendezvous Servers (RVS). A HIP host uses a 239 Rendezvous Server as a Rendezvous point, to maintain reachability 240 with possible HIP initiators. Such a HIP node would publish in the 241 DNS its RVS IP address or DNS name in a HIPRVS RR, while keeping its 242 RVS up-to-date with its current set of IP addresses. 244 When a HIP node wants to initiate a HIP exchange with a responder it 245 will perform a number of DNS lookups. First the initiator will need 246 to query for an A or AAAA record at the responders FQDN. 248 If the query for the A and/or AAAA was responded to with a DNS answer 249 with RCODE=3 (Name Error), then the responder's information is not 250 present in the DNS and further queries SHOULD NOT be made. 252 In case the query for the address records returned a DNS answer with 253 RCODE=0 (No Error), then the initiator sends out two queries: One for 254 the HIPHI type and one for the HIPRVS type at the responder's FQDN. 256 Depending on the combinations of answer the situations described in 257 Section 3.1, Section 3.2 and Section 3.3 can occur. 259 Note that storing HIP RR information in the DNS at a FQDN which is 260 assigned to a non-HIP node might have ill effects on its reachability 261 by HIP nodes. 263 3.1 Simple static singly homed end-host 265 A HIP node (R) with a single static network attachment, wishing to be 266 reachable by reference to its FQDN (www.example.com), would store in 267 the DNS, in addition to its IP address(es) (IP-R), its Host Identity 268 (HI-R) in a HIPHI resource record. 270 An initiator willing to associate with a node would typically issue 271 the following queries: 273 QNAME=www.example.com, QTYPE=A 275 (QCLASS=IN is assumed and ommitted from the examples) 277 Which returns a DNS packet with RCODE=0 and one or more A RRs A with 278 the address of the responder (e.g. IP-R) in the answer section. 280 QNAME=www.example.com, QTYPE=HIPHI 282 Which returns a DNS packet with RCODE=0 and one or more HIPHI RRs 283 with the HIT and HI (e.g. HIT-R and HI-R) of the responder in the 284 answer section. 286 QNAME=www.example.com, QTYPE=HIPRVS 288 Which returns a DNS packet with RCODE=0 and an empty answer section. 290 Caption: In the remainder of this document, for the sake of keeping 291 diagrams simple and concise, several DNS queries and answers 292 are represented as one single transaction, while in fact 293 there are several queries and answers flowing back and 294 forth, as described in the textual examples. 296 [A? HIPRVS? HIPHI?] 297 [www.example.com ] +-----+ 298 +-------------------------------->| | 299 | | DNS | 300 | +-------------------------------| | 301 | | [A? HIPRVS? HIPHI? ] +-----+ 302 | | [www.example.com ] 303 | | [A IP-R ] 304 | | [HIPHI 10 3 2 HIT-R HI-R] 305 | v 306 +-----+ +-----+ 307 | |--------------I1------------->| | 308 | I |<-------------R1--------------| R | 309 | |--------------I2------------->| | 310 | |<-------------R2--------------| | 311 +-----+ +-----+ 313 3.2 Mobile end-host 315 A mobile HIP node (R) wishing to be reachable by reference to its 316 FQDN (www.example.com) would store in the DNS, possibly in addition 317 to its IP address(es) (IP-R), its HI (HI-R) in a HIPHI RR, and the IP 318 address(es) of its Rendezvous Server(s) (IP-RVS) in HIPRVS resource 319 record(s). The mobile HIP node also need to notify its Rendezvous 320 Servers of any change in its set of IP address(es). 322 An initiator willing to associate with such mobile node would 323 typically issue the following queries: 325 QNAME=www.example.com, QTYPE=A 327 Which returns a DNS packet with RCODE=0 and an empty answer section. 329 QNAME=www.example.com, QTYPE=HIPHI 331 Which returns a DNS packet with RCODE=0 and one or more HIPHI RRs 332 with the HIT and HI (e.g HIT-R and HI-R) of the responder in the 333 answer section. 335 QNAME=www.example.com, QTYPE=HIPRVS 337 Which returns a DNS packet with RCODE=0 and one or more HIPRVS RRs 338 containing IP address(es) (e.g IP-RVS) or FQDN(s) of RVS(s). 340 [A? HIPRVS? HIPHI?] 341 [www.example.com ] +-----+ 342 +--------------------------------->| | 343 | | DNS | 344 | +--------------------------------| | 345 | | [A? HIPRVS? HIPHI? ] +-----+ 346 | | [www.example.com ] 347 | | [HIPRVS 1 2 IP-RVS ] 348 | | [HIPHI 10 3 2 HIT-R HI-R] 349 | | 350 | | +-----+ 351 | | +------I1----->| RVS |-----I1------+ 352 | | | +-----+ | 353 | | | | 354 | | | | 355 | v | v 356 +-----+ +-----+ 357 | |<---------------R1------------| | 358 | I |----------------I2----------->| R | 359 | |<---------------R2------------| | 360 +-----+ +-----+ 362 The initiator would then send an I1 to one of its RVS. Following, 363 the RVS will relay the I1 up to the mobile node, which will complete 364 the HIP exchange. 366 3.3 Mixed Scenario 368 A HIP node might be configured with more than one IP address (multi- 369 homed), or Rendezvous Server (multi-reachable). In these cases, it 370 is possible that the DNS returns multiple A or AAAA RRs, as well as 371 HIPRVS containing one or multiple Rendezvous Servers. In addition to 372 its set of IP address(es) (IP-R1, IP-R2), a multi-homed end-host 373 would store in the DNS its HI (HI-R) in a HIPHI RR, and possibly the 374 IP address(es) of its RVS(s) (IP-RVS1, IP-RVS2) in HIPRVS RRs. 376 An initiator willing to associate with such a node would typically 377 issue the following queries: 379 QNAME=www.example.com, QTYPE=A 381 Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs 382 containing IP address(es) (e.g IP-R1 and IP-R2) in the answer 383 section. 385 QNAME=www.example.com, QTYPE=HIPHI 387 Which returns a DNS packet with RCODE=0 and one or more HIPHI RRs 388 with the HIT and HI (e.g HIT-R and HI-R) of the responder in the 389 answer section. 391 QNAME=www.example.com, QTYPE=HIPRVS 393 Which returns a DNS packet with RCODE=0 and one or more HIPRVS RRs 394 containing IP address(es) (e.g IP-RVS1, IP-RVS2) or FQDN(s) of 395 RVS(s). 397 [A? HIPRVS? HIPHI?] 398 [www.example.com ] +-----+ 399 +--------------------------------->| | 400 | | DNS | 401 | +--------------------------------| | 402 | | [A? HIPRVS? HIPHI? ] +-----+ 403 | | [www.example.com ] 404 | | [A IP-R1 ] 405 | | [A IP-R2 ] 406 | | [HIPRVS 1 2 IP-RVS1 ] 407 | | [HIPRVS 1 2 IP-RVS2 ] 408 | | [HIPHI 10 3 2 HIT-R HI-R] 409 | | 410 | | +------+ 411 | | +-----I1----->| RVS1 |------I1------+ 412 | | | +------+ | 413 | v | v 414 +-----+ +-----+ 415 | |---------------I1------------->| | 416 | | | | 417 | I |<--------------R1--------------| R | 418 | |---------------I2------------->| | 419 | |<--------------R2--------------| | 420 +-----+ +-----+ 421 | ^ 422 | +------+ | 423 +-----I1----->| RVS2 |------I1------+ 424 +------+ 426 4. Overview of using the DNS with HIP 428 4.1 Storing HI and HIT in DNS 430 Any conforming implementation may store Host Identifiers in a DNS 431 HIPHI RDATA format. An implementation may also store a HIT along 432 with its associated HI. If a particular form of an HI or HIT does 433 not already have a specified RDATA format, a new RDATA-like format 434 SHOULD be defined for the HI or HIT. 436 4.1.1 Different types of HITs 438 There are two types of HITs. HITs of the first type, called Type 1 439 HIT, consist of an 8-bit prefix followed by 120 bits of the hash of 440 the public key. HITs of the second type (Type 2 HIT) consist of a 441 Host Assigning Authority Field (HAA), and only the last 64 bits come 442 from a SHA-1 hash of the Host Identity. This latter format for HIT 443 is recommended for 'well known' systems. It is possible to support a 444 resolution mechanism for these names in hierarchical directories, 445 like the DNS. 447 This document fully specifies only Type 2 HITs. Type 1 HITs are 448 specified in Section 3.1 of [11]. 450 Note that the format how HITs are stored in the HIPHI RRs may be 451 different form the format actually used in protocols, the HIP base 452 exchange [11] included. This is because the DNS RR explicitly 453 contains the HIT type and algorithm, while some protocols may prefer 454 to use a prefix to indicate the HIT type. The implementations are 455 expected to use the actual HI when comparing Host Identities. 457 4.1.1.1 Host Assigning Authority (HAA) field 459 The 64 bits of HAA supports two levels of delegation. The first is a 460 registered assigning authority (RAA). The second is a registered 461 identity (RI, commonly a company). The RAA is 24 bits with values 462 assign sequentially by ICANN. The RI is 40 bits, also assigned 463 sequentially but by the RAA. 465 4.1.1.2 Storing HAA in HIPHI Resource Records 467 Any conforming implementation may store a domain name Host Assigning 468 Authority (HAA) in a DNS HIPHI RDATA format. A HAA MUST be stored 469 like a Type 2 HIT, while the least significant bits of the HIT 470 extracted from the HI hash output are set to zero, the Host Identity 471 Length is set zero, and the Host Identity field is omitted. If a 472 particular form of a HAA does not already have an associated HIT 473 specified RDATA format, a new RDATA-like format SHOULD be defined for 474 the HIT/HAA. 476 4.1.1.3 HI and HIT verification 478 Upon return of a HIPHI RR, a host MUST always calculate the HI- 479 derivative HIT to be used in the HIP exchange, as specified in the 480 HIP architecture [12], while the HIT possibly embedded along SHOULD 481 only be used as an optimization (e.g. table lookup). 483 4.2 Storing Rendezvous Servers in the DNS 485 The HIP Rendezvous server (HIPRVS) resource record indicates an 486 address or a domain name of a RendezVous Server, towards which a HIP 487 I1 packet might be sent to trigger the establishment of an 488 association with the entity named by this resource record [14]. 490 An RVS receiving such an I1 would then relay it to the appropriate 491 responder (the owner of the I1 receiver HIT). The responder will 492 then complete the exchange with the initiator, typically without 493 ongoing help from the RVS. 495 Any conforming implementation may store Rendezvous Server's IP 496 address(es) or DNS name in a DNS HIPRVS RDATA format. If a 497 particular form of a RVS reference does not already have a specified 498 RDATA format, a new RDATA-like format SHOULD be defined for the RVS. 500 4.3 Initiating connections based on DNS names 502 On a HIP node, a Host Identity Protocol exchange SHOULD be initiated 503 whenever an Upper Layer Protocol attempt to communicate with an 504 entity and the DNS lookup returns HIPHI and/or HIPRVS resource 505 records. If a DNS lookup returns one or more HIPRVS RRs and no A nor 506 AAAA RRs, the afore mentioned HIP exchange SHOULD be initiated 507 towards one of these RVS [11]. Since some hosts may choose not to 508 have HIPHI information in DNS, hosts MAY implement support for 509 opportunistic HIP. 511 5. Storage Format 513 5.1 HIPHI RDATA format 515 The RDATA for a HIPHI RR consists of a HIT type, an algorithm type, a 516 HIT, and a public key. 518 0 1 2 3 519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | HIT type | HIT algorithm | PK algorithm | | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | 523 ~ ~ 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | / 526 / Public Key / 527 / / 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 530 5.1.1 HIT type format 532 The HIT type field indicates the Host Identity Tag (HIT) type and the 533 implied HIT format. 535 The following values are defined: 537 0 No HIT is present 539 1 A Type 1 HIT is present 541 2 A Type 2 HIT is present 543 3-6 Unassigned 545 7 A HAA is present 547 5.1.2 HIT algorithm format 549 The HIT algorithm indicates the hash algorithm used to generate the 550 Host Identity Tag (HIT) from the HI. 552 The following values are defined: 554 0 Reserved 556 1 SHA1 558 2-255 Unassigned 560 5.1.3 PK algorithm format 562 The PK algorithm field indicates the public key cryptographic 563 algorithm and the implied public key field format. This document 564 reuse the values defined for the 'algorithm type' of the IPSECKEY RR 565 [10] 'gateway type' field. 567 The presently defined values are given only informally: 569 1 A DSA key is present, in the format defined in RFC2536 [5]. 571 2 A RSA key is present, in the format defined in RFC3110 [6]. 573 5.1.4 HIT format 575 There's currently two types of HITs, and a single type of HAA. Both 576 of them are stored in network byte order within a self-describing 577 variable length wire-encoded (as per Section 3.3 578 of [2]): 580 o A *Type 1* HIT: least significant bits of the hash (e.g. SHA1) of 581 the public key (Host Identity), which is possibly following in the 582 HIPHI RR. 584 o A *Type 2* HIT: binary prefix (HAA) concatenated with a the least 585 significant bits of the hash (e.g. SHA1) of the public key (Host 586 Identity), which is possibly following in the HIPHI RR. 588 o A HAA: binary prefix (HAA) concatenated with 0, up to the 589 associated HIT length. 591 5.1.5 Public key format 593 Both of the public key types defined in this document (RSA and DSA) 594 reuse the public key formats defined for the IPSECKEY RR [10] (which 595 in turns contains the algorithm-specific portion of the KEY RR RDATA, 596 all of the KEY RR DATA after the first four octets, corresponding to 597 the same portion of the KEY RR that must be specified by documents 598 that define a DNSSEC algorithm). 600 In the future, if a new algorithm is to be used both by IPSECKEY RR 601 and HIPHI RR, it would probably use the same public key encodings for 602 both RRs. Unless specified otherwise, the HIPHI public key field 603 would use the same public key format as the IPSECKEY RR RDATA for the 604 corresponding algorithm. 606 The DSA key format is defined in RFC2536 [5]. 608 The RSA key format is defined in RFC3110 [6] and the RSA key size 609 limit (4096 bits) is relaxed in the IPSECKEY RR [10] specification. 611 5.2 HIPRVS RDATA format 613 The RDATA for a HIPRVS RR consists of a preference value, a 614 Rendezvous server type and either one or more Rendezvous server 615 address, or one Rendezvous server domain name. 617 0 1 2 3 618 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | preference | type | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rendezvous server | 622 ~ ~ 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 5.2.1 Preference format 627 This is an unsigned 8-bit value, used to specify the preference given 628 to the RVS in the HIPRVS RR amongst others at the same owner. RVSs 629 with lower values are preferred. If there is a tie within some RR 630 subset, the initiating HIP host should pick one of the RVS randomly 631 from the set of RRs, such that the requester load is fairly balanced 632 amongst all RVSs of the set. 634 5.2.2 Rendezvous server type format 636 The Rendezvous server type indicates the format of the information 637 stored in the Rendezvous server field. 639 This document reuses the type values for the 'gateway type' field of 640 the IPSECKEY RR [10]. The presently defined values are given only 641 informally: 643 1. One or more 4-byte IPv4 address(es) in network byte order are 644 present. 646 2. One or more 16-byte IPv6 address(es) in network byte order are 647 present. 649 3. One or more variable length wire-encoded domain names as 650 described in section 3.3 of RFC1035 [2]. The wire-encoded format 651 is self-describing, so the length is implicit. The domain names 652 MUST NOT be compressed. 654 5.2.3 Rendezvous server format 656 The Rendezvous server field indicates one or more Rendezvous 657 Server(s) IP address(es), or domain name(s). A HIP I1 packet sent to 658 any of these RVS would reach the entity named by this resource 659 record. 661 This document reuses the format used for the 'gateway' field of the 662 IPSECKEY RR [10], but allows to concatenate several IP (v4 or v6) 663 addresses. The presently defined formats for the data portion of the 664 Rendezvous server field are given only informally: 666 o One or more 32-bit IPv4 address(es) in network byte order. 668 o One or more 128-bit IPv6 address(es) in network byte order. 670 o One or more variable length wire-encoded domain names as described 671 in section 3.3 of RFC1035 [2]. The wire-encoded format is self- 672 describing, so the length is implicit. The domain names MUST NOT 673 be compressed. 675 6. Presentation Format 677 This section specifies the representation of the HIPHI and HIPRVS RR 678 in a zone data master file. 680 6.1 HIPHI Representation 682 The HIT Type, HIT algorithm, PK algorithm, HIT and Public Key are 683 REQUIRED. 685 The HIT Type, HIT algorithm, and PK algorithm are represented as 686 unsigned integers. 688 The HIT field is represented as the Base16 encoding [8] (a.k.a. hex 689 or hexadecimal) of the public key hash. The encoding MUST NOT 690 contains whitespace. If no HIT is to be indicated, then the HIT 691 algorithm MUST be zero and the HIT field must be "." (a single dot 692 character). 694 The Public Key field is represented as the Base64 encoding [8] of the 695 public key. The encoding MAY contains whitespace(s), and such 696 whitespaces MUST be ignored. 698 The complete representation of the HPIHI record is: 700 IN HIPHI ( hit-type hit-algorithm pk-algorithm 701 base16-encoded-hit 702 base64-encoded-public-key ) 704 6.2 HIPRVS Representation 706 The Preference and RVS Type fields are REQUIRED. At least one RVS 707 field MUST be present. 709 The HIT Type, HIT algorithm, and PK algorithm are represented as 710 unsigned integers. 712 The RVS field is represented by one or more: 714 o IPv4 dotted decimal address(es) 716 o IPv6 colon hex address(es) 718 o uncompressed domain name(s) 720 The complete representation of the HPIRVS record is: 722 IN HIPRVS ( preference rendezvous-server-type 723 rendezvous-server[1] 724 ... 725 rendezvous-server[n] ) 727 6.3 Examples 729 Example of a node with a HI but no HIT: 731 www.example.com IN HIPHI ( 0 1 2 732 . 733 AB3NzaC1kc3MAAACBAOBhKn 734 TCPOuFBzZQX/N3O9dm9P9iv 735 UIMoId== ) 737 Example of a node with a HI and a HIT: 739 www.example.com IN HIPHI ( 1 1 2 740 AB3NzaC1kc3MAAACBAOBhKn 741 TCPOuFBzZQX/N3O9dm9P9iv 742 UIMoId== ) 744 Example of a node with an IPv6 RVS: 746 www.example.com IN HIPRVS (10 2 2001:db8:200:1:20c:f1ff:feb:a533 ) 748 Example of a node with three IPv4 RVS: 750 www.example.com IN HIPRVS ( 10 1 192.0.1.2 192.0.2.2 192.0.3.2 ) 752 Example of a node with two named RVS: 754 www.example.com IN HIPRVS ( 10 3 rvs.uk.example.com 755 rvs.us.example.com ) 757 7. Retrieving Multiple HITs and IPs from the DNS 759 If a host receives multiple HITs in a response to a DNS query, those 760 HITs MUST be considered to denote a single service, and be 761 semantically equivalent from that point of view. When initiating a 762 base exchange with the denoted service, the host SHOULD be prepared 763 to accept any of HITs as the peer's identity. A host MAY implement 764 this by using the opportunistic mode (destination HIT null in I1), or 765 by sending multiple I1s, if needed. 767 In particular, if a host receives multiple HITs and multiple IP 768 addresses in response to a DNS query, the host cannot know how the 769 HITs are reachable at the listed IP addresses. The mapping may be 770 any, i.e., all HITs may be reachable at all of the listed IP 771 addresses, some of the HITs may be reachable at some of the IP 772 addresses, or there may even be one-to-one mapping between the HITs 773 and IP addresses. In general, the host cannot know the mapping and 774 MUST NOT expect any particular mapping. 776 It is RECOMMENDED that if a host receives multiple HITs, the host 777 SHOULD first try to initiate the base exchange by using the 778 opportunistic mode. If the returned HIT does not match with any of 779 the expected HITs, the host SHOULD retry by sending further I1s, one 780 at time, trying out all of the listed HITs. If the host receives an 781 R1 for any of the I1s, the host SHOULD continue to use the successful 782 IP address until an R1 with a listed HIT is received, or the host has 783 tried all HITs, and try the other IP addresses only after that. A 784 host MAY also send multiple I1s in parallel, but sending such I1s 785 MUST be rate limited to avoid flooding (as per Section 8.4.1 of 786 [11]). 788 8. Security Considerations 790 Though the security considerations of the HIP DNS extensions still 791 need to be more investigated and documented, this section contains a 792 description of the known threats involved with the usage of the HIP 793 DNS extensions. 795 In a manner similar to the IPSECKEY RR [10], the HIP DNS Extensions 796 allows to provision two HIP nodes with the public keying material 797 (HI) of their peer. These HIs will be subsequently used in a key 798 exchange between the peers. Hence, the HIP DNS Extensions introduce 799 the same kind of threats that IPSECKEY does, plus threats caused by 800 the possibility given to a HIP node to initiate or accept a HIP 801 exchange using "Opportunistic" or "Unpublished Initiator HI" modes. 803 A HIP node SHOULD obtain both the HIPHI and HIPRVS RRs from a trusted 804 party trough a secure channel insuring proper data integrity of the 805 RRs. DNSSEC [3] provides such a secure channel. 807 In the absence of a proper secure channel, both parties are 808 vulnerable to MitM and DoS attacks, and unrelated parties might be 809 subject to DoS attacks as well. These threats are described in the 810 following sections. 812 8.1 Attacker tampering with an unsecure HIPHI RR 814 The HIPHI RR contains public keying material in the form of the named 815 peer's public key (the HI) and its secure hash (the HIT). Both of 816 these are not sensitive to attacks where an adversary gains knowledge 817 of them. However, an attacker that is able to mount an active attack 818 on the DNS, i.e., tampers with this HIPHI RR (e.g. using DNS 819 spoofing) is able to mount Man-in-the-Middle attacks on the 820 cryptographic core of the eventual HIP exchange (responder's HIPHI 821 and HIPRVS rewritten by the attacker). 823 8.2 Attacker tampering with an unsecure HIPRVS RR 825 The HIPRVS RR contains a destination IP address where the named peer 826 is reachable by an I1 (HIP Rendezvous Extensions IPSECKEY RR [14] ). 827 Thus, an attacker able to tamper with this RRs is able to redirect I1 828 packets sent to the named peer to a chosen IP address, for DoS or 829 MitM attacks. Note that this kind of attacks are not specific to HIP 830 and exist independently to whether or not HIP and the HIPRVS RR are 831 used. Such an attacker might tamper with A and AAAA RRs as well. 833 An attacker might obviously use these two attacks in conjunction: It 834 will replace the responder's HI and RVS IP address by its owns in a 835 spoofed DNS packet sent to the initiator HI, then redirect all 836 exchanged packets through him and mount a MitM on HIP. In this case 837 HIP won't provide confidentiality nor initiator HI protection from 838 eavesdroppers. 840 8.3 Opportunistic HIP 842 A HIP initiator may not be aware of its peer's HI, and/or its HIT 843 (e.g. because the DNS does not contains HIP material, or the resolver 844 isn't HIP-enabled), and attempt an opportunistic HIP exchange towards 845 its known IP address, filling the responder HIT field with zeros in 846 the I1 header. Such an initiator is vulnerable to a MitM attack 847 because it can't validate the HI and HIT contained in a replied R1. 848 Hence, an implementation MAY choose not to use opportunistic mode. 850 8.4 Unpublished Initiator HI 852 A HIP initiator may choose to use an unpublished HI, which is not 853 stored in the DNS by means of a HIPHI RR. A responder associating 854 with such an initiator knowingly risks a MitM attack because it 855 cannot validate the initiator's HI. Hence, an implementation MAY 856 choose not to use unpublished mode. 858 8.5 Hash and HITs Collisions 860 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 861 by HIP to generate a HIT from an HI) eventually become insecure, 862 because an exploit has been found in which an attacker with a 863 reasonable computation power breaks one of the security features of 864 the hash (e.g. its supposed collision resistance). This is why a HIP 865 end-node implementation SHOULD NOT authenticate its HIP peers based 866 solely on a HIT retrieved from DNS, but SHOULD rather use HI-based 867 authentication. 869 8.6 DNSSEC 871 In the absence of DNSSEC, the HIPHI and HIPRVS RRs are subject to the 872 threats described in RFC 3833 [17]. 874 9. IANA Considerations 876 IANA needs to allocate two new RR type code for HIPHI and HIPRVS from 877 the standard RR type space. 879 IANA needs to open a new registry for the HIPHI RR HIT type. Defined 880 types are: 882 0 No HIT is present 884 1 A Type 1 HIT is present 886 2 A Type 2 HIT is present 888 3-6 Unassigned 890 7 A HAA is present 892 Adding new reservations requires IETF consensus RFC2434 [16]. 894 IANA needs to open a new registry for the HIPHI RR HIT algorithm. 895 Defined types are: 897 0 Reserved 899 1 SHA1 901 2-255 Unassigned 903 Adding new reservations requires IETF consensus RFC2434 [16]. 905 IANA does not need to open a new registry for the HIPHI RR type for 906 public key algorithms because the HIPHI RR reuse 'algorithms types' 907 defined for the IPSECKEY RR [10]. The presently defined numbers are 908 given here only informally: 910 0 is reserved 912 1 is RSA 914 2 is DSA 916 IANA does not need to open a new registry for the HIPRVS RR 917 Rendezvous server type because the HIPHI RR reuse the 'gateway types' 918 defined for the IPSECKEY RR [10]. The presently defined numbers are 919 given here only informally: 921 0 is reserved 923 1 is IPv4 925 2 is IPv6 927 3 is a wire-encoded uncompressed domain name 929 10. Acknowledgments 931 As usual in the IETF, this document is the result of a collaboration 932 between many people. The authors would like to thanks the author 933 (Michael Richardson), contributors and reviewers of the IPSECKEY RR 934 [10] specification, which this document was framed after. The 935 authors would also like to thanks the following people, who have 936 provided thoughtful and helpful discussions and/or suggestions, that 937 have helped improving this document: Rob Austein, Hannu Flinck, Tom 938 Henderson, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, 939 and Gabriel Montenegro. Some parts of this draft stem from [11]. 941 Julien Laganier is partly funded by Ambient Networks, a research 942 project supported by the European Commission under its Sixth 943 Framework Program. The views and conclusions contained herein are 944 those of the authors and should not be interpreted as necessarily 945 representing the official policies or endorsements, either expressed 946 or implied, of the Ambient Networks project or the European 947 Commission. 949 11. References 951 11.1 Normative references 953 [1] Mockapetris, P., "Domain names - concepts and facilities", 954 STD 13, RFC 1034, November 1987. 956 [2] Mockapetris, P., "Domain names - implementation and 957 specification", STD 13, RFC 1035, November 1987. 959 [3] Eastlake, D. and C. Kaufman, "Domain Name System Security 960 Extensions", RFC 2065, January 1997. 962 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 963 Levels", BCP 14, RFC 2119, March 1997. 965 [5] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 966 (DNS)", RFC 2536, March 1999. 968 [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 969 System (DNS)", RFC 3110, May 2001. 971 [7] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, 972 "Representing Internet Protocol version 6 (IPv6) Addresses in 973 the Domain Name System (DNS)", RFC 3363, August 2002. 975 [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 976 RFC 3548, July 2003. 978 [9] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS 979 Extensions to Support IP Version 6", RFC 3596, October 2003. 981 [10] Richardson, M., "A Method for Storing IPsec Keying Material in 982 DNS", RFC 4025, March 2005. 984 [11] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 985 (work in progress), June 2005. 987 [12] Moskowitz, R., "Host Identity Protocol Architecture", 988 draft-ietf-hip-arch-02 (work in progress), January 2005. 990 [13] Nikander, P., "End-Host Mobility and Multi-Homing with Host 991 Identity Protocol", draft-ietf-hip-mm-01 (work in progress), 992 February 2005. 994 [14] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 995 Rendezvous Extension", draft-ietf-hip-rvs-02 (work in 996 progress), June 2005. 998 11.2 Informative references 1000 [15] Jokela, P., "Using ESP transport format with HIP", 1001 draft-jokela-hip-esp-00 (work in progress), February 2005. 1003 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1004 Considerations Section in RFCs", BCP 26, RFC 2434, 1005 October 1998. 1007 [17] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 1008 System (DNS)", RFC 3833, August 2004. 1010 Authors' Addresses 1012 Pekka Nikander 1013 Ericsson Research Nomadic Lab 1014 JORVAS FIN-02420 1015 FINLAND 1017 Phone: +358 9 299 1 1018 Email: pekka.nikander@nomadiclab.com 1020 Julien Laganier 1021 DoCoMo Communications Laboratories Europe GmbH 1022 Landsberger Strasse 312 1023 Munich 80687 1024 Germany 1026 Phone: +49 89 56824 231 1027 Email: julien.ietf@laposte.net 1028 URI: http://www.docomolab-euro.com/ 1030 Intellectual Property Statement 1032 The IETF takes no position regarding the validity or scope of any 1033 Intellectual Property Rights or other rights that might be claimed to 1034 pertain to the implementation or use of the technology described in 1035 this document or the extent to which any license under such rights 1036 might or might not be available; nor does it represent that it has 1037 made any independent effort to identify any such rights. Information 1038 on the procedures with respect to rights in RFC documents can be 1039 found in BCP 78 and BCP 79. 1041 Copies of IPR disclosures made to the IETF Secretariat and any 1042 assurances of licenses to be made available, or the result of an 1043 attempt made to obtain a general license or permission for the use of 1044 such proprietary rights by implementers or users of this 1045 specification can be obtained from the IETF on-line IPR repository at 1046 http://www.ietf.org/ipr. 1048 The IETF invites any interested party to bring to its attention any 1049 copyrights, patents or patent applications, or other proprietary 1050 rights that may cover technology that may be required to implement 1051 this standard. Please address the information to the IETF at 1052 ietf-ipr@ietf.org. 1054 Disclaimer of Validity 1056 This document and the information contained herein are provided on an 1057 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1058 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1059 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1060 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1061 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1064 Copyright Statement 1066 Copyright (C) The Internet Society (2005). This document is subject 1067 to the rights, licenses and restrictions contained in BCP 78, and 1068 except as set forth therein, the authors retain all their rights. 1070 Acknowledgment 1072 Funding for the RFC Editor function is currently provided by the 1073 Internet Society.