information security technical report 12 (2007) 32–43

available at www.sciencedirect.com

www.compseconline.com/publications/prodinf.htm

Security in Mobile IPv6: A survey

Khaled Elgoarany*, Mohamed Eltoweissy

The Bradley Department of Electrical and Computer Engineering, Virginia Tech, USA

article info abstract

Published online 6 March 2007
Secure mobile communication is essential for the pervasive accessibility of critical infor-
mation infrastructure. Connecting control systems with the business enterprise, wireless
telemetry and mobile user interaction with critical infrastructure systems are examples
of services that motivate the need for secure mobile communication. Mobile IPv6 is being
touted to provide communication support for such services. The security of Mobile IPv6
poses key challenges impeding its wide-scale adoption. Several security mechanisms
have been proposed in the literature. This paper surveys security vulnerabilities of Mobile
IPv6, provides a taxonomy for the main existing and proposed solutions, and then extends
to outline some open issues.
ª 2007 Elsevier Ltd. All rights reserved.

1. Introduction public wireless networks have radically changed the situation.

Numerous applications overlaying the critical information in-
frastructure such as transportation systems, emergency first
responder care and crisis management require secure mobile
communications. For example, in railway systems, mobile
communication can be used for the wireless train control,
for the interaction with SCADA nodes for electric traction
and signaling, for the mobile users’ access to ticket vending
servers, and for the connection of control systems with the
business enterprise. Mobile IPv6 (MIPv6) has been proposed
as an IP layer mobility protocol for the IPv6 (Perkins, 2004).
The Mobile IPv6 standardization process started in 1995. After
about three years, the mobility mechanism itself had been
fully specified, including an efficient and elegant protocol for
location updates that enabled optimized routing. Around
that time, it became apparent that spoofed location updates
posed a major security risk that had not been sufficiently
taken into account in the design (Aura, 2006). Moreover,
when IPv6 Neighbor and Router Discovery functions were de-
fined, it was assumed that the local links would consist of mu-
tually trusting nodes. However, the recent developments in
IPv6 nodes on a local link cannot necessarily trust each other
any more, but they must now become mutually suspicious,
even when the nodes have completed an authentication ex-
change with the network. This had added a number of new se-
curity threats as well (Arkko et al., 2002). In addition, the lack
of a global authentication infrastructure made it very hard to
solve the presented problems with straightforward applica-
tion of standard Internet security protocols, such as IPsec
and IKE. For all of the previous reasons, the standardization
of Mobile IPv6 was delayed (Aura, 2006).
This paper surveys the security vulnerabilities of Mobile
IPv6 and its projected threats, describes the proposed solu-
tions and highlights the open research problems. The rest of
the paper is organized as follows: Section 2 describes the
major security threats against Mobile IPv6. Section 3 gives
an overview of the proposed security solutions, focusing on
the solutions for authentication and key management, and
discusses the benefits of introducing cross-layering to the Mo-
bile IPv6 security design. Section 6 gives an overview of some
of the remaining open research issues. Finally, Section 7 con-
cludes the paper.

* Corresponding author.
E-mail addresses: goarany@vt.edu (K. Elgoarany), toweissy@vt.eduy (M. Eltoweissy).
1363-4127/$ – see front matter ª 2007 Elsevier Ltd. All rights reserved.
doi:10.1016/j.istr.2007.02.002
 information security technical report 12 (2007) 32–43
2. Security issues in MIPv6
The security of Mobile IPv6 has been a key issue blocking the
standardization of Mobile IPv6. The goal in designing MIPv6
was simply to make IPv6 mobile and at least as secure as
MIPv4. However, MIPv6 does introduce several additional se-
curity vulnerabilities into IPv6, mainly authorization of binding
updates (BUs), in addition to other vulnerabilities inherited
from IPv4 (Sudanthi, 2003). The following subsections discuss
the background of the main Mobile IPv6 security issues.
2.1. Route optimization binding updates
Authorization of binding updates is Mobile IPv6 biggest vul-
nerability, which was introduced by the protocol’s own en-
hancement in supporting mobility, i.e., route optimization
(Aura, 2006). To understand the security implications of route
optimization, it is necessary to briefly explore the mobility
problems Mobile IPv6 aims to solve, and the design principles
it applied in this solution.
One of the basic design goals of Mobile IPv6 is to provide
a solution to Mobile IPv4’s triangular routing problem; that is
not having a direct bidirectional route between the mobile
node (MN) and any correspondent node (CN). Initially, Mobile
IPv6 protocol has attempted to solve this problem by arrang-
ing traffic to be forwarded from a permanent address to a tem-
porary one, while notifying the correspondent nodes about
the address change. The forwarding process has the advan-
tage of being transparent to the correspondents while notifi-
cations result in direct and, thus, more efficient delivery of
packets (Aura, 2006).
In a Mobile IPv6 network, the home agent (HA) intercepts
packets sent by correspondents to it and forwards them to
the care-of-address (CoA) over a bidirectional IP tunnel, i.e., en-
capsulated in another IP packet. When the mobile wants to
send packets to a correspondent, it sends them to the home
agent over the reverse tunnel. The home agent decapsulates
the packets and forwards them to the correspondent. When
the mobile moves to a new location, it tells the home agent
its new CoA by sending a binding update (BU) message. The
binding update causes the home agent to update its IP tunnels
in such a way that the tunneled packets are routed to and
from the new CoA. The binding update and the following bind-
ing acknowledgement (BA) are authenticated using a preconfig-
ured IPsec security association between the mobile and the
home agent. This operation depends heavily on the long-
term trust relationship between the mobile and its home
network.
This bidirectional tunneling is sufficient to both enable
reachability and to prevent the breaking of connections
when the mobile moves. The routing is, however, far from op-
timal. Packets between the mobile and its correspondents
have to travel via the home network, which may be far
away. To rectify this problem, Mobile IPv6 defines a mecha-
nism called route optimization (RO). The optimization requires
changes to the correspondent. It is optional to implement, al-
though most non-mobile nodes are expected to eventually
support it.
33
Fig. 1 – Route optimization in Mobile IPv6 (courtesy of Aura,
2006).
The route optimization protocol, shown in Fig. 1, employs
binding updates and binding acknowledgement messages.
When the mobile changes its current address, it sends BUs
to its correspondents to notify them about the new location.
The binding update contains the mobile node’s home address
(HoA) and its current CoA. The correspondent node acknowl-
edges the binding update and stores the location information
in a binding cache, which is effectively a routing table: it tells
that packets destined to the HA should instead be sent to
the CoA. The binding needs to be refreshed every few minutes
by sending a new BU even if the mobile stays at the same CoA.
If the cache entry expires or if it is explicitly deleted (by send-
ing a BU with zero lifetime), the correspondent node will stop
accepting packets directly from the CoA.
Although the implementation of the binding update proto-
col described above enables the mobile node to directly com-
municate to its peers, it creates serious new security
vulnerabilities. The binding updates are not authenticated
and, therefore, can be spoofed. Unauthenticated location in-
formation makes it possible for an attacker to misinform cor-
respondents about the mobile’s location and, thus, to redirect
packets intended for the mobile to a wrong destination, such
as that of the attacker, or flooding third parties with unwanted
traffic. This can lead to the compromise of secrecy and integ-
rity as well as to denial-of-service because the target nodes are
unable to communicate.
2.2. Mobile prefix and dynamic home agent discovery
Years ago, when the basic design of Ipv6 was being decided, it
was hardly possible to foresee the wireless environments that
Mobile Ipv6 nodes are currently considered to interact with.
Correspondingly, the Ipv6 functions that manage the local
link were designed with physically protected trust worthy
links in mind. However, now people are demanding to use Mo-
bile Ipv6 nodes with public radio networks, such as Wireless
LANs at airports, hotels, and cafes. Even though the actual
links may be somewhat protected using various authentica-
tion, access control and encryption mechanisms, some of
the nodes on the link may not be trustworthy, in addition to
the well-known deficiencies in the security schemes of some
34 information security technical report 12 (2007) 32–43

