idnits 2.17.1 draft-vogt-mobopts-credit-based-authorization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1881. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 41 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (February 14, 2005) is 7009 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 3775 (ref. '1') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. '2' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Vogt 2 Internet-Draft Univ. of Karlsruhe, Germany 3 Expires: August 18, 2005 J. Arkko 4 Ericsson Research NomadicLab 5 February 14, 2005 7 Credit-Based Authorization for Mobile IPv6 Early Binding Updates 8 draft-vogt-mobopts-credit-based-authorization-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 18, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The latency associated with Mobile IPv6's Return Routability test can 44 have an adverse impact on delay-sensitive applications. Early 45 Binding Updates mitigate this issue by already using a new care-of 46 address in parallel with testing it. We propose and analyze a 47 credit-based mechanism that prevents misuse of Early Binding Updates 48 for amplified flooding attacks and discourages such misuse for 49 non-amplified flooding attacks. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Flooding Attacks . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1 Early Binding Updates . . . . . . . . . . . . . . . . . . 9 58 4.2 Credit-Based Authorization . . . . . . . . . . . . . . . . 10 59 4.3 Variants of Credit-Based Authorization . . . . . . . . . . 11 60 5. Detailed Description . . . . . . . . . . . . . . . . . . . . 13 61 5.1 State at the Correspondent Node . . . . . . . . . . . . . 13 62 5.2 Exponential Aging . . . . . . . . . . . . . . . . . . . . 15 63 5.3 Sending Packets to a Mobile Node . . . . . . . . . . . . . 16 64 5.4 Receiving Packets from a Mobile Node . . . . . . . . . . . 18 65 5.5 Handling Clock Ticks . . . . . . . . . . . . . . . . . . . 19 66 6. Care-of-Address Spot Checks . . . . . . . . . . . . . . . . 20 67 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 20 68 6.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 69 6.3 Generating Random Strings . . . . . . . . . . . . . . . . 23 70 6.4 Spot Check Frequency . . . . . . . . . . . . . . . . . . . 24 71 6.5 State at the Correspondent Node . . . . . . . . . . . . . 24 72 6.6 Sending Packets to a Mobile Node . . . . . . . . . . . . . 26 73 6.7 Receiving Packets from a Mobile Node . . . . . . . . . . . 27 74 6.8 Handling Clock Ticks . . . . . . . . . . . . . . . . . . . 29 75 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 76 7.1 Scope of Protection . . . . . . . . . . . . . . . . . . . 30 77 7.2 Attacks on the Routing Infrastructure . . . . . . . . . . 31 78 7.3 Limiting Packet Rate . . . . . . . . . . . . . . . . . . . 32 79 7.4 Asymmetric Network Attachment . . . . . . . . . . . . . . 34 80 7.5 Resource Exhaustion Attacks . . . . . . . . . . . . . . . 35 81 7.6 Alternatives to Credit-Based Authorization . . . . . . . . 36 82 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 37 83 9. Protocol Configuration Variables . . . . . . . . . . . . . . 38 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 86 11.1 Normative References . . . . . . . . . . . . . . . . . . 39 87 11.2 Informative References . . . . . . . . . . . . . . . . . 39 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 89 Intellectual Property and Copyright Statements . . . . . . . 41 91 1. Introduction 93 Along with the introduction of mobility support in the Internet comes 94 the concern about a new family of previously unknown attacks. The 95 potential misuse of mobility-management protocols is multifold, 96 ranging from resource-exhaustion attacks and redirection-based 97 flooding attacks to masquerading attacks and attacks against data 98 confidentiality or integrity [4]. Mobility-related attacks are of 99 great concern because any node in the Internet is a potential victim. 100 A victim does not even have to be mobile. The problem is that the 101 victim has little means to protect itself, whereas the party that is 102 in a position to build an effective security mechanism does not 103 directly benefit from its investments into this mechanism [8]. 105 There is hence a strong need that a mobility-management protocol, 106 like Mobile IPv6, incorporates the required security mechanisms in 107 the first place. Mobile IPv6 has been carefully designed with regard 108 to this. Malicious binding updates with home agents are discouraged 109 by a mandatory security and trust relationship between a mobile node 110 and its home agent. Since neither a security nor a trust 111 relationship can be presupposed to exist between a mobile node and a 112 correspondent node, Mobile IPv6 prevents malicious binding updates 113 with correspondent nodes, when using Route Optimization, through a 114 home-address test and a care-of-address test. A mobile node must 115 pass both tests in order to authenticate its home address and care-of 116 address during the binding-update phase. Home-address authentication 117 verifies that the mobile node is the legitimate owner of the home 118 address. It prevents masquerading attacks and attacks against data 119 confidentiality or integrity. Care-of-address authentication 120 verifies that the mobile node is actually present at the new care-of 121 address. It prevents a malicious node from flooding a third party 122 with a stream of redirected packets. 124 A disadvantage of Mobile IPv6's home-address and care-of-address 125 tests is that both tests have to be accomplished before a mobile node 126 can initiate a binding update. The latency of registering a new 127 care-of address with a correspondent node can therefore be 128 significant, and it can have an adverse impact on delay-sensitive 129 applications. Early Binding Updates for Mobile IPv6 [2], an optional 130 extension to Mobile IPv6 Route Optimization, reduce this latency by 131 moving both tests out of the critical period during which a new 132 care-of address cannot yet be used: A "prophylactic home-address 133 test" is accomplished before the mobile node changes its point of 134 network attachment, and a "concurrent care-of-address test" runs in 135 parallel with data transfer to and from the new care-of address. The 136 new care-of address is said to be "unconfirmed" until the mobile node 137 authenticates the care-of address to the correspondent node, and it 138 is called "confirmed" thereafter. 140 Section 7 of [2] furnishes evidence that the security of Early 141 Binding Updates is equivalent to that of standard Mobile IPv6 except 142 for a new vulnerability to flooding attacks based on packet 143 redirection towards an unconfirmed care-of address. We show in 144 Section 3 that the data volume and rate of a redirection-based 145 flooding attack can be substantially higher than the data volume and 146 rate generated by the attacker itself. No such "amplification" can 147 be achieved through flooding attacks that exist in today's Internet. 148 With the objective that a mobility-management protocol does not 149 introduce new threats in addition to those that already exist, 150 flooding-attack amplification, be it with respect to data volume or 151 data rate, is certainly unacceptable. In this document, we propose a 152 mechanism, Credit-Based Authorization, that prevents misuse of Early 153 Binding Updates for amplified, redirection-based flooding attacks. 154 Through proper parameterization, Credit-Based Authorization can 155 discourage misuse of Early Binding Updates even for non-amplified, 156 redirection-based flooding attacks. 158 Credit-Based Authorization limits the data volume that a 159 correspondent node can send to a mobile node's unconfirmed care-of 160 address, and it limits the data rate at which the correspondent node 161 can send this data. The maximum data volume and rate depend on how 162 much data the mobile node has sent to, or received from, the 163 correspondent node during the last few seconds. With Credit-Based 164 Authorization, a correspondent node measures the "effort" that a 165 mobile node spends for sending or receiving packets, and it grants 166 "credit" for this effort. The mobile node needs credit during the 167 binding-update phase: If it has enough credit, the mobile node can 168 use a new, unconfirmed care-of address for both sending and receiving 169 packets. Without sufficient credit, the mobile node can use a new, 170 unconfirmed care-of address only for packets that it sends to the 171 correspondent node. The correspondent node then sends packets for 172 the mobile node to the mobile node's home address until the mobile 173 node authenticates its care-of address, and the care-of address 174 becomes confirmed. We show that Credit-Based Authorization can be 175 realized at reasonable deployment costs. 177 The applicability of Credit-Based Authorization goes beyond the 178 protection against misuse of Early Binding Updates. In [5], a 179 credit-based approach is used to incrementally extend binding 180 lifetimes. This reduces the signaling overhead required for binding 181 refreshes. We are also working on an extended version of Early 182 Binding Updates which allows a mobile node to already register a new 183 care-of address from its old point of network attachment. Such 184 "Anticipated Binding Updates" would naturally depend on something 185 similar to Mobile IPv6's Alternate Care-of-Address option. We 186 believe that Credit-Based Authorization can help to make Anticipated 187 Binding Updates a secure and, thus, realistic option. 189 The rest of this document is structured as follows: We define a set 190 of key terms in Section 2. In Section 3, we compare the types of 191 flooding attacks that already exist in today's Internet to those that 192 could become possible by the introduction of mobility support if no 193 preventive measures are taken. In Section 4, we describe Early 194 Binding Updates in a nutshell, and we sketch the idea of Credit-Based 195 Authorization. We show that there are two variants of Credit-Based 196 Authorization: The first variant measures a mobile node's effort for 197 sending packets to the correspondent node, the second variant 198 measures a mobile node's effort for receiving packets from the 199 correspondent node. Either variant comes with its particular 200 advantages and drawbacks. We detail both variants in Section 5. In 201 section Section 6, we discuss potential security concerns which one 202 might have with measuring a mobile node's effort for receiving 203 packets from the correspondent node. We propose a mechanism, 204 periodic care-of-address spot checks, which can disperse these 205 concerns. Security considerations follow in Section 7. We conclude 206 in Section 8. 208 Credit-Based Authorization for Mobile IPv6 Early Binding Updates was 209 first presented at the 59th IETF meeting in Seoul, Republic of Korea, 210 in February 2004. 212 2. Terminology 214 Effort 215 Effort is a mobile node's investment in terms of bandwidth, 216 processing power, and memory. There are two types of effort which 217 a mobile node typically spends: effort for sending packets to the 218 correspondent node and effort for receiving packets from the 219 correspondent node. 221 Credit 222 Credit is a unit used by a correspondent node to determine how 223 much data it can send to a particular mobile node. A mobile node 224 earns credit by investing effort. 226 Amplification 227 Amplification describes the severity of a flooding attack. It is 228 defined as the ratio between the data volume and rate that the 229 attacked victim is exposed to and the data volume and rate that 230 the attacker itself generates. 232 Early Binding Update message 233 An Early Binding Update message equals a standard Binding Update 234 message except that it only authenticates the mobile node's home 235 address. When a mobile node changes its point of network 236 attachment and configures a new care-of address, the mobile node 237 sends to the correspondent node an Early Binding Update message in 238 order to tentatively register the new care-of address with the 239 correspondent node [2]. 241 Early Binding Acknowledgement message 242 A correspondent node sends to a mobile node an Early Binding 243 Acknowledgement message in order to indicate successful reception 244 of an Early Binding Update message [2]. 246 Prophylactic home-address test 247 A prophylactic home-address test is a home-address test which a 248 mobile node performs before it changes its point of network 249 attachment. The mobile node executes a prophylactic home-address 250 test whenever a handover is imminent. Alternatively, if handovers 251 cannot be anticipated, the mobile node should do a prophylactic 252 home-address test periodically [2]. 254 Concurrent care-of-address test 255 A concurrent care-of-address test is a care-of-address test which 256 is performed in parallel with data transfer to and from the tested 257 care-of address [2]. 259 Confirmed care-of address 260 A confirmed care-of address is a care-of address which a mobile 261 node has registered with a correspondent node by means of a 262 properly authenticated standard Binding Update message [2]. 264 Unconfirmed care-of address 265 An unconfirmed care-of address is a care-of address which a mobile 266 node has registered with a correspondent node by means of a 267 properly authenticated Early Binding Update message and which has 268 not yet been confirmed by means of a properly authenticated 269 standard Binding Update message [2]. 271 3. Flooding Attacks 273 Flooding attacks are a variant of denial-of-service attacks. They 274 are characterized by a victim being bombarded with unwanted packets 275 at a rate that the victim, and possibly the victim's access network, 276 cannot handle. In this section, we compare the types of flooding 277 attacks that already exist in today's Internet to those that could 278 become possible by the introduction of mobility support if no 279 preventive measures are taken. We show that the latter are 280 potentially much more severe due to a significantly higher 281 amplification. "Amplification" is the ratio between the data volume 282 and rate that the victim is exposed to and the data volume and rate 283 that the attacker itself generates. 285 There are essentially two types of flooding attacks that are already 286 possible in today's Internet: direct flooding attacks and reflection 287 attacks. In a direct flooding attack, the attacker itself sends 288 unwanted packets to the victim. In an indirect reflection attack, a 289 third node, the reflection point, sends the packets. The attacker 290 typically uses a known protocol vulnerability to make the reflection 291 point generate these packets [7]. One example is that the attacker 292 sends ICMP Echo Request packets to the reflection point with the 293 packets' source addresses set to the victim's IP address. The 294 reflection point, in turn, sends ICMP Echo Reply packets "back" to 295 the victim. Another example is that the attacker sends TCP SYN 296 packets, again with false source addresses, to the reflection point, 297 which in turn sends TCP SYN-ACK packets to someone who does not 298 expect these packets. Since most TCP servers are configured so that 299 they re-send a TCP SYN packet multiple times when failing to receive 300 an acknowledgement, this reflection attack can even produce a small 301 amplification. Gaining more significant amplification in today's 302 Internet typically requires more complex attack strategies like 303 taking over control of other nodes by spreading compromised code. 304 Such attacks are of a different quality because they change the 305 behavior of infected nodes. We do not discuss these attacks in this 306 document. Instead, we focus on attacks that are based on misuse of 307 vulnerable, but uncompromised protocol behavior. Note that 308 vulnerable protocol behavior could be misused by infected nodes to 309 substantially increase the damage each of them causes. 311 Given uncompromised behavior of Internet protocols, we make the 312 following two observations: First, both in a direct flooding attack 313 and in a reflection attack, the attacker can conceal its identity by 314 spoofing its packets' source addresses. Reflection attacks are 315 purely based on source-address spoofing. Ingress filtering [6] in 316 the attacker's access network may prevent source-address spoofing, 317 but more than a few access networks do not employ ingress filtering. 318 Second, what limits a flooding attack in today's Internet is the 319 minimum bandwidth along the path from the attacker to the victim, 320 possibly through a reflection point. The data volume and rate that 321 the flooding attack comes to is by and large determined by the data 322 volume and rate that the attacker itself generates, i.e., there is no 323 significant amplification. 325 The situation can change when we introduce mobility. Suppose a node 326 is allowed to change its IP address without having to evidence that 327 it is present at the new IP address. Then, an attacker can 328 subscribe, through its own IP address, to a large data flow (e.g., a 329 video stream) offered by some server on the Internet. The attacker 330 can easily accomplish the initial handshake procedure with the server 331 while it uses its own IP address. Once data is flowing, the attacker 332 can redirect the flow to the IP address of an arbitrary third party, 333 the victim. The attacker can use the sequence numbers learned during 334 the initial handshake procedure in order to spoof acknowledgements 335 for packets that it assumes the server has sent to the victim. 337 The unprecedented severity of redirection-based flooding attacks is 338 that not the attacker, but a faithful server on the Internet can be 339 made generate packets used for an attack. The server does not have 340 to be infected with compromised code, and neither the victim nor the 341 server has to be mobile. The attacker produces as little as spoofed 342 feedback information to keep the data flow alive. To make matters 343 worse, the attacker can redirect to the victim data flows from 344 multiple servers. We observe that the scope of a redirection-based 345 flooding attack is only limited by the data volume and rate that one, 346 or even multiple, servers can generate, as well as the cumulative 347 minimum bandwidths of the paths from each server to the victim. The 348 associated amplification is much higher than in the discussed ICMP 349 and TCP flooding attacks. Hence, there is a strong need that a 350 mobility-management protocol cannot be misused for amplified, 351 redirection-based flooding attacks. In fact, since non-amplified 352 flooding attacks are already possible in today's Internet, protection 353 against non-amplified, redirection-based flooding attacks is less 354 important. 356 4. Overview 358 In this section, we provide a brief description of Early Binding 359 Updates for Mobile IPv6, and we sketch the idea of Credit-Based 360 Authorization. We explain how Credit-Based Authorization can 361 discourage misuse of Early Binding Updates for redirection-based 362 flooding attacks, and how it can prevent such misuse for 363 flooding-attack amplification. We show that there are two variants 364 of Credit-Based Authorization: The first variant measures a mobile 365 node's effort for sending packets to the correspondent node, the 366 second variant measures a mobile node's effort for receiving packets 367 from the correspondent node. We discuss the particular advantages 368 and drawbacks of either variant. 370 We refer to Section 5 for more details on Credit-Based Authorization, 371 and we refer to [2] for a thorough specification of Early Binding 372 Updates. 374 4.1 Early Binding Updates 376 When a mobile node recognizes that it is about to change its point of 377 network attachment, the mobile node initiates a prophylactic 378 home-address test. Alternatively, if the mobile node cannot 379 anticipate handovers, it should periodically repeat the home-address 380 test. When the mobile node eventually moves, the mobile node 381 configures a new care-of address and sends to the correspondent node 382 an Early Binding Update message. The prophylactic home-address test 383 allows the mobile node to authenticate its home address in this 384 message. 386 The mobile node initiates a concurrent care-of-address test as soon 387 as it has dispatched the Early Binding Update message. The mobile 388 node can start using its new care-of address as of then. The 389 correspondent node starts using the mobile node's new care-of address 390 as soon as it receives the Early Binding Update message from the 391 mobile node. Hence, both the mobile node and the correspondent node 392 use the mobile node's new care-of address in parallel with the 393 concurrent care-of-address test being executed. 395 When the correspondent node receives the Early Binding Update message 396 from the mobile node, it can be confident that the mobile node is the 397 legitimate owner of the home address advertised in this message due 398 to the home-address authentication. Since there is no 399 care-of-address authentication in the Early Binding Update message, 400 the correspondent node does not know at this point whether the mobile 401 node is actually present at its new care-of address. The new care-of 402 address is therefore said to be "unconfirmed". The binding lifetime 403 for an unconfirmed care-of address is limited to a few seconds, 404 TENTATIVE_RR_BINDING_LIFETIME [2]. 406 When the concurrent care-of-address test concludes, the mobile node 407 sends to the correspondent node a standard Binding Update message. 408 This message obeys the formats and semantics defined in [1], i.e., it 409 authenticates both the mobile node's home address and the mobile 410 node's new care-of address. Hence, when the correspondent node 411 receives the standard Binding Update message, it can be confident 412 that the mobile node uses the correct home address, and that the 413 mobile node is actually present at the new care-of address. The 414 correspondent node then changes the status of the new care-of address 415 from "unconfirmed" to "confirmed", and it extends the lifetime of the 416 associated binding to the smaller of the lifetime requested by the 417 mobile node and the maximum lifetime, MAX_RR_BINDING_LIFETIME, 418 according to Section 9.5.1 and Section 9.5.2 of [1]. 420 Due to the lack of care-of-address authentication in the Early 421 Binding Update message, there needs to be additional protection while 422 a mobile node's care-of address is unconfirmed. If no such 423 protection is provided, a malicious node may misuse Early Binding 424 Updates to register, as an unconfirmed care-of address, the IP 425 address of a third party. The correspondent node would then redirect 426 the attacker's packets to the third party without knowing it. 427 Credit-Based Authorization provides the additional protection that is 428 needed while a mobile node's care-of address is unconfirmed. 430 4.2 Credit-Based Authorization 432 Credit-Based Authorization limits the data volume that a 433 correspondent node can send to a mobile node's unconfirmed care-of 434 address, and it limits the rate at which the correspondent node can 435 send this data. Credit-Based Authorization is transparent to the 436 mobile node. There are two variants of Credit-Based Authorization, 437 which determine the maximum data volume and rate in different ways: 438 The first variant limits the data volume and rate according to how 439 much data the mobile node has sent to the correspondent node during 440 the last few seconds. The second variant limits the data volume and 441 rate according to how much data the mobile node has received from the 442 correspondent node during the last few seconds. We will compare both 443 variants in Section 4.3. 445 The correspondent node measures the "effort" that a mobile node 446 spends for sending or receiving packets, depending on which variant 447 of Credit-Based Authorization is used. Effort is measured in terms 448 of the size of packets recently sent or received. The product of 449 effort and a factor, EFFORT_QUENCH_FACTOR, of less than 1.0 yields 450 the mobile node's "credit". Credit, in turn, authorizes the mobile 451 node to receive packets at an unconfirmed care-of address. For each 452 packet that the correspondent node sends to an unconfirmed care-of 453 address of the mobile node, the correspondent node charges the mobile 454 node credit in the amount of the size of the packet. Through 455 exponential aging, we ensure that the mobile node's credit is at all 456 times determined by the effort that the mobile node has spent 457 throughout the last few seconds. 459 When the correspondent node has a packet for the mobile node, the 460 correspondent node first checks the state of the mobile node's 461 care-of address. If the care-of address is confirmed, the care-of 462 address has recently been authenticated by the mobile node, and the 463 correspondent node can be confident that the mobile node is actually 464 present at the care-of address. In this case, the correspondent node 465 sends the packet to the mobile node's care-of address as usual, 466 without touching the mobile node's credit. Otherwise, if the mobile 467 node's care-of address is unconfirmed, the correspondent node 468 determines the packet's destination according to how much credit the 469 mobile node has. If the mobile node's credit is more than, or equal 470 to, the size of the outgoing packet, the correspondent node sends the 471 packet directly to the mobile node's care-of address, and it reduces 472 the mobile node's credit by the size of this packet. If the mobile 473 node's credit is less than the size of the outgoing packet, the 474 correspondent node sends the packet to the mobile node's home 475 address. The packet is forwarded to the mobile node by the mobile 476 node's home agent in this case. Since the mobile node's home address 477 has been authenticated in the Early Binding Update message, the 478 correspondent node can assume that the mobile node is the legitimate 479 owner of the home address [2]. Thus, the correspondent node can send 480 packets to the mobile node's home address without security concerns, 481 and it does not need to reduce the mobile node's credit in this case. 483 We believe that a faithful mobile node, communicating with a 484 correspondent node in a typical manner, automatically expends effort 485 for sending packets to the correspondent node as well as for 486 receiving packets from the correspondent node. A faithful mobile 487 node hence automatically earns credit due to its normal behavior such 488 that it can receive packets at an unconfirmed care-of address during 489 the binding-update phase. As a consequence, the mobile node does not 490 have to be aware that Credit-Based Authorization is applied at the 491 correspondent node. 493 4.3 Variants of Credit-Based Authorization 495 A mobile node spends effort--in terms of bandwidth, processing power, 496 and memory--for sending packets to the correspondent node as well as 497 for receiving packets from the correspondent node. A correspondent 498 node may credit either type of effort. Effort for sending packets 499 can be credited, at the correspondent node, by measuring packets 500 received from the mobile node. Effort for receiving packets can be 501 credited by measuring packets sent to the mobile node while the 502 mobile node's care-of address is confirmed. Both variants have their 503 particular advantages and drawbacks. 505 The advantage of crediting a mobile node's effort for sending packets 506 is that it is exactly this type of effort that an attacker would have 507 to invest for a direct flooding attack or a reflection attack, both 508 of which are already possible in today's Internet. Through proper 509 selection of the EFFORT_QUENCH_FACTOR protocol-configuration 510 variable, the crediting function can easily be parameterized such 511 that misuse of Early Binding Updates for a redirection-based flooding 512 attack becomes more expensive than a direct flooding attack or a 513 reflection attack. Thus, requiring a node, whether faithful or 514 malicious, to send packets in order to earn credit is a 515 straightforward way to discourage misuse of Early Binding Updates. 517 The motivation for crediting a mobile node's effort for receiving 518 packets is different. Consider a mobile node running an application 519 which receives much more data from the correspondent node than it 520 sends back to the correspondent node. Streaming applications are 521 probably the most dominant example where user data is transferred 522 one-way only. The correspondent node is typically a server 523 originating a lot of data, whereas the mobile node generates little 524 more than acknowledgements and status information. The huge data 525 stream originating from the correspondent node leads to excessive 526 credit consumption during the binding-update phase. The mobile node, 527 however, can be expected to have a hard time gathering this credit if 528 its credit depends on the packets that it sends to the correspondent 529 node. We believe that crediting the mobile node's effort for 530 receiving packets is the most reasonable approach in this case. 531 Then, assuming that the volume and rate of data originating from the 532 correspondent node does not fluctuate too much--particularly, that 533 there is no significant increase in the generated data volume and 534 rate during the binding-update phase--applications with asymmetric 535 traffic will work fine. We emphasize that only while the mobile 536 node's care-of address is confirmed should the correspondent node 537 grant credit for packets sent to the mobile node. Only then can the 538 correspondent node expect that the mobile node actually receives 539 these packets. Note that this crediting function also works fine for 540 applications with symmetric traffic. 542 Packet loss on the path from the correspondent node to the mobile 543 node can be an issue when the correspondent node measures a mobile 544 node's effort for receiving packets based on the packets that it has 545 sent to the mobile node. We discuss this issue in Section 6. We 546 show how the correspondent node can use care-of-address spot checks 547 to take packet loss into consideration when it grants credit for 548 packets the mobile node was supposed to receive. 550 The first variant of Credit-Based Authorization, crediting a mobile 551 node's effort for sending packets, is transparent to the mobile node. 552 The second variant of Credit-Based Authorization, crediting a mobile 553 node's effort for receiving packets, is transparent to the mobile 554 node unless care-of-address spot checks are used. 556 A correspondent node may credit a mobile node's effort for both, 557 sending packets and receiving packets. After all, the mobile node 558 invests resources for traffic in both directions. The combination of 559 the two variants of Credit-Based Authorization is straightforward. 560 One simply needs to make sure that the total credit a mobile node can 561 earn does not exceed the total effort the mobile node has spent on 562 sending and receiving packets. To simplify matters, we do not 563 explicitly consider the case of crediting traffic in both directions 564 in this document. 566 5. Detailed Description 568 In this section, we describe independent implementations for two 569 variants of Credit-Based Authorization. The first variant measures a 570 mobile node's effort for sending packets to the correspondent node, 571 the other variant measures a mobile node's effort for receiving 572 packets from the correspondent node. Both implementations affect the 573 correspondent node only; no changes are needed at the mobile node. 575 5.1 State at the Correspondent Node 577 Credit-Based Authorization requires a correspondent node to be aware 578 of the state, confirmed or unconfirmed, of all registered care-of 579 addresses. The state of a care-of address is important to decide 580 whether or not a mobile node needs credit for packets sent to its 581 care-of address. We propose that the correspondent node maintains, 582 for each binding, an additional one-bit flag, 583 CONFIRMED_CARE_OF_ADDRESS, indicating whether or not the respective 584 care-of address is confirmed. CONFIRMED_CARE_OF_ADDRESS equals 1 if 585 the care-of address is confirmed. CONFIRMED_CARE_OF_ADDRESS equals 0 586 if the care-of address is unconfirmed. Figure 1 shows the two 587 care-of-address states as well as the state transitions that a 588 care-of address can be subject to. 590 Reordered +------+ Early 591 Early | | Binding 592 Binding | +-------------+ Update +-------------+ 593 Update +--> | | --------> | | ---+ Early 594 | Confirmed | | Unconfirmed | | Binding 595 Standard +--> | | <-------- | | <--+ Update 596 Binding | +-------------+ Standard +-------------+ 597 Update | | Binding 598 +------+ Update 600 Figure 1: Care-of Address States 602 When a mobile node changes its point of network attachment, it sends 603 to the correspondent node an Early Binding Update message in order to 604 tentatively register its new care-of address. Having sent the Early 605 Binding Update message, the mobile node initiates a concurrent 606 care-of-address test and, once the care-of-address test concludes, 607 sends to the correspondent node a standard Binding Update message in 608 order to confirm its care-of address [2]. 610 When the correspondent node receives the Early Binding Update message 611 from the mobile node, the correspondent node registers the mobile 612 node's new care-of address, and it sets the lifetime of the mobile 613 node's binding to TENTATIVE_RR_BINDING_LIFETIME, according to Section 614 4.1 of [2]. Beyond this, the correspondent node clears the 615 CONFIRMED_CARE_OF_ADDRESS flag in the mobile node's binding in order 616 to indicate that the new care-of address is unconfirmed at this 617 point. When the correspondent node receives the standard Binding 618 Update message from the mobile node, the correspondent node extends 619 the lifetime of the mobile node's binding to the smaller of the 620 lifetime requested by the mobile node and the maximum lifetime, 621 MAX_RR_BINDING_LIFETIME, according to Section 9.5.1 and Section 9.5.2 622 of [1]. Moreover, the correspondent node sets the 623 CONFIRMED_CARE_OF_ADDRESS flag in the mobile node's binding in order 624 to indicate that the care-of address is now confirmed. When the 625 mobile node changes its point of network attachment another time, it 626 again sends to the correspondent node an Early Binding Update 627 message, and the procedure repeats itself. 629 The correspondent node may receive from the mobile node multiple 630 Early Binding Update messages in a row. The messages may carry the 631 same care-of address, for instance, if the concurrent care-of-address 632 test fails for some reason, and the mobile node recognizes, due to a 633 timeout, that either the Care-of Test Init message or the Care-of 634 Test message got lost under way. The mobile node may then re-send 635 both, the Early Binding Update message in order to refresh the 636 tentative binding at the correspondent node, and the Care-of Test 637 Init message in order to re-initiate the concurrent care-of-address 638 test. The Early Binding Update messages may carry different care-of 639 addresses, for instance, if the mobile node changes its point of 640 network attachment two times shortly one after the other, and there 641 is no sufficient time to let the first concurrent care-of-address 642 test conclude. 644 When the correspondent node receives multiple Early Binding Update 645 messages in a row, the correspondent node handles each message 646 according to the procedure defined in Section 4.1 of [2], regardless 647 of whether this message carries a new or an already registered 648 care-of address. I.e., the correspondent node registers the care-of 649 address and resets the binding lifetime to 650 TENTATIVE_RR_BINDING_LIFETIME. The state of the care-of address 651 remains unconfirmed. 653 When the correspondent node receives multiple standard Binding Update 654 messages in a row, the correspondent node handles each message 655 according to the procedure defined in Section 9.5.1 and Section 9.5.2 656 of [1], regardless of whether this message carries a new or an 657 already registered care-of address. I.e., the correspondent node 658 registers the care-of address and resets the binding lifetime to the 659 smaller of the lifetime requested by the mobile node and the maximum 660 lifetime, MAX_RR_BINDING_LIFETIME. The state of the care-of address 661 remains confirmed. 663 A mobile node's Early Binding Update message and subsequent standard 664 Binding Update message might get reordered on the way to the 665 correspondent node. In this case, the correspondent node receives 666 from the mobile node a standard Binding Update message before it 667 receives from the same mobile node an Early Binding Update message 668 carrying the same care-of address. Since the two messages carry the 669 same care-of address, they obviously belong together. Thus, when the 670 correspondent node receives an Early Binding Update message carrying 671 an already registered, confirmed care-of address, the correspondent 672 node must ignore the message, keeping both the care-of-address state 673 and the binding lifetime unchanged. 675 5.2 Exponential Aging 677 We feel that a mobile node's credit should represent the mobile 678 node's most recently spent effort only. Otherwise, a mobile node may 679 collect credit over a potentially very long period and consume this 680 credit during a very short period. Though unlikely, a malicious node 681 may exploit this property by accumulating a large amount of credit 682 with a relatively slow data stream, and by using this credit, all at 683 once, for a short but potent data burst against an arbitrary victim. 685 We propose exponential aging to gradually reduce a mobile node's old 686 credit over time. With exponential aging, a mobile node's credit 687 diminishes while the mobile node does not use it. Accumulating 688 credit over a very long period, as well as collecting an indefinite 689 amount of credit, is thus impossible. An implication of this is that 690 exponential aging can limit the rate of packets which are being sent 691 to an unconfirmed care-of address of a mobile node to approximately 692 the rate of packets which have recently been sent to a confirmed 693 care-of address of the same mobile node. In other words, the 694 implication is that exponential aging can limit the rate of packets 695 which are consuming a mobile node's credit to approximately the rate 696 of packets based on which the same mobile node has recently earned 697 this credit. See Section 7.3 for a more detailed explanation on why 698 exponential aging can limit the rate of packets sent to an 699 unconfirmed care-of address. 701 A precise aging function ages a mobile node's credit whenever this 702 credit is about to be increased or reduced, and it accommodates the 703 time passed since the mobile node's credit was changed before. A 704 precise aging function is very complex, though. We thus propose to 705 simply re-calculate a mobile node's credit in equidistant "crediting 706 intervals" of TENTATIVE_RR_BINDING_LIFETIME length. The effort that 707 a mobile node has invested throughout a crediting interval is turned 708 into credit after having exponentially aged the mobile node's old 709 credit at the end of the crediting interval. We thus ensure that new 710 credit does not age before it has been around for at least one 711 crediting interval. The correspondent node may synchronize the 712 crediting intervals for all entries in its binding cache. A single 713 clock is therefore sufficient. 715 Note that TENTATIVE_RR_BINDING_LIFETIME defines both the length of a 716 crediting interval and the binding lifetime for an unconfirmed 717 care-of address [2]. Since the binding lifetime for an unconfirmed 718 care-of address is exactly the time for which the mobile node's 719 credit should be good during the binding-update phase, it makes sense 720 to let a mobile node collect credit during this time and to age the 721 mobile node's credit only when it is older than this time. 723 An alternative to exponential aging is to simply limit a mobile 724 node's credit by a constant upper bound. A limit certainly prevents 725 a mobile node from collecting an indefinite amount of credit. 726 However, a limit does not prevent a mobile node from keeping 727 collected credit for a long time before using the credit. A limit is 728 also insensitive to throughput conditions on the path between the 729 mobile node and the correspondent node. I.e., a limit for a 730 low-bandwidth connection is certainly inappropriate for a 731 high-bandwidth connection, and vice versa. We thus feel that 732 exponential aging is a more appropriate approach than limiting a 733 mobile node's credit by a constant upper bound. 735 5.3 Sending Packets to a Mobile Node 737 Suppose a correspondent node has a packet for a mobile node, and the 738 mobile node's care-of address is confirmed. If the correspondent 739 node credits the mobile node's effort for sending packets to the 740 correspondent node, it does not need to do anything related to 741 Credit-Based Authorization in this case. The correspondent node 742 simply sends the packet to the care-of address (A.1) without changing 743 the mobile node's credit: 745 (A) Sending a packet to a confirmed care-of address 746 (Credit is given for sending packets) 747 ------------------------------------------------------------ 748 (A.1) send(PACKET,CARE_OF_ADDRESS) 750 If the correspondent node credits the mobile node's effort for 751 receiving packets from the correspondent node, the correspondent node 752 proceeds according to the following algorithm. 754 (A') Sending a packet to a confirmed care-of address 755 (Credit is given for receiving packets) 756 ------------------------------------------------------------ 757 (A'.1) EFFORT := EFFORT + size(PACKET) 758 (A'.2) send(PACKET,CARE_OF_ADDRESS) 760 The correspondent node measures the mobile node's effort for 761 receiving a packet from the correspondent node in terms of the size 762 of the packet in bytes (A'.1). Effort invested during one crediting 763 interval is accumulated in a variable, EFFORT, which should be 764 sufficiently long not to roll over. The correspondent node maintains 765 this variable for each entry in its binding cache. New credit will 766 be calculated, based on the value of EFFORT, at the end the crediting 767 interval in step (D), after having exponentially aged any old credit. 768 We thus ensure that new credit does not age before it has been around 769 for at least one crediting interval. In step (A'.2), the packet is 770 sent to the mobile node's care-of address. 772 Now suppose that the correspondent node has a packet for a mobile 773 node, and the mobile node's care-of address is unconfirmed. In this 774 case, the correspondent node determines the packet's destination 775 according to the following steps, independently of whether the 776 correspondent node credits the mobile node's effort for sending or 777 for receiving packets. 779 (B) Sending a packet to an unconfirmed care-of address 780 (Credit is given for sending or receiving packets) 781 ------------------------------------------------------------ 782 (B.1) If CREDIT >= size(PACKET) 783 Then 784 (B.2) CREDIT := CREDIT - size(PACKET) 785 (B.3) send(PACKET,CARE_OF_ADDRESS) 786 (B.4) Else 787 (B.5) CREDIT := 0 788 (B.6) send(PACKET,HOME_ADDRESS) 789 EndIf 791 The correspondent node keeps the mobile node's credit in a variable, 792 CREDIT, which should be sufficiently long not to roll over. The 793 correspondent node maintains this variable for each entry in its 794 binding cache. Provided that CREDIT is greater than or equal to the 795 size of the outgoing packet in bytes (B.1), CREDIT is reduced by this 796 packet size (B.2), and the packet is sent to the mobile node's 797 care-of address (B.3). Otherwise, if CREDIT is smaller than the size 798 of the outgoing packet in bytes (B.4), any remaining credit is 799 eliminated (B.5) in order not to switch between the mobile node's 800 home address and current care-of address multiple times during a 801 single binding-update phase in case packet sizes differ. The packet 802 is then sent to the mobile node's home address (B.6). Note that 803 CREDIT never becomes a negative value. 805 Note that, even when the mobile node's care-of address is 806 unconfirmed, the correspondent node can assume that the mobile node 807 is the legitimate owner of the registered home address, and it can 808 send packets to this home address without security concerns. This is 809 because the correspondent node has recently received from the mobile 810 node an Early Binding Update message in which the mobile node's home 811 address has been authenticated [2]. However, differences in 812 propagation delay between packets directly relayed between the mobile 813 node and the correspondent node and packets passing the mobile node's 814 home agent may have an adverse performance impact on transport-layer 815 protocols and application behavior. It is subject to further 816 research how significant this impact can be. 818 The amount of available credit does not impact the route taken by 819 those packets which the mobile node sends to the correspondent node. 820 The correspondent node can safely accept a packet sent from the 821 mobile node's care-of address even if this care-of address is 822 unconfirmed and CREDIT is smaller than the size of the packet. The 823 reason is that packets sent from the mobile node to the correspondent 824 node cannot leverage a flooding attack other than a direct flooding 825 attack or a reflection attack, both of which are already possible in 826 today's Internet (Section 3). This implies that a mobile node can 827 send packets to the correspondent node from a new care-of address 828 immediately after having dispatched an Early Binding Update message 829 for this care-of address. The mobile node does not need to be aware 830 that the correspondent node uses Credit-Based Authorization, and it 831 does not need to know how much credit it has. 833 5.4 Receiving Packets from a Mobile Node 835 Suppose a correspondent node receives a packet from a mobile node. 836 If the correspondent node credits the mobile node's effort for 837 sending packets to the correspondent node, the correspondent node 838 executes the following algorithm independently of whether the mobile 839 node's care-of address is confirmed or unconfirmed. 841 (C) Receiving a packet 842 (Credit is given for receiving packets) 843 ------------------------------------------------------------ 844 (C.1) EFFORT := EFFORT + size(PACKET) 845 (C.2) deliver(PACKET) 847 The correspondent node measures the mobile node's effort for sending 848 a packet to the correspondent node in terms of the size of the packet 849 in bytes (C.1). The packet is delivered to the application in step 850 (C.2). 852 If the correspondent node credits the mobile node's effort for 853 receiving packets from the correspondent node, the correspondent node 854 does not need to do anything specific to Credit-Based Authorization. 855 It simply delivers the packet to the application (C'.1) without 856 changing the mobile node's credit: 858 (C') Receiving a packet 859 (Credit is given for sending packets) 860 ------------------------------------------------------------ 861 (C'.1) deliver(PACKET) 863 5.5 Handling Clock Ticks 865 The correspondent node may synchronize the crediting intervals for 866 all entries in its binding cache. A single clock marking the end of 867 a crediting interval is therefore sufficient. Upon a clock tick, the 868 correspondent node re-calculates the credit for each entry in its 869 binding cache according to the following formula. This formula is 870 used independently of whether the correspondent node credits the 871 mobile node's effort for sending or for receiving packets. There is 872 no distinction between bindings with a confirmed care-of address and 873 bindings with an unconfirmed care-of address. 875 (D) Handling a clock tick 876 (Credit is given for sending or receiving packets) 877 ------------------------------------------------------------ 878 (D.1) For Each Binding Do 879 (D.2) NEW_CREDIT := EFFORT_QUENCH_FACTOR * EFFORT 880 (D.3) CREDIT := CREDIT * CREDIT_AGING_FACTOR \ 881 + NEW_CREDIT 882 (D.4) EFFORT := 0 883 EndFor 885 The correspondent node re-computes the credit for each entry in its 886 binding cache (D.1). A particular mobile node's new credit, 887 NEW_CREDIT, equals EFFORT multiplied by EFFORT_QUENCH_FACTOR (D.2). 888 NEW_CREDIT is a helper variable used in this specification for 889 clarity purposes only. NEW_CREDIT is added to the aged value of 890 CREDIT in step (D.3). We use the aging factor, CREDIT_AGING_FACTOR, 891 proposed in Section 9. In step (D.4), the correspondent node resets 892 EFFORT to zero. 894 EFFORT_QUENCH_FACTOR is intended to optionally choke the increase of 895 a mobile node's credit. If EFFORT_QUENCH_FACTOR is smaller than 1.0, 896 a mobile node is forced to invest more effort, through sending or 897 receiving packets, than it gets back from a correspondent node while 898 its care-of address is unconfirmed. Therefore, the smaller 899 EFFORT_QUENCH_FACTOR is chosen, the less efficiently can Early 900 Binding Updates be misused for a flooding attack. If 901 EFFORT_QUENCH_FACTOR is set to 0.0, the correspondent node does not 902 send any packets to an unconfirmed care-of address, but it sends 903 these packets to the mobile node's home agent. Obviously, 904 EFFORT_QUENCH_FACTOR is ineffective if set to 1.0. We propose the 905 value given in Section 9. 907 We believe that the following observation is worthwhile mentioning: 908 If the values of EFFORT_QUENCH_FACTOR and CREDIT_AGING_FACTOR are 0.5 909 or less, the theory of infinite series tells that, assuming EFFORT is 910 constant throughout all crediting intervals, CREDIT approaches, but 911 never exceeds, the value of EFFORT. 913 6. Care-of-Address Spot Checks 915 A correspondent node may credit a mobile node's effort for sending 916 packets to the correspondent node, or it may credit a mobile node's 917 effort for receiving packets from the correspondent node 918 (Section 4.3). In this section, we discuss security concerns that 919 one might have with the latter approach. Although we provide 920 rationale that such security concerns are of less importance than 921 they may seem to be, we propose an optional mechanism, 922 care-of-address spot checks, that can disperse these security 923 concerns. 925 6.1 Introduction 927 The question with crediting a mobile node's effort for receiving 928 packets from a correspondent node is how the correspondent node can 929 measure this effort. Limiting effort measurements to confirmed 930 care-of addresses may not be sufficient in case of packet loss along 931 the path from the correspondent node to the mobile node. If a router 932 drops packets due to congestion, the mobile node receives less data 933 than the correspondent node has originally sent, even though the 934 mobile node's care-of address is confirmed. Thus, the mobile node 935 may earn credit for data that was lost and that it has never 936 received. A malicious node may even be able to position itself 937 behind a bottleneck router on purpose, and it may spoof 938 acknowledgements to encourage the correspondent node to send more 939 data. 941 Fortunately, there is an argument that the described attack scenario 942 is less likely to occur than it may seem: As explained in Section 5.2 943 and Section 7.3, exponential aging ensures that packets used to 944 collect credit must occur at approximately the same rate as packets 945 that consume this credit. Consequently, if an attacker hid behind a 946 bottleneck router, illegitimately collecting credit for a later 947 flooding attack against a third party, the workload exposed to the 948 bottleneck router would have to be comparable with the magnitude of 949 the flooding attack to come upon the third party. Moreover, a 950 bottleneck router is typically located at the edge of the Internet, 951 presumably in the access network itself. Abnormal workload of a 952 router should draw the attention of the access network's 953 administrator, who could easily identify the perpetrator for two 954 reasons: First, the attacker's care-of address would show up as the 955 destination address of all packets causing the high workload. The 956 care-of address would reveal the attacker's identity because it would 957 have to be confirmed in this case. Second, the attacker's home 958 address would show up in the Type-2 Routing extension header 959 mandatorily attached to all packets causing the high workload. The 960 home address, too, would reveal the attacker's identity independently 961 of the care-of-address state, because it would have been 962 authenticated in all recently transmitted Early Binding Update 963 messages and standard Binding Update messages. 965 Note that the attacker may spoof acknowledgements in order to 966 accelerate the packet stream originating from the correspondent node. 967 The resulting packet flood might go beyond the capacity not only of 968 the attacker's access network, but also of some link deeper in the 969 Internet. It can be expected, though, that congestion inside the 970 Internet does not mitigate the flood upon the attacker's access 971 network due to a higher available bandwidth inside the Internet. 972 Hence, the attacker should be identified even in this situation. 974 These observations suggest that no attractive new type of flooding 975 attack is introduced when a correspondent node credits a mobile 976 node's effort for receiving packets from the correspondent node. On 977 the other hand, we recognize the usefulness of some sort of feedback 978 mechanism that can help the correspondent node determine how much 979 data a mobile node really receives. Transport- or application-layer 980 protocols may provide this feedback. We propose a network-layer 981 approach, periodic care-of-address spot checks, which can disperse 982 the security concerns explained above. Our work on care-of-address 983 spot checks is in its very early stages. We decided to present 984 care-of-address spot checks in this document in order to spark a 985 discussion on their practicality and sufficiency. 987 6.2 Overview 989 Care-of-address spot checks periodically probe a mobile node's 990 presence at a confirmed care-of address. They are used to 991 approximately determine the congestion on the path between the 992 correspondent node and the mobile node. The correspondent node 993 calculates the mobile node's credit based on the packets sent to the 994 mobile node and the measured congestion. The more congestion the 995 correspondent node perceives, the fewer packets is the mobile node 996 expected to have received, and the less credit is given to the mobile 997 node. Thus, care-of-address spot checks provide reasonable certainty 998 that a mobile node earns credit only for packets that it actually 999 receives. Spot-check-related signaling data is piggybacked to 1000 user-data packets to reduce the bandwidth required for 1001 care-of-address spot checks to a minimum. Care-of-address spot 1002 checks are, by definition, unnecessary if there are no user-data 1003 packets to which spot-check-related signaling data can be attached. 1005 Care-of-address spot checks are initiated by the correspondent node. 1006 When a care-of-address spot check is due for a particular mobile 1007 node, the correspondent node attaches a random string to the next 1008 packet that it sends to the mobile node. In case the packet gets 1009 through to the mobile node, the mobile node retrieves the random 1010 string from the received packet, and it sends the random string back 1011 with the next packet addressed to the correspondent node. The mobile 1012 node is said to "pass" the care-of-address spot check if the 1013 correspondent node finds that the returned random string matches the 1014 random string originally sent to the mobile node. 1016 An important rule in the security design for Mobile IPv6 is that all 1017 signaling is initiated by the mobile node, and that the correspondent 1018 node only responds to the source address from which it has received a 1019 request. This rule ensures that a malicious node cannot redirect a 1020 correspondent node's response except by spoofing a request's source 1021 address. Mobile IPv6's home-address and care-of-address tests, both 1022 of which are initiated by the mobile node, are a good example where 1023 this rule has left a mark. See Section 3.3.3 of [3] for details on 1024 this. 1026 One may argue that care-of-address spot checks violate the described 1027 security-design rule since care-of-address spot checks are initiated 1028 by the correspondent node. This, however, is not the case for two 1029 reasons. First, random strings are attached to packets which would 1030 anyway be sent. The increase in packet size, which is due to an 1031 attached random string, should be acceptable. Second, 1032 care-of-address spot checks are exclusively initiated for confirmed 1033 care-of addresses. Therefore, the correspondent node can rest 1034 assured that packets carrying a random string cannot be redirected to 1035 spoofed care-of addresses, even though some of these packets may be 1036 dropped under way. 1038 6.3 Generating Random Strings 1040 There are multiple ways in which a correspondent node can generate 1041 the random strings that it needs for care-of-address spot checks. 1042 For instance, the correspondent node may generate a new random string 1043 for each care-of-address spot check. An obvious disadvantage of this 1044 approach, though, is that the number of random strings which the 1045 correspondent node must remember grows with the number of pending 1046 care-of-address spot checks. 1048 Mobile IPv6 uses Care-of Keygen Tokens [1] for care-of-address tests, 1049 which can be handled in a more economic way. The beauty of Care-of 1050 Keygen Tokens is that the correspondent node does not have to 1051 explicitly store them. Instead, the correspondent node can 1052 re-compute a mobile node's Care-of Keygen Token on demand given a 1053 nonce, which can be re-used for multiple mobile nodes, and the mobile 1054 node's care-of address. All the correspondent node needs to remember 1055 is a set of nonces, the size of which is independent of the number of 1056 pending care-of-address tests. This kind of resource preservation is 1057 an important precaution against denial-of-service attacks that aim at 1058 exhausting the correspondent node's resources [3][4]. 1060 One may argue that protection against denial-of-service attacks is 1061 less important in the case of care-of-address spot checks than it is 1062 in the case of care-of-address tests. After all, both a mobile 1063 node's home address and care-of address are already authenticated 1064 during a care-of-address spot check. Computational efficiency may 1065 therefore be more important than storage efficiency. This is a 1066 fundamental difference to standard care-of-address tests. 1067 Nonetheless, in order to simplify our proposed implementation of 1068 care-of-address spot checks, we re-use existing Mobile IPv6 code for 1069 handling Care-of Keygen Tokens. 1071 Note that nonces used for care-of-address spot checks typically have 1072 a much shorter lifetime, and are more frequently re-produced, than 1073 nonces used for care-of-address tests. We therefore use separate 1074 nonce sets for care-of-address tests and care-of-address spot checks. 1075 Henceforth, when we mention nonces or Care-of Keygen Tokens, we are 1076 referring to those used for care-of-address spot checks rather than 1077 care-of-address tests. 1079 We propose a new option, a Spot Check option, for the IPv6 1080 Destination Options extension header. When a correspondent node 1081 initiates a spot check of a mobile node's care-of address, it uses a 1082 Spot Check option to carry to the mobile node a Care-of Keygen Token 1083 and the index of the nonce used to produce this Care-of Keygen Token. 1084 Likewise, the mobile node uses a Spot Check option to return the 1085 received Care-of Keygen Token and nonce index to the correspondent 1086 node. The mobile node may use a single Spot Check option to return 1087 multiple pairs of Care-of Keygen Tokens and nonce indices to the 1088 correspondent node. This can be helpful in case the rate at which 1089 the mobile node sends packets to the correspondent node is less than 1090 the frequency of care-of-address spot checks. 1092 One may deploy a mechanism other than Care-of Keygen Tokens to 1093 generate and verify random strings for care-of-address spot checks. 1094 Although we do not discuss any such mechanism in this document, we 1095 emphasize that a random string, regardless of how it is created, must 1096 be sufficiently long to discourage a malicious node from guessing the 1097 string. Moreover, random-string generation must not be predictable, 1098 and there must be different random strings for different mobile 1099 nodes. 1101 6.4 Spot Check Frequency 1103 A correspondent node calculates a mobile node's new credit at the end 1104 of each crediting interval. An important design choice is hence how 1105 many care-of-address spot checks the correspondent node should 1106 initiate for a particular mobile node during one crediting interval. 1107 Obviously, there is a trade-off: On one hand, the higher the 1108 frequency of spot checks, the more accurately can the correspondent 1109 node determine the level of congestion on the path towards a mobile 1110 node. The frequency of care-of-address spot checks should therefore 1111 be high. On the other hand, each care-of-address spot check has an 1112 associated processing overhead--not so much at the mobile node as at 1113 the correspondent node. The frequency of care-of-address spot checks 1114 should therefore be limited in order to contain this overhead. We 1115 propose a maximum number of MAXIMUM_SPOT_CHECKS spot checks per 1116 crediting interval (Section 9). The correspondent node then 1117 initiates at most one care-of-address spot check per mobile node 1118 every TENTATIVE_RR_BINDING_LIFETIME/MAXIMUM_SPOT_CHECKS time. The 1119 correspondent node may initiate less care-of-address spot checks for 1120 a particular mobile node if there are, at times, no packets to be 1121 sent to the mobile node, or if the mobile node's care-of address is 1122 unconfirmed during part of the crediting interval. 1124 6.5 State at the Correspondent Node 1126 The time required to complete a care-of-address spot check not only 1127 depends on the round-trip time between a correspondent node and a 1128 mobile node, but also on the availability of packets which can carry 1129 a Spot Check option. However, neither the round-trip time nor the 1130 availability of packets is known in advance. Since a mobile node 1131 must have enough time to return a received Spot Check option, the 1132 correspondent node should be able to re-produce Care-of Keygen Tokens 1133 for a sufficiently long time. We propose that the correspondent node 1134 keeps the MAXIMUM_SPOT_CHECKS recently generated nonces. This allows 1135 it to re-produce one crediting interval worth of Care-of Keygen 1136 Tokens. We store these nonces in an array, NONCE[], with 1137 MAXIMUM_SPOT_CHECKS slots. The currently oldest nonce is replaced by 1138 a new nonce every TENTATIVE_RR_BINDING_LIFETIME/MAXIMUM_SPOT_CHECKS 1139 time. Consequently, any nonce is valid for a period of 1140 TENTATIVE_RR_BINDING_LIFETIME length, and a care-of-address spot 1141 check should not take longer than this time to complete. An index, 1142 CURRENT_NONCE_INDEX, points to the most recently generated nonce in 1143 the NONCE[] array. 1145 The correspondent node needs to remember which nonces it has used for 1146 spot checks of a particular mobile node's care-of address. 1147 Therefore, we extend each entry in the correspondent node's binding 1148 cache by an array, INITIATED[], of MAXIMUM_SPOT_CHECKS bits' length. 1149 Given a binding for a particular mobile node, INITIATED[i] is one if 1150 and only if NONCE[i] was used for a spot check of this mobile node's 1151 care-of address. When NONCE[CURRENT_NONCE_INDEX] is replaced by a 1152 new value, INITIATED[CURRENT_NONCE_INDEX] is set to zero for all 1153 entries in the correspondent node's binding cache. 1155 Moreover, the correspondent node needs to remember whether an 1156 initiated care-of-address spot check has been passed by a particular 1157 mobile node. This information is needed to compute the mobile node's 1158 credit at the end of a crediting interval. For this, we extend each 1159 entry in the correspondent node's binding cache by another array, 1160 PASSED[], of MAXIMUM_SPOT_CHECKS bits' length. Given a binding for a 1161 particular mobile node, PASSED[i] is one if and only if INITIATED[i] 1162 is one and the mobile node has passed the care-of-address spot check 1163 for which NONCE[i] was used. When NONCE[CURRENT_NONCE_INDEX] is 1164 replaced by a new value, PASSED[CURRENT_NONCE_INDEX] is set to zero 1165 for all entries in the correspondent node's binding cache. 1167 Care-of-address spot checks for multiple mobile nodes may coincide 1168 because each mobile node is spot-checked with a different Care-of 1169 Keygen Token. A single clock is thus sufficient to trigger spot 1170 checks of all registered confirmed care-of addresses. The same clock 1171 can also trigger the crediting function at the end of a crediting 1172 interval, i.e., after each series of MAXIMUM_SPOT_CHECKS clock ticks. 1174 A mobile node may attach the same Spot Check option to multiple 1175 packets sent to a correspondent node in order to compensate for 1176 potential packet loss. Of course, the correspondent node must not 1177 attach the same Spot Check option to multiple packets sent to the 1178 mobile node, because this would increase the likelihood that the 1179 mobile node receives the Spot Check option. An increased likelihood, 1180 in turn, would distort the measured congestion on the path towards 1181 the mobile node. For the same reason, a nonce must not be used for 1182 more than one spot check of a single care-of address, although it may 1183 be re-used for spot checks of multiple different care-of addresses. 1185 6.6 Sending Packets to a Mobile Node 1187 When a correspondent node has a packet for a mobile node, and the 1188 mobile node's care-of address is confirmed, the correspondent node's 1189 operation looks like this: 1191 (A") Sending a packet to a confirmed care-of address 1192 (Credit is given for receiving packets) 1193 ------------------------------------------------------------ 1194 (A".1) EFFORT := EFFORT + size(PACKET) 1195 (A".2) If INITIATED[CURRENT_NONCE_INDEX] == 0 1196 Then 1197 (A".3) CoKT := careOfKeygenToken(NONCES[CURRENT_NONCE_INDEX]) 1198 (A".4) attachSpotCheckOption(PACKET,CoKT,CURRENT_NONCE_INDEX) 1199 (A".5) INITIATED[CURRENT_NONCE_INDEX] := 1 1200 EndIf 1201 (A".6) send(PACKET,CARE_OF_ADDRESS) 1203 The correspondent node measures the mobile node's effort for 1204 receiving a packet in terms of the size of the packet in bytes 1205 (A".1). Effort invested during one crediting interval is accumulated 1206 in the variable EFFORT, which we have introduced in Section 5.3. New 1207 credit will be calculated at the end the crediting interval in step 1208 (D"), after having exponentially aged any old credit. The height of 1209 new credit depends on the value of EFFORT as well as the ratio of 1210 initiated to passed spot checks of the mobile node's care-of address. 1212 In step (A".2), the correspondent node checks whether a new spot 1213 check of the mobile node's care-of address is due. This is the case 1214 if INITIATED[CURRENT_NONCE_INDEX] is zero, which means that the most 1215 recently generated nonce, NONCE[CURRENT_NONCE_INDEX], has not yet 1216 been used for a spot check of the mobile node's care-of address. In 1217 step (A".3), the correspondent node produces a Care-of Keygen Token 1218 based on the mobile node's care-of address and 1219 NONCE[CURRENT_NONCE_INDEX] as defined in Section 5.2.5 of [1]. The 1220 correspondent node attaches a Spot Check option carrying this Care-of 1221 Keygen Token and CURRENT_NONCE_INDEX to the outgoing packet in step 1222 (A".4). The correspondent node then sets 1223 INITIATED[CURRENT_NONCE_INDEX] to one (A".5) in order not to do 1224 another care-of-address spot check with the same nonce for the same 1225 mobile node. If, at step (A".2), the correspondent node finds that 1226 INITIATED[CURRENT_NONCE_INDEX] is one, NONCE[CURRENT_NONCE_INDEX] has 1227 already been used for a spot check of the mobile node's care-of 1228 address. In this case, no care-of-address spot check is due, and 1229 steps (A".3) through (A".5) are skipped. Finally, the correspondent 1230 node sends the packet to the mobile node's care-of address (A".6). 1232 When the correspondent node has a packet for a mobile node, and the 1233 mobile node's care-of address is unconfirmed, the correspondent node 1234 determines the packet's destination according to step (B) of 1235 Section 5.3. 1237 6.7 Receiving Packets from a Mobile Node 1239 When the correspondent node receives a packet from a mobile node, the 1240 correspondent node executes the following algorithm independently of 1241 whether the mobile node's care-of address is confirmed or 1242 unconfirmed. 1244 (C") Receiving a packet 1245 (Credit is given for receiving packets) 1246 ------------------------------------------------------------ 1247 (C".1) If hasSpotCheckOption(PACKET) 1248 Then 1249 (C".2) CoKT := getCareOfKeygenToken(PACKET) 1250 (C".3) NONCE_INDEX := getNonceIndex(PACKET) 1251 (C".4) If (INITIATED[NONCE_INDEX] == 1) \ 1252 and (PASSED[NONCE_INDEX] == 0) 1253 Then 1254 (C".5) myCoKT := careOfKeygenToken(NONCES[NONCE_INDEX]) 1255 (C".6) If CoKT == myCoKT 1256 Then 1257 (C".7) PASSED[NONCE_INDEX] := 1 1258 EndIf 1259 EndIf 1260 EndIf 1261 (C".8) deliver(PACKET) 1263 In step (C".1), the correspondent node checks whether the packet has 1264 a Spot Check option attached to it. If there is no Spot Check 1265 option, the packet is simply delivered to the application in step 1266 (C".8). If a Spot Check option exists, the correspondent node 1267 determines as follows whether this Spot Check option is the correct 1268 response to a recently initiated care-of-address spot check. Let 1269 CoKT be the Care-of Keygen Token advertised in the Spot Check option 1270 (C".2), and let NONCE_INDEX be the nonce index advertised in the Spot 1271 Check option (C".3). NONCE_INDEX identifies the nonce that was 1272 allegedly used to create CoKT. 1274 The correspondent node then ensures that INITIATED[NONCE_INDEX] is 1275 one and PASSED[NONCE_INDEX] is zero (C".4). If 1276 INITIATED[NONCE_INDEX] is zero, NONCE[NONCE_INDEX] has not yet been 1277 used for a spot check of the mobile node's care-of address. This may 1278 happen if the received Spot Check option pertains to a nonce that has 1279 been replaced in the meantime. The correspondent node can safely 1280 ignore the Spot Check option in this case. If PASSED[NONCE_INDEX] is 1281 one, the mobile node has already passed the care-of-address spot 1282 check for which NONCE[NONCE_INDEX] was used. This may happen if the 1283 packet carrying the Spot Check option gets duplicated during 1284 transmission, or if the mobile node attaches the same Spot Check 1285 option to multiple packets in order to mitigate the potential of 1286 packet loss. Although it would not harm if the correspondent node 1287 set PASSED[NONCE_INDEX] to 1 again in step (C".7), the correspondent 1288 node can avoid re-producing the Care-of Keygen Token from the Spot 1289 Check option in step (C".5) in this case. 1291 Given that INITIATED[NONCE_INDEX] is one and PASSED[NONCE_INDEX] is 1292 zero, the correspondent node re-produces the Care-of Keygen Token 1293 from the Spot Check option based on the mobile node's care-of address 1294 and NONCE[NONCE_INDEX] (C".5). If the re-produced value matches the 1295 Care-of Keygen Token from the Spot Check option (C".6), the 1296 correspondent node sets PASSED[NONCE_INDEX] to one (C".7). In case 1297 of a mismatch, the correspondent node ignores the Spot Check option. 1298 The correspondent node should not punish the mobile node for 1299 returning an incorrect Care-of Keygen Token because a malicious node 1300 may otherwise fake false Spot Check options in order to prevent a 1301 faithful mobile node from gathering credit. Finally, the 1302 correspondent node delivers the packet to the application in step 1303 (C".8). 1305 Care-of-address spot checks are needed only when a mobile node 1306 collects credit, i.e., when the mobile node's care-of address is 1307 confirmed. On the other hand, the correspondent node should accept a 1308 Spot Check option coming back from a mobile node even if the mobile 1309 node's care-of address is unconfirmed. The reason is that the mobile 1310 node may receive a Spot Check option at a confirmed care-of address 1311 shortly before changing its point of network attachment. The mobile 1312 node may not be able to immediately return the Spot Check option due 1313 to a lack of outgoing packets. If the mobile node changes its 1314 network-attachment point at that time, chances are that the mobile 1315 node returns the received Spot Check option through an unconfirmed 1316 care-of address. 1318 6.8 Handling Clock Ticks 1320 As mentioned, the correspondent node may synchronize the 1321 care-of-address spot checks for all entries in its binding cache. A 1322 single clock is thus sufficient to trigger care-of-address spot 1323 checks, nonce replacements, and crediting. With spot check, the 1324 clock ticks MAXIMUM_SPOT_CHECKS times per crediting interval, i.e., 1325 in intervals of TENTATIVE_RR_BINDING_LIFETIME/MAXIMUM_SPOT_CHECKS 1326 length. The currently oldest nonce is replaced upon every clock 1327 tick; crediting is done only once per crediting interval, i.e., every 1328 MAXIMUM_SPOT_CHECKS clock ticks. 1330 Nonce replacement and crediting are united in the following 1331 algorithm, which the correspondent node runs upon every clock tick. 1332 The algorithm also prepares the next spot check of all confirmed 1333 care-of addresses. Note that the initiation time for a particular 1334 care-of-address spot check depends on when the correspondent node 1335 sends to the mobile node the next packet. This packet is then used 1336 to carry a Spot Check option. 1338 (D") Handling a clock tick 1339 (Credit is given for receiving packets) 1340 ------------------------------------------------------------ 1341 (D".1) CURRENT_NONCE_INDEX := (CURRENT_NONCE_INDEX + 1) \ 1342 modulo MAXIMUM_SPOT_CHECKS 1343 (D".2) NONCE[CURRENT_NONCE_INDEX] := random(2**64-1) 1344 (D".3) For Each Binding Do 1345 PASSED[CURRENT_NONCE_INDEX] := 0 1346 INITIATED[CURRENT_NONCE_INDEX] := 0 1347 EndFor 1348 (D".4) If CURRENT_NONCE_INDEX == 0 1349 Then 1350 (D".5) For Each Binding Do 1351 (D".6) NEW_CREDIT := EFFORT * EFFORT_QUENCH_FACTOR \ 1352 * sum(PASSED)/sum(INITIATED) 1353 (D".7) CREDIT := CREDIT * CREDIT_AGING_FACTOR \ 1354 + NEW_CREDIT 1355 (D".8) EFFORT := 0 1356 EndFor 1357 EndIf 1359 In step (D".1), the correspondent node increments 1360 CURRENT_NONCE_INDEX, which rolls over to zero when it reaches 1361 MAXIMUM_SPOT_CHECKS. The correspondent node then replaces 1362 NONCE[CURRENT_NONCE_INDEX] by a new random string (D".2), and it sets 1363 INITIATED[CURRENT_NONCE_INDEX] and PASSED[CURRENT_NONCE_INDEX] to 1364 zero for each entry in its binding cache (D".3). There is no 1365 distinction between bindings with a confirmed care-of address and 1366 bindings with an unconfirmed care-of address. For a particular 1367 mobile node with a confirmed care-of address, 1368 INITIATED[CURRENT_NONCE_INDEX] and PASSED[CURRENT_NONCE_INDEX] help 1369 the correspondent node remember that a new care-of-address spot check 1370 is due, and that a Spot Check option should be attached to the next 1371 packet sent to the mobile node. 1373 In step (D".4), the correspondent node checks whether the current 1374 crediting interval is over. This is defined to be the case when 1375 CURRENT_NONCE_INDEX rolls over to zero in step (D".1). 1376 CURRENT_NONCE_INDEX then points to the first nonce in the NONCE[] 1377 array. If so, the correspondent node re-computes the credit for each 1378 entry in its binding cache (D".5). A particular mobile node's new 1379 credit, NEW_CREDIT, is the product of EFFORT, EFFORT_QUENCH_FACTOR, 1380 and the ratio of the number of passed to the number of initiated 1381 care-of-address spot checks during the crediting interval (D".6). 1382 NEW_CREDIT is added to the aged value of CREDIT in step (D".7). 1383 Finally, the correspondent node resets EFFORT to zero (D".8). 1385 7. Security Considerations 1387 Credit-Based Authorization can prevent misuse of Early Binding 1388 Updates for amplified, redirection-based flooding attacks, and it can 1389 discourage such misuse for non-amplified, redirection-based flooding 1390 attacks. In this section, we explain why this is exactly the scope 1391 of protection that is needed to securely employ Early Binding 1392 Updates. We also discuss the design of Credit-Based Authorization 1393 itself with respect to security. 1395 7.1 Scope of Protection 1397 We emphasize that the objective of Credit-Based Authorization is not 1398 to prevent flooding attacks in general: This would probably be a 1399 hopeless venture given that we already have direct flooding attacks 1400 and reflection attacks in today's Internet (Section 3). The 1401 objective of Credit-Based Authorization is rather to prohibit misuse 1402 of Early Binding Updates for a type of flooding attack that is more 1403 potent than those types of flooding attacks already possible today. 1404 With this aim, Credit-Based Authorization prevents misuse of Early 1405 Binding Updates for amplified, redirection-based flooding attacks. 1406 As shown in Section 3, these attacks constitute to the Internet a 1407 significant threat which does not exist today. Credit-Based 1408 Authorization prevents them by limiting the data volume that a 1409 correspondent node can send to a mobile node's care-of address while 1410 this care-of address is unconfirmed. We show in Section 5.2 and 1411 Section 7.3 that, through exponentially aging a mobile node's old 1412 credit, there is also a limitation on the correspondent node's data 1413 rate when sending to an unconfirmed care-of address. 1415 Although Credit-Based Authorization does not prevent misuse of Early 1416 Binding Updates for non-amplified, redirection-based flooding 1417 attacks, it still makes such misuse unattractive enough to render it 1418 practically negligible. The reason is that the correspondent node 1419 can control, through the EFFORT_QUENCH_FACTOR protocol-configuration 1420 variable, how much effort a potential attacker must spend to gain the 1421 credit it needs for a flooding attack. Provided that 1422 EFFORT_QUENCH_FACTOR is below 1.0, the maximum data volume and rate 1423 that a flooding attack can amount to is less than the data volume and 1424 rate that the attacker has either previously sent to the 1425 correspondent node or previously received from the correspondent 1426 node. This makes misuse of Early Binding Updates for non-amplified, 1427 redirection-based flooding attacks very ineffective. 1429 From an attacker's point of view, misuse of Early Binding Updates for 1430 non-amplified, redirection-based flooding attacks has another 1431 important disadvantage compared to a conventional flooding attack: 1432 The attacker's home address shows up in the Type-2 Routing extension 1433 header mandatorily attached to all redirected packets. The home 1434 address reveals the attacker's identity independently of the 1435 care-of-address state, because it has been authenticated in all 1436 recently transmitted Early Binding Update messages and standard 1437 Binding Update messages. 1439 7.2 Attacks on the Routing Infrastructure 1441 Suppose an attacker has access to the path between a mobile node's 1442 home agent and the correspondent node. In this position, the 1443 attacker can impersonate the mobile node by spoofing an Early Binding 1444 Update message or a standard Binding Update message. For this, the 1445 attacker has to obtain a valid Home Keygen Token, which it can obtain 1446 in one of two ways. First, the attacker can eavesdrop on the Home 1447 Test Init and Home Test messages being exchanged between the mobile 1448 node and the correspondent node. Second, the attacker can itself 1449 inject into the network a Home Test Init message on behalf of the 1450 mobile node, and it can intercept the Home Test message coming back 1451 from the correspondent node. 1453 The difference between spoofing an Early Binding Update message and a 1454 standard Binding Update message is that the attacker has to have a 1455 valid Care-of Keygen Token in addition to the Home Keygen Token in 1456 the latter case. The attacker can produce a Care-of Keygen Token for 1457 a particular care-of address if it is present, or has a recorder, on 1458 the path from the correspondent node to that care-of address. For 1459 this, the attacker injects into the network a spoofed Care-of Test 1460 Init message, and it intercepts the Care-of Test message, along with 1461 the Care-of Keygen Token, returning from the correspondent 1462 node--either by itself or through the recorder. In a special case, 1463 the attacker is located in the correspondent node's network, where it 1464 can acquire a Care-of Keygen Token for an arbitrary care-of address. 1466 With the standard binding-update procedure, there is no way by which 1467 the attacker can redirect the mobile node's packets to a care-of 1468 address unless it is present, or has a recorder, on the path from the 1469 correspondent node to that care-of address. Things are different if 1470 the correspondent node supports Early Binding Updates and 1471 Credit-Based Authorization. In this case, an attacker on the path 1472 between the mobile node's home agent and the correspondent node can 1473 redirect the mobile node's packets to an arbitrary care-of address 1474 without having to show presence at that care-of address. Of course, 1475 the accumulated data volume of the redirected packets is limited by 1476 the mobile node's credit. 1478 We argue that the described type of attack is unlikely to occur for 1479 two reasons. First, a fundamental assumption in the design of the 1480 Mobile IPv6 security design [3] is that the routing infrastructure is 1481 secure and functioning. As this specifically includes the path 1482 between the mobile node's home agent and the correspondent node, it 1483 is reasonably unlikely that an attacker can get access to this path. 1485 Second, an attacker would have to invest a significant amount of 1486 effort in order to wage the described attack. Apart from having to 1487 get access to the routing infrastructure between the mobile node's 1488 home agent and the correspondent node, the attacker would have to 1489 synchronize with the mobile node in order to determine a point of 1490 time at which the mobile node's credit is high enough to make the 1491 attack worthwhile. We believe that these investments are 1492 unprofitable given that the yield of the described attack is limited 1493 by the mobile node's credit anyway. 1495 Though unlikely to occur, this potential attack ought to be borne in 1496 mind during experimental deployments of Early Binding Updates and 1497 Credit-Based Authorization. 1499 7.3 Limiting Packet Rate 1501 We repeatedly mention in this document that Credit-Based 1502 Authorization limits both the volume and the rate of packets that a 1503 correspondent node can send to a mobile node's unconfirmed care-of 1504 address. According to the specification in Section 5, however, there 1505 is an explicit limitation only of the data volume, whereas the 1506 limitation of the data rate is an implicit consequence of the 1507 application of exponential aging. In this section, we explain how 1508 exponential aging effectively enforces a limitation of the rate of 1509 packets that a correspondent node can send to a mobile node's 1510 unconfirmed care-of address. 1512 Exponential aging ensures that credit older than one crediting 1513 interval rapidly looses its value. Consequently, a mobile node's 1514 available credit is, at any time, for the most part determined by the 1515 effort that the mobile node has spent during the preceding crediting 1516 interval. A crediting interval has the same length as a tentative 1517 binding's lifetime, TENTATIVE_RR_BINDING_LIFETIME, which, in turn, is 1518 the time period for which the mobile node needs its credit during a 1519 binding-update phase. These things considered, we observe that the 1520 time period during which credit can be most effectively collected is 1521 as long as the time period during which this credit can be consumed, 1522 i.e., TENTATIVE_RR_BINDING_LIFETIME time. The consequence is as 1523 follows. 1525 Suppose, first, that the correspondent node measures the mobile 1526 node's effort for sending packets to the correspondent node. Since 1527 credit translates into data volume, the data volume that the 1528 correspondent node can send to a mobile node's unconfirmed care-of 1529 address during TENTATIVE_RR_BINDING_LIFETIME time is limited by the 1530 data volume that the mobile node has recently sent to the 1531 correspondent node during a period of the same length. Hence, the 1532 mean rate at which the correspondent node can send data to a mobile 1533 node's unconfirmed care-of address, averaged over a period of 1534 TENTATIVE_RR_BINDING_LIFETIME length, is limited by the mean rate at 1535 which the mobile node has recently sent data to the correspondent 1536 node during a period of the same length. Provided the value of 1537 TENTATIVE_RR_BINDING_LIFETIME is reasonably small, the actual data 1538 rates are bound to be close together as well. 1540 Things are similar when the correspondent node measures the mobile 1541 node's effort for receiving packets from the correspondent node. In 1542 this case, the data volume that the correspondent node can send to a 1543 mobile node's unconfirmed care-of address during 1544 TENTATIVE_RR_BINDING_LIFETIME time is limited by the data volume that 1545 the mobile node has recently received from the correspondent node 1546 during a period of the same length. Provided the value of 1547 TENTATIVE_RR_BINDING_LIFETIME is reasonably small, the actual rate at 1548 which the correspondent node can send data to a mobile node's 1549 unconfirmed care-of address is bound to be close to the actual rate 1550 at which the mobile node has recently received data from the 1551 correspondent node. 1553 In Section 3, we show that the power of a conventional flooding 1554 attack is by and large determined by the data volume and rate 1555 generated by the attacker itself. As explained above, Credit-Based 1556 Authorization transfers this property from conventional flooding 1557 attacks to flooding attacks realized through misuse of Early Binding 1558 Updates if and only if the correspondent node measures the mobile 1559 node's effort for sending packets to the correspondent node. The 1560 situation is different if the correspondent node measures the mobile 1561 node's effort for receiving packets from the correspondent node. See 1562 Section 7.4 for more details on this. 1564 7.4 Asymmetric Network Attachment 1566 In Section 4.3, we show that there are two variants of Credit-Based 1567 Authorization: The first variant measures a mobile node's effort for 1568 sending packets to a correspondent node; the second variant measures 1569 the mobile node's effort for receiving packets from the correspondent 1570 node. The first variant is based on the observation that, in a 1571 direct flooding attack or a reflection attack (Section 3), the 1572 attacker needs to spend resources in terms of sending, rather than 1573 receiving, packets. Thus, requiring a node, whether faithful or 1574 malicious, to send packets in order to earn credit is a 1575 straightforward way to discourage misuse of Early Binding Updates for 1576 redirection-based flooding attacks. The second variant accommodates 1577 a mobile node which receives much more data from the correspondent 1578 node than it sends back to the correspondent node. If the first 1579 variant was used in this case, this mobile node might not be able to 1580 collect the credit it needs, during a binding-update phase, to 1581 sustain the data stream received from the correspondent node. 1583 In most scenarios, crediting a mobile node's effort both for sending 1584 packets and for receiving packets provides comparable protection 1585 against misuse of Early Binding Updates. This even though, in a 1586 direct flooding attack or a reflection attack, the attacker's 1587 investments are in terms of packets which the attacker sends rather 1588 than in terms of packets which the attacker receives. The reason is 1589 that a node, whether faithful or malicious, typically spends 1590 comparable effort--in terms of bandwidth, processing power, and 1591 memory--for both sending and receiving packets. 1593 Things are different, however, if a node is asymmetrically attached 1594 to the Internet through, for instance, ADSL. An attacker could 1595 collect much more credit for receiving packets than it could collect 1596 for sending packets in this situation. As a consequence, if credit 1597 is given for packets which the attacker receives, misuse of Early 1598 Binding Updates for a redirection-based flooding attack might still 1599 be lucrative. Whether the existence of asymmetric network attachment 1600 prohibits the second variant of Credit-Based Authorization is subject 1601 to further discussion. 1603 As an aside, there is an alternative to the second variant of 1604 Credit-Based Authorization which likewise accommodates applications 1605 with asymmetric traffic patterns: Here, the correspondent node 1606 extends the length of a crediting interval such that the mobile 1607 node--even though it may not send as much data to the correspondent 1608 node as it receives from the correspondent node--has a chance to 1609 collect the amount credit that it needs, during a binding-update 1610 phase, to sustain the data stream received from the correspondent 1611 node. The advantage of this approach is that it accommodates 1612 applications with asymmetric traffic patterns without posing a new 1613 threat due to the existence of asymmetric network attachment. The 1614 drawback is that extending the length of a crediting interval allows 1615 a mobile node to collect credit over a longer period of time. A 1616 malicious node may misuse this property to by-pass the 1617 rate-controlling function of exponential aging, which we describe in 1618 Section 5.2 and Section 7.3. For this reason, we do not deepen the 1619 idea of extending the length of a crediting interval in this 1620 document. 1622 7.5 Resource Exhaustion Attacks 1624 In Section 6.3, we discuss how a correspondent node may produce and 1625 check the random strings needed for care-of-address spot checks. We 1626 propose to re-use the standard formula from Section 5.2.5 of [1], 1627 which is used to produce and check Care-of Keygen Tokens for 1628 care-of-address tests. This formula is an HMAC_SHA1 function. 1630 Mobile IPv6's Care-of Keygen Tokens help the correspondent node to 1631 efficiently manage its resources in terms of memory storage [3][4]. 1632 However, when Care-of Keygen Tokens are used for care-of-address spot 1633 checks, care has to be taken by the correspondent node not to fall 1634 victim to denial-of-service attacks that aim at exhausting its 1635 resources in terms of processing power. This can happen if a 1636 malicious node sends to the correspondent node Spot Check options 1637 with bogus Care-of Keygen Tokens. The correspondent node would have 1638 to check the validity of each of the received tokens in this case. 1639 The processing capacity required to validate Care-of Keygen Tokens in 1640 normal operation should be acceptable, but the processing capacity 1641 needed to invalidate a large number of bogus Care-of Keygen Tokens 1642 may be substantial. 1644 On the other hand, both a mobile node's home address and care-of 1645 address are already authenticated during a care-of-address spot 1646 check. One may argue that this feature is likely to discourage an 1647 attacker from waging a denial-of-service attack against the 1648 correspondent node. 1650 Still, it remains to be discussed how susceptible care-of-address 1651 spot checks are to denial-of-service attacks. One could mitigate the 1652 threat of such attacks by using a more efficient function to produce 1653 and check Care-of Keygen Tokens for care-of-address spot checks, 1654 while keeping the standard function used in [1] to produce and check 1655 Care-of Keygen Tokens for care-of-address test. For instance, one 1656 may calculate Care-of Keygen Tokens for care-of-address spot checks 1657 as a simple SHA1 hash rather than a keyed HMAC_SHA1. 1659 7.6 Alternatives to Credit-Based Authorization 1661 There are alternatives to Credit-Based Authorization which can 1662 protect against misuse of Early Binding Updates for redirection-based 1663 flooding attacks. One alternative is to grant the use of Early 1664 Binding Updates to a trusted community only. Recall that, when the 1665 correspondent node receives an Early Binding Update message from the 1666 mobile node, it can be confident that the mobile node is the 1667 legitimate owner of the home address advertised in this message due 1668 to the home-address authentication. This, in turn, allows the 1669 correspondent node to use the mobile node's home address as a 1670 criterion for deciding whether or not to install a tentative binding 1671 for the mobile node's new care-of address. For instance, the 1672 correspondent node may be a corporate server which grants Early 1673 Binding Updates to mobile nodes from the corporate network only. [9] 1674 goes a step further; it uses pre-configured binding-management keys 1675 shared between mutually trusting nodes. These approaches have a 1676 rather limited application scope, however. 1678 Another alternative to Credit-Based Authorization is a combination of 1679 ingress filtering [6] and a ban on the Alternate Care-of-Address 1680 option in the Early Binding Update message. Ingress filtering is a 1681 function in the access network, preventing packets with spoofed 1682 source addresses to leave the network. The disadvantage of ingress 1683 filtering is that it is not universally deployed, and as such cannot 1684 be relied upon. 1686 A third alternative to Credit-Based Authorization is to identify and 1687 blacklist malicious nodes based on their observed behavior. 1688 Credit-Based Authorization is a proactive strategy, whereas 1689 behavior-based blacklisting is a reactive one. The advantage of a 1690 reactive approach is that a faithful mobile node does not need to 1691 invest effort (i.e., collect credit) before it can receive packets at 1692 an unconfirmed care-of address during the binding-update period. 1693 This can accommodate a mobile node having trouble to collect 1694 sufficient credit--be it because the mobile node's care-of address 1695 changes too frequently, or because the correspondent node measures 1696 the mobile node's effort for sending packets to the correspondent 1697 node, but the mobile node's application generates only very little 1698 data. On the other hand, a reactive approach is by definition unable 1699 to prevent misuse of Early Binding Updates in advance. What it can 1700 do is contain the damage of such misuse and punish the perpetrator. 1701 Punishment, however, will be negligible in most cases, since an 1702 administrative relationship between a mobile node and a correspondent 1703 node does usually not exist. 1705 Behavior-based blacklisting requires a heuristic to determine what 1706 behavior is considered "ill". Choosing the right heuristic, however, 1707 is far from trivial. If carelessly chosen, a heuristic may punish a 1708 faithful mobile node or overlook an evil one. For instance, a simple 1709 heuristic may assume that a faithful mobile node sends a standard 1710 Binding Update message soon after having sent an Early Binding Update 1711 message. At first glance, this heuristic seems to work well: Keeping 1712 alive an unconfirmed care-of address by repeatedly sending Early 1713 Binding Update messages is no longer possible. On the other hand, 1714 there is an easy way to trick this heuristic: An attacker can send to 1715 the correspondent node a forged Early Binding Update message using a 1716 victim's IP address as its care-of address. The attacker can cause 1717 the correspondent node to send packets to the victim as long as the 1718 heuristic allows. The attacker can then update the care-of address 1719 to its own IP address by means of a standard Binding Update 1720 message--thereby fulfilling what the heuristic expects it to do--and 1721 immediately re-update the care-of address to the victim's IP address 1722 by means of an Early Binding Update message. This procedure can be 1723 repeated indefinitely. 1725 While a heuristic may fail to identify a malicious node, it may also 1726 wrongly accuse a faithful mobile node. For example, a mobile node 1727 may be subject to two handovers immediately following each other. 1728 After the first handover, the mobile node may be able to send an 1729 Early Binding Update message, but it may not have enough time to 1730 complete the concurrent care-of address test. If the mobile node 1731 attempted another Early Binding Update after the second handover, the 1732 above-described heuristic would wrongly blacklist it. 1734 8. Conclusion 1736 Early Binding Updates for Mobile IPv6 have been proposed as an 1737 optional optimization for Mobile IPv6. Early Binding Updates allow a 1738 mobile node to use a new care-of address while a care-of-address test 1739 is in progress. Protective measures are necessary to rule out misuse 1740 of this concurrency for redirection-based flooding attacks. We 1741 propose a mechanism, Credit-Based Authorization, that prevents misuse 1742 of Early Binding Updates for amplified, redirection-based flooding 1743 attacks. Through proper parameterization, Credit-Based Authorization 1744 can discourage misuse of Early Binding Updates even for 1745 non-amplified, redirection-based flooding attacks. 1747 With Credit-Based Authorization, a correspondent node monitors a 1748 mobile node's effort for sending or receiving packets. The 1749 correspondent node acknowledges invested effort based on the size of 1750 packets that the mobile node sends to the correspondent node or 1751 receives from the correspondent node. Invested effort is turned into 1752 credit. This credit is consumed by each packet that the 1753 correspondent node sends to an unconfirmed care-of address of the 1754 mobile node during the binding-update phase. The invoiced credit is 1755 such that a malicious node would have to invest more effort to misuse 1756 Early Binding Updates for a redirection-based flooding attack than it 1757 would have to invest for a conventional flooding attack. It stands 1758 to reason that this property will make the malicious node change its 1759 mind about misusing Early Binding Updates. 1761 9. Protocol Configuration Variables 1763 In this section, we recommend default values for the 1764 protocol-configuration variables used in this document. We believe 1765 that the proposed values are reasonable. A protocol implementer may 1766 choose different values nonetheless. 1768 CREDIT_AGING_FACTOR 0.5 1769 CREDIT_AGING_FACTOR 0.5 1770 EFFORT_QUENCH_FACTOR 0.5 1771 MAXIMUM_SPOT_CHECKS 15 1772 TENTATIVE_RR_BINDING_LIFETIME 3 seconds 1774 TENTATIVE_RR_BINDING_LIFETIME is originally defined in [2]. It is 1775 used as the length of a crediting interval in this document. When 1776 care-of-address spot checks are used, we propose a maximum of 1777 MAXIMUM_SPOT_CHECKS spot checks per crediting interval, i.e., at most 1778 one care-of-address spot check every 200 milliseconds. 1780 10. Acknowledgements 1782 The necessity for a mechanism to prevent or discourage misuse of 1783 Early Binding Updates for flooding attacks was sparked by a fruitful 1784 discussion on the MIP6 and MOBOPTS mailing lists. Credit-Based 1785 Authorization has been developed as a candidate solution, and a first 1786 presentation was given at the 59th IETF meeting. For their interest 1787 and valuable feedback, the authors thank the MIP6 and MOBOPTS 1788 communities, in particular Roland Bless, Mark Doll, Francis Dupont, 1789 Gregory Daley, Lars Eggert, James Kempf, Tobias Kuefner, Marco 1790 Liebsch, Gabriel Montenegro, Nick (Sharkey) Moore, Pekka Nikander, 1791 Erik Nordmark, Charles Perkins, and Kilian Weniger (listed in 1792 alphabetical order). Thanks are also due to Keiichi Shima and his 1793 colleagues from the Kame-Shisa development team. 1795 11. References 1797 11.1 Normative References 1799 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1800 IPv6", RFC 3775, June 2004. 1802 [2] Vogt, C., "Early Binding Updates for Mobile IPv6", 1803 Internet-Draft draft-vogt-mobopts-early-binding-updates (work in 1804 progress). 1806 11.2 Informative References 1808 [3] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. 1809 Nordmark, "Mobile IP version 6 Route Optimization Security 1810 Design Background", Internet-Draft draft-ietf-mip6-ro-sec (work 1811 in progress). 1813 [4] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location 1814 Management", In Proceedings of the 18th Annual Computer 1815 Security Applications Conference, Las Vegas, Nevada, USA., 1816 December 2002. 1818 [5] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 1819 Lifetime Extension", 1820 Internet-Draft draft-arkko-mipv6-binding-lifetime-extension 1821 (work in progress). 1823 [6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 1824 Denial of Service Attacks which employ IP Source Address 1825 Spoofing", RFC 2827, May 2000. 1827 [7] Paxson, V., "An Analysis of Using Reflectors for Distributed 1828 Denial-of-Service Attacks", Computer Communication Review 1829 31(3)., July 2001. 1831 [8] Anderson, R., "Why Information Security is Hard -- An Economic 1832 Perspective", In Proceedings of the 17th Annual Computer 1833 Security Applications Conference, New Orleans, Louisiana, USA., 1834 December 2001. 1836 [9] Perkins, C., "Precomputable Binding Management Key Kbm for 1837 Mobile IPv6", Internet-Draft draft-ietf-mip6-precfgkbm (work in 1838 progress). 1840 Authors' Addresses 1842 Christian Vogt (Editor and Contact Person) 1843 Institute of Telematics 1844 University of Karlsruhe (TH) 1845 P.O. Box 6980 1846 76128 Karlsruhe 1847 Germany 1849 Email: chvogt@tm.uka.de 1850 URI: http://www.tm.uka.de/~chvogt/ 1852 Jari Arkko 1853 Ericsson Research NomadicLab 1854 FI-02420 Jorvas 1855 Finland 1857 Email: jari.arkko@ericsson.com 1859 Intellectual Property Statement 1861 The IETF takes no position regarding the validity or scope of any 1862 Intellectual Property Rights or other rights that might be claimed to 1863 pertain to the implementation or use of the technology described in 1864 this document or the extent to which any license under such rights 1865 might or might not be available; nor does it represent that it has 1866 made any independent effort to identify any such rights. Information 1867 on the procedures with respect to rights in RFC documents can be 1868 found in BCP 78 and BCP 79. 1870 Copies of IPR disclosures made to the IETF Secretariat and any 1871 assurances of licenses to be made available, or the result of an 1872 attempt made to obtain a general license or permission for the use of 1873 such proprietary rights by implementers or users of this 1874 specification can be obtained from the IETF on-line IPR repository at 1875 http://www.ietf.org/ipr. 1877 The IETF invites any interested party to bring to its attention any 1878 copyrights, patents or patent applications, or other proprietary 1879 rights that may cover technology that may be required to implement 1880 this standard. Please address the information to the IETF at 1881 ietf-ipr@ietf.org. 1883 Disclaimer of Validity 1885 This document and the information contained herein are provided on an 1886 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1887 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1888 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1889 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1890 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1893 Copyright Statement 1895 Copyright (C) The Internet Society (2005). This document is subject 1896 to the rights, licenses and restrictions contained in BCP 78, and 1897 except as set forth therein, the authors retain all their rights. 1899 Acknowledgment 1901 Funding for the RFC Editor function is currently provided by the 1902 Internet Society.