Secure and Efficient Multi-Hop Mobile IP Registration ... - IEEE Xplore

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the WCNC 2010 proceedings.

Secure and Efficient Multi-hop Mobile IP Registration Scheme for MANET-Internet Integrated Architecture Ali Al Shidhani and Victor C. M. Leung Department of Electrical and Computer Engineering The University of British Columbia Vancouver, BC, Canada V6T 1Z4 (alia, vleung)@ece.ubc.ca Abstract −Mobile Nodes (MNs) in the Mobile Ad hoc Network (MANET) employ multi-hop relaying techniques to exchange messages. These MNs are not globally reachable by nodes in the Internet. Adding Mobile IP protocol capabilities to MANETs grants the MNs the required Internet reachability. Several security and performance issues are introduced as a result of incorporating MANETs with Mobile IP. In this paper, we propose a secure and efficient multi-hop Mobile IP registration scheme for the MANET-Internet integrated architecture. Our proposed scheme is designed to defend against common security attacks affecting the integrated architecture. Additionally, the scheme outperforms closely competitive schemes reported in the literature in terms of registration delay.

I. INTRODUCTION A Mobile Ad Hoc Network (MANET) consists of a collection of wirelessly interconnected Mobile Nodes (MNs) capable of intercommunicating in an ad hoc fashion. One of the limitations of MANETs is the lack of Internet connectivity. Wireless access networks like IEEE 802.11 and IEEE 802.16 offer roaming MNs continues and cost effective high speed Internet accessibility. The Base Station (BS) in the wireless access network have a fixed coverage area and could be congested when serving large number of MNs. Integrating MANET with a wireless access network permits extensions to the BS’s coverage area and could aid in load balancing the traffic [1]. Since the MNs in the MANET could obtain Internet connectivity through the wireless access network, this integrated architecture is hereafter referred to as MANETInternet Integrated (MII) architecture. Figure 1 depicts the MII architecture; MN3 belongs to the MANET but resides outside the coverage area of the BS. MN3 reaches the BS by multihop communication with the help of intermediate nodes in the MANET like MN1, MN2, MN4 and MN5. Two gateways exist in the MII architecture, an Authentication Gateway (AG) and an Internet Gateway (IG). A new MN visiting a foreign network must be initially authenticated before access to the network and the Internet can be granted. Typically, due to the absence of MN’s credentials in the visited network, the new MN is authenticated by its Home Authentication Authorization and Accounting server (HAAA) located in its home network. A long term security association exists between the HAAA and the AG. During

MN authentication, the AG relays authentication related information between the MN and the HAAA.

Figure 1. MANET-Internet Integrated (MII) architecture.

Mobile IPv4 (MIPv4) [2] protocol is widely used in providing Internet connectivity to nodes roaming in foreign IP networks. In MIPv4, or simply MIP, the MN maintains its Internet reachability despite the change in its physical location by registering a Care of Address (CoA) with its Home Agent (HA). This CoA is provided by the visited Foreign Agent (FA). The FA plays the role of the IG in the MII architecture. A newly joined MN residing outside the communication range of the BS performs a multi-hop secure FA discovery and a multi-hop MIP registration procedure with the help of intermediate nodes. Two challenges exist in such a procedure; firstly, securing the process of FA discovery which includes establishing a secure multi-hop route to the FA, and secondly, completing the registration with minimum latency. Several papers in the literature proposed secure single and multi-hop FA discovery and MIP registration [3, 4, 5]. The proposed schemes show adequate protection against security attacks that might affect the MII architecture. Nevertheless, they depend on public key operations, which might entail heavy processing burden on MNs and require sophisticated Digital Certificate (DC) management. These problems yields to considerable increase in the MIP registration delay. In this paper, we propose a secure and efficient multi-hop FA discovery and MIP registration scheme. Our proposed scheme is based on shared-key cryptography; therefore it is faster than the schemes proposed in [3, 4, 5]. Since authenticating a MN is a prerequisite for gaining network and Internet access, we proposed a multi-hop authentication scheme as well. Security keys derived from the multi-hop authentication are used to secure FA discovery and the MIP registration procedure. Our proposed scheme experience

