idnits 2.17.1 draft-ietf-shim6-hba-04.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 1160. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1184. 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 (October 2007) is 6039 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 3041 (ref. '7') (Obsoleted by RFC 4941) == 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 October 2007 5 Expires: April 3, 2008 7 Hash Based Addresses (HBA) 8 draft-ietf-shim6-hba-04 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 April 3, 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. The main idea is that information about 44 the multiple prefixes is included within the addresses themselves. 45 This is achieved by generating the interface identifiers of the 46 addresses of a host as hashes of the available prefixes and a random 47 number. Then, the multiple addresses are generated by prepending the 48 different prefixes to the generated interface identifiers. The 49 result is a set of addresses, called Hash Based Addresses (HBAs), 50 that are inherently bound. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3. Motivations for the HBA design . . . . . . . . . . . . . . 6 60 4. Cryptographic Generated Addresses (CGA) compatibility 61 considerations . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . . 8 63 6. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . . 9 64 7. HBA verification . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1. Verification that a particular HBA address corresponds 66 to a given CGA Parameter Data Structure . . . . . . . . . 12 67 7.2. Verification that a particular HBA address belongs tto 68 the HBA set associated to a given CGA Parameter Data 69 Structure . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. Example of HBA application to a multihoming scenario . . . . . 14 71 8.1. Dynamic Address Set Support . . . . . . . . . . . . . . . 17 72 9. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 18 73 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 74 11. Security considerations . . . . . . . . . . . . . . . . . . . 18 75 11.1. Security considerations when using HBAs in the shim6 76 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 11.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 22 78 11.3. Interaction with IPSec. . . . . . . . . . . . . . . . . . 22 79 11.4. SHA-1 Dependency Considerations. . . . . . . . . . . . . . 22 80 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 82 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 14.1. Changes from draft-ietf-shim6-hba-03 to 84 draft-ietf-multi6-hba-04 . . . . . . . . . . . . . . . . . 23 85 14.2. Changes from draft-ietf-shim6-hba-02 to 86 draft-ietf-multi6-hba-03 . . . . . . . . . . . . . . . . . 23 87 14.3. Changes from draft-ietf-shim6-hba-01 to 88 draft-ietf-multi6-hba-02 . . . . . . . . . . . . . . . . . 24 89 14.4. Changes from draft-ietf-shim6-hba-00 to 90 draft-ietf-multi6-hba-01 . . . . . . . . . . . . . . . . . 24 91 14.5. Changes from draft-ietf-multi6-hba-00 to 92 draft-ietf-shim6-hba-00 . . . . . . . . . . . . . . . . . 24 93 14.6. Changes from draft-bagnulo-multi6dt-hba-00 to 94 draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . . 24 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 97 15.2. Informative References . . . . . . . . . . . . . . . . . . 25 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 Intellectual Property and Copyright Statements . . . . . . . . . . 27 101 1. Introduction 103 In order to preserve inter-domain routing system scalability, IPv6 104 sites obtain addresses from their Internet Service Providers. Such 105 addressing strategy significantly reduces the amount of routes in the 106 global routing tables, since each ISP only announces routes to its 107 own address blocks, rather than announcing one route per customer 108 site. However, this addressing scheme implies that multihomed sites 109 will obtain multiple prefixes, one per ISP. Moreover, since each ISP 110 only announces its own address block, a multihomed site will be 111 reachable through a given ISP if the ISP prefix is contained in the 112 destination address of the packets. This means that, if an 113 established communication needs to be routed through different ISPs 114 during its lifetime, addresses with different prefixes will have to 115 be used. Changing the address used to carry packets of an 116 established communication exposes the communication to numerous 117 attacks, as described in [11], so security mechanisms are required to 118 provide the required protection to the involved parties. This memo 119 describes a tool that can be used to provide protection against some 120 of the potential attacks, in particular against future / premeditated 121 attacks (a.k.a. time shifting attacks in [12]). 123 It should be noted that, as opposed to the mobility case where the 124 addresses that will be used by the mobile node are not known a 125 priori, the multiple addresses available to a host within the 126 multihomed site are pre-defined and known in advance in most of the 127 cases. The mechanism proposed in this memo takes advantage of this 128 address set stability, and provides a secure binding between all the 129 addresses of a node in a multihomed site. The mechanism does so 130 without requiring the usage of public key cryptography, providing a 131 cost efficient alternative to public key cryptography based schemes. 133 This memo describes a mechanism to provide a secure binding between 134 the multiple addresses with different prefixes available to a host 135 within a multihomed site. The main idea is that information about 136 the multiple prefixes is included within the addresses themselves. 137 This is achieved by generating the interface identifiers of the 138 addresses of a host as hashes of the available prefixes and a random 139 number. Then, the multiple addresses are obtained by prepending the 140 different prefixes to the generated interface identifiers. The 141 result is a set of addresses, called Hash Based Addresses (HBAs), 142 that are inherently bound. A cost efficient mechanism is available 143 to determine if two addresses belong to the same set, since given the 144 prefix set and the additional parameters used to generate the HBA, a 145 single hash operation is enough to verify if an HBA belongs to a 146 given HBA set. No public key operations are involved in the 147 verification process. In addition, it should also be noted that it 148 is not required that all interface identifiers of the addresses of an 149 HBA set are equal, preserving some degree of privacy through changes 150 in the addresses used during the communications. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119[1]." 158 3. Overview 160 3.1. Threat Model 162 The threat analysis for the multihoming problem is described in 163 [11].This analysis basically identifies attacks based on redirection 164 of packets by a malicious attacker towards addresses that do not 165 belong to the multihomed node. There are essentially two type of 166 redirection attacks: communication hijacking and flooding attacks. 167 communication hijacking attacks are about an attacker stealing on- 168 going and/or future communications from a victim. Flooding attacks 169 are about redirecting the traffic generated by a legitimate source 170 towards a third party, flooding it. The HBA solution provides full 171 protection against the communication hijacking attacks and limited 172 protection against flooding attacks. Residual threats are described 173 in the security considerations section. 175 3.2. Overview 177 The basic goal of the HBA mechanism is to securely bind together 178 multiple IPv6 addresses that belong to the same multihomed host. 179 This allows rerouting of traffic without worrying that the 180 communication is being redirected to an attacker. The technique that 181 is used is to include a hash of the permitted prefixes in the low 182 order bits of the IPv6 address. 184 So, eliding some details, say the available prefixes are A, B, C, and 185 D, the host would generate a prefix list P consisting of (A,B,C,D) 186 and a random number M. Then it would generate the new addresses: 188 A || H(M || A || P) 190 B || H(M || B || P) 192 C || H(M || C || P) 194 D || H(M || D || P) 195 Thus, given one valid address out of the group and the prefix list P 196 and the random number M it is possible to determine whether another 197 address is part of the group by computing the hash and checking 198 against the low order bits. 200 3.3. Motivations for the HBA design 202 The design of the HBA technique was driven by the following 203 considerations: 205 First of all, the goal of HBA is to provide a secure binding between 206 the IPv6 address used as identifier by the upper layer protocols and 207 the alternative locators available in the multihomed node, so that 208 redirection attacks are prevented. 210 Second, in order to achieve such protection, the selected approach 211 was to include security information in the identifer itself, instead 212 of relying in third trusted parties to secure the binding, such as 213 the ones based on repositories or Public Key Infrastructure. This 214 decision was driven by deployment considerations i.e. the cost of 215 deploying the third trusted party infrastucture. 217 Third, application support considerations described in [16] resulted 218 in selecting routable IPv6 addresses to be used as identifiers. 219 Hence, security information is stuffed within the interface 220 identifier part of the IPv6 address. 222 Fourth, performance considerations as described in [17] motivated the 223 usage of a hash based approach as oposed to a public key based 224 approach based on pure Cryptographic Generated Addresses (CGA), in 225 order to avoid imposing the performance of public key operations for 226 every communication in multihomed environments. The HBA appraoch 227 presented in this document presents a cheaper alternative that is 228 attractive to many common usage cases. Note that the HBA approach 229 and the CGA approaches are not mutually exclusive and that it is 230 possible to generate addresses that are both CGA and HBA providing 231 the benefits of both approaches if needed. 233 4. Cryptographic Generated Addresses (CGA) compatibility considerations 235 As described in previous section, the HBA technique uses the 236 interface identifier part of the IPv6 address to encode information 237 about the multiple prefixes available to a multihomed host. However, 238 the interface identifier is also used to carry cryptographic 239 information when Cryptographic Generated Addresses (CGA) [2] are 240 used. Therefore, conflicting usages of the interface identifier bits 241 may result if this is not taken into account during the HBA design. 243 There are at least two valid reasons to provide CGA-HBA 244 compatibility: 246 First, the current Secure Neighbor Discovery specification [3] uses 247 the CGAs defined in [2] to prove address ownership. If HBAs are not 248 compatible with CGAs, then nodes using HBAs for multihoming wouldn't 249 be able to do Secure Neighbor Discovery using the same addresses (at 250 least the parts of SeND that require CGAs). This would imply that 251 nodes would have to choose between security (from SeND) and fault 252 tolerance (from shim6). In addition to SeND, there are other 253 protocols that are considering to benefit from the advantages offered 254 by the CGA scheme, such as mobility support protocols [13]. Those 255 protocols would also become incompatible with HBAs if HBAs are not 256 compatible with CGAs. 258 Second, CGAs provide additional features that cannot be achieved 259 using only HBAs. In particular, because of its own nature, the HBA 260 technique only supports a predetermined prefix set that is known at 261 the time of the generation of the HBA set. No additions of new 262 prefixes to this original set are supported after the HBA set 263 generation. In most of the cases relevant for site multihoming, this 264 is not a problem because the prefix set available to a multihomed set 265 is not very dynamic. New prefixes may be added in a multihomed site 266 when a new ISP is available, but the timing of those events are 267 rarely in the same time scale than the lifetime of established 268 communications. It is then enough for many situations that the new 269 prefix is not available for established communications and that only 270 new communications benefit from it. However, in the case that such 271 functionality is required, it is possible to use CGAs to provide it. 272 This approach clearly requires that HBA and CGA approaches are 273 compatible. If this is the case, it then would be possible to create 274 HBA/CGA addresses that support CGA and HBA functionality 275 simultaneously. The inputs to the HBA/CGA generation process will be 276 both a prefix set and a public key. In this way, a node that has 277 established a communication using one address of the CGA/HBA set can 278 tell its peer to use the HBA verification when one of the addresses 279 of its HBA/CGA set is used as locator in the communication or to use 280 CGA (public/private key based) verification when a new address that 281 does not belong to the HBA/CGA set is used as locator in the 282 communication. 284 So, because of the aforementioned reasons, it is a goal of the HBA 285 design to define HBAs in a way that they are compatible with CGAs as 286 defined in [2] and their usages described in [3] (Consequently, to 287 understand the rest of this note, the reader should be familiar with 288 the CGA specification defined in [2]). This means that it must be 289 possible to generate addresses that are both an HBA and a CGA i.e. 290 that the interface identifier contains cryptographic information of 291 CGA and the prefix-set information of an HBA. The CGA specification 292 already considers the possibility of including additional information 293 into the CGA generation process through the usage of Extension Fields 294 in the CGA Parameter Data Structure. It is then possible to define a 295 Multi-Prefix Extension for CGA so that the prefix set information is 296 included in the interface identifier generation process. 298 Even though a CGA compatible approach is adopted, it should be noted 299 that HBAs and CGAs are different concepts. In particular, the CGA is 300 inherently bound to a public key, while a HBA is inherently bound to 301 a prefix set. This means that a public key is not strictly required 302 to generate an HBA. Because of that, we define three different types 303 of addresses: 305 - CGA-only addresses: These are addresses generated as specified in 306 [2] without including the Multi-Prefix Extension. They are bound 307 to a public key and to a single prefix (contained in the basic CGA 308 Parameter Data Structure). These addresses can be used for SeND 309 [3] and if used for multihoming, their application will have to be 310 based on the public key usage. 312 - CGA/HBA addresses: These addresses are CGAs that include the 313 Multi-Prefix Extension in the CGA Parameters Data Structure used 314 for their generation. These addresses are bound to a public key 315 and a prefix set and they provide both CGA and HBA 316 functionalities. They can be used for SeND as defined in [3] and 317 for any usage defined for HBA (such as a shim6 protocol) 319 - HBA-only addresses: These addresses are bound to a prefix set but 320 they are not bound to a public key. Because CGA compatibility, 321 the CGA Parameter Data Structure will be used for their 322 generation, but a random nonce will be included in the Public Key 323 field instead of a public key. These addresses can be used for 324 HBA based multihoming protocols, but they cannot be used for SeND. 326 5. Multi-Prefix Extension for CGA 328 The Multi-Prefix Extension has the following TLV format as defined in 329 [8] : 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Extension Type | Extension Data Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 |P| Reserved | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 + Prefix[1] + 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 + Prefix[2] + 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 . . . 347 . . . 348 . . . 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 + Prefix[n] + 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Ext Type: 16-bit type identifier of the Multi-Prefix Extension (See 356 IANA Considerations section) 358 Ext Len: 16-bit unsigned integer. Length of the Extension in 359 octets, not including the first 4 octets. 361 P flag: P flag: Set if a public key is included in the Public Key 362 field of the CGA Parameter Data Structure, reset otherwise. 364 Reserved: 31-bit reserved field. MUST be initialized to zero, and 365 ignored upon receipt. 367 Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n. 369 6. HBA-Set Generation 371 The HBA generation process is based on the CGA generation process 372 defined in section 4 of [2]. The goal is to require the minimum 373 amount of changes to the CGA generation process. It should be noted 374 that the following procedure is only valid for Sec values of 0, 1 and 375 2. For other Sec values, RFC4982 [10] has defined a CGA SEC registry 376 which will contain the specifications used to generate CGAs. The 377 generation procedures defined in such specifications must be used for 378 Sec values other than 0,1 or 2. 380 The CGA generation process has three inputs: a 64-bit subnet prefix, 381 a public key (encoded in DER as an ASN.1 structure of the type 382 SubjectPublicKeyInfo), and the security parameter Sec. 384 The main difference between the CGA generation and the HBA generation 385 is that while a CGA can be generated independently, all the HBAs of a 386 given HBA set have to be generated using the same parameters, which 387 implies that the generation of the addresses of an HBA set will occur 388 in a coordinated fashion. In this memo, we will describe a mechanism 389 to generate all the addresses of a given HBA set. The generation 390 process of each one of the HBA address of an HBA set will be heavily 391 based in the CGA generation process defined in [2]. More precisely, 392 the HBA set generation process will be defined as a sequence of 393 lightly modified CGA generations. 395 The changes required in the CGA generation process when generating a 396 single HBA are the following: First, the Multi-Prefix Extension has 397 to be included in the CGA Parameters Data Structure. Second, in the 398 case that the address being generated is an HBA-only address, a 399 random nonce will have to be used as input instead of a valid public 400 key. For backward compatibility issues with pure CGAs, the random 401 nonce must be encoded as a public key as defined in [2]. In 402 particular, the random nonce must be formatted as a DER-encoded ASN.1 403 structure of the type SubjectPublicKeyInfo, defined in the Internet 404 X.509 certificate profile [5]. The algorithm identifier must be 405 rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce 406 must be formatted by using the RSAPublicKey type as specified in 407 Section 2.3.1 of RFC 3279 [4]. The random nonce length is 384 bits. 409 The resulting HBA-set generation process is the following: 411 The inputs to the HBA generation process are: 412 o A vector of n 64-bit prefixes 413 o A Sec parameter, and 414 o In the case of the generation of a set of HBA/CGA addresses a 415 public key is also provided as input (not required when generating 416 HBA-only addresses) 418 The output of the HBA generation process are: 419 o An HBA-set 420 o their respective CGA Parameters Data Structures 422 The steps of the HBA-set generation process are: 424 1. Multi-Prefix Extension generation. Generate the Multi-Prefix 425 Extension with the format defined in section 3. Include the 426 vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext 427 Len field value is (n*8 + 4). If a public key is provided, then 428 the P flag is set. Otherwise, the P flag is reset. 430 2. Modifier generation. Generate a Modifier as a random or 431 pseudorandom 128-bit value. If a public key has not been provided 432 as an input, generate the Extended Modifier as a 384-bit random or 433 pseudorandom value. Encode the Extended Modifier value as a RSA 434 key in a DER-encoded ASN.1 structure of the type 435 SubjectPublicKeyInfo defined in the Internet X.509 certificate 436 profile [5]. 438 3. Concatenate from left to right the Modifier, 9 zero octets, the 439 encoded public key or the encoded Extended Modifier (if no public 440 key was provided) and the Multi-Prefix Extension. Execute the 441 SHA-1 algorithm on the concatenation. Take the 112 leftmost bits 442 of the SHA-1 hash value. The result is Hash2. 444 4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 445 all zero (or if Sec=0), continue with step (5). Otherwise, 446 increment the modifier by one and go back to step (3). 448 5. Set the 8-bit collision count to zero. 450 6. For i=1 to n do 452 6.1. Concatenate from left to right the final Modifier value, 453 Prefix[i], the collision count, the encoded public key or the 454 encoded Extended Modifier (if no public key was provided) and 455 the Multi-Prefix Extension. Execute the SHA-1 algorithm on the 456 concatenation. Take the 64 leftmost bits of the SHA-1 hash 457 value. The result is Hash1[i]. 459 6.2. Form an interface identifier from Hash1[i] by writing the 460 value of Sec into the three leftmost bits and by setting bits 6 461 and 7 (i.e., the "u" and "g" bits) both to zero. 463 6.3. Generate address HBA[i] by concatenating Prefix[i] and the 464 64-bit interface identifier to form a 128-bit IPv6 address with 465 the subnet prefix to the left and interface identifier to the 466 right as in a standard IPv6 address [6]. 468 6.4. Perform duplicate address detection if required. If an 469 address collision is detected, increment the collision count by 470 one and go back to step (6). However, after three collisions, 471 stop and report the error. 473 6.5. Form the CGA Parameters Data Structure that corresponds to 474 HBA[i] by concatenating from left to right the final modifier 475 value, Prefix[i], the final collision count value, the encoded 476 public key or the encoded Extended Modifier and the Multi- 477 Prefix Extension. 479 [Note: most of the steps of the process are taken from [2]] 481 7. HBA verification 483 The following procedure is only valid for Sec values of 0, 1 and 2. 484 For other Sec values, RFC4982 [10] has defined a CGA SEC registry 485 which will contain the specifications used to verify CGAs. The 486 verification procedures defined in such specifications must be used 487 for Sec values other than 0,1 or 2. 489 7.1. Verification that a particular HBA address corresponds to a given 490 CGA Parameter Data Structure 492 HBAs are constructed as a CGA Extension, so a properly formated HBA 493 and its correspondent CGA Parameter Data Structure will successfully 494 finish the verification process described in section 5 of [2]. Such 495 verification is useful when the goal is the verification of the 496 binding between the public key and the HBA. 498 7.2. Verification that a particular HBA address belongs tto the HBA set 499 associated to a given CGA Parameter Data Structure 501 For multihoming applications, it is also relevant to verify if a 502 given HBA address belongs to a certain HBA set. An HBA set is 503 identified by a CGA Parameter Data structure that contains a Multi- 504 Prefix Extension. So, it is then needed to verify if an HBA belongs 505 to the HBA set defined by a CGA Parameter Data Structure. It should 506 be noted that it may be needed to verify if an HBA belongs to the HBA 507 set defined by the CGA Parameter Data Structure of another HBA of the 508 set. If this is the case, the CGA verification process as defined in 509 [2] will fail, because the prefix included in the Subnet Prefix field 510 of the CGA Parameter Data Structure will not match with the one of 511 the HBA that is being verified. However, this doesn't mean that this 512 HBA does not belong to the HBA set. In order to address this issue, 513 it is only required to verify that the HBA prefix is included in 514 prefix set defined in the Multi-Prefix Extension, and if this is the 515 case, then substitute the prefix included in the Subnet Prefix field 516 by the prefix of the HBA, and then perform the CGA verification 517 process defined in [2]. 519 So, the process to verify that an HBA belongs to an HBA set 520 determined by a CGA Parameter Data Structure is called HBA 521 verification and it is the following: 523 The inputs to the HBA verification process are: 524 o An HBA 525 o A CGA Parameter Data Structure 527 The steps of the HBA verification process are the following: 529 1. Verify that the 64-bit HBA prefix is included in the prefix set of 530 the Multi-Prefix Extension. If it is not included, the 531 verification fails. If it is included, replace the prefix 532 contained in the Subnet Prefix field of the CGA Parameter Data 533 Structure by the 64-bit HBA prefix. 535 2. Run the verification process described in section 5 of [2] with 536 the HBA and the new CGA Parameters Data Structure (including the 537 Multi-Prefix Extension) as inputs. The steps of the process are 538 included below, extracted from [2] 540 2.1. Check that the collision count in the CGA Parameters Data 541 Structure is 0, 1 or 2. The CGA verification fails if the 542 collision count is out of the valid range. 544 2.2. Check that the subnet prefix in the CGA Parameters Data 545 Structure is equal to the subnet prefix (i.e., the leftmost 64 546 bits) of the address. The CGA verification fails if the prefix 547 values differ. [Note: This step is trivially successful 548 because step 1] 550 2.3. Execute the SHA-1 algorithm on the CGA Parameters Data 551 Structure. Take the 64 leftmost bits of the SHA-1 hash value. 552 The result is Hash1. 554 2.4. Compare Hash1 with the interface identifier (i.e., the 555 rightmost 64 bits) of the address. Differences in the three 556 leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) 557 are ignored. If the 64-bit values differ (other than in the 558 five ignored bits), the CGA verification fails. 560 2.5. Read the security parameter Sec from the three leftmost bits 561 of the 64-bit interface identifier of the address. (Sec is an 562 unsigned 3-bit integer.) 564 2.6. Concatenate from left to right the modifier, 9 zero octets, 565 and the public key, and any extension fields [in this case, the 566 Multi-Prefix Extension will be included, at least] that follow 567 the public key in the CGA Parameters data structure. Execute 568 the SHA-1 algorithm on the concatenation. Take the 112 569 leftmost bits of the SHA-1 hash value. The result is Hash2. 571 2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any 572 one of them is non-zero, the CGA verification fails. 573 Otherwise, the verification succeeds. (If Sec=0, the CGA 574 verification never fails at this step.) 576 8. Example of HBA application to a multihoming scenario 578 In this section, we will describe a possible application of the HBA 579 technique to IPv6 multi-homing. 581 We will consider the following scenario: a multihomed site obtains 582 Internet connectivity through two providers ISPA and ISPB. Each 583 provider has delegated a prefix to the the multihomed site 584 (PrefA::/nA and PrefB::/nb respectively). In order to benefit from 585 multihoming, the hosts within the multihomed site will configure 586 multiple IP addresses, one per available prefix. The resulting 587 configuration is depicted in the next figure. 589 +-------+ 590 | Host2 | 591 |IPHost2| 592 +-------+ 593 | 594 | 595 (Internet) 596 / \ 597 / \ 598 +------+ +------+ 599 | ISPA | | ISPB | 600 | | | | 601 +------+ +------+ 602 | | 603 \ / 604 \ / 605 +---------------------+ 606 | multihomed site | 607 | PA::/nA | 608 | PB::/nB +------+ | 609 | |Host1 | | 610 | +------+ | 611 +---------------------+ 613 We assume that both Host1 and Host2 support the shim6 protocol. 615 Host2 in not located in a multihomed site, so there is no need for it 616 to create HBAs (it must be able to verify them though, in order to 617 support the shim6 protocol, as we will describe next.) 619 Host1 is located in the multihomed site, so it will generate its 620 addresses as HBAs. In order to do that, it needs to execute the HBA- 621 set generation process as detailed in Section 4 of this memo. The 622 inputs of the HBA-set generation process will be: a prefix vector 623 containing the two prefixes available in its link i.e. PA:LA::/64 624 and PB:LB::/64, a Sec parameter value, and optionally a public key. 625 In this case we will assume that a public key is provided so that we 626 can also illustrate how a renumbering event can be supported when 627 HBA/CGA addresses are used (see the sub-section referring to dynamic 628 address set support). So, after executing the HBA-set generation 629 process, Host1 will have: an HBA-set consisting in two addresses i.e. 630 PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data 631 Structures i.e. CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are 632 different but both contain information about the prefix set available 633 in the multihomed site. 635 We will next consider a communication between Host1 and Host2. 636 Assume that both ISPs of the multihomed site are working properly, so 637 any of the available addresses in Host1 can be used for the 638 communication. Suppose then that the communication is established 639 using PA:LA:iidA and IPHost2 for Host1 and Host2 respectively. So 640 far, no special shim6 support has been required, and PA:LA:iidA is 641 used as any other global IP address. 643 Suppose that at a certain moment one of the hosts involved in the 644 communication decides that multihoming support is required in this 645 communication (this basically means that one of the hosts involved in 646 the communication desires enhanced fault tolerance capabilities for 647 this communication, so that if an outage occurs, the communication 648 can be rehomed to an alternative provider). 650 At this moment, the shim6 protocol Host-Pair Context establishment 651 exchange will be perfomed between the two hosts (see [9].). In this 652 exchange, Host1 will send CGA_PDS_A to Host2. 654 After the reception of CGA_PDS_A, Host2 will verify that the received 655 CGA Parameter Data Structure corresponds to the address being used in 656 the communication PA:LA:iidA. This means that Host2 will execute the 657 HBA verification process described in Section 5 of this memo with PA: 658 LA:iidA and CGA_PDS_A as inputs. In this case, the verification will 659 succeed since the CGA Parameter Data Structure and the addresses used 660 in the verification match. 662 As long as there are no outages affecting the communication path 663 through ISPA, packets will continue flowing. If a failure affects 664 the path through ISPA, Host1 will attempt to re-home the 665 communication to an alternative address i.e. PB:LB:iidB. For that, 666 after detecting the outage, Host1 will inform Host2 about the 667 alternative address. Host2 will verify that the new address belongs 668 to the HBA set of the initial address. For that, Host2 will execute 669 the HBA verification process with the CGA Parameter Data Structure of 670 the original address (i.e. CGA_PDS_A) and the new address (i.e. PB: 671 LB:iidB) as inputs. The verification process will succeed because 672 PB:LB::/64 has been included in the Multi-Prefix Extension during the 673 HBA-set generation process. Additional verifications may be required 674 to prevent flooding attacks (see the comments about flooding attacks 675 prevention in the Security Considerations section of this memo). 677 Once the new address is verified, it can be used as an alternative 678 locator to re-home the communication, while preserving the original 679 address (PA:LA:iidA) as an identifier for the upper layers. This 680 means that following packets will be addressed to/from this new 681 address. Note that no additional HBA verification is required for 682 the following packets, since the new valid address can be stored in 683 Host2. 685 Eventually, the communication will end and the associated shim6 686 context information will be discarded. 688 In this example, only the HBA capabilities of the Host1 addresses 689 were used. In other words, neither the public key included in the 690 CGA Parameter Data Structure nor its correspondent private key was 691 used in the protocol. In the following section we will consider a 692 case where its usage is required. 694 8.1. Dynamic Address Set Support 696 In the previous section we have presented the mechanisms that allow a 697 host to use different addresses of a pre-determined set to exchange 698 packets of a communication. The set of addresses involved was pre- 699 determined and known when the communication was initiated. To 700 achieve such functionality, only HBA functionalities of the addresses 701 were needed. In this section we will explore the case where the goal 702 is to exchange packets using additional addresses that were not known 703 when the communication was established. An example of such situation 704 is for instance when a new prefix is available in a site after a 705 renumbering event. In this case, the hosts that have the new address 706 available may want to use it in communications that were established 707 before the renumbering event. In this case, HBA functionalities of 708 the addresses are not enough and CGA capabilities are to be used. 710 Consider then the previous case of the communication between Host1 711 and Host2. Suppose that the communication is up and running, as 712 described earlier. Host1 is using PA:LA:iidA and Host2 is using 713 IPHost2 to exchange packets. Now suppose that a new address, PC:LC: 714 addC is available in Host1. Note that this address is just a regular 715 IPv6 address, and it is neither an HBA nor a CGA. Host1 wants to use 716 this new address in the existent communication with Host2. It should 717 be noted that the HBA mechanism described in the previous section 718 cannot be used to verify this new address, since this address does 719 not belong to the HBA set (since the prefix was not available at the 720 moment of the generation of the HBA set). This means that 721 alternative verification mechanisms will be needed. 723 In order to verify this new address, CGA capabilities of PA:LA:iidA 724 are used. Note that the same address is used, only that the 725 verification mechanism is different. So, if Host1 wants to use PC: 726 LC:addC to exchange packets in the established communication, it will 727 use message of the shim6 protocol, conveying the new address, PC:LC: 728 addC, and this message will be signed using the private key 729 corresponding to the public key contained in CGA_PDS_A. When Host2 730 receives the message, it will verify the signature using the public 731 key contained in the CGA Parameter Data Structure associated with the 732 address used for establishing the communication i.e. CGA_PDS_A and 733 PA:LA:iidA respectively. Once that the signature is verified, the 734 new address (PC:LC:addC) can be used in the communication. 736 9. DNS considerations 738 HBA sets can be generated using any prefix set. Actually, the only 739 particularity of the HBA is that they contain information about the 740 prefix set in the interface identifier part of the address in the 741 form of a hash, but no assumption about the properties of prefixes 742 used for the HBA generation is made. This basically means that 743 depending on the prefixes used for the HBA set generation, it may or 744 may not be recommended to publish the resulting (HBA) addresses in 745 the DNS. For instance, when ULA prefixes [18] are included in the 746 HBA generation process specific DNS considerations related to the 747 local nature of the ULA should be taken into account and proper 748 reccomendations related to publishing such prefixes in the DNS should 749 followed. 751 In addition, it should be noted that the actual HBA values are a 752 result of the HBA generation procedure meaning that they cannot be 753 arbitrarily chosen. This has an implication with respect to DNS 754 management, because the party that generates the HBA address set 755 needs to convey the address information to the DNS manager, so that 756 the addresses are published and not the other way round. The 757 situation is similar to regular CGA addresses and even to the case 758 where stateless address autoconfiguration is used. 760 10. IANA considerations 762 This document defines a new CGA Extension, the Multi-Prefix 763 Extension. This extension has been assigned the CGA Extension Type 764 value TBD (IANA). 766 To be removed prior publication: The 0x12 value is recommended for 767 trials whil IANA does not assign the value. We request IANA to 768 assign the 0x12 value, in order not to impose changes on existent 769 implemntations. 771 11. Security considerations 773 The goal of HBAs is to create a group of addresses that are securely 774 bound, so that they can be used interchangeably when communicating 775 with a node. If there is no secure binding between the different 776 addresses of a node, a number of attacks are enabled, as described in 777 [11]. In particular, it would possible for an attacker to redirect 778 the communications of a victim to an address selected by the 779 attacker, hijacking the communication. When using HBAs, only the 780 addresses belonging to an HBA set can be used interchangeably, 781 limiting the addresses that can be used to redirect the communication 782 to a well, pre-determined set, that belongs to the original node 783 involved in the communication. So, when using HBAs, a node that is 784 communicating using address A can redirect the communication to a new 785 address B if and only if B belongs to the same HBA set than A. 787 This means that if an attacker wants to redirect communications 788 addressed to address HBA1 to an alternative address IPX, the attacker 789 will need to create a CGA Parameters data structure that generates an 790 HBA set that contains both HBA1 and IPX. 792 In order to generate the required HBA set, the attacker needs to find 793 a CGA Parameter data structure that fulfills the following 794 conditions: 795 o the prefix of HBA1 and the prefix of IPX are included in the 796 Multi-Prefix Extension 797 o HBA1 is included in the HBA set generated. 799 (this assumes that it is acceptable for the attacker to redirect HBA1 800 to any address of the prefix of IPX). 802 The remaining fields that can be changed at will by the attacker in 803 order to meet the above conditions are: the Modifier, other prefixes 804 in the Multi-Prefix Extension and other extensions. In any case, in 805 order to obtain the desired HBA set, the attacker will have to use a 806 brute force attack, which implies the generation of multiple HBA sets 807 with different parameters (for instance with a different Modifier) 808 until the desired conditions are meet. The expected number of times 809 that the generation process will have to be repeated until the 810 desired HBA set is found is exponentially related with the number of 811 bits containing hash information included in the interface identifier 812 of the HBA. Since 59 of the 64 bits of the interface identifier 813 contain hash bits, then the expected number of generations that will 814 have to be performed by the attacker are O(2^59). 816 The protection against brute force attacks can be improved increasing 817 the Sec parameter. A non zero Sec parameter implies that steps 3-4 818 of the generation process will be repeated O(2^(16*Sec)) times 819 (expected number of times). If we assimilate the cost of repeating 820 the steps 3-4 to the cost of generating the HBA address, we can 821 estimate the number of times that the generation is to be repeated in 822 O(2^(59+16*Sec)) in the case of Sec values of 1 and 2. For other Sec 823 values, Sec protection mechanisms will be defined by the 824 specifications pointed by the CGA SEC registry defined in RFC 4982 825 [10]. 827 11.1. Security considerations when using HBAs in the shim6 protocol 829 In this section we will analyze the security provided by HBAs in the 830 context of a shim6 protocol as described in section 6 of this memo. 832 First of all, it must be noted that HBAs cannot prevent man-in-the- 833 middle (hereafter MITM) attacks. This means, that in the scenario 834 described in Section 6, if an attacker is located along the path 835 between Host1 and Host2 during the lifetime of the communication, the 836 attacker will be able to change the addresses used for the 837 communication. This means that he will be able to change the 838 addresses used in the communication, adding or removing prefixes at 839 his will. However, the attacker must make sure that the CGA 840 Parameter Data Structure and the HBA set is changed accordingly. 841 This essentially means that the attacker will have to change the 842 interface identifier part of the addresses involved, since a change 843 in the prefix set will result in different interface identifiers of 844 the addresses of the HBA set, unless the appropriate Modifier value 845 is used (which would require O(2(59+16*Sec)) attempts). So, HBA 846 don't provide MITM attacks protection, but a MITM attacker will have 847 to change the address used in the communication in order to change 848 the prefix set valid for the communication. 850 HBAs provide protection against time shifting attacks [11], [12]. In 851 the multihoming context, an attacker would perform a time-shifted 852 attack in the following way: an attacker placed along the path of the 853 communication will modify the packets to include an additional 854 address as a valid address for the communication. Then the attacker 855 would leave the on-path location, but the effects of the attack would 856 remain (i.e. the address would still be considered as a valid address 857 for that communication). Next we will present how HBAs can be used 858 to prevent such attacks. 860 If the attacker is not on-path when the initial CGA Parameter Data 861 Structure is exchanged, his only possibility to launch a redirection 862 attack is to fake the signature of the message for adding new 863 addresses using CGA capabilities of the addresses. This implies 864 discovering the public key used in the CGA Parameter Data Structure 865 and then cracking the key pair, which doesn't seem feasible. So in 866 order to launch a redirection attack, the attacker needs to be on- 867 path when the CGA Parameter Data Structure is exchanged, so he can 868 modify it. Now, in order to launch the redirection attack, the 869 attacker needs to add his own prefix in the prefix set of the CGA 870 Parameter Data Strcutre. We have seen in the previous section that 871 there are two possible approaches for this: 873 1. Find the right Modifier value, so that the address initially used 874 in the communication is contained in the new HBA set. The cost of 875 this attack is O(2(59+16*Sec)) iterations of the generation 876 process, so it is deemed unfeasible 877 2. Use any Modifier value, so that the address initially used in the 878 communication is probably not included in the HBA set. In this 879 case, the attacker must remain on-path, since he needs to rewrite 880 the address carried in the packets (if not the endpoints will 881 notice a change in the address used in the communication). This 882 essentially means that the attacker cannot launch a time-shifted 883 attack, but he must be a full time man-in-the-middle. 885 So, the conclusion is that HBAs provide protection against time- 886 shifted attacks 888 HBAs do not provide complete protection against flooding attacks, 889 However, HBAs make very difficult to launch a flooding attack towards 890 a specific address. It is possible though, to launch a flooding 891 attack against a prefix. 893 Suppose that an attacker has easy access to a prefix PX::/nX and that 894 he wants to launch a flooding attack to a host located in the address 895 P:iid. The attack would consist in establishing a communication with 896 a server S and requesting a heavy flow from it. Then simply redirect 897 the flow to P:iid, flooding the target. In order to perform this 898 attack the attacker needs to generate an HBA set including P and PX 899 in the prefix set and that the resulting HBA set contains P:iid. In 900 order to do this, the attacker needs to find the appropriate Modifier 901 value. The expected number of attempts required to find such 902 Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can 903 conclude that such attack is not feasible. 905 However, the target of a flooding attack is not limited to specific 906 hosts, but it can also be launched against other element of the 907 infrastructure, such as router or access links. In order to do that, 908 the attacker can establish a communication with a server S and 909 request a download of a heavy flow. Then, the attacker redirects the 910 communication to any address of the target network. Even if the 911 target address is not assigned to any host, the flow will flood the 912 access link of the target site, and the site access router will also 913 suffer the overload. Such attack cannot be prevented using HBAs, 914 since the attacker can easily generate an HBA set using his own 915 prefix and the target network prefix. In order to prevent such 916 attacks, additional mechanisms are required, such as reachability 917 tests. 919 11.2. Privacy Considerations 921 HBAs can be used as RFC 3041 [7] addresses. If a node wants to use 922 temporary addresses, it will need to periodically generate new HBA 923 sets. The effort required for this operation depends on the Sec 924 parameter value. If Sec=0, then the cost of generating a new HBA set 925 is similar to the cost of generating a random number i.e. one 926 iteration of the HBA set generation procedure. However, if Sec>0, 927 then the cost of generating an HBA set is significantly increased, 928 since it required O(2(16*Sec)) iterations of the generation process. 929 In this case, depending on the frequency of address change required, 930 the support for RFC 3041 address may be more expensive. 932 11.3. Interaction with IPSec. 934 In the case that both IPSec and CGA/HBA address are used 935 simultaneously, it is possible that two public keys are available in 936 a node, one for IPSec and another one for the CGA/HBA operation. In 937 this case, an improved security can be achieved by verifying that the 938 keys are related somehow, (in particular if the same key is used for 939 both purposes). The actual verification procedure is outside the 940 scope of this specification. 942 11.4. SHA-1 Dependency Considerations. 944 Recent attacks on currently used hash functions have motivated a 945 considerable amount of concern in the Internet community. The 946 recommended approach [14] [15] to deal with this issue is first to 947 analyze the impact of these attacks on the different Internet 948 protocols that use hash functions and second to make sure that the 949 different Internet protocols that use hash functions are capable of 950 migrating to an alternative (more secure) hash function without a 951 major disruption in the Internet operation. 953 The aforementioned analysis for CGAs and its extensions (including 954 HBAs) is performed in RFC4982 [10]. The conclusion of the analysis 955 is that the security of the protocols using CGAs and its extensions 956 is not affected by the recently available attacks against hash 957 functions. In spite of that, the CGA specification [2] was updated 958 by RFC4982 [10] to enable the support of alternative hash functions. 960 12. Contributors 962 This document was originally produced of a MULTI6 design team 963 consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo, 964 Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret 965 Wasserman, and Jukka Ylitalo. 967 13. Acknowledgments 969 The initial discussion about HBA benefited from contributions from 970 Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra. 972 The HBA-set generation and HBA verification processes described in 973 this document contain several steps extracted from [2]. 975 Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka 976 Savola, Brian Carpenter, Eric Rescorla, Robin Whittle and Sam Hartman 977 have reviewed this document and provided valuable comments. 979 The text included in section 2.2 Overview was provided by Eric 980 Rescorla. 982 We would also like to thanks Francis Dupont for providing the first 983 implementation of HBA 985 14. Change Log 987 To be removed prior publication 989 14.1. Changes from draft-ietf-shim6-hba-03 to draft-ietf-multi6-hba-04 991 Reworded the definition of the P flag 993 Changed IANA considerations to include a request to IANA to assign 994 the trial value. 996 Updated HBA generation and verification process to make coheret with 997 rfc4982 999 Updated the sha1 consideration section to make it coherent with 1000 rfc4982 1002 Updated the DNS consideration section to include an explicit 1003 references to ULAs and added a section about DNS managemnt of HBAs 1005 Editorial changes 1007 Updatred references 1009 14.2. Changes from draft-ietf-shim6-hba-02 to draft-ietf-multi6-hba-03 1011 added terminology section 1013 updated references 1015 14.3. Changes from draft-ietf-shim6-hba-01 to draft-ietf-multi6-hba-02 1017 A new section SHA-1 Dependency Considerations has been added in the 1018 Security Considerations Section (addressing Eric Rescorla (SecDir) 1019 comment) 1021 A new Overview section containing a Threat model subsection, a 1022 general description subsection and a motivations subsection has been 1023 added (addressing Eric Rescorla (SecDir) comment) 1025 Modified section of HBA verification in order to improve readability 1027 14.4. Changes from draft-ietf-shim6-hba-00 to draft-ietf-multi6-hba-01 1029 Changed the format of the Multi-Prefix extension to make it compliant 1030 with the generic TLV format proposed for CGA extensions 1032 Added IANA considerations section 1034 Added DNS considerations section 1036 14.5. Changes from draft-ietf-multi6-hba-00 to draft-ietf-shim6-hba-00 1038 Editorial changes 1040 14.6. Changes from draft-bagnulo-multi6dt-hba-00 to 1041 draft-ietf-multi6-hba-00 1043 Added "Example of HBA application to a multihoming scenario" section 1045 Added Privacy Considerations section 1047 Added flooding attacks comments in the Security Considerations 1048 section 1050 Added the Multi-Prefix extension in step 6.1 of the HBA-set 1051 generation process 1053 Added the Security considerations when using HBAs in a multi6 1054 protocol sub-section in the Security Considerations section 1056 Added Ext type value recommended for trials 1058 Changed the name of the draft 1060 Some rewording 1062 15. References 1064 15.1. Normative References 1066 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1067 Levels", BCP 14, RFC 2119, March 1997. 1069 [2] Aura, T., "Cryptographically Generated Addresses (CGA)", 1070 RFC 3972, April 2004. 1072 [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 1073 Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, 1074 July 2004. 1076 [4] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1077 Identifiers for the Internet X.509 Public Key Infrastructure 1078 Certificate and Certificate Revocation List (CRL) Profile", 1079 RFC 3279, April 2002. 1081 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1082 Public Key Infrastructure Certificate and Certificate 1083 Revocation List (CRL) Profile", RFC 3280, April 2002. 1085 [6] Hinden, R. and S. Deering, "IP Version 6 Addressing 1086 Architecture", RFC 4291, February 2006. 1088 [7] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1089 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1091 [8] Bagnulo, M. and J. Arkko, "Cryptographically Generated 1092 Addresses (CGA) Extension Field Format", RFC 4581, 1093 October 2006. 1095 [9] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim 1096 Protocol for IPv6", draft-ietf-shim6-proto-08 (work in 1097 progress), April 2007. 1099 [10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms 1100 in Cryptographically Generated Addresses (CGAs)", RFC 4982, 1101 July 2007. 1103 15.2. Informative References 1105 [11] Nordmark, E., "Threats relating to IPv6 multihoming solutions", 1106 RFC 4218, October 2005. 1108 [12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1109 Nordmark, "Mobile IP version 6 Route Optimization Security 1110 Design Background", RFC 4225, December 2005. 1112 [13] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying 1113 Cryptographically Generated Addresses to Optimize MIPv6 (CGA- 1114 OMIPv6)", draft-haddad-mip6-cga-omipv6-04 (work in progress), 1115 June 2004. 1117 [14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes 1118 in Internet Protocols", RFC 4270, November 2005. 1120 [15] Bellovin, S. and E. Rescorla, "Deploying a new hash algorithm", 1121 2005 September. 1123 [16] Nordmark, E., "Multi6 Application Referral Issues", 1124 draft-nordmark-multi6dt-refer-00 (work in progress), 1125 October 2004. 1127 [17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient 1128 Security for IPv6 Multihoming.", ACM Computer Communications 1129 Review Vol 35 n 2, April 2005. 1131 [18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1132 Addresses", RFC 4193, October 2005. 1134 Author's Address 1136 Marcelo Bagnulo 1137 Universidad Carlos III de Madrid 1138 Av. Universidad 30 1139 Leganes, Madrid 28911 1140 SPAIN 1142 Phone: 34 91 6249500 1143 Email: marcelo@it.uc3m.es 1144 URI: http://www.it.uc3m.es 1146 Full Copyright Statement 1148 Copyright (C) The IETF Trust (2007). 1150 This document is subject to the rights, licenses and restrictions 1151 contained in BCP 78, and except as set forth therein, the authors 1152 retain all their rights. 1154 This document and the information contained herein are provided on an 1155 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1156 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1157 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1158 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1159 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1160 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1162 Intellectual Property 1164 The IETF takes no position regarding the validity or scope of any 1165 Intellectual Property Rights or other rights that might be claimed to 1166 pertain to the implementation or use of the technology described in 1167 this document or the extent to which any license under such rights 1168 might or might not be available; nor does it represent that it has 1169 made any independent effort to identify any such rights. Information 1170 on the procedures with respect to rights in RFC documents can be 1171 found in BCP 78 and BCP 79. 1173 Copies of IPR disclosures made to the IETF Secretariat and any 1174 assurances of licenses to be made available, or the result of an 1175 attempt made to obtain a general license or permission for the use of 1176 such proprietary rights by implementers or users of this 1177 specification can be obtained from the IETF on-line IPR repository at 1178 http://www.ietf.org/ipr. 1180 The IETF invites any interested party to bring to its attention any 1181 copyrights, patents or patent applications, or other proprietary 1182 rights that may cover technology that may be required to implement 1183 this standard. Please address the information to the IETF at 1184 ietf-ipr@ietf.org. 1186 Acknowledgment 1188 Funding for the RFC Editor function is provided by the IETF 1189 Administrative Support Activity (IASA).