SECUIRTY THREATS ANALYSIS OF ROUTE
OPTIMIZATION MECHANSIM IN MOBILE IPV6
W. Al-Salihy
Network Research Group
School of Computer Sciences
University Science Malaysia
Penang, Malaysia
H/P (006) 0125581776
wafaa@nrg.cs.usm.my
R. Sures
Network Research Group
School of Computer Sciences
University Science Malaysia
Penang, Malaysia.
H/P (006) 0124083334
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.
To support route optimization, current Mobile IPv6 [4] 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.
MIPv6 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
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 a
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 be direct between
the correspondent node (Cn) and the mobile node (Mn)
when route optimization mechanism applied the nodes must
be certain from the mobile node whether it is the original
one or a malicious node which need for strong
authentication.
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 a Mn and a 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 a 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 may be established 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.
Figure 1 shows the message flow for the Return Routability
procedures 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
TI
TI
2.1 IPSec Doesn’t Applicable for Mipv6
HOME Agent
Ho
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 following sections
be returned quickly, perhaps nearly simultaneously. These four
messages form the Return Routability procedure.
Ho
2. CURRENT PROBLEMS IN THE
SECURITY OF MIPV6
CoTI
Mobile node
(Mn)
HoT
Correspondent
node (Cn)
CoT
Figure 1. Message Flow for 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.1.1 Bomb any Mobile Node with Unwanted Data
Attack
2.3 Attacks that Exploit MIPv6
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
congest the link toward that network by bombing random
addresses within its routing prefix or group of prefixes.
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
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.
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.
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 2 shows the attack.
Attacker
Data Flow before attack
Mn
Cn
Attacker redirect
packets to
random host
Random host
or non - exist
Figure 2: 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 3 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
2.3.2 Replaying and Blocking Binding Updates
Attack
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 5 shows the attack.
Figure 3: 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 4 shows the attack
Da
Attacker
Mn
Data Flow before attack
by
d
ifie
od er
m ck
ta atta
Attacker redirect
packets to itself
Attacker
Mobile node
previous
location
Attacker
redirect packets
to mobile node
previous
location
Mn
Cn
Data Flow before attack
Figure 5: 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
Cn
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
Figure 4: Against Secrecy and Integrity Attack
Attacker
n
Si
gl
e
pa
ck
et
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.
Mn
Many packets
Cn
Figure 6: 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 6shows
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 7 shows the attack.
The idea is to form the last 64 bits of the IP address (the interface
identifier) by hashing the host's public signature key. Binding
Updates can then be signed with this key. A secure one-way hash
function makes it difficult for the attacker to come up with a key
that matches a given address and to forge signed BUs. The
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.
Attacker bidding down from strong security to weak security
3.2
Attacker
Strong
security
Mn
Cn
Weak security (RR as default)
Figure 7: 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].
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
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.
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.
7. REFERENCES
4. CURRENT RESEARCH
[3] Greg, O. and Michael, R. Childproof Authentication
for MIPv6 (CAM). ACM Computer Communication
Review, 31 (2), April 2001.
Writing this paper convey the analysis done which was the first
step in this research. The current research exploring different
issues for securing Mobile IPv6 including, neighbor discovery
security and Enhancing Internet location security, and security of
IPv6 routing header and home address options. 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.
[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
[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.