978-1-4244-6398-5/10/$26.00 ©2010 IEEE


reduced MIP registration delays comparing to the schemes in [3, 4, 5] due to the absence of processing and power demanding public key operations. The remainder of this paper is organized as follows. In Section II some related work are presented. In Section III we describe our proposed scheme. Security analysis and performance evaluation of our proposed scheme are discussed in sections IV and V, respectively. Section VI presents some conclusions and future work. II. RELATED WORK Various MANET-Internet integration schemes based on MIP have been proposed in the literature [6]. These schemes are based on the assumption that MNs in the MANET fully trust each other to relay messages without alteration [3, 6]. Such an assumption might be unrealistic because of the adversarial nature of MANETs [7]. The MII architecture is subject to MIP related security problems and attacks such as fake MIP registration requests and registration message modification attacks in addition to a variety of security vulnerabilities that exist in a pure MANET architecture. Vaidya et al. [5], Xie et al. [3] and Kandikattu et al. [4] proposed secured FA discovery and MIP registration schemes based on public key cryptography to protect the MII architecture from some of these attacks. Vaidya’s scheme [5] is based on the assumption that all MNs receive a DC from a trusted Certificate Authority (CA) prior joining the MII architecture. The scheme only discusses single hop connectivity. Xie’s scheme [3] relies extensively on public key operations to secure multi-hop FA discovery and MIP registration. A newly joined MN obtains a DC from the FA following a successful MIP registration. Intermediate nodes residing on the multi-hop path between the MN and FA perform extensive public key operations on transient messages. Kandikattu’s scheme [4] utilizes minimal public key operations to achieve secure multi-hop MIP registration. Intermediate nodes perform keyed hashing operations to secure the registration. The schemes proposed in [3], [4], and [5] show adequate defense against attacks on the MII architecture. However, they encounter three practical obstacles, firstly, the need for feasible DC management system, secondly, the need for efficient key management and distribution scheme between the visiting MN and HA, and thirdly, the delay in registration caused by public key operations. Managing DCs is complex and could cause delays in the MII architecture. An authority trusted by all nodes must exist to generate DCs and to maintain a Certificate Revocation List (CRL). MNs might need to validate a chain of DCs before reaching a DC issued by a trusted CA. Additionally; they might need to consult the CRL in the CA to ensure that the received DC is not revoked. In [4] and [5], the method by which a visiting MN contacts a remote CA to validate FA’s DC is questionable since no Internet connectivity is yet established. DC management limits the flexibility and the promptness by which new MNs could join and leave different wireless access networks in the MII architecture.

All three schemes assume that the visiting MN shares a key with HA prior MIP registration. With such setup, MN and HA are likely to share a key for a long time since no rekeying mechanisms are specified. A long lifetime shared key is more susceptible to discloser attacks than a key with a short key lifetime. Finally, performing public key operations and DC validations by MNs incur additional processing delays and consume valuable power much needed by such resourceconstrained devices. This results in a substantial increase in MIP registration delay. III. PROPOSED SCHEME A secure and efficient single and multi-hop FA discovery and MIP registration scheme is proposed. The proposed scheme utilizes keys derived following a successful authentication between the visiting MN and HAAA when the MN enters a foreign wireless access network. These keys are distributed by HAAA to HA and FA. The MN and HA share a new key whenever MN visits a new foreign IP network to limit key discloser attacks. Typically, authentication messages exchanged between MN and HAAA are carried by the Extensible Authentication Protocol (EAP) [8]. EAP is an authentication protocol that runs directly over the data link layer without requiring IP. We propose modifying the traditional EAP session between MN and HAAA to include the exchange of fresh nonces. In addition, MN supplies the identity or the IP address of the HA to signal its desire to use MIP service as shown in Figure 2. As a result, HAAA computes a Top HA Key (THAK) and forwards it to both HA and FA. THAK is used by HA and FA to derive a shared secret key to protect the communications between them. By the successful completion of an EAP session, MN and HAAA shares a Master Session Key (MSK), an Extended MSK (EMSK) and a Transient EAP Key (TEK) [9]. As per the EAP key management specifications [9], TEK is used to protect the integrity and confidentiality of the exchanged EAP messages and MSK is used to protect the communications between MN and BS. We propose using EMSK to derive MIP related keys. Table 1 lists the notation used in describing our proposed scheme. Table.1 Notations used in the proposed scheme The identity of node x IDx IPx The IP address of node x MNx Æ MNy MNx sends a message to MNy (* * ) Route record Ksolx Solicitation key shared between FA and MNx KHAx A key shared between HA and MNx KFAx A key shared between FA and MNx KHA-FA A key shared between HA and FA Nx A nonce generated by node x K A keyed message authenticated code (MAC) of A calculated using the key K. t A timestamp, an estimate of the current time f Key derivation function

