routing optimization security in mobile ipv6

ARTICLE IN PRESS

Computer Networks xxx (2005) xxx–xxx

www.elsevier.com/locate/comnet

Routing optimization security in mobile IPv6

Kui Ren a,*, Wenjing Lou a, Kai Zeng a, Feng Bao b, Jianying Zhou b,Robert H. Deng c

a Department of Electrical and Computer Engineering, Worcester Polytechnic Institute, 100 Institute Road,

Worcester, MA 01609, United Statesb Institute for Infocomm Research, 21 Heng Mui Keng Terrace, Singapore 119613, Singapore

c School of Information Systems, Singapore Management University, Singapore 259756, Singapore

Received 30 March 2004; received in revised form 1 August 2005; accepted 17 September 2005

Responsible Editor: C. Blondia

Abstract

Route Optimization (RO) in Mobile IPv6 (MIPv6) provides a mobile node (MN) the opportunity to eliminate the inef-ficient triangle routing with its corresponding node (CN) and therefore, greatly improves the network performance. How-ever, in doing so, MIPv6 introduces several security vulnerabilities, and among them a major concern is the authenticationand authorization of Binding Updates (BUs) during the RO process. Unauthenticated or malicious BUs open the door formany types of attacks. As every IPv6 node is expected to support MIPv6, mechanisms to secure BU will have a significantimpact on the next generation Internet. In this paper, based on an in-depth analysis of the security weaknesses existing inpreviously proposed protocols, a light-weight BU protocol with high security strength is proposed, which makes use ofpublic key certificate-based strong authentication technique. Another important contribution of the paper is the introduc-tion of a novel and scalable 3-layer trust management framework, which takes advantage of IPv6 address format and homelink�s jurisdiction over the addresses it assigns, and thereby solves the difficult certificate issuing and management problempresented in the previous public key certificate-based solutions via trust delegation. The proposed protocol is highly effi-cient in term of both computation and communication costs on both MN and CN sides. An extended protocol is also pro-posed to explicitly support Hierarchical MIPv6 (HMIPv6).� 2005 Elsevier B.V. All rights reserved.

Keywords: MIPv6; Routing optimization; Security; Binding Update protocol

1. Introduction

Mobile IP version 6 (MIPv6) is an IP-layermobility protocol for the IPv6 Internet [11,12,23],

1389-1286/$ - see front matter � 2005 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2005.09.019

* Corresponding author. Tel.: +1 508 831 5783.E-mail address: [email protected] (K. Ren).

which is designed based on the idea of providingmobility support on top of the existing IP infra-structure, without requiring any modifications torouters, applications or stationary hosts. The MIPallows transport layer sessions (TCP connectionsor UDP-based transactions) to continue even ifthe underlying host(s) move and change their IPaddresses; it also allows a node to be reached

.

mailto:[email protected]

2 K. Ren et al. / Computer Networks xxx (2005) xxx–xxx

ARTICLE IN PRESS

through a static IP address. MIPv6 takes the viewthat IP addresses can be used as natural identifiersof nodes, as they have been used since the beginningof the Internet.

In MIP, a mobile node (MN) is addressed by twoIP addresses, a home address (HoA) and a care-ofaddress (CoA). A MN has its static HoA at its homesubnet. When moving to a new subnet, the MN willdiscover the default router, perform (stateful orstateless [9,32]) address auto-configuration, anduse its new address as CoA. The former is an IPaddress assigned to MN within its subnet prefixon its home link and the latter is a temporaryaddress acquired by MN while visiting a foreignlink. This dual address mechanism realizes thedesign goal of MIP. Mobile IP version 4 (MIPv4)was specified in [23] and MIPv6 was specified in[12]. Mobility support in IPv6 is considered particu-larly important, since mobile devices are predictedto account for a significant fraction of the popula-tion of the Internet during the lifetime of IPv6.

In MIPv4, when a MN changes location, itobtains a CoA and informs its Home Agent (HA)its new CoA and the HA encapsulates and tunnelsany packets it receives for MN on its home networkto this CoA. Therefore, every time a correspondentnode (CN) sends a packet to MN, while MN isaway from home link, the packet first travels tothe home network before reaching the MN. Thisinefficient routing is called triangle routing. InMIPv6, there are two possible modes for communi-cations between the MN and a CN. One mode iscalled bidirectional tunnelling. In this mode, packetsfrom the CN are routed to the home agent and thentunnelled to the MN. Packets to the CN are tun-nelled from the MN to the home agent (‘‘reversetunnelled’’) and then routed normally from thehome network to the CN. The other mode, ‘‘RouteOptimization’’(RO), requires the mobile node to

Fig. 1. Basic operati

register its current binding at the correspondentnode. RO provides MN the opportunity to elimi-nate the inefficient triangle routing and bidirectionalMN–HA tunnelling as shown in Fig. 1. On receivinga tunnelled packet from its HA, MN knows that CNthat sent the packet is unaware of its current CoA.MN may choose to inform CN its new CoA usinga Binding Update (BU) message, thereby allowCN to send subsequent packets directly to MN.Unfortunately, unauthenticated or malicious BUmessages provide intruders an easy means to launchvarious types of attacks [7,8,16,19,20]. Therefore,RO security is of paramount importance for MIPv6to meet its basic security requirements.

In this paper, based on an in-depth analysis ofthe security weaknesses existing in previously pro-posed protocols, a light-weight BU protocol withhigh security strength is proposed. Our protocolmakes use of public key certificate-based strongauthentication technique. Another important con-tribution of the paper is the introduction of a noveland scalable 3-layer trust management framework,which takes advantage of IPv6 address format andhome link�s jurisdiction over the addresses it assignsand therefore, solves the difficult certificate issuingand management problem presented in the previouspublic key certificate-based solutions via trust dele-gation. Also by taking advantage of early bindingupdate technique, the proposed protocol is highlyefficient in term of both computation and communi-cation costs with respect to both MN and CN sides.An extended protocol is also proposed to explicitlysupport Hierarchical MIPv6 (HMIPv6).

The rest of the paper is organized as follows:In Section 2, we give the background of securitydesign in MIPv6, as well as the security threats. InSection 3, we review three existing state-of-the-artRO protocols presented in the IETF�s Internetdrafts and [10,24]. We focus on the security analysis

ons in MIPv6.

K. Ren et al. / Computer Networks xxx (2005) xxx–xxx 3

ARTICLE IN PRESS

of these protocols and point out their security limi-tations. Section 4 is devoted to our new protocoland its analysis. Finally, Section 5 is our concludingremarks.

2. Background in MIPv6 security

2.1. Basic assumptions for MIPv6 and its security

The main assumptions [7,8,10,16,19,20] whichdrive the MIPv6 design and specifications are : (1)The routing prefixes available to a node are deter-mined by its current location, and therefore thenode must change its IP address as it moves; (2)The routing infrastructure is assumed to generallydeliver packets to their intended destinations asidentified by the destination address. The design ofMIPv6 is to follow the end-to-end principle, to dulynotice the differences in trust relationships betweenthe nodes, and not to make the security any worsethan IPv4 is today. The end-to-end principle is ap-plied by restricting mobility related state primarilyto the home agent. Additionally, the correspondentnodes also maintain a soft state [20]. The securityassumptions made on MIPv6 are as follows:

1. Pre-established security association between amobile node and its home agent: Mobile nodesand home agents know each other, and can thushave a pre-established strong security associationto reliably authenticate exchanged messagesbetween them. IPsec Encapsulating Security Pay-load (ESP) [3] is used to set up a secure tunnelbetween a mobile node and its home agent.

2. No pre-established security association between amobile node and a random correspondent node:It is expected that MIPv6 will be used on a globalbasis between nodes belonging to differentadministrative domains, hence building a globalauthentication infrastructure to authenticatemobile nodes and random correspondent nodeswould be a very demanding task, at least in thenear to medium terms. Furthermore, making atraditional authentication infrastructure to keeptrack of correct IP addresses for all hosts is eitherimpossible or at least very hard due to thedynamic association between IP addresses andhosts [10].

The current MIPv6 RFC reacts to the secondassumption with a so-called infrastructurelessauthentication mechanism (i.e., Return Routability

(RR) [7,8,20] or Cryptographically Generated Ad-dresses (CGA) [5,6,29]) and thus sacrifices securitystrength and is exposed to certain attacks. The solu-tion reflects only a straightforward response to thesecond assumption. While it is true that neitherthe existence nor the deployment of global publickey infrastructure (PKI) (or other global securityinfrastructure) for authentication on MIPv6 nodeswithout pre-relationship is possible in the nearfuture, this does not rule out the possibility ofhaving fragmented authentication infrastructureswithin individual administration domains or evencross different domains. For example, secure BGP(S-BGP) relies on a PKI where announced prefixesexchanged among ASes are certified [34,35]. We alsonotice that IPv6 addresses are assigned in a hierar-chical manner [17]. Very few blocks of addresses willbe directly assigned by Internet addressing authori-ties. In general, IP addresses are required to obtainfrom its upstream Internet Service Provider (ISP),which in turn gets address from the next level up.Only the Top Level Aggregators (TLA) getaddresses assigned by an addressing authority, andusually belong to global or ‘‘Tier-1’’ ISPs (e.g.,UUNET, Sprint, AOL, AT&T, NTT, etc.) [17].These Tier-1 ISPs cooperate extensively with eachother and have well-established long term trust rela-tionships, and hence it is easy to prove each otheron the ownership of their corresponding subnet pre-fixes through mutually trusted certificates or othermeans. This observation leads to a reasonablereduction that reduces the difficult authenticationproblem of MIPv6 nodes to a much easier one.The problem of authentication of a MIPv6 nodecan firstly be delegated to the home agent it belongsto based on the first assumption. The problem thencan be further delegated to the upper level ISPs thehome agent belongs to. Finally, a Tier-1 ISP is sup-posed to authenticate itself on behalf of the mobilenode. Obviously, the above reduction leads to amuch simpler and more practical solution forauthentication of MIPv6 nodes and therefore,allows strong security designs in MIPv6.

