Internet DRAFT - draft-aura-mipv6-bu-attacks

draft-aura-mipv6-bu-attacks






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]