idnits 2.17.1 draft-ietf-shim6-hba-02.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 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1088. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1101. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 353: '...reserved field. MUST be initialized t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2006) is 6400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3280 (ref. '3') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3513 (ref. '4') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3041 (ref. '5') (Obsoleted by RFC 4941) -- Unexpected draft version: The latest known version of draft-bagnulo-shim6-cga-ext is -01, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-01 == Outdated reference: A later version (-04) exists of draft-haddad-mip6-cga-omipv6-02 == Outdated reference: A later version (-03) exists of draft-bagnulo-multiple-hash-cga-00 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Standards Track October 17, 2006 5 Expires: April 20, 2007 7 Hash Based Addresses (HBA) 8 draft-ietf-shim6-hba-02 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 20, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. Motivations for the HBA design . . . . . . . . . . . . . . 5 59 3. CGA compatibility considerations . . . . . . . . . . . . . . . 5 60 4. Multi-Prefix Extension for CGA . . . . . . . . . . . . . . . . 7 61 5. HBA-Set Generation . . . . . . . . . . . . . . . . . . . . . . 8 62 6. HBA verification . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.1. Verification that a particular HBA address corresponds 64 to a given CGA Parameter Data Strcuture . . . . . . . . . 11 65 6.2. Verification that a particular HBA address belongs tto 66 the HBA set associated to a given CGA Parameter Data 67 Strcuture . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. Example of HBA application to a multihoming scenario . . . . . 12 69 7.1. Dynamic Address Set Support . . . . . . . . . . . . . . . 15 70 8. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 16 71 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 72 10. Security considerations . . . . . . . . . . . . . . . . . . . 16 73 10.1. Security considerations when using HBAs in the shim6 74 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 10.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 19 76 10.3. Interaction with IPSec. . . . . . . . . . . . . . . . . . 20 77 10.4. SHA-1 Dependency Considerations. . . . . . . . . . . . . . 20 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 80 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 13.1. Changes from draft-ietf-shim6-hba-01 to 82 draft-ietf-multi6-hba-02 . . . . . . . . . . . . . . . . . 21 83 13.2. Changes from draft-ietf-shim6-hba-00 to 84 draft-ietf-multi6-hba-01 . . . . . . . . . . . . . . . . . 21 85 13.3. Changes from draft-ietf-multi6-hba-00 to 86 draft-ietf-shim6-hba-00 . . . . . . . . . . . . . . . . . 21 87 13.4. Changes from draft-bagnulo-multi6dt-hba-00 to 88 draft-ietf-multi6-hba-00 . . . . . . . . . . . . . . . . . 21 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 91 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 Intellectual Property and Copyright Statements . . . . . . . . . . 24 95 1. Introduction 97 In order to preserve inter-domain routing system scalability, IPv6 98 sites obtain addresses from their Internet Service Providers. Such 99 addressing strategy significantly reduces the amount of routes in the 100 global routing tables, since each ISP only announces routes to its 101 own address blocks, rather than announcing one route per customer 102 site. However, this addressing scheme implies that multihomed sites 103 will obtain multiple prefixes, one per ISP. Moreover, since each ISP 104 only announces its own address block, a multihomed site will be 105 reachable through a given ISP if the ISP prefix is contained in the 106 destination address of the packets. This means that, if an 107 established communication needs to be routed through different ISPs 108 during its lifetime, addresses with different prefixes will have to 109 be used. Changing the address used to carry packets of an 110 established communication exposes the communication to numerous 111 attacks, as described in [8], so security mechanisms are required to 112 provide the required protection to the involved parties. This memo 113 describes a tool that can be used to provide protection against some 114 of the potential attacks, in particular against future/ premeditated 115 attacks (a.k.a. time shifting attacks in [9]). 117 It should be noted that, as opposed to the mobility case where the 118 addresses that will be used by the mobile node are not known a 119 priori, the multiple addresses available to a host within the 120 multihomed site are pre-defined and known in advance in most of the 121 cases. The mechanism proposed in this memo takes advantage of this 122 address set stability, and provides a secure binding between all the 123 addresses of a node in a multihomed site. The mechanism does so 124 without requiring the usage of public key cryptography, providing a 125 cost efficient alternative to public key cryptography based schemes. 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. The main idea is that information about 130 the multiple prefixes is included within the addresses themselves. 131 This is achieved by generating the interface identifiers of the 132 addresses of a host as hashes of the available prefixes and a random 133 number. Then, the multiple addresses are obtained by prepending the 134 different prefixes to the generated interface identifiers. The 135 result is a set of addresses, called Hash Based Addresses (HBAs), 136 that are inherently bound. A cost efficient mechanism is available 137 to determine if two addresses belong to the same set, since given the 138 prefix set and the additional parameters used to generate the HBA, a 139 single hash operation is enough to verify if an HBA belongs to a 140 given HBA set. No public key operations are involved in the 141 verification process. In addition, it should also be noted that it 142 is not required that all interface identifiers of the addresses of an 143 HBA set are equal, preserving some degree of privacy through changes 144 in the addresses used during the communications. 146 2. Overview 148 2.1. Threat Model 150 The threat analysis for the multihoming problem is described in 151 [8].This analysis basically identifies attacks based on redirection 152 of packets by a malicious attacker towards addresses that do not 153 belong to the multihomed node. There are essentially two type of 154 redirection attacks: communication hijacking and flooding attacks. 155 communication hijacking attacks are about an attacker stealing on- 156 going and/or future communications from a victim. Flooding attacks 157 are about redirecting the traffic generated by a legitimate source 158 towards a third party, flooding it. The HBA solution provides full 159 protection against the communication hijacking attacks and limited 160 protection against flooding attacks. Residual threats are described 161 in the security cosniderations section. 163 2.2. Overview 165 The basic goal of the HBA mechanism is to securely bind together 166 multiple IPv6 addresses that belong to the same multihomed host. 167 This allows rerouting of traffic without worrying that the 168 communication is being redirected to an attacker. The technique that 169 is used is to inlcude a hash of the permitted prefixes in the low 170 order bits of the IPv6 address. 172 So, eliding some details, say the available prefixes are A, B, C, and 173 D, the host would generate a prefix list P consisting of (A,B,C,D) 174 and a random number M. Then it would generate the new addresses: 176 A || H(M || A || P) 178 B || H(M || B || P) 180 C || H(M || C || P) 182 D || H(M || D || P) 184 Thus, given one valid address out of the group and the prefix list P 185 and the random number M it is possible to determine whether another 186 address is part of the group by computing the hash and checking 187 against the low order bits. 189 2.3. Motivations for the HBA design 191 The design of the HBA technique was dirven by the following 192 considerations: 194 First of all, the goal of HBA is to provide a secure binding between 195 the IPv6 address used as identifier by the upper layer protocols and 196 the alternative locators available in the multihomed node, so that 197 redirection attacks are prevented. 199 Second, in order to achieve such protection, the selected approach 200 was to include security information in the identifer itself, instead 201 of relying in third trusted parties to secure the binding, such as 202 the ones based on repositories or Public Key Infrastructure. this 203 decision was driven by deployment considerations i.e. the cost of 204 deploying the third trusted party infrastucture. 206 Third, application support considerations described in [14] resulted 207 in selecting routable IPv6 addresses to be used as identifiers. 208 Hence, security information is stuffed within the interface 209 identifier part of the IPv6 address. 211 Fourth, performance considerations as described in [15] motivated the 212 usage of a hash based approach as oposed to a public key based 213 approach based on pure CGA, in order to avoid imposing the 214 performance of public key operations for every communication in 215 multihomed environments. The HBA appraoch presented in this document 216 present a cheaper alternative that is attractive to many common usage 217 cases. Note that the HBA appraoch and the CGA appraoches are not 218 mutually exclusive and that it is possible to generate addresses that 219 are both CGA and HBA providing the benefits of both approaches if 220 needed. 222 3. CGA compatibility considerations 224 As described in previous section, the HBA technique uses the 225 interface identifier part of the IPv6 address to encode information 226 about the multiple prefixes available to a multihomed host. However, 227 the interface identifier is also used to carry cryptographic 228 information when Cryptographic Generated Addresses [1] are used. 229 Therefore, conflicting usages of the interface identifier bits may 230 result if this is not taken into account during the HBA design. 231 There are at least two valid reasons to provide CGA-HBA 232 compatibility: 234 First, the current Secure Neighbor Discovery specification [2] uses 235 the CGAs defined in [1] to prove address ownership. If HBAs are not 236 compatible with CGAs, then nodes using HBAs for multihoming wouldn't 237 be able to do Secure Neighbor Discovery using the same addresses (at 238 least the parts of SeND that require CGAs). This would imply that 239 nodes would have to choose between security (from SeND) and fault 240 tolerance (from shim6). In addition to SeND, there are other 241 protocols that are considering to benefit from the advantages offered 242 by the CGA scheme, such as mobility support protocols [10]. Those 243 protocols would also become incompatible with HBAs if HBAs are not 244 compatible with CGAs. 246 Second, CGAs provide additional features that cannot be achieved 247 using only HBAs. In particular, because of its own nature, the HBA 248 technique only supports a predetermined prefix set that is known at 249 the time of the generation of the HBA set. No additions of new 250 prefixes to this original set are supported after the HBA set 251 generation. In most of the cases relevant for site multihoming, this 252 is not a problem because the prefix set available to a multihomed set 253 is not very dynamic. New prefixes may be added in a multihomed site 254 when a new ISP is available, but the timing of those events are 255 rarely in the same time scale than the lifetime of established 256 communications. It is then enough for many situations that the new 257 prefix is not available for established communications and that only 258 new communications benefit from it. However, in the case that such 259 functionality is required, it is possible to use CGAs to provide it. 260 This approach clearly requires that HBA and CGA approaches are 261 compatible. If this is the case, it then would be possible to create 262 HBA/CGA addresses that support CGA and HBA functionality 263 simultaneously. The inputs to the HBA/CGA generation process will be 264 both a prefix set and a public key. In this way, a node that has 265 established a communication using one address of the CGA/HBA set can 266 tell its peer to use the HBA verification when one of the addresses 267 of its HBA/CGA set is used as locator in the communication or to use 268 CGA (public/private key based) verification when a new address that 269 does not belong to the HBA/CGA set is used as locator in the 270 communication. 272 So, because of the aforementioned reasons, it is a goal of the HBA 273 design to define HBAs in a way that they are compatible with CGAs as 274 defined in [1] and their usages described in [2] (Consequently, to 275 understand the rest of this note, the reader should be familiar with 276 the CGA specification defined in [1]). This means that it must be 277 possible to generate addresses that are both an HBA and a CGA i.e. 278 that the interface identifier contains cryptographic information of 279 CGA and the prefix-set information of an HBA. The CGA specification 280 already considers the possibility of including additional information 281 into the CGA generation process through the usage of Extension Fields 282 in the CGA Parameter Data Structure. It is then possible to define a 283 Multi-Prefix Extension for CGA so that the prefix set information is 284 included in the interface identifier generation process. 286 Even though a CGA compatible approach is adopted, it should be noted 287 that HBAs and CGAs are different concepts. In particular, the CGA is 288 inherently bound to a public key, while a HBA is inherently bound to 289 a prefix set. This means that a public key is not strictly required 290 to generate an HBA. Because of that, we define three different types 291 of addresses: 293 - CGA-only addresses: These are addresses generated as specified in 294 [1] without including the Multi-Prefix Extension. They are bound 295 to a public key and to a single prefix (contained in the basic CGA 296 Parameter Data Structure). These addresses can be used for SeND 297 [2] and if used for multihoming, their application will have to be 298 based on the public key usage. 300 - CGA/HBA addresses: These addresses are CGAs that include the 301 Multi-Prefix Extension in the CGA Parameters Data Structure used 302 for their generation. These addresses are bound to a public key 303 and a prefix set and they provide both CGA and HBA 304 functionalities. They can be used for SeND as defined in [2] and 305 for any usage defined for HBA (such as a shim6 protocol) 307 - HBA-only addresses: These addresses are bound to a prefix set but 308 they are not bound to a public key. Because CGA compatibility, 309 the CGA Parameter Data Structure will be used for their 310 generation, but a random nonce will be included in the Public Key 311 field instead of a public key. These addresses can be used for 312 HBA based multihoming protocols, but they cannot be used for SeND. 314 4. Multi-Prefix Extension for CGA 316 The Multi-Prefix Extension has the following TLV format as defined in 317 [6] : 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Extension Type | Extension Data Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |P| Reserved | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | | 327 + Prefix[1] + 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 + Prefix[2] + 332 | | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 . . . 335 . . . 336 . . . 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 + Prefix[n] + 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Ext Type: 16-bit type identifier of the Multi-Prefix Extension (TBD 344 IANA) (Meanwhile, the 0x12 value is recommended for trails) 346 Ext Len: 16-bit unsigned integer. Length of the Extension in 347 octets, not including the first 4 octets. 349 P flag: Set if a public key is included in the Public Key field of 350 the CGA Parameter Data Structure. Reset if a additional Modifier 351 bits are included in the CGA Parameter Data Structure. 353 Reserved: 31-bit reserved field. MUST be initialized to zero, and 354 ignored upon receipt. 356 Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n. 358 5. HBA-Set Generation 360 The HBA generation process is based on the CGA generation process 361 defined in section 4 of [1]. The goal is to require the minimum 362 amount of changes to the CGA generation process. 364 The CGA generation process has three inputs: a 64-bit subnet prefix, 365 a public key (encoded in DER as an ASN.1 structure of the type 366 SubjectPublicKeyInfo), and the security parameter Sec. 368 The main difference between the CGA generation and the HBA generation 369 is that while a CGA can be generated independently, all the HBAs of a 370 given HBA set have to be generated using the same parameters, which 371 implies that the generation of the addresses of an HBA set will occur 372 in a coordinated fashion. In this memo, we will describe a mechanism 373 to generate all the addresses of a given HBA set. The generation 374 process of each one of the HBA address of an HBA set will be heavily 375 based in the CGA generation process defined in [1]. More precisely, 376 the HBA set generation process will be defined as a sequence of 377 lightly modified CGA generations. 379 The changes required in the CGA generation process when generating a 380 single HBA are the following: First, the Multi-Prefix Extension has 381 to be included in the CGA Parameters Data Structure. Second, in the 382 case that the address being generated is an HBA-only address, a 383 random nonce (encoded in DER as an ASN.1 structure of the type 384 SubjectPublicKeyInfo) will have to be used as input instead of a 385 valid public key. 387 The resulting HBA-set generation process is the following: 389 The inputs to the HBA generation process are: 390 o A vector of n 64-bit prefixes 391 o A Sec parameter, and 392 o In the case of the generation of a set of HBA/CGA addresses a 393 public key is also provided as input (not required when generating 394 HBA-only addresses) 396 The output of the HBA generation process are: 397 o An HBA-set 398 o their respective CGA Parameters Data Structures 400 The steps of the HBA-set generation process are: 402 1. Multi-Prefix Extension generation. Generate the Multi-Prefix 403 Extension with the format defined in section 3. Include the 404 vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext 405 Len field value is (n*8 + 4). If a public key is provided, then 406 the P flag is set. Otherwise, the P flag is reset. 408 2. Modifier generation. Generate a Modifier as a random or 409 pseudorandom 128-bit value. If a public key has not been provided 410 as an input, generate the Extended Modifier as a 384-bit random or 411 pseudorandom value. Encode the Extended Modifier value as a RSA 412 key in a DER-encoded ASN.1 structure of the type 413 SubjectPublicKeyInfo defined in the Internet X.509 certificate 414 profile [3]. 416 3. Concatenate from left to right the Modifier, 9 zero octets, the 417 encoded public key or the encoded Extended Modifier (if no public 418 key was provided) and the Multi-Prefix Extension. Execute the 419 SHA-1 algorithm on the concatenation. Take the 112 leftmost bits 420 of the SHA-1 hash value. The result is Hash2. 422 4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are 423 all zero (or if Sec=0), continue with step (5). Otherwise, 424 increment the modifier by one and go back to step (3). 426 5. Set the 8-bit collision count to zero. 428 6. For i=1 to n do 430 6.1. Concatenate from left to right the final Modifier value, 431 Prefix[i], the collision count, the encoded public key or the 432 encoded Extended Modifier (if no public key was provided) and 433 the Multi-Prefix Extension. Execute the SHA-1 algorithm on the 434 concatenation. Take the 64 leftmost bits of the SHA-1 hash 435 value. The result is Hash1[i]. 437 6.2. Form an interface identifier from Hash1[i] by writing the 438 value of Sec into the three leftmost bits and by setting bits 6 439 and 7 (i.e., the "u" and "g" bits) both to zero. 441 6.3. Generate address HBA[i] by concatenating Prefix[i] and the 442 64-bit interface identifier to form a 128-bit IPv6 address with 443 the subnet prefix to the left and interface identifier to the 444 right as in a standard IPv6 address [4]. 446 6.4. Perform duplicate address detection if required. If an 447 address collision is detected, increment the collision count by 448 one and go back to step (6). However, after three collisions, 449 stop and report the error. 451 6.5. Form the CGA Parameters Data Structure that corresponds to 452 HBA[i] by concatenating from left to right the final modifier 453 value, Prefix[i], the final collision count value, the encoded 454 public key or the encoded Extended Modifier and the Multi- 455 Prefix Extension. 457 [Note: most of the steps of the process are taken from [1]] 459 6. HBA verification 461 6.1. Verification that a particular HBA address corresponds to a given 462 CGA Parameter Data Strcuture 464 HBAs are constructed as a CGA Extension, so a properly formated HBA 465 and its correspondent CGA Parameter Data Structure will successfully 466 finish the verification process described in section 5 of [1]. Such 467 verification is useful when the goal is the verification of the 468 binding between the public key and the HBA. 470 6.2. Verification that a particular HBA address belongs tto the HBA set 471 associated to a given CGA Parameter Data Strcuture 473 For multihoming applications, it is also relevant to verify if a 474 given HBA address belongs to a certain HBA set. An HBA set is 475 identified by a CGA Parameter Data structure that contains a Multi- 476 Prefix Extension. So, it is then needed to verify if an HBA belongs 477 to the HBA set defined by a CGA Parameter Data Structure. It should 478 be noted that it may be needed to verify if an HBA belongs to the HBA 479 set defined by the CGA Parameter Data Structure of another HBA of the 480 set. If this is the case, the CGA verification process as defined in 481 [1] will fail, because the prefix included in the Subnet Prefix field 482 of the CGA Parameter Data Structure will not match with the one of 483 the HBA that is being verified. However, this not means that this 484 HBA does not belong to the HBA set. In order to address this issue, 485 it is only required to verify that the HBA prefix is included in 486 prefix set defined in the Multi-Prefix Extension, and if this is the 487 case, then substitute the prefix included in the Subnet Prefix field 488 by the prefix of the HBA, and then perform the CGA verification 489 process defined in [1]. 491 So, the process to verify that an HBA belongs to an HBA set 492 determined by a CGA Parameter Data Structure is called HBA 493 verification and it is the following: 495 The inputs to the HBA verification process are: 496 o An HBA 497 o An CGA Parameter Data Structure 499 The steps of the HBA verification process are the following: 501 1. Verify that the 64-bit HBA prefix is included in the prefix set of 502 the Multi-Prefix Extension. If it is not included, the 503 verification fails. If it is included, replace the prefix 504 contained in the Subnet Prefix field of the CGA Parameter Data 505 Structure by the 64-bit HBA prefix. 507 2. Run the verification process described in section 5 of [1] with 508 the HBA and the new CGA Parameters Data Structure (including the 509 Multi-Prefix Extension) as inputs. The steps of the process are 510 included below, extracted from [1] 512 2.1. Check that the collision count in the CGA Parameters Data 513 Structure is 0, 1 or 2. The CGA verification fails if the 514 collision count is out of the valid range. 516 2.2. Check that the subnet prefix in the CGA Parameters Data 517 Structure is equal to the subnet prefix (i.e., the leftmost 64 518 bits) of the address. The CGA verification fails if the prefix 519 values differ. [Note: This step is trivially successful 520 because step 1] 522 2.3. Execute the SHA-1 algorithm on the CGA Parameters Data 523 Structure. Take the 64 leftmost bits of the SHA-1 hash value. 524 The result is Hash1. 526 2.4. Compare Hash1 with the interface identifier (i.e., the 527 rightmost 64 bits) of the address. Differences in the three 528 leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) 529 are ignored. If the 64-bit values differ (other than in the 530 five ignored bits), the CGA verification fails. 532 2.5. Read the security parameter Sec from the three leftmost bits 533 of the 64-bit interface identifier of the address. (Sec is an 534 unsigned 3-bit integer.) 536 2.6. Concatenate from left to right the modifier, 9 zero octets, 537 and the public key, and any extension fields [in this case, the 538 Multi-Prefix Extension will be included, at least] that follow 539 the public key in the CGA Parameters data structure. Execute 540 the SHA-1 algorithm on the concatenation. Take the 112 541 leftmost bits of the SHA-1 hash value. The result is Hash2. 543 2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any 544 one of them is non-zero, the CGA verification fails. 545 Otherwise, the verification succeeds. (If Sec=0, the CGA 546 verification never fails at this step.) 548 7. Example of HBA application to a multihoming scenario 550 In this section, we will describe a possible application of the HBA 551 technique to IPv6 multi-homing. 553 We will consider the following scenario: a multihomed site obtains 554 Internet connectivity through two providers ISPA and ISPB. Each 555 provider has delegated a prefix to the the multihomed site 556 (PrefA::/nA and PrefB::/nb respectively). In order to benefit from 557 multihoming, the hosts within the multihomed site will configure 558 multiple IP addresses, one per available prefix. The resulting 559 configuration is depicted in the next figure. 561 +-------+ 562 | Host2 | 563 |IPHost2| 564 +-------+ 565 | 566 | 567 (Internet) 568 / \ 569 / \ 570 +------+ +------+ 571 | ISPA | | ISPB | 572 | | | | 573 +------+ +------+ 574 | | 575 \ / 576 \ / 577 +---------------------+ 578 | multihomed site | 579 | PA::/nA | 580 | PB::/nB +------+ | 581 | |Host1 | | 582 | +------+ | 583 +---------------------+ 585 We assume that both Host1 and Host2 support the shim6 protocol. 587 Host2 in not located in a multihomed site, so there is no need for 588 him to create HBAs (it must be able to verify them though, in order 589 to support the shim6 protocol, as we will describe next.) 591 Host1 is located in the multihomed site, so it will generate its 592 addresses as HBAs. In order to do that, it needs to execute the HBA- 593 set generation process as detailed in Section 4 of this memo. The 594 inputs of the HBA-set generation process will be: a prefix vector 595 containing the two prefixes available in its link i.e. PA:LA::/64 596 and PB:LB::/64, a Sec parameter value, and optionally a public key. 597 In this case we will assume that a public key is provided so that we 598 can also illustrate how a renumbering event can be supported when 599 HBA/CGA addresses are used (see the sub-section referring to dynamic 600 address set support). So, after executing the HBA-set generation 601 process, Host1 will have: an HBA-set consisting in two addresses i.e. 602 PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data 603 Structures i.e. CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are 604 different but both contain information about the prefix set available 605 in the multihomed site. 607 We will next consider a communication between Host1 and Host2. 608 Assume that both ISPs of the multihomed site are working properly, so 609 any of the available addresses in Host1 can be used for the 610 communication. Suppose then that the communication is established 611 using PA:LA:iidA and IPHost2 for Host1 and Host2 respectively. So 612 far, no special shim6 support has been required, and PA:LA:iidA is 613 used as any other global IP address 615 Suppose that at a certain moment one of the hosts involved in the 616 communication decides that multihoming support is required in this 617 communication (this basically means that one of the hosts involved in 618 the communication desires enhanced fault tolerance capabilities for 619 this communication, so that if an outage occurs, the communication 620 can be rehomed to an alternative provider). 622 At this moment, the shim6 protocol Host-Pair Context establishment 623 exchange will be perfomed between the two hosts (see [7].). In this 624 exchange, Host1 will send CGA_PDS_A to Host2. 626 After the reception of CGA_PDS_A, Host2 will verify that the received 627 CGA Parameter Data Structure corresponds to the address being used in 628 the communication PA:LA:iidA. this means that Host2 will execute the 629 HBA verification process described in Section 5 of this memo with PA: 630 LA:iidA and CGA_PDS_A as inputs. In this case, the verification will 631 succeed since the CGA Parameter Data Structure and the addresses used 632 in the verification match. 634 As long as there are no outages affecting the communication path 635 through ISPA, packets will continue flowing. If a failure affects 636 the path through ISPA, Host1 will attempt to re-home the 637 communication to an alternative address i.e. PB:LB:iidB. For that, 638 after detecting the outage, Host1 will inform Host2 about the 639 alternative address. Host2 will verify that the new address belongs 640 to the HBA set of the initial address. For that, Host2 will execute 641 the HBA verification process with the CGA Parameter Data Structure of 642 the original address (i.e. CGA_PDS_A) and the new address (i.e. PB: 643 LB:iidB) as inputs. The verification process will succeed because 644 PB:LB::/64 has been included in the Multi-Prefix Extension during the 645 HBA-set generation process. Additional verifications may be required 646 to prevent flooding attacks (see the comments about flooding attacks 647 prevention in the Security Considerations section of this memo). 649 Once the new address is verified, it can be used as an alternative 650 locator to re-home the communication, while preserving the original 651 address (PA:LA:iidA) ad identifier for the upper layers. This means 652 that following packets will be addressed to/from this new address. 653 Note that no additional HBA verification is required for the 654 following packets, since the new valid address can be stored in 655 Host2. 657 Eventually, the communication will end and the associated shim6 658 context information will be discarded. 660 In this example, only the HBA capabilities of the Host1 addresses 661 were used. In other words, neither the public key included in the 662 CGA Parameter Data Structure nor its correspondent private key was 663 used in the protocol. In the following section we will consider a 664 case where its usage is required. 666 7.1. Dynamic Address Set Support 668 In the previous section we have presented the mechanisms that allow a 669 host to use different addresses of a pre-determined set to exchange 670 packets of a communication. The set of addresses involved was pre- 671 determined and known when the communication was initiated. To 672 achieve such functionality, only HBA functionalities of the addresses 673 were needed. In this section we will explore the case where the goal 674 is to exchange packets using additional addresses that were not known 675 when the communication was established. An example of such situation 676 is for instance when a new prefix is available in a site after a 677 renumbering event. In this case, the hosts that have the new address 678 available may want to use it in communications that were established 679 before the renumbering event. In this case, HBA functionalities of 680 the addresses are not enough and CGA capabilities are to be used. 682 Consider then the previous case of the communication between Host1 683 and Host2. Suppose that the communication is up and running, as 684 described earlier. Host1 is using PA:LA:iidA and Host2 is using 685 IPHost2 to exchange packets. Now suppose that a new address, PC:LC: 686 addC is available in Host1. Note that this address is just a regular 687 IPv6 address, and it is neither an HBA nor a CGA. Host1 wants to use 688 this new address in the existent communication with Host2. It should 689 be noted that the HBA mechanism described in the previous section 690 cannot be used to verify this new address, since this address does 691 not belong to the HBA set (since the prefix was not available at the 692 moment of the generation of the HBA set). This means that 693 alternative verification mechanisms will be needed. 695 In order to verify this new address, CGA capabilities of PA:LA:iidA 696 are used. Note that the same address is used, only that the 697 verification mechanism is different. So, if Host1 wants to use PC: 698 LC:addC to exchange packets in the established communication, it will 699 use message of the shim6 protocol, conveying the new address, PC:LC: 700 addC, and this message will be signed using the private key 701 corresponding to the public key contained in CGA_PDS_A. When Host2 702 receives the message, it will verify the signature using the public 703 key contained in the CGA Parameter Data Structure associated with the 704 address used for establishing the communication i.e. CGA_PDS_A and 705 PA:LA:iidA respectively. Once that the signature is verified, the 706 new address (PC:LC:addC) can be used in the communication. 708 8. DNS considerations 710 HBA sets can be generated using any prefix set. Actually, the only 711 particularity of the HBA is that they contain information about the 712 prefix set in the interface identifier part of the address in the 713 form of a hash, but no assumption about the properties of prefixes 714 used for the HBA generation is made. This basically means that 715 depending on the prefixes used for the HBA set generation, it may or 716 may not be recommended to publish the resulting (HBA) addresses in 717 the DNS. 719 9. IANA considerations 721 This document defines a new CGA Extension, the Multi-Prefix 722 Extension. This extension has been assigned the CGA Extension Type 723 value TBD (IANA). 725 10. Security considerations 727 The goal of HBAs is to create a group of addresses that are securely 728 bound, so that they can be used interchangeably when communicating 729 with a node. If there is no secure binding between the different 730 addresses of a node, a number of attacks are enabled, as described in 731 [8]. It particular, it would possible for an attacker to redirect 732 the communications of a victim to an address selected by the 733 attacker, hijacking the communication. When using HBAs, only the 734 addresses belonging to an HBA set can be used interchangeably, 735 limiting the addresses that can be used to redirect the communication 736 to a well, pre-determined set, that belongs to the original node 737 involved in the communication. So, when using HBAs, a node that is 738 communicating using address A can redirect the communication to a new 739 address B if and only if B belongs to the same HBA set than A. 741 This means that if an attacker wants to redirect communications 742 addressed to address HBA1 to an alternative address IPX, the attacker 743 will need to create a CGA Parameters data structure that generates an 744 HBA set that contains both HBA1 and IPX. 746 In order to generate the required HBA set, the attacker needs to find 747 a CGA Parameter data structure that fulfills the following 748 conditions: 749 o the prefix of HBA1 and the prefix of IPX are included in the 750 Multi-Prefix Extension 751 o HBA1 is included in the HBA set generated. 753 (this assumes that it is acceptable for the attacker to redirect HBA1 754 to any address of the prefix of IPX). 756 The remaining fields that can be changed at will by the attacker in 757 order to meet the above conditions are: the Modifier, other prefixes 758 in the Multi-Prefix Extension and other extensions. In any case, in 759 order to obtain the desired HBA set, the attacker will have to use a 760 brute force attack, which implies the generation of multiple HBA sets 761 with different parameters (for instance with a different Modifier) 762 until the desired conditions are meet. The expected number of times 763 that the generation process will have to be repeated until the 764 desired HBA set is found is exponentially related with the number of 765 bits containing hash information included in the interface identifier 766 of the HBA. Since 59 of the 64 bits of the interface identifier 767 contain hash bits, then the expected number of generations that will 768 have to be performed by the attacker are O(2^59). 770 The protection against brute force attacks can be improved increasing 771 the Sec parameter. A non zero Sec parameter implies that steps 3-4 772 of the generation process will be repeated O(2^(16*Sec)) times 773 (expected number of times). If we assimilate the cost of repeating 774 the steps 3-4 to the cost of generating the HBA address, we can 775 estimate the number of times that the generation is to be repeated in 776 O(2^(59+16*Sec)). 778 10.1. Security considerations when using HBAs in the shim6 protocol 780 In this section we will analyze the security provided by HBAs in the 781 context of a shim6 protocol as described in section 6 of this memo. 783 First of all, it must be noted that HBAs cannot prevent man-in-the- 784 middle (hereafter MITM) attacks. This means, that in the scenario 785 described in Section 6, if an attacker is located along the path 786 between Host1 and Host2 during the lifetime of the communication, the 787 attacker will be able to change the addresses used for the 788 communication. This means that he will be able to change the 789 addresses used in the communication, adding or removing prefixes at 790 his will. However, the attacker must make sure that the CGA 791 Parameter Data Structure and the HBA set is changed accordingly. 792 This essentially means that the attacker will have to change the 793 interface identifier part of the addresses involved, since a change 794 in the prefix set will result in different interface identifiers of 795 the addresses of the HBA set, unless the appropriate Modifier value 796 is used (which would require O(2(59+16*Sec)) attempts). So, HBA 797 don't provide MITM attacks protection, but a MITM attacker will have 798 to change the address used in the communication in order to change 799 the prefix set valid for the communication. 801 HBAs provide protection against time shifting attacks [8], [9]. In 802 the multihoming context, an attacker would perform a time-shifted 803 attack in the following way: an attacker placed along the path of the 804 communication will modify the packets to include an additional 805 address as a valid address for the communication. Then the attacker 806 would leave the on-path location, but the effects of the attack would 807 remain (i.e. the address would still be considered as a valid address 808 for that communication). Next we will present how HBAs can be used 809 to prevent such attacks. 811 If the attacker is not on-path when the initial CGA Parameter Data 812 Structure is exchanged, his only possibility to launch a redirection 813 attack is to fake the signature of the message for adding new 814 addresses using CGA capabilities of the addresses. This implies 815 discovering the public key used in the CGA Parameter Data Structure 816 and then cracking the key pair, which doesn't seem feasible. So in 817 order to launch a redirection attack, the attacker needs to be on- 818 path when the CGA Parameter Data Structure is exchanged, so he can 819 modify it. Now, in order to launch the redirection attack, the 820 attacker needs to add his own prefix in the prefix set of the CGA 821 Parameter Data Strcutre. We have seen in the previous section that 822 there are two possible approaches for this: 823 1. Find the right Modifier value, so that the address initially used 824 in the communication is contained in the new HBA set. The cost of 825 this attack is O(2(59+16*Sec)) iterations of the generation 826 process, so it is deemed unfeasible 827 2. Use any Modifier value, so that the address initially used in the 828 communication is probably not included in the HBA set. In this 829 case, the attacker must remain on-path, since he needs to rewrite 830 the address carried in the packets (if not the endpoints will 831 notice a change in the address used in the communication). This 832 essentially means that the attacker cannot launch a time-shifted 833 attack, but he must be a full time man-in-the-middle. 835 So, the conclusion is that HBAs provide protection against time- 836 shifted attacks 838 HBAs do not provide complete protection against flooding attacks, 839 However, HBAs make very difficult to launch a flooding attack towards 840 a specific address. It is possible though, to launch a flooding 841 attack against a prefix. 843 Suppose that an attacker has easy access to a prefix PX::/nX and that 844 he wants to launch a flooding attack to a host located in the address 845 P:iid. The attack would consist in establishing a communication with 846 a server S and requesting a heavy flow from it. Then simply redirect 847 the flow to P:iid, flooding the target. In order to perform this 848 attack the attacker need to generate an HBA set including P and PX in 849 the prefix set and that the resulting HBA set contains P:iid. In 850 order to do this, the attacker need to find the appropriate Modifier 851 value. The expected number of attempts required to find such 852 Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can 853 conclude that such attack is not feasible. 855 However, the target of a flooding attack is not limited to specific 856 hosts, but it can also be launched against other element of the 857 infrastructure, such as router or access links. In order to do that, 858 the attacker can establish a communication with a server S and 859 request a download of a heavy flow. Then, the attacker redirects the 860 communication to any address of the target network. Even if the 861 target address is not assigned to any host, the flow will flood the 862 access link of the target site, and the site access router will also 863 suffer the overload. Such attack cannot be prevented using HBAs, 864 since the attacker can easily generate an HBA set using his own 865 prefix and the target network prefix. In order to prevent such 866 attacks, additional mechanisms are required, such as reachability 867 tests. 869 10.2. Privacy Considerations 871 HBAs can be used as RFC 3041 [5]. addresses. If a node wants to use 872 temporary addresses, it will need to periodically generate new HBA 873 sets. The effort required for this operation depends on the Sec 874 parameter value. If Sec=0, then the cost of generating a new HBA set 875 is similar to the cost of generating a random number i.e. one 876 iteration of the HBA set generation procedure. However, if Sec>0, 877 then the cost of generating an HBA set is significantly increased, 878 since it required O(2(16*Sec)) iterations of the generation process. 879 In this case, depending on the frequency of address change required, 880 the support for RFC 3041 address may be more expensive. 882 10.3. Interaction with IPSec. 884 In the case that both IPSec and CGA/HBA address are used 885 simultaneously, it is possible that two public keys are available in 886 a node, one for IPSec and another one for the CGA/HBA operation. In 887 this case, an improved security can be achieved by verifying that the 888 keys are related somehow, (in particular if the same key is used for 889 both purposes). 891 10.4. SHA-1 Dependency Considerations. 893 Recent attacks to currently used hash functions have motivated a 894 considerable amount of concern in the Internet community. The 895 recommended approach [12] [13] to deal with this issue is first to 896 analyze the impact of these attacks on the different Internet 897 protocols that use hash functions and second to make sure that the 898 different Internet protocols that use hash functions are capable of 899 migrating to an alternative (more secure) hash function without a 900 major disruption in the Internet operation. 902 The aforementioned analysis for CGAs and its extensions (including 903 HBAs) is performed in [11]. The conclusion of the analysis is that 904 the security of the protocols using CGAs and its extensions is not 905 affected by the recently available attacks against hash functions. 906 In spite of that an update to the CGA specification [1] to enable the 907 support of alternative hash functions is proposed in [11]. In case 908 that the proposed modifications are adopted for CGAs and that new 909 mechanisms for generating CGAs are defined using alternative hash 910 functions, HBA generation/verification mehtods will need to be 911 produced compliant with the new CGA generation/verification methods 912 defined. 914 11. Contributors 916 This document was originally produced of a MULTI6 design team 917 consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo, 918 Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret 919 Wasserman, and Jukka Ylitalo. 921 12. Acknowledgments 923 The initial discussion about HBA benefited from contributions from 924 Alberto Garcia-Martinez, Tuomas Aura and Arturo Azcorra. 926 The HBA-set generation and HBA verification processes described in 927 this document contain several steps extracted from [1]. 929 Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka 930 Savola, Brian Carpenter, Eric Rescorla and Sam Hartman have reviewed 931 this document and provided valuable comments. 933 The text included in section 2.2 Overview was provided by Eric 934 Rescorla. 936 We would also like to thanks Francis Dupont for providing the first 937 implementation of HBA 939 13. Change Log 941 To be removed prior publication 943 13.1. Changes from draft-ietf-shim6-hba-01 to draft-ietf-multi6-hba-02 945 A new section SHA-1 Dependency Considerations has been added in the 946 Security Considerations Section (addressing Eric Rescorla (SecDir) 947 comment) 949 A new Overview section containing a Threat model subsection, a 950 general description subsection and a motivations subsection has been 951 added (addressing Eric Rescorla (SecDir) comment) 953 Modified section of HBA verification in order to improve readability 955 13.2. Changes from draft-ietf-shim6-hba-00 to draft-ietf-multi6-hba-01 957 Changed the format of the Multi-Prefix extension to make it compliant 958 with the generic TLV format proposed for CGA extensions 960 Added IANA considerations section 962 Added DNS considerations section 964 13.3. Changes from draft-ietf-multi6-hba-00 to draft-ietf-shim6-hba-00 966 Editorial changes 968 13.4. Changes from draft-bagnulo-multi6dt-hba-00 to 969 draft-ietf-multi6-hba-00 971 Added "Example of HBA application to a multihoming scenario" section 973 Added Privacy Considerations section 975 Added flooding attacks comments in the Security Considerations 976 section 978 Added the Multi-Prefix extension in step 6.1 of the HBA-set 979 generation process 981 Added the Security considerations when using HBAs in a multi6 982 protocol sub-section in the Security Considerations section 984 Added Ext type value recommended for trials 986 Changed the name of the draft 988 Some rewording 990 14. References 992 14.1. Normative References 994 [1] Aura, T., "Cryptographically Generated Addresses (CGA)", 995 RFC 3972, April 2004. 997 [2] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 998 "SEcure Neighbor Discovery (SEND)", RFC 3971, July 2004. 1000 [3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1001 Public Key Infrastructure Certificate and Certificate Revocation 1002 List (CRL) Profile", RFC 3280, April 2002. 1004 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1005 Addressing Architecture", RFC 3513, April 2003. 1007 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1008 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1010 [6] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses 1011 (CGA) Extension Field Format", draft-bagnulo-shim6-cga-ext-02 1012 (work in progress), October 2005. 1014 [7] Nordmark, E., "Level 3 multihoming shim protocol", 1015 draft-ietf-shim6-proto-01 (work in progress), October 2005. 1017 14.2. Informative References 1019 [8] Nordmark, E., "Threats relating to IPv6 multihoming solutions", 1020 RFC 4218, October 2005. 1022 [9] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1024 Nordmark, "Mobile IP version 6 Route Optimization Security 1025 Design Background", RFC 4225, December 2005. 1027 [10] Haddad, W., Madour, L., Arkko, J., and F. Dupont, "Applying 1028 Cryptographically Generated Addresses to Optimize MIPv6 (CGA- 1029 OMIPv6)", draft-haddad-mip6-cga-omipv6-02 (work in progress), 1030 June 2004. 1032 [11] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms 1033 in Cryptographically Generated Addresses (CGAs)", 1034 draft-bagnulo-multiple-hash-cga-00 (work in progress), 1035 June 2006. 1037 [12] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes 1038 in Internet Protocols", RFC 4270, November 2005. 1040 [13] Bellovin, S. and E. Rescorla, "Deploying a new hash algorithm", 1041 2005 September. 1043 [14] Nordmark, E., "Multi6 Application Referral Issues", 1044 draft-nordmark-multi6dt-refer-00 (work in progress), 1045 October 2004. 1047 [15] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient 1048 Security for IPv6 Multihoming.", ACM Computer Communications 1049 Review Vol 35 n 2, April 2005. 1051 Author's Address 1053 Marcelo Bagnulo 1054 Universidad Carlos III de Madrid 1055 Av. Universidad 30 1056 Leganes, Madrid 28911 1057 SPAIN 1059 Phone: 34 91 6249500 1060 Email: marcelo@it.uc3m.es 1061 URI: http://www.it.uc3m.es 1063 Full Copyright Statement 1065 Copyright (C) The Internet Society (2006). 1067 This document is subject to the rights, licenses and restrictions 1068 contained in BCP 78, and except as set forth therein, the authors 1069 retain all their rights. 1071 This document and the information contained herein are provided on an 1072 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1073 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1074 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1075 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1076 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1077 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Intellectual Property 1081 The IETF takes no position regarding the validity or scope of any 1082 Intellectual Property Rights or other rights that might be claimed to 1083 pertain to the implementation or use of the technology described in 1084 this document or the extent to which any license under such rights 1085 might or might not be available; nor does it represent that it has 1086 made any independent effort to identify any such rights. Information 1087 on the procedures with respect to rights in RFC documents can be 1088 found in BCP 78 and BCP 79. 1090 Copies of IPR disclosures made to the IETF Secretariat and any 1091 assurances of licenses to be made available, or the result of an 1092 attempt made to obtain a general license or permission for the use of 1093 such proprietary rights by implementers or users of this 1094 specification can be obtained from the IETF on-line IPR repository at 1095 http://www.ietf.org/ipr. 1097 The IETF invites any interested party to bring to its attention any 1098 copyrights, patents or patent applications, or other proprietary 1099 rights that may cover technology that may be required to implement 1100 this standard. Please address the information to the IETF at 1101 ietf-ipr@ietf.org. 1103 Acknowledgment 1105 Funding for the RFC Editor function is provided by the IETF 1106 Administrative Support Activity (IASA).