A. Single hop Secure FA Discovery and MIP Registration


A visiting MN entering a new foreign IP network uses EMSK to derive Top MIP Key (TMK) and FA-level MIP Key (FMK). These keys are also derived by HAAA as follows: TMK = f(EMSK, NHAAA | N1MN1 | IDHA | IDMN1 ,128) (1) (2) FMK = f(TMK, IDAG | IDMN1, 128) where NHAAA and N1MN1 are nonces generated by HAAA and MN, MN1 in Figure 2, and exchanged in the last EAP session. NHAAA and N1MN1 are encrypted during transmission with TEK. IDMN1 is an identity that uniquely identifies MN1 to HAAA and “|” denotes concatenation. After a successful authentication, HAAA forwards TMK, THAK and IDMN1 to HA and forwards FMK, THAK, IDHA and IDMN1 to AG, which relays this message to all FA’s under its jurisdiction. A lookup table is created by each FA containing two entries; the first entry includes IDMN1 and the corresponding FMK while the second entry includes IDHA and the corresponding THAK. MN1 could receive advertisements from FAs. However, the advertisements can not be trusted because they could be sent by forged FAs. Hence, MN1 launches a secure FA discovery and MIP registration procedure that proceeds as follows: 1- MN1 generates N2MN1 and derives a solicitation key (Ksol1). A FA discovery request (FA_Req) is broadcasted to all neighboring FAs. MN1 Æ FA : FA_Req = { M1, FA_Address, Ksol1 } where, M1 = { IDMN1, IPMN1, N2MN1, t }, FA_Address is the All Mobility Agents multicast group address [2], set to 224.0.0.11 and Ksol1 is derived as follows: (3) Ksol1 = f(FMK, N2MN1 | IDMN1, 128) 2- Each FA receives FA_Req message and checks the timestamp, t, and N2MN1 to ensure the freshness of the request. The FA holding the FMK corresponding to IDMN1 derives Ksol1 using (3). Subsequently, it validates Ksol1 to ensure the authenticity of MN1. Lastly, it generates N1FA and replies to the request. FA Æ MN1: FA_Rep = { M2, Ksol1 } where M2 = { M1, IDFA, List of CoA, N1FA, t } 3- MN1 selects a specific FA if multiple replies are received. It validates t and N1FA and matches M1 in FA_Rep against M1 included in FA_Req. If all validations are successful, it selects a CoA, computes N3MN1, and computes a shared key with the selected FA (KFA1) and a shared key with HA (KHA1). Finally, MN1 sends a registration request (R_Req) to FA and HA. KFA1 = f(FMK, N2MN1 | N1FA | IDFA | IDMN1, 128) (4) (5) KHA1 = f(TMK, N3MN1 | IDHA | IDMN1, 128) MN1 Æ FA: R_Req = { P1, KFA1 } where P1 = { M3, KHA1, N1FA, t } M3 = { IDMN1, IDFA, IDHA, IPMN1, CoA, N3MN1 } 4- FA checks t, validates that N1FA is similar to the one sent in FA_Rep and derives KFA1 using (4). Subsequently, it validates KFA1. If this is its first communication with HA or if the key shared between them (KHA-FA) have expired, FA extracts THAK correspondent to IDHA and derives a new KHA-FA. Finally, FA generates N2FA and relays the request to HA. (6) KHA-FA = f(THAK, N2FA | IDHA | IDFA , 128) FA Æ HA: HA-R_Req = { P2, KHA-FA }