On the other hand, portable devices with con-straint computational ability and battery life, suchas PDAs and cellular phones, are predicted toaccount for a majority or at least a substantial frac-tion of the population of mobile devices [10]. Hence,computational cost at mobile nodes side should belight-weight, and public key cryptosystem opera-tions should be avoided whenever possible in thesecurity design. Usually, there are two ways to


ARTICLE IN PRESS

reduce the computation cost: (1) Reduce the numberof computationally expensive operations. (2) Dele-gate the computationally expensive operations tomore powerful nodes (e.g., home agents in our case).The number of communication rounds is anotherconsideration in the light-weight security design.Due to the dynamic and error-prone nature in wire-less environments, less communication rounds arepreferred to ensure the success of the protocolbesides the consideration of saving power.

2.2. Security threats in MIPv6

The goal in designing MIPv6 is simply to makeIPv6 mobile and at least as secure as the staticIPv6. However, MIPv6 does introduce several addi-tional security vulnerabilities into IPv6 and amongthem the biggest concern is the weak authenticationand authorization of BUs. As discussed before, ROin MIPv6 greatly improves the efficiency of routingby allowing the shortest communications path to beused and eliminating congestion at the mobilenode�s home agent and home link; however, it alsogreatly increases the number of BUs sent by aMN to its CNs, and in doing so, greatly increasesthe security risk of MIPv6. As every IPv6 node isexpected to be deployed as a MIPv6 node as well,and every MIPv6 node is to be a CN, BU securitythreats can been seen as applicable to the wholeInternet.

Firstly, unauthenticated or malicious BUs opensthe door for many types of attacks as discussedbelow [4,7,8,10,16,19,20,31].

False Binding Update Attack: Spoofed BUs maybe sent to HAs and CNs. By spoofing BUs, anattacker can redirect traffic to itself or another nodeand prevent the original node from receiving trafficdestined to it. For example, let us say nodes A and Bhave been communicating with each other, then, anattacker, node C, sends a spoofed BU packet tonode B, claiming to be node A with a CoA of nodeC. This would cause node B to create a binding fornode A�s CoA and subsequent further traffic to nodeC, believing it to be node A�s new CoA. Node Awould not receive the data it was intended toreceive, and, if the data in the packets is not crypto-graphically protected, node C will be able to see allof node A�s sensitive information.

Man-in-the-Middle Attack: An attacker may alsospoof BUs to two CNs in order to set itself as aMan-in-the-Middle between a MN and a CN. Forexample, if node A and node B are communicating,

the attacker could send both nodes a spoofed BUwith the CoA set to its own address. This wouldcause both nodes A and B to send all packets tonode C rather than to each other, and therefore,results in attacks against secrecy and integrity.(Note that without RO, an attacker would have tobe in the path between the nodes in order to captureand read packets.)

Denial-of-Service Attack: By sending spoofedBUs, an attacker could also send large amounts ofunwanted traffic to overwhelm the resources of asingle node or those of a network. The attackercould first find a site with streaming video oranother heavy data stream and establish a connec-tion with it. Then it could send a BU to the corre-sponding node, saying to redirect subsequent datatraffic to the attacker�s new location, that of an arbi-trary node. This arbitrary node would be thenbombed with a large amount of unnecessary traffic.Similarly, the attacker could also use spoofed BUsto redirect several streams of data to randomaddresses with the network prefix of a particulartarget network, thereby congesting an entire net-work with unwanted data.

Secondly, the adversary may also try to attackthe BU protocol itself, and thus prevent the proto-col participants from correctly completing the pro-tocol [4,10]. Basically, this type of attacks can beidentified as DoS attacks. The stateful protocolsare known to expose the protocol participants toDoS attack. ‘‘In particular, if a host stores a statein a protocol run that someone else has initiatedand before authenticating the initiator, an attackercan initiate the protocol many times and cause thehost to store a large number of unnecessary proto-col states’’ [7]. Other attacks of this type includereflection and amplification attack and replay attack[7,36]. In reflection and amplification attack, pack-ets are sent into a looping path to the target (ampli-fication); the attacker can also hide the source of apackets by reflecting the traffic from other node(reflection), and therefore, the protocol participantnodes can be tricked into sending many more pack-ets than they receive from the attacker. In replayattack, the attacker captures the BUs of MN, andtries to replay back after MNmoved away wheneverpossible.

Note that the different attacks assume differentconditions and requirements of the attackers andtherefore, the security threats vary largely. We willdiscuss them along with the analysis of the existingprotocols.


ARTICLE IN PRESS

3. Security analysis of the state-of-the-art protocols

In this section we first discuss the latest IETFMobile IPv6 draft, i.e., Mobility Support in IPv6[12] and its security flaws. Our certificate-basedBinding Update (CBU) protocol, which was pro-posed among the first to improve the securitystrength of the current Internet draft [10], is thendiscussed. Comments on security limitations of theCBU protocol conclude this section. We list belowthe cryptographic notation used throughout thepaper for easy reference:

h( )
a cryptographic secure one-way hashfunction, or one-way hash function inshort, such as MD5 [26] and SHA [22].
prf(k, m)
a keyed one-way pseudo-randomfunction—often a keyed hash function[15]. It accepts a secret key k and amessage m, and generates apseudo-random output. This functionis used for both generation of messageauthentication codes and derivation ofcryptographic keys.
PX/SX
public/private key pair of node X ina digital signature scheme such asRSA [27] or DSS [21].
SX(m)
node X�s digital signature on amessage m using the private key SX.
mjn
concatenation of two messages m and n. KCN a secret key for a correspondent
node—it stays the same betweenprotocol runs, but canchange periodically.

Fig. 2. The Return Routability Protocol.

3.1. IETF related secure binding update protocols

In this subsection we describe and analyze twokinds of protocols for authenticating BindingUpdate messages, the Return Routability (RR) pro-tocol appeared in [12,19] and the CGA-based proto-cols proposed in [14,28].

3.1.1. The RR protocol and its analysisThe RR protocol consists of two checks, a home

address check and a care-of address check. Basi-cally, it means that a node verifies that there is anode that can respond to packets sent to a givenaddress. It is assumed that a successful reply indi-cates that there is indeed a node at the givenaddress, and that the node is willing to reply to

the probes sent to it. The packet flow is depictedin Fig. 2. The real return routability checks arethe message pairs (Home Test, BU) and (Care-ofTest, BU). The Home Test Init (HoTI) and Care-of Test Init (CoTI) packets are only needed to trig-ger the test packets, and the BU message acts as acombined routability response to both of the tests.

1. Home Address check: The Home Address checkconsists of a Home Test (HoT) packet and a sub-sequent BU. The HoT is assumed to be tunnelledby the HA to the MN. The HoT contains a cryp-tographically generated token, home token =h(KcnjHoAjnij0), which is formed by calculatinga hash function over the concatenation of a secretkey Kcn known only by the CN, the sourceaddress of the HoTI packet, and a nonce ni.The index i is also included in the HoT packet,allowing the correspondent node to easier findthe appropriate nonce.

2. Care-of Address check: From the CN�s point ofview, the care-of address check is very similarto the Home address check, but the packet is sentdirectly to MN�s CoA. Furthermore, the tokenis created in a slightly different manner in orderto make it impossible to use home tokens forcare-of tokens or vice versa (care-of token =h(KcnjCoAjnjj1)).

3. Forming the first Binding Update: When themobile node has received both the HoT andCoT messages, it creates a binding key Kbm:Kbm = h(care-of tokenjhome token) by taking ahash function over the concatenation of thetokens received. This key is used to protect thefirst and the subsequent binding updates, as longas the key remains valid. Note that Kbm is avail-able to anyone that can obtain both CoT andHoT messages.


ARTICLE IN PRESS

