SECUIRYT THREATS ANALYSIS OF ROUTE
OPTIMIZATION MECHANSIM IN MOBILE IPV6
W. Al-Salihy
R. Sures
Network Research Group
School of computer Science
University Sains Malaysia
Penang, Malaysia
Network Research Group
School of computer Science
University Sains Malaysia
Penang, Malaysia
H/P (006) 0125581776
H/P (006) 0134303334
wafaa@nrg.cs.usm.my
sures@usm.my
ABSTRACT
1.1 How Mobile IPv6 work
In current mobile Ipv6, each mobile node is identified by its home
address, regardless of its current point of attachment to the
Internet. While situated away from its home, a mobile node is
also
associated with a care-of address, which provides
information about the mobile node's current location. IPv6
packets addressed to a mobile node's home address are
transparently routed to its care-of address. The protocol enables
IPv6 nodes to apply route optimization thereby cache the binding
of a mobile node's home address with its care-of address, and to
then send any packets destined for the mobile node directly to it at
this care-of address.
MIPv6 [4] describes mechanisms similar to mobile IP whereby a
mobile node can freely roam between network links and yet
constantly remain accessible through a home address (HoA)
statically allocated on its “home” network. While away from its
home network a mobile node (Mn) makes use of a care-of address
(CoA) dynamically allocated on the network to which it is
currently attached, while a proxy known as a home agent is
responsible for forwarding (tunneling) packets arriving at the
home network on to the mobile node’s care-of address. A mobile
node makes its whereabouts known to its home agent by sending
it a binding update (BU) message, the triplet message, which
contains home address, its current care-of address and the
lifetime. Every home agent maintains a binding cache recording
the binding updates it has received. Any node that communicates
with a mobile node is a correspondent node (Cn), and in fact
every IPv6 node is a potential correspondent node. A mobile node
also sends a binding update (BU) to any correspondent node from
which a (tunneled) packet has been received via its home agent.
Dislike mobile IP, mobile IPv6 offer route optimization
mechanism in which each correspondent node maintains a binding
cache which its transmit function uses to redirect packets directly
to the mobile node’s care-of address, thus saving at least one
network hop relative to the route through the home agent. Home
agents and correspondent nodes may refresh a binding cache entry
by sending a binding request to a mobile node, requesting the
transmission of a fresh binding update. MIPv6 minimizes the state
that a correspondent node must maintain by including a home
address option field, encoding a mobile node’s home address, in
every packet sent by a mobile node while it is away from its home
To support route optimization, current Mobile IPv6 facing many
security threats, this paper focusing on analyzing all the security
threats of route optimization mechanism and explaining why the
need for redesign the current mobile ipv6. This paper doesn’t
show the MIPv6 protocol after redesign rather it shows the need
for redesign it.
Keywords
Mobile IPv6, Route Optimization, Security Threats
1. BACKGROUND
Mobile computing and networking should not be confused with
the portable computing and networking we have today. In mobile
networking, computing activities are not disrupted when the user
changes the computer’s point of attachment to the Internet.
Instead, all the needed reconnection occurs automatically [10], a
standard proposed by a working group within the Internet
Engineering Task Force, was designed to provide this way of
communication (mobility) by allowing the mobile node to use two
IP address: a fixed home address and a care of address that
changes at each new point of attachment.
Current mobile IP will change with mobile IPv6, which have
many features for mobility support that are missing in current
version, including, Stateless Address Auto configuration [11], and
Neighbor Discovery [8], which allow the node to configure it’s
care-of address. Thus, foreign agents are not required to support
mobility in IPv6. and Route Optimization which improve the
performance of IPv6 Mobile nodes.
network. The receive side of the IP stack on the
correspondent node informs higher level software that the
packet was sourced not from the care-of address in the
packet’s header, but from the address given in the home
address option.
Because the binding updates sent remotely to the home
agent to affect the home agent’s routing table (binding
cash), and because the communication become direct
between the correspondent node (Cn) and the mobile node
(Mn) when route optimization mechanism enabled, the
nodes must be certain from the mobile node whether it is
the original one or a malicious node and this assurance need
for strong authentication and security mechanism.
2. CURRENT PROBLEMS IN THE
SECURITY OF MIPV6
Initially the plan was to use only IPSec Authentication Header
(AH) for binding message authentication, without defining and
developing any new authentication protocol. This approach
encountered many problems and that is why several other methods
have also been developed.
The current specification defines that IPSec ESP should be used
for authentication between MN and HA, and Return Routability
(RR) should be used for authentication between MN and CN. The
specification makes also possible to use some other, more secure
methods than RR for authentication between MN and CN. These
methods are discussed in the next sections.
2.1 IPSec Doesn’t Applicable for Mipv6
IPSec [5, 6] can be used to authenticate and encrypt packets at IP
level. That is why it was naturally the first proposed method for
authentication of the binding messages. The biggest problem with
the IPSec method is the key distribution. Key distribution of the
IPSec, which is called Internet Key Exchange (IKE), uses either
preshared secrets or public keys in the key exchange. When
authentication is needed between an Mn and an HA, which must
have some relationship in advance, because the MN uses services
of the HA, the needed secrets might be exchanged beforehand or
some private public key distribution can be utilized. After several
discussions in IETF, IPSec ESP was chosen for binding message
authentication between Mn and HA instead of IPSec AH. When
considering authentication of the binding messages between an
Mn and some unknown Cn, no preshared secret can be used.
There doesn’t either exist global public key infrastructure that
could be utilized. Because of that, actually IPSec as a whole is not
usable for authentication between the MN and the CN.
2.2 Return Routability
In MIPv6 draft, Binding Updates to correspondent nodes
supposed to be protected by using a binding management key,
Kbm. Kbm establish using data exchanged during the return
Routability (RR) procedure. The Return Routability Procedure
enables the correspondent node to obtain some reasonable
assurance that the mobile node is in fact addressable at its claimed
care-of address as well as at its home address. Only with this
assurance is the correspondent node able to accept Binding
Updates from the mobile node, which would then instruct the
correspondent node to direct that mobile node's data traffic to its
claimed care-of address. This is done by testing whether packets
addressed to the two claimed addresses are routed to the mobile
node. The mobile node can pass the test only if it is able to
supply proof that it received certain data (the "keygen tokens")
that the correspondent node sends to those addresses. These data
are combined by the mobile node into a binding management key,
The Home and Care-of Test Init messages are sent at the same
time. The procedure requires very little processing at the
correspondent node, and the Home and Care-of Test messages can
be returned quickly, perhaps nearly simultaneously. These four
messages form the Return Routability procedure denoted Kbm.
The following are the four messages that form the Return
Routability procedure.
Home Test Init (HoTI):
Source Address = home address
Destination Address = correspondent
Parameters: home init cookie
Care-of Test Init (CoTI):
Source Address = care-of address
Destination Address = correspondent
Parameters: care-of init cookie
Home Test (HoT):
Source Address = correspondent
Destination Address = home address
Parameters: - home init cookie
- home keygen token
- home nonce index
Care-of Test (CoT):
Source Address = correspondent
Destination Address = care-of address
Parameters: - care-of init cookie
- Care-of keygen token
- Care-of nonce index
Care-of keygen token = First (64, HMAC_SHA1 (Kcn, (care-of
address | nonce | 1)))
When the mobile node has received both the Home and Care-of
Test messages, the Return Routability procedure is complete. As
a result of the procedure, the mobile node has the data it needs to
send a Binding Update to the correspondent node. The mobile
node hashes the tokens together to form a 20 octet binding key
Kbm:
Kbm = SHA1 (home keygen token | care-of keygen token).
One of the design principles of Mobile IPv6 from the security
perspective was that it should not introduce any new threats and
vulnerabilities for the IPv6. The problem is that an attacker in the
route between two communicating nodes can use binding
messages, which are authenticated with using the RR method, to
break the connection easily. This is possible, because any node
between a CN and a HA gets both the keys home keygen and
care-of keygen and can use them to convince the CN to believe
the impersonated attacker’s binding messages. This happens as
follows: the attacker eavesdrops two communicating nodes A and
B that are located in their home networks and learns their IP
addresses. They can be any type of nodes, i.e. Cn, Mn. After that
attacker initiates the RR method by sending messages HoTI and
CoTI directly to B with using its own address as CoA and A’s
address as HoA. B sends messages HoT and CoT as response to
the received messages and attacker gets the keys. After that
attacker sends a BU to B where it claims that A has moved to its
own address and B accepts the message, because it is
authenticated correctly with using the RR method
2.3 Attacks that Exploit MIPv6
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-ofservice by keeping data from arriving at the right destination and
by bombing a target host or network with unwanted data. Further
more the attacker can amplify the number of packets sent to the
destination or reflect them. Using Return Routability as default
authentication can cause the hosts with bidding down attack,
which makes them give up the stronger authentication methods
and choose RR.
Attacks as known are active and passive 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. In this paper
we consider the active attacks only
congest the link toward that network by bombing random
addresses within its routing prefix or group of prefixes.
2.3.1.2 Basic Denial of Service Attack
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. Figure 1shows the attack.
2.3.1 Spoofing Binding Updates and Reroute IP
Packets to Wrong Destination Attacks
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 [1].
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.
2.3.1.1 Bomb any Mobile Node with Unwanted Data
Attack
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.
It does not help if the targets 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
Attacker
Data Flow before attack
Mn
Attacker redirect
packets to
random host
Cn
Random host
or non - exist
Figure 1: Basic Denial of Service Attack
2.3.1.3 Using HoA to Bomb any Host with Unwanted
Data Attack
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. The attacker can keep
the stream alive by spoofing acknowledgments. Figure 2 shows
the attack
The attacker is mobile with HoA equal to target address
Attacker
First step Cn trust
attacker
Mn
Cn
After cash entry expire
or cancel BU
Target host
Figure 2: Using HoA to bomb any host with unwanted data
Attack
When BUs is 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
2.3.1.4 Against Secrecy and Integrity Attack
By spoofing Binding Updates, an attacker can redirect packets
between two IP hosts to itself. By sending a spoofed BU to Cn, it
can capture the data intended to Mn. It can pretend to be Mn and
highjack B's connections with Cn, or establish new spoofed
connections. The attacker can also send spoofed BUs to both Cn
and Mn 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 Cn and Mn. The
attacks are possible if the target host or its correspondent supports
Route Optimization and the attacker knows their IP addresses.
Figure 3 shows the attack
Da
Attacker
Mn
Data Flow before attack
by
d
ifie
od er
m ck
ta atta
Attacker redirect
packets to itself
Cn
Figure 3: Against Secrecy and Integrity Attack
Attacker
redirect packets
to mobile node
previous
location
Mn
Cn
Data Flow before attack
Figure 4: Replay Attack
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.
2.3.3 Amplification or Reflection Attack
In this attack, attackers sometimes try to hide the source of a
packet by reflecting the traffic from other nodes [2].
Attacker send Cn packet ask him to send many packets to Mn
Attacker
n
Si
gl
e
Strong encryption and integrity protection 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. 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.
Attacker
Mobile node
previous
location
pa
ck
Any protocol for authenticating BUs will have to consider replay
attacks [2]. 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 carefully designed to avoid
more complex replay attacks. Figure 4 shows the attack.
et
2.3.2 Replaying and Blocking Binding Updates
Attack
Mn
Many packets
Cn
Figure 5: Amplification or Reflection Attack
That is, instead of sending a flood of packets directly to the target,
the attacker sends data to other nodes and tricks them into sending
the same number, or more, packets to the target. Figure 5 shows
the attack.
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 nodes can
be tricked into sending many more packets than they receive from
the attacker. Such features can be used to amplify the amount of
attack traffic by a significant factor. When designing protocols,
one should avoid creating services that can be used for reflection
and amplification attacks.
2.3.4 Bidding Down Attack
This attack is different from other above attacks [7], whereby the
above attacks can be applied when the BU is not authenticated or
using RR, while this one can be applied when strong
authentication required and Return Routability (RR) exist as
default mechanism for authentication, the attacker force the two
hosts or bidding them down from using strong security to use
weak security like RR. Figure 6 shows the attack.
Attacker bidding down from strong security to weak security
Attacker
Strong
security
Mn
Cn
Weak security (RR as default)
Figure 6: Bidding Down Attack
3. ROPOSED AUTHENTICATION
METHODS
In order to prevent the above attacks, the route optimization must
be secure and the Binding Updates signals must be authenticated.
As mentioned in section 2, IPSec and RR proposed to be used for
this purpose but as also mentioned, IPSec need Internet Key
Exchange (IKE), or public Key Infrastructure (PKI) to 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. In other hand RR do not
need any infrastructure solutions but it still weak authentication
method which the attacker can easily break the communication as
explained in section 2.2. And this is why we have another
proposed solutions:
3.1 Cryptographically Generated Addresses
This technique provides an intermediate level of security below
strong public-key authentication (IPSec) and above Return
Routability (RR) [3].
The idea of this technique 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-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.
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. 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.
3.2
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 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.
3.3 Two Independent Routes
Some BU authentication schemes have been proposed [9], 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.
3.4 Leap of Faith
Another idea that has been proposed 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.5 The Role of Ingress Filtering
Ingress filtering is another way of limiting the number of potential
attackers and their targets. Thereby preventing spoofed source IP
addresses. This can help but, 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.
4. CURRENT RESEARCH
Writing this paper convey the analysis done which was the first
step in this research. The current research exploring several issues
for securing Mobile IPv6 including, neighbor discovery security,
and security of IPv6 routing header and home address options.
Beside that we study the possibility of adding more cash tables in
Cn and Mn and logical comparisons between these cash tables for
the purpose of security. The security of Mipv6 will not base on
Infrastructure solution. The work in progress.
5. CONCLUSIONS
Mobile IPv6 specification is still unfinished and it needs
some research work to get it working and to get it widely
accepted. The basic functionality has been there for some
time already, but the problems have been in the security of
the protocol. The security has been identified to be the most
crucial part of the protocol, because without a proper
security solution, the protocol has no possibility to be
accepted and usable at all. This paper analyzed almost the
attacks that exploit the route optimization mechanism and
BU signals in the current Mobile IPv6 draft and highlighted
the main points that orient the current research.
6. LIMITATIONS
Writing of this paper has been a challenging task because
the Mobile IPv6 specification is under development at the
moment and a lot of changes and new propositions are
introduced all the time. Finding the most important ones of
them required a lot of reading of different research papers,
Internet drafts and mailing list messages, which is made
available by IETF.
7. REFERENCES
[1] Aura, T., Arkko, J. MIPv6 BU attacks and Defenses,
draft-aura-mipv6-bu-attacks-01.txt, IETF, February
2002.
[2] Greg, O., Mobile Ipv6 for Windows XP (.NET Server)
and Windows CE4.0, MSRC Joint with Lancaster
University And Ericsson Research. Microsoft Research
@ Lancaster UK
[3] Greg, O. and Michael, R. Childproof Authentication
for MIPv6 (CAM). ACM Computer Communication
Review, 31 (2), April 2001.
[4] Johnson, D., Perkins, C. Arkko, J. Mobility Support in
IPv6, draft-ietf- mobileip-ipv6-18, IETF, June 2002.
[5] Kent, S. and Atiknson, R. IP Encapsulation Security
Payload (ESP), IETF, RFC 2406 November 1998.
[6] Kent, S. and Atiknson, R. IP Authentication Header
(AH), IETF, RFC 2402 November 1998.
[7] Montenegro, G. and Nikander, P. Protecting against
Bidding Down Attacks. Draft-montenegro-mipv6secbit-method-00.txt, IETF, April 2002.
[8] Narten, T., Nordmark, E., and Simpon, W. Neighbor
Discovery for IP Version 6 (IPv6), IETF, RFC 1970,
August 1996.
[9] Nikandar, P. and Perkins, C. Binding authentication
key establishment protocol for Mobile Ipv6, draftperkins-bake-01.txt, IETF Mobile IP Working Group,
July 2001.
[10] Perkins, C., ed. IP Mobility Support. IETF, RFC 2002,
October 1996.
[11] Thomson, S. and Narten, T. IPv6 Stateless Address
Autoconfiguration. IETF, RFC 1971, August 1996.