Network Working Group C. Vogt Internet-Draft Universitaet Karlsruhe (TH) Expires: August 18, 2006 J. Arkko Ericsson Research NomadicLab February 14, 2006 Credit-Based Authorization for Concurrent Reachability Verification draft-vogt-mobopts-simple-cba-00.txt Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 18, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Mobility and multi-homing protocols enable multi-addressed nodes to redirect ongoing communication sessions from one IP address to another. Most of these protocols verify a multi-addressed node's reachability at a claimed new IP address in order to prevent redirection-based flooding attacks. In view of reduced protocol latencies, such verification is preferably performed concurrently, i.e., while packets are already being sent to the new IP address. Vogt & Arkko Expires August 18, 2006 [Page 1] Internet-Draft Credit-Based Authorization February 2006 This document defines Credit-Based Authorization, a technique that facilitates concurrent reachability verification without compromise of security. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Detailed Specification . . . . . . . . . . . . . . . . . . . . 7 4.1 IP Address States . . . . . . . . . . . . . . . . . . . . 7 4.2 Handling Payload Packets . . . . . . . . . . . . . . . . . 8 4.3 Credit Aging . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5.1 Conventional Types of Flooding . . . . . . . . . . . . . . 12 5.2 Redirection-Based Flooding . . . . . . . . . . . . . . . . 13 5.3 Protection against Redirection-Based Flooding . . . . . . 13 5.4 Alternatives to Credit-Based Authorization . . . . . . . . 14 5.5 Alternatives to Credit Aging . . . . . . . . . . . . . . . 15 6. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 19 Vogt & Arkko Expires August 18, 2006 [Page 2] Internet-Draft Credit-Based Authorization February 2006 1. Introduction Mobility and multi-homing protocols enable multi-addressed nodes to redirect ongoing communication sessions from one IP address to another, be it for the purpose of mobility support, recovery from a failure upstream in the network, network renumbering, or a DHCP lease expiry. Many of these protocols operate end to end, and it is a multi-addressed node's responsibility to inform its correspondent node(s) when it changes IP connectivity. An undesired implication of end-to-end packet redirection is that, when a correspondent node learns that a multi-addressed peer has a new IP address, it does not necessarily know whether the peer is actually reachable at that IP address. In fact, a malicious peer may intentionally give a false IP address in order to cause a packet flood on the victim located there [6]. Likewise, viral software may have compromised the peer, programming it to redirect packets to a specific victim. Such redirection-based flooding is particularly serious due to its potential for high amplification: It is generally sufficient for the attacker to spoof small acknowledgments so that the correspondent node's instance of the transport protocol continues to send larger data packets to the victim. Similar means for amplification are today possible only through distributed denial-of- service attacks. Most mobility and multi-homing protocols mitigate the threat of redirection-based flooding by checking a multi-addressed node's reachability at a new IP address before data packets are sent to that IP address. For this, the correspondent node sends an unguessable number to the new IP address and waits for this number to be echoed by the multi-addressed peer. In its basic form, reachability verification requires the correspondent node to refrain from sending packets to the new IP address until the multi-addressed node is known to be present at that address. This causes undesired delays, however, which have been shown [7] to compromise the quality of real- time applications such as VoIP, video conferencing, and multi-player games, and to cause adverse reactions of TCP's retransmission and congestion-avoidance mechanisms. Concurrent reachability verification has been proposed as an optimization, but additional protection is necessary during the phase when packets are sent to a new IP address while it is yet unverified. This document specifies a mechanism, Credit-Based Authorization, that facilitates secure and concurrent reachability verification. The mechanism is fully transparent to the multi-addressed node. In particular, it does not introduce any signaling between the peers. Vogt & Arkko Expires August 18, 2006 [Page 3] Internet-Draft Credit-Based Authorization February 2006 2. Terminology Multi-addressed node A mobile or multi-homed node whoose IP address may change. Correspondent node A multi-addressed node's peer, which may itself be mobile or multi-homed. Mobility protocol A protocol for mobility management executed between a mobile node and a correspondent node. Examples are Mobile IPv6 [5] or the mobility extensions [3] of the Host Identity Protocol [2]. Multi-homing protocol A protocol for multi-homing management executed between a multi- homed node and a correspondent node. An example for a site multi- homing protocol is the Level 3 Multihoming Shim protocol [4]. Binding The internal state at the correspondent node tying some form of identity of a multi-addressed node to the IP address(es) that the multi-addressed node uses at a particular time. Binding update The process of adding a new IP address to a binding or removing an existing IP address from a binding. Verified IP address An IP address at which the multi-addressed node that claims the address has been shown to be reachable. Unverified IP address An IP address for which no reachability verification has yet been accomplished. Credit The number of bytes that a correspondent node has recently received from a multi-addressed node. The correspondent node uses the credit to determine how much data it can securely send to an unverified IP address of the multi-addressed node. Credit counter A variable, maintained by the correspondent node, that shows a particular multi-addressed node's current credit. Credit aging Vogt & Arkko Expires August 18, 2006 [Page 4] Internet-Draft Credit-Based Authorization February 2006 A function that gradually reduces a multi-addressed node's credit over time. Flooding attack A variant of a denial-of-service attack that is characterized by a victim being bombarded with unwanted packets at a rate that the victim, and possibly the victim's access network, cannot handle. Amplification The ratio between the data volume that the victim of a flooding attack is exposed to and the data volume that the attacker itself generates. 3. Overview Concurrent reachability verification requires protection against spoofed unverified IP addresses and redirection-based flooding attacks. Credit-Based Authorization is a technique that provides such protection based on the following three hypotheses: 1. A flooding attacker typically seeks to somehow multiply the packets it assembles for the purpose of the attack because bandwidth is an ample resource for many attractive victims. 2. An attacker can always cause unamplified flooding by generating bogus packets itself and sending them to its victim directly. 3. Consequently, the additional effort required to set up a redirection-based flooding attack pays off for the attacker only if amplification can be obtained this way. On this basis, rather than eliminating malicious packet redirection in the first place, Credit-Based Authorization prevents any amplification that can be reached through it. This is accomplished by limiting the data a correspondent node can send to an unverified IP address of a multi-addressed peer by the data that the correspondent node has recently received from that peer. A redirection-based flooding attack thus becomes no more attractive than pure direct flooding, where the attacker itself sends bogus packets to the victim. It is actually less attractive given that the attacker needs to maintain a context for mobility or multi-homing management in order to coordinate the redirection. Vogt & Arkko Expires August 18, 2006 [Page 5] Internet-Draft Credit-Based Authorization February 2006 multi-addressed node correspondent node | | | | IP address |--data----------------->| credit += size(data) verified | | |--data----------------->| credit += size(data) |<-----------------data--| don't change credit | | IP address + IP address changes | unverified |<-----------------data--| credit -= size(data) |--data----------------->| credit += size(data) |<-----------------data--| credit -= size(data) | | |<-----------------data--| credit -= size(data) | X credit < size(data) ==> drop! | | IP address | | verified |<-----------------data--| don't change credit | | Figure 1: Credit Maintenance Figure 1 illustrates the specifics of Credit-Based Authorization for an exemplifying exchange of data packets: The correspondent node measures the bytes received from the multi-addressed node. These bytes are called the multi-addressed node's "credit" and are kept by the correspondent node in a "credit counter". When the multi- addressed node changes IP connectivity and registers a new IP address, the correspondent node labels this address UNVERIFIED first. Packets may be sent to an unverified IP address as long as the packet sizes do not exceed the currently available credit. For each such packet, the correspondent node reduces the credit counter by the packet size. The multi-addressed node's reachability at the new IP address is meanwhile verified. Once the verification concludes, the correspondent node relabels the new IP address from UNVERIFIED to VERIFIED. Packets can then be sent to the address without restrictions. When insufficient credit is left while the IP address is still in UNVERIFIED state, the correspondent node stops sending further packets to the address until the verification completes. The correspondent node may drop these packets or buffer them for later transmission after the IP address has changed to VERIFIED state. Figure 1 does not show signaling packets from a mobility or multi- homing protocol. The correspondent node ensures that the multi-addressed node's acquired credit gradually decreases over time. This "credit aging" prevents the multi-addressed node from building up credit over a long time. A malicious node with a slow Internet connection could Vogt & Arkko Expires August 18, 2006 [Page 6] Internet-Draft Credit-Based Authorization February 2006 otherwise provision for a burst of redirected packets which does not relate to its own upstream capacity. Credit-Based Authorization does not require support from the multi- addressed node and does not introduce any signaling between the peers. A faithful multi-addressed node, communicating with a correspondent node in a typical manner, automatically earns credit for sending packets to the correspondent node. It neither needs to understand that Credit-Based Authorization is effective at the correspondent node, nor does it have to have an idea of how much credit it has at a particular point in time. 4. Detailed Specification Credit-Based Authorization requires a correspondent node to store the state of each multi-addressed node's IP address(es), maintain a credit counter for each multi-addressed node, and execute an exponential aging function on each credit counter. This is explained in detail in the following. 4.1 IP Address States Mobility and multi-homing protocols typically require a correspondent node to bind a multi-addressed node's changing IP address to some form of identity of the multi-addressed node. E.g., in Mobile IPv6 [5], this "binding" is between a mobile node's home address and current care-of address. In the mobility extensions [3] of the Host Identity Protocol [2], the multi-addressed node's current locators are bound to a Host Identity Tag. Credit-Based Authorization in addition requires the correspondent node to associate each IP address with a state, VERIFIED or UNVERIFIED, in order to be able to determine whether or not packets sent to the multi-addressed node's current IP address are subject to credit limitations. When a multi-addressed node changes its point of IP attachment and configures a new IP address, a "binding update" is initiated in order to inform the correspondent node of that new IP address. The new IP address is initially set to UNVERIFIED state at the correspondent node. The multi-addressed node may start to send packets from the new IP address as soon as it has dispatched the signaling message(s) that the mobility or multi-homing protocol provides for the binding update. However, packets that the correspondent node may sent to an IP address in UNVERIFIED state are subject to the limitations specified in Section 4.2. Vogt & Arkko Expires August 18, 2006 [Page 7] Internet-Draft Credit-Based Authorization February 2006 At some time after the multi-addressed node has sent the signaling message(s) for the binding update, the mobility or multi-homing protocol initiates reachability verification for the new IP address and conveys the result to the correspondent node. If reachability verification confirms that the multi-addressed node is present at the new IP address, the correspondent node changes the state of this address from UNVERIFIED to VERIFIED. Any limits imposed on packets that the correspondent node sends to the new IP address do no longer apply as of then. If the outcome of reachability verification is that the multi- addressed node is not reachable at the new IP address, the correspondent node MUST stop sending packets to that IP address. However, the correspondent node MAY keep the unverified IP address within the binding and continue to accept packets that the multi- addressed node sends from the IP address. This is reasonable given that reachability verification may fail for reasons outside the influence of the multi-addressed node, e.g., due to packet loss on the path between the multi-addressed node and the correspondent node. It is the responsibility of the mobility or multi-homing protocol to repeat reachability verification an appropriate number of times in case of failure. 4.2 Handling Payload Packets A correspondent node maintains a credit counter for each multi- addressed node it communicates with. All IP addresses within a binding, both verified and unverified ones, map to the same credit counter. New credit counters are initialized to zero. Vogt & Arkko Expires August 18, 2006 [Page 8] Internet-Draft Credit-Based Authorization February 2006 inbound ___________________ packet | | | | locate peer's | '----> | binding and | | credit counter | '___________________' | | | v ___________________ ___________________ | | | | | increase | | deliver packet | | credit counter |------------> | to application | | by packet size | | | '___________________' '___________________' Figure 2: Inbound Packet Handling When the correspondent node receives a packet from a multi-addressed node (cf. Figure 2), and the packet's IPv6 Source Address is currently bound to the multi-addressed node, the correspondent node SHOULD increase that multi-addressed node's credit counter by the size of the received packet. In particular, it does not matter whether the state of the packet's IPv6 Source Address is VERIFIED or UNVERIFIED. Vogt & Arkko Expires August 18, 2006 [Page 9] Internet-Draft Credit-Based Authorization February 2006 outbound ___________________ packet | | | | locate peer's | '----> | binding and | | credit counter | '___________________' | | | v _______________ ___________________ / \ | | / IP address in \ yes | send packet | | VERIFIED state |-----------> | to IP address in | \ exists? / | VERIFIED state | \_______________/ '___________________' | | no | v _______________ ___________________ / \ | | / IP address in \ no | drop or buffer | | UNVERIFIED state |-----------> | the packet | \ exists? / | | \_______________/ '___________________' | | yes | v _______________ ___________________ / \ | | / credit counter \ no | drop or buffer | | >= |-----------> | the packet | \ packet size? / | | \_______________/ '___________________' | | yes | v ___________________ ___________________ | | | | | reduce | | send packet | | credit counter |------------> | to IP address in | | by packet size | | UNVERIFIED state | '___________________' '___________________' Figure 3: Outbound Packet Handling Vogt & Arkko Expires August 18, 2006 [Page 10] Internet-Draft Credit-Based Authorization February 2006 When the correspondent node has a packet for the multi-addressed node (cf. Figure 3), it SHOULD send the packet to an IP address in VERIFIED state if such an address exists in the multi-addressed node's binding. In case no IP address currently bound to the multi- addressed node is in VERIFIED state, the correspondent node selects an IP address in UNVERIFIED state provided that such an address is available. If an unverified IP address exists, the correspondent node checks to see whether it can send the packet to that address: In case the value of the credit counter is higher than the size of the packet or equal to it, the correspondent node reduces the credit counter by the packet size and sends the packet to the unverified IP address. If the credit counter is too low, the packet MUST be discarded or buffered until reachability verification succeeds. Should the mobility or multi-homing protocol support a stable IP address via which the multi-addressed node is permanently reachable, possibly through a sub-optimal routing path, the correspondent node may also send the packets to that stable IP address until the multi- addressed node becomes again directly reachable through a verified IP address. A Mobile IPv6 home address is an example of such a stable IP address. 4.3 Credit Aging The correspondent node ensures that all credit counters maintained for its multi-addressed peers gradually decrease over time. For this, it multiplies each credit counter with a factor, CreditAgingFactor, of less than one in fixed time intervals of CreditAgingInterval length. Such credit aging prevents a malicious peer with poor uplink capacity from building up credit at a very slow speed and using this, all at once, for a burst of redirected packets. At the same time, credit aging naturally limits the rate at which the correspondent node can durably sent to an IP address in UNVERIFIED state. Choosing appropriate values for CreditAgingFactor and CreditAgingInterval is important to facilitate applications where the correspondent node sends at a higher rate than the multi-addressed node. If CreditAgingFactor or CreditAgingInterval are too small, the credit counter might be too low to allow for packets being sent to an unverified IP address. The values specified in this document work well when the host transfers a file to the peer via a TCP connection and the end-to-end round-trip time does not exeed 500 milliseconds. Vogt & Arkko Expires August 18, 2006 [Page 11] Internet-Draft Credit-Based Authorization February 2006 5. Security Considerations Essentially three types of flooding attacks are already possible in today's Internet: direct attacks, reflection attacks, and distributed attacks. The following analysis compares these attack types with those that could become possible by the introduction of mobility and multi-homing support if no preventive measures are taken. The power of a flooding attack is thereby measured by its potential for amplification. It is shown that the new attack types would facilitate much higher amplification than conventional attack types, and that a combination of concurrent reachability verification and Credit-Based Authorization can neutralize this disadvantage. 5.1 Conventional Types of Flooding In a direct flooding attack, the attacker simply generates the flooding packets and sends them to the victim by itself. Direct flooding attacks are an inherent vulnerability of the Internet architecture given that the routing infrastructure delivers packets independently of whether they have actually been requested by the recipient. Firewalls mitigate the issue to some extent in that they block undesired traffic at some point close to the end of the routing path. The flooding packets are thus screened from a victim node. On the other hand, the flooding packets may still exhaust downstream capacities of an entire network. Firewalls are generally unsuitable to prevent this. Inverse firewalls at the attacker's side screen the undesired traffic close to the source, but most likely an attacker can choose a location where inverse firewalling is not performed. In an indirect reflection attack, the attacker tricks a third node, the reflection point, into sending packets to the victim. The attacker typically uses a known protocol vulnerability to make the reflection point generate these packets [12]. One example is that the attacker sends ICMP Echo Request packets, with the IPv6 Source Address fields set to the victim's IP address, to the reflection point. The reflection point, in turn, sends ICMP Echo Reply packets "back" to the victim. Another example is that the attacker sends TCP SYN packets, again with false source addresses, to the reflection point, which in turn sends TCP SYN-ACK packets to someone who does not expect these packets. Since most TCP servers are configured so that they resend a TCP SYN packet multiple times when failing to receive an acknowledgment, this reflection attack can even produce small amplification. As the examples show, reflection attacks are generally characterized by the attacker sending packets with spoofed IPv6 Source Address fields. The amplification possible through reflection is generally rather limited, however, since most protocols refrain from sending large amounts of data to an address before some Vogt & Arkko Expires August 18, 2006 [Page 12] Internet-Draft Credit-Based Authorization February 2006 assurance has been obtained that there is indeed a node willing to accept packets at the other end. Distributed flooding attacks provide more significant amplification. Here, the attacker takes over control of other nodes by compromising them with viral software, which it typically distributes by conventional means. The infected nodes are then programmed to jointly send packets to the victim. Typically, the attack proceeds automatically, and the attacker itself does not send itself packets to the victim. Distributed flooding attacks are of a different quality than the flooding attacks described afore because they generally exploit implementation vulnerabilities in operating systems rather than vulnerabilities in standard networking protocols. 5.2 Redirection-Based Flooding Redirection-based flooding attacks are a fourth attack type, which mobility and multi-homing protocols could introduce if they fail to provide appropriate protection. In such an attack, the perpetrator requests a server to transmit a large file, e.g., a video, and subsequently misuses a mobility or multi-homing protocol to redirect this download to the IP address of its victim. The transport protocol may require the attacker to spoof acknowledgment on behalf of the victim. But since the acknowledgments are typically smaller in size and number than the data packets that the server generates, the amplification in this attack can be much higher than in the discussed ICMP and TCP flooding attacks. Today's transport protocols were developed for an Internet where nodes use stable IP addresses, hence most of them perform reachability verification, if at all, only at some early stage during connection establishment. E.g., TCP requires the receiver to obtain a random 32-bit sequence number during the initial handshake. Mobility and multi-homing protocols defeat the purpose of such reachability verification as they introduce the ability to redirect packets subsequently to the initial handshake. Referring to the example of the TCP download, the attacker could execute the initial handshake procedure via its own IP address, and use the sequence number obtained that way to spoof acknowledgments after it has redirected the session to the IP address of its victim. 5.3 Protection against Redirection-Based Flooding Most mobility and multi-homing protocols execute an IP-layer reachability check as a protection against redirection-based flooding whenever a node changes its IP address. Given that the delay of such Vogt & Arkko Expires August 18, 2006 [Page 13] Internet-Draft Credit-Based Authorization February 2006 a check can have a noticable impact on applications, a straightforward strategy is to execute reachability verification concurrently while packets are already being sent to the new IP address. This requires additional protection for the phase during which packets are sent to the new IP address although the validity of that IP address is still questionable. Credit-Based Authorization provides this protection in that it limits the impact of such redirection to what could also be accomplished---with much less coordinative effort---through a direct flooding attack. Specifically, the combination of concurrent reachability verification and Credit-Based Authorization does not prevent malicious redirection per se, but it prevents its use from a location off the path towards the flooded victim as well as any amplification in the quantity of redirected packets. As a result, a redirection-based flooding attack becomes as effective as a direct flooding attack. 5.4 Alternatives to Credit-Based Authorization There are alternatives to Credit-Based Authorization which can protect against misuse of mobility or multi-homing protocols for redirection-based flooding attacks. One alternative is to perform reachability verification in a concurrent way only with nodes from a trusted community. Mobility and multi-homing protocols usually authenticate a node during a binding update, providing a way for secure identification. The correspondent node can thus decide whether or not to use the new IP address before the result of reachability verification becomes known. For instance, the correspondent node may be a corporate server which grants concurrent reachability verification exlusively to nodes from the corporate network. Mobility and multi-homing protocols that use the IPv6 Source Address field to signal a new IP address to the correspondent node may rely on ingress filtering [11] to be enforced within the multi-addressed nodes' networks. Ingress filtering is a function that routers may execute to prevent packets with spoofed source addresses from leaving a network. The natural crux with ingress filtering, however, is that the correspondent node in general does not know whether or not ingress filtering has been performed on packets received from a particular multi-addressed node. Furthermore, the granularity of ingress filtering decreases with the distance between the access network and the router that executes it. In an optimal case, ingress filtering is directly applied in the first-hop router. But even then may an attacker use a false IPv6 Source Address as long as the network prefix is correct. A third alternative to Credit-Based Authorization is to identify and Vogt & Arkko Expires August 18, 2006 [Page 14] Internet-Draft Credit-Based Authorization February 2006 blacklist malicious nodes based on their observed behavior. Credit- Based Authorization is a proactive strategy, whereas behavior-based blacklisting is a reactive one. The advantage of a reactive approach is that a faithful multi-addressed node does not need to invest effort (i.e., collect credit) in order to be able to receive packets at an unverified IP address. This can accommodate a multi-addressed node having trouble to collect sufficient credit---be it because its IP address changes too frequently, or because its application generates too little data. On the other hand, a reactive approach by definition fails to prevent misuse of concurrent reachability verification in advance. What it can do is contain the damage of such misuse and punish the perpetrator. Punishment depends on an administrative relationship between the multi-addressed node and the correspondent node, however, and such a relationship may not exist. finally, behavior-based blacklisting requires a heuristic to determine what behavior is considered "ill". Yet choosing the right heuristic is far from trivial. An inappropriate heuristic may punish a faithful mobile node or overlook an evil one. 5.5 Alternatives to Credit Aging Credit-Based Authorization uses exponential aging to slowly reduce collected credit over time. An alternative to exponential aging would be a constant upper bound on the credit. However, such a limit would allow an attacker to acquire credit at a very slow speed, possibly through a slow Internet connection, and to use this credit quickly for a burst of packets redirected to a victim. Collected credit may also be kept for a long time before it is eventually used. This would allow the attacker to build up credit at multiple correspondent nodes one after another. Finally, a constant limit would be insensitive to throughput conditions on the path between the multi-addressed node and the correspondent node. A limit for a low- bandwidth connection is certainly inappropriate for a high-bandwidth connection, and vice versa. Exponential aging does not have these disadvantages and was thus considered a more appropriate approach than limiting a mobile node's credit by a constant upper bound. 6. Protocol Constants CreditAgingFactor 7/8 CreditAgingInterval 5 seconds Vogt & Arkko Expires August 18, 2006 [Page 15] Internet-Draft Credit-Based Authorization February 2006 7. Acknowledgment The necessity for a mechanism to prevent or discourage misuse of concurrent reachability verification for amplified redirection-based flooding attacks was sparked by a fruitful discussion on the MIP6 and MOBOPTS mailing lists. Credit-Based Authorization was developed as a candidate solution, and a first presentation was given at the 59th IETF meeting in Seoul, Republic of Korea. For their interest and valuable feedback, the authors thank the MIP6 and MOBOPTS communities, in particular Roland Bless, Mark Doll, Francis Dupont, Gregory Daley, Lars Eggert, James Kempf, Rajeev Koodli, Tobias Kuefner, Marco Liebsch, Gabriel Montenegro, Nick (Sharkey) Moore, Pekka Nikander, Erik Nordmark, Charles Perkins, and Kilian Weniger (listed in alphabetical order). Thanks are also due to the development team of the Kame-Shisa Mobile IPv6 implementation. 8. References 8.1 Normative References [1] Vogt, C., "Early Binding Updates for Mobile IPv6", draft-vogt-mobopts-early-binding-updates (work in progress) (work in progress). 8.2 Informative References [2] Moskowitz, R., Nikander, P., Jokela, P., and T. R., "Host Identity Protocol", IETF Internet Draft draft-ietf-hip-base-04.txt (work in progress), October 2005. [3] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", IETF Internet Draft draft-ietf-hip-mm-02.txt (work in progress), July 2005. [4] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim protocol", IETF Internet Draft draft-ietf-shim6-proto-03.txt (work in progress), December 2005. [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", IETF Request for Comments 4225, December 2005. Vogt & Arkko Expires August 18, 2006 [Page 16] Internet-Draft Credit-Based Authorization February 2006 [7] Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in IPv6", To appear in the proceedings of the IEEE Wireless Communications and Networking Conference, IEEE, April 2006. [8] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec (work in progress) (work in progress). [9] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", In Proceedings of the 18th Annual Computer Security Applications Conference, Las Vegas, Nevada, USA., December 2002. [10] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding Lifetime Extension", draft-arkko-mipv6-binding-lifetime-extension (work in progress) (work in progress). [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [12] Paxson, V., "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3)., July 2001. [13] Anderson, R., "Why Information Security is Hard -- An Economic Perspective", In Proceedings of the 17th Annual Computer Security Applications Conference, New Orleans, Louisiana, USA., December 2001. [14] Perkins, C., "Precomputable Binding Management Key Kbm for Mobile IPv6", draft-ietf-mip6-precfgkbm (work in progress) (work in progress). Authors' Addresses Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de Vogt & Arkko Expires August 18, 2006 [Page 17] Internet-Draft Credit-Based Authorization February 2006 Jari Arkko Ericsson Research NomadicLab FI-02420 Jorvas Finland Email: jari.arkko@ericsson.com Vogt & Arkko Expires August 18, 2006 [Page 18] Internet-Draft Credit-Based Authorization February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt & Arkko Expires August 18, 2006 [Page 19]