In the RR protocol, the two token exchangesverify that MN is alive at its corresponding HoAand CoA, respectively. The liveness test is used tosubstitute authentication of nodes as the responseto the infrastructureless assumption. While it is veryuseful to make sure the liveness of MN on bothHoA and CoA, the security of RR protocol obvi-ously hinges on the secret sharing of Kbm betweenMN and CN, which in turn hinges on the secrecyof one of the two tokens. As pointed out above,the two tokens are available to anyone that canobtain both CoT and HoT message. Hence, thesecurity of RR protocol is considerably weak.Although the authors argued that the motivationfor designing the RR protocol was to have sufficientsupport for MIP, without creating major new secu-rity problems. It was not the goal to protect againstattacks that were already possible before the intro-duction of IP mobility [7,12,20]. The protocol doesnot defend against an intruder who can monitor theCN–HA path. Such intruders would in any case beable to mount an active attack against MN when itis at its home location. However, the design princi-ple of the RR protocol, i.e., defending against intru-der who can monitor the CN–MN path but not theCN–HA path, is fundamentally flawed since it vio-lates the well known ‘‘weakest link’’ principle insecurity as pointed out in [10]. After all, one hasno reason to assume that an intruder will monitorone link and not the other, especially when theintruder knows that monitoring a given link is par-ticularly effective to expedite its attack. While it istrue that intruders are able to mount active attackswhen a node is at home in the base IPv6, it is mucheasier to launch such attacks in MIPv6 than in thebase IPv6.

First, let us consider the false BU attack. In thecase of the base IPv6 without mobility (which isequivalent to the mobile node MN at its home linkin MIPv6), to succeed in the attack, the intrudermust be constantly present on the CN–HA path.In order to redirect CN�s traffic intended for MNto a malicious node, the intruder most likely hasto get control of a router or a switch along theCN–HA path. Furthermore, after taking over thesession from MN, if the malicious node wants tocontinue the session with CN while pretending tobe MN, the malicious node and the router need tocollaborate throughout the session. For example,the router tunnels CN�s traffic to the malicious nodeand vice versa. In the case of MIPv6, the effort com-

mitted to break the RR protocol to launch a sessionhijacking attack could be considerably less. Assumethat MN1 and CN are having an on-going commu-nication session and the intruder wants to redirectCN�s traffic to his collaborator MN2. The intrudermonitors the CN–HA path (i.e., anywhere fromMN1�s home network to CN�s network) to obtainHoT, extracts the home token CH and sends itMN2. Upon receiving CH, MN2 sends a CoTI toCN and CN will reply with a care-of token CC.MN2 simply hashes the two cookies to obtain avalid session key, and uses the key to send a bindingupdate message to CN on behalf of MN1. The bind-ing update will be accepted by CN which will in turndirect its traffic to MN2.

Next, consider the malicious mobile node flood-ing attack. In the base IPv6 without mobility, per-haps the best example of flooding attack is theDDoS attack in which a multitude of compromisedsystems attack a single target. There are many waysto launch a malicious mobile node flooding attackagainst a victim (which can be either a node or anetwork) in MIPv6. For example, the maliciousnode starts some traffic intensive sessions with cor-respondent nodes and moves to the victim�s networkor the border between the victim network and theoutside world. It then runs the RR protocol to redi-rect traffic from the correspondent nodes to the vic-tim�s network by sending them binding updatemessages. The malicious mobile node does not needany special software or networking skill to launchthis attack. Due to the stateless nature of the RRprotocol, it is easy for an intruder to cause havocto, say B2C operations. Imagine a correspondentnode provides on-line services to many mobile cli-ents. The intruder can simply eavesdrop on theRR protocol messages to collect cookies on the bor-der between the correspondent node and the Inter-net. The intruder then randomly hashes pairs ofcookies to form session keys, and sends bindingupdate messages to the correspondent node. Thiswill cause redirection of traffic to randomly selectedmobile clients and eventually bring down the ser-vices of the correspondent node. Hence, the RRprotocol is vulnerable to many attacks. The EarlyBinding Updates protocol (EBU) [33] was later pro-posed to increase the protocol execution latency ofthe RR protocol by sending part of messages beforean imminent handover; however, both protocols areof the same security strength, that is, the attacksapplicable above are also applicable to EBU.


ARTICLE IN PRESS

3.1.2. The CGA-based protocol and its analysis

The Cryptographic Generated Address (CGA)[5,6] technique for secure Binding Update, was firstproposed in [29] and then in [28,14]. A 128-bit IPv6address is divided into a 64-bit subnet prefix and a64-bit interface identifier. ‘‘CGA technique gener-ates a valid IPv6 address where the interface identi-fier is computed via a cryptographic one-way hashfunction from a public key and auxiliary parame-ters. The binding between the public key and theaddress can be verified by re-computing the hashvalue and by comparing the hash with the interfaceidentifier’’ [37]. Each CGA is associated with a secu-rity parameter (Sec) and a CGA Parameters datastructure (CGAP). Sec is a 3-bit unsigned integerand determines the security strength against brute-force attacks. And CGAP = (128-bit Modifier, 64-bit Subnet Prefix, 8-bit Collision Count, variablelength public key, optional variable length Exten-sion Fields). The process of generating a newCGA takes three input values: a subnet prefix, thepublic key of the address and the Sec. The outputof the address generation algorithm is a new CGAand a CGAP. CGA verification takes as input anIPv6 address and a CGAP. It is important to notethat because CGAs themselves are not certified, anattacker can create a new CGA from any subnetprefix and its own (or anyone else�s) public key.

CAM-DH was proposed based on CGA tech-nique to secure Binding Updates in [28]. In CAM-DH, each MN has a public and private key pairPMN and SMN in a digital signature scheme. MN�sHoA is a CGA generated from PMN. The protocolis described in Fig. 3, which contains five messagesin total:

Fig. 3. The CAM-DH Protocol.

Message 1: MN ! CN:HoA, CoA.Message 2: CN ! MN�sHoA:{rh, j, g

y}, where rh ¼MACKCN ðHoAjNjj0Þ.

Message 3: HA ! MN�sCoA:{rh, j, gy}, where rh ¼

MACKCN ðHoAjNjj0Þ.Message 4: CN ! MN�sCoA:{rc, j}, where rc ¼

MACKCN ðCoAjNjj1Þ.Message 5: MN ! CN : fT 0;HoA;CoA; i;MACKBU

ðT 0jHoAjCoAjiÞ;gx;SMN ðTypeTagjgxjHoAÞ;PMN ;MACK3

ðT 0j . . .PMN Þ; jg, where K3 =h(rhjrc), Kh = h(gxyjrh), KBU = h(Khjrc).

In Message 1, the MN informs the CN that it ismobile, and gives both the mobile�s home address(HoA) and its care-of address (CoA). In Message2, CN sends the MN one challenge rh to the homeaddress, the Diffie–Hellman exponent gy and a serialnumber j that indicates which version of Nj was usedto generate the challenge. In Message 3, HA for-wards Message 2 to MN� CoA. In Message 4, CNsends the MN one challenge rc to the care-of addressand the same serial number j as that in Message 2.In Message 5, MN sends CN a binding update, amessage authentication code on the binding updatecomputed using KBU, the MN�s Diffie–Hellmanexponent signed with its private signature keySMN, the MN�s public signature key PMN, and amessage authentication code on all of the aforemen-tioned data, computed using a key derived from thetwo challenges. This message contains a tag T0 sothat it can be distinguished from message 1 of thevariant version of the protocol. The binding updatealso contains a sequence number i so that if morethan one binding update is sent within the lifetimeof a single value of Nj, it is possible to determinetheir relative ordering. ‘‘The TypeTag is used to pre-vent accidental type collision with messages of otherprotocols that use the same signature public key butmay or may not use type tags’’ [37]. CN verifies thetwo MACs and can check integrity and identity ofgx by CGA.

Although the use of CGA offers CAM-DH amethod for binding MN�s PMN to its IPv6 address,CAM-DH suffers from some limitation and prob-lems. First, CAM-DH does not authenticate thecare-of address. An attacker who can interceptpackets sent to the care-of address can completethe protocol and cause the care-of address to beflooded with data, even if the host that actuallyowns the care-of address is not willing to participatein the protocol. An alternative method of authenti-cating the care-of address would have been to derive

Fig. 4. The CBU Protocol.


ARTICLE IN PRESS

the care-of address (as well as the home address)from the node�s public key. But this approach maynot be applicable, because some subnetworks mayimpose constraints on the care-of addresses thatcan be used. Second, CGA generation is computa-tionally expensive, especially when MN uses a highSec value. CAM-DH protocol needs much process-ing power because it involves asymmetric cryptogra-phy and CGA. Further, the computation load onMN side is heavy since every BU message requiresthe MN to generate a signature and the CN to per-form a signature verification.

Another recently proposed CGA-based protocol,CGA-OMIPv6 [14], follows the same principles asin the original RR protocol and combines CGAtechnique and other mechanisms. Although thisprotocol reduces the signaling load and the handoffdelay, it is exposed to the man-in-the-middle attack.Also, it is computationally expensive when generat-ing CGA.

3.2. The CBU protocol and its analysis

