idnits 2.17.1 draft-ietf-shim6-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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 909. ** 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 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.) ** 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 255: '...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 == Line 81 has weird spacing: '...SP only annou...' == Line 648 has weird spacing: '...eet the above...' == Line 777 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 (July 11, 2005) is 6861 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: 8 errors (**), 0 flaws (~~), 8 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: January 12, 2006 July 11, 2005 6 Hash Based Addresses (HBA) 7 draft-ietf-shim6-hba-00 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 January 12, 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 . . . . . . . . . . . . . . 5 55 3. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . 7 56 4. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . 9 57 5. HBA verification . . . . . . . . . . . . . . . . . . . . . . 12 58 6. Example of HBA application to a multihoming scenario . . . . 15 59 6.1 Dynamic Address Set Support . . . . . . . . . . . . . . . 17 60 7. Security considerations . . . . . . . . . . . . . . . . . . 19 61 7.1 Security considerations when using HBAs in a multi6 62 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 20 63 7.2 Privacy Considerations . . . . . . . . . . . . . . . . . . 22 64 7.3 Interaction with IPSec. . . . . . . . . . . . . . . . . . 22 65 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24 67 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 25 68 10.1 Changes from draft-bagnulo-multi6dt-hba-00 to 69 draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . 25 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 71 11.1 Normative References . . . . . . . . . . . . . . . . . . 26 72 11.2 Informative References . . . . . . . . . . . . . . . . . 26 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 74 Intellectual Property and Copyright Statements . . . . . . . 28 76 1. Introduction 78 In order to preserve inter-domain routing system scalability, IPv6 79 sites obtain addresses from their Internet Service Providers. Such 80 addressing strategy significantly reduces the amount of routes in the 81 global routing tables, since each ISP only announces routes to its 82 own address blocks, rather than announcing one route per customer 83 site. However, this addressing scheme implies that multihomed sites 84 will obtain multiple prefixes, one per ISP. Moreover, since each ISP 85 only announces its own address block, a multihomed site will be 86 reachable through a given ISP if the ISP prefix is contained in the 87 destination address of the packets. This means that, if an 88 established communication needs to be routed through different ISPs 89 during its lifetime, addresses with different prefixes will have to 90 be used. Changing the address used to carry packets of an 91 established communication exposes the communication to numerous 92 attacks, as described in [6], so security mechanisms are required to 93 provide the required protection to the involved parties. This memo 94 describes a tool that can be used to provide protection against some 95 of the potential attacks, in particular against future/ premeditated 96 attacks (a.k.a. time shifting attacks in [7]). 98 It should be noted that, as opposed to the mobility case where the 99 addresses that will be used by the mobile node are not known a 100 priori, the multiple addresses available to a host within the 101 multihomed site are pre-defined and known in advance in most of the 102 cases. The mechanism proposed in this memo takes advantage of this 103 address set stability, and provides a secure binding between all the 104 addresses of a node in a multihomed site. The mechanism does so 105 without requiring the usage of public key cryptography, providing a 106 cost efficient alternative to public key cryptography based schemes. 108 This memo describes a mechanism to provide a secure binding between 109 the multiple addresses with different prefixes available to a host 110 within a multihomed site. The main idea is that information about 111 the multiple prefixes is included within the addresses themselves. 112 This is achieved by generating the interface identifiers of the 113 addresses of a host as hashes of the available prefixes and a random 114 number. Then, the multiple addresses are obtained by prepending the 115 different prefixes to the generated interface identifiers. The 116 result is a set of addresses, called Hash Based Addresses (HBAs), 117 that are inherently bound. A cost efficient mechanism is available 118 to determine if two addresses belong to the same set, since given the 119 prefix set and the additional parameters used to generate the HBA, a 120 single hash operation is enough to verify if an HBA belongs to a 121 given HBA set. No public key operations are involved in the 122 verification process. In addition, it should also be noted that it 123 is not required that all interface identifiers of the addresses of an 124 HBA set are equal, preserving some degree of privacy through changes 125 in the addresses used during the communications. 127 2. CGA compatibility considerations 129 As described in previous section, the HBA technique uses the 130 interface identifier part of the IPv6 address to encode information 131 about the multiple prefixes available to a multihomed host. However, 132 the interface identifier is also used to carry cryptographic 133 information when Cryptographic Generated Addresses [1] are used. 134 Therefore, conflicting usages of the interface identifier bits may 135 result if this is not taken into account during the HBA design. 136 There are at least two valid reasons to provide CGA-HBA 137 compatibility: 139 First, the current Secure Neighbor Discovery specification [2] uses 140 the CGAs defined in [1] to prove address ownership. If HBAs are not 141 compatible with CGAs, then nodes using HBAs for multihoming wouldn't 142 be able to do Secure Neighbor Discovery using the same addresses (at 143 least the parts of SeND that require CGAs). This would imply that 144 nodes would have to choose between security (from SeND) and fault 145 tolerance (from multi6). In addition to SeND, there are other 146 protocols that are considering to benefit from the advantages offered 147 by the CGA scheme, such as mobility support protocols [8]. Those 148 protocols would also become incompatible with HBAs if HBAs are not 149 compatible with CGAs. 151 Second, CGAs provide additional features that cannot be achieved 152 using only HBAs. In particular, because of its own nature, the HBA 153 technique only supports a predetermined prefix set that is known at 154 the time of the generation of the HBA set. No additions of new 155 prefixes to this original set are supported after the HBA set 156 generation. In most of the cases relevant for site multihoming, this 157 is not a problem because the prefix set available to a multihomed set 158 is not very dynamic. New prefixes may be added in a multihomed site 159 when a new ISP is available, but the timing of those events are 160 rarely in the same time scale than the lifetime of established 161 communications. It is then enough for many situations that the new 162 prefix is not available for established communications and that only 163 new communications benefit from it. However, in the case that such 164 functionality is required, it is possible to use CGAs to provide it. 165 This approach clearly requires that HBA and CGA approaches are 166 compatible. If this is the case, it then would be possible to create 167 HBA/CGA addresses that support CGA and HBA functionality 168 simultaneously. The inputs to the HBA/CGA generation process will be 169 both a prefix set and a public key. In this way, a node that has 170 established a communication using one address of the CGA/HBA set can 171 tell its peer to use the HBA verification when one of the addresses 172 of its HBA/CGA set is used as locator in the communication or to use 173 CGA (public/private key based) verification when a new address that 174 does not belong to the HBA/CGA set is used as locator in the 175 communication. 177 So, because of the aforementioned reasons, it is a goal of the HBA 178 design to define HBAs in a way that they are compatible with CGAs as 179 defined in [1] and their usages described in [2] (Consequently, to 180 understand the rest of this note, the reader should be familiar with 181 the CGA specification defined in [1]). This means that it must be 182 possible to generate addresses that are both an HBA and a CGA i.e. 183 that the interface identifier contains cryptographic information of 184 CGA and the prefix-set information of an HBA. The CGA specification 185 already considers the possibility of including additional information 186 into the CGA generation process through the usage of Extension Fields 187 in the CGA Parameter Data Structure. It is then possible to define a 188 Multi-Prefix Extension for CGA so that the prefix set information is 189 included in the interface identifier generation process. 191 Even though a CGA compatible approach is adopted, it should be noted 192 that HBAs and CGAs are different concepts. In particular, the CGA is 193 inherently bound to a public key, while a HBA is inherently bound to 194 a prefix set. This means that a public key is not strictly required 195 to generate an HBA. Because of that, we define three different types 196 of addresses: 198 - CGA-only addresses: These are addresses generated as specified in 199 [1] without including the Multi-Prefix Extension. They are bound 200 to a public key and to a single prefix (contained in the basic CGA 201 Parameter Data Structure). These addresses can be used for SeND 202 [2] and if used for multihoming, their application will have to be 203 based on the public key usage. 205 - CGA/HBA addresses: These addresses are CGAs that include the Multi- 206 Prefix Extension in the CGA Parameters Data Structure used for 207 their generation. These addresses are bound to a public key and a 208 prefix set and they provide both CGA and HBA functionalities. 209 They can be used for SeND as defined in [2] and for any usage 210 defined for HBA (such as a multi6 protocol) 212 - HBA-only addresses: These addresses are bound to a prefix set but 213 they are not bound to a public key. Because CGA compatibility, 214 the CGA Parameter Data Structure will be used for their 215 generation, but a random nonce will be included in the Public Key 216 field instead of a public key. These addresses can be used for 217 HBA based multihoming protocols, but they cannot be used for SeND, 219 3. Multi-Prefix Extension for CGA 221 The format of the Multi-Prefix Extension is the following: 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Ext Type | Ext Len |P| Reserved | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 + Prefix[1] + 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | | 233 + Prefix[2] + 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 . . . 237 . . . 238 . . . 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | | 241 + Prefix[n] + 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Ext Type: 8-bit identifier of the Multi-Prefix Extension (TBD IANA) 246 (Meanwhile, the 0x12 value is recommended for trails) 248 Ext Len: 8-bit unsigned integer. Length of the Extension in 8-octet 249 units, not including the first 4 octets. 251 P flag: Set if a public key is included in the Public Key field of 252 the CGA Parameter Data Structure. Reset if a additional Modifier 253 bits are included in the CGA Parameter Data Structure. 255 Reserved: 15-bit reserved field. MUST be initialized to zero, and 256 ignored upon receipt.. 258 Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n. 260 4. HBA-Set Generation 262 The HBA generation process is based on the CGA generation process 263 defined in section 4 of [1]. The goal is to require the minimum 264 amount of changes to the CGA generation process. 266 The CGA generation process has three inputs: a 64-bit subnet prefix, 267 a public key (encoded in DER as an ASN.1 structure of the type 268 SubjectPublicKeyInfo), and the security parameter Sec. 270 The main difference between the CGA generation and the HBA generation 271 is that while a CGA can be generated independently, all the HBAs of a 272 given HBA set have to be generated using the same parameters, which 273 implies that the generation of the addresses of an HBA set will occur 274 in a coordinated fashion. In this memo, we will describe a mechanism 275 to generate all the addresses of a given HBA set. The generation 276 process of each one of the HBA address of an HBA set will be heavily 277 based in the CGA generation process defined in [1]. More precisely, 278 the HBA set generation process will be defined as a sequence of 279 lightly modified CGA generations. 281 The changes required in the CGA generation process when generating a 282 single HBA are the following: First, the Multi-Prefix Extension has 283 to be included in the CGA Parameters Data Structure. Second, in the 284 case that the address being generated is an HBA-only address, a 285 random nonce (encoded in DER as an ASN.1 structure of the type 286 SubjectPublicKeyInfo) will have to be used as input instead of a 287 valid public key. 289 The resulting HBA-set generation process is the following: 291 The inputs to the HBA generation process are: 293 o A vector of n 64-bit prefixes 295 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: 303 o An HBA-set 305 o their respective CGA Parameters Data Structures 307 The steps of the HBA-set generation process are: 309 1. Multi-Prefix Extension generation. Generate the Multi-Prefix 310 Extension with the format defined in section 3. Include the 311 vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext 312 Len field value is (n*8). If a public key is provided, then the P 313 flag is set. Otherwise, the P flag is reset. 315 2. Modifier generation. Generate a Modifier as a random or 316 pseudorandom 128-bit value. If a public key has not been provided 317 as an input, generate the Extended Modifier as a 384-bit random or 318 pseudorandom value. Encode the Extended Modifier value as a RSA 319 key in a DER-encoded ASN.1 structure of the type 320 SubjectPublicKeyInfo defined in the Internet X.509 certificate 321 profile [3]. 323 3. Concatenate from left to right the Modifier, 9 zero octets, the 324 encoded public key or the encoded Extended Modifier (if no public 325 key was provided) and the Multi-Prefix Extension. Execute the 326 SHA-1 algorithm on the concatenation. Take the 112 leftmost bits 327 of the SHA-1 hash value. The result is Hash2. 329 4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 330 all zero (or if Sec=0), continue with step (5). Otherwise, 331 increment the modifier by one and go back to step (3). 333 5. Set the 8-bit collision count to zero. 335 6. For i=1 to n do 337 6.1. Concatenate from left to right the final Modifier value, 338 Prefix[i], the collision count, the encoded public key or the 339 encoded Extended Modifier (if no public key was provided) and 340 the Multi-Prefix Extension. Execute the SHA-1 algorithm on the 341 concatenation. Take the 64 leftmost bits of the SHA-1 hash 342 value. The result is Hash1[i]. 344 6.2. Form an interface identifier from Hash1[i] by writing the 345 value of Sec into the three leftmost bits and by setting bits 6 346 and 7 (i.e., the "u" and "g" bits) both to zero. 348 6.3. Generate address HBA[i] by concatenating Prefix[i] and the 349 64-bit interface identifier to form a 128-bit IPv6 address with 350 the subnet prefix to the left and interface identifier to the 351 right as in a standard IPv6 address [4]. 353 6.4. Perform duplicate address detection if required. If an 354 address collision is detected, increment the collision count by 355 one and go back to step (6). However, after three collisions, 356 stop and report the error. 358 6.5. Form the CGA Parameters Data Structure that corresponds to 359 HBA[i] by concatenating from left to right the final modifier 360 value, Prefix[i], the final collision count value, the encoded 361 public key or the encoded Extended Modifier and the Multi- 362 Prefix Extension. 364 [Note: most of the steps of the process are taken from [1]] 366 5. HBA verification 368 HBAs are constructed as a CGA Extension, so a properly formated HBA 369 and its correspondent CGA Parameter Data Structure will successfully 370 finish the verification process described in section 5 of [1]. Such 371 verification is useful when the goal is the verification of the 372 binding between the public key and the HBA. 374 However, for multihoming applications, it is also relevant to verify 375 if a given HBA address belongs to a certain HBA set. An HBA set is 376 identified by a CGA Parameter Data structure that contains a Multi- 377 Prefix Extension. So, it is then needed to verify if an HBA belongs 378 to the HBA set defined by a CGA Parameter Data Structure. It should 379 be noted that it may be needed to verify if an HBA belongs to the HBA 380 set defined by the CGA Parameter Data Structure of another HBA of the 381 set. If this is the case, the CGA verification process as defined in 382 [1] will fail, because the prefix included in the Subnet Prefix field 383 of the CGA Parameter Data Structure will not match with the one of 384 the HBA that is being verified. However, this not means that this 385 HBA does not belong to the HBA set. In order to address this issue, 386 it is only required to verify that the HBA prefix is included in 387 prefix set defined in the Multi-Prefix Extension, and if this is the 388 case, then substitute the prefix included in the Subnet Prefix field 389 by the prefix of the HBA, and then perform the CGA verification 390 process defined in [1]. 392 So, the process to verify that an HBA belongs to an HBA set 393 determined by a CGA Parameter Data Structure is called HBA 394 verification and it is the following: 396 The inputs to the HBA verification process are: 398 o An HBA 400 o An CGA Parameter Data Structure 402 The steps of the HBA verification process are the following: 404 1. Verify that the 64-bit HBA prefix is included in the prefix set of 405 the Multi-Prefix Extension. If it is not included, the 406 verification fails. If it is included, replace the prefix 407 contained in the Subnet Prefix field of the CGA Parameter Data 408 Structure by the 64-bit HBA prefix. 410 2. Run the verification process described in section 5 of [1] with 411 the HBA and the new CGA Parameters Data Structure (including the 412 Multi-Prefix Extension) as inputs. The steps of the process are 413 included below, extracted from [1] 415 2.1. Check that the collision count in the CGA Parameters Data 416 Structure is 0, 1 or 2. The CGA verification fails if the 417 collision count is out of the valid range. 419 2.2. Check that the subnet prefix in the CGA Parameters Data 420 Structure is equal to the subnet prefix (i.e., the leftmost 64 421 bits) of the address. The CGA verification fails if the prefix 422 values differ. [Note: This step is trivially successful 423 because step 1] 425 2.3. Execute the SHA-1 algorithm on the CGA Parameters Data 426 Structure. Take the 64 leftmost bits of the SHA-1 hash value. 427 The result is Hash1. 429 2.4. Compare Hash1 with the interface identifier (i.e., the 430 rightmost 64 bits) of the address. Differences in the three 431 leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) 432 are ignored. If the 64-bit values differ (other than in the 433 five ignored bits), the CGA verification fails. 435 2.5. Read the security parameter Sec from the three leftmost bits 436 of the 64-bit interface identifier of the address. (Sec is an 437 unsigned 3-bit integer.) 439 2.6. Concatenate from left to right the modifier, 9 zero octets, 440 and the public key, and any extension fields [in this case, the 441 Multi-Prefix Extension will be included, at least] that follow 442 the public key in the CGA Parameters data structure. Execute 443 the SHA-1 algorithm on the concatenation. Take the 112 444 leftmost bits of the SHA-1 hash value. The result is Hash2. 446 2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any 447 one of them is non-zero, the CGA verification fails. 448 Otherwise, the verification succeeds. (If Sec=0, the CGA 449 verification never fails at this step.) 451 6. Example of HBA application to a multihoming scenario 453 In this section, we will describe a possible application of the HBA 454 technique to IPv6 multi-homing. 456 We will consider the following scenario: a multihomed site obtains 457 Internet connectivity through two providers ISPA and ISPB. Each 458 provider has delegated a prefix to the the multihomed site 459 (PrefA::/nA and PrefB::/nb respectively). In order to benefit from 460 multihoming, the hosts within the multihomed site will configure 461 multiple IP addresses, one pre available prefix. The resulting 462 configuration is depicted in the next figure. 464 +-------+ 465 | Host2 | 466 |IPHost2| 467 +-------+ 468 | 469 | 470 (Internet) 471 / \ 472 / \ 473 +------+ +------+ 474 | ISPA | | ISPB | 475 | | | | 476 +------+ +------+ 477 | | 478 \ / 479 \ / 480 +---------------------+ 481 | multihomed site | 482 | PA::/nA | 483 | PB::/nB +------+ | 484 | |Host1 | | 485 | +------+ | 486 +---------------------+ 488 We assume that both Host1 and Host2 support the multi6 protocol. 490 Host2 in not located in a multihomed site, so there is no need for 491 him to create HBAs (it must be able to verify them though, in order 492 to support the multi6 protocol, as we will describe next.) 493 Host1 is located in the multihomed site, so it will generate its 494 addresses as HBAs. In order to do that, it needs to execute the HBA- 495 set generation process as detailed in Section 4 of this memo. The 496 inputs of the HBa-set generation process will be: a prefix vector 497 containing the two prefixes available in its link i.e. PA:LA::/64 498 and PB:LB::/64, a Sec parameter value, and optionally a public key. 499 In this case we will assume that a public key is provided so that we 500 can also illustrate how a renumbering event can be supported when 501 HBA/CGA addresses are used (see the sub-section referring to dynamic 502 address set support). So, after executing the HBA-set generation 503 process, Host1 will have: an HBA-set consisting in two addresses i.e. 504 PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data 505 Structures i.e. CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are 506 different but both contain information about the prefix set available 507 in the multihomed site. 509 We will next consider a communication between Host1 and Host2. 510 Assume that both ISPs of the multihomed site are working properly, so 511 any of the available addresses in Host1 can be used for the 512 communication. Suppose then that the communication is established 513 using PA:LA:iidA and IPHost2 for Host1 and Host2 respectively. So 514 far, no special multi6 support has been required, and PA:LA:iidA is 515 used as any other global IP address 517 Suppose that at a certain moment one of the hosts involved in the 518 communication decides that multihoming support is required in this 519 communication (this basically means that one of the hosts involved in 520 the communication desires enhanced fault tolerance capabilities for 521 this communication, so that if an outage occurs, the communication 522 can be rehomed to an alternative provider). 524 At this moment, the capabilities detection protocol will be executed, 525 in order to verify that both ends support the multi6 protocol (see 526 [10].). Once that multi6 support is confirmed, additional parameters 527 will be exchanged, like a context tag for identifying packets that 528 belong to this communication (see [9].). In addition, Host1 will 529 send CGA_PDS_A to Host2. 531 After the reception of CGA_PDS_A, Host2 will verify that the received 532 CGA Parameter Data Structure corresponds to the address being used in 533 the communication PA:LA:iidA. this means that Host2 will execute the 534 HBA verification process described in Section 5 of this memo with PA: 535 LA:iidA and CGA_PDS_A as inputs. (The exact moment of this 536 verification depends on the details of the multi6 protocol). In this 537 case, the verification will succeed since the CGA Parameter Data 538 Structure and the addresses used 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 multi6 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 multi6 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. Security considerations 616 The goal of HBAs is to create a group of addresses that are securely 617 bound, so that they can be used interchangeably when communicating 618 with a node. If there is no secure binding between the different 619 addresses of a node, a number of attacks are enabled, as described in 620 [6]. It particular, it would possible for an attacker to redirect 621 the communications of a victim to an address selected by the 622 attacker, hijacking the communication. When using HBAs, only the 623 addresses belonging to an HBA set can be used interchangeably, 624 limiting the addresses that can be used to redirect the communication 625 to a well, pre-determined set, that belongs to the original node 626 involved in the communication. So, when using HBAs, a node that is 627 communicating using address A can redirect the communication to a new 628 address B if and only if B belongs to the same HBA set than A. 630 This means that if an attacker wants to redirect communications 631 addressed to address HBA1 to an alternative address IPX, the attacker 632 will need to create a CGA Parameters data structure that generates an 633 HBA set that contains both HBA1 and IPX. 635 In order to generate the required HBA set, the attacker needs to find 636 a CGA Parameter data structure that fulfills the following 637 conditions: 639 o the prefix of HBA1 and the prefix of IPX are included in the 640 Multi-Prefix Extension 642 o HBA1 is included in the HBA set generated. 644 (this assumes that it is acceptable for the attacker to redirect HBA1 645 to any address of the prefix of IPX). 647 The remaining fields that can be changed at will by the attacker in 648 order to meet the above conditions are: the Modifier, other prefixes 649 in the Multi-Prefix Extension and other extensions. In any case, in 650 order to obtain the desired HBA set, the attacker will have to use a 651 brute force attack, which implies the generation of multiple HBA sets 652 with different parameters (for instance with a different Modifier) 653 until the desired conditions are meet. The expected number of times 654 that the generation process will have to be repeated until the 655 desired HBA set is found is exponentially related with the number of 656 bits containing hash information included in the interface identifier 657 of the HBA. Since 59 of the 64 bits of the interface identifier 658 contain hash bits, then the expected number of generations that will 659 have to be performed by the attacker are O(2^59). 661 The protection against brute force attacks can be improved increasing 662 the Sec parameter. A non zero Sec parameter implies that steps 3-4 663 of the generation process will be repeated O(2^(16*Sec)) times 664 (expected number of times). If we assimilate the cost of repeating 665 the steps 3-4 to the cost of generating the HBA address, we can 666 estimate the number of times that the generation is to be repeated in 667 O(2^(59+16*Sec)). 669 7.1 Security considerations when using HBAs in a multi6 protocol 671 In this section we will analyze the security provided by HBAs in the 672 context of a multi6 protocol as described in section 6 of this memo. 674 First of all, it must be noted that HBAs cannot prevent man-in-the- 675 middle (hereafter MITM) attacks. This means, that in the scenario 676 described in Section 6, if an attacker is located along the path 677 between Host1 and Host2 during the lifetime of the communication, the 678 attacker will be able to change the addresses used for the 679 communication. This means that he will be able to change the 680 addresses used in the communication, adding or removing prefixes at 681 his will. However, the attacker must make sure that the CGA 682 Parameter Data Structure and the HBA set is changed accordingly. this 683 essentially means that the attacker will have to change the interface 684 identifier part of the addresses involved, since a change in the 685 prefix set will result in different interface identifiers of the 686 addresses of the HBA set, unless the appropriate Modifier value is 687 used (which would require O(2(59+16*Sec)) attempts). So, HBA don't 688 provide MITM attacks protection, but a MITM attacker will have to 689 change the address used in the communication in order to change the 690 prefix set valid for the communication. 692 HBAs provide protection against future attacks [6], (a.k.a. time 693 shifting attacks in [7]. In the multihoming context, an attacker 694 would perform a time-shifted attack in the following way: an attacker 695 placed along the path of the communication will modify the packets to 696 include an additional address as a valid address for the 697 communication. then the attacker would leave the on-path location, 698 but the effects of the attack would remain (i.e. the address would 699 still be considered as a valid address for that communication). Next 700 we will present how HBAs can be used to prevent such attacks. 702 If the attacker is not on-path when the initial CGA Parameter Data 703 Structure is exchanged, his only possibility to launch a redirection 704 attack is to fake the signature of the message for adding new 705 addresses using CGA capabilities of the addresses. This implies 706 discovering the public key used in the CGA Parameter Data Structure 707 and then cracking the key pair, which doesn't seem feasible, So in 708 order to launch a redirection attack, the attacker needs to be on- 709 path when the CGA Parameter Data Structure is exchanged, so he can 710 modify it. Now, in order to launch the redirection attack, the 711 attacker needs to add his own prefix in the prefix set of the CGA 712 Parameter Data Strcutre. We have seen in the previous section that 713 there are two possible approaches for this: 715 1. Find the right Modifier value, so that the address initially used 716 in the communication is contained in the new HBA set. The cost of 717 this attack is O(2(59+16*Sec)) iterations of the generation 718 process, so it deemed unfeasible 720 2. Use any Modifier value, so that the address initially used in the 721 communication is probably not included in the HBA set. In this 722 case, the attacker must remain on-path, since he needs to rewrite 723 the address carried in the packets (if not the endpoints will 724 notice a change in the address used in the communication). This 725 essentially means that the attacker cannot launch a time-shifted 726 attack, but he must be a full time man-in-the-middle. 728 So, the conclusion is that HBAs provide protection against time- 729 shifted attacks 731 HBAs do not provide complete protection against flooding attacks, 732 However, HBAs make very difficult to launch a flooding attack towards 733 a specific address. It is possible though, to launch a flooding 734 attack against a prefix. 736 Suppose that an attacker has easy access to a prefix PX::/nX and that 737 he wants to launch a flooding attack to a host located in the address 738 P:iid. The attack would consist in establishing a communication with 739 a server S and requesting a heavy flow from it. Then simply redirect 740 the flow to P:iid, flooding the target. In order to perform this 741 attack the attacker need to generate an HBA set including P and PX in 742 the prefix set and that the resulting HBA set contains P:iid. In 743 order to do this, the attacker need to find the appropriate Modifier 744 value. The expected number of attempts required to find such 745 Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can 746 conclude that such attack is not feasible. 748 However, the target of a flooding attack is not limited to specific 749 hosts, but it can also be launched against other element of the 750 infrastructure, such as router or access links. In order to do that, 751 the attacker can establish a communication with a server S and 752 request a download of a heavy flow. Then, the attacker redirects the 753 communication to any address of the target network. Even if the 754 target address is not assigned to any host, the flow will flood the 755 access link of the target site, and the site access router will also 756 suffer the overload. Such attack cannot be prevented using HBAs, 757 since the attacker can easily generate an HBA set using his own 758 prefix and the target network prefix. In order to prevent such 759 attacks, additional mechanisms are required, such as reachability 760 tests. 762 7.2 Privacy Considerations 764 HBAs can be used as RFC 3041 [5]. addresses. If a node wants to use 765 temporary addresses, it will need to periodically generate new HBA 766 sets. The effort required for this operation depends on the Sec 767 parameter value. If Sec=0, then the cost of generating a new HBA set 768 is similar to the cost of generating a random number i.e. one 769 iteration of the HBA set generation procedure. However, if Sec>0, 770 then the cost of generating an HBA set is significantly increased, 771 since it required O(2(16*Sec)) iterations of the generation process. 772 In this case, depending on the frequency of address change required, 773 the support for RFC 3041 address may be more expensive. 775 7.3 Interaction with IPSec. 777 In the case that both IPSec and CGA/HBA address are used 778 simultaneously, it is possible that two public keys are available in 779 a node, one for IPSec and another one for the CGA/HBA operation. In 780 this case, an improved security can be achieved by verifying that the 781 keys are related somehow, (in particular if the same key is used for 782 both purposes). 784 8. Contributors 786 This document was originally produced of a MULTI6 design team 787 consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo 788 Braun, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret 789 Wasserman, and Jukka Ylitalo. 791 9. Acknowledgments 793 The initial discussion about HBA benefited from contributions from 794 Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra. 796 The HBA-set generation and HBA verification processes described in 797 this document contain several steps extracted from [1]. 799 Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Savola and 800 Brian Carpenter have reviewed this document and provided valuable 801 comments. 803 We would also like to thanks Francis Dupont (ENST) for providing the 804 first implementation of HBA 806 10. Change Log 808 10.1 Changes from draft-bagnulo-multi6dt-hba-00 to 809 draft-ietf-multi6-hba-00 811 Added "Example of HBA application to a multihoming scenario" section 813 Added Privacy Considerations section 815 Added flooding attacks comments in the Security Considerations 816 section 818 Added the Multi-Prefix extension in step 6.1 of the HBA-set 819 generation process 821 Added the Security considerations when using HBAs in a multi6 822 protocol sub-section in the Security Considerations section 824 Added Ext type value recommended for trials 826 Changed the name of the draft 828 Some rewording 830 11. References 832 11.1 Normative References 834 [1] Aura, T., "Cryptographically Generated Addresses (CGA)", 835 draft-ietf-send-cga-06 (work in progress), April 2004. 837 [2] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 838 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 839 (work in progress), July 2004. 841 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 842 Public Key Infrastructure Certificate and Certificate Revocation 843 List (CRL) Profile", RFC 3280, April 2002. 845 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 846 Addressing Architecture", RFC 3513, April 2003. 848 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless 849 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 851 11.2 Informative References 853 [6] Nordmark, E., "Threats relating to IPv6 multihoming solutions", 854 draft-ietf-multi6-multihoming-threats-01 (work in progress), 855 September 2004. 857 [7] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 858 Nordmark, "Mobile IP version 6 Route Optimization Security 859 Design Background", draft-ietf-mip6-ro-sec-01 (work in 860 progress), July 2004. 862 [8] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying 863 Cryptographically Generated Addresses to Optimize MIPv6 (CGA- 864 OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in progress), 865 June 2004. 867 [9] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", 868 draft-nordmark-multi6dt-shim-00 (work in progress), 869 October 2004. 871 [10] Bagnulo, M. and J. Arkko, "Functional decomposition of the M6 872 protocol", draft-bagnulo-multi6dt-functional-dec-00 (work in 873 progress), October 2004. 875 Author's Address 877 Marcelo Bagnulo 878 Universidad Carlos III de Madrid 879 Av. Universidad 30 880 Leganes, Madrid 28911 881 SPAIN 883 Phone: 34 91 6249500 884 Email: marcelo@it.uc3m.es 885 URI: http://www.it.uc3m.es 887 Intellectual Property Statement 889 The IETF takes no position regarding the validity or scope of any 890 Intellectual Property Rights or other rights that might be claimed to 891 pertain to the implementation or use of the technology described in 892 this document or the extent to which any license under such rights 893 might or might not be available; nor does it represent that it has 894 made any independent effort to identify any such rights. Information 895 on the procedures with respect to rights in RFC documents can be 896 found in BCP 78 and BCP 79. 898 Copies of IPR disclosures made to the IETF Secretariat and any 899 assurances of licenses to be made available, or the result of an 900 attempt made to obtain a general license or permission for the use of 901 such proprietary rights by implementers or users of this 902 specification can be obtained from the IETF on-line IPR repository at 903 http://www.ietf.org/ipr. 905 The IETF invites any interested party to bring to its attention any 906 copyrights, patents or patent applications, or other proprietary 907 rights that may cover technology that may be required to implement 908 this standard. Please address the information to the IETF at 909 ietf-ipr@ietf.org. 911 Disclaimer of Validity 913 This document and the information contained herein are provided on an 914 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 915 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 916 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 917 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 918 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 919 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 921 Copyright Statement 923 Copyright (C) The Internet Society (2005). This document is subject 924 to the rights, licenses and restrictions contained in BCP 78, and 925 except as set forth therein, the authors retain all their rights. 927 Acknowledgment 929 Funding for the RFC Editor function is currently provided by the 930 Internet Society.