A survey of secure protocols in Mobile IPv6

Journal of Network and Computer Applications 39 (2014) 351368

Contents lists available at ScienceDirect

Journal of Network and Computer Applications

1084-80http://d

n CorrE-m

amir.mojlloret@

journal homepage: www.elsevier.com/locate/jnca

Review

A survey of secure protocols in Mobile IPv6

Hero Modares a,n, Amirhossein Moravejosharieh b, Jaime Lloret c, Rosli Salleh a

a Department of Computer System and Technology, University of Malaya, Kuala Lumpur, Malaysiab Department of Computer Science and Software Engineering, University of Canterbury, New Zealandc Department of Communications, Polytechnic University of Valencia, Camino de Vera s/n, Valencia, Spain

a r t i c l e i n f o

Article history:Received 19 April 2013Received in revised form8 June 2013Accepted 18 July 2013Available online 7 August 2013

Keywords:Mobile IPv6Binding update messagesSecurity threatsAuthentication protocols in MIPv6Attacks in Mobile IPv6

45/$ - see front matter & 2013 Elsevier Ltd. Ax.doi.org/10.1016/j.jnca.2013.07.013

esponding author. Tel.: +60 176664612.ail addresses: [email protected] (H. [email protected] (A. Moravdcom.upv.es (J. Lloret), [email protected]

a b s t r a c t

Mobile IPv6, also known as MIPv6, is an IP-layer protocol that offers mobility support. The MIPv6protocol allows Mobile Nodes (MNs) to remain connected to Correspondent Nodes (CNs), even whenmoving to foreign networks. Basically, MNs may change their position throughout the IPv6 networkwhile retaining their existing connections by managing address variations in the Internet layer.Numerous advantages are thus attained, but security remains a fundamental concern. According toour research, a number of protocols can form a secure connection environment between MNs and CNs,though each has advantages and disadvantages. This paper presents a state-of-the art survey of securityprotocols in MIPv6. Moreover, we propose taxonomy, and comparative study that does not exist in thesurveys in the literature. Along with the location management feature within these protocols, potentialattacks and security threats, together with the security services and requirements are necessary forminimizing such problems, are subsequently presented.

& 2013 Elsevier Ltd. All rights reserved.

Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3522. Binding updates in a Mobile IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

2.1. Malicious MN flooding attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3532.2. False binding update attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

2.2.1. Session hijacking attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3532.2.2. Denial-of-Service (DoS) attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3532.2.3. Man-in-the-middle (MITM) attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

2.3. Return-to-home spoofing attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3543. Analyses of security services and architectures for binding updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3553.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3563.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

4. Authentication protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3564.1. Basic Mobile IPv6 process-tunneling mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3564.2. Infrastructure-less binding update protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

4.2.1. Return routability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3574.2.2. Cryptographically generated addresses (CGA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3584.2.3. Early binding update (EBU) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3594.2.4. Purpose-built key (PBK) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3594.2.5. CAMchild-proof authentication for MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3604.2.6. Unauthenticated DiffieHellman-based binding update (UDHBU) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

ll rights reserved.

odares),ejosharieh),y (R. Salleh).
www.sciencedirect.com/science/journal/10848045www.elsevier.com/locate/jncahttp://dx.doi.org/10.1016/j.jnca.2013.07.013http://dx.doi.org/10.1016/j.jnca.2013.07.013http://dx.doi.org/10.1016/j.jnca.2013.07.013http://crossmark.crossref.org/dialog/?doi=10.1016/j.jnca.2013.07.013&domain=pdfhttp://crossmark.crossref.org/dialog/?doi=10.1016/j.jnca.2013.07.013&domain=pdfhttp://crossmark.crossref.org/dialog/?doi=10.1016/j.jnca.2013.07.013&domain=pdfmailto:[email protected]:[email protected]:[email protected]:[email protected]://dx.doi.org/10.1016/j.jnca.2013.07.013

H. Modares et al. / Journal of Network and Computer Applications 39 (2014) 351368352

4.2.7. Optimizing Mobile IPv6 (OMIPv6) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3604.2.8. Applying CGAs to optimize Mobile IPv6 (CGA-OMIPv6) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3614.2.9. Enhanced route optimization for Mobile IPv6 (ERO-MIPv6) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3614.2.10. CAM-DH protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

4.3. Infrastructure-based binding update Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
4.3.1. Certificate-based binding update protocol (CBU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3634.3.2. Hierarchical certificate-based binding update (HCBU) protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3644.3.3. Shared key protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3644.3.4. Ticket-based binding update (TBU) protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3644.3.5. Password-based authenticated key exchange (PAK-based) binding update protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3654.3.6. BAKE/2 protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3656. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

1. Introduction

The Internet now facilitates worldwide access to informationanywhere and anytime, security continues to be a concern unlessconfidentiality is ensured. With respect to portability, personallaptops have turned computing into a mobile commodity wherewith the advent of mobile IP, users can now enjoy uninterruptedInternet roaming and transparent applications. Users' demand forwireless connectivity in their mobile devices and the growthobserved as a result has tremendously helped develop IP-basedmobility protocols. With such protocols, mobile Internet hosts orMobile Nodes (MNs) are now able to remain connected to othercorrespondent hosts and nodes even while roaming the Internet.

Mobile IP operates according to the following mechanism. First,a MN obtains an address from its Home Address (HoA), or itsoriginal location, and stores it to sustain end-to-end communica-tion. The MN additionally acquires a temporary address known asa Care-of Address (CoA) from a foreign agent (new location router)each time it shifts to a new network. Next, the MN sends a BindingUpdate (BU) with its new CoA to its Home Agent (HA). The bindingcache allows the home agent to intercept packets on the way tothe MN's HoA, encapsulates it with its CoA, and channels it to theMN at the new location. Thus, the CoA can reach its MN anywhereon the Internet, while the higher-layer applications can detect theMN by its HA (Fig. 1) (Hassan and Hoong, 2012; Sudanthi, 2003).BU messages are some of the most significant types of messagesfor sending a CoA to the HA and Correspondent Node (CN). BUvulnerability problems are usually related to authentication andauthorization. In turn, these issues lead to data packet intercep-tion, through which an attacker may eavesdrop on data packets,breaching user data confidentiality or modifying transmittedpackets to suit the attacker's malicious purposes. Other forms of

Fig. 1. How a mobile IP works.

attacks that capitalize on mobile IP vulnerability are the Man-in-the-Middle, Session Hijacking, Denial-of-Service (DoS) and Return-to-Home spoofing attacks, which will be discussed in Section 3.

For the last few years, Mobile IPv6 has been an active researcharea where the limited surveys are available in various domains ofMIPv6 such as Aura (2002), Elgoarany and Eltoweissy (2007), Guanet al. (2012), Sun et al. (2010). This technology is also beingincluded in Mobile Ad Hoc Networks (Ortiz et al., 2011). Aura(2002) has investigated the design process of the MIPv6. Sun et al.(2010) focus on authentication in MIPv6 and Return Routabilityprotocol. The major focus of the survey presented in Elgoarany andEltoweissy (2007) is surveys security vulnerabilities of Mobile IPv6where our paper investigates existing protocols that serve toprotect BUs by identifying their strengths and weaknesses withrespect to their security threats and services. The respectiveprotocols fall under two categories: infrastructure-less and infra-structure-based, each of which is explained in Section 5. Inaddition, this paper explores all available solutions for protectingBUs as well as the many types of security threats that exist todevise ideal solutions that do not feature the drawbacks ofpreviously proposed solutions. By understanding the securitysolutions offered by the many authentication methods that exist,it will then be possible to determine what they each have incommon and to employ this knowledge in building a novelsolution. The primary objective of this work is to provide anoverview of the MIPv6 BU protocols.

The rest of the paper is organized as follows: Section 2 presentsan overview of the binding update in Mobile IPv6. In Section 3, themost important security threats to BUs are discussed. Section 3presents and discusses an analysis of security services and archi-tectures for BUs. Section 4 presents the taxonomy of the authenti-cation protocols. A discussion and comparison of the authenticationprotocols mentioned in Section 4 are provided in Section 5, andfinally, Section 6 concludes by presenting the outcomes of review-ing contemporary research and provides several recommendationsfor further work.

2. Binding updates in a Mobile IPv6

The MIPv6 protocol allows a MN to clearly maintain its networkconnection during its attachment transfers (Johnson et al., 2004).A MN may be reached at its HoA anytime, in which case the MNreceives a Care-of Address from the local router through statelessor stateful auto-configuration. Next, home registration takes place,in which the MN sends its current CoA in a Binding UpdateMessage (BU) to its associated HA. The HA can then redirect andtunnel packets straight to the MN's CoA. If there is no binding

H. Modares et al. / Journal of Network and Computer Applications 39 (2014) 351368 353

between the CN and MN, meaning registration is in progress, orMIPv6 is not supported by the CN; then, bidirectional tunnelingcan be used. This entails an HA acting as a medium through whicha foreign location MN communicates with a CN (a stationary ormobile peer communicating with a MN). For Mobile IPv6 to runproperly, it is important to keep binding updates protected. Forthis reason, only a MN should ideally have the right to update itsCoA bindings to Mobile IPv4 to provide binding messages withauthentication and protection from replay attacks or maliciousnodes corrupting binding caches with invalid addresses (Ehmkeet al., 2009; Kempf et al., 2004; Srivastava and Nandi, 2013;Tripathi et al., 2012).

The MIPv6 protocol has a location management feature thatallows attackers to send spoofed BU messages to the MN and/orCN. Considering the abovementioned factors, it is of utmostimportance for MIPv6 to meet the security requirements for BUmessages. For instance, the Internet Engineering Steering Group(IESG) sent back an earlier draft of MIPv6 by the IETF afteridentifying an issue with the security and scalability of BUmessages (Islam, 2005; Mankin et al., 2001). Several sorts ofattacks are feasible through BU spoofing, including session hijack-ing, Denial-of-Service (DoS) and Man-in-the-Middle (MITM)attacks (Aura, 2002; Aura et al., 2002; Deng et al., 2002; Mankinet al., 2001; Nikander et al., 2003, 2005; Subashini and Kavitha,2011; Sudanthi, 2003). The subsequent section will describesecurity risks and attacks, after which Section 4 will cover securityservices that could impede such attacks, as well as performancerequirements to be considered when providing the respectivesecurity services.

Fig. 3. Session hija

Fig. 2. Malicious MN flooding attacks.

2.1. Malicious MN flooding attacks

In a malicious MN flooding attack, the HA and/or CN receives aspoofed message from a valid MN. The spoofed message containsan HA of the fake MN and the victim's CoA. It falsely claims that ithas changed location to the victim's node. The HA and CN thenproceed to send all packets originally meant for the MN to thevictim's address, flooding the victim with unwanted data. Figure 2shows an example of such an attack (Soliman, 2004).

2.2. False binding update attacks

A BU message can be spoofed by an attacker pretending to beanother mobile node. The attacker redirects the traffic meant forthe original node to another node or to itself (Soliman, 2004). Thisprocess is summarized next.

2.2.1. Session hijacking attacksIn the hijacking session illustrated in Fig. 3, it is assumed that

MN1 is communicating with the CN. A forged BU message is sent(or an old BU message is replayed) to the CN, claiming that the MNhas moved to a new CoA that belongs to MN2. If the CN acceptsthis false BU notice, it will begin communication with MN2 insteadof MN1. Such an attack may result in information leakage, mobilenode impersonation or MN2 flooding. By employing an RR proto-col (Section 4.2.1), the effort to launch a hijacking session in aMIPv6 protocol is greatly reduced. Let us assume that MN1 and CNin Fig. 4 are undergoing a continuous communication session. Arogue intruder wants to reroute communication traffic from MN1to the collaborating MN2. To obtain the Home-of Test (HoT), theintruder monitors the CNHA path (anywhere between MN1'shome network and the CN's own network). The home cookie isthen extracted and sent to MN2. Once MN2 receives the cookie, itsends a Care-of Test Init (CoTI) to the CN, which in turn replies viaa care-of cookie (CC). MN2 then hashes the two cookies to obtainthe legitimate session key, which will be used to send the BUmessage to the CN in place of MN1. The CN will accept the hijackedBU message and redirect its traffic to MN2. This sort of attack canbe prevented if a suspicious message first goes through authenti-cation (Deng et al., 2002; Sehwa et al., 2009; Ying and Feng, 2010).

2.2.2. Denial-of-Service (DoS) attacksIn a DoS-type attack, the assailant uses a BU message to stop

any service from being transmitted from the CN to the MN. A falseBU may be sent, requesting a CN to forward packets meant for theMN to a fake address that is not the real MN's CoA. By utilizingsuch a spoofed BU, an attacker can send a large amount of

cking attacks.

Fig. 4. Break the RR protocol by attacker.

Fig. 5. Denial-of-Service attacks.


unwanted traffic to overwhelm the resources of a single node ornetwork. First, the attacker locates a website with streaming videoor a different heavy data stream and connects to it. It then sends aBU to the CN, requesting traffic redirection to the attackers' newarbitrary location. This arbitrary node will thus be bombarded byconstant unwanted traffic. Attackers may also employ a targetnetwork's prefix to pass on a spoofed BU message, redirecting agreat deal of streaming traffic to the intended network andflooding it with unwanted data (Ren et al., 2006). A variation ofa DoS attack entails saturating the CN's memory (meant for storingbinding cache entries) with fake BUs filled with false Has (Soliman,2004). Therefore, no real message from any genuine node can beprocessed because the CN's memory is already full. Yet anothertype of DoS attack can hijack or cause the malfunctioning of arouter on the path between the MN and CN or its HA. The attackercan refuse service to the MN's packet by actively dropping it,though it is not common within Mobile IPv6. There is no way toavoid such an attack other than making it impossible for theattacker to compromise the router (Sudanthi, 2003) (Fig. 5).Basically, ensuring that none of the CNs maintain their state untilBU message authentication is performed could help prevent theabovementioned DoS attacks (Soliman, 2004).

2.2.3. Man-in-the-middle (MITM) attacksMan-in-the-Middle (MITM) attacks occur when a device man-

ages to insert itself into the communication path between twohosts (Kalajdzic et al., 2011). In other words, an attacker sends a

spoofed BU message to hosts A (MN) and B (CN) and proceeds toinsert itself into the communication path between both hosts(Fig. 6). When the attacker is located on the path between a MNand a CN, it can modify the BU message, potentially hijackingongoing connections or creating a reflection attack between theMN and CN (Soliman, 2004). Even if host A (MN) is able to proveaddress ownership, the attacker can still situate itself on the MNCN path. Because the attacker can modify the content of the BUmessage and its IPv6 header for his or her own purposes, the CNneeds to authenticate the MN's message to determine whether itwas modified during the communication. For this reason, someform of authentication is required during the BU process. Authen-tication may also be placed in the binding acknowledgment,where a MN must ensure it came from the correct CN. Otherwise,the attacker can impersonate the CN and reply using a fake BU.Therefore, it is important for mutual authentication to take placebetween nodes (Elshakankiry et al., 2010).

2.3. Return-to-home spoofing attacks

In return-to-home spoofing attacks, an attacker will pretend tobe a MN that is away from its own home link. It will thencommunicate with a CN and send a spoofed BU that contains theHA of a victim's MN while the attacker's address is set as the care-to address. The steps in Fig. 7 show the attacker requesting heavydownloads of data, e.g., video streaming, from the CN. Anotherspoofed BU is sent to the CN, informing the CN that the attackerhas returned to its home link. As a result, the CN will continuously

Fig. 7. Return-to-home spoofing attacks.

Fig. 6. Man-in-the-Middle attacks.


send traffic to the victim's MN, eventually flooding the victim withexcessive unwanted data (Elshakankiry et al., 2010; Ren et al.,2006; Soliman, 2004).

3. Analyses of security services and architecturesfor binding updates

To address and minimize the security risks and attacks dis-cussed above, the following security services should be provided(Modares, 2009; Riedel and Paar, 2003; Rocha et al., 2010;Stoneburner, 2001; Xiong et al., 2012).

3.1. Authentication

The process of verifying a user's or device's identity for thepurpose of communication is called the authentication process (Liet al., 2013). Authentication provides security assurance to all BUmessages coming from nodes with original HAs and CoAs.Authenticating the CoA ensures that the entity is indeed locatedat that address. There are a variety of authentication architecturesin existence today, such as the Kerberos (Neuman et al., 2005; Yu

and Astrand, 2012), but they mostly refer to a central (infrastruc-ture-based) authentication database for user verification. Aninfrastructure-less or decentralized authentication system mayprovide much better security for a mobile IP and several otherprotocols mentioned in Section 4.2. However, the flaws are eithera high amount of resource consumption or the exposure of vitaladdress data that can lead to attacks. Commonality could serve indeveloping an ultimate solution and can be obtained by under-standing all of the fundamental components of the many differenttypes of authentication systems. The commonality would includecomponents for hashes (Arkko et al., 2002), digital signatures(Tanenbaum and Van Steen, 2003), address-based keys (Kempfet al., 2002) and cryptographically generated addresses (Aura,2005).

Other, more elaborate authentication systems such as IPSEC(Arkko et al., 2004) and AAA (Authentication, Authorization andAccounting)-based RADIUS have also been investigated (Rigneyet al., 2000). From this analysis, we can determine how necessaryit is to implement security architecture and a central authentica-tion authority. An additional consideration concerns the resourcesneeded to run these architectures beyond what is required by amobile device.

Fig. 8. Bidirectional tunneling of the mobile IPv6.


3.2. Integrity

Integrity is considered to be another important security componentin dealing with attacks and other security risks. This service ensuresthat sent BUmessages contain the same binding data upon arrival. Thehash algorithm is adopted to provide data integrity. By default, themobile IP provides support for the MD5 Message-Digest Algorithm(RFC 1321)an algorithm that provides integrity verification andsecret-key authentication (Babu and Gokulraj, 2010; Rivest, 1992;Sahadevaiah and PVGD, 2011). A good encryption schememay providea means for a node to decrypt and determine whether a recoveredplaintext is the correct (integrity checking) or false one. Currently, anIPSec security association is applied between the HA and the MN as aform of integrity protection with BUs and acknowledgment authenti-cation. The Encapsulation Security Payload (ESP) (Eastlake, 2005; Kent,2005) header must and should be supported by both the MNs and theHA. It must be used during the transport mode and feature a non-nullpayload authentication algorithm. Thus, authentication of the data'sorigin and connectionless integrity verification are offered.

3.3. Confidentiality

Any data passing through the Internet can be intercepted andfalsified. With BUs, several security breaches could potentially takeplace. Violations include data packet interception when an intru-der eavesdrops on communicated content, thus violating a user'sconfidentiality, or modifies transmitted packets for maliciouspurposes. When an attacker poses as an HA, there may be seriousconsequences for a user's confidentiality. An attacker may(Georgiades, 2011; Rathi and Thanuskodi, 2009).
cause DoS attacks by preventing the transmission of packets toa node's CoA; cause MITM attacks by eavesdropping on data packets, thusbreaching user confidentiality; and cause MITM attacks by hijacking and modifying the transmitteddata for personal malicious use.
The HA must undergo an authentication process to mitigatepossible attacks towards it (Roe et al., 2002). Meanwhile, the attackerhas the ability to misinform the CN of the MN's location, preventingdata from reaching their intended destination. As such, user con-fidentiality is compromised because the packets are transmitted to theattacker instead. This is in fact a different sort of DoS attack. Therefore,it is essential for communicated data to have confidentiality as well aslocation privacy within a mobile IP environment (Moon et al., 2010).

Unfortunately, the proposed solution poses some drawbacks. Either atremendous quantity of resources is consumed or fundamental loca-tion data are given away such that carrying out attacks is facilitated(Georgiades, 2011).

4. Authentication protocols

4.1. Basic Mobile IPv6 process-tunneling mode

A Mobile IPv6 allows for an HA to function as a stationary proxyfor a MN, and anytime the MN travels away from its homenetwork, the HA intercepts the packets destined to the node andforwards them to the node's current addressthe CoA. Thetransport layer (e.g., TCP and UDP) uses the HA as a stationaryidentifier for the MN. Internet topology provides Mobile IPv6 ahost with two addresses: a permanent one for host identificationand another for the topological location. MIPv6's function is tomanage the binding between these two addresses via an HA, aswell as to ensure that the host is reachable at its permanentaddress even when traveling throughout the Internet. To secure aMN roaming through the Internet, Mobile IPv6 prepares a strategythat involves the MN continually obtaining new local IP addresses(CoAs) and notifying the HA of the new location's time and place.

MNs and a CN can communicate through MIPv6 in twodifferent ways. The first mode is bidirectional tunneling, whichdoes not require the CN to support Mobile IPv6 and is availableeven if the MN's current binding is not registered with the CN.Packets from the CN are routed to the HA and then tunneled to theMN; packets to the CN are reverse-tunneled from the MN to theHA and then routed normally from the home network to the CN.The HA authenticates the roaming device, and moreover, it makesall communications to the device pass through it prior to deliveryto the temporary location (CoA). Bidirectional tunneling entailstriangular routing, something that creates redundant latency,which is not advantageous for real-time traffic such as VoIP.Reliability is also affected because longer data paths have a higherchance of breaking due to link malfunction. Bidirectional tunnel-ing is summarized as follows (Fig. 8):

1.
The MN uses its HA while in the home network. A datagramsent from the CN to the MN will be passed to the MN's HA.
2.
The HA delivers the datagram to the MN's HA.3. The MN then travels to a visiting network and acquires a
temporary IP address, that is, a CoA from the visiting network'sagent (local router).

Fig. 10. Return routability protocol.

Fig. 9. Existing binding update protocols in MIPv6.


4.
The MN registers its CoA to the HA. The CN then sends the MNa datagram to its HA (the only reachable address) withoutknowing if it is in its home network.
5.
The HA forwards the datagram to the MN, at its CoA.6. The MN finally sends the datagram to the CN, tunneling it
through its HA.

The protocol summarized above represents a basic MIPv6function mode with no optimization. It involves the possibility ofcreating delays, affecting real-time traffic such as VoIP andinfluencing reliability as well, owing to the links that may break

due to the longer paths (Kandirakis, 2007). Therefore, the weak-ness identified in this type of routing is the longer path the packetmust travel from the sender to the MN, as opposed to using adirect path; thus, it is not optimal (Zuleger, 2005). However, routeoptimization is standard in MIPv6, and it eliminates inefficienttriangle routing (Anari Zare Mehdizadeh, 2008).

Mobile IPv6 may opt for route optimizationan operation modethrough which a MN and its CN can directly exchange packets,completely bypassing the following HA setup. Next, the MN sendsits current CoA to the CN via BU messages. Binding information isstored in the CN's Binding Cache. Route optimization can apply theReturn Routability (RR) procedure, a solution without infrastructurethrough which the MN needs the CN to test HA and CoA ownership,and authorizes binding through a cryptographic token exchange(Kandirakis, 2007). Based on our research, there are various novelmethods that can be implemented to address BU security. Thesemethods are divided into infrastructure-less and infrastructure-basedtypes (Fig. 9).

4.2. Infrastructure-less binding update protocols

Infrastructure-less protocols are recommended on a globalscale when MNs and CNs belong to their own various adminis-trative domains. These protocols are widely applied and find greatgeneral usage in the Internet. An infrastructure-less protocolbasically facilitates authentication between MNs and CNs withoutthe support of security infrastructure.

4.2.1. Return routabilityThe Return Routability (RR) protocol is used to conduct HoA

and CoA checks. Such checks are necessary for a node to confirmthe presence of another node that answers to the packetstraveling to a certain address. A positive reply confirms theexistence of a node at the given address (Fig. 10). Returnroutability checks include message pairs such as (Home Test,BU) and (Care-of Test, BU). To activate the test packets, Home TestInit (HoTI) and Care-of Test Init (CoTI) are needed, while the BUmessage plays the role of a combined routability response forboth tests (Ren et al., 2006).

1.
The HA check includes a HoT packet and a successive BU. It isassumed that the HA tunnels the HoT to the MN. The HoT tokenproduced cryptographically is
Home token hKcnjHoAjnij0where there is a hash function over the concatenation of asecret key, Kcn, known only by the CN, the HoTI packet's sourceaddress, and a nonce, ni. The HoT packet also has an index, i, foreasier identification of a suitable nonce.

2.
CoA checks: Regarding the CN, there is not much differencebetween the CoA and HA checks except that the packet is sentstraight to the MN's CoA. The token is developed a littledifferently to prevent using home tokens for care-of tokens orvice versa
Care of token hKcnjCoAjnjj1

3.
Forming the first BU: Upon receiving both the HoT and CoTmessages, a binding key Kbm is produced
Kbm hcare of tokenjhome tokenwhere a hash function is taken over the received tokens'concatenation. As long as the key is valid, it protects the firstand any subsequent BUs. Kbm is accessible to anyone able toacquire both CoT and HoT messages.


In the RR protocol, the two token exchanges confirm that theMN is active at its corresponding HA and CoA. This confirmation isin lieu of node authentication as the response to theinfrastructure-less assumption. MN activity at both the HA andCoA is important; however, so is RR protocol security because itclearly depends on the MN secretly sharing Kbm with CN, which issubsequently dependent on at least one token's secrecy. Again,because anyone with access to CoT and HoT messages can obtaintokens, RR protocol security is particularly fragile. Although the RRprotocol was originally designed with sufficient MIP support inmind and with the hope that it would not incur new majorsecurity problems, protection against attacks viable even prior tothe introduction of IP mobility was somewhat overlooked (Aura,2002; Nikander et al., 2003; Perkins et al., 2011). The protocol doesnot defend against intruders observing the CNHA path becausesuch intruders would be able to actively attack a MN at its homelocation anytime. However, the RR protocol's fundamental designincludes, for example, defending against intruders who are able tomonitor the CNMN path but not the CNHA path; however, theprotocol is essentially inconsistent in its breach of the weakestlink security standard (Deng et al., 2002). Attacks on MIPv6 aretypically easier to carry out than those on IPv6 despite the fact thata node might be at home in the base IPv6 because it is possible tomonitor one link or the other during an attack.

4.2.1.1. Attack in return routability. For instance, for an intruder tocarry out a false BU attack, he or she should always be on the CNHA path on a base IPv6 without mobility (equivalent to a MN at itshome link in MIPv6). To redirect CN traffic to attach the MN to amalicious node, the intruder should gain control of a router or aswitch on the CNHA path. If the malicious node (disguised as aMN) wishes to continue its session with the CN after taking overthe session from the MN, it ought to continue collaborating withthe router. In such a case, the router would tunnel the CN traffic tothe malicious node and vice versa. With MIPv6, it would take lesseffort to prevent the RR protocol from initiating a hijacking.Another instance is that in which it is assumed that MN1 andthe CN are communicating and the intruder wishes to redirect CNtraffic to his or her associated MN2. In this case, the intruder wouldmonitor the CNHA path (i.e., anywhere from MN1's homenetwork to the CN's network) to obtain the HoT, after which itwould extract the home token CH and send it to MN2. As MN2receives CH, it would forward a CoTI to CN and CN would replywith a care-of token CC. MN2 can then hash the two cookies for avalid session key to use to send a BU message to the CN on behalfof MN1. The CN would accept the BU, and CN would finally directtraffic to MN2.

Another type of attack is one involving malicious MN flooding.A DDoS attack is a good example of an attack in a base IPv6without mobility, where many compromised systems attack onetarget. A malicious MN flooding attack on MIPv6 can be carried outin many ways on a node or network. For example, a MN couldbegin communicating intensively with the CNs and shift to thevictim's network or its exterior boundary. The malicious nodewould then send BU messages via the PR protocol to redirecttraffic from the CNs to the victim's network. No special software ornetworking ability is necessary for this attack, so it would besimple for an intruder to disturb B2C operations through the PRprotocol. In another scenario, if a correspondent node offersnumerous mobile clients on-line services, an intruder couldeffortlessly eavesdrop on RR protocol messages and then gathercookies from its location between the CN and the Internet. Next,the intruder could redirect the traffic to any mobile client byrandomly hashing the cookie pairs to create session keys, anddelivering these BU messages to the CN. The result would bedetrimental to the CN's services.

With the aim of improving RR protocol latency, the Early BindingUpdates protocol (EBU) (Vogt et al., 2005) was planned. Thisprotocol is meant to send message fractions prior to handover;however, because both protocols have similar security architectures,EBU is prone to the same types of attacks mentioned above.

4.2.2. Cryptographically generated addresses (CGA)Cryptographically generated addresses (CGAs) (Aura, 2005) are

IPv6 addresses where up to 64 address bits are generated byhashing the address owner's public key. The address owneremploys the corresponding private key to affirm address owner-ship and sign messages from addresses without a PKI or othersecurity infrastructure. CGA-based authentication may help protect IP-layer signaling protocols, including neighbor discovery and mobilityprotocols, in addition to key exchanges in an opportunistic IPSec. Thenotion of hashing CGA originated in a paper on Child-proof Authenti-cation for Mobile IPv6 (CAM). It was standardized in RFC 3972 andutilized for the secure neighbor discovery protocol (Aura, 2005).
Address generationThe procedure for generating an IPv6 address using CGA isillustrated in Fig. 11 (Bos et al., 2009).1. Set the modifier to a random 128-bit value. Select the
security parameter Sec and the collision count to zero.2. Concatenate the modifier, 64+8 zero bits, and the encoded

public key. Execute the H algorithm on the concatenation.The leftmost 112 bits of the result are Hash2.

3. Compare the 16nSec leftmost bits of Hash2 with zero. If theyare all zero (or if Sec0), continue with Step (4). Otherwise,increment the modifier and go back to Step (2).

4. Concatenate the modifier, subnet prefix, collision count andencoded public key.Execute the H algorithm on the concatenation. The leftmost64 bits of the result are Hash1.

5. Form an interface identifier by setting both reserved bits uand g in Hash1 to 1 and the three leftmost bits to Sec.

6. Concatenate the subnet prefix and interface identifier toform a 128-bit IPv6 address.

7. If an address collision with another node within the samesubnet is detected, increment the collision count and goback to step (4). Otherwise, after three collisions, stop andreport the error.
Verification of address ownershipAddress ownership verification is accomplished by executingthe following steps given the IPv6 address, collision count andthe modifier:1. Verify that the collision count is 0, 1 or 2 and that the subnet
prefix is equal to the subnet prefix of the address. CGAverification fails if either check fails.

2. Concatenate the modifier, subnet prefix, collision count andthe public key. Execute the H algorithm on the concatena-tion. The 64 leftmost bits of the result are Hash1.

3. Compare Hash1 with the interface identifier of the address.The differences between the two reserved bits u and g andbetween the three leftmost bits are ignored. If the values ofthe 64 bits(other than the five ignored bits) differ, then CGAverification fails.

4. Concatenate the modifier 64+8 zero bits and the public key.Execute the H algorithm on the concatenation. The leftmost112 bits of the result are Hash2.

5. Read the security parameter Sec from the three leftmost bitsof the address' interface identifier. Compare the 16nSecleftmost bits of Hash2 with zero. If any one of these bits isnot zero, CGA verification fails; otherwise, verificationsucceeds. If Sec0, verification never fails at this step.

Fig. 11. Data flow of address generation in cryptography generated address.

Using CGA addresses in security protocols.To verify that a message is coming from a specific CGA address, theaddress owner signs the message with his or her public key. Theowner will then send the message, the public key, the auxiliaryparameters, and the signature from the CGA address to the verifier.The verifier follows the steps outlined in the previous section foraddress verification. If address verification succeeds, the verifierknows that the public key belongs to the address owner. Finally,the verifier uses the public key to verify the signature on themessage. If the signature is valid, the verifier recognizes that themessage was sent by the owner of the specific address.
Aura (2005) proposed reserving the currently unused bitcombination u1, g1 for CGA addresses. The type bits informthe recipient of an IP packet that the source address is a CGAaddress and the sender supports CGA-based authentication, mak-ing it possible to use authenticated CGA addresses and unauthen-ticated legacy addresses side by side. CGA addresses will have touse the bit combination u0, g0, rendering it impossible todistinguish CGA addresses from non-CGA addresses and moredifficult to deploy new security protocols based on CGA. In somesituations, it is possible to accept both authenticated andunauthenticated information and give priority to the authenti-cated over the unauthenticated data.

4.2.3. Early binding update (EBU) protocolTo enhance the RR procedure, Early binding update (EBU) (Vogt

et al., 2005) is proposed. EBU reduces the high registration delaycaused by the RR by shifting the HoA and CoA tests to a handoversection where they cannot affect the registration delay. The HA testis executed prior to handover, while MN uses the old CoA.After handover, the CoA test is carried out in parallel with thedata transfer. EBU uses the Credit-Based Authorization technique

(Vogt, 2005) to limit the data that a CN sends to the MN with itsunconfirmed CoA and to concurrently run the CoA test. Fig. 12illustrates the EBU protocol.

EBU enhances the RR and decreases correspondent registrationdelay; however, one or two additional messages are necessary, andif MN needs to run the HoA test periodically, signaling overheadincreases. Implementing Credit-Based Authorization in the CNraises complexity, and EBU will still suffer from on-path attacksapplicable to the RR (Elshakankiry et al., 2010).

4.2.4. Purpose-built key (PBK) protocolThe main goal of the purpose-built key (PBK) protocol (Mankin

et al., 2003) is to authenticate and verify the network commu-nication initiator. In this case, the communication packets mustcontinuously arrive from the same source for the protocol to run,but initiator identity is not crucial. Thus, this protocol is suitable inproviding the confirmation that CN requires to acknowledge thatthe correspondent's registration originates from the MN thatbegan communication.

During the registration of any correspondent, the PBK protocolneeds four messages. Compared to the RR procedure, this methodactually reduces signaling overhead. Unfortunately, registrationdelay persists owing to the 1.5 round-trip between the MN and CN.DoS attack vulnerability rises as a result, causing resource over-consumption. The process requires the formation of a state for theverification of two digital signatures during protocol execution.Because it travels back and forth, the protocol is open to attacks,such as return-to-home spoofing, due to its inability to performauthentication on the HoA. An additional weakness lies in thevulnerability to MITM attacks during the initialization processwith respect to the security threats explained in Section 2.2.3. Thehash key or public key (i.e., PBID) can be intercepted duringinitialization if an attacker listens in on the transmission path

Fig. 12. EBU protocol.


and then transmits a different key. Finally, this protocol requiresboth CN and MN to perform two operations to acquire public keysfor each correspondent registration (Elshakankiry et al., 2010).

4.2.5. CAMchild-proof authentication for MIPv6CAM is a unilateral security system that authenticates BUs in

MIPv6 (Lowe, 1997). It functions by incorporating a one-way hashof its public key into the MN's chosen HA. Demonstrating knowl-edge of the corresponding private key, validates address owner-ship. Therefore, given that a key pair must correspond to the hash,falsification becomes difficult. A CAM node creates a key pairwhich is stored locally upon initialization, after which a HA has tobe chosen. A 64-bit routing prefix is obtained by listening for thelocal router advertisements. In most cases, the interface ID isobtained from the media access control address (MAC address)because it is economical, and globally unique. However, the CAMprotocol alone cannot ensure node reliability, thus, other protocolsare needed to compensate for this deficiency. CAM does notprotect against distributed DoS attacks. Other protocols to protectagainst such attacks include the IKE protocol. Moreover, in asituation where an attacker jams a mobile's BU but delivers abinding acknowledgment that cuts the MN off from the HA andthe correspondent, the protection alternatives would be IPSec orsome variants of CAM (Lowe, 1997). The advantage of CAM is thatit reduces both the signaling overhead and the registration delays.In the CAM protocol, only one message is required between theMN and the CN. It checks the authentiity of the HoA by using theCGA-based address and the reachability test. However, a drawbackis that the protocol will then be open to MN flooding attacksbecause it is unable to verify the authenticity of the CoA. The CAMprotocol can detect any replay BUs using time stamps. In addition,both the MN and the CN must possess a synchronised clock, andthis gives rise to the same weaknesses as for the CGA-basedtechnique, mentioned above (Koo and Lee, 2007).

4.2.6. Unauthenticated DiffieHellman-based binding update(UDHBU) protocol

The DiffieHellman key exchange protocol is the methodemployed in the Unauthenticated DiffieHellman Binding Update(UDHBU) protocol (Le and Faccin, 2001). It provides a session keythat is shared among both the MN and the CN. The two nodes laterutilize this session key for authentication during correspondentregistration. The two instances in which the UDHBU protocol isapplied are the start of correspondent registration and thesubsequent registration. An example is provided in Fig. 13.

The UDHBU protocol requires four messages in the first registra-tion but only two for the subsequent correspondent registration.Delay is thus reduced because only one-way registration is neces-sary for subsequent correspondents between MN and CN. UDHBUalso protects the CN from DoS attacks because it does not need tocreate a state until the authentication BU in Message 3 arrives fromthe MN. The CN only performs two exponential calculations in theinitial registration phase as per the lightweight MAC operations.Finally, the protocol allows long-term use of the shared keybetween MN and CN because redundant message signaling isreducedusually a result of the RR procedure, which constantlygenerates new shared keys.

The UDHBU protocol is particularly prone to flooding attacks atthe MN due to its inability to authenticate the CoA. MITM and falseBU attacks can also disturb this protocol owing to the unauthenti-cated DH key. In this case, an attacker may plant him- or herself onthe path and intercept the DH public value before relaying its ownversion during the first correspondent registration. It is alsofeasible for the attacker, rather than a legitimate MN, to initializethe protocol. If this happens, the attacker has an opportunity tocapture the session key and ultimately use it to transmit false BUs.

4.2.7. Optimizing Mobile IPv6 (OMIPv6) protocolOne procedure that combines the RR method with the Diffie

Hellman key exchange protocol is the optimizing Mobile IPv6

Fig. 13. UDHBU protocol.


(OMIPv6) protocol (Haddad and Krishnan, 2004). The two techni-ques are combined to produce a shared key for sessions betweenMN and CN via a similar process to the above mentioned UDHBUprotocol. OMIPv6 was developed as well with the aim to includethe initial registration phase and subsequent registration ofcorrespondents. Its course begins in the initialization phase ofcorrespondent registration. Both the MN and CN will performexecute the RR protocol to generate a shared secret. The two nodeswill then exchange the DH key that has been verified by the sharedsecret during the previous RR process for a long-term shared keysession. OMIPv6 employs exactly the same subsequent correspon-dent registration used by the UDHBU protocol.

It takes eight messages and 2.5 round trips between MN andCN for OMIPv6 to register the correspondent. Subsequent registra-tions only require one-way trips between MN and CN and twomessages. This protocol therefore offers superior protectionagainst DoS attacks compared with UDHBU. Overall, both OMIPv6and UDHBU share similar features and possess advantages anddisadvantages.

4.2.8. Applying CGAs to optimize Mobile IPv6 (CGA-OMIPv6)protocol

This protocol (Haddad et al., 2005) is an amalgamation of theCGA-based techniques and the RR procedure. The optimizationsteps of the MIPv6 protocol are as follows: (1) public/private keysare self-generated by the MN; (2) the HoA is configured by MNaccording to the CGA concept described in Section 4.2.2; (3) theMN exchanges CoTI and CoT messages with the CN to obtain theCoA reachability proof when a new CoA is requested and (4) uponinitial correspondent registration with the CN, the MN providesthe reachability proof along with HoA ownership. These steps areaccomplished by signing the first BU message with its own privatekey, after which the public key is sent with the signed message.Proof can be obtained during the CoTI and CoT exchanges.

This CGA-OMIPv6 protocol has two phases: the initial registra-tion of a correspondent and the subsequent registration. In theinitial correspondent registration phase, the CN authenticates theMN's HoA along with the reachability of the MN's HoA and CoA.These two nodes can proceed by exchanging secret session keys.Subsequent registration occurs when there is a new CoA at the CNthat needs to be registered by the MN. At the new CoA, the CN can

verify the MN's reachability. Figure 14 illustrates the CGA-OMIPv6protocol.

Five messages during the initial phase of correspondent regis-tration and four messages during the subsequent registration arepassed in the CGA-OMIPv6 protocol. Correspondent registrationbetween the MN and CN requires 1.5 round trips. HoA is authen-ticated using the CGA-based HoA together with the reachabilitytest that authenticates the HoA. This journey helps to marginallyprotect against return-to-home spoofing attacks. When a new CoAis claimed, a CoA reachability test is performed to ensure partialprotection against DoS attacks on third parties. The CN will use RRto establish the Kbm, which is used to verify BU message authen-ticity before any CGA-based address verification algorithm is run.In the initial correspondent registration stage, both MN and CN areadditionally required to carry out two public key operations.

4.2.9. Enhanced route optimization for Mobile IPv6 (ERO-MIPv6)protocol

The functions of EBU and CGAOMIPv6 (shown in Sections 4.2.3and 4.2.8) are combined to produce the ERO-MIPv6 protocol(Arkko et al., 2007), as shown in Fig. 15.

In the ERO-MIPv6 protocol, six messages are sent during thefirst correspondent registration and four in the subsequent regis-tration. For any correspondent registration, the delay timebetween MN and CN has been optimized to a one-way route bythis protocol. In addition to the delay time optimization function,this protocol has the same advantages and disadvantages as CGA-OMIPv6, as elaborated in Section 4.2.8. Implementing the Credit-based Authorization technique in the CN has also grown to beincreasingly complex, as in EBU (Elshakankiry et al., 2010).

4.2.10. CAM-DH protocolCGA provides a basis for CAM-DH to secure BUs (Roe et al.,

2002). CAMDH contains a digital signature system in which everyMN possesses a public and private key pair, PMN and SMN. The MN'sHA is a CGA generated from PMN. The protocol comprises fivemessages, as shown in Fig. 16.

In Message 1, MN notifies the CN that it is mobile and providesthe mobile's HA and CoA. In Message 2, the CN transmits MN's HAa challenge, rh, the DiffieHellman exponent, gy, and a serialnumber, j, specifying the Nj version used to create the challenge.In Message 3, the HA forwards Message 2 to the MN's CoA.

Fig. 15. ERO-MIPv6 protocol.

Fig. 14. CGA-OMIPv6 protocol.


Then, in Message 4, the CN sends the MN's CoA one challenge, rc,and serial number, j, as in Message 2. In Message 5, the MNforwards the CN a BU, a message authentication code of the BUcomputed with KBU, the MN's DiffieHellman exponent signedwith its private signature key, SMN, the MN's public signature key,PMN, and a message authentication code including all of the abovedata computed with a key obtained from the two challenges.

To distinguish this message from the first message of theprotocol's alternative version, it is tagged T0. The BU also has a

sequence number, i, to establish an order in case more than one BUis sent within the lifetime of a single value of Nj. TypeTag helpsavert accidental type collisions with messages from other proto-cols that utilize the same signature public key but may or may notemploy type tags. The CN confirms the two MACs and can then usethe CGA to verify gx's integrity. CGA presents CAM-DH with a wayto bind the MN's PMN to its IPv6 address; nevertheless, CAM-DHhas some limitations, one of which is that CAM-DH does notauthenticate the CoA. Furthermore, an attacker intercepting

Fig. 17. CBU protocol.

Fig. 16. CAM-DH protocol.


packets meant for the CoA can complete the protocol and becomethe source of CoA data overload, even if the real CoA owner-hostdoes not wish to partake in the protocol. An alternative to CoAauthentication is to develop the CoA and HA from the node'spublic key. This may not succeed, however, if the subnet enforcesconstraints on the CoA. Secondly, CGA generation is highlydemanding computationally, particularly if the MN uses a highSec value.

The CAM-DH protocol requires large processing power tohandle asymmetric cryptography and CGA. Moreover, the MNincurs a high computation load from each BU message that needsa signature produced by the MN in addition to signature validationby the CN.

4.3. Infrastructure-based binding update Protocols

Correspondent registration protocols generally require supportfrom some security infrastructure to provide protection through-out correspondent registration. Such protocols provide assuranceto the CN that the MN's HA is valid and correct, i.e., that the MN's

HoA is related to the secret key or the public key of the private/public pair. In turn, any need to test the HA is eliminated, leadingto diminished delays during registration and less overhead insignaling.

4.3.1. Certificate-based binding update protocol (CBU)A CBU protocol was proposed to resolve the abovementioned

security issues (Deng et al., 2002). Figure 17 shows the exchange ofmessages between the nodes in the CBU protocol. The CBUprotocol authenticates a MN and its HoA using a certificate.However, the CBU does not address the HoA certificate manage-ment concerns. It is built around disjointed authentication infra-structures existing within individual or various domains. TheCertificate Authority (CA) provides each home link subnet prefixwith a certificate, and this is not very practical. Flexibility is clearlyanother issue in this flat-structured trust management, hence, it isimpossible to implement it across domains with various infra-structures on a global scale. The CN is not responsible for trackingcomplex individual subnet prefix changes of the home links, as

Fig. 18. HCBU protocol.


there can be as many as 261 individual home links, worldwide. Tominimize and better manage these shortcomings, a divide-and-conquer tactic is recommended. Another disadvantage of the CBUprotocol is that the CN cannot ensure that the MN is live on itsclaimed CoA in the BU message (Mankin et al., 2001). Fake BUswithin a MN's CoA, can be transmitted by malicious nodesdisguised as MNs, could be potential intense attacks (Rescorla,2001).

4.3.2. Hierarchical certificate-based binding update (HCBU) protocolThe HCBU protocol (Ren et al., 2006) provides additional

improvements to CBU in that it asserts the MN's ownership of aclaimed CoA. The signature of a foreign link is obtained with thebinding of the HoA and CoA whenever the MN roams to a foreignlink with a newly configured CoA. The HA's duty also extends tocovering not only all home-linked MNs but other roaming MNsfrom different links, which are all of the nodes under its home link.The home link proves to the CN that both HoA and CoA are ownedby the MNs. HCBU also comprises an initial correspondentregistration component and subsequent correspondent registra-tion, which are further divided into pre-handover and post-handover steps. Figure 18 illustrates the HCBU protocol.

Both HCBU and CBU protocols share some of the same advan-tages mentioned in the preceding sections. Claimed CoAs areauthenticated, resulting in added security and protection againstmalicious MN flooding attacks on third-party nodes. By adding theEBU protocol, the delay time caused by correspondent registrationis reduced, i.e., pre-handover is executed before handover. Thepre-handover stage may be repeated several times over a givenperiod of time, especially when handovers are not anticipated. Therepetition could increase signaling overhead during the signalingphase. A further requirement is a trusted third party or foreign linkto verify the CoAs of the MNs; an authentication infrastructurewould be helpful for this type of service. The duty of the HA thenbecomes more complex because it begins to cover roaming MNsfrom other links. Finally, foreign HAs are needed to assist in

computing the roaming MN's signature, thereby reducing foreignnetwork throughput.

4.3.3. Shared key protocolThe shared key protocol (Dupont and Combes, 2006; Perkins,

2006; C. E.) is used for authenticating the BUs between a MN and aCN where both nodes share a symmetric key. A CN randomlygenerates a number (a nonce) at regular intervals, then uses thesame key to nonce all MNs it communicates with. The node,therefore, does not have to generate or store new ones for freshmobile communication. The Correspondents can differentiatebetween the nonces because their values have a subscript, and if+1 is added; the values can be verified and compared with theprevious messages. CNs store current and old nonces, but candispose of older values, while messages with old nonces areabandoned as replays. The keys can maintain fixed values or getrepeatedly updated. Updating both a key and a nonce can be donesimultaneously, in which case, the subscript would signify the keyand the nonce, together. The Shared key protocol requires onlytwo messages, and this reduces signaling overhead when com-pared to the RR procedure. However, the Share key protocol isunable to authenticate the claimed CoA, and it is vulnerable toflooding attacks by malicious MNs. The MN is required to storedifferent confidential information of each CN, and in turn, the CNis required to do the same for each MN. In order to protect itselfagainst replay attacks, the CN has to keep track of the latest valueof sequence numbers in the BU message sent from the MN. If thevalue received from the MN is not properly maintained by the CN,then the chances of it being fooled into accepting a replay BUmessage is very high.

4.3.4. Ticket-based binding update (TBU) protocolIn the TBU protocol (Koo et al., 2006), communication between

the MN and CN must be protected using the IPSec ESP tunnel.Other requirements include extending the HA's duty to verifyingthe MN's HOA validity, establishing a ticket as well as a secret keybetween the MN and CN, and providing a mutual authentication

Fig. 19. TBU protocol.


system for both nodes. The TBU protocol is divided into twophases: the initial correspondent registration and the subsequentregistration (Fig. 19).

Only two messages traveling one-way are required by the TBUprotocol for the subsequent correspondent registration betweenthe MN and CN. Thus, both signaling overhead and registrationdelay are maintained at a minimum. Home address ownership isadditionally ensured, which translates into enhanced security. Forinstance, return-to-home spoofing attacks are minimized, whichhelps reduce the issue of redundant signaling messages of fre-quently generated shared keys during the RR procedure byproviding both MN and CN with a long-term secret key and ticket.

During the initial registration of correspondents, the TBUprotocol requires four messages and a one-way path to commu-nicate between the MN and CN. Included is a one-way pathbetween the CN and HA. A requirement of the TBU protocol is tohave the MN, HA and CN clocks fully synchronized because theprotocol relies on time stamps to recognize replaying messages.In TBU, the complexity of the MN correspondent registrationat the HA is greater, and unfortunately, this protocol is still opento MN flooding attacks due to its inability to authenticate therequesting CoAs.

4.3.5. Password-based authenticated key exchange (PAK-based)binding update protocol

For the BU protocol based on PAK (Yoon et al., 2006), both theMN and CN are required to share the same password. Via anoptimized PAK scheme, the MN and CN can authenticate eachother, allowing for future correspondent registration one-timebinding of the established management key, as well as authenti-cating the validity of the MN's location and its HA. Within the PAK-based BU protocol, four messages are exchanged by the MN andCN during correspondent registration. The optimized PAK schemeis found in the first two messages (Yoon et al., 2006), in which theDiffieHellman-based password authentication key exchangescheme is employed by both the MN and CN (Boyko et al.,2000). The remaining two are the standard BU and BA messagesthat are protected by the PAK scheme's optimized key.

Four messages and approximately 1.5 round trips are requiredby the PAK-based BU protocol. Verification of the MN's reachabilityat the CoA is performed to protect against malicious floodingattacks on the MN and other third parties. Another attribute thatimproves security strength is that HA ownership is ensuredbecause the password is set according to the MN's HoA. Thus,protection against return-to-home spoofing type attacks isachieved. However, both the MN and CN must store passwordsthat are different from one another. The two nodes must alsocompute two different exponential calculations for every corre-spondent registration.

4.3.6. BAKE/2 protocolThe BAKE/2 protocol (Roe et al., 2002) facilitates the dynamic

establishment of a shared secret key by expanding the shared keyprotocol. BAKE/2 is appropriate for communication between nodeswhich have been secured against eavesdropping, or secured byIPSecsomething not offered by this protocol. A weakness ofBAKE/2 is that it can be breached by attacks somewhere betweenthe HA and the CN (Gunderson, 2008). The protocol does not offerprotection against an attacker who can monitor the HA to CNroute. However, it can protect the CN against denial of serviceattacks. This conserves resources as there is no need for largeamount of processing power to authenticate the messages. Thisprotocol facilitates communication between a MN and a non-mobile server, but may not be suitable for communication with amobile server. This protocol provides protection against DoSattacks, in which the attacker uses the victim's CoA to redirecthigh bandwidth traffic to it.

5. Discussion

Among the fundamental issues to be addressed in IP mobilitysolutions are the security and privacy of BU messages. BUs haveseveral security weaknesses, such as data packet interception,which breaches user confidentiality as attackers eavesdrop onpacket content, and the modification of transmitted packets to suitthe attacker's malicious intent. Mobile IP security vulnerabilities

Table 1Comparison of results obtained for existing protocols based on authentication of the HoA and CoA and integrity of CoA.

Infrastructure less Infrastructure based

EBU RR PBK UDHBU OMIPv6 CGA-OMIPv6 ERO-MIPv6 CAM CBU HCBU SK TBU PAK based

Authenticate HoA X Authenticate CoA X X X X X X Integrity of CoA

it uses an address reachability test.it uses cga-based address.it uses both cga and address reachability.authenticated.xnot authenticated.

Fig. 20. Structure of proposed protocols.


include address spoofing, DoS attacks and redirection. One com-monality among all of these attacks is that the attacker only needsto know the IPv6 address of the HA belonging to the MN and theCN (Georgiades, 2011). Certain protocols are specifically designedto improve the security of BUs, such as IPSec and RR.

Regarding IPSec, BU message protection occurs between the HAand its MNs, whereas RR relies on securing the communicationpath between the CN and the MN; however, both bear similarsecurity vulnerabilities, as mentioned in Section 3. Our researchreveals various novel mechanisms that can address BU security,including Cryptographically Generated Address (CGA) (Aura,2005), Early Binding Update (EBU) (Vogt et al., 2005), Purpose-Built Key (PBK) (Mankin et al., 2003), CAM-Child-Proof Authenti-cation (Lowe, 1997), Unauthenticated DiffeHellman-based BU(Le and Faccin, 2001), Enhanced Route Optimization (Jari Arkkoet al., 2007), Certificate-based BU (R. H. Deng et al., 2002), sharedkey (Dupont and Combes, 2006), Ticket-based (J. Koo et al., 2006),BAKE/2 protocol (Roe et al., 2002), Dual Identity Return Routability(Georgiades et al., 2006), Distributed Authentication Protocol(Andrew Georgiades et al., 2009) and the Georgiades Method

(A. Georgiades, 2011). In Section 5, solutions to the stated securityissues were suggested, along with their pros and cons. Thesolutions' most important function is to protect BU messagesagainst eavesdropping, modification and DoS attacks. These pro-tocols were categorized into infrastructure-less and infrastructure-based types and a detailed description of their architecture as wellas their communicated messages and the possible attacks that canbe mitigated were provided.

Figure 20 illustrates the relationships between previouslyreported protocols. For example, Haddad et al. (2005) proposedCGA-OMIPv6 to resolve issues that OMIPv6 is faced with whensending BU messages (Section 4.2.7). The researchers combinedOMIPv6 with CGA to develop CGA-OMIPv6. Table 1 comparesresults obtained for the current protocols.

The protocol for BU authentication should be based on the factthat the location information in IPv6 must be authenticated. TheMNs should authenticate themselves every time they move toforeign networks. In the absence of a proper authenticationprocess, the packet flow from one node to another might beintercepted by a malicious node that could redirect the flow to its


location or to an arbitrary IP address. The consequence is thatservice meant for the intended legal receiver will be denied.In Section 4, we described the potential security risks and attacksin MIPv6. These are security issues that occur as a result of currentprotocols not having effective authentication methods to verifyuser validity or conceal HoA and CoA location data. Eventually,vulnerability to malicious attacks is inevitable. In summary, wecan conclude that the majority of protocols endure securityvulnerabilities due to the ineffectiveness of
Authenticating user authority: Thus, the CN has no way toensure that the MN is indeed a valid node and not a maliciousone (the MN needs to perform self-authentication). This facil-itates several types of attacks. Concealing CoA data in the current MIPv6 security protocols. Itis not possible for the CN to validate the address owner (CoAswith spoofed addresses).
6. Conclusions

To design a protocol that can mitigate or avoid all associatedsecurity risks, an essential step would be to examine the availablesolutions for protecting BU messages, as well as the numeroustypes of security threats. The objective would also be to obtain anoptimum solution with none of the drawbacks or disadvantagesobserved for previously developed solutions. This paper haspresented an overview of the MIPv6 protocol. With the help ofthe location management feature of this protocol, potential attacksand security threats, in addition to the security services andrequirements necessary to minimize such problems, have beendiscussed. This research has highlighted several existing protocolsthat provide some degree of protection during the correspondentregistration phase of MIPv6. The conclusion drawn is that the BUmessage should be designed on a case-by-case basis to minimizeiterating steps throughout the entire protocol. Redundant repeti-tion of sections will be avoided in the protocol, and efficiency willbe enhanced in response to the diminished step iteration. Thecorrespondent registration protocol ought to be ingeniouslydesigned to allow for the HAs to help complete the registrationprocedure and minimize the computing cost of the MN.

Our future work will involve providing a secure connectionbetween MNs and CNs to protect BU messages against a number ofdevastating attacks on Mobile IPv6, e.g., DoS, in which attackersimpersonate and deny services of the target node by directingnetwork traffic to themselves or another node; Man-in-the-Mid-dle; Session Hijacking; and Return-to-home spoofing attacks arevarious other types of attacks that were discussed in Section 3.

Acknowledgments

This work was supported in part by the University of Malaya,Kuala Lumpur Malaysia under UMRG Grant (RG080/11ICT).

References

Anari Zare Mehdizadeh A. Security enhancement of route optimization in mobileIPv6 Networks. University Putra Malaysia; 2008.

Arkko J, Devarapalli V, Dupont F. RFC 3776: Using IPsec to protect mobile IPv6signaling between mobile nodes and home agents. Internet Engineering TaskForce (IETF); 2004.

Arkko J, Haddad W, Vogt C. RFC 4866: enhanced route optimization for mobile IPv6.Internet Engineering Task Force (IETF); 2007.

Arkko J, Nikander P, Montenegro G. Selection of MIPv6 security Level using ahashed address Internet draft draft-arkko-mIPv6-select-hash-00. txt. Work inprogress, IETF; 2002.

Aura T. Mobile IPv6 security. In: Proceedings of 10th international workshop thesecurity protocols. Cambridge, UK: LNCS; 2002. p. 1226.

Aura T. Cryptographically generated addresses (CGA). In: Proceedings of 6thinformation security conference (ISC'03). UK: Bristol; 2005. p. 2943.

Aura T, Roe M, Arkko J. Security of Internet location management. In: Proceedings ofthe 18th annual computer security applications conference. Las Vegas: IEEE;2002. p. 7887.

Babu SS, Gokulraj K. A multifactor hash digest challenge-response authenticationscheme for session initiation protocol. Network Protocols and Algorithms2010;2(4):309.

Bos J, zen O, Hubaux J-P. Analysis and optimization of cryptographically generatedaddresses. In: Proceedings of the 12th international conference on informationsecurity. Pisa, Italy; September 79, 2009. p. 1732.

Boyko V, MacKenzie P, Patel S. Provably secure password-authenticated keyexchange using DiffieHellman. In: Proceedings of the 19th internationalconference on theory and application of cryptographic techniques. Bruges,Belgium; May 1418, 2000. p. 15671.

Deng RH, Zhou J, Bao F. Defending against redirect attacks in mobile IP. In:Proceedings of the 9th ACM conference on computer and communicationssecurity (CCS). Washington, DC, USA; November 1721, 2002. p. 5967.

Dupont F, Combes J. RFC 4651: care-of address test for MIPv6 using a state cookie.Network Working Group; 2006.

Eastlake D. RFC 4305: cryptographic algorithm implementation requirements forencapsulating security payload (ESP) and authentication header (AH). InternetEngineering Task Force (IETF); 2005.

Ehmke M, Forsgren H, Grahn K, Karlsson J, Karvi T, Pulkkis G. Securing controlsignaling in mobile IPv6 with identity-based encryption. Issues in InformingScience and Information Technology 2009;6:64967.

Elgoarany K, Eltoweissy M. Security in mobile IPv6: a survey. Information SecurityTechnical Report 2007;12(1):3243.

Elshakankiry O, Zhang N, Carpenter A. Securing home and correspondent registra-tions in mobile IPv6 networks. University of Manchester, School of ComputerScience; 2010.

Georgiades A. A security protocol for authentication of binding updates in MobileIPv6. Middlesex University; 2011.

Georgiades A, Luo Y, Lasebae A, Comley R. Dual identity return routability for thesecurity of mobile Ipv6 binding updates within the distributed authenticationprotocol. In: Proceedings of the 6th WSEAS international conference on appliedinformatics and communications. World Scientific and Engineering Academyand Society (WSEAS); 2006. p. 40611.

Georgiades A, Luo Y, Lasebae A, Comley R. Location privacy in mobile IPv6distributed authentication protocol using mobile home agents. In: Proceedingsof the 8th WSEAS international conference on electronics, hardware, wirelessand optical communication. Cambridge, UK: World Scientific and EngineeringAcademy and Society (WSEAS); 2009. p. 516.

Guan J, You I, Xu C, Zhou H, Zhang H. Survey on route optimization schemes forproxy mobile IPv6. In: Proceedings of the 6th international conference oninnovative mobile and internet services in ubiquitous computing (IMIS).Palermo, Italy: IEEE; 2012. p. 5416.

Gunderson SH. Global IPv6 statistics-measuring the current state of IPv6 forordinary users. Google White Paper; 2008.

Haddad W, Dupont F, Madour L, Arkko J. Applying cryptographically generatedaddresses to optimize MIPv6 (CGA-OMIPv6). Internet Engineering Task Force(IETF); 2005.

Haddad W, Krishnan S. Optimizing mobile IPv6 (OMIPv6). Internet EngineeringTask Force (IETF); 2004.

Hassan MM, Hoong PK. Seamless handover integrated solution for video transmis-sion over proxy mobile IPv6 in a micro mobility domain. Journal of Networkand Computer Applications 2012;36:6676.

Islam R. Enhanced security in mobile IP communication.Stockholm; Sweden:Department of Computer and Systems Sciences, Royal Institute of Technology;2005 ([MSc thesis]).

Johnson D., Perkins C., Arkko J. RFC 3775: mobility support in IPv6. InternetEngineering Task Force (IETF); June 2004.

Kalajdzic K, Patel A, Taghavi M. Two methods for active detection and prevention ofsophisticated ARP-Poisoning Man-in-the-Middle attacks on switched ethernetLANs. International Journal of Digital Crime and Forensics (IJDCF) 2011;3:5060.

Kandirakis I. Route optimization for mobile IPV6 using the return routabilityprocedure: test bed implementation and security analysis.California: Monterey;2007 ([Master's thesis]).

Kempf J, Arkko J, Nikander P. Mobile IPv6 security. Wireless Personal Communica-tions 2004;29(34):389414.

Kempf J, Gentry C, Silverberg A. Securing IPv6 neighbor discovery using addressbased keys (ABKs). draft-kempf-ipng-secure-nd-00 txt. Work in progress; 2002.

Kent S. RFC 4303: IP encapsulating security payload (ESP). Internet EngineeringTask Force (IETF); 2005.

Koo J-D, Lee D-C. Extended ticket-based binding update (ETBU) protocol for mobileIPv6 (MIPv6) networks. IEICE transactions on Communications 2007;90:77787 ([Oxford University Press]).

Koo J, Koo J, Lee D. A new authentication scheme of binding update protocol onhandover in mobile IPv6 networks. In: Proceeding of international conferenceon emerging directions in embedded and ubiquitous computing. Springer-Verlag Berlin; 2006. p. 9728.

Le F., Faccin S.M. Dynamic Diffie Hellman based key distribution for mobile IPv6.Internet Engineering Task Force (IETF); 2001.

Li X, Niu J, Khurram Khan M, Liao J. An enhanced smart card based remote userpassword authentication scheme. Journal of Network and Computer Applica-tions 2013.
http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref1http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref1http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0005http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0005http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0005http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0010http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0010http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0015http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0015http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0015http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0020http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0020http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0025http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0025http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0030http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0030http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0030http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref2http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref2http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref2http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0035http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0035http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0035http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0040http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0040http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0040http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0040http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0045http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0045http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0045http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0050http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0050http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0055http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0055http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0055http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref3http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref3http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref3http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref4http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref4http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref5http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref5http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref5http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref6http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref6http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0060http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0060http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0060http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0060http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0060http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0065http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0065http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0065http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0065http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0065http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0070http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0070http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0070http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0070http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0075http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0075http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0080http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0080http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0080http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0085http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0085http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref7http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref7http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref7http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref8http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref8http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref8http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0090http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0090http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref9http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref9http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref9http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref10http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref10http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref10http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref11http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref11http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0095http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0095http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0100http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0100http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref12http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref12http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref12http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0105http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0105http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0105http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0105http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0110http://refhub.elsevier.com/S1084-8045(13)00173-2/othref0110http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref13http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref13http://refhub.elsevier.com/S1084-8045(13)00173-2/sbref13


Lowe G. Casper: A compiler for the analysis of security protocols. In: Proceedings ofthe 10th computer security foundations workshop. Rockport, MA: IEEE; 1997.p. 1830.

Mankin A, Bradner S, Schiller J. A framework for purpose built keys (PBK). InternetEngineering Task Force (IETF); 2003.

Mankin A, Patil B, Harkins D, Nordmark E, Nikander P, Roberts P, et al. Threatmodels introduced by Mobile IPv6 and requirements for security in mobileIPv6. Internet Engineering Task Force (IETF); 2001.

Modares H. A scalar multiplication in elliptic curve cryptography with binarypolynomial operations in Galois Field.Kuala LumpurMalaysia: University ofMalaya; 2009.

Moon JS, Lee SH, Lee IY, Byeon SG. Authentication protocol using authorizationticket in mobile network service environment. In: Proceedings of the 3rdinternational conference on human-centric computing (HumanCom'10). Cebu:IEEE; 2010. p. 16.

Neuman C, Yu T, Hartman S, Raeburn K. RFC 4120: the Kerberos networkauthentication service (V5). Internet Engineering Task Force (IETF); 2005.

Nikander P, Arkko J, Aura T, Montenegro G. Mobile IP version 6 (MIPv6) routeoptimization security design. In: Proceedings of the IEEE vehicular technologyconference fall 2003. vol. 3. Orlando: IEEE; 2003. p. 20048.

Nikander P, Arkko J, Aura T, Montenegro G, Nordmark E. Mobile IP version 6 routeoptimization security design background. Internet Engineering Task Force(IETF); draft-ietf-mip6-ro-sec-03 (work in progress); 2005.

Ortiz JH, Perea J, Lpez JC, Ortiz A. Integration of protocols FHAMIPv6/AODV in Adhoc networks. Network Protocols and Algorithms 2011;3(1):8293.

Perkins C, Johnson D, Arkko J. RFC 6275: mobility support in IPv6. InternetEngineering Task Force (IETF); 2011.

Perkins C.E. RFC 4449: securing mobile IPv6 route optimization using a staticshared key. Network Working Group; 2006.

Rathi S, Thanuskodi K. A Secure and fault tolerant framework for mobile IPv6 basednetworks. International Journal of Computer Science and Information Security2009;5:4655.

Ren K, Lou W, Zeng K, Bao F, Zhou J, Deng RH. Routing optimization security inmobile IPv6. Computer Networks 2006;50:240119.

Rescorla E. SSL and TLS-designing and building secure systems. Boston, MA, USA;2001.

Riedel I, Paar IC. Security in ad-hoc networks: Protocols and elliptic curvecryptography on an embedded platform. Ruhr-Universitaet Bochum; 2003([Master's thesis]).

Rigney C, Willens S, Livingston R, Merit A, Simpson W. RFC 2865: remoteauthentication dial in user service (RADIUS). Internet Engineering Task Force(IETF); 2000.

Rivest R. RFC 1321: the MD5 Message-Digest Algorithm. Internet Engineering TaskForce (IETF); April 1992.

Rocha BP, Costa DN, Moreira RA, Rezende CG, Loureiro AA, Boukerche A. Adaptivesecurity protocol selection for mobile computing. Journal of Network andComputer Applications 2010;33:56987.

Roe M, Aura T, O'Shea G.J. Arkko Authentication of mobile IPv6 binding updates andacknowledgments. Internet Engineering Task Force (IETF). Work in Progress;2002.

Sahadevaiah K, Prasad Reddy PVGD. Impact of security attacks on a new securityprotocol for mobile ad hoc networks. Network Protocols and Algorithms2011;3:12240.

Sehwa S, Hyoung-Kee C, Jung-Yoon K. A secure and lightweight approach forrouting optimization in mobile IPv6. EURASIP Journal on Wireless Commu-nications and Networking 2009;1:110.

Soliman H. Securing mobile IPv6 signaling. Mobile IPv6: mobility in a wirelessInternet. Addison-Wesley; 2004.

Srivastava S, Nandi G. Self-reliant mobile code: a new direction of agent security.Journal of Network and Computer Applications 2013:114.

Stoneburner G. Underlying technical models for information technology security.National Institute of Standards & Technology; 2001.

Subashini S, Kavitha V. A survey on security issues in service delivery models ofcloud computing. Journal of Network and Computer Applications 2011;34:111.

Sudanthi S. Mobile IPv6. Information Security Reading Room 2003;1:114.Sun H, Song J, Chen Z. Survey of authentication in mobile IPv6 network. In:

Proceedings of 7th IEEE conference in consumer communications and network-ing conference (C

A survey of secure protocols in Mobile IPv6

Documents

Transcript of A survey of secure protocols in Mobile IPv6