In [10], we proposed the certificate-based BindingUpdate protocol (CBU) to solve the security prob-lems discussed above. In the CBU protocol, the dig-ital signature cryptosystem is also used. The public/private key pair of HA is denoted by PHA and SHA.The private key SHA is kept by HA in the home link,probably inside a tamper-resistant hardware ofcryptogram processing device. The home linkobtains a public key certificate:

CertHA ¼ fHLSP ; PHA; Valid Interval; SIGCAgfrom a Certification Authority (CA), where HLSPis the home link subnet prefix, Valid_Interval is thevalid duration of the certificate, and SIGCA isCA�s signature on HLSP, PHA and Valid_Interval.Fig. 4 shows message exchanges between a MN,its HA and its CN in CBU protocol. The existenceof operations performed by HA is made transparentto CN.

When MN wants to start RO operation with CN,it sends a RO request REQ = {HoA, CN, n0} to CNvia reserved tunnelling, where n0 is a nonce valueused to match the reply message REP. CN is usedto represent both the correspondent node and itsIP address. Message REQ is sent to MN�s HA viathe IPsec protected secure tunnel. Upon arrivingat HA, REQ is intercepted by HA using IPv6Neighbor Discovery [16,18]. HA will not forwardREQ to CN, instead, it creates a cookie C0 and

sends COOKIE0 = {HoA, CN, C0} to CN. In reply,CN creates a nonce n1 and a cookie C1, and sendsCOOKIE1 = {CN, HoA, C0, C1, n1} to MN. Notethat the destination address in COOKIE1 is MN�sHoA.

After receiving COOKIE1, HA checks on thevalidity of C0, generates a nonce n2 and a Dif-fie–Hellman (DH) secret value x, and computesthe public value gx. Then HA generates a signa-ture SIGHA = SHA(HoAjCNjgxjn1jn2jTS) using itsprivate key SHA. Finally, HA replies CN withEXCH0 = {HoA, CN, C0, C1, n1, n2, g

x, TS, SIGHA,CertHA}, where CertHA = {HLSP, PHA, Valid_Inter val, SIGCA} is the public key certificateof HA. When CN receives EXCH0, it validatesthe cookies, the HA�s public key certificateCertHA, the signature and importantly, checksfor equality of the HA�s subnet prefix stringsembedded in both CertHA and HoA. If all the val-idations and checking are positive, CN can beconfident that the home address HoA of MN isauthorized by its HA and the DH public valuegx is freshly generated by MN�s HA. CN nextgenerates its own secret value y and its publicvalue gy, and then computes the DH keyKDH = (gx)y, a session key KBU = prf(KDH, n1jn2)and a MAC MAC1 = prf(KBU, g

yjEXCH0), andsends EXCH1 = {CN, HoA, C0, C1, g

y, MAC1} toMN. Again, this message is intercepted by HA,which first validates the cookies, calculates theKDH = (gy)x and KBU = prf(KDH, n1jn2). HA thencomputes MAC2 = prf(KBU, EXCH1), and sendsan optional CONFIRM = {HoA, CN, MAC2} toCN. The validity of MAC2 is checked by CNand if valid, CN creates a cache entry for HoAand the session key KBU, which will be used forauthenticating binding update messages fromMN. Upon positive verification of MAC1, HA


ARTICLE IN PRESS

also sends REP = {CN, HoA, n0, KBU} to MNthrough the secure IPsec ESP protected tunnel.After receiving REP, MN checks that n0 is thesame as the one it sent out in REQ. If so, MNproceeds to send CN binding update messagesprotected using KBU as in the RR protocol.

The protocol came up with a novel idea that cre-ates a certificate for a home link, i.e., the subnet pre-fix instead of individual IP address. The argumentgoes as follows: First, IP addresses are oftenobtained by DNS (Directory Name Service) look-up and DNS does not provide a secure way of map-ping names to IP addresses. Second, IP addressesare subject to renumbering both when service pro-viders change and when configurations change sothey may not be as persistent as other subject names(e.g., domain names) [25]. Third, IP addresses areleased to an interface for a fixed length of time.When an IP address�s lease time expires, the associ-ation of the address with the interface becomes inva-lid and the address may be reassigned to anotherinterface elsewhere in the Internet. And there mightbe various reasons for keeping IP addresses� leasetime short, such as for privacy protection. There-fore, it is very difficult in practice for CAs to keeptrack of correct associations between IP addressesand all devices� interfaces in a consistent and timelymanner, not to mention certificate renewal and rev-ocation task. Subnet prefixes for home links, how-ever, are more trackable and manageable. First, ahome link subnet prefix is normally much more per-sistent than MN�s home address. Second, the num-ber of home links is significantly smaller than thatof MNs. Third, keeping track of subnet prefixes ismuch easier than that of individual IP address.

The CBU protocol successfully reduces theimpossible task of authenticating MN and itsHoA via individual certificate to a much easierone as above mentioned. However, the protocoldoes not address certificate management issues forHAs. The CBU protocol is based on the assumptionof the existence of fragmented authentication infra-structures within individual administration domainsor even cross different domains. A CA is responsibleto issue the certificate to every home link subnet pre-fix. But simply issuing certificate directly to everyindividual home link subnet prefix from one CA isstill far from practical. Obviously, this flat structureof trust management is not flexible and scalable andeven impossible in crossed domains resided in differ-ent administrative areas, not to mention in the glo-bal-wide range. It is also impossible for consistent

and timely certificate management on renewal andrevocation. Further, neither should it be CA�s dutyto keep tracking of the highly complicated individ-ual subnet prefix changes of home links, nor is itpossible. Note that the number of individual homelinks can be as high as 261 and they can be anywherearound the world. Instead, a divide-and-conquerapproach should be adopted to reduce the complex-ity and therefore, handle the flexibility and scalabil-ity problem as we will explain in the followingsection. The second problem with the CBU protocolis that there�s no way for CN to assure MN�s live-ness on its claimed CoA in the BU message. Thisis dangerous as we have pointed out in Section 2.A spoofed BU lying on MN�s CoA can be sent byany malicious node (acts as MN) and therefore,results in serious attacks.

4. Our secure routing optimization protocol: HCBU

Based on the security analysis against all aboveprotocols mentioned so far, in this paper we pro-pose a Hierarchical Certificate-based BindingUpdate protocol (HCBU). We first discuss the trustmanagement framework of HCBU and then givethe protocol details.

4.1. Trust management in HCBU

One important design rationale behind HCBU istrust delegation. We first analyze the role of HA inthe RR protocol. In the RR protocol, HA onlyrelays the message sent by both MN and CN. Theunderlying assumption is that MN has registeredits CoA to HA, so that HA is aware of MN�s cur-rent CoA, although the registered CoA may be afalse one. Note that there�s no way for HA to mapMN�s HoA to its real CoA if MN lies on its CoA.In the CBU protocol, the functionality of the HAis extended. HA is responsible for proving the cor-rectness of the binding of MN and its HoA toCN. This task in the CBU protocol is achieved byissuing certificate to individual home link subnetprefix and therefore, allowing HA to sign on themessage. This is reasonable because HA shares asecret key with MN and can easily authenticateMN via IPsec. Also once with a certificate in hand,HA can easily prove MN�s ownership of HoA toCN via a signature. Hence in CBU, HA�s duty isto assure CN: (1) MN�s ownership of its HoA and(2) the BU request is indeed sent by MN. In HCBU,HA�s duty is further extended to cover all the nodes


ARTICLE IN PRESS

currently under its link, including roaming mobilenodes. Therefore, it will also certify a roamingMN�s CoA, as long as the roaming MN�s CoA isassigned by itself. HA signs on the binding of(HoA, CoA), which proves MN�s ownership ofCoA.

Trust Setting: Now we focus on the certificateproblem and see how a global PKI can be avoidedvia combining a hierarchical certificate structurewith the inherent unicast address structure ofIPv6. A 3-layer hierarchical trust managementframework is adopted in HCBU to achieve flexibil-ity and scalability as shown in Fig. 5. Basically, thisis a divide-and-conquer approach, taking advantageof the underlying IPv6 address assigning and alloca-tion mechanism. In the 1st layer, based on the exist-ing trust relationships among Tier-1 ISPs, one orseveral mutually agreed CAs are chosen to issue aspecial certificate to each ISP. And each certificateat the minimum contains the following contents:(a) TLAs owned by the given ISP; (b) public keyof the ISP; (c) valid interval; (d) a CA�s signatureon (a), (b) and (c). In the 2nd layer, each Tier-1ISP issues certificate from its own domain to Next

Fig. 5. The 3-layer trust ma

Level Aggregators (NLAs) of its downstream inter-mediate ISPs. The certificate structure is the samewith the former one with slight difference in con-tents: (a) NLAs owned by the intermediate ISP;(b) public key of that intermediate ISP; (c) validinterval; (d) Tier-1 ISP�s signature on (a), (b) and(c) using its own private key. This certificate issuingoperation could be repeated several times accordingto the real situations. Each upper level ISP issuescertificates to its immediate down stream ISPs fromits own domain. Generally, the length of this certif-icate chain would not be long in practice. The certif-icate�s valid interval at each lower layer should beshorter than that of the upper layer certificate.Finally, each home link gets a certificate of itsown on its Site Level Aggregator (SLA). At thispoint, all the routing information (i.e., TLA + N-LA + SLA) in the subnet prefix(s) of a home linkhas been approved by the certificates from boththe 1st and 2nd layer. Then in the 3rd layer, eachhome agent dynamically signs on the binding of(MN, HoA) or (HoA, CoA) upon request, whichproves to CN the correctness of the binding. (Wewill discuss it in detail later.)