of the wireless technologies, leading the wireless link in gen-
eral to easily become the weakest link in terms of system
and network security. It is fairly easy to setup a phony Wire-
less LAN base station for example, leading to various kinds
of access stealing, denial-of-service, and traffic snooping
attacks (Arkko et al., 2002).
On the other hand, Mobile Ipv6 provides support for multi-
ple home agents, and a limited support for the reconfiguration
of the home network. In these cases, the mobile node may not
know the IP address of its own home agent, nor sufficient in-
formation about its home network, and even the home subnet
prefixes may change over time. The mechanism employed by
Mobile Ipv6 nodes to learn new information about their home
subnet prefixes, known as mobile prefix discovery, now creates
vulnerability by the possible leakage of critical information
about the home network topology, and prefix lifetimes, to un-
trustworthy nodes such as those described above (Perkins,
2004).
2.3. Home address option in payload packets
 Preventing a CN from communicating with some or all
nodes.
 Preventing an HA from serving legitimate MNs.
c Disclosure of sensitive information
 Disclosure of nodes serving as home agents in a network.
3.2. Classification of attackers
The following classes of attackers are considered as a basis for
the types of threat scenarios which are described in the fol-
lowing subsection.
 An arbitrary node, anywhere in the Internet, launching an
attack against an MN, a CN, or an HA.
 An attacker located on the same (wireless) link as the MN.
 An attacker located on the same link as the CN.
 An attacker located on the same link as the HA.

As described in Section 2.1, tunneling of data packets from CNs to

3.3. Threat scenarios
mobile nodes is only employed initially, before the communica-
tion is carried directly between the two end parties. Other than
In this subsection, a number of specific threat scenarios are
BUs, Mobile IPv6 employs a mechanism known as home address
presented. The scenarios are arranged by the capabilities of
option (HAO), which is used in packets sent by a mobile node
an attacker, using the same order as the classification above,
while away from home, to inform the correspondents of the mo-
as the well as the type of threats overviewed earlier. The focus
bile node’s home address, which is later validated by each corre-
here was upon the threats scenarios that are specific to Mobile
spondent using its binding cache entry (Perkins, 2004).
IPv6 mechanisms, while non-specific general threats are left
The following section presents the security threats of Mo-
out. To make cross-referencing easier, the scenarios can be
bile IPv6, which are projected by the problems discussed above.
classified as shown in Table 1 and 2.

3.3.1. Threats presented by attackers located anywhere

3. Mobile IPv6 security vulnerabilities
in the Internet
(Mankin et al., 2001)
This subsection describes the main scenario, threats and ef-
fects that deal with manipulating the binding cache at the CN.
This section identifies the security vulnerabilities that Mobile
IPv6 can bring. The described threats and scenarios have be-
come a driving force to a new set of goals that Mobile IPv6
was required to address in order to be standardized. The fol-
lowing subsections include a classification of threat, types of
Table 1 – Mobile IPv6 & security acronyms
attackers and a discussion of possible threat scenarios.
AH Authentication header
3.1. Classification of threats BA Binding acknowledgement
BU Binding update
CN Correspondent node
In the absence of a security association between most MN–CN
CoA Care-of-address
pairs, there are multiple vulnerabilities that the MN, the CN, or DoS Denial-of-service
the HA or home network, become exposed to. Based on the DDoS Distributed denial-of-service
problems discussed in the previous section, the threats can ESP Encapsulation security payload
be classified as follows. HA Home agent
HAO Home address option
HoA Home address
a Tampering with the binding cache entries
HoT Home test message
 Tampering binding cache entry at a home agent.
IPsec IP security protocol suite
 Tampering binding cache entry at a correspondent node. IKE Internet key exchange
 Tampering binding cache entry at the previous access router, MN Mobile node
acting as a temporary packet forwarding home agent. MITM Man in the middle
MIPv6 Mobile IPv6
b Denial-of-service (DoS) MML-IPsec Mobile multi-layered IPsec
RR Return routability
 Preventing an MN from communicating with some or all
SA Security association
nodes.
 information security technical report 12 (2007) 32–43