where P2 = { M3, KHA1, N2FA, t }

Figure 2. Single hop authentication and MIP registration.

5- HA validates t and N2FA, derives KHA-FA using (6) and validates KHA-FA to ensure the authenticity of FA. Consequently, it extracts IDMN1 from M3 and looks up the corresponding TMK to derive KHA1 using (5). Then, it validates KHA1 to verify the authenticity of MN1 and registers the new CoA. Lastly, it computes N1HA and replies to the request. HA Æ FA: HA-R_Rep = { P3, KHA-FA } where P3 = { M4, KHA1, N2FA, t } M4 = { Registration Result, N1HA, M3 } 6- FA checks t, verifies that N2FA is similar to the one sent in HA-R_Req and validates KHA-FA to authenticate HA. FA also generates N3FA and relays the reply to MN1. FA Æ MN1 : R_Rep = { P4, KFA1 } where P4 = { M4, KHA1, N3FA, t } 7- MN1 checks t and the received N3MN1 and validates KFA1 and KHA1 to authenticate FA and HA. B. Multi-hop Authentication A new multi-hop authentication scheme is proposed for MNs residing outside the coverage area of the BS. Due to the lack of a direct link to the BS, we propose adopting the Protocol for carrying Authentication for Network Access (PANA) [10] to carry EAP messages between MNs and BS. PANA is designed to carry EAP messages over IP; hence it is suitable for multi-hop authentication in the MII architecture. There are four functional entities in PANA: • PANA Client (PaC): is the client requesting network access. • PANA Authentication Agent (PAA): is the node responsible for authenticating the PaC. The PAA could offload PaC authentication to a back-end AAA server. • Enforcement Point (EP): is a node that allows/blocks data traffic from clients depending on their authorization. In the MII architecture depicted in Figures 1, the role of PaC is played by MN3, role of EP is played by BS, role of PAA is played by AG and role of back-end AAA server is played by HAAA. During a PANA session, MN3 initially starts a DHCP discovery process to configure the IP address of the AG [10]. Subsequently, PANA carries EAP messages between MN3 and AG with the help of intermediate nodes like MN2 and MN1. Consequent a successful PANA session, MN3 and HAAA mutually authenticate each other and share a


new MSK, EMSK and TEK. HAAA and MN3 derive TMK and FMK from EMSK using (1) and (2) and HAAA forwards FMK to AG and FA. C. Multi-hop Secure FA Discovery and MIP Registration Since MN3 is not within a direct communication range with the BS, it broadcasts FA_Req to neighboring MNs in search for a FA. Only intermediate nodes that have completed MIP registration and share a valid Ksol and KFA with FA could participate in FA discovery. Similar assumptions apply to Xie’s and Kandikattu’s schemes. Figure 3 depicts the proposed multi-hop FA discovery and MIP registration scheme initiated by MN3. The scheme proceeds as follows: 1- MN3 generates N2MN3, derives Ksol3 and broadcasts FA_Req. Only MNs sharing a valid Ksol with FA can process and relay the request. MN3 Æ MN2: FA_Req = { M1, FA_Address, Ksol3 } where M1 = { IDMN3, IPMN3, N2MN3, t } 2- Every intermediate node receives the request and checks t and N2MN3, appends its IP address as a route record and calculates a MAC keyed with Ksol it shares with FA. Afterwards, the request is rebroadcasted. MN2 Æ MN1: RelMN2-FA_Req = { FA_Req, S1 } where S1 = { (* IPMN2 *), Ksol2 } MN1 Æ FA: RelMN1-FA_Req = { RelMN2-FA_Req, S2 } where S2 = { (* IPMN1 *), Ksol1 } 3- The FA checks t and N2MN3, and validates Ksol1, Ksol2 and Ksol3. The FA could receive a duplicate request from a different route. In such a scenario, it selects the best route to MN3 among the routes that passed the security validation. Later, it generates N1FA and replies to the request. Every intermediate node indicated in the route record (R) receives the reply, validates Ksol to confirm the integrity of the route record, stores R in its routing cache and relays the reply. FA Æ MN1: FA_Rep = { M2, Ksol3, R, Ksol2, Ksol1 } where M2 = { M1, IDFA, List of CoA, N1FA, R, t } and R is a route record, R = (* IPMN3, IPMN2, IPMN1, IPFA *) MN1 Æ MN2: RelMN1-FA_Rep = { M2, Ksol3, R, Ksol2 } MN2 Æ MN3: RelMN2-FA_Rep = { M2, Ksol3 } 4- MN3 validates t and N1FA, validates Ksol3, extracts R from M2 to update its routing table and selects a CoA. 5- To achieve FA and HA registration, MN3 sends R_Req message to FA through the intermediate nodes indicated in R. Initially, MN3 generates N3MN3 and derives both KFA3 and KHA3 using (4) and (5), respectively. MN3 Æ MN2: R_Req = { P1, KFA3 } where P1 = { M3, KHA3, N1FA } M3 = { IDMN3, IDFA, IDHA, IPMN3, CoA, N3MN3 } 6- Every intermediate node in R appends a new nonce protected by a MAC. MAC is calculated by every node using KFA that corresponds to IDFA. MN2ÆMN1:RelMN2-R_Req = {R_Req, NMN2, KFA2} MN1ÆFA:RelMN1-R_Req={RelMN2-R_Req,NMN1,KFA1} 7- The FA verifies the received N1FA, validates KFA1 and KFA2, derives KFA3 using (4) and validates