nagement framework.


ARTICLE IN PRESS

Trust Delegation: In our trust managementframework, the home agent of MN�s roaming linksigns the binding of (HoA, CoA). Note that this sig-nature only proves MN�s ownership of CoA and isonly used for this purpose. It does not implyMN�s ownership of HoA. This signature togetherwith a valid subnet prefix certificate chain of thatlink convinces MN�s HA that MN actually ownsthis CoA after receiving this information in thecare-of address registration sent by MN. Subse-quently, upon successful verifying MN�s ownershipof its claimed CoA, HA now proves to CN the cor-rectness of the binding of (HoA, CoA) by signing itthrough its own private key. In turn, CN is con-vinced that MN actually owns both HoA andCoA by verifying HA�s signature and its subnet pre-fix certificate chain. Therefore, MN proves to CN itsownership of both its HoA and CoA by delegatingthe job to its own HA. At the same time, MN is alsoexempted from computation-expensive signatureoperations due to the delegation. We note that thisdelegation significantly improves the performanceof our routing optimization protocol as we will seein the next section.

As a consequence of our framework, during theRO process, a signed message together with a certif-icate chain (Cert_ChainHA) is sent from HA to CNupon request from MN, which proves MN�s owner-ship of both its HoA and CoA. The Cert_ChainHA isa series of certificates with the first certificate issuedby CA and the last issued by HA�s immediate upperstream ISP. A sample home link certificate a HAmay hold can be expressed as below at theminimum.

fSLA; PHA; Valid Interval; SIGISPg

The intermediate certificates in the Cert_Chain areissued by intermediate ISPs. So it is clear that inour trust management framework, the subnet prefixof a MN is proved by the certificate chain, and theinterface identifier is proved by the HA signed mes-sage. At the CN side, certificates of 1st and 2nd lay-ers can be easily checked by caching a small set offrequently used ones. Generally, CN only needs toactually verify the signature(s) in the last one ortwo certificates at the end of the certificate chain.More over, should CN be a mobile node itself, thechecking task can be delegated to its own HA easily.

Remarks. In our framework, CA is required toissue certificates only to Tier-1 ISPs. The argumentgoes as follows: (1) Tier-1 ISPs have steady network

prefixes (i.e., TLAs) and a very small number.Therefore, they can be reasonably tracked by CA.(2) The existence of well established long term trustrelationships and extensive cooperations amongthese Tier-1 ISPs makes it easy to find mutuallyagreed CA(s) to issue the certificate of such a kind.(3) The Tier-1 ISPs cover most parts of the Internet.(4) Due to the hierarchical structure of IPv6 unicastaddress itself, address changes at lower layer aretransparent to the upper layer and thus have noimpact on the upper layers� certificates.

Considering the difficulty of the deploymentissue, the certificate verification between CN andan arbitrary 3rd layer agent may not be trivial.However, this problem can be eased by combiningthe use of our subnet prefix certificates with thosefor SEND [2]. The gradual build-up of SEND infra-structure could ease transition to HCBU. In addi-tion, HCBU may also obtain help from the AAAinfrastructure [13].

4.2. The HCBU protocol

As in both RR and CBU protocols, all the proto-col messages in HCBU are carried within IPv6‘‘Mobility Header’’. The protocol messagesexchanged among a MN, its HA and CN are shownin Fig. 6. Before a secure BU assured by CN can besent, the following three steps are followed by thethree protocol participants. In HCBU, when aMN is roaming to a foreign link, it obtains a CoAas usual and additionally, MN requests a signatureon the binding of (HoA, CoA): SIGHA0 ¼ SHA0 ðHoA;CoA; Valid IntervalÞ.

In the 1st step, MN first initializes a BindingUpdate request in Message 1, when it realizes animminent handover:

Message 1. Binding Update Request (BUReq):

fBU ;Nm;HoA;CNg.

Message 1 contains MN�s own home address, afresh random nonce, and CN�s address in additionto Binding update preparation request (BU). (Weuse CN to denote both the node and its correspond-ing IP address.) Message 1 is sent to HA throughthe pre-established secure tunnel via IPsec. CN�s ad-dress is included in the message to clearly indicatethe destination of the BU request. HA next doespre-exchanges with CN to prepare the coming bind-ing update through Message 2 and Message 3.

.

Fig. 6. The HCBU Protocol.


ARTICLE IN PRESS

Message 2. Pre-Information Exchange0 (EXCH0):

fNm;HoA;CN ; gxg.

Message 3. Pre-Information Exchange1 (EXCH1):

fNm;Nc;HoA;CN ; gx; gy ;CookieCNg;where

CookieCN ¼ prf ðKCN ;NmjNcjHoAjCN jgxjgyÞ.Message 2 passes the fresh nonce Nm, MN�s HoA,CN�s address and a DH public value gx to CN. Inreply, CN attaches its own fresh nonce NC andDH public value gy to the received Message 2 andthus forms Message 3. CN next creates a cookieCookieCN for HA using its own secret key KCN.We will discuss more on the two DH public valueslater. At this point, CN does not create a state forthe protocol. This is useful for protecting CN fromresource exhausting attack.

In the 2nd step, MN first proves to HA its own-ership of CoA. HA then proves to CN MN�s owner-ship of both its CoA and HoA. A session key is alsoestablished between HA (on behalf of MN) and CNto certify the final BU message between MN andCN during the 3rd step. The DH key exchangemethod is used. The 2nd step consists of 3 messages.

Message 4. Care-of address Registration:

fCoA;HoA; Valid Interval;CN ; SIGHA0 ;Cert ChainHA0 g

HA checks the validity of the certificate chain andverifies the signature contained in the message. Neg-ative result of either of them leads to the rejection ofthe message. Note that this checking operation as-sures the correctness of MN�s CoA. Message 4 actu-ally can be a piggy-backed part of MN�s care-ofaddress registration message. Note that when themobile node moves to a different network, and is

configured a new care-of address, the mobile nodemust first register the new care-of address with itshome agent together with other operations, beforeit can use the new care-of address [12].

Next Message 5 completes the preparation forthe Binding Update. Message 5(a) passes all therequired information for Routing optimization toCN, including the information HA obtains in Mes-sage 1, the cookie obtained in Message 3 and HA�ssignature on these information. Finally, HA�s certif-icate chain is also attached.

Message 5(a). Binding Update Request with Certi-fied (HoA, CoA):

fNm; gx;CookieCN ;HoA;CoA; Valid Interval;CN ;

SIGHA;Cert ChainHAg;

where

SIGHA ¼ SHAðHoAjCoAjValid IntervaljCN jgxy jNmjNcÞ

On arriving at CN, Message 5(a) is processed inthe following sequence: (1) Validate the cookieCookieCN; (2) Check on the authenticity of thecertificate chain Cert_ChainHA; (3) Calculate DHkey KHS, verify the signature, and importantly,check for the equality of the home link subnet prefixstrings embedded in both Cert_ChainHA and HoA.The included fresh nonce assures the freshness ofthe signature. If all the results of validation andchecking operations are positive, CN now can beconfident that both MN�s HoA and CoA are indeedcorrect. At this point, CN creates a cache for(HoA, CoA) and the Binding Update key KBU =prf(gxy, NmjNc). Now CN only needs to wait a finalmessage (Message 6) from MN to make sure MN isstill alive on its CoA. At the same time, MN obtainsthe Binding Update key KBU in Message 5(b) fromHA and therefore, could send out the final Binding


ARTICLE IN PRESS

Update message. Note that Message 5(b) is actuallysent before Message 5(a) is sent so that Message 6can be sent earlier.

Message 5(b). Binding Update Reply (BURep):

fHoA;CoA;CN ;KBUg.

Note that Message 5(b) is sent through IPsec as welland this completes the 2nd step. Upon getting KBU,MN now sends out the final message:

Message 6. Binding Update Message certified byKBU:

fHoA;CN ;CoA;MACg;where

MAC ¼ prf ðKBU ;NmjHoAjCN jCoAÞ.Upon receiving Message 6, CN easily verifies thatMN is still alive on its CoA. In case that Message6 arrives at CN before Message 5(a), CN will simplydiscard it. Considering that buffering Message 6 atCN may cause flooding attacks, we require MN toresend Message 6, if MN still receives data sent byCN from HA. Although this setting may sacrificethe performance a little bit (because of the delay be-tween Message 5(a) and the next Message 6), ithelps HCBU be highly robust against such floodingattacks. Thus, this last step completes our routingoptimization protocol.

Note that KBU is the shared secret key to certifythe binding update between MN and CN and there-fore, KBU proves MN�s ownership of HoA. By mak-ing use of KBU, the subsequent Binding Updatesbetween MN and CN can be much more efficientas shown below:

