idnits 2.17.1 draft-ietf-shim6-hba-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1243. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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, 2007) is 5968 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. '5') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4941 (ref. '7') (Obsoleted by RFC 8981) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-08 Summary: 3 errors (**), 0 flaws (~~), 3 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 Intended status: Standards Track December 22, 2007 5 Expires: June 24, 2008 7 Hash Based Addresses (HBA) 8 draft-ietf-shim6-hba-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 24, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo describes a mechanism to provide a secure binding between 42 the multiple addresses with different prefixes available to a host 43 within a multihomed site. This mechanism employs either 44 Cryptographically Generated Addresses (CGAs) or a new variant of the 45 same theme that uses the same format in the addresses. The main idea 46 in the new variant is that information about the multiple prefixes is 47 included within the addresses themselves. This is achieved by 48 generating the interface identifiers of the addresses of a host as 49 hashes of the available prefixes and a random number. Then, the 50 multiple addresses are generated by prepending the different prefixes 51 to the generated interface identifiers. The result is a set of 52 addresses, called Hash Based Addresses (HBAs), that are inherently 53 bound to each other. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Motivations for the HBA design . . . . . . . . . . . . . . 6 63 4. Cryptographic Generated Addresses (CGA) compatibility 64 considerations . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . . 8 66 6. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . . 9 67 7. HBA verification . . . . . . . . . . . . . . . . . . . . . . . 12 68 7.1. Verification that a particular HBA address corresponds 69 to a given CGA Parameter Data Structure . . . . . . . . . 12 70 7.2. Verification that a particular HBA address belongs to 71 the HBA set associated to a given CGA Parameter Data 72 Structure . . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. Example of HBA application to a multihoming scenario . . . . . 14 74 8.1. Dynamic Address Set Support . . . . . . . . . . . . . . . 17 75 9. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 18 76 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 77 11. Security considerations . . . . . . . . . . . . . . . . . . . 19 78 11.1. Security considerations when using HBAs in the Shim6 79 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 11.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 23 81 11.3. SHA-1 Dependency Considerations. . . . . . . . . . . . . . 23 82 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 84 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 14.1. Changes from draft-ietf-shim6-hba-04 to 86 draft-ietf-multi6-hba-05 . . . . . . . . . . . . . . . . . 24 87 14.2. Changes from draft-ietf-shim6-hba-03 to 88 draft-ietf-multi6-hba-04 . . . . . . . . . . . . . . . . . 24 89 14.3. Changes from draft-ietf-shim6-hba-02 to 90 draft-ietf-multi6-hba-03 . . . . . . . . . . . . . . . . . 24 91 14.4. Changes from draft-ietf-shim6-hba-01 to 92 draft-ietf-multi6-hba-02 . . . . . . . . . . . . . . . . . 25 93 14.5. Changes from draft-ietf-shim6-hba-00 to 94 draft-ietf-multi6-hba-01 . . . . . . . . . . . . . . . . . 25 95 14.6. Changes from draft-ietf-multi6-hba-00 to 96 draft-ietf-shim6-hba-00 . . . . . . . . . . . . . . . . . 25 97 14.7. Changes from draft-bagnulo-multi6dt-hba-00 to 98 draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . . 25 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 15.1. Normative References . . . . . . . . . . . . . . . . . . . 26 101 15.2. Informative References . . . . . . . . . . . . . . . . . . 26 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 Intellectual Property and Copyright Statements . . . . . . . . . . 28 105 1. Introduction 107 In order to preserve inter-domain routing system scalability, IPv6 108 sites obtain addresses from their Internet Service Providers. Such 109 addressing strategy significantly reduces the amount of routes in the 110 global routing tables, since each ISP only announces routes to its 111 own address blocks, rather than announcing one route per customer 112 site. However, this addressing scheme implies that multihomed sites 113 will obtain multiple prefixes, one per ISP. Moreover, since each ISP 114 only announces its own address block, a multihomed site will be 115 reachable through a given ISP if the ISP prefix is contained in the 116 destination address of the packets. This means that, if an 117 established communication needs to be routed through different ISPs 118 during its lifetime, addresses with different prefixes will have to 119 be used. Changing the address used to carry packets of an 120 established communication exposes the communication to numerous 121 attacks, as described in [11], so security mechanisms are required to 122 provide the required protection to the involved parties. This memo 123 describes a tool that can be used to provide protection against some 124 of the potential attacks, in particular against future / premeditated 125 attacks (a.k.a. time shifting attacks in [12]). 127 This memo describes a mechanism to provide a secure binding between 128 the multiple addresses with different prefixes available to a host 129 within a multihomed site. 131 It should be noted that, as opposed to the mobility case where the 132 addresses that will be used by the mobile node are not known a 133 priori, the multiple addresses available to a host within the 134 multihomed site are pre-defined and known in advance in most of the 135 cases. The mechanism proposed in this memo employs either 136 Cryptographically Generated Addresses (CGAs) [2] or a new variant of 137 the same theme that uses the same format in the addresses. The new 138 variant, Hash Based Address (HBA), takes advantage of the address set 139 stability. In either case, a secure binding between the addresses of 140 a node in a multihomed site can be provided. CGAs employ public key 141 cryptography and can deal with changing address sets. HBAs employ 142 only symmetric key cryptography, and have smaller computational 143 requirements. 145 For the purposes of the Shim6 protocol, the other characteristics of 146 the CGAs and HBAs are similar. Both can be generated by the host 147 itself without any reliance on external infrastructure. Both employ 148 the same format of addresses and same format of data fed to generate 149 the addresses. It is not required that all interface identifiers of 150 a node's addresses are equal, preserving some degree of privacy 151 through changes in the addresses used during the communications. 153 The main idea in HBAs is that information about the multiple prefixes 154 is included within the addresses themselves. This is achieved by 155 generating the interface identifiers of the addresses of a host as 156 hashes of the available prefixes and a random number. Then, the 157 multiple addresses are obtained by prepending the different prefixes 158 to the generated interface identifiers. The result is a set of 159 addresses that are inherently bound. A cost efficient mechanism is 160 available to determine if two addresses belong to the same set, since 161 given the prefix set and the additional parameters used to generate 162 the HBA, a single hash operation is enough to verify if an HBA 163 belongs to a given HBA set. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119." 171 3. Overview 173 3.1. Threat Model 175 The threat analysis for the multihoming problem is described in [11]. 176 This analysis basically identifies attacks based on redirection of 177 packets by a malicious attacker towards addresses that do not belong 178 to the multihomed node. There are essentially two type of 179 redirection attacks: communication hijacking and flooding attacks. 180 communication hijacking attacks are about an attacker stealing on- 181 going and/or future communications from a victim. Flooding attacks 182 are about redirecting the traffic generated by a legitimate source 183 towards a third party, flooding it. The HBA solution provides full 184 protection against the communication hijacking attacks. The Shim6 185 protocol [9] protects against flooding attacks. Residual threats are 186 described in the security considerations section. 188 3.2. Overview 190 The basic goal of the HBA mechanism is to securely bind together 191 multiple IPv6 addresses that belong to the same multihomed host. 192 This allows rerouting of traffic without worrying that the 193 communication is being redirected to an attacker. The technique that 194 is used is to include a hash of the permitted prefixes in the low 195 order bits of the IPv6 address. 197 So, eliding some details, say the available prefixes are A, B, C, and 198 D, the host would generate a prefix list P consisting of (A,B,C,D) 199 and a random number called Modifier M. Then it would generate the new 200 addresses: 202 A || H(M || A || P) 204 B || H(M || B || P) 206 C || H(M || C || P) 208 D || H(M || D || P) 210 Thus, given one valid address out of the group and the prefix list P 211 and the random Modifier M it is possible to determine whether another 212 address is part of the group by computing the hash and checking 213 against the low order bits. 215 3.3. Motivations for the HBA design 217 The design of the HBA technique was driven by the following 218 considerations: 220 First of all, the goal of HBA is to provide a secure binding between 221 the IPv6 address used as identifier by the upper layer protocols and 222 the alternative locators available in the multihomed node, so that 223 redirection attacks are prevented. 225 Second, in order to achieve such protection, the selected approach 226 was to include security information in the identifier itself, instead 227 of relying in third trusted parties to secure the binding, such as 228 the ones based on repositories or Public Key Infrastructure. This 229 decision was driven by deployment considerations i.e. the cost of 230 deploying the trusted third party infrastructure. 232 Third, application support considerations described in [16] resulted 233 in selecting routable IPv6 addresses to be used as identifiers. 234 Hence, security information is stuffed within the interface 235 identifier part of the IPv6 address. 237 Fourth, performance considerations as described in [17] motivated the 238 usage of a hash based approach as opposed to a public key based 239 approach based on pure Cryptographic Generated Addresses (CGA), in 240 order to avoid imposing the performance of public key operations for 241 every communication in multihomed environments. The HBA approach 242 presented in this document presents a cheaper alternative that is 243 attractive to many common usage cases. Note that the HBA approach 244 and the CGA approaches are not mutually exclusive and that it is 245 possible to generate addresses that are both valid CGA and HBA 246 addresses providing the benefits of both approaches if needed. 248 4. Cryptographic Generated Addresses (CGA) compatibility considerations 250 As described in previous section, the HBA technique uses the 251 interface identifier part of the IPv6 address to encode information 252 about the multiple prefixes available to a multihomed host. However, 253 the interface identifier is also used to carry cryptographic 254 information when Cryptographic Generated Addresses (CGA) [2] are 255 used. Therefore, conflicting usages of the interface identifier bits 256 may result if this is not taken into account during the HBA design. 257 There are at least two valid reasons to provide CGA-HBA 258 compatibility: 260 First, the current Secure Neighbor Discovery (SeND) specification [3] 261 uses the CGAs defined in [2] to prove address ownership. If HBAs are 262 not compatible with CGAs, then nodes using HBAs for multihoming 263 wouldn't be able to do Secure Neighbor Discovery using the same 264 addresses (at least the parts of SeND that require CGAs). This would 265 imply that nodes would have to choose between security (from SeND) 266 and fault tolerance (from IPv6 multihoming support provided by the 267 Shim6 protocol [9]). In addition to SeND, there are other protocols 268 that are considering to benefit from the advantages offered by the 269 CGA scheme, such as mobility support protocols [13]. Those protocols 270 could not be used with HBAs if HBAs are not compatible with CGAs. 272 Second, CGAs provide additional features that cannot be achieved 273 using only HBAs. In particular, because of its own nature, the HBA 274 technique only supports a predetermined prefix set that is known at 275 the time of the generation of the HBA set. No additions of new 276 prefixes to this original set are supported after the HBA set 277 generation. In most of the cases relevant for site multihoming, this 278 is not a problem because the prefix set available to a multihomed set 279 is not very dynamic. New prefixes may be added in a multihomed site 280 when a new ISP is available, but the timing of those events are 281 rarely in the same time scale than the lifetime of established 282 communications. It is then enough for many situations that the new 283 prefix is not available for established communications and that only 284 new communications benefit from it. However, in the case that such 285 functionality is required, it is possible to use CGAs to provide it. 286 This approach clearly requires that HBA and CGA approaches are 287 compatible. If this is the case, it then would be possible to create 288 HBA/CGA addresses that support CGA and HBA functionality 289 simultaneously. The inputs to the HBA/CGA generation process will be 290 both a prefix set and a public key. In this way, a node that has 291 established a communication using one address of the CGA/HBA set can 292 tell its peer to use the HBA verification when one of the addresses 293 of its HBA/CGA set is used as locator in the communication or to use 294 CGA (public/private key based) verification when a new address that 295 does not belong to the HBA/CGA set is used as locator in the 296 communication. 298 So, because of the aforementioned reasons, it is a goal of the HBA 299 design to define HBAs in a way that they are compatible with CGAs as 300 defined in [2] and their usages described in [3] (Consequently, to 301 understand the rest of this note, the reader should be familiar with 302 the CGA specification defined in [2]). This means that it must be 303 possible to generate addresses that are both an HBA and a CGA i.e. 304 that the interface identifier contains cryptographic information of 305 CGA and the prefix-set information of an HBA. The CGA specification 306 already considers the possibility of including additional information 307 into the CGA generation process through the usage of Extension Fields 308 in the CGA Parameter Data Structure. It is then possible to define a 309 Multi-Prefix Extension for CGA so that the prefix set information is 310 included in the interface identifier generation process. 312 Even though a CGA compatible approach is adopted, it should be noted 313 that HBAs and CGAs are different concepts. In particular, the CGA is 314 inherently bound to a public key, while a HBA is inherently bound to 315 a prefix set. This means that a public key is not required to 316 generate an HBA-only address. Because of that, we define three 317 different types of addresses: 319 - CGA-only addresses: These are addresses generated as specified in 320 [2] without including the Multi-Prefix Extension. They are bound 321 to a public key and to a single prefix (contained in the basic CGA 322 Parameter Data Structure). These addresses can be used for SeND 323 [3] and if used for multihoming, their application will have to be 324 based on the public key usage. 326 - CGA/HBA addresses: These addresses are CGAs that include the 327 Multi-Prefix Extension in the CGA Parameters Data Structure used 328 for their generation. These addresses are bound to a public key 329 and a prefix set and they provide both CGA and HBA 330 functionalities. They can be used for SeND as defined in [3] and 331 for any usage defined for HBA (such as a Shim6 protocol) 333 - HBA-only addresses: These addresses are bound to a prefix set but 334 they are not bound to a public key. Because HBAs are compatible 335 with CGA, the CGA Parameter Data Structure will be used for their 336 generation, but a random nonce will be included in the Public Key 337 field instead of a public key. These addresses can be used for 338 HBA based multihoming protocols, but they cannot be used for SeND. 340 5. Multi-Prefix Extension for CGA 342 The Multi-Prefix Extension has the following TLV format as defined in 344 [8] : 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Extension Type | Extension Data Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |P| Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 + Prefix[1] + 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 + Prefix[2] + 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 . . . 362 . . . 363 . . . 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 + Prefix[n] + 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Ext Type: 16-bit type identifier of the Multi-Prefix Extension (See 371 IANA Considerations section) 373 Ext Len: 16-bit unsigned integer. Length of the Extension in 374 octets, not including the first 4 octets. 376 P flag: P flag: Set if a public key is included in the Public Key 377 field of the CGA Parameter Data Structure, reset otherwise. 379 Reserved: 31-bit reserved field. MUST be initialized to zero, and 380 ignored upon receipt. 382 Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n. 384 6. HBA-Set Generation 386 The HBA generation process is based on the CGA generation process 387 defined in section 4 of [2]. The goal is to require the minimum 388 amount of changes to the CGA generation process. It should be noted 389 that the following procedure is only valid for Sec values of 0, 1 and 390 2. For other Sec values, RFC4982 [10] has defined a CGA SEC registry 391 which will contain the specifications used to generate CGAs. The 392 generation procedures defined in such specifications must be used for 393 Sec values other than 0,1 or 2. 395 The CGA generation process has three inputs: a 64-bit subnet prefix, 396 a public key (encoded in DER as an ASN.1 structure of the type 397 SubjectPublicKeyInfo), and the security parameter Sec. 399 The main difference between the CGA generation and the HBA generation 400 is that while a CG A can be generated independently, all the HBAs of 401 a given HBA set have to be generated using the same parameters, which 402 implies that the generation of the addresses of an HBA set will occur 403 in a coordinated fashion. In this memo, we will describe a mechanism 404 to generate all the addresses of a given HBA set. The generation 405 process of each one of the HBA address of an HBA set will be heavily 406 based in the CGA generation process defined in [2]. More precisely, 407 the HBA set generation process will be defined as a sequence of 408 lightly modified CGA generations. 410 The changes required in the CGA generation process when generating a 411 single HBA are the following: First, the Multi-Prefix Extension has 412 to be included in the CGA Parameters Data Structure. Second, in the 413 case that the address being generated is an HBA-only address, a 414 random nonce will have to be used as input instead of a valid public 415 key. For backwards compatibility issues with pure CGAs, the random 416 nonce MUST be encoded as a public key as defined in [2]. In 417 particular, the random nonce MUST be formatted as a DER-encoded ASN.1 418 structure of the type SubjectPublicKeyInfo, defined in the Internet 419 X.509 certificate profile [5]. The algorithm identifier MUST be 420 rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce 421 MUST be formatted by using the RSAPublicKey type as specified in 422 Section 2.3.1 of RFC 3279 [4]. The random nonce length is 384 bits. 424 The resulting HBA-set generation process is the following: 426 The inputs to the HBA generation process are: 427 o A vector of n 64-bit prefixes 428 o A Sec parameter, and 429 o In the case of the generation of a set of HBA/CGA addresses a 430 public key is also provided as input (not required when generating 431 HBA-only addresses) 433 The output of the HBA generation process are: 434 o An HBA-set 435 o their respective CGA Parameters Data Structures 437 The steps of the HBA-set generation process are: 439 1. Multi-Prefix Extension generation. Generate the Multi-Prefix 440 Extension with the format defined in section 5. Include the 441 vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext 442 Len field value is (n*8 + 4). If a public key is provided, then 443 the P flag is set to one. Otherwise, the P flag is set to zero. 445 2. Modifier generation. Generate a Modifier as a random or 446 pseudorandom 128-bit value. If a public key has not been provided 447 as an input, generate the Extended Modifier as a 384-bit random or 448 pseudorandom value. Encode the Extended Modifier value as a RSA 449 key in a DER-encoded ASN.1 structure of the type 450 SubjectPublicKeyInfo defined in the Internet X.509 certificate 451 profile [5]. 453 3. Concatenate from left to right the Modifier, 9 zero octets, the 454 encoded public key or the encoded Extended Modifier (if no public 455 key was provided) and the Multi-Prefix Extension. Execute the 456 SHA-1 algorithm on the concatenation. Take the 112 leftmost bits 457 of the SHA-1 hash value. The result is Hash2. 459 4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 460 all zero (or if Sec=0), continue with step (5). Otherwise, 461 increment the modifier by one and go back to step (3). 463 5. Set the 8-bit collision count to zero. 465 6. For i=1 to n (number of prefixes) do 467 6.1. Concatenate from left to right the final Modifier value, 468 Prefix[i], the collision count, the encoded public key or the 469 encoded Extended Modifier (if no public key was provided) and 470 the Multi-Prefix Extension. Execute the SHA-1 algorithm on the 471 concatenation. Take the 64 leftmost bits of the SHA-1 hash 472 value. The result is Hash1[i]. 474 6.2. Form an interface identifier from Hash1[i] by writing the 475 value of Sec into the three leftmost bits and by setting bits 6 476 and 7 (i.e., the "u" and "g" bits) both to zero. 478 6.3. Generate address HBA[i] by concatenating Prefix[i] and the 479 64-bit interface identifier to form a 128-bit IPv6 address with 480 the subnet prefix to the left and interface identifier to the 481 right as in a standard IPv6 address [6]. 483 6.4. Perform duplicate address detection if required. If an 484 address collision is detected, increment the collision count by 485 one and go back to step (6). However, after three collisions, 486 stop and report the error. 488 6.5. Form the CGA Parameters Data Structure that corresponds to 489 HBA[i] by concatenating from left to right the final modifier 490 value, Prefix[i], the final collision count value, the encoded 491 public key or the encoded Extended Modifier and the Multi- 492 Prefix Extension. 494 [Note: most of the steps of the process are taken from [2]] 496 7. HBA verification 498 The following procedure is only valid for Sec values of 0, 1 and 2. 499 For other Sec values, RFC4982 [10] has defined a CGA SEC registry 500 which will contain the specifications used to verify CGAs. The 501 verification procedures defined in such specifications must be used 502 for Sec values other than 0,1 or 2. 504 7.1. Verification that a particular HBA address corresponds to a given 505 CGA Parameter Data Structure 507 HBAs are constructed as a CGA Extension, so a properly formatted HBA 508 and its correspondent CGA Parameter Data Structure will successfully 509 finish the verification process described in section 5 of [2]. Such 510 verification is useful when the goal is the verification of the 511 binding between the public key and the HBA. 513 7.2. Verification that a particular HBA address belongs to the HBA set 514 associated to a given CGA Parameter Data Structure 516 For multihoming applications, it is also relevant to verify if a 517 given HBA address belongs to a certain HBA set. An HBA set is 518 identified by a CGA Parameter Data structure that contains a Multi- 519 Prefix Extension. So, we need to verify if a given HBA belongs to 520 the HBA set defined by a CGA Parameter Data Structure. It should be 521 noted that we may need to verify if an HBA belongs to the HBA set 522 defined by the CGA Parameter Data Structure of another HBA of the 523 set. If this is the case, HBAs will fail to pass the CGA 524 verification process defined in [2], because the prefix included in 525 the Subnet Prefix field of the CGA Parameter Data Structure will not 526 match the prefix of the HBA that is being verified. To verify if an 527 HBA belongs to an HBA set associated with another HBA, verify that 528 the HBA prefix is included in the prefix set defined in the Multi- 529 Prefix Extension, and if this is the case, then substitute the prefix 530 included in the Subnet Prefix field by the prefix of the HBA, and 531 then perform the CGA verification process defined in [2]. 533 So, the process to verify that an HBA belongs to an HBA set 534 determined by a CGA Parameter Data Structure is called HBA 535 verification and it is the following: 537 The inputs to the HBA verification process are: 538 o An HBA 539 o A CGA Parameter Data Structure 541 The steps of the HBA verification process are the following: 543 1. Verify that the 64-bit HBA prefix is included in the prefix set of 544 the Multi-Prefix Extension. If it is not included, the 545 verification fails. If it is included, replace the prefix 546 contained in the Subnet Prefix field of the CGA Parameter Data 547 Structure by the 64-bit HBA prefix. 549 2. Run the verification process described in section 5 of [2] with 550 the HBA and the new CGA Parameters Data Structure (including the 551 Multi-Prefix Extension) as inputs. The steps of the process are 552 included below, extracted from [2] 554 2.1. Check that the collision count in the CGA Parameters Data 555 Structure is 0, 1 or 2. The CGA verification fails if the 556 collision count is out of the valid range. 558 2.2. Check that the subnet prefix in the CGA Parameters Data 559 Structure is equal to the subnet prefix (i.e., the leftmost 64 560 bits) of the address. The CGA verification fails if the prefix 561 values differ. [Note: This step always succeeds because of the 562 action taken in step 1] 564 2.3. Execute the SHA-1 algorithm on the CGA Parameters Data 565 Structure. Take the 64 leftmost bits of the SHA-1 hash value. 566 The result is Hash1. 568 2.4. Compare Hash1 with the interface identifier (i.e., the 569 rightmost 64 bits) of the address. Differences in the three 570 leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) 571 are ignored. If the 64-bit values differ (other than in the 572 five ignored bits), the CGA verification fails. 574 2.5. Read the security parameter Sec from the three leftmost bits 575 of the 64-bit interface identifier of the address. (Sec is an 576 unsigned 3-bit integer.) 578 2.6. Concatenate from left to right the modifier, 9 zero octets, 579 and the public key, and any extension fields [in this case, the 580 Multi-Prefix Extension will be included, at least] that follow 581 the public key in the CGA Parameters data structure. Execute 582 the SHA-1 algorithm on the concatenation. Take the 112 583 leftmost bits of the SHA-1 hash value. The result is Hash2. 585 2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any 586 one of them is non-zero, the CGA verification fails. 587 Otherwise, the verification succeeds. (If Sec=0, the CGA 588 verification never fails at this step.) 590 8. Example of HBA application to a multihoming scenario 592 In this section, we will describe a possible application of the HBA 593 technique to IPv6 multi-homing. 595 We will consider the following scenario: a multihomed site obtains 596 Internet connectivity through two providers ISPA and ISPB. Each 597 provider has delegated a prefix to the the multihomed site 598 (PrefA::/nA and PrefB::/nb respectively). In order to benefit from 599 multihoming, the hosts within the multihomed site will configure 600 multiple IP addresses, one per available prefix. The resulting 601 configuration is depicted in the next figure. 603 +-------+ 604 | Host2 | 605 |IPHost2| 606 +-------+ 607 | 608 | 609 (Internet) 610 / \ 611 / \ 612 +------+ +------+ 613 | ISPA | | ISPB | 614 | | | | 615 +------+ +------+ 616 | | 617 \ / 618 \ / 619 +---------------------+ 620 | multihomed site | 621 | PA::/nA | 622 | PB::/nB +------+ | 623 | |Host1 | | 624 | +------+ | 625 +---------------------+ 627 We assume that both Host1 and Host2 support the Shim6 protocol. 629 Host2 is not located in a multihomed site, so there is no need for it 630 to create HBAs (it must be able to verify them though, in order to 631 support the Shim6 protocol, as we will describe next.) 633 Host1 is located in the multihomed site, so it will generate its 634 addresses as HBAs. In order to do that, it needs to execute the HBA- 635 set generation process as detailed in Section 6 of this memo. The 636 inputs of the HBA-set generation process will be: a prefix vector 637 containing the two prefixes available in its link i.e. PA:LA::/64 638 and PB:LB::/64, a Sec parameter value, and optionally a public key. 639 In this case we will assume that a public key is provided so that we 640 can also illustrate how a renumbering event can be supported when 641 HBA/CGA addresses are used (see the sub-section referring to dynamic 642 address set support). So, after executing the HBA-set generation 643 process, Host1 will have: an HBA-set consisting in two addresses i.e. 644 PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data 645 Structures i.e. CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are 646 different but both contain information about the prefix set available 647 in the multihomed site. 649 We will next consider a communication between Host1 and Host2. 650 Assume that both ISPs of the multihomed site are working properly, so 651 any of the available addresses in Host1 can be used for the 652 communication. Suppose then that the communication is established 653 using PA:LA:iidA and IPHost2 for Host1 and Host2 respectively. So 654 far, no special Shim6 support has been required, and PA:LA:iidA is 655 used as any other global IP address. 657 Suppose that at a certain moment one of the hosts involved in the 658 communication decides that multihoming support is required in this 659 communication (this basically means that one of the hosts involved in 660 the communication desires enhanced fault tolerance capabilities for 661 this communication, so that if an outage occurs, the communication 662 can be re-homed to an alternative provider). 664 At this moment, the Shim6 protocol Host-Pair Context establishment 665 exchange will be performed between the two hosts (see [9].). In this 666 exchange, Host1 will send CGA_PDS_A to Host2. 668 After the reception of CGA_PDS_A, Host2 will verify that the received 669 CGA Parameter Data Structure corresponds to the address being used in 670 the communication PA:LA:iidA. This means that Host2 will execute the 671 HBA verification process described in Section 7 of this memo with PA: 672 LA:iidA and CGA_PDS_A as inputs. In this case, the verification will 673 succeed since the CGA Parameter Data Structure and the addresses used 674 in the verification match. 676 As long as there are no outages affecting the communication path 677 through ISPA, packets will continue flowing. If a failure affects 678 the path through ISPA, Host1 will attempt to re-home the 679 communication to an alternative address i.e. PB:LB:iidB. For that, 680 after detecting the outage, Host1 will inform Host2 about the 681 alternative address. Host2 will verify that the new address belongs 682 to the HBA set of the initial address. For that, Host2 will execute 683 the HBA verification process with the CGA Parameter Data Structure of 684 the original address (i.e. CGA_PDS_A) and the new address (i.e. PB: 685 LB:iidB) as inputs. The verification process will succeed because 686 PB:LB::/64 has been included in the Multi-Prefix Extension during the 687 HBA-set generation process. Additional verifications may be required 688 to prevent flooding attacks (see the comments about flooding attacks 689 prevention in the Security Considerations section of this memo). 691 Once the new address is verified, it can be used as an alternative 692 locator to re-home the communication, while preserving the original 693 address (PA:LA:iidA) as an identifier for the upper layers. This 694 means that following packets will be addressed to/from this new 695 address. Note that no additional HBA verification is required for 696 the following packets, since the new valid address can be stored in 697 Host2. 699 In this example, only the HBA capabilities of the Host1 addresses 700 were used. In other words, neither the public key included in the 701 CGA Parameter Data Structure nor its correspondent private key was 702 used in the protocol. In the following section we will consider a 703 case where its usage is required. 705 8.1. Dynamic Address Set Support 707 In the previous section we have presented the mechanisms that allow a 708 host to use different addresses of a pre-determined set to exchange 709 packets of a communication. The set of addresses involved was pre- 710 determined and known when the communication was initiated. To 711 achieve such functionality, only HBA functionalities of the addresses 712 were needed. In this section we will explore the case where the goal 713 is to exchange packets using additional addresses that were not known 714 when the communication was established. An example of such situation 715 is for instance when a new prefix is available in a site after a 716 renumbering event. In this case, the hosts that have the new address 717 available may want to use it in communications that were established 718 before the renumbering event. In this case, HBA functionalities of 719 the addresses are not enough and CGA capabilities are to be used. 721 Consider then the previous case of the communication between Host1 722 and Host2. Suppose that the communication is up and running, as 723 described earlier. Host1 is using PA:LA:iidA and Host2 is using 724 IPHost2 to exchange packets. Now suppose that a new address, PC:LC: 725 addC is available in Host1. Note that this address is just a regular 726 IPv6 address, and it is neither an HBA nor a CGA. Host1 wants to use 727 this new address in the existent communication with Host2. It should 728 be noted that the HBA mechanism described in the previous section 729 cannot be used to verify this new address, since this address does 730 not belong to the HBA set (since the prefix was not available at the 731 moment of the generation of the HBA set). This means that 732 alternative verification mechanisms will be needed. 734 In order to verify this new address, CGA capabilities of PA:LA:iidA 735 are used. Note that the same address is used, only that the 736 verification mechanism is different. So, if Host1 wants to use PC: 737 LC:addC to exchange packets in the established communication, it will 738 use the UPDATE message defined in the Shim6 protocol [9], conveying 739 the new address, PC:LC:addC, and this message will be signed using 740 the private key corresponding to the public key contained in 741 CGA_PDS_A. When Host2 receives the message, it will verify the 742 signature using the public key contained in the CGA Parameter Data 743 Structure associated with the address used for establishing the 744 communication i.e. CGA_PDS_A and PA:LA:iidA respectively. Once that 745 the signature is verified, the new address (PC:LC:addC) can be used 746 in the communication. 748 In any case, a renumbering event has an impact on a site that is 749 using the HBA technique. In particular, the new prefix added will 750 not be included in the existing HBA set, so it is only possible t use 751 the new prefix with the existing HBA set if CGA capabilities are 752 used. While this is acceptable for the short term, in the long run 753 the site will need to renumber its HBA addresses. In order to do 754 that, it will need to re-generate the HBA sets assigned to hosts 755 including the new prefix in the prefix set, which will result in 756 different addresses, not only because we need to add a new address 757 with the new prefix but also because the addresses with the existing 758 prefixes will also change because the inclusion of a new prefix in 759 the prefix set. Moreover, since HBA addresses need to be generated 760 locally, once that these are generated after the renumbering event, 761 the new address information needs to be conveyed to the DNS manager 762 in case that such address information is to be published in the DNS 763 (see DNS considerations section for more details). 765 9. DNS considerations 767 HBA sets can be generated using any prefix set. Actually, the only 768 particularity of the HBA is that they contain information about the 769 prefix set in the interface identifier part of the address in the 770 form of a hash, but no assumption about the properties of prefixes 771 used for the HBA generation is made. This basically means that 772 depending on the prefixes used for the HBA set generation, it may or 773 may not be recommended to publish the resulting (HBA) addresses in 774 the DNS. For instance, when ULA prefixes [18] are included in the 775 HBA generation process specific DNS considerations related to the 776 local nature of the ULA should be taken into account and proper 777 recommendations related to publishing such prefixes in the DNS should 778 followed. Moreover, a given host can have among its addresses some 779 HBAs and some other IPv6 addresses. The consequence from this is 780 that only HBA addresses will be bound together by the HBA technique, 781 while other addresses would not be bound to the HBA set. This would 782 basically mean that if one of the other addresses are used for 783 initiating a Shim6 communication, it won't be possible to use the HBA 784 technique to bind the address used with the HBA set. Furthermore, 785 since HBA are indistinguishable from other IPv6 addresses in their 786 format, an initiator will not be able to distinguish by merely 787 looking at the different addresses which ones belong to the HBA set 788 and which ones do not, so alternative means would be required the 789 initiator is supposed to use only HBA for establishing communications 790 in the presence of non-HBA addresses in the DNS. 792 In addition, it should be noted that the actual HBA values are a 793 result of the HBA generation procedure meaning that they cannot be 794 arbitrarily chosen. This has an implication with respect to DNS 795 management, because the party that generates the HBA address set 796 needs to convey the address information to the DNS manager, so that 797 the addresses are published and not the other way round. The 798 situation is similar to regular CGA addresses and even to the case 799 where stateless address autoconfiguration is used. In order to do 800 that, it is possible to use Dynamic DNS updates [19] or other 801 proprietary tools. A similar consideration applies when the host 802 wants to publish reverse DNS entries. Since the host needs to 803 generate its HBA addresses, it will need to convey the address 804 information to the DNS manager so the proper reverse DNS entry is 805 populated in case it is needed. It should be noted that neither the 806 Shim6 protocol nor the HBA technique rely on the reverse DNS for its 807 proper functioning and the general reasons for requiring reverse DNS 808 population apply as for any other regular IPv6 address. 810 10. IANA considerations 812 This document defines a new CGA Extension, the Multi-Prefix 813 Extension. This extension has been assigned the CGA Extension Type 814 value TBD (IANA). 816 To be removed prior publication: The 0x12 value is recommended for 817 trials while IANA does not assign the value. We request IANA to 818 assign the 0x12 value, in order not to impose changes on existent 819 implementations. 821 11. Security considerations 823 The goal of HBAs is to create a group of addresses that are securely 824 bound, so that they can be used interchangeably when communicating 825 with a node. If there is no secure binding between the different 826 addresses of a node, a number of attacks are enabled, as described in 827 [11]. In particular, it would possible for an attacker to redirect 828 the communications of a victim to an address selected by the 829 attacker, hijacking the communication. When using HBAs, only the 830 addresses belonging to an HBA set can be used interchangeably, 831 limiting the addresses that can be used to redirect the communication 832 to a well, pre-determined set, that belongs to the original node 833 involved in the communication. So, when using HBAs, a node that is 834 communicating using address A can redirect the communication to a new 835 address B if and only if B belongs to the same HBA set than A. 837 This means that if an attacker wants to redirect communications 838 addressed to address HBA1 to an alternative address IPX, the attacker 839 will need to create a CGA Parameters data structure that generates an 840 HBA set that contains both HBA1 and IPX. 842 In order to generate the required HBA set, the attacker needs to find 843 a CGA Parameter data structure that fulfills the following 844 conditions: 845 o the prefix of HBA1 and the prefix of IPX are included in the 846 Multi-Prefix Extension 847 o HBA1 is included in the HBA set generated. 849 (this assumes that it is acceptable for the attacker to redirect HBA1 850 to any address of the prefix of IPX). 852 The remaining fields that can be changed at will by the attacker in 853 order to meet the above conditions are: the Modifier, other prefixes 854 in the Multi-Prefix Extension and other extensions. In any case, in 855 order to obtain the desired HBA set, the attacker will have to use a 856 brute force attack, which implies the generation of multiple HBA sets 857 with different parameters (for instance with a different Modifier) 858 until the desired conditions are meet. The expected number of times 859 that the generation process will have to be repeated until the 860 desired HBA set is found is exponentially related with the number of 861 bits containing hash information included in the interface identifier 862 of the HBA. Since 59 of the 64 bits of the interface identifier 863 contain hash bits, then the expected number of generations that will 864 have to be performed by the attacker are O(2^59). Note: We assume 865 brute force is the best attack against HBA/CGAs. Also, note that the 866 assumption that the Sec tool defined in [2] multiplies the attack 867 factor holds for brute force attacks but may not hold for other 868 attack classes. 870 The protection against brute force attacks can be improved increasing 871 the Sec parameter. A non zero Sec parameter implies that steps 3-4 872 of the generation process will be repeated O(2^(16*Sec)) times 873 (expected number of times). If we assimilate the cost of repeating 874 the steps 3-4 to the cost of generating the HBA address, we can 875 estimate the number of times that the generation is to be repeated in 876 O(2^(59+16*Sec)) in the case of Sec values of 1 and 2. For other Sec 877 values, Sec protection mechanisms will be defined by the 878 specifications pointed by the CGA SEC registry defined in RFC 4982 879 [10]. 881 11.1. Security considerations when using HBAs in the Shim6 protocol 883 In this section we will analyze the security provided by HBAs in the 884 context of a Shim6 protocol as described in section 8 of this memo. 886 First of all, it must be noted that HBAs cannot prevent man-in-the- 887 middle (hereafter MITM) attacks. This means, that in the scenario 888 described in Section 8, if an attacker is located along the path 889 between Host1 and Host2 during the lifetime of the communication, the 890 attacker will be able to change the addresses used for the 891 communication. This means that he will be able to change the 892 addresses used in the communication, adding or removing prefixes at 893 his will. However, the attacker must make sure that the CGA 894 Parameter Data Structure and the HBA set is changed accordingly. 895 This essentially means that the attacker will have to change the 896 interface identifier part of the addresses involved, since a change 897 in the prefix set will result in different interface identifiers of 898 the addresses of the HBA set, unless the appropriate Modifier value 899 is used (which would require O(2(59+16*Sec)) attempts). So, HBA 900 don't provide MITM attacks protection, but a MITM attacker will have 901 to change the address used in the communication in order to change 902 the prefix set valid for the communication. 904 HBAs provide protection against time shifting attacks [11], [12]. In 905 the multihoming context, an attacker would perform a time-shifted 906 attack in the following way: an attacker placed along the path of the 907 communication will modify the packets to include an additional 908 address as a valid address for the communication. Then the attacker 909 would leave the on-path location, but the effects of the attack would 910 remain (i.e. the address would still be considered as a valid address 911 for that communication). Next we will present how HBAs can be used 912 to prevent such attacks. 914 If the attacker is not on-path when the initial CGA Parameter Data 915 Structure is exchanged, his only possibility to launch a redirection 916 attack is to fake the signature of the message for adding new 917 addresses using CGA capabilities of the addresses. This implies 918 discovering the public key used in the CGA Parameter Data Structure 919 and then cracking the key pair, which doesn't seem feasible. So in 920 order to launch a redirection attack, the attacker needs to be on- 921 path when the CGA Parameter Data Structure is exchanged, so he can 922 modify it. Now, in order to launch the redirection attack, the 923 attacker needs to add his own prefix in the prefix set of the CGA 924 Parameter Data Structure. We have seen in the previous section that 925 there are two possible approaches for this: 926 1. Find the right Modifier value, so that the address initially used 927 in the communication is contained in the new HBA set. The cost of 928 this attack is O(2(59+16*Sec)) iterations of the generation 929 process, so it is deemed unfeasible 931 2. Use any Modifier value, so that the address initially used in the 932 communication is probably not included in the HBA set. In this 933 case, the attacker must remain on-path, since he needs to rewrite 934 the address carried in the packets (if not the endpoints will 935 notice a change in the address used in the communication). This 936 essentially means that the attacker cannot launch a time-shifted 937 attack, but he must be a full time man-in-the-middle. 939 So, the conclusion is that HBAs provide protection against time- 940 shifted attacks 942 HBAs do not provide complete protection against flooding attacks, and 943 as a result the SHIM6 protocol has other means to deal with them. 944 However, HBAs make very difficult to launch a flooding attack towards 945 a specific address. It is possible though, to launch a flooding 946 attack against a prefix. And of course, the protection that HBA 947 offers applies only to nodes that employ it; HBA provides no solution 948 for general purpose flooding attack protection for other nodes. 950 Suppose that an attacker has easy access to a prefix PX::/nX and that 951 he wants to launch a flooding attack to a host located in the address 952 P:iid. The attack would consist in establishing a communication with 953 a server S and requesting a heavy flow from it. Then simply redirect 954 the flow to P:iid, flooding the target. In order to perform this 955 attack the attacker needs to generate an HBA set including P and PX 956 in the prefix set and that the resulting HBA set contains P:iid. In 957 order to do this, the attacker needs to find the appropriate Modifier 958 value. The expected number of attempts required to find such 959 Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can 960 conclude that such attack is not feasible. 962 However, the target of a flooding attack is not limited to specific 963 hosts, but it can also be launched against other element of the 964 infrastructure, such as router or access links. In order to do that, 965 the attacker can establish a communication with a server S and 966 request a download of a heavy flow. Then, the attacker redirects the 967 communication to any address of the target network. Even if the 968 target address is not assigned to any host, the flow will flood the 969 access link of the target site, and the site access router will also 970 suffer the overload. Such attack cannot be prevented using HBAs, 971 since the attacker can easily generate an HBA set using his own 972 prefix and the target network prefix. In order to prevent such 973 attacks, additional mechanisms are required, such as reachability 974 tests. 976 11.2. Privacy Considerations 978 HBAs can be used as RFC 4941 [7] addresses. If a node wants to use 979 temporary addresses, it will need to periodically generate new HBA 980 sets. The effort required for this operation depends on the Sec 981 parameter value. If Sec=0, then the cost of generating a new HBA set 982 is similar to the cost of generating a random number i.e. one 983 iteration of the HBA set generation procedure. However, if Sec>0, 984 then the cost of generating an HBA set is significantly increased, 985 since it required O(2(16*Sec)) iterations of the generation process. 986 In this case, depending on the frequency of address change required, 987 the support for RFC 4941 address may be more expensive. 989 11.3. SHA-1 Dependency Considerations. 991 Recent attacks on currently used hash functions have motivated a 992 considerable amount of concern in the Internet community. The 993 recommended approach [14] [15] to deal with this issue is first to 994 analyze the impact of these attacks on the different Internet 995 protocols that use hash functions and second to make sure that the 996 different Internet protocols that use hash functions are capable of 997 migrating to an alternative (more secure) hash function without a 998 major disruption in the Internet operation. 1000 The aforementioned analysis for CGAs and its extensions (including 1001 HBAs) is performed in RFC4982 [10]. The conclusion of the analysis 1002 is that the security of the protocols using CGAs and its extensions 1003 is not affected by the recently available attacks against hash 1004 functions. In spite of that, the CGA specification [2] was updated 1005 by RFC4982 [10] to enable the support of alternative hash functions. 1007 12. Contributors 1009 This document was originally produced of a MULTI6 design team 1010 consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo, 1011 Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret 1012 Wasserman, and Jukka Ylitalo. 1014 13. Acknowledgments 1016 The initial discussion about HBA benefited from contributions from 1017 Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra. 1019 The HBA-set generation and HBA verification processes described in 1020 this document contain several steps extracted from [2]. 1022 Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka 1023 Savola, Brian Carpenter, Eric Rescorla, Robin Whittle, Matthijs 1024 Mekking, Hannes Tschofenig, Spencer Dawkins, Lars Eggert, Tim Polk, 1025 Peter Koch, Niclas Comstedt and Sam Hartman have reviewed this 1026 document and provided valuable comments. 1028 The text included in section 3.2 Overview was provided by Eric 1029 Rescorla. 1031 We would also like to thanks Francis Dupont for providing the first 1032 implementation of HBA 1034 14. Change Log 1036 To be removed prior publication 1038 14.1. Changes from draft-ietf-shim6-hba-04 to draft-ietf-multi6-hba-05 1040 addressed comments from reviews from Matthijs Mekking, Hannes 1041 Tschofenig, Spencer Dawkins, Sam Hartman, Lars Eggert, Tim Polk, Jari 1042 Arkko 1044 14.2. Changes from draft-ietf-shim6-hba-03 to draft-ietf-multi6-hba-04 1046 Reworded the definition of the P flag 1048 Changed IANA considerations to include a request to IANA to assign 1049 the trial value. 1051 Updated HBA generation and verification process to make coherent with 1052 rfc4982 1054 Updated the sha1 consideration section to make it coherent with 1055 rfc4982 1057 Updated the DNS consideration section to include an explicit 1058 references to ULAs and added a section about DNS management of HBAs 1060 Editorial changes 1062 Updatred references 1064 14.3. Changes from draft-ietf-shim6-hba-02 to draft-ietf-multi6-hba-03 1066 added terminology section 1068 updated references 1070 14.4. Changes from draft-ietf-shim6-hba-01 to draft-ietf-multi6-hba-02 1072 A new section SHA-1 Dependency Considerations has been added in the 1073 Security Considerations Section (addressing Eric Rescorla (SecDir) 1074 comment) 1076 A new Overview section containing a Threat model subsection, a 1077 general description subsection and a motivations subsection has been 1078 added (addressing Eric Rescorla (SecDir) comment) 1080 Modified section of HBA verification in order to improve readability 1082 14.5. Changes from draft-ietf-shim6-hba-00 to draft-ietf-multi6-hba-01 1084 Changed the format of the Multi-Prefix extension to make it compliant 1085 with the generic TLV format proposed for CGA extensions 1087 Added IANA considerations section 1089 Added DNS considerations section 1091 14.6. Changes from draft-ietf-multi6-hba-00 to draft-ietf-shim6-hba-00 1093 Editorial changes 1095 14.7. Changes from draft-bagnulo-multi6dt-hba-00 to 1096 draft-ietf-multi6-hba-00 1098 Added "Example of HBA application to a multihoming scenario" section 1100 Added Privacy Considerations section 1102 Added flooding attacks comments in the Security Considerations 1103 section 1105 Added the Multi-Prefix extension in step 6.1 of the HBA-set 1106 generation process 1108 Added the Security considerations when using HBAs in a multi6 1109 protocol sub-section in the Security Considerations section 1111 Added Ext type value recommended for trials 1113 Changed the name of the draft 1115 Some rewording 1117 15. References 1119 15.1. Normative References 1121 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1122 Levels", BCP 14, RFC 2119, March 1997. 1124 [2] Aura, T., "Cryptographically Generated Addresses (CGA)", 1125 RFC 3972, April 2004. 1127 [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 1128 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, 1129 July 2004. 1131 [4] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1132 Identifiers for the Internet X.509 Public Key Infrastructure 1133 Certificate and Certificate Revocation List (CRL) Profile", 1134 RFC 3279, April 2002. 1136 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1137 Public Key Infrastructure Certificate and Certificate 1138 Revocation List (CRL) Profile", RFC 3280, April 2002. 1140 [6] Hinden, R. and S. Deering, "IP Version 6 Addressing 1141 Architecture", RFC 4291, February 2006. 1143 [7] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions 1144 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 1145 September 2007. 1147 [8] Bagnulo, M. and J. Arkko, "Cryptographically Generated 1148 Addresses (CGA) Extension Field Format", RFC 4581, 1149 October 2006. 1151 [9] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim 1152 Protocol for IPv6", draft-ietf-shim6-proto-08 (work in 1153 progress), April 2007. 1155 [10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms 1156 in Cryptographically Generated Addresses (CGAs)", RFC 4982, 1157 July 2007. 1159 15.2. Informative References 1161 [11] Nordmark, E., "Threats relating to IPv6 multihoming solutions", 1162 RFC 4218, October 2005. 1164 [12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1166 Nordmark, "Mobile IP version 6 Route Optimization Security 1167 Design Background", RFC 4225, December 2005. 1169 [13] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1170 Optimization for Mobile IPv6", RFC 4866, May 2007. 1172 [14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes 1173 in Internet Protocols", RFC 4270, November 2005. 1175 [15] Bellovin, S. and E. Rescorla, "Deploying a new hash algorithm", 1176 2005 September. 1178 [16] Nordmark, E., "Multi6 Application Referral Issues", 1179 draft-nordmark-multi6dt-refer-00 (work in progress), 1180 October 2004. 1182 [17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient 1183 Security for IPv6 Multihoming.", ACM Computer Communications 1184 Review Vol 35 n 2, April 2005. 1186 [18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1187 Addresses", RFC 4193, October 2005. 1189 [19] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1190 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1191 April 1997. 1193 Author's Address 1195 Marcelo Bagnulo 1196 Universidad Carlos III de Madrid 1197 Av. Universidad 30 1198 Leganes, Madrid 28911 1199 SPAIN 1201 Phone: 34 91 6249500 1202 Email: marcelo@it.uc3m.es 1203 URI: http://www.it.uc3m.es 1205 Full Copyright Statement 1207 Copyright (C) The IETF Trust (2007). 1209 This document is subject to the rights, licenses and restrictions 1210 contained in BCP 78, and except as set forth therein, the authors 1211 retain all their rights. 1213 This document and the information contained herein are provided on an 1214 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1215 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1216 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1217 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1218 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1219 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1221 Intellectual Property 1223 The IETF takes no position regarding the validity or scope of any 1224 Intellectual Property Rights or other rights that might be claimed to 1225 pertain to the implementation or use of the technology described in 1226 this document or the extent to which any license under such rights 1227 might or might not be available; nor does it represent that it has 1228 made any independent effort to identify any such rights. Information 1229 on the procedures with respect to rights in RFC documents can be 1230 found in BCP 78 and BCP 79. 1232 Copies of IPR disclosures made to the IETF Secretariat and any 1233 assurances of licenses to be made available, or the result of an 1234 attempt made to obtain a general license or permission for the use of 1235 such proprietary rights by implementers or users of this 1236 specification can be obtained from the IETF on-line IPR repository at 1237 http://www.ietf.org/ipr. 1239 The IETF invites any interested party to bring to its attention any 1240 copyrights, patents or patent applications, or other proprietary 1241 rights that may cover technology that may be required to implement 1242 this standard. Please address the information to the IETF at 1243 ietf-ipr@ietf.org. 1245 Acknowledgment 1247 Funding for the RFC Editor function is provided by the IETF 1248 Administrative Support Activity (IASA).