idnits 2.17.1 draft-ietf-hip-dns-03.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 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 940. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 953. ** 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 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 -- 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 (October 10, 2005) is 6772 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) -- Looks like a reference, but probably isn't: '1' on line 651 == Unused Reference: 'RFC3363' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC3596' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 904, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Downref: Normative reference to an Informational RFC: RFC 3363 ** Obsolete normative reference: RFC 3548 (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. 'I-D.ietf-hip-base') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. 'I-D.ietf-hip-rvs') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-02 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 9 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: April 13, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 October 10, 2005 8 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 9 draft-ietf-hip-dns-03 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 April 13, 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. HI and HIT Verification . . . . . . . . . . . . . . . 12 61 4.2. Storing Rendezvous Servers in the DNS . . . . . . . . . . 12 62 4.3. Initiating connections based on DNS names . . . . . . . . 12 63 5. Storage Format . . . . . . . . . . . . . . . . . . . . . . . . 13 64 5.1. HIPHI RDATA format . . . . . . . . . . . . . . . . . . . . 13 65 5.1.1. PK algorithm format . . . . . . . . . . . . . . . . . 13 66 5.1.2. HIT length format . . . . . . . . . . . . . . . . . . 13 67 5.1.3. HIT format . . . . . . . . . . . . . . . . . . . . . . 13 68 5.1.4. Public key format . . . . . . . . . . . . . . . . . . 13 69 5.2. HIPRVS RDATA format . . . . . . . . . . . . . . . . . . . 14 70 5.2.1. Preference format . . . . . . . . . . . . . . . . . . 14 71 5.2.2. Rendezvous server type format . . . . . . . . . . . . 14 72 5.2.3. Rendezvous server format . . . . . . . . . . . . . . . 15 73 6. Presentation Format . . . . . . . . . . . . . . . . . . . . . 16 74 6.1. HIPHI Representation . . . . . . . . . . . . . . . . . . . 16 75 6.2. HIPRVS Representation . . . . . . . . . . . . . . . . . . 16 76 6.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. Retrieving Multiple HITs and IPs from the DNS . . . . . . . . 18 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 8.1. Attacker tampering with an insecure HIPHI RR . . . . . . . 19 80 8.2. Attacker tampering with an insecure HIPRVS RR . . . . . . 19 81 8.3. Opportunistic HIP . . . . . . . . . . . . . . . . . . . . 20 82 8.4. Unpublished Initiator HI . . . . . . . . . . . . . . . . . 20 83 8.5. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 20 84 8.6. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 11.1. Normative references . . . . . . . . . . . . . . . . . . . 23 89 11.2. Informative references . . . . . . . . . . . . . . . . . . 24 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 91 Intellectual Property and Copyright Statements . . . . . . . . . . 26 93 1. Introduction 95 This document specifies two new resource records (RRs) for the Domain 96 Name System (DNS) [RFC1034], and how to use them with the Host 97 Identity Protocol (HIP) [I-D.ietf-hip-base]. These RRs allow a HIP 98 node to store in the DNS its Host Identity (HI, the public component 99 of the node public-private key pair), Host Identity Tag (HIT, a 100 truncated hash of its HI), and the Domain Name or IP addresses of its 101 rendezvous servers (RVS) [I-D.ietf-hip-rvs]. 103 The current Internet architecture defines two global namespaces: IP 104 addresses and domain names. The Domain Name System provides a two 105 way lookup between these two namespaces. The HIP architecture 106 [I-D.ietf-hip-arch] defines a new third namespace, called the Host 107 Identity Namespace. This namespace is composed of Host Identifiers 108 (HI) of HIP nodes. The Host Identity Tag (HIT) is one representation 109 of an HI. This representation is obtained by taking the output of a 110 secure hash function applied to the HI, truncated to the IPv6 address 111 size. HITs are supposed to be used in the place of IP addresses 112 within most ULPs and applications. 114 The Host Identity Protocol [I-D.ietf-hip-base] allows two HIP nodes 115 to establish together a HIP Association. A HIP association is bound 116 to the nodes HIs rather than to their IP address(es). 118 A HIP node establish a HIP association by initiating a 4 way 119 handshake where two parties, the initiator and responder, exchange 120 the I1, I2, R1 and R2 HIP packets (see section 5.3 of [I-D.ietf-hip- 121 base]) 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 prior knowledge of its peer's HI, 132 doing so exposes both endpoints to Man-in-the-Middle attacks on the 133 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 [RFC1034] to name nodes, DNS is a straightforward way to 137 provision nodes with the HIP information (i.e. HI, HIT and possibly 138 RVS) of nodes named in the DNS tree, without introducing or relying 139 on an additional piece of infrastructure. Note that in the absence 140 of DNSSEC [RFC2065], the DNS name resolution is vulnerable to Man-in- 141 the-Middle attack (See Section 8), and hence the HIP handshake is 142 also vulnerable to a Man-in-the-Middle attack. 144 The proposed HIP multi-homing mechanisms [I-D.ietf-hip-mm] allow a 145 node to dynamically change its set of underlying IP addresses while 146 maintaining IPsec SA and transport layer session survivability. The 147 HIP rendezvous extensions [I-D.ietf-hip-rvs] proposal allows a HIP 148 node to maintain HIP reachability while it is changing its current 149 location (the node IP address(es)). This rendezvous service is 150 provided by a third 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 use 178 HIs or HITs instead (ICMP might be an example of an ULP not using 179 them). Consequently, we need a means to translate a domain name into 180 an HI. Using the DNS for this translation is pretty straightforward: 181 We define a new HIPHI (HIP HI) resource record. Upon query by an 182 application or ULP for a FQDN -> IP lookup, the resolver would then 183 additionally perform an FQDN -> HI lookup, and use it to construct 184 the resulting HI -> IP mapping (which is internal to the HIP layer). 185 The HIP layer uses the HI -> IP mapping to translate HIs and their 186 local representations (HITs, IPv4 and IPv6-compatible LSIs) into IP 187 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 [RFC2119]. 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 information 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 prior 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. Depending on the type of the 246 implementation, the order in which those lookups will be issued may 247 vary. For instance, implementations using IP address in APIs may 248 typically first query for A and/or AAAA records at the responder 249 FQDN, while those using HIT in APIS may typically first query for 250 HIPHI records. 252 In the following we assume that the initiator first queries for A 253 and/or AAAA records at the responder FQDN. 255 If the query for the A and/or AAAA was responded to with a DNS answer 256 with RCODE=3 (Name Error), then the responder's information is not 257 present in the DNS and further queries SHOULD NOT be made. 259 In case the query for the address records returned a DNS answer with 260 RCODE=0 (No Error), then the initiator sends out two queries: One for 261 the HIPHI type and one for the HIPRVS type at the responder's FQDN. 263 Depending on the combinations of answer the situations described in 264 Section 3.1, Section 3.2 and Section 3.3 can occur. 266 Note that storing HIP RR information in the DNS at a FQDN which is 267 assigned to a non-HIP node might have ill effects on its reachability 268 by HIP nodes. 270 3.1. Simple static singly homed end-host 272 A HIP node (R) with a single static network attachment, wishing to be 273 reachable by reference to its FQDN (www.example.com), would store in 274 the DNS, in addition to its IP address(es) (IP-R), its Host Identity 275 (HI-R) in a HIPHI resource record. 277 An initiator willing to associate with a node would typically issue 278 the following queries: 280 QNAME=www.example.com, QTYPE=A 282 (QCLASS=IN is assumed and omitted from the examples) 284 Which returns a DNS packet with RCODE=0 and one or more A RRs A with 285 the address of the responder (e.g. IP-R) in the answer section. 287 QNAME=www.example.com, QTYPE=HIPHI 289 Which returns a DNS packet with RCODE=0 and one or more HIPHI RRs 290 with the HIT and HI (e.g. HIT-R and HI-R) of the responder in the 291 answer section. 293 QNAME=www.example.com, QTYPE=HIPRVS 295 Which returns a DNS packet with RCODE=0 and an empty answer section. 297 Caption: In the remainder of this document, for the sake of keeping 298 diagrams simple and concise, several DNS queries and answers 299 are represented as one single transaction, while in fact 300 there are several queries and answers flowing back and 301 forth, as described in the textual examples. 303 [A? HIPRVS? HIPHI?] 304 [www.example.com ] +-----+ 305 +-------------------------------->| | 306 | | DNS | 307 | +-------------------------------| | 308 | | [A? HIPRVS? HIPHI? ] +-----+ 309 | | [www.example.com ] 310 | | [A IP-R ] 311 | | [HIPHI 10 3 2 HIT-R HI-R] 312 | v 313 +-----+ +-----+ 314 | |--------------I1------------->| | 315 | I |<-------------R1--------------| R | 316 | |--------------I2------------->| | 317 | |<-------------R2--------------| | 318 +-----+ +-----+ 320 3.2. Mobile end-host 322 A mobile HIP node (R) wishing to be reachable by reference to its 323 FQDN (www.example.com) would store in the DNS, possibly in addition 324 to its IP address(es) (IP-R), its HI (HI-R) in a HIPHI RR, and the IP 325 address(es) of its rendezvous server(s) (IP-RVS) in HIPRVS resource 326 record(s). The mobile HIP node also needs to notify its rendezvous 327 servers of any change in its set of IP address(es). 329 An initiator willing to associate with such mobile node would 330 typically issue the following queries: 332 QNAME=www.example.com, QTYPE=A 334 Which returns a DNS packet with RCODE=0 and an empty answer section. 336 QNAME=www.example.com, QTYPE=HIPHI 338 Which returns a DNS packet with RCODE=0 and one or more HIPHI RRs 339 with the HIT and HI (e.g. HIT-R and HI-R) of the responder in the 340 answer section. 342 QNAME=www.example.com, QTYPE=HIPRVS 344 Which returns a DNS packet with RCODE=0 and one or more HIPRVS RRs 345 containing IP address(es) (e.g. IP-RVS) or FQDN(s) of RVS(s). 347 [A? HIPRVS? HIPHI?] 348 [www.example.com ] +-----+ 349 +--------------------------------->| | 350 | | DNS | 351 | +--------------------------------| | 352 | | [A? HIPRVS? HIPHI? ] +-----+ 353 | | [www.example.com ] 354 | | [HIPRVS 1 2 IP-RVS ] 355 | | [HIPHI 10 3 2 HIT-R HI-R] 356 | | 357 | | +-----+ 358 | | +------I1----->| RVS |-----I1------+ 359 | | | +-----+ | 360 | | | | 361 | | | | 362 | v | v 363 +-----+ +-----+ 364 | |<---------------R1------------| | 365 | I |----------------I2----------->| R | 366 | |<---------------R2------------| | 367 +-----+ +-----+ 369 The initiator would then send an I1 to one of its RVS. Following, 370 the RVS will relay the I1 up to the mobile node, which will complete 371 the HIP exchange. 373 3.3. Mixed Scenario 375 A HIP node might be configured with more than one IP address (multi- 376 homed), or rendezvous server (multi-reachable). In these cases, it 377 is possible that the DNS returns multiple A or AAAA RRs, as well as 378 HIPRVS containing one or multiple rendezvous servers. In addition to 379 its set of IP address(es) (IP-R1, IP-R2), a multi-homed end-host 380 would store in the DNS its HI (HI-R) in a HIPHI RR, and possibly the 381 IP address(es) of its RVS(s) (IP-RVS1, IP-RVS2) in HIPRVS RRs. 383 An initiator willing to associate with such a node would typically 384 issue the following queries: 386 QNAME=www.example.com, QTYPE=A 388 Which returns a DNS packet with RCODE=0 and one or more A or AAAA RRs 389 containing IP address(es) (e.g. IP-R1 and IP-R2) in the answer 390 section. 392 QNAME=www.example.com, QTYPE=HIPHI 394 Which returns a DNS packet with RCODE=0 and one or more HIPHI RRs 395 with the HIT and HI (e.g. HIT-R and HI-R) of the responder in the 396 answer section. 398 QNAME=www.example.com, QTYPE=HIPRVS 400 Which returns a DNS packet with RCODE=0 and one or more HIPRVS RRs 401 containing IP address(es) (e.g. IP-RVS1, IP-RVS2) or FQDN(s) of 402 RVS(s). 404 [A? HIPRVS? HIPHI?] 405 [www.example.com ] +-----+ 406 +--------------------------------->| | 407 | | DNS | 408 | +--------------------------------| | 409 | | [A? HIPRVS? HIPHI? ] +-----+ 410 | | [www.example.com ] 411 | | [A IP-R1 ] 412 | | [A IP-R2 ] 413 | | [HIPRVS 1 2 IP-RVS1 ] 414 | | [HIPRVS 1 2 IP-RVS2 ] 415 | | [HIPHI 10 3 2 HIT-R HI-R] 416 | | 417 | | +------+ 418 | | +-----I1----->| RVS1 |------I1------+ 419 | | | +------+ | 420 | v | v 421 +-----+ +-----+ 422 | |---------------I1------------->| | 423 | | | | 424 | I |<--------------R1--------------| R | 425 | |---------------I2------------->| | 426 | |<--------------R2--------------| | 427 +-----+ +-----+ 428 | ^ 429 | +------+ | 430 +-----I1----->| RVS2 |------I1------+ 431 +------+ 433 4. Overview of using the DNS with HIP 435 4.1. Storing HI and HIT in DNS 437 Any conforming implementation may store a Host Identity (HI) and its 438 associated Host Identity Tag (HIT) in a DNS HIPHI RDATA format. If a 439 particular form of an HI does not already have a specified RDATA 440 format, a new RDATA-like format SHOULD be defined for the HI. HI and 441 HIT are defined in Section 3 of [I-D.ietf-hip-base]. 443 4.1.1. HI and HIT Verification 445 Upon return of a HIPHI RR, a host MUST always calculate the HI- 446 derivative HIT to be used in the HIP exchange, as specified in 447 Section 3 of the HIP base specification [I-D.ietf-hip-base], while 448 the HIT possibly embedded along SHOULD only be used as an 449 optimization (e.g. table lookup). 451 4.2. Storing Rendezvous Servers in the DNS 453 The HIP rendezvous server (HIPRVS) resource record indicates an 454 address or a domain name of a rendezvous Server, towards which a HIP 455 I1 packet might be sent to trigger the establishment of an 456 association with the entity named by this resource record [I-D.ietf- 457 hip-rvs]. 459 An RVS receiving such an I1 would then relay it to the appropriate 460 responder (the owner of the I1 receiver HIT). The responder will 461 then complete the exchange with the initiator, typically without 462 ongoing help from the RVS. 464 Any conforming implementation may store rendezvous server's IP 465 address(es) or DNS name in a DNS HIPRVS RDATA format. If a 466 particular form of a RVS reference does not already have a specified 467 RDATA format, a new RDATA-like format SHOULD be defined for the RVS. 469 4.3. Initiating connections based on DNS names 471 On a HIP node, a Host Identity Protocol exchange SHOULD be initiated 472 whenever an Upper Layer Protocol attempt to communicate with an 473 entity and the DNS lookup returns HIPHI and/or HIPRVS resource 474 records. If a DNS lookup returns one or more HIPRVS RRs and no A nor 475 AAAA RRs, the afore mentioned HIP exchange SHOULD be initiated 476 towards one of these RVS [I-D.ietf-hip-base]. Since some hosts may 477 choose not to have HIPHI information in DNS, hosts MAY implement 478 support for opportunistic HIP. 480 5. Storage Format 482 5.1. HIPHI RDATA format 484 The RDATA for a HIPHI RR consists of a public key algorithm type, the 485 HIT length, a HIT, and a public key. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | PK algorithm | HIT length | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | 492 ~ ~ 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | / 495 / Public Key / 496 / / 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 499 The PK algorithm, HIT length, HIT and Public Key field are REQUIRED. 501 5.1.1. PK algorithm format 503 The PK algorithm field indicates the public key cryptographic 504 algorithm and the implied public key field format. This document 505 reuse the values defined for the 'algorithm type' of the IPSECKEY RR 506 [RFC4025] 'gateway type' field. 508 The presently defined values are given only informally: 510 1 A DSA key is present, in the format defined in RFC2536 511 [RFC2536]. 513 2 A RSA key is present, in the format defined in RFC3110 514 [RFC3110]. 516 5.1.2. HIT length format 518 The HIT length indicates the length in bytes of the HIT field. 520 5.1.3. HIT format 522 The HIT is stored, as a binary value, in network byte order. 524 5.1.4. Public key format 526 Both of the public key types defined in this document (RSA and DSA) 527 reuse the public key formats defined for the IPSECKEY RR [RFC4025] 528 (which in turns contains the algorithm-specific portion of the KEY RR 529 RDATA, all of the KEY RR DATA after the first four octets, 530 corresponding to the same portion of the KEY RR that must be 531 specified by documents that define a DNSSEC algorithm). 533 In the future, if a new algorithm is to be used both by IPSECKEY RR 534 and HIPHI RR, it would probably use the same public key encoding for 535 both RRs. Unless specified otherwise, the HIPHI public key field 536 would use the same public key format as the IPSECKEY RR RDATA for the 537 corresponding algorithm. 539 The DSA key format is defined in RFC2536 [RFC2536]. 541 The RSA key format is defined in RFC3110 [RFC3110] and the RSA key 542 size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] 543 specification. 545 5.2. HIPRVS RDATA format 547 The RDATA for a HIPRVS RR consists of a preference value, a 548 rendezvous server type and either one or more rendezvous server 549 address, or one rendezvous server domain name. 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | preference | type | | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ rendezvous server | 556 ~ ~ 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 The Preference and RVS Type fields are REQUIRED. At least one RVS 560 field MUST be present. 562 5.2.1. Preference format 564 This is an unsigned 8-bit value, used to specify the preference given 565 to the RVS in the HIPRVS RR amongst others at the same owner. RVSs 566 with lower values are preferred. If there is a tie within some RR 567 subset, the initiating HIP host should pick one of the RVS randomly 568 from the set of RRs, such that the requester load is fairly balanced 569 amongst all RVSs of the set. 571 5.2.2. Rendezvous server type format 573 The rendezvous server type indicates the format of the information 574 stored in the rendezvous server field. 576 This document reuses the type values for the 'gateway type' field of 577 the IPSECKEY RR [RFC4025]. The presently defined values are given 578 only informally: 580 1. One or more 4-byte IPv4 address(es) in network byte order are 581 present. 583 2. One or more 16-byte IPv6 address(es) in network byte order are 584 present. 586 3. One or more variable length wire-encoded domain names as 587 described in section 3.3 of RFC1035 [RFC1035]. The wire-encoded 588 format is self-describing, so the length is implicit. The domain 589 names MUST NOT be compressed. 591 5.2.3. Rendezvous server format 593 The rendezvous server field indicates one or more rendezvous 594 server(s) IP address(es), or domain name(s). A HIP I1 packet sent to 595 any of these RVS would reach the entity named by this resource 596 record. 598 This document reuses the format used for the 'gateway' field of the 599 IPSECKEY RR [RFC4025], but allows to concatenate several IP (v4 or 600 v6) addresses. The presently defined formats for the data portion of 601 the rendezvous server field are given only informally: 603 o One or more 32-bit IPv4 address(es) in network byte order. 605 o One or more 128-bit IPv6 address(es) in network byte order. 607 o One or more variable length wire-encoded domain names as described 608 in Section 3.3 of RFC1035 [RFC1035]. The wire-encoded format is 609 self-describing, so the length is implicit. The domain names MUST 610 NOT be compressed. 612 6. Presentation Format 614 This section specifies the representation of the HIPHI and HIPRVS RR 615 in a zone data master file. 617 6.1. HIPHI Representation 619 The PK algorithm field is represented as unsigned integers. 621 The HIT length field is not represented as it is implicitly known 622 thanks to the HIT field representation. 624 The HIT field is represented as the Base16 encoding [RFC3548] (a.k.a. 625 hex or hexadecimal) of the HIT. The encoding MUST NOT contains 626 whitespace(s). 628 The Public Key field is represented as the Base64 encoding [RFC3548] 629 of the public key. The encoding MAY contains whitespace(s), and such 630 whitespace(s) MUST be ignored. 632 The complete representation of the HPIHI record is: 634 IN HIPHI ( pk-algorithm 635 base16-encoded-hit 636 base64-encoded-public-key ) 638 6.2. HIPRVS Representation 640 The RVS field is represented by one or more: 642 o IPv4 dotted decimal address(es) 644 o IPv6 colon hex address(es) 646 o uncompressed domain name(s) 648 The complete representation of the HPIRVS record is: 650 IN HIPRVS ( preference rendezvous-server-type 651 rendezvous-server[1] 652 ... 653 rendezvous-server[n] ) 655 6.3. Examples 657 Example of a node with a HI and a HIT: 659 www.example.com IN HIPHI ( 2 2A20E0FF0FE8A52422D059FFFEA938A1 660 AB3NzaC1kc3MAAACBAOBhKn 661 TCPOuFBzZQX/N3O9dm9P9iv 662 UIMoId== ) 664 Example of a node with an IPv6 RVS: 666 www.example.com IN HIPRVS (10 2 2001:db8:200:1:20c:f1ff:feb:a533 ) 668 Example of a node with three IPv4 RVS: 670 www.example.com IN HIPRVS ( 10 1 192.0.1.2 192.0.2.2 192.0.3.2 ) 672 Example of a node with two named RVS: 674 www.example.com IN HIPRVS ( 10 3 rvs.uk.example.com 675 rvs.us.example.com ) 677 7. Retrieving Multiple HITs and IPs from the DNS 679 If a host receives multiple HITs in a response to a DNS query, those 680 HITs MUST be considered to denote a single service, and be 681 semantically equivalent from that point of view. When initiating a 682 base exchange with the denoted service, the host SHOULD be prepared 683 to accept any of HITs as the peer's identity. A host MAY implement 684 this by using the opportunistic mode (destination HIT null in I1), or 685 by sending multiple I1s, if needed. 687 In particular, if a host receives multiple HITs and multiple IP 688 addresses in response to a DNS query, the host cannot know how the 689 HITs are reachable at the listed IP addresses. The mapping may be 690 any, i.e., all HITs may be reachable at all of the listed IP 691 addresses, some of the HITs may be reachable at some of the IP 692 addresses, or there may even be one-to-one mapping between the HITs 693 and IP addresses. In general, the host cannot know the mapping and 694 MUST NOT expect any particular mapping. 696 It is RECOMMENDED that if a host receives multiple HITs, the host 697 SHOULD first try to initiate the base exchange by using the 698 opportunistic mode. If the returned HIT does not match with any of 699 the expected HITs, the host SHOULD retry by sending further I1s, one 700 at time, trying out all of the listed HITs. If the host receives an 701 R1 for any of the I1s, the host SHOULD continue to use the successful 702 IP address until an R1 with a listed HIT is received, or the host has 703 tried all HITs, and try the other IP addresses only after that. A 704 host MAY also send multiple I1s in parallel, but sending such I1s 705 MUST be rate limited to avoid flooding (as per Section 8.4.1 of 706 [I-D.ietf-hip-base]). 708 8. Security Considerations 710 Though the security considerations of the HIP DNS extensions still 711 need to be more investigated and documented, this section contains a 712 description of the known threats involved with the usage of the HIP 713 DNS extensions. 715 In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS 716 Extensions allows to provision two HIP nodes with the public keying 717 material (HI) of their peer. These HIs will be subsequently used in 718 a key exchange between the peers. Hence, the HIP DNS Extensions 719 introduce the same kind of threats that IPSECKEY does, plus threats 720 caused by the possibility given to a HIP node to initiate or accept a 721 HIP exchange using "opportunistic" or "unpublished initiator HI" 722 modes. 724 A HIP node SHOULD obtain both the HIPHI and HIPRVS RRs from a trusted 725 party trough a secure channel insuring proper data integrity of the 726 RRs. DNSSEC [RFC2065] provides such a secure channel. 728 In the absence of a proper secure channel, both parties are 729 vulnerable to MitM and DoS attacks, and unrelated parties might be 730 subject to DoS attacks as well. These threats are described in the 731 following sections. 733 8.1. Attacker tampering with an insecure HIPHI RR 735 The HIPHI RR contains public keying material in the form of the named 736 peer's public key (the HI) and its secure hash (the HIT). Both of 737 these are not sensitive to attacks where an adversary gains knowledge 738 of them. However, an attacker that is able to mount an active attack 739 on the DNS, i.e., tampers with this HIPHI RR (e.g. using DNS 740 spoofing) is able to mount Man-in-the-Middle attacks on the 741 cryptographic core of the eventual HIP exchange (responder's HIPHI 742 and HIPRVS rewritten by the attacker). 744 8.2. Attacker tampering with an insecure HIPRVS RR 746 The HIPRVS RR contains a destination IP address where the named peer 747 is reachable by an I1 (HIP Rendezvous Extensions IPSECKEY RR 748 [I-D.ietf-hip-rvs] ). Thus, an attacker able to tamper with this RR 749 is able to redirect I1 packets sent to the named peer to a chosen IP 750 address, for DoS or MitM attacks. Note that this kind of attacks is 751 not specific to HIP and exists independently to whether or not HIP 752 and the HIPRVS RR are used. Such an attacker might tamper with A and 753 AAAA RRs as well. 755 An attacker might obviously use these two attacks in conjunction: It 756 will replace the responder's HI and RVS IP address by its owns in a 757 spoofed DNS packet sent to the initiator HI, then redirect all 758 exchanged packets to him and mount a MitM on HIP. In this case HIP 759 won't provide confidentiality nor initiator HI protection from 760 eavesdroppers. 762 8.3. Opportunistic HIP 764 A HIP initiator may not be aware of its peer's HI, and/or its HIT 765 (e.g. because the DNS does not contains HIP material, or the resolver 766 isn't HIP-enabled), and attempt an opportunistic HIP exchange towards 767 its known IP address, filling the responder HIT field with zeros in 768 the I1 header. Such an initiator is vulnerable to a MitM attack 769 because it can't validate the HI and HIT contained in a replied R1. 770 Hence, an implementation MAY choose not to use opportunistic mode. 772 8.4. Unpublished Initiator HI 774 A HIP initiator may choose to use an unpublished HI, which is not 775 stored in the DNS by means of a HIPHI RR. A responder associating 776 with such an initiator knowingly risks a MitM attack because it 777 cannot validate the initiator's HI. Hence, an implementation MAY 778 choose not to use unpublished mode. 780 8.5. Hash and HITs Collisions 782 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 783 by HIP to generate a HIT from an HI) eventually become insecure, 784 because an exploit has been found in which an attacker with a 785 reasonable computation power breaks one of the security features of 786 the hash (e.g. its supposed collision resistance). This is why a HIP 787 end-node implementation SHOULD NOT authenticate its HIP peers based 788 solely on a HIT retrieved from DNS, but SHOULD rather use HI-based 789 authentication. 791 8.6. DNSSEC 793 In the absence of DNSSEC, the HIPHI and HIPRVS RRs are subject to the 794 threats described in RFC 3833 [RFC3833]. 796 9. IANA Considerations 798 IANA needs to allocate two new RR type code for HIPHI and HIPRVS from 799 the standard RR type space. 801 IANA does not need to open a new registry for the HIPHI RR type for 802 public key algorithms because the HIPHI RR reuse 'algorithms types' 803 defined for the IPSECKEY RR [RFC4025]. The presently defined numbers 804 are given here only informally: 806 0 is reserved 808 1 is RSA 810 2 is DSA 812 IANA does not need to open a new registry for the HIPRVS RR 813 rendezvous server type because the HIPHI RR reuse the 'gateway types' 814 defined for the IPSECKEY RR [RFC4025]. The presently defined numbers 815 are given here only informally: 817 0 is reserved 819 1 is IPv4 821 2 is IPv6 823 3 is a wire-encoded uncompressed domain name 825 10. Acknowledgments 827 As usual in the IETF, this document is the result of a collaboration 828 between many people. The authors would like to thanks the author 829 (Michael Richardson), contributors and reviewers of the IPSECKEY RR 830 [RFC4025] specification, which this document was framed after. The 831 authors would also like to thanks the following people, who have 832 provided thoughtful and helpful discussions and/or suggestions, that 833 have helped improving this document: Rob Austein, Hannu Flinck, Tom 834 Henderson, Olaf Kolkman, Miika Komu, Andrew McGregor, Erik Nordmark, 835 and Gabriel Montenegro. Some parts of this draft stem from 836 [I-D.ietf-hip-base]. 838 Julien Laganier is partly funded by Ambient Networks, a research 839 project supported by the European Commission under its Sixth 840 Framework Program. The views and conclusions contained herein are 841 those of the authors and should not be interpreted as necessarily 842 representing the official policies or endorsements, either expressed 843 or implied, of the Ambient Networks project or the European 844 Commission. 846 11. References 848 11.1. Normative references 850 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 851 STD 13, RFC 1034, November 1987. 853 [RFC1035] Mockapetris, P., "Domain names - implementation and 854 specification", STD 13, RFC 1035, November 1987. 856 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 857 Extensions", RFC 2065, January 1997. 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997. 862 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 863 (DNS)", RFC 2536, March 1999. 865 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 866 Name System (DNS)", RFC 3110, May 2001. 868 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 869 Hain, "Representing Internet Protocol version 6 (IPv6) 870 Addresses in the Domain Name System (DNS)", RFC 3363, 871 August 2002. 873 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 874 Encodings", RFC 3548, July 2003. 876 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 877 "DNS Extensions to Support IP Version 6", RFC 3596, 878 October 2003. 880 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 881 Material in DNS", RFC 4025, March 2005. 883 [I-D.ietf-hip-base] 884 Moskowitz, R., "Host Identity Protocol", 885 draft-ietf-hip-base-03 (work in progress), June 2005. 887 [I-D.ietf-hip-rvs] 888 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 889 Rendezvous Extension", draft-ietf-hip-rvs-04 (work in 890 progress), October 2005. 892 11.2. Informative references 894 [I-D.ietf-hip-arch] 895 Moskowitz, R. and P. Nikander, "Host Identity Protocol 896 Architecture", draft-ietf-hip-arch-03 (work in progress), 897 August 2005. 899 [I-D.ietf-hip-mm] 900 Nikander, P., "End-Host Mobility and Multihoming with the 901 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 902 progress), July 2005. 904 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 905 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 906 October 1998. 908 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 909 Name System (DNS)", RFC 3833, August 2004. 911 Authors' Addresses 913 Pekka Nikander 914 Ericsson Research Nomadic Lab 915 JORVAS FIN-02420 916 FINLAND 918 Phone: +358 9 299 1 919 Email: pekka.nikander@nomadiclab.com 921 Julien Laganier 922 DoCoMo Communications Laboratories Europe GmbH 923 Landsberger Strasse 312 924 Munich 80687 925 Germany 927 Phone: +49 89 56824 231 928 Email: julien.ietf@laposte.net 929 URI: http://www.docomolab-euro.com/ 931 Intellectual Property Statement 933 The IETF takes no position regarding the validity or scope of any 934 Intellectual Property Rights or other rights that might be claimed to 935 pertain to the implementation or use of the technology described in 936 this document or the extent to which any license under such rights 937 might or might not be available; nor does it represent that it has 938 made any independent effort to identify any such rights. Information 939 on the procedures with respect to rights in RFC documents can be 940 found in BCP 78 and BCP 79. 942 Copies of IPR disclosures made to the IETF Secretariat and any 943 assurances of licenses to be made available, or the result of an 944 attempt made to obtain a general license or permission for the use of 945 such proprietary rights by implementers or users of this 946 specification can be obtained from the IETF on-line IPR repository at 947 http://www.ietf.org/ipr. 949 The IETF invites any interested party to bring to its attention any 950 copyrights, patents or patent applications, or other proprietary 951 rights that may cover technology that may be required to implement 952 this standard. Please address the information to the IETF at 953 ietf-ipr@ietf.org. 955 Disclaimer of Validity 957 This document and the information contained herein are provided on an 958 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 959 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 960 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 961 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 962 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 963 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 965 Copyright Statement 967 Copyright (C) The Internet Society (2005). This document is subject 968 to the rights, licenses and restrictions contained in BCP 78, and 969 except as set forth therein, the authors retain all their rights. 971 Acknowledgment 973 Funding for the RFC Editor function is currently provided by the 974 Internet Society.