Binding Update Message certified by KBU:

fHoA;CoA; SIGHA0 ;N 0m;CN ;Cert ChainHA0 ;MACg;

where

MAC ¼ prf ðKBU ;N 0mjHoAjCN jCoAÞ.

Upon receiving this binding update message, CNfirst checks the integrity of the attached MAC,and thus verifies the message is indeed sent byMN. Next, CN checks HA 0�s certificate and verifiesSIGHA0 . If both verifications succeed, CN now as-sures that MN is indeed alive in the CoA as claimedin the previous messages. Further, both MN andCN update KBU ¼ prf ðKBU ;N 0

mÞ in order to preventreplay attack by resending the same message. Notethat only one message is needed in this case toaccomplish routing optimization between MN and

CN. The HCBU protocol treats this scenario as aspecial case of the above general protocol.

4.3. Analysis of the HCBU protocol

The HCBU protocol achieves high securitystrength by adopting certificate-based strongauthentication approach, and keeps low computa-tion costs by relying on the underlying trust man-agement framework. The communication efficiencyof HCBU protocol is achieved by integrating thetechnique introduced in the EBU protocol [33].

4.3.1. Security analysis

In Message 1, BUReq is sent from MN to its HAthrough the pre-established secure tunnel via IPsec;hence, only a legal mobile node belonging to thatparticular home link can initialize this message.The following messages exchanged between HAand CN provide strong one-way authentication toCN on MN�s ownership of its HoA and CoA,because the signature on subnet prefix and the cer-tificate chain of HA are used. The design techniqueof these messages is basically adapted from well-known JFKr protocol [1]. In Message 2 and Mes-sage 3, by pre-computing and reusing the DH publicvalue gx and gy, neither HA nor CN commits muchprocessing resources, except for the fresh nonce andcookie generating. This prevents DoS attack againstboth HA and CN.

After receiving Message 5(a), CN checks on theequality of the home link subnet prefix containedin both certificate chain and HoA. The checking iscritical to detect man-in-the-middle attack. The sig-nature in the message serves for three purposes:First, it certifies that the DH value gx was originatedby MN�s home agent HA on behalf of MN. Second,it testifies that HoA is under HA�s (or equivalentlythe home link�s) jurisdiction and is a legitimatehome address for its mobile node MN, whichauthenticates MN�s HoA to CN. Third, becauseMN�s HA signs on the binding of (MN, HoA,CoA), implying that HA has already verified theauthenticity and valid interval of MN�s CoA, CNis therefore exempted from the computation-expen-sive checking operations on the correctness of MN�sCoA. Hence, by verifying HA�s signature SIGHA,CN now assures the authenticity of both MN�sHoA and CoA. Finally, CN assures MN�s livenesson its CoA by getting Message 6.

Since a successful completion of the protocolallows CN to authenticate MN�s HoA as well as


ARTICLE IN PRESS

allows the two nodes to set up a secret session keyfor certifying the Binding Updates, the protocol pre-vents any spoofed BU message attack. In addition,by introducing our trust management framework,our protocol assures MN�s CoA to CN. Lackingof assurance on MN�s CoA results in attacks onall the other protocols based on Routing Return-ability technique, because a malicious node can lieon its CoA while uses its authenticated HoA. As dis-cussed in the RR protocol, an attacker only needs toeavesdrop the exchanged messages, and easilymounts attacks by convincing CN to accept spoofedBUs. In the CBU protocol, CN never assures MN�sliveness on its claimed CoA; a malicious node canclaim any CoA arbitrarily in the BU Message, andthere�s no requirement of the ability to present itselfon the route between CN and this claimed CoA. Inour protocol, CN assures the authenticity of bothMN�s HoA and CoA by obtaining the signed mes-sage from MN�s HA, and MN�s liveness by gettingthe binding update from MN certified by a freshshared secret key. Therefore, such malicious nodeattack is not valid in HCBU.

Another point needs to be addressed is theauthentication of HA�s certificate chain at CN�sside. In MIPv6, CN can be any node ranging froma powerful web server, a regular static node to amuch weaker mobile node. When CN is a web ser-ver, it is easy for CN to cache the 1st layer and2nd layer certificates; hence there should be noproblem for CN to authenticate HA�s certificate. IfCN is a regular static node, CN can cache a smallset of frequently used upper level certificates, andseek help from its own home link whenever needed.In case that CN is a mobile node itself, CN can del-egate the certificate authentication job to its ownhome agent. In that case, the authentication mes-sages will be exchanged between the two HAs, andthen the results are tunnelled to the respectivemobile node. The potential inter-domain authenti-cation problem as discussed in Section 4.1 can beeased with the help of SEND certificates and theAAA infrastructure [2,13].

4.3.2. Computation and communication efficiency

analysis

Computation Efficiency Analysis: HCBU tries tominimize the number of computation-expensiveoperations, and especially, MN is exempted fromsuch operations by design. In Message 2 and Mes-sage 3, by introducing Forward Secrecy Interval

technique, the DH public value gx and gy can be

reused in different protocol runs by HA and CN,respectively. The freshness of the established DHkey is guaranteed by the two fresh nonces Nm andNC. The detailed discussion on this issue can befound in [1]. By doing so, two goals are achieved:First, the computation burdens on both sides aresignificantly reduced. Both gx and gy only need tobe refreshed periodically. To achieve the same goal,HA and CN in the CBU protocol must compute afresh DH public value in every protocol run, respec-tively. Note that Binding Update in MIPv6 happensextensively. Therefore, it is critical to reduce thecomputation burden on both HA and CN sides.

Hence, in HCBU the computation-extensiveoperations of each protocol participant are as fol-lows: (1) MN: none; (2) HA: one signature verifica-tion, one certificate verification, one signatureoperation, one DH value generation operation perForward Secrecy Interval and one DH key calcula-tion operation; (3) CN: one certificate verification,one signature verification, one DH value generationoperation per Forward Secrecy Interval and one keycalculation operation. Note that in CAM-DH [5],MN is required to do: one DH value generationoperation and one DH key calculation operationin addition to one signature operation, while atCN side, the computation costs are mostly as sameas that in HCBU: only one DH value generationoperation per Forward Secrecy Interval is requiredadditionally.

HA�s computation costs are further significantlyreduced as HCBU does not require HA�s participa-tion when CN is known to MN as we discussed inSection 4.2. The computation costs at CN side canbe further reduced, if CN delegates its verificationtask to its own home link when CN itself is a mobilenode.

Communication Efficiency Analysis: In HCBU, tocomplete the whole routing optimization operation,MN is required to send 3 messages, HA is requiredto send 3 messages and CN sends only one message.In total, 7 messages are needed for the three protocolparticipants. Also note that Message 4 is actuallycombined with the care-of address registration mes-sage and thus is not an additionally generated mes-sage. Moreover, if MN has multiple concurrentsessions ongoing with different or the same CN(s),the proposed HCBU could be more economical. Inthis scenario, MN sends only one Message 1 toHA with a list of CN addresses, instead of a separatemessage for each CN and each session. Note that thesame suppressing technique can be applied to

Fig. 7. Hierarchy MIPv6 architecture.


ARTICLE IN PRESS

Message 4 and 5(b). This further improves commu-nication efficiency of the proposed HCBU protocol.

The protocol latency is significantly reduced byexecuting the 1st step (Messages 1–3) right beforean imminent handover. If handovers cannot beanticipated, the mobile node may periodicallyrepeat the 1st step, so that they can always be pre-pared for an unexpected handover. By executingthe 1st step before the handover, HA and CN arethus able to compute KBU beforehand, which fur-ther saves processing time. Hence, right after thehandover happened, MN registers its CoA to HAand proves its ownership of CoA at the same timeby sending Message 4 along with the registrationmessage. And HA is quickly able to send outMessages 5 with KBU already in hand. Therefore,the protocol latency is fairly low by pre-sendingmessages before the handover and controlling thenumber of computation-expensive operations afterthe handover. Vogt et al. [33] claims that this tech-nique would reduce the protocol latency to halfand even more as compared to the RR protocol.Note that lower latency and higher efficiency maybe critical for a mobile node to successfully finishthe protocol in the error-prone wireless communica-tion environment.

4.4. Support for hierarchical MIPv6

In the protocol of Hierarchical Mobile IPv6(HMIPv6) [30], the concept of Mobility AnchorPoint (MAP) is introduced. MAP is a router locatedin a domain visited by the mobile nodes. MAP pro-vides the localized mobility management for the vis-iting mobile nodes. Every mobile node bundles threeaddresses: Home Address (HoA), Regional Care-ofAddress (RCoA), and On-Link Care-of Address(LCoA). RCoA is an address on the MAP subnet,and obtained by the mobile node (MN) from thevisited domain. LCoA is configured on a MN�sinterface based on the prefix advertised by itsdefault router. In fact, it is a care-of address in nor-mal MIPv6. Fig. 7 shows the architecture ofHMIPv6. Note that the hierarchy in HMIPv6 canbe arbitrarily deep.

