IETF Mobile IP Working Group T. Aura INTERNET DRAFT Microsoft Expires August 2002 J. Arkko Ericsson February 2002 MIPv6 BU Attacks and Defenses draft-aura-mipv6-bu-attacks-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document overviews attacks against mobile and fixed IP nodes by exploiting features of the Mobile IPv6 Route Optimization. Many of the attacks can be prevented by authenticating the Mobile IPv6 Binding Updates (BU) but some cannot, some depend on the details of the BU protocol, and some denial-of-service attacks specifically take advantage of authentication mechanisms. The purpose of this document is to help those involved in the design and standardization of BU authentication protocols to understand the attacks, to assess suggested protection mechanisms, and to choose between different levels of protection. Aura, Arkko Expires August 28, 2002 [Page 1] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 Table of Contents Status of This Memo...............................................1 Abstract..........................................................1 Table of Contents.................................................2 1. Introduction...................................................3 2. Attacks that Corrupt Routing Tables............................3 2.1 Spoofing Binding Updates (o).................................4 2.2 Attacks against Secrecy and Integrity (o)....................5 2.3 Basic Denial of Service Attacks (o)..........................5 2.4 Replaying and Blocking Binding Updates (o)...................6 2.5 Bombing CoA with Unwanted Data...............................6 2.6 Bombing HoA with unwanted data (*)...........................8 3. Authentication of Binding Updates..............................8 3.1 Public Key Authentication (o)................................9 3.2 Cryptographically Generated Addresses........................9 3.3 Return Routability for HoA and CoA (*)......................10 3.4 Assuming a safe route.......................................12 3.5 Two Independent Routes......................................13 3.6 Leap of Faith...............................................14 3.7 The Role of Ingress Filtering (o)...........................14 4. DoS Attacks against BU Authentication.........................15 4.1 Inducing Unnecessary Binding Updates........................15 4.2 Consuming Authentication Resources..........................16 4.3 Forcing Non-Optimized Routing (o)...........................17 4.4 Reflection and Amplification (*)............................17 5. Preventing Resource Exhaustion................................18 5.1 Delaying Commitment.........................................18 5.2 Controlling Damage..........................................20 5.3 Favoring Regular Customers..................................20 6. The Right Level of Protection.................................21 6.1 Prioritizing the Goals (*)..................................21 6.2 Multiple Levels of Authentication (*).......................22 7. Security Considerations.......................................24 8. Conclusions...................................................25 Acknowledgments..................................................25 References.......................................................25 Authors' Addresses............................................27 Aura, Arkko Expires August 28, 2002 [Page 2] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 1. Introduction This document describes attacks against Mobile IPv6 [JP01] Route Optimization and related protection mechanisms. The goal of the attacker can be to corrupt the correspondent host's routing table (the Binding Cache) and to cause packets to be routed to a wrong address. This can compromise secrecy and integrity of communication and cause denial-of-service (DoS) both at the communicating parties and at the address that receives the unwanted packets. The attacker may also exploit features of a Binding Update (BU) protocol to exhaust the resources of either the mobile or the correspondent. The aim of this document is to describe the major attacks and to overview various protocol mechanisms and their limitations. In particular, we want to make known several attacks which should be considered when designing a protocol for authenticating BUs but which have only lately received attention at the Working Group (e.g. they were not mentioned in [MPH+01]). First, data flows can be redirected to flood a third party who is not taking part in the BU protocol (Sec. 2.5 -2.6 ). Second, some proposed BU authentication protocols can be broken by attackers located on the route from the correspondent to the Home Agent (Sec. 3.5 ). Third, an attacker can consume the resources of any mobile or correspondent by inducing authentic but unnecessary Binding Updates (Sec. 4.1 ). It is essential to understand that some of the threats are more serious than others, some can be mitigated but not removed, and some may be acceptable or too expensive to prevent. There are also various security mechanisms that provide different levels of guarantees for different security properties. We are particularly interested in mechanisms that allow authentication between arbitrary Internet nodes without pre-established trust relationships, public-key infrastructure (PKI), or trusted third parties (TTP). This means that some compromises must be made. The question for the protocol designer is, which design choices give an acceptable level of protection at an acceptable cost. Our goal is to help answering this question. We have marked with (o) the sections that contain only well-known material, which most readers are likely to be familiar with but which is included for completeness. Sections with major changes or additions since the previous version have been marked with a star (*). 2. Attacks that Corrupt Routing Tables Route optimization and Binding Updates create a new opportunity for attackers. By sending false BUs, they can create false entries in Aura, Arkko Expires August 28, 2002 [Page 3] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 the correspondent host's Binding Cache and, thus, reroute IP packets to wrong destinations. If the data in the packets is not protected cryptographically, this can lead to compromise of secrecy and integrity. The attacker may also cause denial-of-service by keeping data from arriving at the right destination and by bombing a target host or network with unwanted data. We consider only active attackers. The rationale behind this is that in order to corrupt a routing table, the attacker must sooner or later send one or more messages. Thus, it makes little sense to consider attackers that only observe messages but do not send any. In fact, the active attacks are easier to for the average attacker than passive ones would be. In most active attacks, the attacker can initiate the BU protocol execution at any time while more passive attacks would require the attacker to wait for suitable messages to be sent by the targets hosts. 2.1 Spoofing Binding Updates (o) If Binding Updates are not authenticated, an attacker can send spoofed BUs. All Internet hosts are vulnerable to this attack because they all must support the correspondent functionality. There is also no way of telling which addresses belong to mobile hosts that really could send BUs. Consider an IP host A sending IP packets to another IP host B. The attacker can redirect the packets to an arbitrary address C by sending to A a Binding Update where the home address (HoA) is B and the care-of address (CoA) is C. After receiving this BU, A will send all packets intended for B to the address C. The attacker may select the CoA to be either its own current address (or another address in its local network) or any other IP address. If the attacker selects a local CoA where it can receive packets, it will be able to send further packets to a correspondent, which the correspondent believes to be coming from the mobile. Ingress filtering at the attacker's local network does not prevent the spoofing of Binding Updates but forces the attacker either to choose a CoA from inside its own network or to use the Alternate CoA sub-option. This may make it easier for the attack targets to selectively filter the spurious BUs at a firewall. The correspondent stores the HoA-CoA pair in its Binding Cache. The attacker needs to send a new BU every few minutes to refresh the cache entry. The attacker needs to know or guess the IP addresses of both the sender and receiver. This means that it is difficult to redirect all packets to or from a host because the attacker would need to know the IP addresses of all the hosts with which it is Aura, Arkko Expires August 28, 2002 [Page 4] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 communicating. Hosts with well-known addresses, such as servers and those using stateless auto-configuration, are most vulnerable. Hosts that are a part of the network infrastructure, such as DNS servers, are particularly interesting targets for attackers. Hosts with frequently changing random addresses and no DNS names are relatively safe. However, hosts that visit publicly accessible networks such as airport wireless LANs risk revealing their addresses. IPv6 addressing privacy features [ND01] mitigate these risks to an extent but it should be noted that addresses cannot be completely recycled while there are still open sessions that use those addresses. 2.2 Attacks against Secrecy and Integrity (o) By spoofing Binding Updates, an attacker can redirect packets between two IP hosts to itself. By sending a spoofed BU to A, it can capture the data intended to B. It can pretend to be B and highjack B's connections with A, or establish new spoofed connections. The attacker can also send spoofed BUs to both A and B and insert itself to the middle of all connections between them (man-in-the-middle attack). Consequently, the attacker is able to see and modify the packets sent between A and B. The attacks are possible if the target host or its correspondent supports Route Optimization and the attacker knows their IP addresses. Strong encryption and integrity protection, such as authenticated IPSec, can prevent all the attacks against data secrecy and integrity. When the data is cryptographically protected, spoofed BUs can result in denial of service but not in disclosure or corruption of sensitive data beyond revealing the existence of the traffic flows. Two fixed hosts could also protect communication between themselves by refusing to accept BUs from each other. Ingress filtering, on the other hand, does not help because the attacker is using its own address as the CoA and is not spoofing source IP addresses. The attacks described above are a serious threat to the Internet for two reasons. First, a lot of Internet traffic is unprotected. Second, an attacker anywhere on the network can mount the attacks against any Internet hosts, also non-mobile ones. If Binding Updates did not exist, the attacker would need to be on the route between the attack targets in order to listen to the traffic between them. 2.3 Basic Denial of Service Attacks (o) By sending spoofed BUs, the attacker can redirect all packets sent between two IP hosts to a random or nonexistent address. This way, Aura, Arkko Expires August 28, 2002 [Page 5] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 it may be able to stop or disrupt communication between the hosts. The requirements are that the target host or its correspondent must support Route Optimization and the attacker must know their IP addresses. The attack is serious because any Internet host can be targeted, also fixed hosts. Hosts belonging to the infrastructure necessary for other hosts to communicate are also vulnerable. Again, two hosts can protect the communication between themselves by refusing BUs from each other or by establishing an authenticated IPSec tunnel for the BUs. 2.4 Replaying and Blocking Binding Updates (o) Any protocol for authenticating BUs will have to consider replay attacks. That is, an attacker may be able to replay recent authenticated BUs to the correspondent and, that way, direct packets to the mobile host's previous location. Like spoofed BUs, this can be used both for capturing packets and for DoS. The attacker can capture the packets and impersonate the mobile node if it reserves the mobile's previous address after the mobile has moved away and then replays the previous BU to redirect packets back to the previous location. The replays are a concern if a timestamps are used for checking the freshness of BUs and the mobile is moving so frequently that it sends the next BU before the timestamp in the previous BU has expired. Sequence numbers in authenticated BUs usually prevent the attack. The authentication protocol needs to be is carefully designed to avoid more complex replay attacks. In a related attack, the attacker blocks binding updates from the mobile at its new location, e.g. by jamming the radio link or by mounting a flooding attack, and takes over its connections at the old location. The attacker will be able to capture the packets sent to the mobile and to impersonate the mobile until the correspondent's Binding Cache entry expires. Both of the above attacks require the attacker to be on the same local network with the mobile, where it can relatively easily observe packets and block them even if the mobile does not move to a new location. Therefore, we believe that these attacks are not as serious as ones that can be mounted from remote locations. 2.5 Bombing CoA with Unwanted Data By sending spoofed BUs, the attacker can redirect traffic to an arbitrary IP address. This can be used to bomb an arbitrary Internet address with excessive amounts of data. The attacker can Aura, Arkko Expires August 28, 2002 [Page 6] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 also target a network by redirecting data to one or more IP addresses within the network. In the simplest attack, the attacker knows that there is a heavy data stream from host A to B and redirects this to the target address C. A will soon stop sending the data because it is not receiving acknowledgments from B. A more sophisticated attacker acts itself as B. It first subscribes to a data stream (e.g. a video stream from a news web site) and then redirects this to the target address C. The attacker may even be able to spoof the acknowledgements. For example, consider a constant-rate TCP stream. The attacker performs the TCP handshake itself and thus knows the initial sequence numbers. After redirecting the data to C, it suffices to send one spoofed acknowledgment per window. In a constant-rate stream, the attacker is able to predict the sequence numbers, the window size, and the right times for sending the acknowledgments. This way, the attacker is able to redirect a steady stream of unwanted data to the target address without doing much work itself. It can carry on opening more streams and refresh the Binding Cache entries by sending a new BU every few minutes. (TCP provides some protection against this attack: If C is the address of a real host, it will respond with TCP Reset, which should prompt A to close the connection. On the other hand, if C is a non-existent address, A will receive both the spoofed acknowledgments and ICMP Destination Unreachable messages. Depending on the implementation, A may ignore the error messages. Other transport-layer protocols might behave less gracefully.) The attack is serious because the target can be any host or network, not only mobile one. What makes it particularly serious compared to the other attacks is that the target itself cannot do anything to prevent the attack. For example, it does not help if the target network stops using Route Optimization. The damage is the worst if these techniques are used to amplify the effect of a distributed denial of service (DDoS) attack. Ingress filtering in the attacker's local network prevents the spoofing of source addresses but the attack is still possible by setting the Alternate CoA sub-option to the target address. The attacker needs to find a correspondent that is willing to send data streams to unauthenticated recipients. Many popular web sites provide such streams. If the target is a single host, the attacker needs to know or guess the target's IP address. On the other hand, if the target is an entire network, the attacker can congest the link toward that network by bombing random addresses within its routing prefix or group of prefixes. In some cases, a firewall on Aura, Arkko Expires August 28, 2002 [Page 7] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 the border of the target network may be able filter out data that is sent to nonexistent addresses. Whether this is possible depends on the way that the addresses within that network are managed. It seems likely that IPv6 addressing privacy features would preclude such filtering in the general case. 2.6 Bombing HoA with unwanted data (*) A variation of the bombing attack targets the HoA instead of the CoA. The attacker claims to be a mobile with the HoA equal to the target address. It starts downloading a data stream. The attacker then sends a BU cancellation (i.e. a request to delete the binding from the Binding Cache), or allows the cache entry to expire, which redirects the data stream to the HoA. Just like when bombing the CoA, the attacker can keep the stream alive by spoofing acknowledgments. When BUs are not authenticated, the attacker can choose an arbitrary address as the HoA and thus target any Internet node. BU authentication usually limits the attacker's choice of target address but care must be taken when designing the protocol. For example, one draft protocol verified the correctness of HoA (using a return routability test, see Sec. 3.3 ) only when a Binding Cache entry was created. This would allow the attacker to target any network where it has once owned an address, e.g. a public access LAN. A limit on the Binding Cache entry lifetimes or more frequent verification of HoA virtually prevents the attacks. When successful, the bombing attack against HoA is just as serious as the one against CoA. One mechanism is not usually enough to prevent both types of bombing attacks and they should be considered separately when designing a BU authentication protocol. 3. Authentication of Binding Updates In order to prevent the corruption of correspondent routing tables, the Binding Updates must be authenticated. The two first subsections (Sec. 3.1 -3.2 ) discuss relatively strong, public-key authentication methods. The later subsections go into progressively weaker authentication methods that would be labeled as insecure in the traditional black-and-white network security thinking. Nevertheless, some of them (Sec. 3.3 -3.4 ) do provide well-defined levels of assurance in the real networks and can complement or even replace the stronger methods. The motivation is that instead of trying to prevent all attacks, the best strategy is often to limit the number of potential attackers that can attack a particular target, and to reduce the number of targets a potential attacker can threaten. In particular, limiting the number of attackers is essential in defending against denial-of-service attacks on the Aura, Arkko Expires August 28, 2002 [Page 8] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 Internet because it is rarely possible to entirely prevent these attacks. The current authors regard the cryptographically generated addresses (Sec. 3.2 ) and return routability tests (Sec. 3.3 ) as the most promising solutions for BU authentication. In situations where public-key cryptography is considered too expensive, the best solution may be be to assume a safe network route (Sec. 3.4 ). 3.1 Public Key Authentication (o) An obvious solution to Mobile IPv6 authentication would be to use a suite of strong generic authentication mechanisms such as IPSec, IKE, and a PKI. The current lack of a standard BU authentication protocol can thus be seen as a consequence of the commercial failure of PKIs and the slow pace of the IPSec standardization process. There are, however, other reasons (than unavailability) why the generic protocol suites may not be good for BU authentication. First, the generic authentication protocols have usually been designed with general-purpose computers and application-level security in mind. The computation and communication overhead of these protocols may be too high for low-end mobile devices and for a network-level signaling protocol. Second, the Mobile IPv6 protocol is carefully designed to accommodate any Internet host as mobile and all hosts as correspondents. This means that a single PKI should cover the entire Internet, which is clearly a formidable goal when even local infrastructures have failed to emerge at the expected rate. Therefore, it is necessary to look for alternative solutions that do not rely on such global infrastructures. There are nevertheless situations where it is possible, and advisable, to apply the generic authentication solutions. In closed user groups and high-security environments, it may be possible to set up a PKI and require BUs to be strongly authenticated. 3.2 Cryptographically Generated Addresses A recently discovered technique provides an intermediate level of security below strong public-key authentication and above routing- based weak methods (which will be described in the following sections). The idea, originally introduced in a BU authentication protocol called CAM [OR01], is to form the last 64 bits of the IP address (the interface identifier) by hashing the host's public signature key. Binding Updates can then be signed with this key. A secure one-way hash function makes it difficult for the attacker to come up with a key that matches a given address and to forge signed BUs. The attraction of this technique is that it provides public- Aura, Arkko Expires August 28, 2002 [Page 9] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 key authentication independent of any trusted third parties, PKI, or other global infrastructure. The main weakness of the scheme is that only 62-64 bits of the IP address can be used for the hash. Thus, an attacker may be able to mount a brute force attack and find a matching signature key by trial and error. It is relatively expensive to generate strong signature keys but the attacker does not need to care about the strength of the keys. There may be relatively fast ways of generating weak signature keys, which the correspondent may not able to tell apart from strong ones. In order to make such brute- force attacks less attractive, one should include the routing prefix of the network into the hash. This forces the attacker to perform the search separately for each prefix. Without this, a global table of all hash values and their corresponding keys might become feasible in the future, even if that seems out of practical reach given current storage technology. A mechanism for generating new public keys and changing addresses at regular intervals should also discourage brute-force attacks against individual hosts. Another limitation of the cryptographically generated addresses (CGA) is that although they prevent the theft of another host's address, they do not stop the attacker from inventing new false addresses with an arbitrary routing prefix. The attacker can generate a public key and a matching IP address in any network and use it to mount bombing attacks (as described in Sec. 2.5 -2.6 ). While the public-key protocols (both PKI-based and CGA-based ones) provide a reasonable protection against unauthentic BUs, they are computationally intensive and therefore expose the participants to denial-of-service attacks (see Sec. 4.1 -4.2 ). 3.3 Return Routability for HoA and CoA (*) One way to limit the number of attackers and their targets is to test the return routability (RR) of the HoA and CoA. That is, the correspondent sends packets to both addresses and accepts Binding Updates only from mobiles that are able to receive them. Some malicious entities (e.g. ones on the correspondent's local network) may be able to capture one or both packets but most Internet users do not have such capabilities. A typical attacker is able to attack only the correspondents in its own local network. The RR test is, in fact, a variation of the cookie exchange, which has been used as part of the TCP handshake [SKK+97] and in authentication protocols, including Photuris [KS99] and IKE [HC98]. Arguments have been made as to whether the RR test should be done for HoA, CoA, or both. In the following, we will explain what kind Aura, Arkko Expires August 28, 2002 [Page 10] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 of attacks each test prevents and conclude that both tests are needed. The RR test for HoA can be seen as a weaker alternative to CGA or other public-key authentication. In order to subvert the authentication, the attacker must be on the route between the correspondent and the HoA. But as we will see below, the routability test for HoA provides other guarantees in addition to mobile authentication, which make it is complementary, rather than alternative, to CGA authentication. The RR for CoA prevents the bombing of third parties at CoA (Sec. 2.5 ). The attacker has to be able to receive the packet sent to the CoA, which means that the attacker must have recently visited the target network. This is a way of checking that the mobile is not lying about its location. Thus, the test has to be repeated every time the mobile moves to a new location. This provides a level of authentication but is not entirely secure because the attacker could be somewhere on the path from the correspondent to the CoA. The bombing attacks against HoA (Sec. 2.6 ) gets around the RR test for CoA (and other the defense mechanisms that somehow verify the correctness the CoA). The first logical reaction to this would be to verify the new location of the mobile no matter if it arrives to a new CoA or to HoA. Unfortunately, it may be impossible to execute a RR test for HoA when a Binding Cache entry is cancelled or expires. The mobile may be unreachable at that time or it may refuse to co-operate in the authentication protocol. What makes the situation difficult is that if the RR test for HoA fails, the correspondent cannot simply drop the cache entry because that is exactly what the attacker would want. However, we believe that it is desirable for the correspondent to be able to delete the Binding Cache entry at any time without executing any further protocols. Therefore, we suggest that the RR test for HoA should be performed regularly during the lifetime of a Binding Cache entry. That way, when the cache entry needs to be deleted for any reason (e.g. BU cancellation, expiring cache entry, or failing authentication), a recent RR test for HoA has always been performed. This prevents bombing of HoA unless the attacker has recently visited that address (or other on-path location where it can receive packets from the correspondent to the HoA). We propose the following guidelines for combining the mechanisms: - Before creating a Binding Cache entry, do authenticated key exchange with CGA, RR test for HoA, and RR test for CoA. Aura, Arkko Expires August 28, 2002 [Page 11] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 - Before a Binding Cache entry is updated with new CoA, do RR test for CoA. - Periodically do RR for HoA. The best time to do this is before refreshing the Binding Cache entry with unchanged CoA but the test must not be postponed indefinitely if the mobile changes its CoA in every BU. (One way to implement this is to limit the lifetime of Binding Cache entries.) The RR test for HoA could executed be more frequently, e.g. every few minutes, in protocols that rely on the RR test for authentication and less often, e.g. every hour, with CGA authentication. This is because CGA removes the need for the RR authentication function and also prevents the bombing of individual addresses. The benefit from such optimization is, however, limited, because the cost of the RR test is lowest when the mobile is not moving and the BU protocol can be executed in the background well before the Binding Cache entry expires. It might, therefore, be simplest to do both RR tests every time when the cache entry is updated without changing CoA. If the CGA authentication or one of RR tests fails, the correspondent should ignore the Binding Update and allow the Binding Cache entry expire. Interestingly, there is an argument for doing RR for CoA in the transport layer rather than in the IP layer. The flooding problem is related to flow control: the correspondent is redirecting a data flow into a new route and needs to verify that this route can accept the data. For TCP streams, the natural solution would be to reset the window size to the initial window size (1 or 2 packets). This would, in effect, test return routability of the new route before sending large amounts of data into it. However, mandating secure RR testing in all transport protocols and changing existing implementations would not be possible in practice. Therefore, the best solution is to do the RR tests in the IP layer. 3.4 Assuming a safe route Some proposed BU authentication protocols make the assumption that the communication between two specific hosts is safe from attackers, even though it is not cryptographically protected. For example, the return routability test for HoA (Sec. 3.3 ) can replace public-key authentication of the mobile if one is prepared to assume that the route from the correspondent to the mobile's Home Agent is secure. (Note that the RR test for HoA has two separate functions: authentication of the mobile and protection of the HoA against flooding.) Aura, Arkko Expires August 28, 2002 [Page 12] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 The assumption may be reasonable because the average Internet host cannot listen to or modify packets on the specific routers. Moreover, even an attacker in control of some routers can only interfere with communication between a limited number of hosts because most Internet traffic will not be routed through the compromised routers. The assumption can be justified also by the fact that an attacker on the route between two fixed hosts (a mobile at home and a correspondent) can mount equally damaging attacks against the communication between them. 3.5 Two Independent Routes Some weak BU authentication schemes have been proposed (Bake [NP01], HA Cookies [TO01]) where the security essentially depends on sending two pieces of the authentication data between the correspondent and the mobile or its Home Agent through two independent routes and hoping that most attackers are unable to capture both of them. This may not help as much as has perhaps been hoped. In all these protocols, a single attacker on the route between the correspondent and Home Agent can spoof BUs by pretending to be both the mobile and its Home Agent. If the attacker uses its own address as the false CoA, it can spoof packets from both the mobile and the Home Agent to the correspondent, and it can receive messages sent by the correspondent to both HoA and CoA. This means that the protocols essentially make the same assumption about a single safe route as we proposed in the previous section. Without ingress filtering at the attacker's local network, the attacker is, in fact, able to select an arbitrary CoA. Ingress filtering at the attacker's network forces the attacker to use a CoA from its local network. (The Alternate CoA sub-option could be used to get around this.) Ingress filtering also prevents attacks against the HA Cookie protocol because the attacker could not spoof packets from Home Agent to the correspondent. A false sense of security is created if one assumes that the three sides of the triangle in MIPv6 triangle routing are independent routes. This is usually the case for an authentic mobile, but need not be true not for an attacker who claims to be the mobile. When the false mobile (i.e. the attacker) is on the route between the correspondent and the Home Agent, the triangle collapses. (When thinking about the protocols one easily starts arguing in terms of active and passive attackers. It is worth remembering here that all attacks against BU protocols are essentially active, as we explained at the beginning of Sec. 2.) Aura, Arkko Expires August 28, 2002 [Page 13] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 On the other hand, if one finds it reasonable to assume a safe route, i.e. that the attacker cannot listen to traffic between the correspondent and the Home Agent, then an equivalent level of security is achieved by a much simpler protocol: the correspondent sends a secret key in plaintext to HoA and Home Agent forwards it through a secure tunnel to the mobile. (This is a variation of the RR test for HoA.) We believe that however ridiculous this may sound, it may sometimes be the best solution for BU authentication. 3.6 Leap of Faith Yet another idea that has been floating around is that if the mobile sends a session key insecurely to the correspondent at the beginning of a connection, the key can be used to authenticate subsequent BUs (so called leap-of-faith authentication). This is a flawed proposition. It fails even if we assume that attacker is unlikely to capture the keys sent by authentic mobiles. First, the attacker can send its false key before the authentic mobile sends the authentic key. Second, there must be a recovery mechanism for situations where the mobile or the correspondent loses its state, and the attacker can exploit this mechanism. The leap-of-faith authentication is suitable for situations where a human user, or some other factor outside the attacker's control, at random times initiates the protocol. The party making the leap must always be the one that initiates the protocol. In such situations, it may be reasonable to argue that an attacker is unlikely to be present at the time of the unauthenticated key exchange. In BU authentication, the protocol is usually initiated by the mobile but the leap in faith should be made by the correspondent. Also, the attacker can trigger the BU protocol at any time by sending a spoofed packet from the correspondent to the mobile's HoA. 3.7 The Role of Ingress Filtering (o) Ingress filtering is another way of limiting the number of potential attackers and their targets. As we have noted above, many of the attacks against Route Optimization involve spoofed source IP addresses and are, thus, prevented by ingress filtering. There are two well-known weaknesses in this thinking, though. Firsts, ingress filtering must be applied on the attacker's local network; on the target network it makes no difference. Second, the Home Address Option and the Alternate Care-of Address sub-option can be used for similar source spoofing. While it is advisable to apply ingress filtering in as many networks as possible, one cannot rely on this to stop all attackers. Aura, Arkko Expires August 28, 2002 [Page 14] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 4. DoS Attacks against BU Authentication Security protocols that successfully protect the secrecy and integrity of data can sometimes make the participants more vulnerable to denial-of-service attacks. In fact, the stronger the authentication, the easier it may be for an attacker to use the protocol features to exhaust the mobile's or the correspondent's resources. 4.1 Inducing Unnecessary Binding Updates When a mobile host receives an IP packet from a new correspondent via the HoA, it automatically sends a Binding Update to that correspondent. The attacker can exploit this by sending the mobile spoofed IP packets (e.g. ping or TCP SYN packets) that appear to come from different correspondent addresses. The attacker will automatically start the BU protocol with these correspondents. If the correspondent addresses are real addresses of existing IP hosts, then most instances of the BU protocol will complete successfully. The entries created in the Binding Cache are correct but useless. This way, the attacker can with little work induce the mobile to execute the BU protocol unnecessarily, which can drain the mobile's resources. A correspondent (i.e. any IP host) can also be attacked in a similar way. The attacker sends spoofed IP packets to a large number of mobiles with the target host's address as the source address. These mobiles will all send Binding Updates to the target host. Again, most of the BU protocol executions will complete successfully. By inducing a large number of unnecessary BUs, the attacker is able to consume the target host's resources. This attack is possible against any BU authentication protocol. The more resources the Binding Update protocol consumes, the more serious the attack. Hence, strong cryptographic authentication protocol is more vulnerable to the attack than a weak one or unauthenticated BUs. A host should protect itself from the attack by setting a limit on the amount of resources, i.e. processing time, memory, and communications bandwidth, which it uses for processing BUs. When the limit is exceeded, the host can simply stop Route Optimization. (See Sec. 5.2 .) Sometimes it is possible to process some BUs even when a host is under the attack. A mobile host may have a local security policy listing a limited number of addresses to which BUs will be sent even when the mobile host is under DoS attack. A correspondent (i.e. any IP host) may similarly have a local security policy listing a limited set of addresses from which BUs will be accepted even when the correspondent is under a DoS attack. Aura, Arkko Expires August 28, 2002 [Page 15] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 The host may also recognize addresses with which they have had meaningful communication in the past and sent BUs to or accept them from those addresses. Ingress filtering at the attacker's local network mitigates the attacks. When flooding a mobile, the attacker can only choose correspondent addresses in its own local network. When flooding a correspondent, the attacker can only target correspondents in its own network. Unfortunately, the Home Address Option (HAO) can be used to circumvent the ingress filtering and to spoof packets from any correspondent. It has been questioned whether the HAO should be allowed in all packets, or only on those that are associated with an already successfully created Binding Cache Entry. The latter would prevent the use of HAOs in DoS attacks against BU authentication. In the following section, we will explain some additional DoS attacks and defense mechanisms. However, these attacks are generally no more serious than the ones described in this section. It usually does not pay to defend against the other types of attacks unless one can also prevent the attacks of this section. 4.2 Consuming Authentication Resources Authentication protocols are often vulnerable to flooding attacks that exploit the protocol features to consume the target host's resources. Computing power is consumed by flooding the host with messages that cause it to perform expensive cryptographic operations. If a host creates state during protocol execution, it is also vulnerable to attacks where the attacker starts excessive numbers of protocol runs and never finishes them. In order to exhaust the computing power of modern processors, the attacker needs to get them to perform public-key cryptographic operations. To do this, they may, for example, spoof large numbers of signed messages where the signatures are replaced by random numbers. The target host must verify the signatures before rejecting the messages. Symmetric encryption, cryptographic hash functions, and non-cryptographic computation are rarely the performance bottleneck. However, if the cryptographic library is optimized only for bulk data, it may behave inefficiently when the functions are invoked on millions of short messages and the keys are changed on every invocation. One way protocols can avoid the unnecessary public-key operations is to require a weak authentication, such as a cookie exchange, before doing the expensive computation. Attacks against stateful protocols can be prevented by making the protocol parties stateless until the honesty of the other participant has been proved or by Aura, Arkko Expires August 28, 2002 [Page 16] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 designing the stare management with flooding attacks in mind. (See Sec. 5.1 .) 4.3 Forcing Non-Optimized Routing (o) If the BUs are not authenticated, the attacker can prevent a correspondent from using Route Optimization by filling its Binding Cache with false entries so that most entries for real mobiles are dropped. With authenticated BUs, the attacker can mount the same attack by inducing unnecessary Binding Updates that create authentic but unnecessary cache entries (see Sec. 4.1 ). Any successful DoS attack against a mobile or a correspondent can also prevent the processing of BUs. We have repeatedly suggested that the target of a DoS attack may respond by stopping Route Optimization for all or some communication. Obviously, an attacker can exploit this fallback mechanism and force the target to use the less efficient triangle routing. The attacker only needs to mount a noticeable DoS attack against the mobile or correspondent, and the target will default to non-optimized routing. The target host can mitigate the effects of the attack by reserving more space for the Binding Cache, by reverting to non-optimized routing only when it cannot otherwise cope with the DoS attack, by trying aggressively to return to optimized routing, and by favoring mobiles with which it has an established relationship. This attack is not as serious as the ones described earlier, but applications that rely on Route Optimization could still be affected. For instance, conversational multimedia sessions can suffer drastically from the additional delays caused by triangle routing. 4.4 Reflection and Amplification (*) Attackers sometimes try to hide the source of a packet flooding attack by reflecting the traffic from other hosts [Sav02]. That is, instead of sending the flood of packets directly to the target, the attacker sends data to other hosts, tricking them to send the same number, or more, packets to the target. Such reflection can hide the attacker's address even when ingress filtering prevents source address spoofing. Reflection is particularly dangerous if the packets can be reflected multiple times, if they can be sent into a looping path, or if the hosts can be tricked into sending many more packets than they receive from the attacker, because such features can be used to amplify the traffic by a significant factor. When designing protocols, one should avoid creating services that can be used for reflection and amplification. Triangle routing easily creates opportunities for reflection: Correspondent receives packets (e.g. TCP SYN) from the mobile and Aura, Arkko Expires August 28, 2002 [Page 17] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 replies to the home address given by the mobile (in a HAO). The mobile might not really be a mobile and the HoA could actually be the target address. The target at the HoA only sees the packets sent by the correspondent and cannot see the attacker's address (even if ingress filtering prevents the attacker from spoofing its source address). The BU protocol could also be used for reflection: the correspondent responds to a data packet or to an unauthenticated BU by initiating the BU authentication protocol, which usually involves sending a packet to HoA. In that case, the reflection attack can be discouraged by copying the mobile's address into the messages sent by the mobile to the correspondent. (The mobile's source address is usually the same as the CoA but an Alternative CoA suboption can specify a different CoA.) In some proposed BU authentication protocols (e.g. one we co- authored [Roe02]), the correspondent responds to an initial message from the mobile with two packets (one to HoA, one to CoA). This can be used to amplify a flooding attack by a factor of two. Furthermore, with public-key authentication, the packets sent by the correspondent may be significantly larger than the one that triggers them. These types of reflection and amplification could be avoided by ensuring that the correspondent only responds to the same address from which it received a packet, and only with a single packet of the same size. Depending on the BU protocol, this might require an increased number of messages and a reverse tunneling mechanism for sending packets from the mobile through the Home Agent to the correspondent. The question that needs to be decided is whether the cost of these protections is more acceptable than threat created by a small constant factor of amplification. Padding could be used to equalize the packet sizes although we believe this would be unnecessary in practice. The mobile nodes usually have low- bandwidth access links, which makes them vulnerable to flooding attack, but high-value targets, such as public servers, rarely are mobile. 5. Preventing Resource Exhaustion In this section, we describe defenses against denial-of-service attacks that exploit features of the BU protocol to exhaust the target host's resources. As it usually is impossible to completely prevent DoS attacks, the right approach is to increase the cost and difficulty of the attacks and to mitigate their effects. 5.1 Delaying Commitment Aura, Arkko Expires August 28, 2002 [Page 18] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 A standard protection against DoS attacks is to delay committing one's resources to the protocol until the other party has provided some assurance about its honesty. This assurance could, for example, be authentication or expensive computation of resources by the other party. Expensive public-key operations can be delayed by starting with a weak but inexpensive authentication mechanism and by proceeding with the public-key operations only after the weak authentication succeeds [Mea99]. This either limits the number of attackers who can get to the public-key stage or increases the cost of the attack by forcing the attacker to break the weak mechanism. For example, a BU authentication protocol could start with a cookie exchange or, preferably, with a RR test for both HoA and CoA (see Sec. 3.3 ), and continue with a public-key authentication only if the RR test succeeds. Memory space for storing protocol state is another resource that attackers can exhaust. The conventional way to defeat attacks that consume state storage is to reserve enough memory for storing the state data and to manage the storage efficiently. Another method is to remain stateless until the authentication is complete [AN97a]. Hosts with little memory and implementations aiming for simplicity are particularly likely to find the stateless approach easier. We therefore recommend the that BU authentication protocol should allow stateless implementation of the correspondent. On the other hand, there is no compelling reason to require statelessness for hosts that can manage the state data in other ways. There are some difficulties in making the BU authentication protocol stateless, which should be understood. The main difficulty is that usually only the responder can be stateless, and it is not clear which party initiates the Binding Update process and which one responds. While the mobile normally initiates the authentication, this may be triggered by a packet belonging to another protocol that arrived from the correspondent. Moreover, if a packet from the correspondent triggers the BU, the correspondent may not know that this was the case. A further complication is that once an upper layer protocol has created a protocol state, it is of little value to refrain from doing so in the lower layers, but the IP layer cannot know when this is happening. For simplicity, we recommend making the correspondent stateless and advice against trying to guess which party initiated the protocol and whether the statelessness is necessary or not. We choose protection of the correspondent over the mobile for two reasons. First, any Internet host can be a correspondent. Second, it is less practical to make the mobile stateless because the mobile usually does not authenticate the correspondent and, thus, there is no clear point after which it is safe to create a state. We acknowledge that the Aura, Arkko Expires August 28, 2002 [Page 19] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 mobile is likely to have more stringent memory constraints than the correspondent and it may be left vulnerable to the state storage exhaustion attacks. Cryptographic puzzles [JB99][ANL00] are another proposed protection against resource-exhaustion attacks. A server requires its clients to solve a cryptographic puzzle (e.g. brute-force search for some input bits of a one-way function) before committing its own resources to the protocol. The server can adjust the difficulty of the puzzles according to its load. Solving the puzzle creates a small cost for each protocol invocation, which makes flooding attacks expensive but has little effect on honest hosts. Unfortunately, there are several drawbacks to this strategy in the Mobile IPv6 protocol. First, the IP layer does not know which one of the nodes, the mobile or the correspondent, is the server (i.e. the respondent). Second, mobile nodes can have extremely limited processor and battery capacity, which makes the cost of solving puzzles too high for them, while an attacker pretending to be a mobile is likely have much more computational capacity. The puzzle protocols work well only when all clients have approximately equal computational capacity. 5.2 Controlling Damage As we suggested in Sec. 4.1 , a host can protect itself from flooding attacks by limiting the amount of resources it uses for BU authentication. It can set limits on the processor time, memory and communications capacity used for this purpose. When this limit is exceeded, the host should stop all further participation in BU authentication protocols. It may stop processing BUs and let all Binding Cache entries expire. Alternatively, it may continue to update entries already in the Binding Cache if there is a light- weight mechanism (e.g. a session key) for re-authenticating them. The effect of this is to stop Route Optimization for all communication, or only for new connections. The host may return to normal operation when it believes the attack is over. Since authentication cannot prevent all the attacks, every host SHOULD implement the limit on resource usage. A host that does not implement the limit will be vulnerable to flooding attacks but it will not cause any damage to other hosts. 5.3 Favoring Regular Customers A correspondent can give priority to mobiles with which it has a long-term relationship or recent meaningful communication in the upper protocols layers. The mobile may similarly favor selected correspondent addresses. The best way to secure Binding Updates when the hosts have a long-term relationship is to use an Aura, Arkko Expires August 28, 2002 [Page 20] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 authenticated IPSec tunnel. The following techniques should only be used when it is not possible to configure an IPSec Security Association. A host's local policy may have a list of addresses or address ranges, to and from which BUs are processed even when the host is under stress from attacks. These should not include addresses for which it is feasible to establish long-term IPSec Security Associations. The list of addresses should not be large or public because otherwise the attacker might be able to mount the attack by using only these addresses. Taking into account authentication and other displays of commitment in the upper protocol layers can be difficult to implement because it violates the stateless nature of the IP protocol layer and creates dependences between protocol layers. In some common situations, it may be worth while to violate the layering principle. For example, a Web server could accept BUs from its clients after it has successfully executed the TCP handshake. It may also help to keep updating the existing entries in the Binding Cache so that existing optimized routes can be maintained during the attack, although it is not certain that the existing cache entries belong to the most important mobiles or even to authentic ones. Some indication of this may be inferred from the packet counts associated with the traffic flowing through the entry. 6. The Right Level of Protection We will conclude this document by discussing the criteria that should be used for selecting and comparing BU authentication protocols and issues that arise when there are several alternative protocols. 6.1 Prioritizing the Goals (*) The strength of the protection against DoS attacks that do not corrupt routing tables is independent of the strength of the BU authentication. As we have observed, strong authentication mechanisms may even enable DoS attacks that would not otherwise be possible. Nevertheless, the following principles apply to all attacks. - A protection mechanism MUST be implemented and used if security of other hosts or communication between other hosts depends on it (except in cases covered by the next bullet). - A protection mechanism SHOULD be implemented if communication between the host itself and others depends on it. Aura, Arkko Expires August 28, 2002 [Page 21] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 - A protection mechanism SHOULD be implemented if only the host's own security depends on it. - Some hosts, e.g. minimal implementations, MAY elect not to protect themselves and their own connections against all the attacks as long as that does not compromise the protection for others. Since Route Optimization is an optimization, a host MAY always protect itself and others by ignoring all Binding Updates, which means giving up Route Optimization. A slightly smarter host MAY implement only the mandatory mechanisms that help protect others and stop using Route Optimization when it detects a DoS attack against itself. The most serious attack is the bombing of third parties with unwanted data (Sec. 2.5 -2.6 ) because they cannot do anything to stop the flood of data. All mobiles and correspondents MUST either implement and use some kind of protection against this attack, or ignore all Binding Updates and give up Route Optimization. Attacks against correspondent hosts that accept Binding Updates form the second most serious class of attacks. This includes attacks on data secrecy and integrity as well as denial-of-service attacks. Every IP host is a potential correspondent and if the Mobile IP protocol makes them vulnerable, then every IP host is vulnerable. It is important that reliable protection mechanisms are available for the correspondents and every IP host SHOULD implement and use these mechanisms to protect itself. If the protection for the correspondents requires support from mobiles, all mobile hosts MUST implement and use the supporting functionality. Finally, there are the attacks against the mobiles. As with correspondents, it is important to have protection mechanisms for the mobiles and they SHOULD be implemented and used. Any necessary supporting functionality in the correspondents MUST be implemented and used. Although attacks against mobile hosts cannot bring down the Internet as we know it, the number and significance of mobiles will increase. If Mobile IPv6 is to become the primary mobility protocol in the Internet, it is essential to protect its reliability against malicious parties. 6.2 Multiple Levels of Authentication (*) The computational and communications capabilities of Internet hosts vary vastly, as does the level of security they require. It would, therefore, be desirable to have a range of BU authentication protocols with different cost and security trade-offs. For example, Aura, Arkko Expires August 28, 2002 [Page 22] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 closed high-security groups could use pre-established shared keys or a PKI, most hosts CCA authentication with return routability tests for DoS prevention, and low-end mobile devices a protocol based only on RR. However, care must be taken to accommodate the multiple levels of protection so that the attacker cannot bid down to the lowest level. In the end, the decision about accepting or not accepting a BU is made by the correspondent. Therefore, the correspondent will always make the final decision about the required level of authentication (e.g. CGA/RR or plain RR) for the particular HoA. Also, it makes little sense for the correspondent to allow multiple levels of authentication for the same HoA because the attacker could always tackle the weakest one. Thus, the mobile must either authenticate itself using the protocol chosen by the correspondent or give up Route Optimization. It makes little sense to negotiate the protocol. In order to conform to the principles of the previous section, any protocol chosen by the correspondent must provide whatever level of DoS protection is considered sufficient for the mobile and for third parties. Thus, the protocols will mostly differ in DoS protection for the correspondent itself, which the correspondent may freely tune, and in the strength of the authentication. It is worth noting that different correspondents can make their choices of authentication strength independently. This is because a weak mechanism accepted by one correspondent would not help the attacker to redirect packets to or from correspondents that use a stronger protocol. It is advisable that the default protocol, used for mobiles with which the correspondent has not prior relationship, be the strongest one which correspondent can afford under normal use. Typically, this could be CGA/RR. This default level of authentication MUST be statically configured at the correspondent and MUST NOT be adjusted according to the current load. Otherwise, the attacker could artificially induce the conditions under which a weaker protocol is chosen. The correspondent MAY have a local policy that mandates a higher level (e.g. shared key authentication or PKI) or lower level (e.g. plain RR) of authentication for a particular HoA or range of addresses. These addresses can be statically configured or dynamically determined by strong authentication or equivalent commitment shown by the mobile in upper protocol layers. For example, a correspondent could be configured to allow weaker authentication for some low-end mobile devices that benefit from Route Optimization but cannot afford to run the stronger authentication protocol. Aura, Arkko Expires August 28, 2002 [Page 23] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 It would be possible to allocate one bit of the IP address, similar to the "u" and "g" bits [HD98] in the interface identifier, to indicate whether the address is a CGA address. The correspondent would then select the BU protocol based on this bit. A disadvantage of this scheme is that the length of the public-key hash would become one bit shorter. Also, there may be increasing pressure to allocate bits of the IPv6 address for various purposes and the 64- bit interface identifier may soon prove to be surprisingly short. The problem can be mitigated by requiring only mobile hosts (rather than all IP nodes) to set the CGA-bit correctly. Based on the above, it should be recommended (or possibly even mandated) that the mobiles implement all common BU protocols (e.g. both CGA/RR and plain RR). If one does not, it may be unable to use Route Optimization with many correspondents. There is also the risk that business reasons will force practically all IP nodes to use the weakest level of authentication that is mandatory to implement and use. For example, if many low-end mobiles only implement the weakest standardized protocol, virtually all correspondents will default to this mechanism, which would defeat the purpose of having any stronger protocol. 7. Security Considerations This document discusses security of Mobile IPv6 Route Optimization but does not present any specific protocols or detailed solutions. A separate specification of the actual BU authentication protocol is needed. There are other security concerns with Mobile IPv6 that are not addresses in this document. The Home Agent Discovery needs to be secured so that the mobile can establish a secure tunnel to a reliable Home Agent. Also, some features of the Mobile IPv6 protocol may reduce the effectiveness of ingress filtering. The Home Address Option, the Alternative CoA sub-option, and possibly IPv6 in IPv6 tunnels, may be used to spoof the origin of packets without spoofing the source IP address. We assume that the mobile has chosen a reliable Home Agent and that Binding Updates and Acknowledgments between the mobile and its Home Agent are strongly authenticated with techniques outside the scope of this document. For example, there could be a manually keyed IPSec tunnel to a router on the mobile's Home Network. There are situations where no secure tunnel exist, for example if the mobile automatically contracts the services of temporary Home Agents along its path, but we feel that the security in such situations is based on much weaker assumptions and should be considered separately. Aura, Arkko Expires August 28, 2002 [Page 24] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 It seems necessary to send the Binding Acknowledgments from other sources than the Home agent without authentication. In most BU authentication protocols, only the mobile is authenticated, and without authenticating the correspondent, there is no way of authenticating the acknowledgments. The consequence is that an attacker can send false acknowledgments and cause the mobile to send the next BU sooner or later than the correspondent expects. At worst, the effect is that the Binding Cache entry expires and Route Optimization is not used. Thus, an attacker anywhere on the network can prevent the use of Route Optimization by sending false Binding Acknowledgments. Finally, where an authenticated IPSec tunnel between the mobile and the correspondent exists, Binding Updates can be sent through the tunnel. However, the return routability test for DoS prevention might still be needed. We feel that currently the simplest and most effective solution is to design the BU protocol independently of IPSec. 8. Conclusions We have described attacks against Mobile IPv6 Route Optimization and mechanisms for protecting the protocol participants and third parties. Some of the attacks may be new in the sense that they have not been considered in earlier BU authentication requirements and protocol drafts. It is our hope that this document will help in designing BU authentication protocols and in the process of choosing the protocol or protocols that will be part of the Mobile IPv6 standard. We are also working on a family of protocols that takes into account the points of this document [Roe02]. Acknowledgments Many of the ideas originate from Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark and various Internet Drafts. References [AN97a] Tuomas Aura and Pekka Nikander. Stateless connections. In Proc. International Conference on Information and Communications Security (ICICS'97), volume 1334 of LNCS, pages 87-97, Beijing, China, November 1997. Springer. [ANL00] Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo. DOS- resistant authentication with client puzzles. In Proc. Security Protocols Workshop 2000, volume 2133 of LNCS, pages 170-181, Cambridge, UK, April 2000. Springer. Aura, Arkko Expires August 28, 2002 [Page 25] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 [HC98] Dan Harkins and Dave Carrel. The Internet key exchange (IKE). RFC 2409, IETF Network Working Group, November 1998. [HD98] Robert M. Hinden and Stephen E. Deering. IP version 6 addressing architecture. RFC 2373, IETF Network Working Group, July 1998. [JB99] Ari Juels and John Brainard. Client puzzles: a cryptographic countermeasure against connection depletion attacks. In Proc. 1999 Network and Distributed Systems Security Symposium (NDSS), pages 151-165, San Diego, CA USA, February 1999. Internet Society. [KS99] Phil Karn and William A. Simpson. Photuris: session-key management protocol. RFC 2522, IETF Network Working Group, March 1999. [KA98] Stephen Kent and Randall Atkinson. Security architecture for the Internet Protocol. RFC 2401, IETF Network Working Group, November 1998. [Mea99] Catherine Meadows. A formal framework and evaluation method for network denial of service. In Proc. 12th IEEE Computer Security Foundations Workshop, pages 4-13, Mordano, Italy, June 1999. IEEE Computer Society. [MPH+01] Allison Mankin, Basavaraj Patil, Dan Harkins, Erik Nordmark, Pekka Nikander, Phil Roberts, and Thomas Narten. Threat models introduced by Mobile IPv6 and requirements for security in Mobile IPv6. Internet Draft draft-ietf-mobileip-mipv6-scrty-reqts-01.txt, IETF IP Routing for Wireless/Mobile Hosts (mobileip) WG, October 2001. Work in progress. [MC01] Gabriel Montenegro and Claude Castelluccia. SUCV identifiers and addresses. Internet Draft draft- montenegro-sucv-02.txt, IETF, November 2001. Work in progress. [ND01] Thomas Narten and Richard Draves. Privacy extensions for stateless address autoconfiguration in IPv6. RFC 3041, IETF Network Working Group, January 2001. [NP01] Pekka Nikander and Charles Perkins. Binding authentication key establishment protocol for Mobile IPv6. Internet Draft draft-perkins-bake-01.txt, IETF Mobile IP Working Group, July 2001. Work in progress. Aura, Arkko Expires August 28, 2002 [Page 26] INTERNET-DRAFT MIPv6 BU Attacks and Defenses February 2002 [OR01] Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001. [JP01] David B. Johnson and Charles Perkins. Mobility support in ipv6. Internet Draft draft-ietf-mobileip-ipv6-15.txt, IETF Mobile IP Working Group, July 2001. Work in progress. [Roe02] Michael Roe, Tuomas Aura, Greg O'Shea, and Jari Arkko. Authentication of Mobile IPv6 binding updates and acknowledgments. Internet Draft draft-roe-mobileip- updateauth-02.txt, IETF Mobile IP Working Group, February 2002. Work in progress. [Sav02] Pekka Savola. Security of IPv6 routing header and home address options. Technical report, IETF, November 2002. Work in progress. [SKK+97] Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spaffold, Aurobindo Sundaram, and Diego Zamboni. Analysis of a denial of service attack on TCP. In Proc. 1997 IEEE Symposium on Security and Privacy, pages 208-223, Oakland, CA USA, May 1997. IEEE Computer Society Press. [TO01] Michael Thomas and Dave Oran. Home agent cookies for binding updates. Internet Draft draft-thomas-mobileip-ha- cookies-00.txt, IETF, July 2001. Work in progress. Authors' Addresses Tuomas Aura 7 J J Thompson Avenue Cambridge, CB3 0FB United Kingdom Phone: +44 1223 479708 Email: tuomaura@microsoft.com Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 Email: Jari.Arkko@ericsson.com Aura, Arkko Expires August 28, 2002 [Page 27]