idnits 2.17.1 draft-vogt-mobopts-simple-cba-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 320: '...rrespondent node MUST stop sending pac...' RFC 2119 keyword, line 321: '...rrespondent node MAY keep the unverifi...' RFC 2119 keyword, line 360: '... SHOULD increase that multi-addresse...' RFC 2119 keyword, line 415: '...f. Figure 3), it SHOULD send the packe...' RFC 2119 keyword, line 425: '...counter is too low, the packet MUST be...' 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, 2006) is 6618 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 659, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 694, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 699, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 717, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-04 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-02 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-03 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Vogt 3 Internet-Draft Universitaet Karlsruhe (TH) 4 Expires: August 18, 2006 J. Arkko 5 Ericsson Research NomadicLab 6 February 14, 2006 8 Credit-Based Authorization for Concurrent Reachability Verification 9 draft-vogt-mobopts-simple-cba-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Mobility and multi-homing protocols enable multi-addressed nodes to 43 redirect ongoing communication sessions from one IP address to 44 another. Most of these protocols verify a multi-addressed node's 45 reachability at a claimed new IP address in order to prevent 46 redirection-based flooding attacks. In view of reduced protocol 47 latencies, such verification is preferably performed concurrently, 48 i.e., while packets are already being sent to the new IP address. 50 This document defines Credit-Based Authorization, a technique that 51 facilitates concurrent reachability verification without compromise 52 of security. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Detailed Specification . . . . . . . . . . . . . . . . . . . . 7 60 4.1 IP Address States . . . . . . . . . . . . . . . . . . . . 7 61 4.2 Handling Payload Packets . . . . . . . . . . . . . . . . . 8 62 4.3 Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 5.1 Conventional Types of Flooding . . . . . . . . . . . . . . 12 65 5.2 Redirection-Based Flooding . . . . . . . . . . . . . . . . 13 66 5.3 Protection against Redirection-Based Flooding . . . . . . 13 67 5.4 Alternatives to Credit-Based Authorization . . . . . . . . 14 68 5.5 Alternatives to Credit Aging . . . . . . . . . . . . . . . 15 69 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 15 70 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 73 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 75 Intellectual Property and Copyright Statements . . . . . . . . 19 77 1. Introduction 79 Mobility and multi-homing protocols enable multi-addressed nodes to 80 redirect ongoing communication sessions from one IP address to 81 another, be it for the purpose of mobility support, recovery from a 82 failure upstream in the network, network renumbering, or a DHCP lease 83 expiry. Many of these protocols operate end to end, and it is a 84 multi-addressed node's responsibility to inform its correspondent 85 node(s) when it changes IP connectivity. 87 An undesired implication of end-to-end packet redirection is that, 88 when a correspondent node learns that a multi-addressed peer has a 89 new IP address, it does not necessarily know whether the peer is 90 actually reachable at that IP address. In fact, a malicious peer may 91 intentionally give a false IP address in order to cause a packet 92 flood on the victim located there [6]. Likewise, viral software may 93 have compromised the peer, programming it to redirect packets to a 94 specific victim. Such redirection-based flooding is particularly 95 serious due to its potential for high amplification: It is generally 96 sufficient for the attacker to spoof small acknowledgments so that 97 the correspondent node's instance of the transport protocol continues 98 to send larger data packets to the victim. Similar means for 99 amplification are today possible only through distributed denial-of- 100 service attacks. 102 Most mobility and multi-homing protocols mitigate the threat of 103 redirection-based flooding by checking a multi-addressed node's 104 reachability at a new IP address before data packets are sent to that 105 IP address. For this, the correspondent node sends an unguessable 106 number to the new IP address and waits for this number to be echoed 107 by the multi-addressed peer. In its basic form, reachability 108 verification requires the correspondent node to refrain from sending 109 packets to the new IP address until the multi-addressed node is known 110 to be present at that address. This causes undesired delays, 111 however, which have been shown [7] to compromise the quality of real- 112 time applications such as VoIP, video conferencing, and multi-player 113 games, and to cause adverse reactions of TCP's retransmission and 114 congestion-avoidance mechanisms. Concurrent reachability 115 verification has been proposed as an optimization, but additional 116 protection is necessary during the phase when packets are sent to a 117 new IP address while it is yet unverified. 119 This document specifies a mechanism, Credit-Based Authorization, that 120 facilitates secure and concurrent reachability verification. The 121 mechanism is fully transparent to the multi-addressed node. In 122 particular, it does not introduce any signaling between the peers. 124 2. Terminology 126 Multi-addressed node 127 A mobile or multi-homed node whoose IP address may change. 129 Correspondent node 130 A multi-addressed node's peer, which may itself be mobile or 131 multi-homed. 133 Mobility protocol 134 A protocol for mobility management executed between a mobile node 135 and a correspondent node. Examples are Mobile IPv6 [5] or the 136 mobility extensions [3] of the Host Identity Protocol [2]. 138 Multi-homing protocol 139 A protocol for multi-homing management executed between a multi- 140 homed node and a correspondent node. An example for a site multi- 141 homing protocol is the Level 3 Multihoming Shim protocol [4]. 143 Binding 144 The internal state at the correspondent node tying some form of 145 identity of a multi-addressed node to the IP address(es) that the 146 multi-addressed node uses at a particular time. 148 Binding update 149 The process of adding a new IP address to a binding or removing an 150 existing IP address from a binding. 152 Verified IP address 153 An IP address at which the multi-addressed node that claims the 154 address has been shown to be reachable. 156 Unverified IP address 157 An IP address for which no reachability verification has yet been 158 accomplished. 160 Credit 161 The number of bytes that a correspondent node has recently 162 received from a multi-addressed node. The correspondent node uses 163 the credit to determine how much data it can securely send to an 164 unverified IP address of the multi-addressed node. 166 Credit counter 167 A variable, maintained by the correspondent node, that shows a 168 particular multi-addressed node's current credit. 170 Credit aging 171 A function that gradually reduces a multi-addressed node's credit 172 over time. 174 Flooding attack 175 A variant of a denial-of-service attack that is characterized by a 176 victim being bombarded with unwanted packets at a rate that the 177 victim, and possibly the victim's access network, cannot handle. 179 Amplification 180 The ratio between the data volume that the victim of a flooding 181 attack is exposed to and the data volume that the attacker itself 182 generates. 184 3. Overview 186 Concurrent reachability verification requires protection against 187 spoofed unverified IP addresses and redirection-based flooding 188 attacks. Credit-Based Authorization is a technique that provides 189 such protection based on the following three hypotheses: 191 1. A flooding attacker typically seeks to somehow multiply the 192 packets it assembles for the purpose of the attack because 193 bandwidth is an ample resource for many attractive victims. 195 2. An attacker can always cause unamplified flooding by generating 196 bogus packets itself and sending them to its victim directly. 198 3. Consequently, the additional effort required to set up a 199 redirection-based flooding attack pays off for the attacker only 200 if amplification can be obtained this way. 202 On this basis, rather than eliminating malicious packet redirection 203 in the first place, Credit-Based Authorization prevents any 204 amplification that can be reached through it. This is accomplished 205 by limiting the data a correspondent node can send to an unverified 206 IP address of a multi-addressed peer by the data that the 207 correspondent node has recently received from that peer. A 208 redirection-based flooding attack thus becomes no more attractive 209 than pure direct flooding, where the attacker itself sends bogus 210 packets to the victim. It is actually less attractive given that the 211 attacker needs to maintain a context for mobility or multi-homing 212 management in order to coordinate the redirection. 214 multi-addressed node correspondent node 215 | | 216 | | 217 IP address |--data----------------->| credit += size(data) 218 verified | | 219 |--data----------------->| credit += size(data) 220 |<-----------------data--| don't change credit 221 | | 222 IP address + IP address changes | 223 unverified |<-----------------data--| credit -= size(data) 224 |--data----------------->| credit += size(data) 225 |<-----------------data--| credit -= size(data) 226 | | 227 |<-----------------data--| credit -= size(data) 228 | X credit < size(data) ==> drop! 229 | | 230 IP address | | 231 verified |<-----------------data--| don't change credit 232 | | 234 Figure 1: Credit Maintenance 236 Figure 1 illustrates the specifics of Credit-Based Authorization for 237 an exemplifying exchange of data packets: The correspondent node 238 measures the bytes received from the multi-addressed node. These 239 bytes are called the multi-addressed node's "credit" and are kept by 240 the correspondent node in a "credit counter". When the multi- 241 addressed node changes IP connectivity and registers a new IP 242 address, the correspondent node labels this address UNVERIFIED first. 243 Packets may be sent to an unverified IP address as long as the packet 244 sizes do not exceed the currently available credit. For each such 245 packet, the correspondent node reduces the credit counter by the 246 packet size. The multi-addressed node's reachability at the new IP 247 address is meanwhile verified. Once the verification concludes, the 248 correspondent node relabels the new IP address from UNVERIFIED to 249 VERIFIED. Packets can then be sent to the address without 250 restrictions. When insufficient credit is left while the IP address 251 is still in UNVERIFIED state, the correspondent node stops sending 252 further packets to the address until the verification completes. The 253 correspondent node may drop these packets or buffer them for later 254 transmission after the IP address has changed to VERIFIED state. 255 Figure 1 does not show signaling packets from a mobility or multi- 256 homing protocol. 258 The correspondent node ensures that the multi-addressed node's 259 acquired credit gradually decreases over time. This "credit aging" 260 prevents the multi-addressed node from building up credit over a long 261 time. A malicious node with a slow Internet connection could 262 otherwise provision for a burst of redirected packets which does not 263 relate to its own upstream capacity. 265 Credit-Based Authorization does not require support from the multi- 266 addressed node and does not introduce any signaling between the 267 peers. A faithful multi-addressed node, communicating with a 268 correspondent node in a typical manner, automatically earns credit 269 for sending packets to the correspondent node. It neither needs to 270 understand that Credit-Based Authorization is effective at the 271 correspondent node, nor does it have to have an idea of how much 272 credit it has at a particular point in time. 274 4. Detailed Specification 276 Credit-Based Authorization requires a correspondent node to store the 277 state of each multi-addressed node's IP address(es), maintain a 278 credit counter for each multi-addressed node, and execute an 279 exponential aging function on each credit counter. This is explained 280 in detail in the following. 282 4.1 IP Address States 284 Mobility and multi-homing protocols typically require a correspondent 285 node to bind a multi-addressed node's changing IP address to some 286 form of identity of the multi-addressed node. E.g., in Mobile IPv6 287 [5], this "binding" is between a mobile node's home address and 288 current care-of address. In the mobility extensions [3] of the Host 289 Identity Protocol [2], the multi-addressed node's current locators 290 are bound to a Host Identity Tag. Credit-Based Authorization in 291 addition requires the correspondent node to associate each IP address 292 with a state, VERIFIED or UNVERIFIED, in order to be able to 293 determine whether or not packets sent to the multi-addressed node's 294 current IP address are subject to credit limitations. 296 When a multi-addressed node changes its point of IP attachment and 297 configures a new IP address, a "binding update" is initiated in order 298 to inform the correspondent node of that new IP address. The new IP 299 address is initially set to UNVERIFIED state at the correspondent 300 node. The multi-addressed node may start to send packets from the 301 new IP address as soon as it has dispatched the signaling message(s) 302 that the mobility or multi-homing protocol provides for the binding 303 update. However, packets that the correspondent node may sent to an 304 IP address in UNVERIFIED state are subject to the limitations 305 specified in Section 4.2. 307 At some time after the multi-addressed node has sent the signaling 308 message(s) for the binding update, the mobility or multi-homing 309 protocol initiates reachability verification for the new IP address 310 and conveys the result to the correspondent node. 312 If reachability verification confirms that the multi-addressed node 313 is present at the new IP address, the correspondent node changes the 314 state of this address from UNVERIFIED to VERIFIED. Any limits 315 imposed on packets that the correspondent node sends to the new IP 316 address do no longer apply as of then. 318 If the outcome of reachability verification is that the multi- 319 addressed node is not reachable at the new IP address, the 320 correspondent node MUST stop sending packets to that IP address. 321 However, the correspondent node MAY keep the unverified IP address 322 within the binding and continue to accept packets that the multi- 323 addressed node sends from the IP address. This is reasonable given 324 that reachability verification may fail for reasons outside the 325 influence of the multi-addressed node, e.g., due to packet loss on 326 the path between the multi-addressed node and the correspondent node. 327 It is the responsibility of the mobility or multi-homing protocol to 328 repeat reachability verification an appropriate number of times in 329 case of failure. 331 4.2 Handling Payload Packets 333 A correspondent node maintains a credit counter for each multi- 334 addressed node it communicates with. All IP addresses within a 335 binding, both verified and unverified ones, map to the same credit 336 counter. New credit counters are initialized to zero. 338 inbound ___________________ 339 packet | | 340 | | locate peer's | 341 '----> | binding and | 342 | credit counter | 343 '___________________' 344 | 345 | 346 | 347 v 348 ___________________ ___________________ 349 | | | | 350 | increase | | deliver packet | 351 | credit counter |------------> | to application | 352 | by packet size | | | 353 '___________________' '___________________' 355 Figure 2: Inbound Packet Handling 357 When the correspondent node receives a packet from a multi-addressed 358 node (cf. Figure 2), and the packet's IPv6 Source Address is 359 currently bound to the multi-addressed node, the correspondent node 360 SHOULD increase that multi-addressed node's credit counter by the 361 size of the received packet. In particular, it does not matter 362 whether the state of the packet's IPv6 Source Address is VERIFIED or 363 UNVERIFIED. 365 outbound ___________________ 366 packet | | 367 | | locate peer's | 368 '----> | binding and | 369 | credit counter | 370 '___________________' 371 | 372 | 373 | 374 v 375 _______________ ___________________ 376 / \ | | 377 / IP address in \ yes | send packet | 378 | VERIFIED state |-----------> | to IP address in | 379 \ exists? / | VERIFIED state | 380 \_______________/ '___________________' 381 | 382 | no 383 | 384 v 385 _______________ ___________________ 386 / \ | | 387 / IP address in \ no | drop or buffer | 388 | UNVERIFIED state |-----------> | the packet | 389 \ exists? / | | 390 \_______________/ '___________________' 391 | 392 | yes 393 | 394 v 395 _______________ ___________________ 396 / \ | | 397 / credit counter \ no | drop or buffer | 398 | >= |-----------> | the packet | 399 \ packet size? / | | 400 \_______________/ '___________________' 401 | 402 | yes 403 | 404 v 405 ___________________ ___________________ 406 | | | | 407 | reduce | | send packet | 408 | credit counter |------------> | to IP address in | 409 | by packet size | | UNVERIFIED state | 410 '___________________' '___________________' 412 Figure 3: Outbound Packet Handling 414 When the correspondent node has a packet for the multi-addressed node 415 (cf. Figure 3), it SHOULD send the packet to an IP address in 416 VERIFIED state if such an address exists in the multi-addressed 417 node's binding. In case no IP address currently bound to the multi- 418 addressed node is in VERIFIED state, the correspondent node selects 419 an IP address in UNVERIFIED state provided that such an address is 420 available. If an unverified IP address exists, the correspondent 421 node checks to see whether it can send the packet to that address: 422 In case the value of the credit counter is higher than the size of 423 the packet or equal to it, the correspondent node reduces the credit 424 counter by the packet size and sends the packet to the unverified IP 425 address. If the credit counter is too low, the packet MUST be 426 discarded or buffered until reachability verification succeeds. 427 Should the mobility or multi-homing protocol support a stable IP 428 address via which the multi-addressed node is permanently reachable, 429 possibly through a sub-optimal routing path, the correspondent node 430 may also send the packets to that stable IP address until the multi- 431 addressed node becomes again directly reachable through a verified IP 432 address. A Mobile IPv6 home address is an example of such a stable 433 IP address. 435 4.3 Credit Aging 437 The correspondent node ensures that all credit counters maintained 438 for its multi-addressed peers gradually decrease over time. For 439 this, it multiplies each credit counter with a factor, 440 CreditAgingFactor, of less than one in fixed time intervals of 441 CreditAgingInterval length. Such credit aging prevents a malicious 442 peer with poor uplink capacity from building up credit at a very slow 443 speed and using this, all at once, for a burst of redirected packets. 444 At the same time, credit aging naturally limits the rate at which the 445 correspondent node can durably sent to an IP address in UNVERIFIED 446 state. 448 Choosing appropriate values for CreditAgingFactor and 449 CreditAgingInterval is important to facilitate applications where the 450 correspondent node sends at a higher rate than the multi-addressed 451 node. If CreditAgingFactor or CreditAgingInterval are too small, the 452 credit counter might be too low to allow for packets being sent to an 453 unverified IP address. The values specified in this document work 454 well when the host transfers a file to the peer via a TCP connection 455 and the end-to-end round-trip time does not exeed 500 milliseconds. 457 5. Security Considerations 459 Essentially three types of flooding attacks are already possible in 460 today's Internet: direct attacks, reflection attacks, and 461 distributed attacks. The following analysis compares these attack 462 types with those that could become possible by the introduction of 463 mobility and multi-homing support if no preventive measures are 464 taken. The power of a flooding attack is thereby measured by its 465 potential for amplification. It is shown that the new attack types 466 would facilitate much higher amplification than conventional attack 467 types, and that a combination of concurrent reachability verification 468 and Credit-Based Authorization can neutralize this disadvantage. 470 5.1 Conventional Types of Flooding 472 In a direct flooding attack, the attacker simply generates the 473 flooding packets and sends them to the victim by itself. Direct 474 flooding attacks are an inherent vulnerability of the Internet 475 architecture given that the routing infrastructure delivers packets 476 independently of whether they have actually been requested by the 477 recipient. Firewalls mitigate the issue to some extent in that they 478 block undesired traffic at some point close to the end of the routing 479 path. The flooding packets are thus screened from a victim node. On 480 the other hand, the flooding packets may still exhaust downstream 481 capacities of an entire network. Firewalls are generally unsuitable 482 to prevent this. Inverse firewalls at the attacker's side screen the 483 undesired traffic close to the source, but most likely an attacker 484 can choose a location where inverse firewalling is not performed. 486 In an indirect reflection attack, the attacker tricks a third node, 487 the reflection point, into sending packets to the victim. The 488 attacker typically uses a known protocol vulnerability to make the 489 reflection point generate these packets [12]. One example is that 490 the attacker sends ICMP Echo Request packets, with the IPv6 Source 491 Address fields set to the victim's IP address, to the reflection 492 point. The reflection point, in turn, sends ICMP Echo Reply packets 493 "back" to the victim. Another example is that the attacker sends TCP 494 SYN packets, again with false source addresses, to the reflection 495 point, which in turn sends TCP SYN-ACK packets to someone who does 496 not expect these packets. Since most TCP servers are configured so 497 that they resend a TCP SYN packet multiple times when failing to 498 receive an acknowledgment, this reflection attack can even produce 499 small amplification. As the examples show, reflection attacks are 500 generally characterized by the attacker sending packets with spoofed 501 IPv6 Source Address fields. The amplification possible through 502 reflection is generally rather limited, however, since most protocols 503 refrain from sending large amounts of data to an address before some 504 assurance has been obtained that there is indeed a node willing to 505 accept packets at the other end. 507 Distributed flooding attacks provide more significant amplification. 508 Here, the attacker takes over control of other nodes by compromising 509 them with viral software, which it typically distributes by 510 conventional means. The infected nodes are then programmed to 511 jointly send packets to the victim. Typically, the attack proceeds 512 automatically, and the attacker itself does not send itself packets 513 to the victim. Distributed flooding attacks are of a different 514 quality than the flooding attacks described afore because they 515 generally exploit implementation vulnerabilities in operating systems 516 rather than vulnerabilities in standard networking protocols. 518 5.2 Redirection-Based Flooding 520 Redirection-based flooding attacks are a fourth attack type, which 521 mobility and multi-homing protocols could introduce if they fail to 522 provide appropriate protection. In such an attack, the perpetrator 523 requests a server to transmit a large file, e.g., a video, and 524 subsequently misuses a mobility or multi-homing protocol to redirect 525 this download to the IP address of its victim. The transport 526 protocol may require the attacker to spoof acknowledgment on behalf 527 of the victim. But since the acknowledgments are typically smaller 528 in size and number than the data packets that the server generates, 529 the amplification in this attack can be much higher than in the 530 discussed ICMP and TCP flooding attacks. 532 Today's transport protocols were developed for an Internet where 533 nodes use stable IP addresses, hence most of them perform 534 reachability verification, if at all, only at some early stage during 535 connection establishment. E.g., TCP requires the receiver to obtain 536 a random 32-bit sequence number during the initial handshake. 537 Mobility and multi-homing protocols defeat the purpose of such 538 reachability verification as they introduce the ability to redirect 539 packets subsequently to the initial handshake. Referring to the 540 example of the TCP download, the attacker could execute the initial 541 handshake procedure via its own IP address, and use the sequence 542 number obtained that way to spoof acknowledgments after it has 543 redirected the session to the IP address of its victim. 545 5.3 Protection against Redirection-Based Flooding 547 Most mobility and multi-homing protocols execute an IP-layer 548 reachability check as a protection against redirection-based flooding 549 whenever a node changes its IP address. Given that the delay of such 550 a check can have a noticable impact on applications, a 551 straightforward strategy is to execute reachability verification 552 concurrently while packets are already being sent to the new IP 553 address. This requires additional protection for the phase during 554 which packets are sent to the new IP address although the validity of 555 that IP address is still questionable. Credit-Based Authorization 556 provides this protection in that it limits the impact of such 557 redirection to what could also be accomplished---with much less 558 coordinative effort---through a direct flooding attack. 559 Specifically, the combination of concurrent reachability verification 560 and Credit-Based Authorization does not prevent malicious redirection 561 per se, but it prevents its use from a location off the path towards 562 the flooded victim as well as any amplification in the quantity of 563 redirected packets. As a result, a redirection-based flooding attack 564 becomes as effective as a direct flooding attack. 566 5.4 Alternatives to Credit-Based Authorization 568 There are alternatives to Credit-Based Authorization which can 569 protect against misuse of mobility or multi-homing protocols for 570 redirection-based flooding attacks. One alternative is to perform 571 reachability verification in a concurrent way only with nodes from a 572 trusted community. Mobility and multi-homing protocols usually 573 authenticate a node during a binding update, providing a way for 574 secure identification. The correspondent node can thus decide 575 whether or not to use the new IP address before the result of 576 reachability verification becomes known. For instance, the 577 correspondent node may be a corporate server which grants concurrent 578 reachability verification exlusively to nodes from the corporate 579 network. 581 Mobility and multi-homing protocols that use the IPv6 Source Address 582 field to signal a new IP address to the correspondent node may rely 583 on ingress filtering [11] to be enforced within the multi-addressed 584 nodes' networks. Ingress filtering is a function that routers may 585 execute to prevent packets with spoofed source addresses from leaving 586 a network. The natural crux with ingress filtering, however, is that 587 the correspondent node in general does not know whether or not 588 ingress filtering has been performed on packets received from a 589 particular multi-addressed node. Furthermore, the granularity of 590 ingress filtering decreases with the distance between the access 591 network and the router that executes it. In an optimal case, ingress 592 filtering is directly applied in the first-hop router. But even then 593 may an attacker use a false IPv6 Source Address as long as the 594 network prefix is correct. 596 A third alternative to Credit-Based Authorization is to identify and 597 blacklist malicious nodes based on their observed behavior. Credit- 598 Based Authorization is a proactive strategy, whereas behavior-based 599 blacklisting is a reactive one. The advantage of a reactive approach 600 is that a faithful multi-addressed node does not need to invest 601 effort (i.e., collect credit) in order to be able to receive packets 602 at an unverified IP address. This can accommodate a multi-addressed 603 node having trouble to collect sufficient credit---be it because its 604 IP address changes too frequently, or because its application 605 generates too little data. On the other hand, a reactive approach by 606 definition fails to prevent misuse of concurrent reachability 607 verification in advance. What it can do is contain the damage of 608 such misuse and punish the perpetrator. Punishment depends on an 609 administrative relationship between the multi-addressed node and the 610 correspondent node, however, and such a relationship may not exist. 611 finally, behavior-based blacklisting requires a heuristic to 612 determine what behavior is considered "ill". Yet choosing the right 613 heuristic is far from trivial. An inappropriate heuristic may punish 614 a faithful mobile node or overlook an evil one. 616 5.5 Alternatives to Credit Aging 618 Credit-Based Authorization uses exponential aging to slowly reduce 619 collected credit over time. An alternative to exponential aging 620 would be a constant upper bound on the credit. However, such a limit 621 would allow an attacker to acquire credit at a very slow speed, 622 possibly through a slow Internet connection, and to use this credit 623 quickly for a burst of packets redirected to a victim. Collected 624 credit may also be kept for a long time before it is eventually used. 625 This would allow the attacker to build up credit at multiple 626 correspondent nodes one after another. Finally, a constant limit 627 would be insensitive to throughput conditions on the path between the 628 multi-addressed node and the correspondent node. A limit for a low- 629 bandwidth connection is certainly inappropriate for a high-bandwidth 630 connection, and vice versa. Exponential aging does not have these 631 disadvantages and was thus considered a more appropriate approach 632 than limiting a mobile node's credit by a constant upper bound. 634 6. Protocol Constants 636 CreditAgingFactor 7/8 637 CreditAgingInterval 5 seconds 639 7. Acknowledgment 641 The necessity for a mechanism to prevent or discourage misuse of 642 concurrent reachability verification for amplified redirection-based 643 flooding attacks was sparked by a fruitful discussion on the MIP6 and 644 MOBOPTS mailing lists. Credit-Based Authorization was developed as a 645 candidate solution, and a first presentation was given at the 59th 646 IETF meeting in Seoul, Republic of Korea. For their interest and 647 valuable feedback, the authors thank the MIP6 and MOBOPTS 648 communities, in particular Roland Bless, Mark Doll, Francis Dupont, 649 Gregory Daley, Lars Eggert, James Kempf, Rajeev Koodli, Tobias 650 Kuefner, Marco Liebsch, Gabriel Montenegro, Nick (Sharkey) Moore, 651 Pekka Nikander, Erik Nordmark, Charles Perkins, and Kilian Weniger 652 (listed in alphabetical order). Thanks are also due to the 653 development team of the Kame-Shisa Mobile IPv6 implementation. 655 8. References 657 8.1 Normative References 659 [1] Vogt, C., "Early Binding Updates for Mobile IPv6", 660 draft-vogt-mobopts-early-binding-updates (work in progress) 661 (work in progress). 663 8.2 Informative References 665 [2] Moskowitz, R., Nikander, P., Jokela, P., and T. R., "Host 666 Identity Protocol", IETF Internet Draft 667 draft-ietf-hip-base-04.txt (work in progress), October 2005. 669 [3] Henderson, T., "End-Host Mobility and Multihoming with the Host 670 Identity Protocol", IETF Internet Draft 671 draft-ietf-hip-mm-02.txt (work in progress), July 2005. 673 [4] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 674 protocol", IETF Internet Draft draft-ietf-shim6-proto-03.txt 675 (work in progress), December 2005. 677 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 678 IPv6", RFC 3775, June 2004. 680 [6] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 681 Nordmark, "Mobile IP Version 6 Route Optimization Security 682 Design Background", IETF Request for Comments 4225, 683 December 2005. 685 [7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in 686 IPv6", To appear in the proceedings of the IEEE Wireless 687 Communications and Networking Conference, IEEE, April 2006. 689 [8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 690 Nordmark, "Mobile IP version 6 Route Optimization Security 691 Design Background", draft-ietf-mip6-ro-sec (work in progress) 692 (work in progress). 694 [9] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location 695 Management", In Proceedings of the 18th Annual Computer 696 Security Applications Conference, Las Vegas, Nevada, USA., 697 December 2002. 699 [10] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 700 Lifetime Extension", 701 draft-arkko-mipv6-binding-lifetime-extension (work in progress) 702 (work in progress). 704 [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: 705 Defeating Denial of Service Attacks which employ IP Source 706 Address Spoofing", RFC 2827, May 2000. 708 [12] Paxson, V., "An Analysis of Using Reflectors for Distributed 709 Denial-of-Service Attacks", Computer Communication Review 710 31(3)., July 2001. 712 [13] Anderson, R., "Why Information Security is Hard -- An Economic 713 Perspective", In Proceedings of the 17th Annual Computer 714 Security Applications Conference, New Orleans, Louisiana, USA., 715 December 2001. 717 [14] Perkins, C., "Precomputable Binding Management Key Kbm for 718 Mobile IPv6", draft-ietf-mip6-precfgkbm (work in progress) 719 (work in progress). 721 Authors' Addresses 723 Christian Vogt 724 Institute of Telematics 725 Universitaet Karlsruhe (TH) 726 P.O. Box 6980 727 76128 Karlsruhe 728 Germany 730 Email: chvogt@tm.uka.de 731 Jari Arkko 732 Ericsson Research NomadicLab 733 FI-02420 Jorvas 734 Finland 736 Email: jari.arkko@ericsson.com 738 Intellectual Property Statement 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; nor does it represent that it has 745 made any independent effort to identify any such rights. Information 746 on the procedures with respect to rights in RFC documents can be 747 found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use of 752 such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at 760 ietf-ipr@ietf.org. 762 Disclaimer of Validity 764 This document and the information contained herein are provided on an 765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 767 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 768 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 769 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 772 Copyright Statement 774 Copyright (C) The Internet Society (2006). This document is subject 775 to the rights, licenses and restrictions contained in BCP 78, and 776 except as set forth therein, the authors retain all their rights. 778 Acknowledgment 780 Funding for the RFC Editor function is currently provided by the 781 Internet Society.