In HMIPv6, when CN sends packets to MN�sRCoA, MAP intercepts the packets and forwardsthe packets to MN�s LCoA. However, as the BUmessage from MN to MAP is not authenticatedwhen MN changes its Access Router (AR), attack-ers can easily launch attacks, which redirect the traf-fic from MAP to fake destinations chosen by the

attackers. An earlier solution appeared in [24] isbased on the extension of the CBU protocol, how-ever it suffers from many security flaws.

In this subsection, we propose our new approachto protect the BU message from MN to MAP.When MN roams in the MAP domain, as soon asMN attaches to another AR and gets a new LCoA,MN will send a BU message to MAP

BU ¼ fT ; LCoA;MAP ;HoA;RCoA; SIGMN ;CertMN ;

Cert ChainHAg;

where

SIGMN ¼ SMN ðT jLCoAjMAP jHoAjRCoAÞ;and

CertMN ¼ fHoA;PMN ;Valid Iinterval;MAP list;SIGHAg.

SMN and PMN denote the private and public keypair of MN. In order to support localized micro-mobility management feature in HMIPv6, a specialpublic key certificate of MN, issued by its HA, is de-signed as above. Here, SIGHA is HA�s signature on atime stamp T, MN�s HoA, PMN, MAP_list andValid_Interval. The time stamp is enclosed to pre-vent replay attack. Once the MN enters a foreignlink which supports HMIPv6, it can then requestits HA to issue such a certificate for him, which isused only for proving the correctness of the bindingof MN and its HoA to a small set of MAPs. TheMAP addresses are included in the certificate asMAP_list to confine the applicable range of the cer-tificate. The Valid_Interval is set appropriatelyaccording to MN�s alive time on the foreign link.Generally, the certificate should expire quickly.Therefore, every time when MN enters a new for-eign link out side the certified MAP domains, it


ARTICLE IN PRESS

must first get such a certificate for subsequent BUs.Then MN will send the signed BU message usingthe public key PMN provided by the certificate,whenever it attaches to another AR and gets a newLCoA. The certificate chain of HA is attached inthe BU messages to facilitate the authentication pro-cess by MAP. Note that through this design, all theBU related traffic is the local traffic (i.e., within theMAP domain), except for occasionally one commu-nication round between MN and its HA, which is re-lated to the certificate request and issuing.

By double-checking the equality of home link�ssubnet prefix string embedded in both Cert_Ch-ainHA and HoA, MAP can finally trust MN�s newBU message. Still the authentication itself cannotcompletely prevent the malicious node from lyingon its LCoA in the BU message and thus mountingan attack. In our design, two countermeasures areused to frustrate the attack: (1) Different MAPdomain outside the certified ones requires differentcertificate so that the attacker could not arbitrarilychoose the target link before getting the accordingcertificate. In [24], the certificate is held by MN allthe time and is applicable at every link, while inour approach such certificate is issued dynamicallyupon request from MN to the specified MAPdomain. Obviously, under their approach a mali-cious MN can always mount the attack at any linkonce with a certificate in hand. (2) In our approach,MN�s certificate is deliberately designed to expirequickly. Any malicious node that is detected tomount attacks will be forbidden to renew its certif-icate. This reduces the attack damage caused by aMN to the minimum. The techniques and solutionsof intrusion detection in wireless LANs can befound in [38,39] and are out of the scope of thispaper. Also note that the protocol in [24] suffersfrom replay attack, because the old BU messagescan be replayed by the attackers at any time. There-fore, The attacker can successfully redirect the traf-fic destined to MN�s current LCoA to its old LCoA.In our protocol, the time stamp T is included bothin the first BU message and the signature and there-fore frustrate the replay attack. Note that this timestamp is only of local significance, that is, it is validonly within the MAP subnet.

5. Concluding remarks

The fast Internet evolution together with theenormous growth in the number of users of wirelesstechnologies has resulted in a strong convergence

trend towards the usage of IP as the common net-work protocol for both fixed and mobile networks.Future All-IP networks will allow users to maintainservice continuity while moving through differentwireless systems. However, introduction of mobilityinto IP also brought with it new security issues andattacks, among them attacks against Routing Opti-mization in MIPv6 are the ones need the most seri-ous attention.

In this paper, we first discussed the backgroundsin MIPv6 security design. The assumptions andstarting point of the security designs in MIPv6 arefirst elaborated in detail. Next we analyzed the secu-rity threats in MIPv6, and classified the attacksagainst Routing Optimization into two kinds.Attacks of the first kind try to exploit the spoofedBinding Update messages to achieve attackers� pur-pose (e.g., redirecting the traffic). The second kindof attacks tries to attack the Binding Update proto-col itself, and prevent the protocol participants fromcorrectly completing the protocol (e.g., Resource

Exhausting). We then reviewed three existing proto-cols, including the ones in current Internet draft anda certificate-based approach. The pros and cons ofthese protocols were discussed in detail, as well asthe underlying design rationale, in order to give anin-depth understanding.

We then proposed our Hierarchical Certificate-based Binding Update protocol (HCBU). A flexibleand scalable 3-layer trust management framework isfirst introduced in order to solve the difficult certif-icate issuing and management problem presented inthe previous certificate-based solutions, which is adivide-and-conquer approach in consideration ofthe underlying IPv6 address assigning mechanismand home link�s jurisdiction over the addresses itassigns. In our framework, CA is required to issuecertificate to only Tier-1 ISPs, which minimizes thenumber of required certificates managed by CA(s).Also this layered-out structure hides the changesand complexities of the lower layer from the upperlayer, fully conforms to the hierarchical structureof IPv6 address format, and therefore, is relativelysimple and efficient in implementation, requiringminimum additional efforts in deployment. Basedon the trust management framework establishedabove, we came up with our binding update proto-col in which both a mobile node�s home address andcare-of-address can be easily authenticated to CNvia MN�s HA and thus a much stronger securitystrength is achieved. The proposed protocol is effi-cient and light-weight in the following sense: (1)


ARTICLE IN PRESS

Certificate management in our protocol is relativelysimple and efficient. (2) Computation costs on theprotocol participants are significantly reduced, com-pared to the previous certificate-based protocols; (3)The latency of our HCBU protocol is fairly low,which ensures fast handovers. The communicationefficiency is achieved in our protocol by takingadvantage of early binding update technique [33].Finally, an extended protocol was also proposedto give explicit support to HMIPv6.

Acknowledgements

The authors would like to thank anonymous ref-erees for their constructive comments on the draft,which helped improve the quality of this papersubstantially.

References

[1] W. Aiello et al., Efficient, DoS-resistant, secure key exchangefor Internet protocols, in: Proceedings of the ACM Com-puter and Communications Security (CCS) Conference,Washington, 2002, pp. 48–58.

[2] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill, P. Nikander,SEcure Neighbor Discovery (SEND), IETF RFC 3971,2005.

[3] J. Arkko, Using IPsec to Protect Mobile IPv6 Signalingbetween Mobile Nodes and Home Agents, IETF RFC 3776,2004.

[4] T. Aura, <http://research.microsoft.com/users/tuomaura/Publications/aura-roe-arkko-acsac02-slides.ppt>.

[5] T. Aura, Cryptographically Generated Address (CGA),IETF RFC 3972, 2005.

[6] T. Aura, Cryptographically generated addresses (CGA), in:Proceedings of the 6th Information Security Conference(ISC�03), Bristol, UK, LNCS, vol. 2851, 2003.

[7] T. Aura, Mobile IPv6 security, in: Proceedings of theSecurity Protocols, 10th International Workshop, Cam-bridge, UK, April, LNCS, vol. 2467, 2002.

[8] T. Aura, M. Roe, J. Arkko, Security of Internet locationmanagement, in: Proceedings of the 18th Annual ComputerSecurity Applications Conference, Las Vegas, 2002, pp. 78–87.

[9] J. Bound et al., Dynamic Host Configuration Protocol forIPv6 (DHCPv6), IETF draft-ietf-dhc-dhcpv6-23.txt, 2002.

[10] R. Deng, J. Zhou, F. Bao, Defending against redirect attacksin mobile IP, in: Proceedings of the of 9th ACM Conferenceon Computer and Communications Security (CCS), Wash-ington, 2002, pp. 59–67.

[11] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)Specifications, IETF RFC 2460, December 1998.

[12] D. Johson, C. Perkins, Mobility Support in IPv6, RFC 3775,2004.

[13] F. Dupont, J. Bournelle, AAA for Mobile IPv6, draft-dupont-mipv6-aaa-01.txt, Expired IETF Internet Draft,November 2001.

[14] W. Haddad, L. Madour, J. Arkko, F. Dupont, Apply-ing Cryptographically Generated Addresses to OptimizeMIPv6 (CGA-OMIPv6), draft-haddad-mip6-cga-omipv6-03.txt, Expired IETF Internet draft, 2004.

[15] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing for Messaging Authentication, IETF RFC 2104,1997.

