IETF Mobile IP Working Group T. Aura INTERNET DRAFT Microsoft Expires May 2002 J. Arkko Ericsson November 2001 MIPv6 BU Attacks and Defenses draft-aura-mipv6-bu-attacks-00.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 various 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, and some denial-of- service attacks specifically exploit features of authentication protocols. The purpose of this document is to list attacks that should be taken into consideration when designing protocols for BU authentication and to outline available protection mechanisms. We also discuss the choice between different levels of protection. Aura Expires May 14, 2002 [Page 1] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 Table of Contents Status of This Memo...............................................1 Abstract..........................................................1 1. Introduction...................................................3 1. Attacks that Corrupt Routing Tables............................3 1.1. Spoofing Binding Updates....................................4 1.2. Attacks against Secrecy and Integrity.......................4 1.3. Basic Denial of Service Attacks.............................5 1.4. Replaying and Blocking Binding Updates......................5 1.5. Bombing CoA with Unwanted Data..............................6 2. Authentication of Binding Updates..............................7 2.1. Public Key Authentication...................................7 2.2. Two Independent Routes......................................8 2.3. Reducing the Number of Attackers and Targets................9 3. DoS Attacks against BU Authentication.........................11 3.1. Inducing Unnecessary Binding Updates.......................11 3.2. Consuming Authentication Resources.........................12 3.3. Forcing Non-Optimized Routing..............................13 4. Preventing Resource Exhaustion................................13 4.1. Delaying Commitment........................................14 4.2. Controlling Damage.........................................15 4.3. Favoring Regular Customers.................................15 5. The Right Level of Protection.................................16 5.1. Prioritizing the Goals.....................................16 5.2. Multiple Levels of Authentication..........................18 5.3. Home Agent and Binding Acknowledgments.....................19 6. Security Considerations.......................................20 7. Conclusions...................................................20 Acknowledgments..................................................20 References.......................................................21 Authors' Addresses...............................................22 Aura Expires May 14, 2002 [Page 2] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 1. Introduction This document describes attacks against Mobile IPv6 [JP00] 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 address that does not receive the wanted packets and at the one 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 not received sufficient attention at the Working Group (e.g. they are 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 (Section 2.5). Second, an attacker can consume the resources of any mobile or correspondent by inducing authentic but unnecessary Binding Updates (Section 4.1). Third, some proposed BU authentication protocols can be broken by attackers located on the route from the correspondent to the Home Agent (Section 3.2). Some of these attacks may be acceptable or too expensive to prevent, but their existence should be clearly acknowledged. 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 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 an unauthentic BU protocol execution at any time and it does not need to wait for a suitable messages to be sent by the targets hosts. Aura Expires May 14, 2002 [Page 3] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 2.1. Spoofing Binding Updates 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 HoA is B and the 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 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 WLANs risk revealing their addresses. IPv6 addressing privacy features 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 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 Aura Expires May 14, 2002 [Page 4] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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 By sending spoofed BUs, the attacker can redirect all packets sent between two IP hosts to a random or nonexistent address. This way, 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 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 Aura Expires May 14, 2002 [Page 5] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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 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. (The sender A is Aura Expires May 14, 2002 [Page 6] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 likely to ignore any ICMP Destination Unreachable messages if it also receives 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. 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 the border of the target network may be able filter out data that is sent to nonexistent addresses. Whether this may be possible depends on the way that the addresses within that network are managed. It seems likely that e.g. IPv6 addressing privacy features would preclude such filtering in the general case. 3. Authentication of Binding Updates In order to prevent the corruption of correspondent routing tables, the Binding Updates must be authenticated. In this section, we discuss both strong and weak authentication methods. 3.1. Public Key Authentication The assumption in Mobile IPv6, as in many other systems, seems to have been that generic security mechanism such as IPSec, IKE, and a public-key infrastructure (PKI) will eventually solve all authentication issues. The current lack of suitable BU authentication protocol can thus be seen as a direct consequence of the failure of global PKIs. Also, it turns out to be difficult to mix strong BU authentication with weaker schemes (see Section 6.2). There are nevertheless situations where it is possible, and advisable, to follow the original plan. In closed user groups and Aura Expires May 14, 2002 [Page 7] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 high-security environments, it may be possible to set up a PKI and require BUs to be strongly authenticated. A recently discovered technique [OR01] provides an intermediate level of security between strong public-key authentication and weak methods such as routability tests. The idea 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 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 is 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, it 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. Another shortcoming of the CAM-type addresses 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 Section 2.5). While the public-key protocols provide a reasonable protection against unauthentic BUs, they expose the correspondent to denial- of-service attacks (see Section 4.2). 3.2. 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 Aura Expires May 14, 2002 [Page 8] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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. 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. (We assume that the Alternate CoA sub- option does cannot be used as a pert of these protocols.) Ingress filtering also prevent 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. On the other hand, if one finds it a reasonable assumption 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. (See the next section.) 3.3. Reducing the Number of Attackers and Targets 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. Such weak methods can be used either when the stronger ones are too expensive or to fix shortcomings of the stronger protocols. Limiting the number of attackers is also essential in defending against denial-of-service attacks on the Internet, because it is rarely possible to entirely prevent the attacks. Some proposed BU authentication protocols make the assumption that the communication between two specific hosts, e.g. on the route between the correspondent and the mobile's home agent, is safe from attackers, even though it is not cryptographically protected. As mentioned above, this 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 controls some routers can only interfere with communication between a limited number of hosts because most Internet traffic will not be Aura Expires May 14, 2002 [Page 9] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 routed through the compromised routers. The assumption can be justified also by the fact that an attacker on the route between two fixed hosts (the mobile at home and the same correspondent) can mount equally damaging attacks against the communication between them. Another way to limit the number of attackers and their targets is to test the routability of both 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 may be able to capture 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 routability test is, in fact, a variation of the cookie exchange, which has been used as part of the TCP handshake [RAOA01] and in authentication protocols, including Photuris [KS99] and IKE [HC98]. The routability test is particularly usable in combination with the CAM-type addresses (see Section 3.1) because it can prevent the bombing of a CoA with unwanted data. A reply to the routability test indicates that someone who can receive packets sent to the CoA wants to receive data from the correspondent. 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). Unfortunately, this 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. Third, the attack may impersonate a random IP addresses in order to mount a variety of DoS attack against the correspondent. 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 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. Ingress filtering is another way of limiting the number potential of 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 Aura Expires May 14, 2002 [Page 10] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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 attacks against Mobile IPv6. 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 Aura Expires May 14, 2002 [Page 11] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 the limit is exceeded, the host can simply stop Route Optimization. (See Section 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. 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. (See Section Error! Reference source not found..) 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 Aura Expires May 14, 2002 [Page 12] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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 designing the stare management with flooding attacks in mind. (See Section 5.1.) 4.3. Forcing Non-Optimized Routing If the BUs are not authenticated, an 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 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. 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. It is usually impossible to completely prevent DoS attacks and the right approach may be to increase the cost and difficulty of the attacks and to mitigate their effects. Aura Expires May 14, 2002 [Page 13] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 5.1. Delaying Commitment 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 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 routability test for both HoA and CoA (see Section 3.3), and continue with a public-key authentication if the routability 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]. In particular, hosts with little memory and implementations aiming for simplicity are 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 Aura Expires May 14, 2002 [Page 14] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 authenticate the correspondent and, thus, there is no clear point after which it is safe to create a state. We acknowledge that the mobile is likely to have more stringent memory constraints than the correspondent and it may be left vulnerable to the state storage exhaustion. 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 IP protocol. First, the IP layer does not know which one of the nodes is the server (i.e. the respondent), the mobile or the correspondent. Second, mobile nodes can have extremely limited processor and battery capacity, which makes the cost of solving puzzles too high for them. The puzzle protocols work well only when all clients have approximately equal computational capacity. 5.2. Controlling Damage As we suggested in Section 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 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 a flooding attack 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 send to use an Aura Expires May 14, 2002 [Page 15] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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 number of addresses in the list 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 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 actually enable DoS attacks that would not otherwise be possible. Nevertheless, the following principles apply to both kinds of attacks. The attacks described in this document can be divided into three classes: The most serious attack is the bombing of third parties with unwanted data (Section 2.5) because they cannot do anything to stop the flood of data. The mobiles and correspondents MUST implement and use some kind of protection against this attack. Aura Expires May 14, 2002 [Page 16] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 Hosts that do not want to implement such protection, MUST ignore all Binding Updates and, thus, cannot use Route Optimization. The attacks against correspondent hosts 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 correspondent and if the Mobile IP protocol makes them vulnerable, then every IP host is vulnerable. It is important that a reliable protection mechanism is available for the correspondents and every IP host SHOULD implement and use it. If the protection for the correspondents requires support from mobiles, all mobile hosts MUST implement and use it. The third class includes all attacks against the mobiles. As with correspondents, it is important to have a protection mechanism for the mobiles and they SHOULD implement and use it. If the protection for the mobiles requires support from correspondents, all correspondents MUST implement and use such support. 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. (Actually, there is a choice between defending only the Internet from Mobile IPv6 and defending also the reliability of Mobile IPv6 itself. We have chosen the former viewpoint. If one goes for the latter alternative, then it is unnecessary to prevent attack against the mobile hosts. This does not necessarily result in significant simplifications in the BU authentication protocols because most protections are needed in any case to protect the non-mobile hosts, i.e. correspondents and third parties.) The guiding principle above is that a protection mechanism MUST be implemented and used if the security of other hosts depends on it. If only the host's own security is at stake, it SHOULD implement and use the protection. However, some hosts, e.g. minimal implementations, MAY elect not to protect themselves against all the attacks as long as that does not compromise the protection for others. 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 cost of the defenses must not be excessive. In particular, the minimum requirements for correspondent nodes have to be low because all IP nodes must satisfy them. One possibility is to require everyone either to use a strong protocol or to refrain from using Route Optimization. The Route Optimization may, however, be crucial Aura Expires May 14, 2002 [Page 17] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 for the performance of many low-end mobile hosts that cannot afford to implement strong authentication but receive audio or video streams. An ideal solution to BU authentication would allow a simple and cheap solution for the low-importance hosts and a more comprehensive protection for those who can afford it. A three level protection would appear to be particularly suitable to cover the needs of different situations: 1. A method based on return routability and symmetric cryptography (similar to Bake). 2. A method based on relationships of addresses and public keys (such as CAM or SUCV). 3. Strong authentication through shared secrets and/or PKIs (e.g. IPSec/IKE). Unfortunately, as we will explain below, it is difficult to accommodate multiple levels of protection without compromising everyone's security. 6.2. Multiple Levels of Authentication As explained above, there is the temptation to allow multiple authentication mechanism of different strength and cost. Unfortunately, this does not necessarily result in any better security than if the weakest method were used alone. The same is true to protocols that provide different levels of DoS protection. The decision about accepting or not accepting a BU is made by the correspondent. Therefore, the decision process at the correspondent is crucial for any BU authentication mechanism. If weak and a strong authentication are alternatives, the correspondent will have to make the decision when to allow the weak BU authentication and when to require the strong method. This section discusses the ways in which the correspondent can make the decision. The same principles apply to the combination of any stronger and weaker BU authentication mechanism regardless of their absolute strength and technical details. The correspondent MAY have a local policy that lists the HoA addresses or address ranges for which weak protection is allowed. For example, a correspondent could be configured to allow weak BU authentication for some low-end mobile devices that benefit from Route Optimization but cannot afford to run the stronger authentication protocol. It is not possible to negotiate the level of protection online between the mobile and the correspondent. If an attacker can impersonate the mobile in the weaker mechanism, it can always negotiate to choose the weak mechanism. A strong authentication Aura Expires May 14, 2002 [Page 18] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 would be required to prove that the authentic mobile agrees to use a weak one. Therefore, the list of mobiles for which the correspondent allows weak BU authentication MUST either be statically configured into the correspondent's local policy, or dynamically determined by strong authentication or equivalent commitment shown in upper protocol layers. On the other hand, weak BU authentication in one correspondent does not compromise strong authentication in another correspondent. Even if the attacker defeats the weak mechanism, it cannot redirect packets to or from correspondents that use a strong protocol. Therefore, a degree of separation exists between the decisions of different nodes, and the decisions of one correspondent do not affect the strength of BU authentication at other correspondents. However, this separation does not apply to most DoS attacks and protection for the other party and for third parties must always be implemented, as explained in the previous section. The correspondents that do not allow weak BU authentication are unable use Route Optimization with low-end mobiles that do not implement the stronger mechanism. From the above it follows that if a public web site or other server does not register its clients, it must choose either strong or weak BU authentication for everyone. If it allows a weak mechanism, it is unnecessary to implement a strong one. On the other hand, different servers may choose the strength of BU authentication mechanisms independently. However, the economics of the Internet may force practically every public server to select the weakest allowed mechanism, which means that Mobile IPv6 may always remain vulnerable to attacks. In conclusion, there are technical and business reasons that will force most IP nodes to use the weakest level of authentication that is mandatory to implement and use in all IP hosts. We therefore recommend that the weakest allowed authentication should be fairly strong. There are nevertheless situations, such as closed groups and networks and high-security environments, where it is possible to deploy weaker or stronger mechanism than the minimum required by the standard, as long a single level of security is used consistently and outsiders on the Internet are not exposed to DoS attacks. 6.3. Home Agent and Binding Acknowledgments 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 Aura Expires May 14, 2002 [Page 19] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 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. 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. (Of course, if an authenticated IPSec tunnel between the mobile and the correspondent exists, it can be used also for the acknowledgments and the problem is solved.) 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. 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 existing 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 [RAOA01]. Acknowledgments Aura Expires May 14, 2002 [Page 20] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 Many of the ideas originate from Mike Roe, Greg O'Shea, and Pekka Nikander 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. [HC98] Dan Harkins and Dave Carrel. The Internet key exchange (IKE). RFC 2409, IETF Network Working Group, November 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- Aura Expires May 14, 2002 [Page 21] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 montenegro-sucv-01.txt, IETF, July 2001. Work in progress. [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. [OR01] Greg O'Shea and Michael Roe. Child-proof authentication for MIPv6 (CAM). ACM Computer Communications Review, 31(2), April 2001. [JP00] David B. Johnson and Charles Perkins. Mobility support in ipv6. Internet Draft draft-ietf-mobileip-ipv6-14.txt, IETF Mobile IP Working Group, July 2000. Work in progress. [RAOA01] Michael Roe, Tuomas Aura, Greg O'Shea, and Jari Arkko. Authentication of Mobile IPv6 binding updates and acknowledgments. Internet Draft draft-roe-mobileip- updateauth-01.txt, IETF Mobile IP Working Group, November 2001. 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 Aura Expires May 14, 2002 [Page 22] INTERNET-DRAFT MIPv6 BU Attacks and Defenses November 2001 Phone: +358 40 5079256 Email: Jari.Arkko@ericsson.com Aura Expires May 14, 2002 [Page 23]