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