Table 2 – Classification of main Mobile IPv6 threat scenarios (Mankin et al., 2001)
Attacker location Attacks
Anywhere in the Internet 1. Tampering with MN /CN binding
cache entries
2. BU flooding
MN/CN link 1. Sending spoofed BU/BA
2. BU flooding
HA link 1. Acting as the HA
2. Tampering with HA binding
cache entries
3. Sending spoofed BU/BA
4. BU flooding
Scenario 1 Attacker knows MNs home address and both end-
points of any session
An MN and a CN have an ongoing session. A malicious node/
attacker determines the MN’s home address through either
Mobile Ipv6 advertisement mechanisms, such as mobile
prefix/dynamic home agent discovery, or through the home
address option in payload packets.
3.3.1.1. Tampering with the CN binding cache.
a Threat
The attacker can send a BU to the CN using the acquired HoA
and a malicious CoA. The CN would believe that the MN has
moved and hence has a new CoA. It updates the entry for
the MN in its binding cache.
b Effect
The packet stream for the ongoing session from the CN to the
MN now is diverted to the malicious node. The MN in this case
may be on its home network and not have any CoA or it may
be on another network and have another CoA. The attacker in
this case would only need to know about the MN’s home address
and any CN that the user may communicate with. The attacker
could be anywhere on the Internet and does not have to be on
the same link or network as the MN. Even if the MN eventually
realizes that it is no longer receiving further packets from the
CN and sends another BU to the CN, this type of attack still poses
a DoS threat. Moreover, the intruder could also send a BU to the
MN, supposedly from the CN, and thus insert himself as a man
in the middle (MITM) for traffic between the two.
3.3.1.2. Tampering with the MN binding cache. The changing
the binding cache entry for an Ipv6 MN in the CN was dis-
cussed. However an MN can also be considered as a CN from
the perspective of being an end-point in a session that is being
terminated at the MN and originated from another MN. In
such a case the MN (now in the role of a CN) also has a binding
cache entry for the other MN. The same threats discussed
above are now opened up on the MN similarly.
3.3.1.3. BU flooding.
a Threat
A malicious node or virus could keep sending fake BUs to any
CN, the MN itself or the HA, at a very rapid rate and thereby
create unnecessary state at the Mobile IPv6 node.
35
Effect Attack requirements
MITM/DoS Knowledge of home address,
DoS and any CN
MITM/DoS Only the knowledge of any CN
DoS
Masquerade/DoS No additional knowledge
MITM/DoS is required
MITM/DoS
DoS
b Effect
This can easily cause the binding cache memory to become in-
undated with entries for nodes that have no real meaning and
thereby preventing a valid node’s entry being created in the
binding cache. Thus, it poses another DoS threat.
3.3.2. Threats presented by attackers located in the same
subnet/link as the MN or the CN
The type of medium accessed by the MN at any point in
time provides various threat possibilities. If the access me-
dium is a shared multiple access network, such as a Wire-
less LAN for example, the attacker could do passive
monitoring of the packets, leading to the interception of
critical information about the ongoing sessions of the MN.
In the case of the attacker on the same link of the MN, it
is even easier for the attacker to insert himself as an
MITM and intercept and modify packets sent between the
MN and the CN. This subsection describes the main sce-
nario, threats and effects that deal with manipulating the
knowledge of CNs.
Scenario 2 Attacker knows a CN communicating with the MN
An MN and a CN have an ongoing session. A mali-
cious node/attacker determines the CN with the
MN through passive monitoring.
3.3.2.1. Sending spoofed BUs.
a Threat
By being able to passively monitor the traffic, the attacker
could learn about the CNs that the MN is communicating
with and also determine to which CNs the MN is sending
BUs. The attacker could in such a case send a spoofed BU
packet to the same CN. Furthermore, it can very easily send
a spoofed BU to the MN, claiming that the CN is currently on
the same link as the MN (i.e., co-located with the attacker).
b Effect
Such attack can cause the traffic from the CN to the MN be
routed elsewhere. Changing the route of packets from CN to
MN is a serious threat. It can be classified as a DoS attack on
the MN or the CN. The latter case where the attacker sends
a BU to both the MN and the CN is considered to be an MITM
attack, where the attacker could possibly alter the contents
of the traffic.
36 information security technical report 12 (2007) 32–43
3.3.2.2. Sending spoofed BAs.
a Threat
Being able to passively monitor the traffic and learning about
the CNs the MN is communicating with and to which it is
sending BUs also poses the threat of allowing the attacker to
synchronize with the MN, such that when MN sends a BU
the attacker would reply to MN with a spoofed BA, different
than the true BA it would receive from the CN (Status, Lifetime
or Refresh fields).
b Effect
This attack can result in (1) MN sends unnecessary BU’s (sub-
ject to rate limiting of sending BU’s) or (2) MN does not send
a BU that is necessary. As further effects of (2) unnecessary tri-
angular routing takes place or MN is not reachable at all, lead-
ing to a DoS effect.
3.3.2.3. BU flooding. A malicious node on the same link of the
MN or the CN could keep sending fake BUs to the CN, or the
MN itself, at a very rapid rate and thereby create unnecessary
state at the Mobile IPv6 node. The threats and its effects are
the same as those described in subsection 3.3.1.3.
3.3.3. Threats presented by attackers located in the same
subnet/link as the HA
An attacker on the same subnet of the mobile node’s home
agent does not require additional information about the MN’s
home address, in addition to a relatively easy chance in the
finding any CN which the MN may be communicating with.
This poses multiple drastic threats, which are detailed below.
Scenario 2 Attacker monitors the HA and the MN communi-
cating with it
An MN frequently communicates with its HA. A malicious
node/attacker on the same subnet/link of the HA can be mon-
itoring this communication. This case can be considered of
the most dangerous, since the malicious node would not
need any information about the MN’s home address before
it starts mounting its attacks.
3.3.3.1. Acting as the HA.
a Threat
If the attacker is on the same subnet as the HA of an MN, the
attacker himself could possibly pretend to be the HA (while
the MN is roaming), and begins to intercept the BUs from
the MN and its destined traffic which originates from other
CNs. The attacker could spoof the HA and send a binding re-
quest to the MN even when it is not required.
b Effect
Masquerading the HA’s identity can lead to drastic effects,
which open the door for various MITM attacks, including those
described in the previous subsections, in addition to DoS attack
through flooding the MN could by binding requests from an at-
tacker with spoofed source IP addresses. In this case, DoS can
also be simply mounted by rejecting its binding updates.
3.3.3.2. Tempering with the HA binding cache.
a Threat
A malicious node on the home subnet can send a binding up-
date to the HA for an MN with false parameters, including
a lifetime set to zero.
b Effect
This latter attack described will thereby lead the HA into be-
lieving that the MN has returned to its home network and
hence does not need a binding to some COA. This will thereby
result in causing the binding cache entry for the mobile to be
deleted.
3.3.3.3. Sending spoofed BUs/BAs.
a Threat
After intercepting BUs communicated between the HA and
the MN, if the attacker was able to insert himself on the
path between the HA and a CN communicating with the MN,
it could start sending a spoofed BU packets the CN.
Being on the path between the HA and the CN, also allows the
attacker to simply monitor the traffic and learning about the
CNs the MN is communicating with and to which it is sending
BUs. This passive monitoring again poses the threat of allowing
the attacker to synchronize with the MN, such that when MN
sends a BU the attacker would reply to MN with a spoofed BA,
different than the true BA it would receive from the CN.
b Effect
This attack of sending spoofed BUs can lead to the changing
the route of packets from CN to MN, which is classified as
a DoS attack on the MN or the CN.
The latter case can be exploited by the attacker in sends a BU
to the CN and BA to the MN, which is considered to be an
MITM attack, where the attacker could possibly alter the
contents of the traffic. Another use is to simply prevent the
MN–CN communication, which falls under the DoS attack
category.
3.3.3.4. BU flooding. A malicious node on the same link of the
HA could be able to reach both the MN and CN, while monitor-
ing the BUs exchanged during the MN sessions. This would
allow the attacker to keep on sending fake BUs to the CN, or
the MN itself, at a very rapid rate and thereby create unneces-
sary state at the Mobile IPv6 nodes. This threats and its DoS ef-
fect are the same as those described in subsection 3.3.1.3.
3.3.4. Other threats
A number of other threats are present, but are mostly related
to the threats discussed in this section, which can be extended
through the additional information that the attacker can gain,
such as the home address option in payload packets which
was mentioned earlier.
According to the Mobile IPv6 specifications, a node receiv-
ing a packet that includes a home address option MAY imple-
ment the processing of this option by physically exchanging
the home address option field with the source IPv6 address
 information security technical report 12 (2007) 32–43