KFA3. FA generates N2FA and sends HA-R_Req to HA. FA Æ HA: HA-R_Req = { P2, KHA-FA } where P2 = { M3, KHA3, N2FA, t } 8- HA follows a procedure similar to step 5 in the single hop MIP registration and replies to the request. HA Æ FA: HA-R_Rep = { P3, KHA-FA } where P3 = { M4, KHA3, N2FA, t } M4 = { Registration Result, N1HA, M3 } 9- FA follows a procedure similar to step 6 in the single hop MIP registration. Later, it increments each nonce received from each intermediate node and protects it with a MAC. Every intermediate node validates the new nonce, the MAC covering it and relays the message to the next route noted in R. FA Æ MN1 : R_Rep = { P4, KFA3, NMN2 + 1, KFA2, NMN1 + 1, KFA1 } where P4 = { M4, KHA3, N3FA , t } MN1 Æ MN2 : RelMN1-R_Rep = { P4, KFA3, NMN2 + 1, KFA2 } MN2 Æ MN3 : RelMN2-R_Rep = { P4, KFA3 } 10- Finally, MN3 verifies both KFA3 and KHA3.

Figure 3. Multi-hop FA Discovery and MIP Registration.

IV. SECURITY ANALYSIS The proposed scheme provides two important security services, mutual authentication and secure multi-hop FA discovery and MIP registration. Mutual authentication is attained, firstly, between the visiting MN and both FA and HA, and secondly, between FA and HA. FA ensures MN’s authenticity by successfully validating Ksol received in FA_Req. A successful validation implies that the request came from a legitimate MN because Ksol can only be held by a MN that knows the correct FMK, TMK and EMSK. Likewise, MN ensures the legitimacy of FA by successfully validating Ksol received in FA_Rep. Only a legitimate FA receives FMK and IDMN from AG, and hence is capable of deriving a unique Ksol that only corresponds to MN. HA confirms the legitimacy of MN by validating KHA in R_Req. Only a legitimate MN is capable of deriving a correct KHA. Similarly, the legitimacy of HA is assured to the MN when a correct KHA is received in R_Rep. Only a legitimate HA receives TMK and IDMN from HAAA, and hence is capable of deriving a correct KHA. HA and FA mutually authenticate each other by the successful validation of KHA-FA and KHA-FA received in R_Req and R_Rep, respectively. KHAFA is only derived by a HA and a FA holding a valid THAK.