[16] A. Mankin et al., Threat Models Introduced by Mobile IPv6and Requirements for Security in Mobile IPv6, IETF draft-ietf-mipv6-scrty-reqts-02.txt, Work in progress, 2002.

[17] MOREnet. Available from: <http://www.more.net/techni-cal/research/ipv6>.

[18] T. Narten, E. Nordmark, W. Simpson, Neighbor Discoveryfor IP Version 6 (IPv6), IETF RFC 2461, December 1998.

[19] P. Nikander, T. Aura, J. Arkko, G. Montenegro, Mobile IPversion 6 Route Optimization Security Design Background,Expired IETF Internet Draft, 2003.

[20] P. Nikander, T. Aura, J. Arkko, G. Montenegro, Mobile IPversion 6 (MIPv6) Route optimization security design, in:Proceedings of the IEEE Vehicular Technology ConferenceFall 2003, Orlando, 2003.

[21] NIST, Digital Signature Standard, NIST FIPS PUB 186,1994.

[22] NIST, Secure Hash Standard, NIST FIPS PUB 180, 1993.[23] C. Perkins, IP Mobility Support, IETF RFC 2002, October

1996.[24] Y. Qiu, J. Zhou, F. Bao, Protecting All Traffic Channels in

Mobile IPv6 Network, IEEE Wireless Communications andNetworking Conference 2004 (WCNC 2004), Atlanta, 2004.

[25] E. Rescorla, SSL and TLS: Designing and Building SecureSystems, Addison-Wesley, 2001.

[26] R. Rivest, The MD5Message Digest Algorithms, IETF RFC1321, 1992.

[27] R. Rivest, A. Shamir, L. Adleman, A Method for ObtainingDigital Signatures and Public-Key Cryptosystems, Commun.ACM 21 (1978) 120–126.

[28] M. Roe, T. Aura, G. O�Shea, J. Arkko, Authentication ofMobile IPv6 Binding Updates and Acknowledgments, draft-roe-mobileip-updateauth-02.txt, Expired IETF Intenet draft,2002.

[29] G. Shea, M. Roe, Child-Proof Authentication for MIPv6(CAM), Computer Communications Review, April 2001.

[30] H. Soliman, K. El-Malki, Hierarchical MIPv6 MobilityManagement (HMIPv6), Internet Draft, draft-ietf-mipshop-hmipv6-04.txt, Work in progress, 2004.

[31] S. Sudanthi, Mobile Ipv6. Available from: <http://www.gia-c.org/practical/GSEC/Sudha_Sudanthi_GSEC.pdf>, 2003.

[32] S. Thomas, T. Narten, IPv6 Stateless Address Autoconfig-uration, IETF RFC 2462, 1998.

[33] C. Vogt, R. Bless, M. Doll, T. Kfner, Early Binding Updatesfor Mobile IPv6, Expired IETF Internet-Draft, draft-vogt-mip6-early-binging-updates, August 2004.

[34] K. Seo, C. Lynn, S. Kent, Public-Key Infrastructure for theSecure Border Gateway Protocol (S-BGP), DARPA Infor-mation Survivability Conference and Exposition paper,2001. Available from: <http://www.net-tech.bbn.com/sbgp/sbgp-index.html>.

[35] S. Kent, C. Lynn, K. Seo, Secure border gateway protocol(Secure-BGP), IEEE J. Select. Areas Commun. (JSAC) 18(4) (2000) 582–592.

[36] <http://www.lancs.ac.uk/postgrad/pissias/netsec/ddos/>.

http://research.microsoft.com/users/tuomaura/Publications/aura-roe-arkko-acsac02-slides.ppt

http://research.microsoft.com/users/tuomaura/Publications/aura-roe-arkko-acsac02-slides.ppt

http://www.more.net/technical/research/ipv6

http://www.more.net/technical/research/ipv6

http://www.giac.org/practical/GSEC/Sudha_Sudanthi_GSEC.pdf

http://www.giac.org/practical/GSEC/Sudha_Sudanthi_GSEC.pdf

http://www.net-tech.bbn.com/sbgp/sbgp-index.html

http://www.net-tech.bbn.com/sbgp/sbgp-index.html

http://www.lancs.ac.uk/postgrad/pissias/netsec/ddos/


ARTICLE IN PRESS

[37] P. Nesser, II, A. Bergstrom (Ed.), Survey of IPv4 Addressesin Currently Deployed IETF Security Area Standards Trackand Experimental Documents, IETF RFC 3792, 2004.

[38] <http://www.airdefense.net/>.[39] J. Wright, Layer 2 Analysis of WLAN Discovery Applica-

tions for Intrusion Detection. Available from: <http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf>.

Kui Ren received his B.Eng and M.Engboth from Zhejiang University, China, in1998 and 2001, respectively. He workedas a research assistant at ShanghaiInstitute of Microsystem and Informa-tion Technology, Chinese Academy ofSciences from March 2001 to January2003, then in Institute for InfocommResearch, Singapore from January 2003to August 2003, and in Information andCommunications University, South

Korea from September 2003 to June 2004. Currently he is a Ph.D.student at ECE department of Worcester Polytechnic Institute.
His research interests include ad hoc/sensor network security,wireless mesh network security, Internet security, and securityand privacy in ubiquitous computing environments.
Wenjing Lou is an assistant professor inthe Electrical and Computer Engineeringdepartment at Worcester PolytechnicInstitute. She obtained her Ph.D. degreein Electrical and Computer Engineeringfrom University of Florida in 2003. Shereceived the M.A.Sc degree from Nany-ang Technological University, Singa-pore, in 1998, theM.E degree and the B.Edegree in Computer Science and Engi-neering from Xi�an Jiaotong University,

China, in 1996 and 1993 respectively. From December 1997 toJuly 1999, she worked as a Research Engineer in Network Tech-
nology Research Center, Nanyang Technological University. Hercurrent research interests are in the areas of ad hoc and sensornetworks, with emphases on network security and routing issues.
Kai Zeng received his BS degree inCommunication Engineering and MSdegree in Communication and Informa-tion System from Huazhong Universityof Science and Technology, China,respectively in June, 2001 and June,2004. He is currently a Ph.D. studentmajored in Electrical and ComputerEngineering department at WorcesterPolytechnic Institute. His researchinterests are in wireless networking,

especially on mobile wireless ad hoc networks and sensor net-works with an emphasis on routing and network security.

Jianying Zhou is a lead scientist atInstitute for Infocomm Research (I2R),and heads the Internet Security Lab. Heis also an adjunct senior scientist inUniversity of Malaga, adjunct associateprofessor in Singapore ManagementUniversity and adjunct professor inUniversity of Science and Technology ofChina. He obtained Ph.D. degree inInformation Security from University ofLondon (sponsored by UK government

and K.C. Wong Education Foundation), MSc degree in Com-puter Science from Chinese Academy of Sciences, and BSc degree
in Computer Science from University of Science and Technologyof China. His research interests are in computer and networksecurity, cryptographic protocol, digital signature and non-repudiation, mobile communications security, public-key infra-structure, secure electronic commerce, and virtual private net-work. He is actively involved in the academic community, servingon international conference committees and publishing papers atprestigious technical conferences and journals. He is a world-leading researcher on non-repudiation, and authored the bookNon-repudiation in Electronic Commerce which was publishedby Artech House in 2001. He is a co-founder and steering com-mittee member of International Conference on Applied Cryp-tography and Network Security, and served as program chair ofACNS 2003 and general chair of ACNS 2004. He receivedNational Science and Technology Progress Award from StateCommission of Science and Technology in 1995 in recognition ofhis achievement in the research and development of informationsecurity in China.
Feng Bao received his BS in mathemat-ics, MS in computer science from PekingUniversity and his Ph.D. in computerscience from Gunma University in 1984,1986 and 1996 respectively. He was anassistant/associate professor of theInstitute of Software, Chinese Academyof Sciences 1987–1993 and a visitingscholar of Hamberg University, Ger-many 1990–1991. Since 1996 he has beenwith Institute of System Science, Kent

Ridge Digital Labs, Labs for Infocomm Technology and Institutefor Infocomm Research, Singapore. Currently he is a Principal
Scientist and the Head of the Cryptography Lab of the Institutefor Infocomm Research. His research areas include algorithm,authomata theory, complexity, cryptography, distributed com-puting, fault tolerance and information security. He has pub-lished more than 130 international journal/conference papers andowned 18 patents.
http://www.airdefense.net/

http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf

http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf


ARTICLE IN PRESS

Robert Deng received his B.Eng fromNational University of Defense Tech-nology, China, his M.Sc and Ph.D. fromIllinois Institute of Technology, Chicago.He is currently Professor and Director ofSIS Research Center, School of Infor-mation Systems, Singapore ManagementUniversity. Prior to this, he was PrincipalScientist and Manager of InfocommSecurity Department, Institute for Info-comm Research. He has more than 20

patents and more than 140 technical publications in internationalconferences and journals in the areas of digital communications,

network and distributed system security and information security.He has served as general chair, program chair, and programcommittee member of numerous international conferences. Hereceived the University Outstanding Researcher Award from theNational University of Singapore in 1999.