in the IPv6 header (Perkins, 2004). However, an attacker can
simply spoof the home address option in packets sent to
a CN causing the CN to swap the source address with the ad-
dress contained in the home address option. This causes the
CN to become a packet reflector in attacks on nodes whose ad-
dresses may be known. Using the CN as a packet reflector
would allow the attacker to mount a distributed denial-of-service
(DDoS) attack, while to hide itself, which makes it harder to
successfully shut down the attack in the absence of knowl-
edge about its origin.
Obtaining information about the home address of an MN
would also expose the structure of the operator’s network,
which is not desirable. It would also allow an attacker to deter-
mine the routers acting as home agents and mount DoS at-
tacks or other types of attacks on these routers and thereby
cause these routers to be unable to forward packets to MNs
that they are intended to serve.
The security vulnerabilities and threats discussed above
were the motive for a number of goals for the developed Mo-
bile IPv6 security design. These goals and other general secu-
rity requirements will be presented in the following section.
4. Security goals and general requirements
One of the fundamental goals of IPv6 was to provide mobility
support, through an implementation that is designed into the
protocol from the ground up, rather than through extensions
that may not enable an optimal integration with the underly-
ing mechanisms, as is the case with IPv4 and its Mobile IP
extension.
As with mobility, there were many security extensions to
the IPv4 protocol that provided security, such as IPsec and
HTTPS, but being that they are not part of IPv4 itself, these ex-
tensions are not implemented pervasively. Thus, the assump-
tion was that since IPv6 has security, IPsec in particular, built
into the protocol itself, the Mobile IPv6 default security mech-
anisms, though may not be perfect, would provide better pro-
tection against many problems that persist in Mobile IPv4
(Sudanthi, 2003). Accordingly, the following general require-
ments were defined as the basis of the initial Mobile IPv6 secu-
rity design.
4.1. General requirements of Mobile IPv6 security
(Mankin et al., 2001)
A. Should be no worse than Mobile IPv4 as it is today.
B. Should be as secure as if the mobile node was on the home
link without using Mobile IP.
C. Should optimize the number of message exchanges and
bytes sent between the participating entities (MN, CN,
and HA), since many MNs are expected to operate over
bandwidth constrained wireless links.
However, as discussed in the previous sections, it became
soon apparent that the same mechanisms employed by Mo-
bile IPv6 to support mobility introduce a number of high secu-
rity risks that must be addressed at first in order to achieve
37
these requirements, and thus are of no less importance. These
goals are described below.
4.2. Mobile IPv6 security goals (Perkins, 2004)
A. Securing binding updates.
B. Securing mobile prefix and dynamic home agent discovery.
C. Securing the mechanisms that Mobile IPv6 uses for trans-
porting data packets.
A number of security solutions were developed to meet the
above goals and requirements. The following section presents
an overview of the main security solutions.
5. Mobile IPv6 security solutions
This section describes the evolution of Mobile IPv6 security so-
lutions. The focus of the majority of solutions is mostly on the
authentication of binding updates.
5.1. IPsec and IKE standard solution
In this subsection, an overview of the standard security proto-
cols, IPsec and IKE are given, followed by a discussion of their
use in securing binding updates and their shortcomings.
5.1.1. Overview of IPsec
IPsec is a suite of protocols ‘‘designed to provide interoperable,
high quality, cryptographically-based security for IPv4 and
IPv6’’ (Kent and Atkinson, 2005a). IPsec provides security ser-
vices, such as access control, data integrity, authentication,
confidentiality (encryption), and replay protection to the IP
layer as well as the layers above.
IPsec could protect one or more paths between two pairs of
hosts, between a pair of security gateways (a security gateway
is an intermediate element that implements IPsec), or be-
tween a host and a security gateway (SG). The granularity at
which the security services are offered for such purposes is
defined by the administrator. For example, it is possible to cre-
ate a single tunnel (IP encapsulation) for all TCP connections
between two hosts, as well as dedicated tunnels for each of
the connections.
The key concept behind this idea is called a security asso-
ciation (SA). An SA is ‘‘a simplex connection that affords secu-
rity services to the traffic carried by it’’ (Kent and Atkinson,
2005a). An SA is uniquely identified by a security parameter in-
dex (SPI), an IP destination address, and a security protocol
(authentication header or encapsulating security payload).
Authentication header (AH) and encapsulating security pay-
load (ESP) are secure protocols provided by IPsec to form SAs
(Kent, 2005; Kent and Atkinson, 2005b). The first provides
connectionless integrity, data origin authentication, and an
optional anti-replay service. The second may provide confi-
dentiality and limited traffic flow confidentiality, as well as
all the functionality provided by the AH. These protocols can
be used alone or in combination. Each supports two modes
of use: transport mode and tunnel mode. The former provides
protection primarily for upper layer protocols, while the latter
38 information security technical report 12 (2007) 32–43
is used to encapsulate IP packets. As a result, two kinds of SA
are defined: tunnel and transport. If the path to protect has in
its ends an SG then tunnel mode must be used. Transport
mode can only be used when communicating host to host.
It is necessary that hosts support both modes while SGs sup-
port only tunnel mode (however an SG can be configured as
a host, for that purpose must support the two modes as well).
Each SA defines the algorithms for encryption, authentica-
tion, hash and key exchange (attributes) for protecting a partic-
ular path. How these security attributes are communicated
from one end to the other is maintained and established by
other specialized protocols, such as ISAKMP, OAKLEY, SKEME,
or a combination of them such as IKE, which is described in fol-
lowing subsection.
5.1.2. Overview of IKE
Internet Key Exchange (IKE) establishes a secure framework
for the distribution of public keys. In addition, it defines how
those keys will be generated. This combines ISAKMP (a proto-
col to establish a framework authentication and key ex-
change), Oakley (which describes a series of key exchange
defining in detail the services provided by them), and SKEME
(a key exchange technique that provides anonymity, reputa-
bility, and quick key refreshment). IKE’s main objective is to
‘‘obtain authenticated keying material for use with ISAKMP,
and for other SAs such as AH and ESP’’ (Harkins and Carrel,
1998). So, after an IKE negotiation the parties involved can
use the keying material to establish different SAs.
IKE’s main functionality consists of two phases: In Phase 1,
the two peers involved in the communication establish the
ISAKMP SA. During Phase 2, the SAs are negotiated on behalf
of services such as IPsec, or any other service that needs key
material and/or parameter negotiation. Phase 1 can be accom-
plished either in Main mode or Aggressive mode. The basic
difference between them is that Main mode provides identity
protection, while Aggressive mode does not. Phase 2 is per-
formed with Quick mode. An additional mode, New Group
mode, is used to change the group for future negotiations
(used for Diffie Hellman exchange during Phase 1). The
ISAKMP SA is bidirectional that is to say that once Phase 1 is
finished, both parties can initiate Quick mode. The attributes
defined by the SA are the encryption algorithm, hash algo-
rithm, authentication method, and the group for the Diffie
Hellman (DH) exchange.
Main mode consists of the exchange of three sets of two
messages: the first pair negotiates the security attributes in or-
der to form the SA; the second set exchanges the DH public pa-
rameters and identities; and the third pair authenticates the
DH exchange. In Aggressive mode, the first two messages ne-
gotiate policy as well as exchange DH public values and iden-
tities. The third message authenticates the responder. The
last message authenticates the sender and provides proof of
participation. For both modes the authentication can be ac-
complished with any of the four following methods: digital
signature, public key encryption, revised mode of public key
encryption and pre-shared key (Harkins and Carrel, 1998;
Cladera et al., 2000).
Quick mode is not a complete exchange by itself – it de-
pends on Phase 1. It is part of the SA used to generate keying
material for other non-ISAKMP SAs. All payloads are
encrypted, and a hash is used to authenticate the message
and provide liveliness proof.
5.1.3. IPsec and IKE uses in Mobile IPv6
In the initial design of Mobile IPv6, the straightforward secu-
rity solution was to use the IPsec protocol suite, which is
a mandatory part of IPv6, along with IKE in the establishment
of secure channels for Mobile IPv6 communications.
Currently, IPsec is used in protecting messages exchanged
between the mobile node and the home agent, and no new
security mechanism exists for this purpose. The use of the
mandatory IPsec authentication header (AH) and the encapsu-
lating security payload (ESP) and a key management mecha-
nism help to ensure the integrity of the binding update
messages between the MN and the HA.
To prevent the MN from sending a binding update for an-
other mobile node using its association, the home agent also
verifies that the binding update message contains the correct
HoA, either as the source of the packet or in an optional field at
end of the packet. Such a check is provided in the IPsec
processing, by having the security policy database entries
unequivocally identify a single security association for pro-
tecting binding updates between any given home address
and the HA. In order to make this possible, it is necessary
that the HoA of the mobile node is visible in either the BU or
the BA. The home address is used in these packets as a source
or destination, or in the home address destination option of
the packets (Perkins, 2004; Cladera et al., 2000).
Automatic key management with IKE may be supported as
well in securing the MN–HA communications. When IKE is
used, either the security policy database entries or the Mobile
IPv6 processing relies on the unequivocal identification of the
IKE Phase 1 credentials which can be used to authorize the
creation of security associations for protecting binding up-
dates for a particular HoA. These mappings may be main-
tained, as a locally administered table in the home agent. If
the Phase 1 identity is a Fully Qualified Domain Name
(FQDN), secure forms of DNS may also be used (Perkins,
2004; Harkins and Carrel, 1998).
However, the biggest security vulnerability of MIPv6, as dis-
cussed earlier, is the authentication and authorizing of binding
updates sent from the mobile nodes to the correspondents. In
solving this problem, the straightforward application of stan-
dard Internet security protocols, namely IPsec and IKE, proved
to have multiple shortcomings (Aura, 2006), which are dis-
cussed in the following section.
5.1.4. Shortcomings
The obvious solution to the BU spoofing is to authenticate the
binding updates exchanged between HA and MN, and MN and
CNs. A typical authentication system would use a suite of
strong cryptographic authentication protocols and a certifica-
tion infrastructure, such as IPsec and IKE. The problem is that
the authentication needs to work between any MN and any
correspondent in the Internet (mobile or not). No infrastruc-
ture-based solution currently exists that could be used to au-
thenticate all IPv6 nodes. Neither is it realistic to suggest
creating such a service for the needs of Mobile IPv6 (Aura,
2006). This means that using the conventional authentication
mechanisms, such that of IPsec/IKE would confine the Mobile
 information security technical report 12 (2007) 32–43
