idnits 2.17.1 draft-ietf-hip-dns-00.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 829. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 20 instances of lines with control characters in the document. 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 18, 2004) is 7123 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: '4' is defined on line 644, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 650, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 657, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 685, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2673 (ref. '4') (Obsoleted by RFC 6891) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 3467 (ref. '7') == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '9') == Outdated reference: A later version (-03) exists of draft-ietf-hip-arch-00 ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. '10') == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '11') == Outdated reference: A later version (-05) exists of draft-ietf-hip-rvs-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '12') == Outdated reference: A later version (-12) exists of draft-ietf-ipseckey-rr-10 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '14') (Obsoleted by RFC 5226) Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Working Group P. Nikander 3 Internet-Draft Ericsson Research Nomadic Lab 4 Expires: April 18, 2005 J. Laganier 5 LIP / Sun Microsystems 6 October 18, 2004 8 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 9 draft-ietf-hip-dns-00 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 18, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document specifies two new resource records for the Domain Name 45 System (DNS), and how to use them with the Host Identity Protocol 46 (HIP). These records allow a HIP node to store in the DNS its Host 47 Identity (its public key), Host Identity Tag (a truncated hash of its 48 public key), and Rendezvous Servers (RVS). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions used in this document . . . . . . . . . . . . . . 5 54 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1 Simple static singly homed end-host . . . . . . . . . . . 7 56 3.2 Mobile end-host . . . . . . . . . . . . . . . . . . . . . 7 57 3.3 Multi-homed Site or End-host . . . . . . . . . . . . . . . 7 58 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 8 59 4.1 Different types of HITs . . . . . . . . . . . . . . . . . 8 60 4.1.1 Host Assigning Authority (HAA) field . . . . . . . . . 8 61 4.2 Storing HI and HIT in DNS . . . . . . . . . . . . . . . . 8 62 4.3 Storing HAA in DNS . . . . . . . . . . . . . . . . . . . . 8 63 4.4 Providing multiple IP addresses . . . . . . . . . . . . . 9 64 4.4.1 Storing Rendezvous Servers in the DNS . . . . . . . . 9 65 4.5 Initiating connections based on DNS names . . . . . . . . 9 66 4.6 HI and HIT verification . . . . . . . . . . . . . . . . . 9 67 5. Storage Format . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5.1 HIPHI RDATA format . . . . . . . . . . . . . . . . . . . . 10 69 5.1.1 HIT type format . . . . . . . . . . . . . . . . . . . 10 70 5.1.2 HIT algorithm format . . . . . . . . . . . . . . . . . 10 71 5.1.3 PK algorithm type format . . . . . . . . . . . . . . . 10 72 5.1.4 HIT format . . . . . . . . . . . . . . . . . . . . . . 11 73 5.1.5 Public key format . . . . . . . . . . . . . . . . . . 11 74 5.2 HIPRVS RDATA format . . . . . . . . . . . . . . . . . . . 11 75 5.2.1 Preference format . . . . . . . . . . . . . . . . . . 12 76 5.2.2 Rendezvous server type format . . . . . . . . . . . . 12 77 5.2.3 Rendezvous server format . . . . . . . . . . . . . . . 12 78 6. Transition mechanisms . . . . . . . . . . . . . . . . . . . . 14 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 7.1 Attacker tampering with an unsecure HIPHI RR . . . . . . . 15 81 7.2 Attacker tampering with an unsecure HIPRVS RR . . . . . . 15 82 7.3 Opportunistic HIP . . . . . . . . . . . . . . . . . . . . 16 83 7.4 Anonymous Initiator . . . . . . . . . . . . . . . . . . . 16 84 7.5 Hash and HITs Collisions . . . . . . . . . . . . . . . . . 16 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 10.1 Normative references . . . . . . . . . . . . . . . . . . . . 19 89 10.2 Informative references . . . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 91 A. Using multiple HIs with multiple IPs . . . . . . . . . . . . . 21 92 B. Document Revision History . . . . . . . . . . . . . . . . . . 23 93 Intellectual Property and Copyright Statements . . . . . . . . 24 95 1. Introduction 97 This document specifies two new resource records (RRs) for the Domain 98 Name System (DNS) [7], and how to use them with the Host Identity 99 Protocol (HIP) [9]. These records allow a HIP node to store in the 100 DNS its Host Identity (its public key), Host Identity Tag (a 101 truncated hash of its public key), and Rendezvous Servers (RVS) [12]. 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 [10] 106 defines a new third namespace, called the Host Identity Namespace. 107 This namespace is composed of Host Identifiers (HI) of HIP nodes. 108 The Host Identity Tag (HIT) is one representation of an HI. This 109 representation is obtained by taking the output of a secure hash 110 function applied to the HI, truncated to the IPv6 address size. HITs 111 are supposed to be used in the place of IP addresses in some ULPs and 112 applications. 114 The Host Identity Protocol [9] allows two HIP nodes to establish a 115 pair of unidirectional IPsec Security Association. These SAs are 116 bound to the HI instead of IP addresses. The proposed HIP 117 multi-homing mechanisms [11] allow a node to dynamically change its 118 set of underlying IP addresses while maintaining IPsec SA and 119 transport layer session survivability. The HIP rendezvous extensions 120 [12] proposal allows a HIP node to maintain HIP reachability while 121 not relying on dynamic DNS updates to make its peers aware of its 122 current location (the set of IP address(es)). 124 Although a HIP node can initiate HIP communication 125 "opportunistically" (without a priori knowledge of its peer's HI), 126 doing so exposes both endpoints to Man-in-the-Middle attacks on the 127 HIP handshake. Hence, there is a desire to gain knowledge of peers' 128 HI before applications and ULPs initiate communication. 130 Currently, most of the Internet applications that need to communicate 131 with a remote host first translate a domain name (often obtained via 132 user input) into one or more IP address(es). This step occurs prior 133 to communication with the remote host, and relies on a DNS lookup. 135 With HIP, IP addresses are expected to be used mostly for on-the-wire 136 communication between end hosts, while most ULPs and applications 137 uses HIs or HITs instead (ICMP might be an example of an ULP not 138 using them). Consequently, we need a means to translate a domain 139 name into an HI. Using the DNS for this translation is pretty 140 straightforward: We define a new HIPHI (HIP HI) resource record. 141 Upon query by an application or ULP for a FQDN -> IP lookup, the 142 resolver would then additionally perform an FQDN -> HI lookup, and 143 use it to construct the resulting HI -> IP mapping (which is internal 144 to the HIP layer). The HIP layer uses the HI -> IP mapping to 145 translate HIs and their local representations (HITs, IPv4 and 146 IPv6-compatible LSIs) into IP addresses and vice versa. 148 This draft introduces the following new DNS Resource Records: 149 - HIPHI, for storing Host Identifiers and Host Identity Tags 150 - HIPRVS, for storing rendezvous server information 152 2. Conventions used in this document 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC2119 [2]. 158 3. Use cases 160 In this section, we briefly introduce a number of use cases where the 161 DNS is useful with the Host Identity Protocol. 163 With HIP, most application and ULPs are unaware of the IP addresses 164 used to carry packets on the wire. Consequently, a HIP node could 165 take advantage of having multiple IP addresses for fail-over, 166 redundancy, mobility, or renumbering, in a manner which is 167 transparent to most ULPs and applications (because they are bound to 168 HIs, hence they are agnostic to these IP address changes). 170 In these situations, a node wishing to be reachable by reference to 171 its FQDN should store the following informations in the DNS: 173 o A set of IP address(es). 174 o A Host Identity (HI) and/or Host Identity Tag (HIT). 175 o An IP address or DNS name of its Rendezvous Server(s) (RVS). 177 When a HIP node wants to initiate a communication with another HIP 178 node, it first needs to perform a HIP base exchange to set-up a HIP 179 association towards its peer. Although such an exchange can be 180 initiated opportunistically, i.e., without a priori knowledge of the 181 responder's HI, by doing so both nodes knowingly risk 182 man-in-the-middle attacks on the HIP exchange. To prevent these 183 attacks, it is recommended that the initiator first obtain the HI of 184 the responder, and then initiate the exchange. This can be done, for 185 example, through manual configuration or DNS lookups. Hence, a new 186 HIPHI RR is introduced. 188 When a HIP node is frequently changing its IP address(es), the 189 dynamic DNS update latency may prevent it from publishing its new IP 190 address(es) in the DNS. For solving this problem, the HIP 191 architecture introduces Rendezvous Servers (RVS). A HIP host uses a 192 Rendezvous Server as a Rendezvous point, to maintain reachability 193 with possible HIP initiators. Such a HIP node would publish in the 194 DNS its RVS IP address or DNS name in a HIPRVS RR, while keeping its 195 RVS up-to-date with its current set of IP addresses. 197 Then, when some other node wants to initiate a HIP exchange with such 198 a responder, it retrieves the RVS IP address by looking up a HIPRVS 199 RR at the FQDN of the responder, and sends an I1 to this IP address. 200 The I1 will then be relayed by the RVS to the responder, which will 201 then complete the HIP exchange, either directly or via the RVS [12]. 203 Note that storing HIP RR information in the DNS at a FQDN which is 204 assigned to a non-HIP node might have ill effects on its reachability 205 by HIP nodes. 207 3.1 Simple static singly homed end-host 209 A HIP node having a single static network attachment, wishing to be 210 reachable by reference to its FQDN, would store in the DNS, in 211 addition to its IP address(es), its Host Identity (HI) in a HIPHI 212 resource record. 214 3.2 Mobile end-host 216 A mobile HIP node wishing to be reachable by reference to its FQDN 217 would store in the DNS, instead of its IP address(es), its HI in a 218 HIPHI RR, and the IP address(es) of its Rendezvous Server(s) in 219 HIPRVS resource record(s). The mobile HIP node also need to notify 220 its Rendezvous Servers of any change in its set of IP address(es). 222 A host wanting to reach this mobile host would then send an I1 to one 223 of its RVS. Following, the RVS will relay the I1 up to the mobile 224 node, which will complete the HIP exchange. 226 3.3 Multi-homed Site or End-host 228 A HIP node with several distinct network attachments is multi-homed. 229 A HIP node attached to a network with multiple ISPs is in a 230 multi-homed site will possibly have multiple prefixes and addresses. 231 Such HIP node might also be reachable via several distinct Rendezvous 232 Servers. In addition to its set of IP address(es), a multi-homed 233 end-host would store in the DNS its HI in a HIPHI RR, and possibly 234 the IP address(es) of its RVS(s) in HIPRVS RRs. 236 4. Overview of using the DNS with HIP 238 4.1 Different types of HITs 240 There are _currently_ two types of HITs. HITs of the first type 241 consists just of the least significant bits of the hash of the public 242 key. HITs of the second type consist of a binary prefix Host 243 Assigning Authority (HAA) field, and only the last bits come from a 244 hash of the Host Identity. This latter format for HIT is recommended 245 for 'well known' systems. It is possible to support a resolution 246 mechanism for these names in directories like DNS. 248 Note that the format how HITs are stored in the DNS may be different 249 form the format actually used in protocols, the HIP base exchange [9] 250 included. This is because the DNS RR explicitly contains the HIT 251 type and algorithm, while some protocols may prefer to use a prefix 252 to indicate the HIT type. The implementations are expected to use 253 the actual HI when comparing Host Identities. 255 4.1.1 Host Assigning Authority (HAA) field 257 The 64 bits of HAA supports two levels of delegation. The first is a 258 registered assigning authority (RAA). The second is a registered 259 identity (RI, commonly a company). The RAA is 24 bits with values 260 assign sequentially by ICANN. The RI is 40 bits, also assigned 261 sequentially but by the RAA. 263 As IPv6 "global site-local" addresses were proposed in the IPv6 WG to 264 replace IPv6 site-local address, it is questionable if HIP needs a 265 kind of "global site-local" HAA, which would be generated by a given 266 site by setting the RAA field to 0 while the RI field is filled by 267 either random or EUI-48 bits. 269 4.2 Storing HI and HIT in DNS 271 Any conforming implementation may store Host Identifiers in a DNS 272 HIPHI RDATA format. An implementation may also store a HIT along 273 with its associated HI. If a particular form of an HI or HIT does 274 not already have a specified RDATA format, a new RDATA-like format 275 SHOULD be defined for the HI or HIT. 277 4.3 Storing HAA in DNS 279 Any conforming implementation may store a site's Host Assigning 280 Authority in a DNS HIPHI RDATA format. A HAA MUST be stored 281 similarly to a Type 2 HIT, while the least significant bits are set 282 to 0. If a particular form of a HAA does not already have an 283 associated HIT specified RDATA format, a new RDATA-like format SHOULD 284 be defined for the HIT/HAA. 286 4.4 Providing multiple IP addresses 288 With HIP, ULPs doesn't see which IP address is indeed used to carry 289 packets on the wire. Consequently, a HIP node could take advantage 290 of having multiple IP addresses for ULPs and applications fail over, 291 redundancy, etc. This can be achieved either by storing multiple 292 addresses in the DNS, while these addresses might be those of 293 different IP interfaces or Rendezvous servers. 295 4.4.1 Storing Rendezvous Servers in the DNS 297 The HIP Rendezvous server (HIPRVS) resource record indicates an 298 address (or a FQDN resolvable into an address) towards which a HIP I1 299 packet might be sent to trigger the establishment of an association 300 with the entity named by this resource record. 302 An RVS receiving such an I1 would then forward it to the appropriate 303 responder (the owner of the destination HIT in this I1). The 304 responder will then complete the exchange with the initiator, 305 possibly without ongoing help from the RVS. 307 Any conforming implementation may store Rendezvous Server's IP 308 address(es) or DNS name in a DNS HIPRVS RDATA format. If a 309 particular form of a RVS reference does not already have a specified 310 RDATA format, a new RDATA-like format SHOULD be defined for the RVS. 312 4.5 Initiating connections based on DNS names 314 A Host Identity Protocol exchange SHOULD be initiated whenever the 315 DNS lookup returns HIPHI resource records. Furthermore, if the DNS 316 lookups also returns HIPRVS resource records, the addresses of these 317 RVS SHOULD be put in the destination IP addresses list while 318 initiating the afore mentioned HIP exchange. Since some hosts may 319 choose not to have HIPHI information in DNS, hosts MAY implement 320 support opportunistic HIP. 322 4.6 HI and HIT verification 324 Upon return of a HIPHI RR, a host MUST always calculate the 325 HI-derivative HIT to be used in the HIP exchange, as specified in the 326 HIP architecture [10], while the HIT possibly embedded along SHOULD 327 only be used as an optimization (e.g., table lookup). 329 5. Storage Format 331 5.1 HIPHI RDATA format 333 The RDATA for a HIPHI RR consists of a HIT type, an algorithm type, a 334 HIT, and a public key. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | HIT type | HIT algorithm | PK algorithm | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | 341 ~ ~ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | / 344 / Public Key / 345 / / 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 348 5.1.1 HIT type format 350 The HIT type field indicates the Host Identity Tag (HIT) type and the 351 implied HIT format. 353 The following values are defined: 355 0 No HIT is present. 356 1 A Type 1 HIT is present. 357 2 A Type 2 HIT is present. 358 3-6 Unassigned 359 7 A HAA is present. 361 5.1.2 HIT algorithm format 363 The HIT algorithm indicates the hash algorithm used to generate the 364 Host Identity Tag (HIT) from the HI. 366 The following values are defined: 368 0 Reserved. 369 1 SHA1 370 2-255 Unassigned 372 5.1.3 PK algorithm type format 374 The algorithm type indicates the public key cryptographic algorithm 375 and the implied public key field format. This document reuse the 376 values defined for the 'algorithm type' of the IPSECKEY RR [13] 377 'gateway type' field. 379 The presently defined values are given only informally: 381 0 No key is present. 382 1 A DSA key is present, in the format defined in RFC2536 [3]. 383 2 A RSA key is present, in the format defined in RFC3110 [5]. 385 5.1.4 HIT format 387 There's currently two types of HITs, and a single type of HAA. Both 388 of them have a variable length and are stored within a single 389 holding the bits of the HITs or HAA: 391 o A *Type 1* HIT: least significant bits of the hash (e.g., SHA1) of 392 the public key (Host Identity), which is possibly following in the 393 HIPHI RR. 394 o A *Type 2* HIT: binary prefix (HAA) concatenated with a the least 395 significant bits of the hash (e.g., SHA1) of the public key (Host 396 Identity), which is possibly following in the HIPHI RR. 397 o A HAA: binary prefix (HAA) concatenated with 0, up to the 398 associated HIT length. 400 5.1.5 Public key format 402 Both of the public key types defined in this document (RSA and DSA) 403 reuse the public key formats defined for the IPSECKEY RR [13] (which 404 in turns contains the algorithm-specific portion of the KEY RR RDATA, 405 all of the KEY RR DATA after the first four octets, corresponding to 406 the same portion of the KEY RR that must be specified by documents 407 that define a DNSSEC algorithm). 409 In the future, if a new algorithm is to be used both by IPSECKEY RR 410 and HIPHI RR, it would probably use the same public key encodings for 411 both RRs. Unless specified otherwise, the HIPHI public key field 412 would use the same public key format as the IPSECKEY RR RDATA for the 413 corresponding algorithm. 415 The DSA key format is defined in RFC2536 [3]. 417 The RSA key format is defined in RFC3110 [5]. 419 5.2 HIPRVS RDATA format 421 The RDATA for a HIPRVS RR consists of a preference value, a 422 Rendezvous server type and either one or more Rendezvous server 423 address, or one Rendezvous server FQDN. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | preference | type | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rendezvous server | 430 ~ ~ 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 5.2.1 Preference format 435 This is an 8-bit preference order for this record. This used to 436 specify the preference given to this RR amongst others at the same 437 owner. Lower values are preferred. If there is a tie with some RRs, 438 the server should return a set of RRs ordered in a load balancing 439 manner (e.g., round robin). 441 5.2.2 Rendezvous server type format 443 The Rendezvous server type indicates the format of the information 444 stored in the Rendezvous server field. 446 This document reuses the type values for the 'gateway type' field of 447 the IPSECKEY RR [13]. The presently defined values are given only 448 informally: 450 0 Reserved. 451 1 One or more 4-byte IPv4 address(es) in network byte order are 452 present. 453 2 One or more 16-byte IPv6 address(es) in network byte order are 454 present. 455 3 One or more variable length wire-encoded domain names as 456 described in section 3.3 of RFC1035 [1]. The wire-encoded format 457 is self-describing, so the length is implicit. The domain names 458 MUST NOT be compressed. 460 5.2.3 Rendezvous server format 462 The Rendezvous server field indicates one or more address(es) (or one 463 or more FQDN(s) resolvable into one or more address(es)) towards 464 which a HIP I1 packet might be send in order to reach the entity 465 named by this resource record. 467 This document reuses the format used for the 'gateway' field of the 468 IPSECKEY RR [13], but allows to concatenate several IP (v4 or v6) 469 addresses. The presently defined formats for the data portion of the 470 Rendezvous server field are given only informally: 472 o One or more 32-bit IPv4 address(es) in network byte order. 473 o One or more 128-bit IPv6 address(es) in network byte order. 474 o One or more variable length wire-encoded domain names as described 475 in section 3.3 of RFC1035 [1]. The wire-encoded format is 476 self-describing, so the length is implicit. The domain names MUST 477 NOT be compressed. 479 6. Transition mechanisms 481 During a transition period, instead of storing the HI or HIT in a 482 HIPHI RR, the HIT MAY be stored in an AAAA RR. If a HIT is stored in 483 an AAAA RR, it MUST be returned as the last item in the set of AAAA 484 RRs returned to avoid as most as possible conflicts with non-HIP IPv6 485 nodes. 487 During a transition period, similarly to what may happen with HITs, 488 the RVS's IP address might be stored in an A or AAAA RR instead of a 489 HIPRVS RR. If a RVS IP address is stored in an A or AAAA RR, it MUST 490 be returned as the last item in the set of returned RRs to avoid as 491 most as possible conflicts with non-HIP IPv6 nodes. 493 7. Security Considerations 495 Though the security considerations of the HIP DNS extensions still 496 need to be more investigated and documented, this section contains a 497 description of the known threats involved with the usage of the HIP 498 DNS extensions. 500 In a manner similar to the IPSECKEY RR [13], the HIP DNS Extensions 501 allows to provision two HIP nodes with the public keying material 502 (HI) of their peer. These HIs will be subsequently used in a key 503 exchange between the peers. Hence, the HIP DNS Extensions introduce 504 the same kind of threats that IPSECKEY does, plus threats caused by 505 the possibility of using unpublished initiator and opportunistic mode 506 in HIP. 508 A HIP node SHOULD obtain both the HIPHI and HIPRVS RRs from a trusted 509 party trough a secure channel insuring proper data integrity of the 510 RRs. This might be DNSSEC, or another secure channel to another 511 directory lookup service. 513 In the absence of a proper secure channel, both parties are 514 vulnerable to MitM and DoS attacks, and unrelated parties might be 515 subject to DoS attacks as well. These threats are described in the 516 following sections. 518 7.1 Attacker tampering with an unsecure HIPHI RR 520 The HIPHI RR contains public keying material in the form of the named 521 peer's public key (the HI) and its secure hash (the HIT). Both of 522 these are not sensitive to attacks where an adversary gains knowledge 523 of them. However, an attacker that is able to mount an active attack 524 on the DNS, i.e., tampers with this HIPHI RR (e.g., using DNS 525 spoofing) is able to mount Man-in-the-Middle attacks on the 526 cryptographic core of the eventual HIP exchange (responder's HIPHI 527 and HIPRVS rewritten by the attacker). 529 7.2 Attacker tampering with an unsecure HIPRVS RR 531 The HIPRVS RR contains a destination IP address where the named peer 532 is reachable by an I1 (HIP Rendezvous Extensions IPSECKEY RR [12] ). 533 Thus, an attacker able to tamper with this RRs is able to redirect I1 534 packets sent to the named peer to a chosen IP address, for DoS or 535 MitM attacks. Note that this kind of attacks are not specific to HIP 536 and exist independently to whether or not HIP and the HIPRVS RR are 537 used. Such an attacker might tamper with A and AAAA RRs as well. 539 An attacker might obviously use these two attacks in conjunction: It 540 will replace the responder's HI and RVS IP address by its owns in a 541 spoofed DNS packet sent to the initiator HI, then redirect all 542 exchanged packets through him and mount a MitM on HIP. In this case 543 HIP won't provide confidentiality nor initiator HI protection from 544 eavesdroppers. 546 7.3 Opportunistic HIP 548 A HIP initiator may not be aware of its peer's HI, and/or its HIT 549 (e.g., because the DNS does not contains HIP material, or the 550 resolver isn't HIP-enabled), and attempt an opportunistic HIP 551 exchange towards its known IP address, filling the responder HIT 552 field with zeros in the I1 header. Such an initiator is vulnerable 553 to a MitM attack because it can't validate the HI and HIT contained 554 in a replied R1. Hence, an implementation MAY choose not to use 555 opportunistic mode. 557 7.4 Anonymous Initiator 559 A HIP initiator may choose to use an unpublished HI, which is not 560 stored in the DNS by means of a HIPHI RR. A responder associating 561 with such an initiator knowingly risks a MitM attack because it 562 cannot validate the initiator's HI. Hence, an implementation MAY 563 choose not to use unpublished mode. 565 7.5 Hash and HITs Collisions 567 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 568 by HIP to generate a HIT from an HI) eventually become insecure, 569 because an exploit has been found in which an attacker with a 570 reasonable computation power breaks one of the security features of 571 the hash (e.g., its supposed collision resistance). This is why a 572 HIP end-node implementation SHOULD NOT authenticate its HIP peers 573 based solely on a HIT retrieved from DNS, but rather use both the HI 574 and HIT. 576 8. IANA Considerations 578 IANA needs to allocate two new RR type code for HIPHI and HIPRVS from 579 the standard RR type space. 581 IANA does not need to open a new registry for the HIPHI RR type for 582 public key algorithms because the HIPHI RR reuse 'algorithms types' 583 defined for the IPSECKEY RR [13]. The presently defined numbers are 584 given here only informally: 586 0 is reserved 587 1 is RSA 588 2 is DSA 590 IANA needs to open a new registry for the HIPHI RR HIT type. Defined 591 types are: 593 0 No HIT is present 594 1 A Type 1 HIT is present 595 2 A Type 2 HIT is present 596 3-6 Unassigned 597 7 A HAA is present 599 Adding new reservations requires IETF consensus RFC2434 [14]. 601 IANA needs to open a new registry for the HIPHI RR HIT algorithm 602 type. Defined types are: 604 0 Reserved 605 1 SHA1 606 2-255 Unassigned 608 Adding new reservations requires IETF consensus RFC2434 [14]. 610 IANA does not need to open a new registry for the HIPRVS RR 611 Rendezvous server type because the HIPHI RR reuse the 'gateway types' 612 defined for the IPSECKEY RR [13]. The presently defined numbers are 613 given here only informally: 615 0 is reserved 616 1 is IPv4 617 2 is IPv6 618 3 is a wire-encoded uncompressed domain name 620 9. Acknowledgments 622 Some parts of this draft stem from [9]. This work is heavily 623 influenced by [13], which serves as a model for this document. 625 The authors would like to thanks the following people, who have 626 provided thoughtful and helpful discussions and/or suggestions, that 627 have improved this document: Rob Austein, Hannu Flinck, Tom 628 Henderson, Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel 629 Montenegro. 631 10. References 633 10.1 Normative references 635 [1] Mockapetris, P., "Domain names - implementation and 636 specification", STD 13, RFC 1035, November 1987. 638 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 639 Levels", BCP 14, RFC 2119, March 1997. 641 [3] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 642 (DNS)", RFC 2536, March 1999. 644 [4] Crawford, M., "Binary Labels in the Domain Name System", RFC 645 2673, August 1999. 647 [5] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 648 System (DNS)", RFC 3110, May 2001. 650 [6] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, 651 "Representing Internet Protocol version 6 (IPv6) Addresses in 652 the Domain Name System (DNS)", RFC 3363, August 2002. 654 [7] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 655 February 2003. 657 [8] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 658 Extensions to Support IP Version 6", RFC 3596, October 2003. 660 [9] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 661 Protocol", draft-ietf-hip-base-01 (work in progress), October 662 2004. 664 [10] Moskowitz, R. and P. Nikander, "Host Identity Protocol 665 Architecture", draft-ietf-hip-arch-00 (work in progress), 666 October 2004. 668 [11] Nikander, P., "End-Host Mobility and Multi-Homing with Host 669 Identity Protocol", draft-ietf-hip-mm-00 (work in progress), 670 October 2004. 672 [12] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 673 Rendezvous Extensions", draft-ietf-hip-rvs-00 (work in 674 progress), October 2004. 676 [13] Richardson, M., "A method for storing IPsec keying material in 677 DNS", draft-ietf-ipseckey-rr-10 (work in progress), April 2004. 679 10.2 Informative references 681 [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 682 Considerations Section in RFCs", BCP 26, RFC 2434, October 683 1998. 685 [15] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 686 Security Considerations", BCP 72, RFC 3552, July 2003. 688 Authors' Addresses 690 Pekka Nikander 691 Ericsson Research Nomadic Lab 692 JORVAS FIN-02420 693 FINLAND 695 Phone: +358 9 299 1 696 EMail: pekka.nikander@nomadiclab.com 698 Julien Laganier 699 LIP (CNRS-INRIA-ENSL-UCBL) & Sun Labs (Sun Microsystems) 700 180, Avenue de l'Europe 701 Saint Ismier CEDEX 38334 702 France 704 Phone: +33 476 188 815 705 EMail: ju@sun.com 707 Appendix A. Using multiple HIs with multiple IPs 709 The RRs defined in this document are "flat", in the sense that the IP 710 addresses and HIs are associated to an FQDN on an equality basis. In 711 the case where an FQDN is resolved into multiple HIs (HIPHI RRs) and 712 IP addresses (A, AAAA or HIPRVS RRs), the requester cannot associate 713 an IP address with a specific HI, nor the opposite. 715 Considering the following DNS-IP load balancing model: Multiple 716 initiators are querying a DNS server with A or AAAA RRs at a given 717 FQDN. The DNS server replies with a round-robin ordered set of IP 718 addresses, causing each initiator to connect to a different address 719 (the first address of the set they received from the DNS). This 720 model can be extended to HIP by having the DNS returning a 721 round-robin ordered set of HIs and IP addresses. But then the 722 problem is that the initiator would need to map each of these HIs to 723 a subset of the returned set of IP addresses. Hence, perhaps there 724 is a need for having a "hierarchical" model for these RRs, which will 725 allows to tie an HI to a specific subset of IP addresses, as 726 illustrated in the figure below: 728 FQDN 729 | 730 +---+---+ 731 | | 732 V V 733 FQDN HI1,HI2 HI3 734 | | | 735 +---+---+---+---+---+ +-+-+ | 736 | | | | | | | | | 737 V V V V V V V V V 738 IP1 IP2 IP3 HI1 HI2 HI3 IP1 IP2 IP3 740 'Flat' DNS model Vs. 'Hierarchical' HI model 742 However, as HIs and Type 1 HITs are not yet resolvable using the DNS, 743 implementing such a model would certainly prove to be difficult. The 744 use of Distributed Hash Tables (DHTs) might help to resolve HIs, but 745 at this point the whole story isn't known. In the absence of HI 746 resolvability, there is two solutions: index IP addresses and 747 HIs/HITs used by HIP with a common key (e.g., the IP address, the 748 HIT, a 8-bit int, etc.), or use a per-HI DNS name, pointed to by the 749 FQDN global to the set of HIs, and pointing to the HIs, and IP 750 addresses associated with this particular set of HIs. to map to 751 specific HIs, in a manner similar to what is done with NS RRs. 753 In the first solution (indexing), each HIPHI, HIPRVS, and HIPLOC (a 754 new to-be-defined RR carrying the IP address of a HIP node, to be 755 used by HIP instead of A and AAAA RRs, if present) would contain an 756 additional HI index field allowing to link an HI with a subset of IP 757 addresses and vice versa. This solution is neither space-efficient, 758 nor it is architecturally clean. 760 In the second solution (parallel DNS names and bindings), the PTR RR 761 is used to alias the name of a group of node into multiple FQDNs, 762 which are then bound to set of HIs and IP addresses, as shown in the 763 figure below. These additional FQDNs are kind of HIP sub-FQDNs; an 764 easy way to generate them is to suffix, or prefix the unqualified 765 name with a sufficient number of bits of the HIT to prevent 766 collisions local to a FQDN (e.g., foo.bar.com might haves multiple 767 HIP sub-FQDNs: foo_2fa6.bar.com, foo_8cc4.bar.com, etc.). 769 FQDN 770 | 771 +---+---+ 772 | | 773 V V 774 FQDN_1<--FQDN-->FQDN_2 HI1,HI2 HI3 775 | | | | 776 +---+---+---+ +-+-+ +-+-+ | 777 | | | | | | | | | 778 V V V V V V V V V 779 HI1 HI2 IP1 IP2 HI3 IP3 IP1 IP2 IP3 781 The 'Hierarchical' HIP model fitting in a 'Flat' DNS model 783 The current plan is to use the second solution unless HIP WG members 784 express desire to have the first solution implemented. 786 Appendix B. Document Revision History 788 +-----------+-------------------------------------------------------+ 789 | Revision | Comments | 790 +-----------+-------------------------------------------------------+ 791 | 00 | Compared to draft-nikander-hip-dns-00: Merge | 792 | | multihomed site and end-host use cases. Remove HAA | 793 | | related text not required for Type 2 HIT definition. | 794 | | Remove IPv6 LSIs definitions. Replace fixed length | 795 | | and algorithm Type 1 and Type 2 HITs by variable | 796 | | length, type and algorithm HITs. Remove 'Policy | 797 | | Considerations' section. Fill-in 'Security | 798 | | Considerations' section. Allow for several IP | 799 | | addresses in the same HIPRVS RR. Reuse the type | 800 | | values and IANA registries of IPSECKEY RR. Add Annex | 801 | | discussing alternatives for storing multiple | 802 | | parallels FQDN-to-HI and HI-to-IP at a single FQDN. | 803 | | Minor fixes to figures and their descriptive text. | 804 | | Update references. | 805 +-----------+-------------------------------------------------------+ 807 Intellectual Property Statement 809 The IETF takes no position regarding the validity or scope of any 810 Intellectual Property Rights or other rights that might be claimed to 811 pertain to the implementation or use of the technology described in 812 this document or the extent to which any license under such rights 813 might or might not be available; nor does it represent that it has 814 made any independent effort to identify any such rights. Information 815 on the procedures with respect to rights in RFC documents can be 816 found in BCP 78 and BCP 79. 818 Copies of IPR disclosures made to the IETF Secretariat and any 819 assurances of licenses to be made available, or the result of an 820 attempt made to obtain a general license or permission for the use of 821 such proprietary rights by implementers or users of this 822 specification can be obtained from the IETF on-line IPR repository at 823 http://www.ietf.org/ipr. 825 The IETF invites any interested party to bring to its attention any 826 copyrights, patents or patent applications, or other proprietary 827 rights that may cover technology that may be required to implement 828 this standard. Please address the information to the IETF at 829 ietf-ipr@ietf.org. 831 Disclaimer of Validity 833 This document and the information contained herein are provided on an 834 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 835 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 836 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 837 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 838 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 839 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 841 Copyright Statement 843 Copyright (C) The Internet Society (2004). This document is subject 844 to the rights, licenses and restrictions contained in BCP 78, and 845 except as set forth therein, the authors retain all their rights. 847 Acknowledgment 849 Funding for the RFC Editor function is currently provided by the 850 Internet Society.