In our proposed scheme, intermediate nodes calculate a MAC keyed with Ksol and KFA to protect the integrity of transient messages, authenticate the sender, establish a secure route to the FA and engage in a secure multi-hop MIP registration. When receiving FA_Req, FA validates each MAC included in the S parameter appended by every intermediate node to ensure the authenticity and the integrity of FA_Req. In the FA_Rep message, FA includes the R parameter and Ksol for each intermediate node. Every intermediate node verifies Ksol to ensure the integrity of R. R is also included in M2 and its integrity is protected by KsolMN. If the MN correctly validates KsolMN, it believes that the received R represents the best secured route to FA. Likewise, each intermediate node includes a fresh nonce and MAC of the nonce in the R_Req message. FA verifies the authenticity and the integrity of R_Req by validating the nonces and their MACs. FA increments the nonces and protects them with a new MAC in R_Rep. Upon receiving R_Rep message, each intermediate node validates the MAC to ensure message integrity and sender authenticity. MNs in the MII architecture are subject to MIP related security problems and attacks such as, fake FA discovery requests, fake registration requests, forged FA attacks, registration message replay and modification attacks [3, 4, 5]. Fake FA discovery and fake MIP registration requests: An illicit MN might attempt to impersonate a legitimate MN and initiate fake FA_Req or R_Req to drain FA’s resources or to obtain a CoA from FA. This attempt is stopped in our scheme by the FA because the illicit MN lacks the knowledge of Ksol and KFA necessary to launch such an attack. The FA can easily determine fake FA_Req and R_Req messages by validating the correctness of the received Ksol in FA_Req and KFA in R_Req. Forged FA: A forged FA can impersonate a legitimate FA and attempt to send fake advertisements to the visiting MN, reply to MN’s request or send fake registration messages to HA. This attack is stopped in our proposed scheme due to the establishment of a mutual authentication between MN and FA on one hand, and between FA and HA on the other hand. MN can immediately identify a forged FA if Ksol received in FA_Rep is incorrect. Similarly, a forged FA is easily discovered by HA when KHA-FA received in R_Req is incorrect since only a legitimate FA can derive a correct KHAFA. Message replay and modification attacks: Nonces and timestamps are used in our scheme to prevent replay attacks. The visiting MN, intermediate nodes, FA and HA record the timestamp and nonces to help identifying message replay attempts. An illicit eavesdropper could record a message and replay it in the future to cheat the recipient. The attack can be easily detected since invalid timestamp and duplication in the nonce is found. The eavesdropper could modify the timestamp and insert a new nonce but would fail to compute a correct MAC because it does not have the correct Ksol and KFA. The recipient must discards messages with failed MAC validation. Protection of multi-hop authentication messages: EAP messages inside PANA are integrity protected by MACs

keyed with TEK. This assures the visiting MN and HAAA that messages are not altered in transient by intermediate nodes. Additionally, PANA provides its own integrity protection, replay protection, and Man-In-The-Middle attack protection mechanisms by appending a special Attribute Value Pair (AVP) named “AUTH” to PANA messages [10]. The AUTH AVP covers the entire PANA messages including the EAP message. The AUTH AVP is calculated using the PANA_AUTH_KEY derived by the PaC/MN and the PAA/AG from the newly derived MSK. V. PERFORMANCE EVALUATION A performance comparison in terms of MIP registration delay between our proposed scheme, Xie’s scheme and Kandikattu’s scheme is studied in this section. The registration delay is calculated starting from sending FA_Req and ends by receiving R_Rep. The delay between two nodes in each of the three schemes can be calculated as follows: TScheme = M wl H wl Dt ( wl ) + D pp ( wl ) + 2 D pc + (7) M wd H wd Dt ( wd ) + D pp ( wd ) + 2 D pc + TE Scheme

(

(

(

(

))

))

