idnits 2.17.1 draft-ietf-shim6-hba-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 929. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 935. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 264: '...reserved field. MUST be initialized t...' 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 23, 2005) is 6760 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) ** Obsolete normative reference: RFC 3280 (ref. '3') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3513 (ref. '4') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3041 (ref. '5') (Obsoleted by RFC 4941) -- Unexpected draft version: The latest known version of draft-bagnulo-shim6-cga-ext is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-01 == Outdated reference: A later version (-03) exists of draft-ietf-multi6-multihoming-threats-01 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-01 == Outdated reference: A later version (-04) exists of draft-haddad-mip6-cga-omipv6-02 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Expires: April 26, 2006 October 23, 2005 6 Hash Based Addresses (HBA) 7 draft-ietf-shim6-hba-01 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 26, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This memo describes a mechanism to provide a secure binding between 41 the multiple addresses with different prefixes available to a host 42 within a multihomed site. The main idea is that information about 43 the multiple prefixes is included within the addresses themselves. 44 This is achieved by generating the interface identifiers of the 45 addresses of a host as hashes of the available prefixes and a random 46 number. Then, the multiple addresses are generated by prepending the 47 different prefixes to the generated interface identifiers. The 48 result is a set of addresses, called Hash Based Addresses (HBAs), 49 that are inherently bound. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. CGA compatibility considerations . . . . . . . . . . . . . . . 4 55 3. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . . 6 56 4. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . . 7 57 5. HBA verification . . . . . . . . . . . . . . . . . . . . . . . 9 58 6. Example of HBA application to a multihoming scenario . . . . . 11 59 6.1. Dynamic Address Set Support . . . . . . . . . . . . . . . 13 60 7. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 14 61 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 62 9. Security considerations . . . . . . . . . . . . . . . . . . . 14 63 9.1. Security considerations when using HBAs in the shim6 64 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 9.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 18 66 9.3. Interaction with IPSec. . . . . . . . . . . . . . . . . . 18 67 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 69 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 12.1. Changes from draft-ietf-shim6-hba-00 to 71 draft-ietf-multi6-hba-01 . . . . . . . . . . . . . . . . . 19 72 12.2. Changes from draft-ietf-multi6-hba-00 to 73 draft-ietf-shim6-hba-00 . . . . . . . . . . . . . . . . . 19 74 12.3. Changes from draft-bagnulo-multi6dt-hba-00 to 75 draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . . 19 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 78 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 Intellectual Property and Copyright Statements . . . . . . . . . . 22 82 1. Introduction 84 In order to preserve inter-domain routing system scalability, IPv6 85 sites obtain addresses from their Internet Service Providers. Such 86 addressing strategy significantly reduces the amount of routes in the 87 global routing tables, since each ISP only announces routes to its 88 own address blocks, rather than announcing one route per customer 89 site. However, this addressing scheme implies that multihomed sites 90 will obtain multiple prefixes, one per ISP. Moreover, since each ISP 91 only announces its own address block, a multihomed site will be 92 reachable through a given ISP if the ISP prefix is contained in the 93 destination address of the packets. This means that, if an 94 established communication needs to be routed through different ISPs 95 during its lifetime, addresses with different prefixes will have to 96 be used. Changing the address used to carry packets of an 97 established communication exposes the communication to numerous 98 attacks, as described in [8], so security mechanisms are required to 99 provide the required protection to the involved parties. This memo 100 describes a tool that can be used to provide protection against some 101 of the potential attacks, in particular against future/ premeditated 102 attacks (a.k.a. time shifting attacks in [9]). 104 It should be noted that, as opposed to the mobility case where the 105 addresses that will be used by the mobile node are not known a 106 priori, the multiple addresses available to a host within the 107 multihomed site are pre-defined and known in advance in most of the 108 cases. The mechanism proposed in this memo takes advantage of this 109 address set stability, and provides a secure binding between all the 110 addresses of a node in a multihomed site. The mechanism does so 111 without requiring the usage of public key cryptography, providing a 112 cost efficient alternative to public key cryptography based schemes. 114 This memo describes a mechanism to provide a secure binding between 115 the multiple addresses with different prefixes available to a host 116 within a multihomed site. The main idea is that information about 117 the multiple prefixes is included within the addresses themselves. 118 This is achieved by generating the interface identifiers of the 119 addresses of a host as hashes of the available prefixes and a random 120 number. Then, the multiple addresses are obtained by prepending the 121 different prefixes to the generated interface identifiers. The 122 result is a set of addresses, called Hash Based Addresses (HBAs), 123 that are inherently bound. A cost efficient mechanism is available 124 to determine if two addresses belong to the same set, since given the 125 prefix set and the additional parameters used to generate the HBA, a 126 single hash operation is enough to verify if an HBA belongs to a 127 given HBA set. No public key operations are involved in the 128 verification process. In addition, it should also be noted that it 129 is not required that all interface identifiers of the addresses of an 130 HBA set are equal, preserving some degree of privacy through changes 131 in the addresses used during the communications. 133 2. CGA compatibility considerations 135 As described in previous section, the HBA technique uses the 136 interface identifier part of the IPv6 address to encode information 137 about the multiple prefixes available to a multihomed host. However, 138 the interface identifier is also used to carry cryptographic 139 information when Cryptographic Generated Addresses [1] are used. 140 Therefore, conflicting usages of the interface identifier bits may 141 result if this is not taken into account during the HBA design. 142 There are at least two valid reasons to provide CGA-HBA 143 compatibility: 145 First, the current Secure Neighbor Discovery specification [2] uses 146 the CGAs defined in [1] to prove address ownership. If HBAs are not 147 compatible with CGAs, then nodes using HBAs for multihoming wouldn't 148 be able to do Secure Neighbor Discovery using the same addresses (at 149 least the parts of SeND that require CGAs). This would imply that 150 nodes would have to choose between security (from SeND) and fault 151 tolerance (from shim6). In addition to SeND, there are other 152 protocols that are considering to benefit from the advantages offered 153 by the CGA scheme, such as mobility support protocols [10]. Those 154 protocols would also become incompatible with HBAs if HBAs are not 155 compatible with CGAs. 157 Second, CGAs provide additional features that cannot be achieved 158 using only HBAs. In particular, because of its own nature, the HBA 159 technique only supports a predetermined prefix set that is known at 160 the time of the generation of the HBA set. No additions of new 161 prefixes to this original set are supported after the HBA set 162 generation. In most of the cases relevant for site multihoming, this 163 is not a problem because the prefix set available to a multihomed set 164 is not very dynamic. New prefixes may be added in a multihomed site 165 when a new ISP is available, but the timing of those events are 166 rarely in the same time scale than the lifetime of established 167 communications. It is then enough for many situations that the new 168 prefix is not available for established communications and that only 169 new communications benefit from it. However, in the case that such 170 functionality is required, it is possible to use CGAs to provide it. 171 This approach clearly requires that HBA and CGA approaches are 172 compatible. If this is the case, it then would be possible to create 173 HBA/CGA addresses that support CGA and HBA functionality 174 simultaneously. The inputs to the HBA/CGA generation process will be 175 both a prefix set and a public key. In this way, a node that has 176 established a communication using one address of the CGA/HBA set can 177 tell its peer to use the HBA verification when one of the addresses 178 of its HBA/CGA set is used as locator in the communication or to use 179 CGA (public/private key based) verification when a new address that 180 does not belong to the HBA/CGA set is used as locator in the 181 communication. 183 So, because of the aforementioned reasons, it is a goal of the HBA 184 design to define HBAs in a way that they are compatible with CGAs as 185 defined in [1] and their usages described in [2] (Consequently, to 186 understand the rest of this note, the reader should be familiar with 187 the CGA specification defined in [1]). This means that it must be 188 possible to generate addresses that are both an HBA and a CGA i.e. 189 that the interface identifier contains cryptographic information of 190 CGA and the prefix-set information of an HBA. The CGA specification 191 already considers the possibility of including additional information 192 into the CGA generation process through the usage of Extension Fields 193 in the CGA Parameter Data Structure. It is then possible to define a 194 Multi-Prefix Extension for CGA so that the prefix set information is 195 included in the interface identifier generation process. 197 Even though a CGA compatible approach is adopted, it should be noted 198 that HBAs and CGAs are different concepts. In particular, the CGA is 199 inherently bound to a public key, while a HBA is inherently bound to 200 a prefix set. This means that a public key is not strictly required 201 to generate an HBA. Because of that, we define three different types 202 of addresses: 204 - CGA-only addresses: These are addresses generated as specified in 205 [1] without including the Multi-Prefix Extension. They are bound 206 to a public key and to a single prefix (contained in the basic CGA 207 Parameter Data Structure). These addresses can be used for SeND 208 [2] and if used for multihoming, their application will have to be 209 based on the public key usage. 211 - CGA/HBA addresses: These addresses are CGAs that include the Multi- 212 Prefix Extension in the CGA Parameters Data Structure used for 213 their generation. These addresses are bound to a public key and a 214 prefix set and they provide both CGA and HBA functionalities. 215 They can be used for SeND as defined in [2] and for any usage 216 defined for HBA (such as a shim6 protocol) 218 - HBA-only addresses: These addresses are bound to a prefix set but 219 they are not bound to a public key. Because CGA compatibility, 220 the CGA Parameter Data Structure will be used for their 221 generation, but a random nonce will be included in the Public Key 222 field instead of a public key. These addresses can be used for 223 HBA based multihoming protocols, but they cannot be used for SeND. 225 3. Multi-Prefix Extension for CGA 227 The Multi-Prefix Extension has the following TLV format as defined in 228 [6] : 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Extension Type | Extension Data Length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |P| Reserved | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + Prefix[1] + 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 + Prefix[2] + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 . . . 246 . . . 247 . . . 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 + Prefix[n] + 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Ext Type: 16-bit type identifier of the Multi-Prefix Extension (TBD 255 IANA) (Meanwhile, the 0x12 value is recommended for trails) 257 Ext Len: 16-bit unsigned integer. Length of the Extension in octets, 258 not including the first 4 octets. 260 P flag: Set if a public key is included in the Public Key field of 261 the CGA Parameter Data Structure. Reset if a additional Modifier 262 bits are included in the CGA Parameter Data Structure. 264 Reserved: 31-bit reserved field. MUST be initialized to zero, and 265 ignored upon receipt. 267 Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n. 269 4. HBA-Set Generation 271 The HBA generation process is based on the CGA generation process 272 defined in section 4 of [1]. The goal is to require the minimum 273 amount of changes to the CGA generation process. 275 The CGA generation process has three inputs: a 64-bit subnet prefix, 276 a public key (encoded in DER as an ASN.1 structure of the type 277 SubjectPublicKeyInfo), and the security parameter Sec. 279 The main difference between the CGA generation and the HBA generation 280 is that while a CGA can be generated independently, all the HBAs of a 281 given HBA set have to be generated using the same parameters, which 282 implies that the generation of the addresses of an HBA set will occur 283 in a coordinated fashion. In this memo, we will describe a mechanism 284 to generate all the addresses of a given HBA set. The generation 285 process of each one of the HBA address of an HBA set will be heavily 286 based in the CGA generation process defined in [1]. More precisely, 287 the HBA set generation process will be defined as a sequence of 288 lightly modified CGA generations. 290 The changes required in the CGA generation process when generating a 291 single HBA are the following: First, the Multi-Prefix Extension has 292 to be included in the CGA Parameters Data Structure. Second, in the 293 case that the address being generated is an HBA-only address, a 294 random nonce (encoded in DER as an ASN.1 structure of the type 295 SubjectPublicKeyInfo) will have to be used as input instead of a 296 valid public key. 298 The resulting HBA-set generation process is the following: 300 The inputs to the HBA generation process are: 301 o A vector of n 64-bit prefixes 302 o A Sec parameter, and 303 o In the case of the generation of a set of HBA/CGA addresses a 304 public key is also provided as input (not required when generating 305 HBA-only addresses) 307 The output of the HBA generation process are: 308 o An HBA-set 309 o their respective CGA Parameters Data Structures 311 The steps of the HBA-set generation process are: 313 1. Multi-Prefix Extension generation. Generate the Multi-Prefix 314 Extension with the format defined in section 3. Include the 315 vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext 316 Len field value is (n*8 + 4). If a public key is provided, then 317 the P flag is set. Otherwise, the P flag is reset. 319 2. Modifier generation. Generate a Modifier as a random or 320 pseudorandom 128-bit value. If a public key has not been provided 321 as an input, generate the Extended Modifier as a 384-bit random or 322 pseudorandom value. Encode the Extended Modifier value as a RSA 323 key in a DER-encoded ASN.1 structure of the type 324 SubjectPublicKeyInfo defined in the Internet X.509 certificate 325 profile [3]. 327 3. Concatenate from left to right the Modifier, 9 zero octets, the 328 encoded public key or the encoded Extended Modifier (if no public 329 key was provided) and the Multi-Prefix Extension. Execute the 330 SHA-1 algorithm on the concatenation. Take the 112 leftmost bits 331 of the SHA-1 hash value. The result is Hash2. 333 4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 334 all zero (or if Sec=0), continue with step (5). Otherwise, 335 increment the modifier by one and go back to step (3). 337 5. Set the 8-bit collision count to zero. 339 6. For i=1 to n do 341 6.1. Concatenate from left to right the final Modifier value, 342 Prefix[i], the collision count, the encoded public key or the 343 encoded Extended Modifier (if no public key was provided) and 344 the Multi-Prefix Extension. Execute the SHA-1 algorithm on the 345 concatenation. Take the 64 leftmost bits of the SHA-1 hash 346 value. The result is Hash1[i]. 348 6.2. Form an interface identifier from Hash1[i] by writing the 349 value of Sec into the three leftmost bits and by setting bits 6 350 and 7 (i.e., the "u" and "g" bits) both to zero. 352 6.3. Generate address HBA[i] by concatenating Prefix[i] and the 353 64-bit interface identifier to form a 128-bit IPv6 address with 354 the subnet prefix to the left and interface identifier to the 355 right as in a standard IPv6 address [4]. 357 6.4. Perform duplicate address detection if required. If an 358 address collision is detected, increment the collision count by 359 one and go back to step (6). However, after three collisions, 360 stop and report the error. 362 6.5. Form the CGA Parameters Data Structure that corresponds to 363 HBA[i] by concatenating from left to right the final modifier 364 value, Prefix[i], the final collision count value, the encoded 365 public key or the encoded Extended Modifier and the Multi- 366 Prefix Extension. 368 [Note: most of the steps of the process are taken from [1]] 370 5. HBA verification 372 HBAs are constructed as a CGA Extension, so a properly formated HBA 373 and its correspondent CGA Parameter Data Structure will successfully 374 finish the verification process described in section 5 of [1]. Such 375 verification is useful when the goal is the verification of the 376 binding between the public key and the HBA. 378 However, for multihoming applications, it is also relevant to verify 379 if a given HBA address belongs to a certain HBA set. An HBA set is 380 identified by a CGA Parameter Data structure that contains a Multi- 381 Prefix Extension. So, it is then needed to verify if an HBA belongs 382 to the HBA set defined by a CGA Parameter Data Structure. It should 383 be noted that it may be needed to verify if an HBA belongs to the HBA 384 set defined by the CGA Parameter Data Structure of another HBA of the 385 set. If this is the case, the CGA verification process as defined in 386 [1] will fail, because the prefix included in the Subnet Prefix field 387 of the CGA Parameter Data Structure will not match with the one of 388 the HBA that is being verified. However, this not means that this 389 HBA does not belong to the HBA set. In order to address this issue, 390 it is only required to verify that the HBA prefix is included in 391 prefix set defined in the Multi-Prefix Extension, and if this is the 392 case, then substitute the prefix included in the Subnet Prefix field 393 by the prefix of the HBA, and then perform the CGA verification 394 process defined in [1]. 396 So, the process to verify that an HBA belongs to an HBA set 397 determined by a CGA Parameter Data Structure is called HBA 398 verification and it is the following: 400 The inputs to the HBA verification process are: 402 o An HBA 403 o An CGA Parameter Data Structure 405 The steps of the HBA verification process are the following: 407 1. Verify that the 64-bit HBA prefix is included in the prefix set of 408 the Multi-Prefix Extension. If it is not included, the 409 verification fails. If it is included, replace the prefix 410 contained in the Subnet Prefix field of the CGA Parameter Data 411 Structure by the 64-bit HBA prefix. 413 2. Run the verification process described in section 5 of [1] with 414 the HBA and the new CGA Parameters Data Structure (including the 415 Multi-Prefix Extension) as inputs. The steps of the process are 416 included below, extracted from [1] 418 2.1. Check that the collision count in the CGA Parameters Data 419 Structure is 0, 1 or 2. The CGA verification fails if the 420 collision count is out of the valid range. 422 2.2. Check that the subnet prefix in the CGA Parameters Data 423 Structure is equal to the subnet prefix (i.e., the leftmost 64 424 bits) of the address. The CGA verification fails if the prefix 425 values differ. [Note: This step is trivially successful 426 because step 1] 428 2.3. Execute the SHA-1 algorithm on the CGA Parameters Data 429 Structure. Take the 64 leftmost bits of the SHA-1 hash value. 430 The result is Hash1. 432 2.4. Compare Hash1 with the interface identifier (i.e., the 433 rightmost 64 bits) of the address. Differences in the three 434 leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) 435 are ignored. If the 64-bit values differ (other than in the 436 five ignored bits), the CGA verification fails. 438 2.5. Read the security parameter Sec from the three leftmost bits 439 of the 64-bit interface identifier of the address. (Sec is an 440 unsigned 3-bit integer.) 442 2.6. Concatenate from left to right the modifier, 9 zero octets, 443 and the public key, and any extension fields [in this case, the 444 Multi-Prefix Extension will be included, at least] that follow 445 the public key in the CGA Parameters data structure. Execute 446 the SHA-1 algorithm on the concatenation. Take the 112 447 leftmost bits of the SHA-1 hash value. The result is Hash2. 449 2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any 450 one of them is non-zero, the CGA verification fails. 451 Otherwise, the verification succeeds. (If Sec=0, the CGA 452 verification never fails at this step.) 454 6. Example of HBA application to a multihoming scenario 456 In this section, we will describe a possible application of the HBA 457 technique to IPv6 multi-homing. 459 We will consider the following scenario: a multihomed site obtains 460 Internet connectivity through two providers ISPA and ISPB. Each 461 provider has delegated a prefix to the the multihomed site 462 (PrefA::/nA and PrefB::/nb respectively). In order to benefit from 463 multihoming, the hosts within the multihomed site will configure 464 multiple IP addresses, one per available prefix. The resulting 465 configuration is depicted in the next figure. 467 +-------+ 468 | Host2 | 469 |IPHost2| 470 +-------+ 471 | 472 | 473 (Internet) 474 / \ 475 / \ 476 +------+ +------+ 477 | ISPA | | ISPB | 478 | | | | 479 +------+ +------+ 480 | | 481 \ / 482 \ / 483 +---------------------+ 484 | multihomed site | 485 | PA::/nA | 486 | PB::/nB +------+ | 487 | |Host1 | | 488 | +------+ | 489 +---------------------+ 491 We assume that both Host1 and Host2 support the shim6 protocol. 493 Host2 in not located in a multihomed site, so there is no need for 494 him to create HBAs (it must be able to verify them though, in order 495 to support the shim6 protocol, as we will describe next.) 497 Host1 is located in the multihomed site, so it will generate its 498 addresses as HBAs. In order to do that, it needs to execute the HBA- 499 set generation process as detailed in Section 4 of this memo. The 500 inputs of the HBA-set generation process will be: a prefix vector 501 containing the two prefixes available in its link i.e. PA:LA::/64 502 and PB:LB::/64, a Sec parameter value, and optionally a public key. 503 In this case we will assume that a public key is provided so that we 504 can also illustrate how a renumbering event can be supported when 505 HBA/CGA addresses are used (see the sub-section referring to dynamic 506 address set support). So, after executing the HBA-set generation 507 process, Host1 will have: an HBA-set consisting in two addresses i.e. 508 PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data 509 Structures i.e. CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are 510 different but both contain information about the prefix set available 511 in the multihomed site. 513 We will next consider a communication between Host1 and Host2. 514 Assume that both ISPs of the multihomed site are working properly, so 515 any of the available addresses in Host1 can be used for the 516 communication. Suppose then that the communication is established 517 using PA:LA:iidA and IPHost2 for Host1 and Host2 respectively. So 518 far, no special shim6 support has been required, and PA:LA:iidA is 519 used as any other global IP address 521 Suppose that at a certain moment one of the hosts involved in the 522 communication decides that multihoming support is required in this 523 communication (this basically means that one of the hosts involved in 524 the communication desires enhanced fault tolerance capabilities for 525 this communication, so that if an outage occurs, the communication 526 can be rehomed to an alternative provider). 528 At this moment, the shim6 protocol Host-Pair Context establishment 529 exchange will be perfomed between the two hosts (see [7].). In this 530 exchange, Host1 will send CGA_PDS_A to Host2. 532 After the reception of CGA_PDS_A, Host2 will verify that the received 533 CGA Parameter Data Structure corresponds to the address being used in 534 the communication PA:LA:iidA. this means that Host2 will execute the 535 HBA verification process described in Section 5 of this memo with PA: 536 LA:iidA and CGA_PDS_A as inputs. In this case, the verification will 537 succeed since the CGA Parameter Data Structure and the addresses used 538 in the verification match. 540 As long as there are no outages affecting the communication path 541 through ISPA, packets will continue flowing. If a failure affects 542 the path through ISPA, Host1 will attempt to re-home the 543 communication to an alternative address i.e. PB:LB:iidB. For that, 544 after detecting the outage, Host1 will inform Host2 about the 545 alternative address. Host2 will verify that the new address belongs 546 to the HBA set of the initial address. For that, Host2 will execute 547 the HBA verification process with the CGA Parameter Data Structure of 548 the original address (i.e. CGA_PDS_A) and the new address (i.e. PB: 549 LB:iidB) as inputs. The verification process will succeed because 550 PB:LB::/64 has been included in the Multi-Prefix Extension during the 551 HBA-set generation process. Additional verifications may be required 552 to prevent flooding attacks (see the comments about flooding attacks 553 prevention in the Security Considerations section of this memo). 555 Once the new address is verified, it can be used as an alternative 556 locator to re-home the communication, while preserving the original 557 address (PA:LA:iidA) ad identifier for the upper layers. This means 558 that following packets will be addressed to/from this new address. 559 Note that no additional HBA verification is required for the 560 following packets, since the new valid address can be stored in 561 Host2. 563 Eventually, the communication will end and the associated shim6 564 context information will be discarded. 566 In this example, only the HBA capabilities of the Host1 addresses 567 were used. In other words, neither the public key included in the 568 CGA Parameter Data Structure nor its correspondent private key was 569 used in the protocol. In the following section we will consider a 570 case where its usage is required. 572 6.1. Dynamic Address Set Support 574 In the previous section we have presented the mechanisms that allow a 575 host to use different addresses of a pre-determined set to exchange 576 packets of a communication. The set of addresses involved was pre- 577 determined and known when the communication was initiated. To 578 achieve such functionality, only HBA functionalities of the addresses 579 were needed. In this section we will explore the case where the goal 580 is to exchange packets using additional addresses that were not known 581 when the communication was established. An example of such situation 582 is for instance when a new prefix is available in a site after a 583 renumbering event. In this case, the hosts that have the new address 584 available may want to use it in communications that were established 585 before the renumbering event. In this case, HBA functionalities of 586 the addresses are not enough and CGA capabilities are to be used. 588 Consider then the previous case of the communication between Host1 589 and Host2. Suppose that the communication is up and running, as 590 described earlier. Host1 is using PA:LA:iidA and Host2 is using 591 IPHost2 to exchange packets. Now suppose that a new address, PC:LC: 592 addC is available in Host1. Note that this address is just a regular 593 IPv6 address, and it is neither an HBA nor a CGA. Host1 wants to use 594 this new address in the existent communication with Host2. It should 595 be noted that the HBA mechanism described in the previous section 596 cannot be used to verify this new address, since this address does 597 not belong to the HBA set (since the prefix was not available at the 598 moment of the generation of the HBA set). This means that 599 alternative verification mechanisms will be needed. 601 In order to verify this new address, CGA capabilities of PA:LA:iidA 602 are used. Note that the same address is used, only that the 603 verification mechanism is different. So, if Host1 wants to use PC: 604 LC:addC to exchange packets in the established communication, it will 605 use message of the shim6 protocol, conveying the new address, PC:LC: 606 addC, and this message will be signed using the private key 607 corresponding to the public key contained in CGA_PDS_A. When Host2 608 receives the message, it will verify the signature using the public 609 key contained in the CGA Parameter Data Structure associated with the 610 address used for establishing the communication i.e. CGA_PDS_A and 611 PA:LA:iidA respectively. Once that the signature is verified, the 612 new address (PC:LC:addC) can be used in the communication. 614 7. DNS considerations 616 HBA sets can be generated using any prefix set. Actually, the only 617 particularity of the HBA is that they contain information about the 618 prefix set in the interface identifier part of the address in the 619 form of a hash, but no assumption about the properties of prefixes 620 used for the HBA generation is made. This basically means that 621 depending on the prefixes used for the HBA set generation, it may or 622 may not be recommended to publish the resulting (HBA) addresses in 623 the DNS. 625 8. IANA considerations 627 This document defines a new CGA Extension, the Multi-Prefix 628 Extension. This extension has been assigned the CGA Extension Type 629 value TBD (IANA). 631 9. Security considerations 632 The goal of HBAs is to create a group of addresses that are securely 633 bound, so that they can be used interchangeably when communicating 634 with a node. If there is no secure binding between the different 635 addresses of a node, a number of attacks are enabled, as described in 636 [8]. It particular, it would possible for an attacker to redirect 637 the communications of a victim to an address selected by the 638 attacker, hijacking the communication. When using HBAs, only the 639 addresses belonging to an HBA set can be used interchangeably, 640 limiting the addresses that can be used to redirect the communication 641 to a well, pre-determined set, that belongs to the original node 642 involved in the communication. So, when using HBAs, a node that is 643 communicating using address A can redirect the communication to a new 644 address B if and only if B belongs to the same HBA set than A. 646 This means that if an attacker wants to redirect communications 647 addressed to address HBA1 to an alternative address IPX, the attacker 648 will need to create a CGA Parameters data structure that generates an 649 HBA set that contains both HBA1 and IPX. 651 In order to generate the required HBA set, the attacker needs to find 652 a CGA Parameter data structure that fulfills the following 653 conditions: 654 o the prefix of HBA1 and the prefix of IPX are included in the 655 Multi-Prefix Extension 656 o HBA1 is included in the HBA set generated. 658 (this assumes that it is acceptable for the attacker to redirect HBA1 659 to any address of the prefix of IPX). 661 The remaining fields that can be changed at will by the attacker in 662 order to meet the above conditions are: the Modifier, other prefixes 663 in the Multi-Prefix Extension and other extensions. In any case, in 664 order to obtain the desired HBA set, the attacker will have to use a 665 brute force attack, which implies the generation of multiple HBA sets 666 with different parameters (for instance with a different Modifier) 667 until the desired conditions are meet. The expected number of times 668 that the generation process will have to be repeated until the 669 desired HBA set is found is exponentially related with the number of 670 bits containing hash information included in the interface identifier 671 of the HBA. Since 59 of the 64 bits of the interface identifier 672 contain hash bits, then the expected number of generations that will 673 have to be performed by the attacker are O(2^59). 675 The protection against brute force attacks can be improved increasing 676 the Sec parameter. A non zero Sec parameter implies that steps 3-4 677 of the generation process will be repeated O(2^(16*Sec)) times 678 (expected number of times). If we assimilate the cost of repeating 679 the steps 3-4 to the cost of generating the HBA address, we can 680 estimate the number of times that the generation is to be repeated in 681 O(2^(59+16*Sec)). 683 9.1. Security considerations when using HBAs in the shim6 protocol 685 In this section we will analyze the security provided by HBAs in the 686 context of a shim6 protocol as described in section 6 of this memo. 688 First of all, it must be noted that HBAs cannot prevent man-in-the- 689 middle (hereafter MITM) attacks. This means, that in the scenario 690 described in Section 6, if an attacker is located along the path 691 between Host1 and Host2 during the lifetime of the communication, the 692 attacker will be able to change the addresses used for the 693 communication. This means that he will be able to change the 694 addresses used in the communication, adding or removing prefixes at 695 his will. However, the attacker must make sure that the CGA 696 Parameter Data Structure and the HBA set is changed accordingly. 697 This essentially means that the attacker will have to change the 698 interface identifier part of the addresses involved, since a change 699 in the prefix set will result in different interface identifiers of 700 the addresses of the HBA set, unless the appropriate Modifier value 701 is used (which would require O(2(59+16*Sec)) attempts). So, HBA 702 don't provide MITM attacks protection, but a MITM attacker will have 703 to change the address used in the communication in order to change 704 the prefix set valid for the communication. 706 HBAs provide protection against time shifting attacks [8], [9]. In 707 the multihoming context, an attacker would perform a time-shifted 708 attack in the following way: an attacker placed along the path of the 709 communication will modify the packets to include an additional 710 address as a valid address for the communication. Then the attacker 711 would leave the on-path location, but the effects of the attack would 712 remain (i.e. the address would still be considered as a valid address 713 for that communication). Next we will present how HBAs can be used 714 to prevent such attacks. 716 If the attacker is not on-path when the initial CGA Parameter Data 717 Structure is exchanged, his only possibility to launch a redirection 718 attack is to fake the signature of the message for adding new 719 addresses using CGA capabilities of the addresses. This implies 720 discovering the public key used in the CGA Parameter Data Structure 721 and then cracking the key pair, which doesn't seem feasible. So in 722 order to launch a redirection attack, the attacker needs to be on- 723 path when the CGA Parameter Data Structure is exchanged, so he can 724 modify it. Now, in order to launch the redirection attack, the 725 attacker needs to add his own prefix in the prefix set of the CGA 726 Parameter Data Strcutre. We have seen in the previous section that 727 there are two possible approaches for this: 729 1. Find the right Modifier value, so that the address initially used 730 in the communication is contained in the new HBA set. The cost of 731 this attack is O(2(59+16*Sec)) iterations of the generation 732 process, so it is deemed unfeasible 733 2. Use any Modifier value, so that the address initially used in the 734 communication is probably not included in the HBA set. In this 735 case, the attacker must remain on-path, since he needs to rewrite 736 the address carried in the packets (if not the endpoints will 737 notice a change in the address used in the communication). This 738 essentially means that the attacker cannot launch a time-shifted 739 attack, but he must be a full time man-in-the-middle. 741 So, the conclusion is that HBAs provide protection against time- 742 shifted attacks 744 HBAs do not provide complete protection against flooding attacks, 745 However, HBAs make very difficult to launch a flooding attack towards 746 a specific address. It is possible though, to launch a flooding 747 attack against a prefix. 749 Suppose that an attacker has easy access to a prefix PX::/nX and that 750 he wants to launch a flooding attack to a host located in the address 751 P:iid. The attack would consist in establishing a communication with 752 a server S and requesting a heavy flow from it. Then simply redirect 753 the flow to P:iid, flooding the target. In order to perform this 754 attack the attacker need to generate an HBA set including P and PX in 755 the prefix set and that the resulting HBA set contains P:iid. In 756 order to do this, the attacker need to find the appropriate Modifier 757 value. The expected number of attempts required to find such 758 Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can 759 conclude that such attack is not feasible. 761 However, the target of a flooding attack is not limited to specific 762 hosts, but it can also be launched against other element of the 763 infrastructure, such as router or access links. In order to do that, 764 the attacker can establish a communication with a server S and 765 request a download of a heavy flow. Then, the attacker redirects the 766 communication to any address of the target network. Even if the 767 target address is not assigned to any host, the flow will flood the 768 access link of the target site, and the site access router will also 769 suffer the overload. Such attack cannot be prevented using HBAs, 770 since the attacker can easily generate an HBA set using his own 771 prefix and the target network prefix. In order to prevent such 772 attacks, additional mechanisms are required, such as reachability 773 tests. 775 9.2. Privacy Considerations 777 HBAs can be used as RFC 3041 [5]. addresses. If a node wants to use 778 temporary addresses, it will need to periodically generate new HBA 779 sets. The effort required for this operation depends on the Sec 780 parameter value. If Sec=0, then the cost of generating a new HBA set 781 is similar to the cost of generating a random number i.e. one 782 iteration of the HBA set generation procedure. However, if Sec>0, 783 then the cost of generating an HBA set is significantly increased, 784 since it required O(2(16*Sec)) iterations of the generation process. 785 In this case, depending on the frequency of address change required, 786 the support for RFC 3041 address may be more expensive. 788 9.3. Interaction with IPSec. 790 In the case that both IPSec and CGA/HBA address are used 791 simultaneously, it is possible that two public keys are available in 792 a node, one for IPSec and another one for the CGA/HBA operation. In 793 this case, an improved security can be achieved by verifying that the 794 keys are related somehow, (in particular if the same key is used for 795 both purposes). 797 10. Contributors 799 This document was originally produced of a MULTI6 design team 800 consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo 801 Braun, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret 802 Wasserman, and Jukka Ylitalo. 804 11. Acknowledgments 806 The initial discussion about HBA benefited from contributions from 807 Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra. 809 The HBA-set generation and HBA verification processes described in 810 this document contain several steps extracted from [1]. 812 Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka 813 Savola and Brian Carpenter have reviewed this document and provided 814 valuable comments. 816 We would also like to thanks Francis Dupont (ENST) for providing the 817 first implementation of HBA 819 12. Change Log 821 To be removed prior publication 823 12.1. Changes from draft-ietf-shim6-hba-00 to draft-ietf-multi6-hba-01 825 Changed the format of the Multi-Prefix extension to make it compliant 826 with the generic TLV format proposed for CGA extensions 828 Added IANA considerations section 830 Added DNS considerations section 832 12.2. Changes from draft-ietf-multi6-hba-00 to draft-ietf-shim6-hba-00 834 Editorial changes 836 12.3. Changes from draft-bagnulo-multi6dt-hba-00 to 837 draft-ietf-multi6-hba-00 839 Added "Example of HBA application to a multihoming scenario" section 841 Added Privacy Considerations section 843 Added flooding attacks comments in the Security Considerations 844 section 846 Added the Multi-Prefix extension in step 6.1 of the HBA-set 847 generation process 849 Added the Security considerations when using HBAs in a multi6 850 protocol sub-section in the Security Considerations section 852 Added Ext type value recommended for trials 854 Changed the name of the draft 856 Some rewording 858 13. References 860 13.1. Normative References 862 [1] Aura, T., "Cryptographically Generated Addresses (CGA)", 863 RFC 3972, April 2004. 865 [2] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 866 "SEcure Neighbor Discovery (SEND)", RFC 3971, July 2004. 868 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 869 Public Key Infrastructure Certificate and Certificate Revocation 870 List (CRL) Profile", RFC 3280, April 2002. 872 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 873 Addressing Architecture", RFC 3513, April 2003. 875 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless 876 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 878 [6] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses 879 (CGA) Extension Field Format", draft-bagnulo-shim6-cga-ext-02 880 (work in progress), October 2005. 882 [7] Nordmark, E., "Level 3 multihoming shim protocol", 883 draft-ietf-shim6-proto-01 (work in progress), October 2005. 885 13.2. Informative References 887 [8] Nordmark, E., "Threats relating to IPv6 multihoming solutions", 888 draft-ietf-multi6-multihoming-threats-01 (work in progress), 889 September 2004. 891 [9] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 892 Nordmark, "Mobile IP version 6 Route Optimization Security 893 Design Background", draft-ietf-mip6-ro-sec-01 (work in 894 progress), July 2004. 896 [10] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying 897 Cryptographically Generated Addresses to Optimize MIPv6 (CGA- 898 OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in progress), 899 June 2004. 901 Author's Address 903 Marcelo Bagnulo 904 Universidad Carlos III de Madrid 905 Av. Universidad 30 906 Leganes, Madrid 28911 907 SPAIN 909 Phone: 34 91 6249500 910 Email: marcelo@it.uc3m.es 911 URI: http://www.it.uc3m.es 913 Intellectual Property Statement 915 The IETF takes no position regarding the validity or scope of any 916 Intellectual Property Rights or other rights that might be claimed to 917 pertain to the implementation or use of the technology described in 918 this document or the extent to which any license under such rights 919 might or might not be available; nor does it represent that it has 920 made any independent effort to identify any such rights. Information 921 on the procedures with respect to rights in RFC documents can be 922 found in BCP 78 and BCP 79. 924 Copies of IPR disclosures made to the IETF Secretariat and any 925 assurances of licenses to be made available, or the result of an 926 attempt made to obtain a general license or permission for the use of 927 such proprietary rights by implementers or users of this 928 specification can be obtained from the IETF on-line IPR repository at 929 http://www.ietf.org/ipr. 931 The IETF invites any interested party to bring to its attention any 932 copyrights, patents or patent applications, or other proprietary 933 rights that may cover technology that may be required to implement 934 this standard. Please address the information to the IETF at 935 ietf-ipr@ietf.org. 937 Disclaimer of Validity 939 This document and the information contained herein are provided on an 940 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 941 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 942 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 943 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 944 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 945 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 947 Copyright Statement 949 Copyright (C) The Internet Society (2005). This document is subject 950 to the rights, licenses and restrictions contained in BCP 78, and 951 except as set forth therein, the authors retain all their rights. 953 Acknowledgment 955 Funding for the RFC Editor function is currently provided by the 956 Internet Society.