IPv6 route optimization to intra-organizational use where the
required security services are in place.
Moreover, the generic authentication protocols have usu-
ally been designed with general-purpose computers and
application-level security requirements in mind. One of the
main shortcomings of the integration of IPsec/IKE into MIPv6
is that the processing overhead of these protocols can be too
high for low-end mobile devices and for a network layer sig-
naling protocol. (There are, nevertheless, some situations
where it is possible, and advisable, to apply the strong generic
authentication solutions. In closed user groups and high secu-
rity environments, it may be possible to setup an IKE and to re-
quire the BU to be strongly authenticated between the group
members.)
For the above reasons, it became essential to consider
other unconventional end-to-end authentication methods.
Two of the main research directions in this field are discussed
in the following sections.
5.2. Return routability solution
One of the main research directions in finding alternatives to
conventional application of standard infrastructure-based secu-
rity protocols, described in the previous subsection, is to de-
velop solutions that do not rely on an end-to-end global
infrastructure. Since these solutions do not require any spe-
cial security infrastructure, they are called infrastructureless
authentication. Although their authentication has shown to
be not necessarily as strong as that enabled by the infrastruc-
ture-based IPsec/IKE in closed networks, it is, nevertheless,
better than no authentication (Aura, 2006).
Moreover, what enables the applicability of an infrastruc-
tureless solution is that the security requirements for BU au-
thentication are unusually weak. As mentioned earlier, one
of the fundamental general security requirements stated in
the IETF working group was that the Mobile IPv6 protocol
should be at least as secure as the current non-mobile IPv4 Internet.
This means that a proposed solution need not be confined to
designing a traditional strong security protocol. On the con-
trary, the ambition was limited to making sure that Mobile
IPv6 does not introduce any new major vulnerability to the
Internet, and was not to create a strong general-purpose au-
thentication protocol (Aura, 2006).
In this context, a number of infrastructureless solutions
were proposed, of which return routability (RR) was selected
by the IETF to be now a part of the Mobile IPv6 suite, replacing
IPsec/IKE in the authentication of binding updates to corre-
spondent nodes.
5.2.1. Standard return routability protocol
Return routability authentication method is based on the fact
that routing in the Internet is semi-reliable. It is difficult for
a remote attacker to change the route of packets that do not
travel via the attacker’s network. Thus, in order to sniff or in-
tercept a packet, the attacker needs to be on its route. The first
version of the routing-based BU authentication protocol is
shown in Fig. 2. The idea is that, after the mobile initiates
the BU protocol (message 1), the correspondent sends a secret
value as plaintext to the mobile’s home address (message 2).
The home agent intercepts the message and forwards it to
39
Fig. 2 – Return routability for Mobile IPv6 (courtesy of
Aura, 2006).
the mobile via a secure tunnel. The mobile then uses the se-
cret to compute a message authentication code for the binding
update (message 3). This mechanism is called the return rout-
ability test for the home address (RR for HoA) because the mobile
must return to the correspondent (a function of) a secret value
sent by the correspondent to the HoA. In effect, the correspon-
dent verifies that the mobile is able to receive messages at the
home address.
In the Mobile IPv6 standard terminology, message 2 is
called the home test message (HoT) and the secret value is the
home keygen token. Messages 3 and 4 are simply the binding up-
date (BU) and the binding acknowledgement (BA), respectively.
Although a number of shortcomings were found in both its
security performance and its QoS support, discussed in sub-
sections 5.2.2 and 6.1, there are, nevertheless, strong argu-
ments in favor of the RR protocol design.
First, the number of potential attackers and targets is dra-
matically reduced. Without authentication, any Internet node
could spoof binding updates to hijack connections between
any two Internet nodes. In this new protocol, the attacker
must be on the route of the hijacked connection. There are
typically only 10s or 100s of nodes on this route, including
both routers and hosts on the local networks of the end nodes.
Compared with the situation where any malicious Internet
node can mount an attack, it is much less likely that one of
this limited set of nodes would do so. The fewer and the
more local the potential attack sources are, the easier it is
also to gain control of them if attacks sometimes occur. An-
other way to explain the same idea is that a malicious Internet
node is able to target only the connections that pass though its
local network. For a typical attacker, such as a compromised
router or host, the number of such connections is small.
This reduction in the scale of the potential damage alone
means that deployment of the Mobile IPv6 would no longer
be a danger to the Internet’s stability.
Second, the protocol fulfills the explicit design goal of being
as secure as the current Internet without mobility. Assume
that the mobile node never leaves its home network and al-
ways communicates directly from the home address. In that
40 information security technical report 12 (2007) 32–43
case, an attacker on the route between the home address and
the correspondent can spoof, intercept and sniff packets be-
tween them, and it can execute all the same attacks that are
possible by exploiting the weaknesses of our BU authentica-
tion protocol. Therefore, it is argued that the simple protocol
of Fig. 2 is sufficient for authenticating the sender of a binding
update.
To summarize, the RR protocol protects against the spoof-
ing of binding updates from the MN to the CN, except if the at-
tacker is located on the CN–HoA route or at the local network
of the CN, which is further discussed in the following subsec-
tion. An attacker anywhere else in the Internet, for example,
in the local network of the CoA, cannot spoof the binding
updates.
5.2.2. Shortcomings
The RR protocol was found to have some shortcomings in both
its security performance and QoS support. This subsection
mainly discusses the security shortcomings and gives an over-
all security evaluation of the RR protocol, while shortly men-
tions its shortcomings in supporting QoS.
To analyze the security of the return routability protocol,
one should evaluate its protection against the following two
main types of attacks: impersonation attacks against a mobile
node or a correspondent node, and flooding attacks against
third parties.
Mobile IPv6 uses the home address as an identifier for a mo-
bile node. Impersonation attacks are thus based on claiming
ownership of another node’s IP address. The return routability
procedure has proved to able to prevent such attacks. How-
ever, if an attacker happens to be on the critical path (on the
path from the correspondent node to a stationary victim or
from the correspondent node to the victim’s home agent), it
can eavesdrop on the returning HoT message, and learn the
information that is necessary for spoofing the BU, leading to
its breaking of the protocol. The impersonator can produce
its own care-of-address Keygen Token by sending the victim’s
correspondent node a false CoA, which can eventually allow
the attacker to send an authenticated binding update message
on behalf of the victim.
However, the described susceptibility to attacks from the
routing path between two communicating nodes was not
found to be an inconsistency with the design objective; to
make the security of a mobile Internet as secure as the cur-
rent, non-mobile Internet. This is because an on-path attacker
can already compromise the communications of two nodes
today, and is accordingly able to block communications, or in-
terfering by ingesting its own packets.
The similarity between the home address test and the
care-of-address test belies the different purpose of these
exchanges. While the former is to prevent impersonation
attacks, the latter tackles the problem of flooding attacks by
probing a mobile node’s presence at a new care-of address.
As with the home address test, a number of care-of-address
test scenarios can be found where the care-of-address test
has no effect. Namely, it cannot protect against attackers
that are on the path between the victim and the correspondent
node at which traffic is to be redirected. In this scenario, the
attacker can perform a care-of-address test on behalf of the
victim further down the path.
Again, the exposure to on-path attacks corresponds to the
objectives of the Mobile IPv6 security design. Flooding attacks
initiated by an on-path attacker are already a threat in the
non-mobile Internet: An on-path attacker could initiate, say,
a large file download from an FTP server on behalf of a victim
if the attacker is on the path from the FTP server to the victim.
In this case, the attacker would probably do a TCP handshake
using the victim’s IP address. As it is on-path, the attacker
could hear the messages from the FTP server, and it could
respond to them. The attacker would so learn the TCP Initial
Sequence Number, which it needs to later spoof acknowledge-
ments on behalf of its victim.
With these above considerations, the care-of-address test
inherent in the RR protocol can be still considered to be an ef-
fective limitation of flooding attacks to exactly those situa-
tions in which comparable flooding attacks are already
possible today. However, the limitation to on-path attacks
alone is insufficient to prevent a related style of attack that
is called ‘‘space- and time-shift attacks’’. In these attacks,
the perpetrator taps the critical wire in order to obtain the se-
cret information it needs, and it then moves to a saver place
and starts an attack from there. The attacker could also wait
for a better point of time. It may even install a binding on
behalf of a victim before the victim starts communicating.
Mobile IPv6 requires mobile nodes to refresh active care-of-
address registrations in intervals of at most 7 min in an at-
tempt to mitigate the threat of space- and time-shift attacks.
To combat the previously discussed problems, a number of
improvements or optional alternatives have been suggested to
the standard RR protocol. The primary driver between these
improvements is usually further reduction of signaling mes-
sages and latency, but other improvements such as better se-
curity have also been suggested.
5.3. Cross-layering security approach
As mentioned earlier, Mobile IPv6 nodes are also expected to
interact with several wireless environments. For wireless net-
works, smart forwarding and processing of packets are critical
for overcoming the effects of the wireless links, especially
highly variable delay and error rates. Several studies have
shown that techniques such as smart scheduling with respect
to the type of data being sent and regulation of TCP acknowl-
edegment information, can greatly improve end-to-end per-
formance in a wireless network (Choi et al., 2005). However,
these services cannot be provided if end-to-end encryption
is used, such as in IPsec, because the information needed by
these algorithms resides inside the portion of the packet
that is encrypted, and can therefore not be used by mobile
routers. This problem still remains to be one of the fundamen-
tal obstacles against applying the end-to-end infrastructure-
based IPsec security design for Mobile IPv6, even where
applicable, which motivated the search for alternative solu-
tions, such as the return routability protocol, described in
the previous section.
Another research direction exists, which instead of provid-
ing a restricted infrastructureless solution that aims to replace
IPsec/IKE where it fails, this direction aims to find solution
that modifies IPsec/IKE in a way so that so that certain por-
tions of the datagram may be exposed to intermediate
 information security technical report 12 (2007) 32–43