where Mwl and Mwd are the numbers of messages exchanged in the wireless and wired networks, respectively. Hwl and Hwd are the numbers of hops in the wireless and wired networks, respectively. Dt(wl) and Dt(wd) are the wireless and wired transmission delays, respectively. Dt(wl/wd) = S / BW(wl/wd), where S is the average messages size, set to 50 bytes and BW(wl/wd) are the wireless and wired network data rates, set to 11 Mbps and 100 Mbps, respectively. Dpp(wl) and Dpp(wd) are the wireless and wired propagation delays, set to 0.5 ms and 2 ms, respectively [11]. Dpc is the nodal processing delay, set to 1 μs. TEScheme accounts for additional delays occurring during MIP registration in each scheme. These delays are caused by cryptographic related operations like hashing and digital signature/verification. TEScheme = eScheme · h, Where h is a single row matrix defined as, h = [DS-MN, DS-S, DV-MN, DV-S, DH-MN, DH-S, DK-MN, DK-S, DC] where DS-MN/DV-MN and DS-S/DV-S are the delays incurred by digitally signing/verifying a message by a MN and a server, respectively. DH-MN and DH-S, are the delays in performing a hashing operation on a message by a MN and a server, respectively. DK-MN and DK-S, are symmetric key generation delays by MN and server, respectively. DC is the delay incurred when validating a DC. DC validation delay can reach up to tens of milliseconds depending on the CA’s location [12]. eScheme for single and multi-hop FA discovery and MIP registration for the three schemes is found as follows: e e e

Single = Xie Single Kandikattu Single Proposed

[1 , 3 , 2 , 3 , 2 , 2 , 0 , 0 , 2 ], = [1 , 3 , 2 , 3 , 5 , 4 ,1 , 3 , 4 ] , = [ 0 , 0 , 0 , 0 , 6 ,10 , 5 , 5 , 0 ]

Multi Single e Xie = e Xie + [2 x − 1,0,2 x − 1,1,0,0,0,0,2 x − 2] ,

Multi Single eKandikattu = eKandikattu + [0,0,0,0,4 x − 1,0,1,1,0],

Multi Single ePropose d = eProposed + [0 ,0 ,0, 0, 2 x,2 x,0,0,0]

(8)

(9)


where x indicates the number of intermediate nodes between MN and FA, x > 0. The speed tool in the OpenSSL toolkit [13] was used to estimate the cryptographic-related processing delays in MNs and the servers. A notebook equipped with a single 1.6 GHz Intel Pentium M processor with a 512MB of RAM was used to estimate the processing delays in MNs. A server with a single 2.83 GHz Intel Core 2 Quad processor with 3.25GB of RAM was used to estimate the processing delays in FA/HA. Xie’s scheme utilizes Elliptic Curve (EC) cryptography with discrete logarithmic techniques such as the Digital Signature Algorithm (ECDSA) to perform public key operations. No particular public key technique was specified in Kandikattu’s scheme. Thus, both ECDSA and the RivestShamir-Adleman (RSA) public key techniques are considered. Xie’s and Kandikattu’s schemes did not indicate the size of the keys used in their schemes. Since our proposed scheme uses a key size of 128-bit in various cryptographic operations, 3072-bit key in RSA and 256-bit key in ECDSA are used in the evaluation because they provide similar security strength to 128-bit key in shared key schemes [14]. A comparison of the single hop MIP registration delay between the three schemes is displayed in Figure 4. Kandikattu’s scheme experiences higher registration delay due to the delay of validating HA and FA DCs by the MN. Our proposed scheme outperforms both Xie’s and Kandikattu’s schemes. Registration Delay (ms)

100 Xie's scheme Kandikattu's scheme Proposed scheme

80 60 40 20

RSA

ECDSA

Figure 4. Single hop MIP registration delay for the three schemes.

Registration Delay (ms)

180 Xie's scheme Kandikattu's scheme Proposed scheme

140 100 60 20 1

2 3 4 Number of Hops between MN and FA

5

Figure 5. Multi-hop MIP registration delay for the three schemes.

Figure 5 shows a comparison of the registration delay experienced by the three schemes when ECDSA is adopted for multi-hop MIP registration. As the number of hops increases, Xie’s scheme underperforms Kandikattu’s scheme. This is due to the extensive digital signature/verification operations performed by intermediate nodes in Xie’s scheme that are not required by Kandikattu’s scheme. Our proposed scheme consistently outperforms both Xie’s and Kandikattu’s schemes. As the number of hops increases, the difference in registration delay between Xie’s scheme and our proposed scheme widens rapidly due to the intensive public key operations required by Xie’s scheme. On the other hand, the

