idnits 2.17.1 draft-ietf-hip-dns-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 940. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 16 characters in excess of 72. 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 (February 20, 2005) is 7005 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 846, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 853, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 878, 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-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. '10') == 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. '11') == 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. '12') == 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. '13') -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '16') (Obsoleted by RFC 5226) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HIP Working Group P. Nikander 2 Internet-Draft Ericsson Research Nomadic Lab 3 Expires: August 21, 2005 J. Laganier 4 LIP / Sun Microsystems 5 February 20, 2005 7 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions 8 draft-ietf-hip-dns-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 21, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document specifies two new resource records (RRs) for the Domain 44 Name System (DNS), and how to use them with the Host Identity 45 Protocol (HIP). These RRs allow a HIP node to store in the DNS its 46 Host Identity (HI, the public component of the node public-private 47 key pair), Host Identity Tag (HIT, a truncated hash of its public 48 key), and the Domain Name or IP addresses of its Rendezvous Servers 49 (RVS). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . 5 55 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1 Simple static singly homed end-host . . . . . . . . . . . 7 57 3.2 Mobile end-host . . . . . . . . . . . . . . . . . . . . . 8 58 3.3 Mixed Scenario . . . . . . . . . . . . . . . . . . . . . . 9 59 4. Overview of using the DNS with HIP . . . . . . . . . . . . . . 10 60 4.1 Storing HI and HIT in DNS . . . . . . . . . . . . . . . . 10 61 4.1.1 Different types of HITs . . . . . . . . . . . . . . . 10 62 4.2 Storing Rendezvous Servers in the DNS . . . . . . . . . . 11 63 4.3 Initiating connections based on DNS names . . . . . . . . 11 64 5. Storage Format . . . . . . . . . . . . . . . . . . . . . . . . 12 65 5.1 HIPHI RDATA format . . . . . . . . . . . . . . . . . . . . 12 66 5.1.1 HIT type format . . . . . . . . . . . . . . . . . . . 12 67 5.1.2 HIT algorithm format . . . . . . . . . . . . . . . . . 12 68 5.1.3 PK algorithm format . . . . . . . . . . . . . . . . . 12 69 5.1.4 HIT format . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1.5 Public key format . . . . . . . . . . . . . . . . . . 13 71 5.2 HIPRVS RDATA format . . . . . . . . . . . . . . . . . . . 13 72 5.2.1 Preference format . . . . . . . . . . . . . . . . . . 14 73 5.2.2 Rendezvous server type format . . . . . . . . . . . . 14 74 5.2.3 Rendezvous server format . . . . . . . . . . . . . . . 14 75 6. Presentation Format . . . . . . . . . . . . . . . . . . . . . 16 76 6.1 HIPHI Representation . . . . . . . . . . . . . . . . . . . 16 77 6.2 HIPRVS Representation . . . . . . . . . . . . . . . . . . 16 78 6.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 7. Retrieving Multiple HITs and IPs from the DNS . . . . . . . . 18 80 8. Transition mechanisms . . . . . . . . . . . . . . . . . . . . 19 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 82 9.1 Attacker tampering with an unsecure HIPHI RR . . . . . . . 20 83 9.2 Attacker tampering with an unsecure HIPRVS RR . . . . . . 20 84 9.3 Opportunistic HIP . . . . . . . . . . . . . . . . . . . . 21 85 9.4 Unpublished Initiator HI . . . . . . . . . . . . . . . . . 21 86 9.5 Hash and HITs Collisions . . . . . . . . . . . . . . . . . 21 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 88 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 12.1 Normative references . . . . . . . . . . . . . . . . . . . . 24 91 12.2 Informative references . . . . . . . . . . . . . . . . . . . 25 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 93 A. Document Revision History . . . . . . . . . . . . . . . . . . 26 94 Intellectual Property and Copyright Statements . . . . . . . . 27 96 1. Introduction 98 This document specifies two new resource records (RRs) for the Domain 99 Name System (DNS) [1], and how to use them with the Host Identity 100 Protocol (HIP) [10]. These RRs allow a HIP node to store in the DNS 101 its Host Identity (HI, the public component of the node 102 public-private key pair), Host Identity Tag (HIT, a truncated hash of 103 its HI), and the Domain Name or IP addresses of its Rendezvous 104 Servers (RVS) [13]. 106 The current Internet architecture defines two global namespaces: IP 107 addresses and domain names. The Domain Name System provides a two 108 way lookup between these two namespaces. The HIP architecture [11] 109 defines a new third namespace, called the Host Identity Namespace. 110 This namespace is composed of Host Identifiers (HI) of HIP nodes. 111 The Host Identity Tag (HIT) is one representation of an HI. This 112 representation is obtained by taking the output of a secure hash 113 function applied to the HI, truncated to the IPv6 address size. HITs 114 are supposed to be used in the place of IP addresses within most ULPs 115 and applications. 117 +-----+ +-----+ 118 | |-------I1------>| | 119 | I |<------R1-------| R | 120 | |-------I2------>| | 121 | |<------R2-------| | 122 +-----+ +-----+ 124 The Host Identity Protocol [10] allows two HIP nodes to establish 125 together a HIP Association. A HIP association is bound to the nodes 126 HIs rather than to their IP address(es). 128 Although a HIP node can initiate HIP communication 129 "opportunistically", i.e., without a priori knowledge of its peer's 130 HI, doing so exposes both endpoints to Man-in-the-Middle attacks on 131 the HIP handshake and its cryptographic protocol. Hence, there is a 132 desire to gain knowledge of peers' HI before applications and ULPs 133 initiate communication. Because many applications use the Domain 134 Name System [1] to name nodes, DNSSEC [3] is a straightforward way to 135 provision nodes with the HIP informations (i.e. HI and possibly RVS) 136 of nodes named in the DNS tree, without introducing or relying on an 137 additional piece of infrastructure. 139 +-----+ 140 +--I1--->| RVS |---I1--+ 141 | +-----+ | 142 | v 143 +-----+ +-----+ 144 | |<------R1-------| | 145 | I |-------I2------>| R | 146 | |<------R2-------| | 147 +-----+ +-----+ 149 The proposed HIP multi-homing mechanisms [12] allow a node to 150 dynamically change its set of underlying IP addresses while 151 maintaining IPsec SA and transport layer session survivability. The 152 HIP rendezvous extensions [13] proposal allows a HIP node to maintain 153 HIP reachability while it is changing its current location (the node 154 IP address(es)). This rendezvous service is provided by a third 155 party, the node's Rendezvous Server (RVS). An initiator (I) willing 156 to establish a HIP association with a responder (R) would typically 157 initiate a HIP exchange by sending an I1 towards the RVS IP address 158 rather than towards the responder IP address. Then, the RVS, 159 noticing that the receiver HIT is not its own, but the HIT of a HIP 160 node registered for the rendezvous Service, would relay the I1 to the 161 responder. Typically the responder would then complete the exchange 162 without further assistance from the RVS by sending an R1 directly to 163 the initiator IP address. 165 Currently, most of the Internet applications that need to communicate 166 with a remote host first translate a domain name (often obtained via 167 user input) into one or more IP address(es). This step occurs prior 168 to communication with the remote host, and relies on a DNS lookup. 170 With HIP, IP addresses are expected to be used mostly for on-the-wire 171 communication between end hosts, while most ULPs and applications 172 uses HIs or HITs instead (ICMP might be an example of an ULP not 173 using them). Consequently, we need a means to translate a domain 174 name into an HI. Using the DNS for this translation is pretty 175 straightforward: We define a new HIPHI (HIP HI) resource record. 176 Upon query by an application or ULP for a FQDN -> IP lookup, the 177 resolver would then additionally perform an FQDN -> HI lookup, and 178 use it to construct the resulting HI -> IP mapping (which is internal 179 to the HIP layer). The HIP layer uses the HI -> IP mapping to 180 translate HIs and their local representations (HITs, IPv4 and 181 IPv6-compatible LSIs) into IP addresses and vice versa. 183 This draft introduces the following new DNS Resource Records: 184 - HIPHI, for storing Host Identifiers and Host Identity Tags 185 - HIPRVS, for storing rendezvous server information 187 2. Conventions used in this document 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC2119 [4]. 193 3. Usage Scenarios 195 In this section, we briefly introduce a number of usage scenarios 196 where the DNS is useful with the Host Identity Protocol. 198 With HIP, most application and ULPs are unaware of the IP addresses 199 used to carry packets on the wire. Consequently, a HIP node could 200 take advantage of having multiple IP addresses for fail-over, 201 redundancy, mobility, or renumbering, in a manner which is 202 transparent to most ULPs and applications (because they are bound to 203 HIs, hence they are agnostic to these IP address changes). 205 In these situations, a node wishing to be reachable by reference to 206 its FQDN should store the following informations in the DNS: 208 o A set of IP address(es). 209 o A Host Identity (HI) and/or Host Identity Tag (HIT). 210 o An IP address or DNS name of its Rendezvous Server(s) (RVS). 212 When a HIP node wants to initiate a communication with another HIP 213 node, it first needs to perform a HIP base exchange to set-up a HIP 214 association towards its peer. Although such an exchange can be 215 initiated opportunistically, i.e., without a priori knowledge of the 216 responder's HI, by doing so both nodes knowingly risk 217 man-in-the-middle attacks on the HIP exchange. To prevent these 218 attacks, it is recommended that the initiator first obtain the HI of 219 the responder, and then initiate the exchange. This can be done, for 220 example, through manual configuration or DNS lookups. Hence, a new 221 HIPHI RR is introduced. 223 When a HIP node is frequently changing its IP address(es), the 224 dynamic DNS update latency may prevent it from publishing its new IP 225 address(es) in the DNS. For solving this problem, the HIP 226 architecture introduces Rendezvous Servers (RVS). A HIP host uses a 227 Rendezvous Server as a Rendezvous point, to maintain reachability 228 with possible HIP initiators. Such a HIP node would publish in the 229 DNS its RVS IP address or DNS name in a HIPRVS RR, while keeping its 230 RVS up-to-date with its current set of IP addresses. 232 Then, when some other node wants to initiate a HIP exchange with such 233 a responder, it retrieves the RVS IP address by looking up a HIPRVS 234 RR at the FQDN of the responder, and sends an I1 to this IP address. 235 The I1 will then be relayed by the RVS to the responder, which will 236 then complete the HIP exchange, either directly or via the RVS [13]. 238 Note that storing HIP RR information in the DNS at a FQDN which is 239 assigned to a non-HIP node might have ill effects on its reachability 240 by HIP nodes. 242 3.1 Simple static singly homed end-host 244 [A? HIPRVS? HIPHI?] 245 [www.example.com ] +-----+ 246 +-------------------------------->| | 247 | | DNS | 248 | +-------------------------------| | 249 | | [A? HIPRVS? HIPHI? ] +-----+ 250 | | [www.example.com ] 251 | | [A IP-R ] 252 | | [HIPHI 10 3 2 HIT-R HI-R] 253 | v 254 +-----+ +-----+ 255 | |--------------I1------------->| | 256 | I |<-------------R1--------------| R | 257 | |--------------I2------------->| | 258 | |<-------------R2--------------| | 259 +-----+ +-----+ 261 A HIP node (R) with a single static network attachment, wishing to be 262 reachable by reference to its FQDN (www.example.com), would store in 263 the DNS, in addition to its IP address(es) (IP-R), its Host Identity 264 (HI-R) in a HIPHI resource record. 266 3.2 Mobile end-host 268 [A? HIPRVS? HIPHI?] 269 [www.example.com ] +-----+ 270 +--------------------------------->| | 271 | | DNS | 272 | +--------------------------------| | 273 | | [A? HIPRVS? HIPHI? ] +-----+ 274 | | [www.example.com ] 275 | | [HIPRVS 1 2 IP-RVS ] 276 | | [HIPHI 10 3 2 HIT-R HI-R] 277 | | 278 | | +-----+ 279 | | +------I1----->| RVS |-----I1------+ 280 | | | +-----+ | 281 | | | | 282 | | | | 283 | v | v 284 +-----+ +-----+ 285 | |<---------------R1------------| | 286 | I |----------------I2----------->| R | 287 | |<---------------R2------------| | 288 +-----+ +-----+ 290 A mobile HIP node (R) wishing to be reachable by reference to its 291 FQDN (www.example.com) would store in the DNS, possibly in addition 292 to its IP address(es) (IP-R), its HI (HI-R) in a HIPHI RR, and the IP 293 address(es) of its Rendezvous Server(s) (IP-RVS) in HIPRVS resource 294 record(s). The mobile HIP node also need to notify its Rendezvous 295 Servers of any change in its set of IP address(es). 297 A host wanting to reach this mobile host would then send an I1 to one 298 of its RVS. Following, the RVS will relay the I1 up to the mobile 299 node, which will complete the HIP exchange. 301 3.3 Mixed Scenario 303 [A? HIPRVS? HIPHI?] 304 [www.example.com ] +-----+ 305 +--------------------------------->| | 306 | | DNS | 307 | +--------------------------------| | 308 | | [A? HIPRVS? HIPHI? ] +-----+ 309 | | [www.example.com ] 310 | | [A IP-R1 ] 311 | | [A IP-R2 ] 312 | | [HIPRVS 1 2 IP-RVS1 ] 313 | | [HIPRVS 1 2 IP-RVS2 ] 314 | | [HIPHI 10 3 2 HIT-R HI-R] 315 | | 316 | | +------+ 317 | | +-----I1----->| RVS1 |------I1------+ 318 | | | +------+ | 319 | v | v 320 +-----+ +-----+ 321 | |---------------I1------------->| | 322 | | | | 323 | I |<--------------R1--------------| R | 324 | |---------------I2------------->| | 325 | |<--------------R2--------------| | 326 +-----+ +-----+ 327 | ^ 328 | +------+ | 329 +-----I1----->| RVS2 |------I1------+ 330 +------+ 332 A HIP node might be configured with more than one IP address 333 (multi-homed), or Rendezvous Server (multi-reachable). In these 334 cases, it is possible that the DNS returns multiples A or AAAA RRs, 335 as well as HIPRVS containing one or multiple Rendezvous Servers. In 336 addition to its set of IP address(es) (IP-R1, IP-R2), a multi-homed 337 end-host would store in the DNS its HI (HI-R) in a HIPHI RR, and 338 possibly the IP address(es) of its RVS(s) (IP-RVS1, IP-RVS2) in 339 HIPRVS RRs. 341 4. Overview of using the DNS with HIP 343 4.1 Storing HI and HIT in DNS 345 Any conforming implementation may store Host Identifiers in a DNS 346 HIPHI RDATA format. An implementation may also store a HIT along 347 with its associated HI. If a particular form of an HI or HIT does 348 not already have a specified RDATA format, a new RDATA-like format 349 SHOULD be defined for the HI or HIT. 351 4.1.1 Different types of HITs 353 There are _currently_ two types of HITs. HITs of the first type 354 consists just of the least significant bits of the hash of the public 355 key. HITs of the second type consist of a binary prefix Host 356 Assigning Authority (HAA) field, and only the last bits come from a 357 hash of the Host Identity. This latter format for HIT is recommended 358 for 'well known' systems. It is possible to support a resolution 359 mechanism for these names in directories like DNS. 361 Note that the format how HITs are stored in the DNS may be different 362 form the format actually used in protocols, the HIP base exchange 363 [10] included. This is because the DNS RR explicitly contains the 364 HIT type and algorithm, while some protocols may prefer to use a 365 prefix to indicate the HIT type. The implementations are expected to 366 use the actual HI when comparing Host Identities. 368 4.1.1.1 Host Assigning Authority (HAA) field 370 The 64 bits of HAA supports two levels of delegation. The first is a 371 registered assigning authority (RAA). The second is a registered 372 identity (RI, commonly a company). The RAA is 24 bits with values 373 assign sequentially by ICANN. The RI is 40 bits, also assigned 374 sequentially but by the RAA. 376 4.1.1.2 Storing HAA in DNS 378 Any conforming implementation may store a domain name Host Assigning 379 Authority (HAA) in a DNS HIPHI RDATA format. A HAA MUST be stored 380 like a Type 2 HIT, while the least significant bits of the HIT 381 extracted from the HI hash output are set to zero, the Host Identity 382 Length is set zero, and the Host Identity field is omitted. If a 383 particular form of a HAA does not already have an associated HIT 384 specified RDATA format, a new RDATA-like format SHOULD be defined for 385 the HIT/HAA. 387 4.1.1.3 HI and HIT verification 389 Upon return of a HIPHI RR, a host MUST always calculate the 390 HI-derivative HIT to be used in the HIP exchange, as specified in the 391 HIP architecture [11], while the HIT possibly embedded along SHOULD 392 only be used as an optimization (e.g. table lookup). 394 4.2 Storing Rendezvous Servers in the DNS 396 The HIP Rendezvous server (HIPRVS) resource record indicates an 397 address or a domain name of a RendezVous Server, towards which a HIP 398 I1 packet might be sent to trigger the establishment of an 399 association with the entity named by this resource record [13]. 401 An RVS receiving such an I1 would then relay it to the appropriate 402 responder (the owner of the I1 receiver HIT). The responder will 403 then complete the exchange with the initiator, typically without 404 ongoing help from the RVS. 406 Any conforming implementation may store Rendezvous Server's IP 407 address(es) or DNS name in a DNS HIPRVS RDATA format. If a 408 particular form of a RVS reference does not already have a specified 409 RDATA format, a new RDATA-like format SHOULD be defined for the RVS. 411 4.3 Initiating connections based on DNS names 413 On a HIP node, a Host Identity Protocol exchange SHOULD be initiated 414 whenever an Upper Layer Protocol attempt to communicate with an 415 entity and the DNS lookup returns HIPHI and/or HIPRVS resource 416 records. If a DNS lookup returns one or more HIPRVS RRs and no A nor 417 AAAA RRs, the afore mentioned HIP exchange SHOULD be initiated 418 towards one of these RVS [10]. Since some hosts may choose not to 419 have HIPHI information in DNS, hosts MAY implement support for 420 opportunistic HIP. 422 5. Storage Format 424 5.1 HIPHI RDATA format 426 The RDATA for a HIPHI RR consists of a HIT type, an algorithm type, a 427 HIT, and a public key. 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | HIT type | HIT algorithm | PK algorithm | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HIT | 434 ~ ~ 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | / 437 / Public Key / 438 / / 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 441 5.1.1 HIT type format 443 The HIT type field indicates the Host Identity Tag (HIT) type and the 444 implied HIT format. 446 The following values are defined: 448 0 No HIT is present 449 1 A Type 1 HIT is present 450 2 A Type 2 HIT is present 451 3-6 Unassigned 452 7 A HAA is present 454 5.1.2 HIT algorithm format 456 The HIT algorithm indicates the hash algorithm used to generate the 457 Host Identity Tag (HIT) from the HI. 459 The following values are defined: 461 0 Reserved 462 1 SHA1 463 2-255 Unassigned 465 5.1.3 PK algorithm format 467 The PK algorithm field indicates the public key cryptographic 468 algorithm and the implied public key field format. This document 469 reuse the values defined for the 'algorithm type' of the IPSECKEY RR 470 [14] 'gateway type' field. 472 The presently defined values are given only informally: 474 1 A DSA key is present, in the format defined in RFC2536 [5]. 475 2 A RSA key is present, in the format defined in RFC3110 [6]. 477 5.1.4 HIT format 479 There's currently two types of HITs, and a single type of HAA. Both 480 of them are stored in network byte order within a self-describing 481 variable length wire-encoded (as per Section 3.3 482 of [2]): 484 o A *Type 1* HIT: least significant bits of the hash (e.g., SHA1) of 485 the public key (Host Identity), which is possibly following in the 486 HIPHI RR. 487 o A *Type 2* HIT: binary prefix (HAA) concatenated with a the least 488 significant bits of the hash (e.g., SHA1) of the public key (Host 489 Identity), which is possibly following in the HIPHI RR. 490 o A HAA: binary prefix (HAA) concatenated with 0, up to the 491 associated HIT length. 493 5.1.5 Public key format 495 Both of the public key types defined in this document (RSA and DSA) 496 reuse the public key formats defined for the IPSECKEY RR [14] (which 497 in turns contains the algorithm-specific portion of the KEY RR RDATA, 498 all of the KEY RR DATA after the first four octets, corresponding to 499 the same portion of the KEY RR that must be specified by documents 500 that define a DNSSEC algorithm). 502 In the future, if a new algorithm is to be used both by IPSECKEY RR 503 and HIPHI RR, it would probably use the same public key encodings for 504 both RRs. Unless specified otherwise, the HIPHI public key field 505 would use the same public key format as the IPSECKEY RR RDATA for the 506 corresponding algorithm. 508 The DSA key format is defined in RFC2536 [5]. 510 The RSA key format is defined in RFC3110 [6] and the RSA key size 511 limit (4096 bits) is relaxed in the IPSECKEY RR [14] specification. 513 5.2 HIPRVS RDATA format 515 The RDATA for a HIPRVS RR consists of a preference value, a 516 Rendezvous server type and either one or more Rendezvous server 517 address, or one Rendezvous server domain name. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | preference | type | | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rendezvous server | 524 ~ ~ 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 5.2.1 Preference format 529 This is an unsigned 8-bit value, used to specify the preference given 530 to this RR amongst others at the same owner. Lower values are 531 preferred. If there is a tie within some RR subset, the server 532 should return a permutation (e.g. round robin) of the set of RRs, 533 such that the requester load is fairly balanced amongst all RRs of 534 the set. 536 5.2.2 Rendezvous server type format 538 The Rendezvous server type indicates the format of the information 539 stored in the Rendezvous server field. 541 This document reuses the type values for the 'gateway type' field of 542 the IPSECKEY RR [14]. The presently defined values are given only 543 informally: 545 1. One or more 4-byte IPv4 address(es) in network byte order are 546 present. 547 2. One or more 16-byte IPv6 address(es) in network byte order are 548 present. 549 3. One or more variable length wire-encoded domain names as 550 described in section 3.3 of RFC1035 [2]. The wire-encoded format 551 is self-describing, so the length is implicit. The domain names 552 MUST NOT be compressed. 554 5.2.3 Rendezvous server format 556 The Rendezvous server field indicates one or more Rendezvous 557 Server(s) IP address(es), or domain name(s). A HIP I1 packet sent to 558 any of these RVS would reach the entity named by this resource 559 record. 561 This document reuses the format used for the 'gateway' field of the 562 IPSECKEY RR [14], but allows to concatenate several IP (v4 or v6) 563 addresses. The presently defined formats for the data portion of the 564 Rendezvous server field are given only informally: 566 o One or more 32-bit IPv4 address(es) in network byte order. 567 o One or more 128-bit IPv6 address(es) in network byte order. 568 o One or more variable length wire-encoded domain names as described 569 in section 3.3 of RFC1035 [2]. The wire-encoded format is 570 self-describing, so the length is implicit. The domain names MUST 571 NOT be compressed. 573 6. Presentation Format 575 This section specifies the representation of the HIPHI and HIPRVS RR 576 in a zone data master file. 578 6.1 HIPHI Representation 580 The HIT Type, HIT algorithm, PK algorithm, and Public Key are 581 REQUIRED. The HIT field is OPTIONAL. 583 The HIT Type, HIT algorithm, and PK algorithm are represented as 584 unsigned integers. 586 The HIT field is represented as the Base16 encoding [8] (a.k.a. hex 587 or hexadecimal) of the public key. If no HIT is to be indicated, 588 then the HIT algorithm MUST be zero and the HIT field must be ".". 590 The Public Key field is represented as the Base64 encoding [8] of the 591 public key. 593 The complete representation of the HPIHI record is: 595 IN HIPHI ( hit-type hit-algorithm pk-algorithm 596 base16-encoded-hit 597 base64-encoded-public-key ) 599 6.2 HIPRVS Representation 601 The Preference and RVS Type fields are REQUIRED. At least one RVS 602 field MUST be present. 604 The HIT Type, HIT algorithm, and PK algorithm are represented as 605 unsigned integers. 607 The RVS field is represented by one or more: 608 o IPv4 dotted decimal address(es) 609 o IPv6 colon hex address(es) 610 o uncompressed domain name(s) 612 The complete representation of the HPIRVS record is: 614 IN HIPRVS ( preference rendezvous-server-type 615 rendezvous-server[1] 616 ... 617 rendezvous-server[n] ) 619 6.3 Examples 621 Example of a node with a HI but no HIT: 623 www.example.com IN HIPHI ( 0 1 2 624 . 625 AB3NzaC1kc3MAAACBAOBhKnTCPOuFBzZQX/N3O9dm9P9ivUIMoId== ) 627 Example of a node with a HI and a HIT: 629 www.example.com IN HIPHI ( 1 1 2 630 120cf10ea842e0ba53320f1fe0ba5d3a3 631 AB3NzaC1kc3MAAACBAOBhKnTCPOuFBzZQX/N3O9dm9P9ivUIMoId== ) 633 Example of a node with an IPv6 RVS: 635 www.example.com IN HIPRVS ( 10 2 2001:0db8:0200:1:20c:f1ff:fe0b:a533 ) 637 Example of a node with three IPv4 RVS: 639 www.example.com IN HIPRVS ( 10 1 192.0.2.2 192.0.99.2 192.0.199.2) 641 Example of a node with two named RVS: 643 www.example.com IN HIPRVS ( 10 3 rvs.uk.example.com rvs.us.example.com ) 645 7. Retrieving Multiple HITs and IPs from the DNS 647 If a host receives multiple HITs in a response to a DNS query, those 648 HITs MUST be considered to denote a single service, and be 649 semantically equivalent from that point of view. When initiating a 650 base exchange with the denoted service, the host SHOULD be prepared 651 to accept any of HITs as the peer's identity. A host MAY implement 652 this by using the opportunistic mode (destination HIT null in I1), or 653 by sending multiple I1s, if needed. 655 In particular, if a host receives multiple HITs and multiple IP 656 addresses in response to a DNS query, the host cannot know how the 657 HITs are reachable at the listed IP addresses. The mapping may be 658 any, i.e., all HITs may be reachable at all of the listed IP 659 addresses, some of the HITs may be reachable at some of the IP 660 addresses, or there may even be one-to-one mapping between the HITs 661 and IP addresses. In general, the host cannot know the mapping and 662 MUST NOT expect any particular mapping. 664 It is RECOMMENDED that if a host receives multiple HITs, the host 665 SHOULD first try to initiate the base exchange by using the 666 opportunistic mode. If the returned HIT does not match with any of 667 the expected HITs, the host SHOULD retry by sending further I1s, one 668 at time, trying out all of the listed HITs. If the host receives an 669 R1 for any of the I1s, the host SHOULD continue to use the successful 670 IP address until an R1 with a listed HIT is received, or the host has 671 tried all HITs, and try the other IP addresses only after that. A 672 host MAY also send multiple I1s in parallel, but sending such I1s 673 MUST be rate limited to avoid flooding (as per Section 8.4.1 of 674 [10]). 676 8. Transition mechanisms 678 During a transition period, to allows to store the HIP informations 679 of a node in a DNS server which does not support the HIPHI and HIPRVS 680 RRs, A and AAAA RRs MAY be overloaded. A HIT would typically be 681 stored in a AAAA RR and a RVS in either a A or AAAA RR. If such a 682 situation occurs, the overloaded RRs MUST be returned as the last 683 items of the returned RRs set (A or AAAA), to avoid as most as 684 possible conflicts with non-HIP IPv6 nodes. 686 9. Security Considerations 688 Though the security considerations of the HIP DNS extensions still 689 need to be more investigated and documented, this section contains a 690 description of the known threats involved with the usage of the HIP 691 DNS extensions. 693 In a manner similar to the IPSECKEY RR [14], the HIP DNS Extensions 694 allows to provision two HIP nodes with the public keying material 695 (HI) of their peer. These HIs will be subsequently used in a key 696 exchange between the peers. Hence, the HIP DNS Extensions introduce 697 the same kind of threats that IPSECKEY does, plus threats caused by 698 the possibility given to a HIP node to initiate or accept a HIP 699 exchange using "Opportunistic" or "Unpublished Initiator HI" modes. 701 A HIP node SHOULD obtain both the HIPHI and HIPRVS RRs from a trusted 702 party trough a secure channel insuring proper data integrity of the 703 RRs. DNSSEC [3] provides such a secure channel. 705 In the absence of a proper secure channel, both parties are 706 vulnerable to MitM and DoS attacks, and unrelated parties might be 707 subject to DoS attacks as well. These threats are described in the 708 following sections. 710 9.1 Attacker tampering with an unsecure HIPHI RR 712 The HIPHI RR contains public keying material in the form of the named 713 peer's public key (the HI) and its secure hash (the HIT). Both of 714 these are not sensitive to attacks where an adversary gains knowledge 715 of them. However, an attacker that is able to mount an active attack 716 on the DNS, i.e., tampers with this HIPHI RR (e.g., using DNS 717 spoofing) is able to mount Man-in-the-Middle attacks on the 718 cryptographic core of the eventual HIP exchange (responder's HIPHI 719 and HIPRVS rewritten by the attacker). 721 9.2 Attacker tampering with an unsecure HIPRVS RR 723 The HIPRVS RR contains a destination IP address where the named peer 724 is reachable by an I1 (HIP Rendezvous Extensions IPSECKEY RR [13] ). 725 Thus, an attacker able to tamper with this RRs is able to redirect I1 726 packets sent to the named peer to a chosen IP address, for DoS or 727 MitM attacks. Note that this kind of attacks are not specific to HIP 728 and exist independently to whether or not HIP and the HIPRVS RR are 729 used. Such an attacker might tamper with A and AAAA RRs as well. 731 An attacker might obviously use these two attacks in conjunction: It 732 will replace the responder's HI and RVS IP address by its owns in a 733 spoofed DNS packet sent to the initiator HI, then redirect all 734 exchanged packets through him and mount a MitM on HIP. In this case 735 HIP won't provide confidentiality nor initiator HI protection from 736 eavesdroppers. 738 9.3 Opportunistic HIP 740 A HIP initiator may not be aware of its peer's HI, and/or its HIT 741 (e.g., because the DNS does not contains HIP material, or the 742 resolver isn't HIP-enabled), and attempt an opportunistic HIP 743 exchange towards its known IP address, filling the responder HIT 744 field with zeros in the I1 header. Such an initiator is vulnerable 745 to a MitM attack because it can't validate the HI and HIT contained 746 in a replied R1. Hence, an implementation MAY choose not to use 747 opportunistic mode. 749 9.4 Unpublished Initiator HI 751 A HIP initiator may choose to use an unpublished HI, which is not 752 stored in the DNS by means of a HIPHI RR. A responder associating 753 with such an initiator knowingly risks a MitM attack because it 754 cannot validate the initiator's HI. Hence, an implementation MAY 755 choose not to use unpublished mode. 757 9.5 Hash and HITs Collisions 759 As many cryptographic algorithm, some secure hashes (e.g. SHA1, used 760 by HIP to generate a HIT from an HI) eventually become insecure, 761 because an exploit has been found in which an attacker with a 762 reasonable computation power breaks one of the security features of 763 the hash (e.g., its supposed collision resistance). This is why a 764 HIP end-node implementation SHOULD NOT authenticate its HIP peers 765 based solely on a HIT retrieved from DNS, but SHOULD rather use 766 HI-based authentication. 768 10. IANA Considerations 770 IANA needs to allocate two new RR type code for HIPHI and HIPRVS from 771 the standard RR type space. 773 IANA needs to open a new registry for the HIPHI RR HIT type. Defined 774 types are: 776 0 No HIT is present 777 1 A Type 1 HIT is present 778 2 A Type 2 HIT is present 779 3-6 Unassigned 780 7 A HAA is present 782 Adding new reservations requires IETF consensus RFC2434 [16]. 784 IANA needs to open a new registry for the HIPHI RR HIT algorithm. 785 Defined types are: 787 0 Reserved 788 1 SHA1 789 2-255 Unassigned 791 Adding new reservations requires IETF consensus RFC2434 [16]. 793 IANA does not need to open a new registry for the HIPHI RR type for 794 public key algorithms because the HIPHI RR reuse 'algorithms types' 795 defined for the IPSECKEY RR [14]. The presently defined numbers are 796 given here only informally: 798 0 is reserved 799 1 is RSA 800 2 is DSA 802 IANA does not need to open a new registry for the HIPRVS RR 803 Rendezvous server type because the HIPHI RR reuse the 'gateway types' 804 defined for the IPSECKEY RR [14]. The presently defined numbers are 805 given here only informally: 807 0 is reserved 808 1 is IPv4 809 2 is IPv6 810 3 is a wire-encoded uncompressed domain name 812 11. Acknowledgments 814 As usual in the IETF, this document is the result of a collaboration 815 between many people. The authors would like to thanks the author 816 (Michael Richardson), contributors and reviewers of the IPSECKEY RR 817 [14] specification, which this document was framed after. The 818 authors would also like to thanks the following people, who have 819 provided thoughtful and helpful discussions and/or suggestions, that 820 have helped improving this document: Rob Austein, Hannu Flinck, Tom 821 Henderson, Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel 822 Montenegro. Some parts of this draft stem from [10]. 824 12. References 826 12.1 Normative references 828 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 829 13, RFC 1034, November 1987. 831 [2] Mockapetris, P., "Domain names - implementation and 832 specification", STD 13, RFC 1035, November 1987. 834 [3] Eastlake, D. and C. Kaufman, "Domain Name System Security 835 Extensions", RFC 2065, January 1997. 837 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 838 Levels", BCP 14, RFC 2119, March 1997. 840 [5] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 841 (DNS)", RFC 2536, March 1999. 843 [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 844 System (DNS)", RFC 3110, May 2001. 846 [7] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, 847 "Representing Internet Protocol version 6 (IPv6) Addresses in 848 the Domain Name System (DNS)", RFC 3363, August 2002. 850 [8] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 851 RFC 3548, July 2003. 853 [9] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 854 Extensions to Support IP Version 6", RFC 3596, October 2003. 856 [10] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 857 Protocol", draft-ietf-hip-base-01 (work in progress), October 858 2004. 860 [11] Moskowitz, R. and P. Nikander, "Host Identity Protocol 861 Architecture", draft-ietf-hip-arch-00 (work in progress), 862 October 2004. 864 [12] Nikander, P., "End-Host Mobility and Multi-Homing with Host 865 Identity Protocol", draft-ietf-hip-mm-00 (work in progress), 866 October 2004. 868 [13] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 869 Rendezvous Extensions", draft-ietf-hip-rvs-00 (work in 870 progress), October 2004. 872 [14] Richardson, M., "A method for storing IPsec keying material in 873 DNS", draft-ietf-ipseckey-rr-12 (work in progress), January 874 2005. 876 12.2 Informative references 878 [15] Jokela, P., Moskowitz, R. and P. Nikander, "Using ESP transport 879 format with HIP", draft-jokela-hip-esp-00 (work in progress), 880 February 2005. 882 [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 883 Considerations Section in RFCs", BCP 26, RFC 2434, October 884 1998. 886 Authors' Addresses 888 Pekka Nikander 889 Ericsson Research Nomadic Lab 890 JORVAS FIN-02420 891 FINLAND 893 Phone: +358 9 299 1 894 EMail: pekka.nikander@nomadiclab.com 896 Julien Laganier 897 LIP (CNRS-INRIA-ENSL-UCBL) & Sun Labs (Sun Microsystems) 898 180, Avenue de l'Europe 899 Saint Ismier CEDEX 38334 900 France 902 Phone: +33 476 188 815 903 EMail: ju@sun.com 905 Appendix A. Document Revision History 907 +-----------+-------------------------------------------------------+ 908 | Revision | Comments | 909 +-----------+-------------------------------------------------------+ 910 | 01 | Compared to draft-ietf-hip-dns-01: Removed HIP | 911 | | rendezvous registration protocol. Removed references | 912 | | to DNS. Added figures. Added text discussing multiple | 913 | | HITs and IP. | 914 | | | 915 | 00 | Initial version as a HIP WG item. | 916 +-----------+-------------------------------------------------------+ 918 Intellectual Property Statement 920 The IETF takes no position regarding the validity or scope of any 921 Intellectual Property Rights or other rights that might be claimed to 922 pertain to the implementation or use of the technology described in 923 this document or the extent to which any license under such rights 924 might or might not be available; nor does it represent that it has 925 made any independent effort to identify any such rights. Information 926 on the procedures with respect to rights in RFC documents can be 927 found in BCP 78 and BCP 79. 929 Copies of IPR disclosures made to the IETF Secretariat and any 930 assurances of licenses to be made available, or the result of an 931 attempt made to obtain a general license or permission for the use of 932 such proprietary rights by implementers or users of this 933 specification can be obtained from the IETF on-line IPR repository at 934 http://www.ietf.org/ipr. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights that may cover technology that may be required to implement 939 this standard. Please address the information to the IETF at 940 ietf-ipr@ietf.org. 942 Disclaimer of Validity 944 This document and the information contained herein are provided on an 945 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 946 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 947 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 948 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 949 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 950 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 952 Copyright Statement 954 Copyright (C) The Internet Society (2005). This document is subject 955 to the rights, licenses and restrictions contained in BCP 78, and 956 except as set forth therein, the authors retain all their rights. 958 Acknowledgment 960 Funding for the RFC Editor function is currently provided by the 961 Internet Society.