idnits 2.17.1 draft-arkko-mipshop-cga-cba-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1419. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (June 23, 2006) is 6516 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) == Unused Reference: '6' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1202, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1210, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3447 (ref. '2') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 3280 (ref. '5') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) -- No information found for draft-ietf-mip6-precfgKbm - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson Research NomadicLab 4 Expires: December 25, 2006 C. Vogt 5 Universitaet Karlsruhe (TH) 6 W. Haddad 7 Ericsson Research 8 June 23, 2006 10 Applying Cryptographically Generated Addresses and Credit-Based 11 Authorization to Mobile IPv6 12 draft-arkko-mipshop-cga-cba-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 25, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document proposes an enhanced security mechanism for Mobile IPv6 46 route optimization, providing lower handoff delays, increased 47 security, and reduced signaling overhead. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Handoff Latency . . . . . . . . . . . . . . . . . . . . . 4 54 2.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3 Signaling Overhead . . . . . . . . . . . . . . . . . . . . 6 56 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 9 58 4.1 Sending Binding Update messages . . . . . . . . . . . . . 9 59 4.2 Receiving Binding Update messages . . . . . . . . . . . . 12 60 4.3 Sending Binding Acknowledgment messages . . . . . . . . . 14 61 4.4 Receiving Binding Acknowledgment messages . . . . . . . . 15 62 4.5 Sending CGA Parameters . . . . . . . . . . . . . . . . . . 15 63 4.6 Receiving CGA Parameters . . . . . . . . . . . . . . . . . 15 64 4.7 Renewing a Permanent Home Keygen Token . . . . . . . . . . 15 65 4.8 Handling Payload Packets . . . . . . . . . . . . . . . . . 16 66 4.9 Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 17 67 4.10 Cryptographic Calculations . . . . . . . . . . . . . . . 18 68 4.11 Simultaneous Movements . . . . . . . . . . . . . . . . . 18 69 5. Option Formats and Status Codes . . . . . . . . . . . . . . 19 70 5.1 CGA Parameters Option . . . . . . . . . . . . . . . . . . 19 71 5.2 Permanent Home Keygen Token Option . . . . . . . . . . . . 20 72 5.3 Signature Option . . . . . . . . . . . . . . . . . . . . . 20 73 5.4 Care-of Test Init Option . . . . . . . . . . . . . . . . . 21 74 5.5 Care-of Test Option . . . . . . . . . . . . . . . . . . . 22 75 5.6 Status Codes . . . . . . . . . . . . . . . . . . . . . . . 22 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 23 77 7. Performance Considerations . . . . . . . . . . . . . . . . . 24 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 9.1 Normative References . . . . . . . . . . . . . . . . . . . 25 81 9.2 Informative References . . . . . . . . . . . . . . . . . . 26 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 83 A. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 28 84 B. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . 28 85 C. Overview of Credit-Based Authorization . . . . . . . . . . . 30 86 Intellectual Property and Copyright Statements . . . . . . . 32 88 1. Introduction 90 Mobile IPv6 [1] includes a mode for route optimization that allows 91 nodes to communicate with reduced latency via a direct routing path. 92 Route optimization is protected through a "return routability 93 procedure", which serves essentially two purposes: 95 o A correspondent node can (weakly) authenticate a mobile node based 96 on a verification of the mobile node's reachability at its home 97 address. 99 o A correspondent node can verify that the mobile node is reachable 100 at the claimed care-of address. 102 While authentication prevents impersonation threats, the reachability 103 verification for the care-of address protects against "redirection- 104 based flooding attacks" [8]. 106 Standard route optimization is limited by the capabilities of the 107 return routability procedure. For one thing, the procedure does not 108 protect against an impersonator on the path between the mobile node's 109 home agent and the correspondent node. This vulnerability may 110 oftentimes be acceptable, given that it already exists in the non- 111 mobile Internet of today. But scenarios with higher security needs 112 are also conceivable. Second, the return routability procedure 113 consumes a significant of the overall handoff delay. Since route 114 optimization was orignally developed with an intent to improve 115 support for interactive real-time applications, it is exactly those 116 applications that suffer from prolonged handoff delays. 118 This document amends the Mobile IPv6 base specification by two 119 optional, interrelated, yet orthogonal optimizations to the return 120 routability procedure. The first optimization enables unidirectional 121 or mutual authentication based on a cryptographically generated home 122 address [9]. This replaces the weaker authentication through pure 123 reachability verification at a home address. The second optimization 124 allows a correspondent node to securely verify a mobile node's 125 reachability at a new care-of address while it already sends data 126 packets to that care-of address [10]. The two optimizations can be 127 applied separately or, preferably, in conjunction. 129 2. Objectives 131 The design of Mobile IPv6 route optimization is in may ways 132 conservative, leaving room to optimize handoff delay, security, and 133 signaling overhead. The protocol defined in this document tackles 134 these issues and thus constitutes a more progressive variant of the 135 base mobility protocol. 137 In spite of any improvements in the mobility protocol, it is 138 important to take into account that other mobility-related activities 139 in the protocol stack may have their own impact, in particular on 140 handoff delay. E.g., attachment procedures, access control, and 141 authentication at the link layer contribute their own delay. So do 142 IPv6 tasks such as router discovery, neighbor discovery, movement 143 detection, and address configuration. These other delays are in many 144 cases significantly larger than the handoff delay of Mobile IPv6 145 route optimization. The protocol defined in this document 146 concentrates on making the mobility signaling as efficient as 147 possible, ignoring mobility-related functions elsewhere in the 148 protocol stack. The improvements that the protocol facilitates hence 149 ought to be seen in view of the entire protocol stack. 151 2.1 Handoff Latency 153 The typical handoff delay in Mobile IPv6 route optimization is 1 154 round-trip time between the mobile node and the home agent for the 155 home registration, 1 round-trip time between the mobile node and the 156 home agent plus 1 round-trip time between the home agent and the 157 correspondent node for the return routability procedure, and 1 one- 158 way time from the mobile node to the correspondent node for the 159 propagation of the Binding Update message. (The assumption here is 160 that the latency of the return routability procedure is dominated by 161 the home-address test.) The first packet sent to the new care-of 162 address requires 1 additional one-way time to propagate from the 163 correspondent node to the mobile node. The mobile node can resume 164 transmissions right after it has dispatched the Binding Update 165 message. But if it requests a Binding Acknowledgment message from 166 the correspondent node, communications are usually delayed until this 167 is received. 169 Handoff delays in Mobile IPv6 route optimization are additive to 170 other delays at IP layer or link layer. They can cause perceptible 171 quality degradations for interactive and real-time applications. TCP 172 bulk-data transfers are likewise affected since long handoff 173 latencies may lead to successive retransmission timeouts and degraded 174 throughput [11]. This protocol eliminates the additional handoff 175 delay induced by Mobile IPv6 route optimization for packets that a 176 mobile node sends, and it reduces the delay to 1 round-trip time 177 between the mobile node and the correspondent node for packets that 178 the mobile node receives. 180 2.2 Security 182 Given that mobile and correspondent nodes with support for Mobile 183 IPv6 route optimization form a true subset of all Internet nodes, the 184 security design of the mobility protocol cannot make the Internet any 185 safer than it is without the mobility protocol. The return 186 routability procedure was therefore designed with the objective to 187 provide a level of security which compares to that of today's non- 188 mobile Internet [8]. As such, it protects against impersonation and 189 denial of service that an insecure mobility protocol may be 190 vulnerable to. In particular, the return routability procedure 191 satisfies the following key requirements for mobility protocols: 193 o An attacker should not be able to redirect a third node's 194 communication flow to itself or to another IP address, at least 195 not beyond what is already possible in plain IPv6. This 196 requirement applies both to ongoing and future communication 197 flows. 199 o An attacker should not be able to redirect its own communication 200 flows to a third party, flooding the victim with unrequested 201 packets. Such redirection-based flooding attack would provide 202 substantial amplification that is today only possible through a 203 network of compromised nodes [12]. E.g., an attacker could 204 accomplish the initial TCP handshake for a voluminous file 205 download through its own address (or home address, for that 206 matter), and then redirect the flow to the address of its victim. 207 The attacker could spoof acknowledgments on behalf of the victim 208 based on the sequence numbers it learned from the initial 209 handshake, but those would be small compared to the full-sized 210 segments that the correspondent node generates. 212 o Attackers should not be able to cause denial-of-service through 213 potentially expensive computations involved in the mobility 214 protocol. 216 Applications that require a higher security level than the return 217 routability procedure can provide are generally advised to use end- 218 to-end protection such as IPsec or TLS. But even then are they 219 vulnerable to denial of service. Furthermore, these mechanisms 220 either require end nodes to be preconfigured with credentials for 221 mutual authentication, or they depend on a public-key infrastructure. 222 Either approache impedes [13] wide deployment of Mobile IPv6 route 223 optimization. The protocol defined in this document permits end 224 nodes to authenticate each other by means of a cryptographic property 225 of their home addresses. It neither depends on preconfiguration nor 226 on a public-key infrastructure, and yet it conforms to the key 227 requirements listed above. 229 2.3 Signaling Overhead 231 A complete correspondent registration involves 6 message 232 transmissions at the mobile node, totaling about 376 bytes (cf. 233 [14]). This signaling overhead may be acceptable if movements are 234 infrequent. E.g., a mobile node that moves once every 30 minutes 235 generates an average of 1.7 bits/second of signaling traffic. Higher 236 mobility causes more serious overhead, however. A cell size of 100 237 meters and a speed of 120 km/h yields 1 movement every 3 seconds and 238 about 1,000 bits/second of signaling traffic. This compares to a 239 highly compressed voice stream with a typical data rate of 10,000 to 240 30,000 bits/second. The protocol defined in this document introduces 241 a new message exchange between mobile and correspondent nodes in 242 order to accomplish the desired improvements in handoff delay. The 243 implied new signaling overhead is compensated for by verifying 244 reachability of the care-of address in-band, sparing a separate 245 message exchange. 247 Standard Mobile IPv6 requires mobile nodes to renew a binding at a 248 correspondent node at least every 7 minutes. The signaling overhead 249 amounts to 7.16 bits per second if the mobile node communicates with 250 a stationary node [14]. It doubles if both peers are mobile. This 251 overhead may be negligible when the nodes communicate, but it can be 252 an issue for mobile nodes that are inactive and stay at the same 253 location for a while. These nodes typically prefer to go to standby 254 mode to conserve battery power. Also, the periodic refreshments 255 consume a fraction of the wireless bandwidth that one could use more 256 efficiently. The protocol defined in this document allows 257 correspondent nodes to specify a binding lifetime much larger than 7 258 minutes. It thereby reduces the signaling overhead generated by 259 mobile nodes that do not change their care-of address for a while. 261 3. Protocol Design 263 The protocol defined in this document applies a set of techniques in 264 order to meet the objectives discussed in Section 2. These are 265 summarized in the following: 267 Cryptographically generated home addresses 269 A Mobile IPv6 binding is conceptually a packet redirection from a 270 home address to a care-of address. The home address is the source 271 of the redirection, whereas the care-of address is the 272 destination. The packets to be redirected can hence be identified 273 based on the home address. This motivates a strong, cryptographic 274 ownership proof for the home address. The protocol defined in 275 this document features this through the application of 276 cryptographically generated home addresses [15][16]. In general, 277 a cryptographically generated address [9] provides a strong, 278 cryptographic binding between the interface identifier of the 279 address and the address owner's public key. This enables other 280 nodes to securely authenticate the owner as such, modulo the 281 correctness of the address prefix. Cryptographically generated 282 home addresses can supersede home address tests with the exeption 283 of an initial test for validating the home address prefix. This 284 facilitates lower handoff delays as well as longer binding 285 lifetimes and, consequently, reduced signaling overhead for nodes 286 which temporarily do not move. 288 Non-cryptographic care-of addresses 290 In contrast to a home address, a care-of address does not have 291 identifying functionality. There is hence little benefit in a 292 cryptographic ownership proof of a care-of address. Given that 293 the care-of address is the destination of a packet redirection, it 294 is rather the mobile node's reachability at the care-of address 295 which matters. The protocol defined in this document uses care-of 296 address tests for this purpose, but allows correspondent nodes to 297 send packets to a new care-of address already before the mobile 298 node has been found to be reachable at the address. 300 Semi-permanent security associations 302 Cryptographically generated addresses involve public-key 303 cryptography and are computationally inefficient to validate. 304 Further, the technique requires a significant amount of 305 supplementary data to be piggybacked onto protected messages. The 306 protocol defined in this document therefore leverages the 307 cryptographic property of home addresses to securely exchange a 308 secret shared key between a mobile node and a correspondent node 309 [17]. This key is used to authenticate subsequent signaling 310 messages efficiently. 312 Initial home address tests 314 An initial home address test is necessary in order to prevent 315 redirection-based flooding attacks against an alleged home 316 network. Specifically, in the absence of a home address test, a 317 malicious node can cryptographically generate a home address with 318 the prefix of a targeted victim network, and register a binding 319 between this spoofed home address and its own IP address at a 320 correspondent node. The attacker proceeds to request the 321 correspondent node, which may be a public server, to send a stream 322 of packets to its current location. The attacker then de- 323 registers the binding, or lets it expire, with the consequence of 324 having the correspondent node redirect the packet stream "back" to 325 the victim network. The result is a flooding attack against the 326 victim network. To avoid such misuse, the initial home address 327 test is executed at the same time as the semi-permanent security 328 association is being established [17]. The test does not need to 329 be repeated upon subsequent movements, however. 331 Concurrent care-of address tests 333 The protocol defined in this document allows a correspondent node 334 to send packets to a new care-of address already before a proof of 335 reachability at that address has been received from the mobile 336 node. Specifically, when the mobile node moves to a different 337 link, it first registers its new care-of address without providing 338 a proof of reachability. The correspondent node registers the 339 unverified care-of address on a tentative basis and sends a token 340 to the mobile node based on which the latter can follow up with a 341 proof of reachability. This completes the binding update. 343 Credit-Based Authorization 345 Concurrent care-of address tests without additional protection 346 would enable an attacker to temporarily redirect its own 347 communication flows to a spoofed, unverified care-of address. 348 This introduces a vulnerability to redirection-based flooding 349 attacks and is hence in conflict with the security requirements 350 defined in Section 2.2. Recall that the appeal of redirection- 351 based flooding attacks is the potential for significant 352 amplification. Credit-Based Authorization [10] guarantees that 353 malicious packet redirection cannot generate amplification. This 354 defeats the purpose of redirection-based flooding: Any attacker 355 could more effectively flood its victim by sending bogus packets 356 directly. 358 Reduced reachability verification 360 A cryptographically generated home address does not tell whether 361 its prefix is correct, so there is still need for a home address 362 test. Reachability verification is also required for care-of 363 addresses since those are not cryptographically protected. The 364 protocol defined in this document executes a home address test 365 during the initial key establishment procedure and a care-of 366 address test upon each handoff. However, due to the strong, 367 cryptographic address ownership authentication of the home 368 address, binding lifetimes can be much longer than in standard 369 Mobile IPv6 route optimization, and reachability tests may occur 370 on a less frequent basis. 372 4. Protocol Operation 374 The protocol defined in this document features a variety of possible 375 message exchanges. These are described below, packaged by the type 376 of message processing operation. 378 4.1 Sending Binding Update messages 380 A mobile node may initiate a correspondent registration for any of 381 the following reasons: 383 o To establish a new binding at a correspondent node so that further 384 packets can be route-optimized and do no longer need to be routed 385 through the mobile node's home agent. 387 o To update an existing binding at the correspondent node while 388 moving from one point of IP attachment to another. 390 o To follow up an early Binding Update message with a complete 391 Binding Update message after receiving a Binding Acknowledgment 392 message with a Care-of Test option. 394 o To refresh an existing binding at the correspondent node without 395 changing its point of IP attachment. 397 o To request the correspondent node to renew an existing permanent 398 home keygen token shared between the mobile node and the 399 correspondent node (cf. Section 4.7). 401 In any of these cases, the mobile node sends a Binding Update message 402 to the correspondent node. The Binding Update message MUST be 403 authenticated either through the CGA property of the mobile node's 404 home address, or through a proof of reachability at the home address. 405 The appropriate authentication method is selected as follows: 407 o If the mobile node's home address is a CGA, and the mobile node 408 has a permanent home keygen token in its Binding Update List entry 409 for the correspondent node, the mobile node MUST authenticate the 410 Binding Update message with the CGA property of its home address. 412 o If the mobile node's home address is a CGA, but the mobile node 413 does not have a permanent home keygen token in its Binding Update 414 List entry for the correspondent node, the mobile node MUST 415 authenticate the Binding Update message with a proof of 416 reachability at its home address. 418 o If the mobile node's home address is not a CGA, the mobile node 419 MUST authenticate the Binding Update message with a proof of 420 reachability at its home address. 422 The mobile node SHOULD request the correspondent node to accept its 423 CGA parameters for future CGA-based authentication if its home addess 424 is a CGA, but it does not yet have a permanent home keygen token from 425 the correspondent node. The mobile node then includes its CGA 426 parameters in the Binding Update message by adding one or more CGA 427 Parameters options (cf. Section 5.1) followed by a Signature option 428 (cf. Section 5.3). Once a permanent home keygen token has been 429 obtained from the correspondent node, the mobile node MUST 430 authenticate all subsequent Binding Update messages with the CGA 431 property of its home address until either the binding lifetime 432 expires, or the mobile node explicitly de-registers from the 433 correspondent node. The mobile node MAY choose to ignore the CGA 434 property of its home address and continue authenticating Binding 435 Update messages through a proof of reachability at the home address, 436 but this behavior is NOT RECOMMENDED. 438 The mobile node also includes its CGA parameters in the Binding 439 Update message if it intends to renew an existing permanent home 440 keygen token shared with the correspondent node (cf. Section 4.7). 441 This is accomplished, as before, by adding to the message one or more 442 CGA Parameters options and a Signature option. 444 The authenticator for the Binding Update message is calculated based 445 on a permanent or temporary home keygen token. Which type of home 446 keygen token the mobile node uses in calculating the authenticator 447 depends on the authentication method: 449 o If the Binding Update message is to be authenticated through the 450 CGA property of the mobile node's home address, the mobile node 451 MUST use the permanent home keygen token that is has in its 452 Binding Update List entry for the correspondent node. 454 o If the Binding Update message is to be authenticated through a 455 proof of reachability at the home address, the mobile node MUST 456 use a temporary home keygen token from the correspondent node. 457 The mobile node may already have a valid temporary home keygen 458 token in its Binding Update List entry for the correspondent node, 459 or it may retrieve one through the exchange of a Home Test Init 460 message and a Home Test message as defined in [1]. 462 The authenticator for the Binding Update message is further 463 calculated based on a care-of keygen token. The care-of keygen token 464 to be used is selected as follows: 466 o If the mobile node has a valid care-of keygen token in its Binding 467 Update List entry for the correspondent node, the mobile node MUST 468 use this in calculating the authenticator for the Binding Update 469 message. The Binding Update message is in this case "complete". 471 o If the mobile node does not have a valid care-of keygen token in 472 its Binding Update List entry for the correspondent node, the 473 mobile node SHOULD define the care-of keygen token to be zero and 474 use this in calculating the authenticator for the Binding Update 475 message. The Binding Update message is in this case "early". 477 o If the mobile node does not have a valid care-of keygen token in 478 its Binding Update List entry for the correspondent node, the 479 mobile node MAY choose to retrieve a care-of keygen token through 480 the exchange of a Care-of Test Init message and a Care-of Test 481 message, as defined in [1], without sending an early Binding 482 Update message. In this case, the mobile node waits for receipt 483 of the Care-of Test message and uses the care-of keygen token 484 contained therein in calculating the authenticator for a complete 485 Binding Update message. This approach is NOT RECOMMENDED, 486 however. 488 If the Binding Update message is early, the mobile node MUST add a 489 Care-of Test Init option to the message, requesting the correspondent 490 node to return a new care-of keygen token. Once a responding Binding 491 Acknowledgment message with a Care-of Test option is received, the 492 mobile node MUST use the care-of keygen token contained therein in 493 calculating the authenticator for a complete Binding Update message 494 and send this message to the correspondent node. 496 The mobile node includes the nonce indices associated with the 497 selected home and care-of keygen tokens in the Binding Update message 498 using a Nonce Indices option [1]. These nonce indices are determined 499 as follows: 501 o The home nonce index is defined to be zero if the Binding Update 502 message is to be authenticated through the CGA property of the 503 mobile node's home address. (In this case, the mobile node uses a 504 permanent home keygen token to calculate the authenticator for the 505 Binding Update message.) 507 o If the Binding Update message is to be authenticated through a 508 proof of reachability at the home address, the mobile node uses a 509 temporary home keygen token to calculate the authenticator for the 510 Binding Update message, and the associated home nonce index is 511 taken from the Home Test message with which the home keygen token 512 was obtained. 514 o The care-of nonce index is zero if the Binding Update message is 515 early. 517 o If the Binding Update message is complete, the associated nonce 518 index is taken from the Care-of Test message with which the 519 care-of keygen token was obtained. 521 The Nonce Indices options follows the CGA Parameters and Signature 522 options, if any. 524 The mobile node finally calculates an authenticator for the Binding 525 Update message based on the selected home and care-of keygen tokens, 526 following the rules described in [1]. The authenticator is placed 527 into a Binding Authorization Data option [1], which the mobile node 528 adds to the Binding Update message as the last option. 530 4.2 Receiving Binding Update messages 532 When the correspondent node receives a Binding Update message, it 533 must first verify whether the sending mobile node is the legitimate 534 owner of the home address specified in the message. This is 535 accomplished either through the CGA property of the home address, or 536 through verification of the mobile node's reachability at the home 537 address. The correspondent node selects the authentication method 538 based on the home nonce index given in the Nonce Indices option of 539 the Binding Update message: 541 o If the home nonce index is zero, the correspondent node MUST 542 authenticate the Binding Update message through the CGA property 543 of the home address. 545 o If the home nonce index is set to a non-null value, the 546 correspondent node MUST authenticate the Binding Update message 547 through verification of the mobile node's reachability at the home 548 address. 550 The authenticator for the Binding Update message is calculated based 551 on a permanent or temporary home keygen token. Which type of home 552 keygen token the correspondent node uses in validating the 553 authenticator, and how to retrieve or recompute the home keygen 554 token, depends on the authentication method: 556 o If the Binding Update message is to be authenticated through the 557 CGA property of the mobile node's home address, the correspondent 558 node should have a permanent home keygen token in its Binding 559 Cache entry for the mobile node. If so, the correspondent node 560 MUST use this permanent home keygen token in validating the 561 authenticator of the Binding Update message. If the correspondent 562 node does not have a permanent home keygen token for the mobile 563 node in its Binding Cache, the correspondent node MUST reject the 564 Binding Update message. 566 o If the Binding Update message is to be authenticated through 567 verification of the mobile node's reachability at the home 568 address, the correspondent node MUST verify that it does not have 569 a permanent home keygen token in its Binding Cache entry for the 570 mobile node. Provided that no permanent home keygen token is 571 found, the correspondent node MUST recompute the temporary home 572 keygen token defined by the (non-null) home nonce index in the 573 Nonce Indices option of the Binding Update message, and it MUST 574 use this recomputed token in validating the authenticator of the 575 message. In case the correspondent node does have a permanent 576 home keygen token in its Binding Cache entry for the mobile node, 577 it MUST reject the Binding Update message. This is necessary to 578 ensure that an attacker cannot bid down the authentication method 579 to hijack a mobile node's legitimate binding. 581 The authenticator for the Binding Update message is further 582 calculated based on a care-of keygen token. Which care-of keygen 583 token the correspondent node uses in validating the authenticator 584 depends on whether the Binding Update message is complete or early: 586 o If the care-of nonce index in the Nonce Indices option of the 587 Binding Update message is set to a non-null value, the Binding 588 Update message is complete. In this case, the correspondent node 589 MUST recompute the care-of keygen token defined by the index, and 590 it MUST use this recomputed token in validating the authenticator 591 of the message. 593 o If the care-of nonce index is zero, the Binding Update message is 594 early. In this case, the correspondent node uses a value of zero 595 in validating the authenticator of the Binding Update message. 597 The correspondent node finally validates the authenticator in the 598 Binding Update message based on the selected home and care-of keygen 599 tokens, following the rules described in [1]. 601 If the validation fails, the correspondent node MUST discard the 602 Binding Update message. The correspondent node may have to send a 603 Binding Acknowledgment message with a negative status code as 604 described in [1]. 606 Provided that the validation of the authenticator in the Binding 607 Update message succeeds, the correspondent node registers the mobile 608 node's new care-of address, either updating an existing Binding Cache 609 entry, if one exists, or creating a new Binding Cache entry. The 610 state of the new care-of address depends on whether the Binding 611 Update message is complete or early: 613 o If the Binding Update message is complete, the new care-of address 614 is set to VERIFIED state. The correspondent node may then 615 immediately send packets to the new care-of address without 616 restrictions. 618 o If the Binding Update message is early, the new care-of address is 619 set to UNVERIFIED state. The correspondent node MUST then follow 620 the rules defined in section 5.4 for sending packets to this 621 care-of address until the care-of address is set in VERIFIED 622 state. 624 If the Binding Update message contains a CGA Parameters option, the 625 mobile node is requesting the correspondent node to accept the 626 included CGA parameters either for establishing a new, or for 627 renewing an existing permanent home keygen token shared between the 628 mobile node and the correspondent node. The correspondent node MUST 629 in this case check if the CGA Parameters option is directly followed 630 by a Signature option and, if so, validate the signature included in 631 the latter. This is done as described in Section 4.6. 633 If the CGA Parameters option is not directly followed by a Signature 634 option, or the validation of the signature included in the Signature 635 option fails, the correspondent node MUST discard the Binding Update 636 message. 638 Provided that the signature included in the Signature option is 639 correct, the correspondent node generates a permanent home keygen 640 token to be shared with the mobile node and stores it in its Binding 641 Cache entry for the mobile node. The permanent home keygen token is 642 sent to the mobile node within a Binding Acknowledgment message as 643 described in Section 4.3. 645 4.3 Sending Binding Acknowledgment messages 647 Upon receipt of a valid Binding Update message, the correspondent 648 node returns to the mobile node a Binding Acknowledgment message in 649 any of the following cases: 651 o The Acknowledge flag in the Binding Update message is set. 653 o The Binding Update message is early and includes a Care-of Test 654 Init option. 656 o The Binding Update message contains a CGA Parameters option 657 followed by a Signature option, and the signature included in the 658 latter was determined to be correct. 660 If the Binding Update message is early, the Binding Acknowledgment 661 message MUST contain a Care-of Test option with a pseudo-random value 662 in the Care-of Keygen Token field. 664 If the Binding Update message contains a CGA Parameters option 665 followed by a Signature option, and the signature included in the 666 latter was determined to be correct, the Binding Acknowledgment 667 message MUST include a Permanent Home Keygen Token option with the 668 permanent home keygen token stored in the correspondent node's 669 Binding Cache entry for the mobile node. 671 4.4 Receiving Binding Acknowledgment messages 673 A mobile node verifies a received Binding Acknowledgment message 674 according to the rules specified in [1]. 676 If the Binding Acknowledgment message contains a Care-of Test option, 677 the mobile node extracts the care-of keygen token included in this 678 option, stores this token in the appropriate entry of its Binding 679 Update List, and sends the correspondent node a complete Binding 680 Update message as defined in section Section 4.1. 682 If the Binding Acknowledgment message contains a Permanent Home 683 Keygen Token option, the mobile node extracts the permanent home 684 keygen token included in this option and stores it in the appropriate 685 entry of its Binding Update List. Future Binding Update messages 686 will then be authenticated based on the CGA property of the mobile 687 node's home address. 689 4.5 Sending CGA Parameters 691 TBD. 693 4.6 Receiving CGA Parameters 695 TBD. 697 4.7 Renewing a Permanent Home Keygen Token 699 A mobile node MAY request a correspondent node to renew an existing 700 permanent home kegen token at any time, but it MUST do so in the 701 imminent event of a sequence number rollover, or when the lifetime of 702 the binding at the correspondent node is about to expire. 704 4.8 Handling Payload Packets 706 A correspondent node maintains a "credit counter" for each mobile 707 nodes with which it uses the protocol specified in this document. 708 Whenever a packet arrives from one of these mobile nodes, the 709 correspondent node SHOULD increase that mobile node's credit counter 710 by the size of the received packet. When the correspondent node has 711 a packet to be sent to the mobile node, if the mobile node's care-of 712 address is labeled UNVERIFIED, the correspondent node checks whether 713 it can send the packet to the UNVERIFIED care-of address: The packet 714 SHOULD be sent if the value of the credit counter is higher than the 715 size of the outbound packet. If the credit counter is too low, the 716 packet MUST be discarded or buffered until address verification 717 succeeds. When a packet is sent to a mobile node at an UNVERIFIED 718 care-of address, the mobile node's credit counter MUST be reduced by 719 the size of the packet. The mobile node's credit counter is not 720 affected by packets that the host sends to a VERIFIED care-of address 721 of that mobile node. 723 Figure 1 depicts the actions taken by the correspondent node when a 724 packet is received. Figure 2 shows the decision chain in the event a 725 packet is sent. 727 Inbound 728 packet 729 | 730 | +-----------------+ +-----------------+ 731 | | Increase the | | Deliver the | 732 +-----> | credit counter |---------------> | packet to the | 733 | by packet size | | application | 734 +-----------------+ +-----------------+ 736 Figure 1: Receiving Packets with Credit-Based Authorization 738 Outbound 739 packet 740 | _________________ 741 | / \ +-----------------+ 742 | / Is the \ No | Send the packet | 743 +-----> | care-of address |-------------> | to the care-of | 744 \ UNVERIFIED? / | address | 745 \_________________/ +-----------------+ 746 | 747 | Yes 748 | 749 v 750 _________________ 751 / \ +-----------------+ 752 / Credit counter \ No | | 753 | >= |-------------> | Drop the packet | 754 \ packet size? / | | 755 \_________________/ +-----------------+ 756 | 757 | Yes 758 | 759 v 760 +-----------------+ +-----------------+ 761 | Reduce the | | Send the packet | 762 | credit counter |---------------> | to the care-of | 763 | by packet size | | address | 764 +-----------------+ +-----------------+ 766 Figure 2: Sending Packets with Credit-Based Authorization 768 4.9 Credit Aging 770 A correspondent node ensures that the credit counters it maintains 771 for its mobile nodes gradually decrease over time. Such "credit 772 aging" prevents a malicious node from building up credit at a very 773 slow speed and using this, all at once, for a severe burst of 774 redirected packets. 776 Credit aging SHOULD be implemented by multiplying credit counters 777 with a factor, CreditAgingFactor, less than one in fixed time 778 intervals of CreditAgingInterval length. Choosing appropriate values 779 for CreditAgingFactor and CreditAgingInterval is important to ensure 780 that the correspondent node can send packets to an address in state 781 UNVERIFIED even when the mobile node sends at a lower rate than the 782 correspondent node itself. When CreditAgingFactor or 783 CreditAgingInterval are too small, the mobile node's credit counter 784 might be too low to continue sending packets until address 785 verification concludes. 787 The following values are used for the credit-aging parameters defined 788 in this document: 790 CreditAgingFactor 7/8 791 CreditAgingInterval 5 seconds 793 Note: These parameter values work well when the correspondent node 794 transfers a file to the mobile node via a TCP connection and the end- 795 to-end round-trip time does not exeed 500 milliseconds. 797 4.10 Cryptographic Calculations 799 The Signature option is calculated with the mobile node's private key 800 over the following sequence of octets: 802 Mobility Data = care-of address | correspondent | MH Data 804 Where | denotes concatenation and "correspondent" is the 805 correspondent node's IPv6 address. Note that in case the 806 correspondent node is mobile, correspondent refers to the 807 correspondent node's home address. 809 MH Data is the content of the mobility message including the MH 810 header. The Authenticator within the Binding Authorization Data 811 option is zeroed for purposes of calculating the signature. 813 The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [2] 814 signature algorithm with the SHA-1 hash algorithm. 816 When the SKey option is used, the correspondent node MUST encrypt the 817 Kbm with the MN's public key using the RSAES-PKCS1-v1_5 format [2]. 819 4.11 Simultaneous Movements 821 As specified in RFC 3775 [1], Mobility Header messages are generally 822 sent via the mobile node's home agent and to the peer's home address, 823 if it is also mobile. This makes it possible for two mobile nodes to 824 communicate even if they are moving simultaneously. 826 5. Option Formats and Status Codes 828 5.1 CGA Parameters Option 830 Options of this type are used to carry the mobile node's public key 831 and the CGA parameters needed by the correspondent node to check the 832 validity of the mobile node's CGA. RFC 3775 [1] limits Mobility 833 Header options to a maximum length of 255 bytes, excluding the Option 834 Type and Option Length fields. For this reason, multiple options of 835 this type are used to carry the entire CGA information, which is 836 likely to exceed the limit specified in RFC 3775. 838 The format of the option is the following: 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Option Type | Option Length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 + + 847 . CGA Parameters . 848 . . 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Option Type 854 . 856 Option Length 858 Length of the option. 860 Option Data 862 This field contains up to 255 bytes of the string holding the 863 mobile node's CGA public key and other CGA parameters in the 864 format defined in [18]. The concatenation of all options of this 865 type in the order they appear in the Binding Update message MUST 866 result in the string defined in [18]. All options of this type 867 carried in the Binding Update message except the last one MUST 868 contain exactly 255 bytes in the Option Data field, and the Option 869 Length field MUST be set to 255 accordingly. All options of this 870 type MUST appear one after another, i.e., an option of a different 871 type MUST NOT be placed in between two options of this type. 873 5.2 Permanent Home Keygen Token Option 875 As it has been mentioned above, the correspondent node MUST send a 876 new Kbm each time it receives a Binding Update message containing the 877 CGA Parameter option. For this purpose, this proposal uses a new 878 option called SKey option, which MUST be inserted in the Binding 879 Acknowledgment message. 881 The format of the option is as follows: 883 0 1 2 3 884 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 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Option Type | Length = 16 | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | | 889 + + 890 | | 891 + Semi-Permanent Key for Binding Management (Kbmperm) + 892 | | 893 + + 894 | | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 Option Type 899 . 901 Option Length 903 Length of the option. 905 Option Data 907 This field contains the Kbmperm value. Note that the content of 908 this field MUST be encrypted with the mobile node's public key as 909 defined in Section 4.10. The length of Kbmperm value is 20 octets 910 (before encryption or padding possibly involved [2]). 912 5.3 Signature Option 914 When the mobile node signs the Binding Update message with its CGA 915 private key, it MUST insert the signature in the SIG option. Such 916 scenario occurs when the mobile node sends its first Binding Update 917 message to the correspondent node and if the mobile node reboots 918 during an ongoing session. 920 The option format is as follows: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Option Type | Option Length | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | | 928 + + 929 . Signature . 930 . . 931 | | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Option Type 936 . 938 Option Length 940 Length of the option. 942 Option Data 944 This field contains the signature of the MH message it is 945 contained within. 947 5.4 Care-of Test Init Option 949 A mobile node that wishes to employ the care-of address test 950 optimization MAY employ this option in Binding Update message sent to 951 a correspondent node in which it has previously established a Binding 952 Cache entry. When received by such a correspondent node, it SHOULD 953 return a Care-of Keygen Token option in the Binding Acknowledgement 954 message. 956 The option format is as follows: 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Option Type | Option Length | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 Option Type 966 . 968 Option Length 970 Length of the option = 0. 972 5.5 Care-of Test Option 974 This option is returned by a correspondent node upon seeing a Care-of 975 Test Init option in a Binding Update. 977 The option format is as follows: 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Option Type | Option Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 + Care-of Keygen Token + 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Option Type 991 . 993 Option Length 995 Length of the option = 8. 997 Care-of Keygen Token 999 A care-of keygen token, calculated as in RFC 3775. 1001 5.6 Status Codes 1003 The following new Status codes are allocated: 1005 Lost Kbmperm State () 1007 This code is returned when the correspondent node does not have a 1008 Binding Cache Entry, Kbmperm, or has an invalid Binding 1009 Authorization Data option. The code MUST only be used in to 1010 respond to Binding Updates that contain one of the mobility 1011 options defined in this document. 1013 6. Security Considerations 1015 This draft describes a method to exploit the CGA features in order to 1016 authenticate route optimization signaling. In fact, the CGA replaces 1017 the authentication by providing a proof of ownership while the RR 1018 procedure replaces the authentication by a routing property. 1020 This proof of ownership ensures that only the mobile node will be 1021 able to change the routing of packets destined to it, modulo 1022 exhaustive attacks on the CGA mechanism itself. The feasibility of 1023 such attacks and the defenses against them have been discussed in 1024 [18]. 1026 Note that, as specified, the proof of ownership protection applies 1027 only to the correspondent node believing the statements made by the 1028 mobile node. There is no guarantee that the answers from the 1029 correspondent node truly come from that correspondent node and not 1030 from someone who was on the path to the correspondent node during the 1031 initial contact phase. This is because we do not require 1032 correspondent nodes to have CGAs, and as a result, they can not make 1033 any statements that are authenticated in the strong sense. We chose 1034 not to protect against this, because this attack is something that 1035 already exists in plain IPv6, as is explained in the following. Lets 1036 assume that the correspondent node does not care about the IP address 1037 of the peers contacting it and that it does not protect its payload 1038 packets cryptographically. Then, a man-in-the-middle can always use 1039 its own address when communicating to the correspondent node, and the 1040 correspondent node's address when communicating to the mobile node. 1041 Philosophically, one can also argue that since the problem we attempt 1042 to solve here is routing modifications for the mobile node's address, 1043 it is sufficient to ensure that these modifications are protected. 1045 It should be mentioned that while the CGA can provide a protection 1046 against unauthenticated Binding Update messages, it can expose the 1047 involved nodes to denial-of-service attacks since it is 1048 computationally expensive. The draft limits the use of CGA to only 1049 the first registration and if/when re-keying is needed. In addition, 1050 it is RECOMMENDED that nodes track the amount of resources spent to 1051 the CGA processing, and disable the processing of new requests when 1052 these resources exceed a predefined limit. 1054 The protocol specified in this document relies on standard 16-bit 1055 Mobile IPv6 sequence numbers and periodic rekeying to avoid replay 1056 attacks. Nodes rekey at least once every 24 hours. Nodes also rekey 1057 whenever a rollover in the available sequence-number space becomes 1058 imminent. Rekeying allows the nodes to reuse sequence numbers 1059 without exposing themselves to replay attacks. 1061 This protocol is secure against flooding attacks due to the use of 1062 care-of-address tests, Credit-Based Authorization, and the use of an 1063 initial home address test. 1065 7. Performance Considerations 1067 Performance of our protocol depends on whether we look at the initial 1068 or subsequent runs. The number of messages in the initial run is one 1069 less as in base Mobile IPv6, but the size of the messages is 1070 increased somewhat. 1072 On a mobile node that does not move that often, there is a 1073 significant signaling reduction, as the lifetimes can be set higher 1074 than in return routability. For instance, a mobile node that stays 1075 in the same address for a day will get a 99.52% signaling reduction. 1076 Such long lifetimes can be achieved immediately, as opposed to 1077 methods like [14] that grow them gradually. 1079 On a mobile node that moves fast, the per-movement signaling is 1080 reduced by 33%. 1082 Latency on the initial run is not affected, but on the subsequent 1083 movements there's a significant impact. This is because the home 1084 address test is eliminated. The exact effect depends on network 1085 topology, but if the home agent is far away and the correspondent 1086 node is on the same link, latency is almost completely eliminated. 1088 Additional latency and signaling improvements could be achieved 1089 through mechanisms that optimize the care-of address tests in some 1090 way. This is outside the scope of this document, however. 1092 8. IANA Considerations 1094 This document defines a new CGA Message Type name space for use as 1095 type tags in messages that may be signed using CGA signatures. The 1096 values in this name space are 128-bit unsigned integers. Values in 1097 this name space are allocated on a First Come First Served basis [3]. 1098 IANA assigns new 128-bit values directly without a review. 1100 CGA Message Type values for private use MAY be generated with a 1101 strong random-number generator without IANA allocation. 1103 This document defines a new 128-bit value under the CGA Message Type 1104 [18] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. 1106 This document defines a set of new mobility options, which must be 1107 assigned Option Type values within the mobility option numbering 1108 space of [1]. This document also allocates a new Status code value. 1110 9. References 1112 9.1 Normative References 1114 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1115 IPv6", RFC 3775, June 2004. 1117 [2] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 1118 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 1119 RFC 3447, February 2003. 1121 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1122 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1124 [4] International Telecommunications Union, "Information Technology 1125 - ASN.1 encoding rules: Specification of Basic Encoding Rules 1126 (BER), Canonical Encoding Rules (CER) and Distinguished Encoding 1127 Rules (DER)", ITU-T Recommendation X.690, July 2002. 1129 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1130 Public Key Infrastructure Certificate and Certificate Revocation 1131 List (CRL) Profile", RFC 3280, April 2002. 1133 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1134 Levels", BCP 14, RFC 2119, March 1997. 1136 [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1137 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1139 9.2 Informative References 1141 [8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1142 Nordmark, "Mobile IP Version 6 Route Optimization Security 1143 Design Background", IETF Request for Comments 4225, 1144 December 2005. 1146 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", 1147 IETF Request for Comments 3972, March 2005. 1149 [10] Vogt, C., "Credit-Based Authorization for Mobile IPv6 Early 1150 Binding Updates", 1151 draft-vogt-mipv6-credit-based-authorization-00 (work in 1152 progress), May 2004. 1154 [11] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in 1155 IPv6", Proceedings of the IEEE Wireless Communications and 1156 Networking Conference, IEEE, April 2006. 1158 [12] Mirkovic, J. and P. Reiher, "A Taxonomy of DDoS Attack and DDoS 1159 Defense Mechanisms", ACM SIGCOMM Computer Communication Review, 1160 Vol. 34, No. 2, ACM Press, April 2004. 1162 [13] Vogt, C. and J. Arkko, "Taxonomy and Analysis of Enhancements 1163 to Mobile IPv6 Route Optimization", IETF Internet Draft 1164 draft-irtf-mobopts-ro-enhancements-08.txt (work in progress), 1165 May 2006. 1167 [14] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 1168 Lifetime Extension", 1169 draft-arkko-mipv6-binding-lifetime-extension-00 (work in 1170 progress), May 2004. 1172 [15] O'Shea, G. and M. Roe, "Child-Proof Authentication for MIPv6 1173 (CAM)", ACM SIGCOMM Computer Communication Review, ACM Press, 1174 Vol. 31, No. 2, April 2001. 1176 [16] Nikander, P., "Denial-of-Service, Address Ownership, and Early 1177 Authentication in the IPv6 World", Revised papers from the 1178 International Workshop on Security Protocols, Springer-Verlag, 1179 April 2002. 1181 [17] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", 1182 draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. 1184 [18] Aura, T., "Cryptographically Generated Addresses (CGA)", 1185 draft-ietf-send-cga-06 (work in progress), April 2004. 1187 [19] Roe, M., "Authentication of Mobile IPv6 Binding Updates and 1188 Acknowledgments", draft-roe-mobileip-updateauth-02 (work in 1189 progress), March 2002. 1191 [20] Haddad, W., "Applying Cryptographically Generated Addresses to 1192 Optimize MIPv6 (CGA-OMIPv6)", draft-haddad-mip6-cga-omipv6-04 1193 (work in progress), May 2005. 1195 [21] Vogt, C., "Early Binding Updates for Mobile IPv6", 1196 draft-vogt-mip6-early-binding-updates-00 (work in progress), 1197 February 2004. 1199 [22] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1200 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1202 [23] Nikander, P., "Mobile IP version 6 Route Optimization Security 1203 Design Background", draft-ietf-mip6-ro-sec-03 (work in 1204 progress), May 2005. 1206 [24] Dupont, F. and J. Combes, "Using IPsec between Mobile and 1207 Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-01 (work 1208 in progress), June 2004. 1210 [25] Perkins, C., "Preconfigured Binding Management Keys for Mobile 1211 IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), 1212 April 2004. 1214 Authors' Addresses 1216 Jari Arkko 1217 Ericsson Research NomadicLab 1218 FI-02420 Jorvas 1219 Finland 1221 Email: jari.arkko@ericsson.com 1223 Christian Vogt 1224 Institute of Telematics 1225 Universitaet Karlsruhe (TH) 1226 P.O. Box 6980 1227 76128 Karlsruhe 1228 Germany 1230 Email: chvogt@tm.uka.de 1231 Wassim Haddad 1232 Ericsson Research 1233 8400, Decarie Blvd 1234 Town of Mount Royal 1235 Quebec H4P 2N2, Canada 1237 Email: wassim.haddad@ericsson.com 1239 Appendix A. Acknowledgment 1241 The authors would like to thank Pekka Nikander, Tuomas Aura, Greg 1242 O'Shea, Mike Roe, Gabriel Montenegro, Vesa Torvinen for 1243 interesting discussions around cryptographically generated addresses. 1245 The authors would also like to thank Greg Daley, Samita Chakrabarti, 1246 Marcelo Bagnulo, Suresh Krishnan, Mohan Parthasarathy, Lila Madour, 1247 Francis Dupont, Roland Bless, Mark Doll, and Tobias Kuefner for their 1248 review and comments on the predecessors of this document. 1250 Finally, the authors would also like to emphasize that [19] pioneered 1251 the use of cryptographically generated addresses in the context of 1252 Mobile IPv6 route optimization, and that this document consists 1253 largely of material from [20], [21], and [10] and the 1254 contributions of their authors. 1256 Appendix B. Overview of CGA 1258 As described in [18], a Cryptographically Generated Address (CGA) is 1259 an IPv6 address, which contains a set of bits generated by hashing 1260 the IPv6 address owner's public key. Such feature allows the user to 1261 provide a "proof of ownership" of its IPv6 address. 1263 The CGA offers three main advantages: it makes the spoofing attack 1264 against the IPv6 address much harder and allows to sign messages with 1265 the owner's private key. CGA does not require any upgrade or 1266 modification in the infrastructure. 1268 The CGA offers a method for binding a public key to an IPv6 address. 1269 The binding between the public key and the address can be verified by 1270 re-computing and comparing the hash value of the public key and other 1271 parameters sent in the specific message with the interface identifier 1272 in the IPv6 address belonging to the owner. Note that an attacker 1273 can always create its own CGA address but he will not be able to 1274 spoof someone else's address since he needs to sign the message with 1275 the corresponding private key, which is supposed to be known only by 1276 the real owner. 1278 CGA assures that the interface identifier part of the address is 1279 correct, but does little to ensure that the node is actually 1280 reachable at that identifier and prefix. As a result, CGA needs to 1281 be employed together with a reachability test where redirection 1282 denial-of-service attacks are a concern. 1284 Each CGA is associated with a public key and auxiliary parameters. 1285 In this protocol, the public key MUST be formatted as a DER-encoded 1286 [4] ASN.1 structure of the type SubjectPublicKeyInfo defined in the 1287 Internet X.509 certificate profile [5]. 1289 The CGA verification takes as input an IPv6 address and auxiliary 1290 parameters. These parameters are the following: 1292 o a 128-bit modifier, which can be any value, 1294 o a 64-bit subnet prefix, which is equal to the subnet prefix of the 1295 CGA, 1297 o an 8-bit collision count, which can have values 0, 1 and 2. 1299 If the verification succeeds, the verifier knows that the public key 1300 in the CGA parameters is the authentic public key of the address 1301 owner. In order to sign a message, a node needs the CGA, the 1302 associated CGA parameters, the message and the private cryptographic 1303 key that corresponds to the public key in the CGA parameters. The 1304 node needs to use a 128 bit type tag for the message from the CGA 1305 Message Type name space. The type tag is an IANA-allocated 128 bit 1306 integer. 1308 To sign a message, a node performs the following two steps: 1310 1. Concatenate the 128 bit type tag (in the network byte order) and 1311 message with the type tag to the left and message to the right. 1312 The concatenation is the message to be signed in the next step. 1314 2. Generate the RSA signature. The inputs to the generation 1315 procedure are the private key and the concatenation created in 1316 a). 1318 Appendix C. Overview of Credit-Based Authorization 1320 To prevent redirection-based flooding attacks, the easiest way would 1321 be not to use a new care-of address until it has been verified. This 1322 could proceed unnoticed when the mobile node can meanwhile 1323 communicate through a second interface. However, many situations are 1324 conceivable in which mobile nodes have a single interface only. The 1325 care-of-address test would increase signaling delays by one round- 1326 trip time in such cases. To avoid this additional delay, a new 1327 care-of address is used as soon as possible, and the correspondent 1328 node verifies the mobile node's reachability at that care-of address 1329 concurrently. Credit-Based Authorization for concurrent care-of- 1330 address tests prevents illegitimate packet redirection until the 1331 validity of the address has been established. This is accomplished 1332 based on the following three hypotheses: 1334 1. A flooding attacker typically seeks to somehow multiply the 1335 packets it generates itself for the purpose of its attack because 1336 bandwidth is an ample resource for many attractive victims. 1338 2. An attacker can always cause unamplified flooding by sending 1339 packets to its victim directly. 1341 3. Consequently, the additional effort required to set up a 1342 redirection-based flooding attack would pay off for the attacker 1343 only if amplification could be obtained this way. 1345 On this basis, rather than eliminating malicious packet redirection 1346 in the first place, Credit-Based Authorization prevents any 1347 amplification that can be reached through it. This is accomplished 1348 by limiting the data a correspondent node can send to an unverified 1349 care-of address of a mobile node by the data recently received from 1350 that mobile node. Redirection-based flooding attacks thus become 1351 less attractive than, e.g., pure direct flooding, where the attacker 1352 itself sends bogus packets to the victim. 1354 Figure 10 illustrates Credit-Based Authorization: The correspondent 1355 node measures the bytes received from the mobile node. When the 1356 mobile node changes to a new care-of address, the correspondent node 1357 labels this address UNVERIFIED and sends packets there as long as the 1358 sum of the packet sizes does not exceed the measured, received data 1359 volume. The mobile node's reachability at the new care-of address 1360 meanwhile gets verified When the care-of-address test completes with 1361 success, the correspondent node relabels the care-of address from 1362 UNVERIFIED to VERIFIED. As of then, packets can be sent to the new 1363 care-of address without restrictions. When insufficient credit is 1364 left while the care-of address is still UNVERIFIED, the correspondent 1365 node stops sending further packets until address verification 1366 completes. 1368 +-------------+ +--------------------+ 1369 | Mobile Node | | Correspondent Node | 1370 +-------------+ +--------------------+ 1371 | | 1372 address |------------------------->| credit += size(packet) 1373 verified | | 1374 |------------------------->| credit += size(packet) 1375 |<-------------------------| don't change credit 1376 | | 1377 + address change | 1378 address |<-------------------------| credit -= size(packet) 1379 unverified|------------------------->| credit += size(packet) 1380 |<-------------------------| credit -= size(packet) 1381 | | 1382 |<-------------------------| credit -= size(packet) 1383 | X credit < size(packet) ==> drop 1384 | | 1385 + address change | 1386 address | | 1387 verified |<-------------------------| don't change credit 1388 | | 1390 Figure 10: Credit-Based Authorization 1392 The correspondent node ensures that the mobile node's acquired credit 1393 gradually decrease over time. Such "credit aging" prevents a 1394 malicious node from building up credit at a very slow speed and using 1395 this, all at once, for a severe burst of redirected packets. 1397 Intellectual Property Statement 1399 The IETF takes no position regarding the validity or scope of any 1400 Intellectual Property Rights or other rights that might be claimed to 1401 pertain to the implementation or use of the technology described in 1402 this document or the extent to which any license under such rights 1403 might or might not be available; nor does it represent that it has 1404 made any independent effort to identify any such rights. Information 1405 on the procedures with respect to rights in RFC documents can be 1406 found in BCP 78 and BCP 79. 1408 Copies of IPR disclosures made to the IETF Secretariat and any 1409 assurances of licenses to be made available, or the result of an 1410 attempt made to obtain a general license or permission for the use of 1411 such proprietary rights by implementers or users of this 1412 specification can be obtained from the IETF on-line IPR repository at 1413 http://www.ietf.org/ipr. 1415 The IETF invites any interested party to bring to its attention any 1416 copyrights, patents or patent applications, or other proprietary 1417 rights that may cover technology that may be required to implement 1418 this standard. Please address the information to the IETF at 1419 ietf-ipr@ietf.org. 1421 The IETF has been notified of intellectual property rights claimed in 1422 regard to some or all of the specification contained in this 1423 document. For more information consult the online list of claimed 1424 rights. 1426 Disclaimer of Validity 1428 This document and the information contained herein are provided on an 1429 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1430 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1431 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1432 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1433 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1436 Copyright Statement 1438 Copyright (C) The Internet Society (2006). This document is subject 1439 to the rights, licenses and restrictions contained in BCP 78, and 1440 except as set forth therein, the authors retain all their rights. 1442 Acknowledgment 1444 Funding for the RFC Editor function is currently provided by the 1445 Internet Society.