difference in registration delay between Kandikattu’s scheme and our proposed scheme remains relatively constant as the number of hops increase. This is because both schemes perform comparable number of keyed hashing operations. Although our proposed scheme largely reduces multi-hop MIP registration delay, the number of shared keys generated by the nodes in our scheme is noticeably high comparing to Xie’s and Kandikattu’s schemes as shown in (8) and (9). VI. CONCLUSIONS A secure and efficient multi-hop authentication, multi-hop FA discovery and Mobile IP registration schemes for MANET-Internet integrated architectures have been proposed in this paper. The proposed scheme provides adequate protection against security problems affecting the integrated architecture such as fake Mobile IP registration attacks, forged FA attacks and attacks based on modifying Mobile IP registration messages. Performance analysis showed that the proposed scheme undergoes less Mobile IP registration delay compared to closely competitive schemes. ACKNOWLEDGMENT This work was supported in part by the Sultan Qaboos University under Contract number 1907/2005, Bell Canada and the Natural Sciences and Engineering Research Council of Canada under grant CRDPJ 328202-05. REFERENCES 1- D. Cavalcanti, D. Agrawal, C. Cordeiro, B. Xie and A. Kumar, “Issues in integrating cellular networks, WLAN, and MANET: A futuristic heterogeneous wireless network”, IEEE Wirel. Comm., vol. 12, issue 3, pp. 30 – 41, Jun. 2005 2- C. Perkins, “IP mobility support”, IETF RFC 2002, Oct. 1996 3- B. Xie, A. Kumar and D. Agrawal, “Secure interconnection protocol for integrated Internet and ad hoc networks”, Wirel. Comm. Mob. Comp., vol. 8, issue 9, pp. 1129 – 1148, Nov. 2008 4- R. Kandikattu and L. Jacob, “Secure Internet Connectivity for Dynamic Source Routing (DSR) based Mobile Ad hoc Networks”, Int. Jour. Elec., Circ. Sys., vol. 2, number 1, pp. 40 – 45, 2008 5- B. Vaidya, B-L. Cho, J. Park and S. Han, “Investigating Secure Framework for Hybrid Multipath Ad Hoc Network”, Proc. 22nd Int. Conf. Adv. Info. Net. App. – Work., (AINAW), pp. 1540 – 1545, Mar. 2008 6- S. Ding, “A survey on integrating MANETs with the Internet: Challenges and designs”, Comp. Comm., vol. 31, issue 14, pp. 3537 – 3551, Sep.2008 7- H. Yang, H. Luo, F. Ye, S. Lu and L. Zhang, “Security in Mobile Ad Hoc Networks: Challenges and Solutions”, IEEE Wirel. Comm, vol. 11, issue 1, pp. 38 – 47, Feb. 2004 8- B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, “Extensible Authentication Protocol (EAP)”, IETF RFC 3748, Jun. 2004 9- B. Aboba, D. Simon and P. Eronen, “Extensible Authentication Protocol (EAP) Key Management Framework”, IETF RFC 5247, Aug. 2008 10- D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin, “Protocol for Carrying Authentication for Network Access (PANA)”, IETF RFC 5191, May 2008 11- N. Banerjee, W. Wu, S. Das, S. Dawkins and J. Pathak, “Mobility Support in Wireless Internet”, IEEE Wirel. Comm., vol. 10, issue 5, pp. 54 – 61, Oct. 2003 12- J-P Yoo, K. Kim, H. Choo, J-I Lee and J. Song, “Secure and Scalable Mobile IP Registration Scheme using PKI”, Lect. Notes in Comp. Sci. 2668, pp. 220-229, 2003 13- The OpenSSL Project, http://www.openssl.org 14- E. Baker, W. Burr, W. Polk and M. Smid. Recommendation for Key Management. NIST special publication 800-57, revised 2006.