network elements, enabling these elements to provide perfor-
mance enhancements (Choi et al., 2005). This approach is gen-
erally called cross-layering (Aune, 2004).
5.3.1. Mobile multi-layered IPsec
The need to have nodes inside the network examine packet
payloads to perform smart packet processing or perform
packet classification is in direct conflict with the current Inter-
net model of security implemented by the IPsec protocol suite
(Choi et al., 2005). As described earlier, IPsec supports a variety
of operational modes including packet authentication, packet
encryption, or both. In the most secure mode, tunnel mode,
the entire IP packet is encrypted and encapsulated with
a new IP packet header. Therefore, intermediate nodes in
the network do not have access to the original IP header infor-
mation, nor the information contained in any of the transport
layer or application layer protocols. This precludes the net-
work from performing smart packet processing and packet
classification to improve end-to-end performance.
A flexible solution to this problem is defined in the Multi-lay-
ered IPsec (ML-IPsec) protocol (Choi et al., 2005). This protocol al-
lows a user to define zones within an IP packet. Each zone is
encrypted and authenticated with its own security association.
Each zone may be accessed (decrypted) by different network el-
ements. This requires SAs to be established between a client
and several nodes in a network, each of which can decrypt
a certain portion of the IP packet while being unable to view
the entire packet. In this way, portions of a datagram may be
encrypted end-to-end, while portions may be read and oper-
ated upon by network elements providing performance en-
hancements. However, the ML-IPsec, as defined in (Zhang
and Singh, 2000) and extended in (Zhang, 2006), is designed
for static environments and does not deal with mobility.
An initial version of ML-IPsec was extended in (Choi et al.,
2005) to deal with mobility and make it suitable for wireless
networks. A suite of protocols was created, which combines
the simplified version of ML-IPsec, and an efficient key distri-
bution protocol for initializing secure wireless sessions and
two protocols for managing mobility for these secure sessions.
This protocol suite is called Mobile ML-IPsec (MML-IPsec) (Choi
et al., 2005).
5.3.1.1. Mobility support. An integration model is proposed in
(Choi et al., 2005) to integrate Mobile IP and MML-IPsec (Fig. 3).
This model does not require changes to the client software,
and does not require IPsec tunnels to be re-established after
CN
MN Internet HA
MML-IPsec Processing Unit Mobile IP Tunnel MML-IPsec Tunnel
Fig. 3 – Integrating Mobile IPv6 and MML-IPsec (Choi et al.,
2005).
41
each handoff. To enable Mobile IPv6 registration messages
to be received by the CN when an IPsec tunnel is in place be-
tween the MH and HA, an additional routing entry is added
in the MH and the fact that route selection chooses the route
having the longest prefix match among multiple matched en-
tries is leveraged. When an agent advertisement is received by
an MH, it adds a route entry for the CN. The new route entry
specifies the CN address as the gateway for all packets des-
tined to the CN. After adding this route, the Mobile IP registra-
tion message addressed to the CN will match the new route,
and therefore be sent directly to the CN, instead of using the
old entry through which packets are encrypted. The above fig-
ure depicts the integration model between MML-IPsec and
Mobile IPv6.
5.3.2. Key management
While ML-IPsec (Zhang and Singh, 2000) was a promising
start, it has limitations and several unknowns. First, it re-
quires that SAs (secret keys, algorithms, parameters, etc.) be
established between multiple elements for a single data ses-
sion. This requires an efficient key distribution algorithm
which has yet to be defined. Second, mobility is not sup-
ported. The mobility requires that new SAs be established
as a mobile host moves during a data session. These modifica-
tions must be performed quickly so that sessions are not dis-
rupted during a handoff. Thus, it becomes more complex in
supporting mobility, particularly with Mobile IP (Choi et al.,
2005) because in the MML-IPsec system, the huge number of
SAs would due to the nature of data applications expected
to be operated.
As previously discussed, IKE supports key distribution and
mutual authentication between two nodes but requires exten-
sions to support the multiple SAs used in ML-IPsec and is not
suitable for mobility. An efficient method of key distribution
and authentication between a home network, security server
in a foreign network, and a mobile host is presented. However,
this work does not address the distribution of multiple keys re-
quired for an ML-IPsec, does not account for mobility, and does
not provide any implementation or performance insights.
To solve these problems, efficient key distribution and
mobility management schemes were proposed in (Choi
et al., 2005) for MML-IPsec integrated with Mobile IP. The paper
includes procedures for session initialization (ML-IKE) and
mobility management. The goal is to enable fast handoffs
while maintaining MML-IPsec sessions. In the proposed
model, the nodes involved in the MML-IPsec session are the
MH, HA, and FA. The MH and HA have access to both zones
in the MML-IPsec packets; the FA serves as the intermediate
node and has access to the first zone of the packet containing
the TCP/IP header. The key management protocols are re-
sponsible for establishing the required SAs between these
nodes, and for enabling mobility.
6. Open research issues
A more secure Mobile IPv6 route optimization scheme may be
possible in the future, if improvements in other areas of the
Internet technologies remove some of the plain IPv6 vulnera-
bilities. For instance, the use of Secure Neighbor Discovery on
42 information security technical report 12 (2007) 32–43
the network where one of the end-points resides, removes
some of the existing threats (Arkko and Voght, 2004).
Yet, a security association alone does not suffice as an en-
hanced security mechanism. General security associations
typically do not show that a node owns a specific IP address,
a property that is desired in the case of route optimization
to authenticate home addresses. Certificate technology, for in-
stance, usually does not track the correct IP address assign-
ments of a large group of users.
Also, the validity of care-of addresses cannot be ensured by
a security association alone. The security association must
either be accompanied by a trust relationship, or care-of
addresses must be checked otherwise. This shows that en-
hancements to the security of route optimization are likely
to employ Mobile IPv6 specific technology rather than gen-
eral-purpose security tools (Arkko and Voght, 2004).
In addition to above, many research problems exist that
can be divided in the following classification.
6.1. Security
In the following, some of the potential research directions for
new security schemes are listed.
(a) Most of the proposed security protocols for Mobile IPv6, in-
cluding the one in the standard, depend on the special re-
lationship between the home network and the mobile. It is
a completely open question, what kind of security mecha-
nisms would be needed if the home agent did not trust the
information provided by the mobile.
(b) Finding care-of address verification mechanisms that em-
ploy lower layer assistance or secure Neighbor Discovery
(Arkko and Voght, 2004).
(c) Finding route optimization security mechanisms that do
not require a reconfiguration of the shared secret between
mobile node and its correspondent node (Perkins, 2006).
(d) Developing adaptive out-of-band security mechanisms
that are not specific to the deployment environment of
a network operator.
(e) Extending the developed mechanisms to full multi-
addressing, i.e., including also multi-homing.
6.2. Performance
Other than finding adaptive mechanisms that are capable of
addressing the current gaps in MIPv6 security, the delay re-
quirements and implementation issues remain to among the
main obstacles against any newly proposed scheme, which
still requires extensive research. More performance measure-
ments of security schemes of Mobile IPv6 are also highly
needed, particularly ones that:
(a) Measure a realistic network scenario, enabling all features
that would likely be needed in commercial deployment.
These features include link-layer access control, for
instance. Similarly, it is necessary to include support for
already specified optimizations.
(b) Measure or simulate the performance impacts of various
suggested security schemes to the different parts of the
stack.
(c) Measure implementation differences between systems
based on the same specifications. It would be valuable to
know how much implementation differ with regards to,
for instance, the use of the parallelism that RFC 3775 al-
lows in the home and correspondent registrations, the
RR procedure, and transmission of packets before binding
acknowledgements have arrived.
(d) Measure the effect of network conditions, such as packet
loss, and their effect to existing and new route optimiza-
tion mechanisms.
(e) Collect data about the behavior of mobile nodes in differ-
ent networks. Different route optimization mechanisms
behave differently depending on what the frequency of
movements is, or what payload traffic streams exist at
the different stages of the mobile node’s existence.
(f) Measure or simulate the performance of different route
optimization schemes under different application scenar-
ios, such as symmetric/asymmetric applications, only
rarely active mobile nodes, and so on.
7. Conclusion
Information infrastructures are core to modern society safety
and prosperity. In particular, all critical infrastructure systems
have become tightly coupled with computing and communi-
cation systems. Secure and pervasive mobile computing and
communication services are therefore required for the opera-
tion and interactions with critical infrastructure systems. Mo-
bile IP v6 is being considered to support such services. This
paper surveys security aspects of Mobile IP v6. Mobile IPv6
design exhibits critical security vulnerabilities that inhibit its
wide-scale adoption in future pervasive networks. A survey
of security vulnerabilities and a taxonomy of the main exist-
ing and proposed security solutions for MIPv6 were presented
in this paper. Generally, security solutions for MIPv6 are add-
on. The evaluation of these solutions in terms of security and
efficiency remains unclear given the complex interdepen-
dencies in critical infrastructure systems and the rapidly
evolving nature of pervasive networking. We conjecture that
we need to avoid the pitfall of patched security and develop
the next generation of mobility protocols based on well-de-
fined secure architecture and protocol engineering process.
references
Aura Tuomas. Designing the Mobile IPv6 security protocol.
Annals of Telecommunications (Special issue on network and
information systems security) March–April 2006;61(3–4).
Arkko Jari, Aura Tuomas, Kempf James. Securing IPv6 neighbor
discovery and router discovery. In: Proc. 2002 ACM Workshop
on Wireless Security (WiSe). Atlanta, GA, USA: ACM Press;
September 2002. p. 77–86.
Arkko J, Voght C. A taxonomy and analysis of enhancements to
mobile, Internet draft, October 2004.
 information security technical report 12 (2007) 32–43
Aune Frank. Cross-layer design tutorial. Technical report.
Norwegian University of Science and Technology, Electronics
and Telecommunications Department; November 2004.
Cladera Jose, De-Niz Dionisio, Nakagawa Junichi. Performance
analysis of IPsec and IKE For Mobile IP on wireless
environments. Technical Report. Information Networking
Institute, Carnegie Mellon University; 2000.
Choi H, Song Hui, Cao Guohong. Mobile multi-layered IPsec, IEEE
INFOCOM, March 2005.
Harkins D, Carrel D. The Internet key exchange, RFC 2409, IETF,
November 1998.
Kent S. Atkinson R. Security architecture for the Internet protocol,
RFC 4301, IETF, December 2005.
Kent S. IP authentication header, RFC 4302, IETF, December 2005.
43
Kent S, Atkinson R. IP Encapsulating security payload (ESP), RFC
4303, IETF, December 2005.
Mankin Allison, Patil Basavaraj, Harkins Dan. Threat models
introduced by Mobile IPv6 and requirements for security in
Mobile IPv6, Internet draft, IETF, November 2001.
Perkins C. Mobility support in IPv6, RFC 3775, IETF, June 2004.
Perkins C, Securing Mobile IPv6 route optimization using a static
shared key, RFC 4449, IETF, June 2006.
Sudanthi Sudha. Mobile IPv6, GSEC Version 1.4b, 17 Jan 2003,
GSEC – SANS security essentials certified graduates.
Zhang Y. Multi-layer protection scheme for IPSEC, Internet draft,
IETF, April 2006.
Zhang Y, Singh B. A multi-layer IPsec protocol. In: Proc. of nineth
USENIX security symposium, 2000.