Secure Multipath Routing for Mobile Ad Hoc Networks - CiteSeerX

Download PDF
2 downloads 155144 Views 230KB Size Report
Comment
In the mobile ad hoc network paradigm (MANET), rout- ing is a challenging task .... of digital signatures by the intermediate nodes of each route request message ...
Secure Multipath Routing for Mobile Ad Hoc Networks Panayiotis Kotzanikolaou, Rosa Mavropodi, Christos Douligeris University of Piraeus Department of Informatics 80 Karaoli & Dimitriou, Piraeus 185 34, Greece {pkotzani,rosa,cdoulig}@unipi.gr

Abstract Multipath routing minimizes the consequences of security attacks deriving from collaborating malicious nodes in MANET, by maximizing the number of nodes that an adversary must compromise in order to take control of the communication. In this paper, we identify several attacks that render multipath routing protocols more vulnerable than it is expected, to collaborating malicious nodes. We propose a novel on-demand multipath routing protocol, the Secure Multipath Routing protocol (SecMR) and we analyze its security properties. The SecMR protocol can be easily integrated in a wide range of on-demand routing protocols, such as DSR and AODV.

1

Introduction

In the mobile ad hoc network paradigm (MANET), routing is a challenging task, not only because of the dynamic topology caused by mobility, but also because of the limitations in bandwidth, range and power. Routing protocols may generally be categorized as table driven (often called proactive) and source initiated (or on-demand). In table driven protocols (e.g. ZRP [8]), each host continuously maintains complete network routing information. Ondemand schemes (e.g. DSR [11]), invoke the routing discovery process only on demand, in a query/reply approach. According to the number of paths that are discovered from a route request, the routing protocols are divided into single path (e.g. [11, 20]) and multipath (e.g. [21, 17]). The number of the discovered paths that are actually used for sending data is another feature of the routing protocols. Some protocols use only a single path for the communication, while others distribute the data through different channels. The route discovery process in the multipath protocols may be initiated either when the active path collapses (in that case communication is performed with one of the alternative paths), or when all known paths towards the destina-

tion are broken [13]. The route discovery may stop when a sufficient number of paths are discovered or when all possible paths are detected. The protocols of the second case, are also known as complete. Multipath routing protocols can be node-disjoint [22] or link-disjoint [14] if a node (or a link) cannot participate in more than one path between two end nodes. Security is a major concern in MANET. Several security issues have been examined such as node authentication and trust establishment [26, 10], key agreement [1] and intrusion detection [25]. Of particular interest is routing security, since the lack of fixed infrastructure makes routing an obvious target for malicious nodes. Several solutions for secure routing have been proposed, such as collaborative monitoring of the routing behavior between nodes [16, 23], motivating nodes to behave well with fictitious currency [5] or participation of nodes in routing paths based on quantifiable criteria [24]. However, these solutions cannot resist Denial-of-Service (DoS) attacks of malicious nodes, since they are designed for single path routing protocols. Indeed, with single path protocols it is trivial for an adversary to launch a DoS attack, even if security measures are taken. A malicious node controlled by the adversary may participate passively in the routing path between two end nodes and may behave as a legitimate intermediate node. The malicious node can stop the communication at any time it seems most advantageous to the adversary. Although communication may be cryptographically protected, network characteristics (such as variation in traffic) or external factors may be used by the adversary in order to identify the proper time to disrupt communication. Although the end nodes may initiate a new route request after the DoS attack, the time required to establish the new path may be critical. A dedicated and skilful adversary may thus identify the most critical nodes and disable their single routing paths, by compromising a small fraction of nodes. Multipath routing protocols are resilient to DoS attacks and may protect network availability from faulty, or even worse, from malicious nodes [3]. Indeed, if there exist k

2

node-disjoint paths between two end nodes, the adversary should compromise at least k nodes - and more particularly at least one node in each path - in order to control their communication. A secure multipath routing protocol must be node-disjoint. Otherwise, a malicious node would be allowed to participate and consequently control more than one paths. Thus, a single malicious node may manipulate the routing protocol and in this way it may compromise all the available routes between two end nodes. By employing k node-disjoint routing paths between two communicating nodes, the integrity and availability of the communication is guaranteed against DoS attacks of an adversary that controls less than k malicious nodes.

Vulnerabilities of multipath routing

Several vulnerabilities or security attacks may affect the route discovery of multipath routing protocols, allowing a small set, or even a single malicious node, to control the routing paths of critical nodes. The security of multipath protocols that are subject to these vulnerabilities is thus reduced to the security of single path routing protocols.

2.1

The racing phenomenon

With several multipath routing protocols, (such as [19, 17, 14]), each intermediate node processes each route request query only the first time it receives it. Then, it drops any succeeding duplicates of a processed query, in order to minimize the signalling cost. This happens despite the fact that a succeeding instance of an already processed rout request query may have propagated through a different path. Whether such protocols discover the complete set of nodedisjoint paths, depends on the racing conditions of the route request propagation through different paths. If an intermediate node happens to receive first a route request query that prevents discovery of another routing path that belongs to the set of node-disjoint paths, then the route request will end up without discovering all existing disjoint paths. Note that a node that experiences the racing phenomenon will behave as if it was under the Rushing attack [9], even though no malicious acts take place.

The SRP [19] is a multipath routing protocol which aims at this kind of protection. SRP uses only symmetric cryptography in an end-to-end manner, to protect the integrity of the route discovery. Thus, it is very efficient and it protects from several attacks of malicious nodes. However, the route request propagation is inherently weak to the racing phenomenon, described in the following section, which may prevent the discovery of existing node-disjoint paths. Moreover, the intermediate nodes are not authenticated, making the protocol vulnerable to impersonation and sybil attacks [6], also described in the following section. Thus, a malicious node may participate with fake identities to several paths, rendering multipath routing insecure. In [4] a secure multipath routing protocol is presented, based on the Ford-Fulkerson MaxFlow algorithm. This protocol satisfies the security requirements of multipath routing. Furthermore, it satisfies completeness, i.e. it discovers all existing paths bounded with a TTL field. However, the propagation of the route request query is not efficient, in computation and space costs. During the route request propagation, each node that receives a request appends its neighborhood information along with a signature and broadcasts it along with the previously received information. This greatly increases the message size. Furthermore, the use of digital signatures by the intermediate nodes of each route request message costs both in delay and processing power.

2.2

Impersonation and lack of authentication

If a protocol requires only end-to end authentication and intermediate nodes participating in a routing path are not authenticated (as for example in [19]), then the protocol is subject to impersonation sybil attacks [6], under which a malicious node may present multiple identities. In this way a malicious node may participate in more than one, seemingly node-disjoint, routing paths, by presenting a different identity in each path. The adversary may then compromise a small fraction of nodes in selected areas of the network, in order to control the routing paths. The effects of this attack can be maximized if it is combined with the “black-hole” attack, where the attacker responds to all route requests, with fake (nonexistent) short path links. Then, the adversary may manipulate the communication, for example by dropping all the routing paths in critical time periods.

In this paper, we propose a complete on-demand multipath routing protocol, the Secure Multipath Routing (SecMR) protocol, which provides protection against DoS attacks from a bounded number of collaborating malicious nodes. In section 2, we indicate vulnerabilities of multipath protocols which make them more vulnerable than expected, to collaborating malicious nodes. In section 3 we describe the SecMR protocol in detail. Section 4 analyzes the security characteristics of our protocol and section 5 discusses the efficiency of SecMR. Section 6 concludes the paper.

2.3

Invisible node

The broadcast nature of MANET, makes multipath routing protocols subject to a special case of Man-In-the-Middle (MIM) attack [2], the invisible node attack [15]. In this situation, a malicious node does not reveal its presence in 2

We present a novel on-demand, multipath routing protocol, secure against a bounded number of colluding malicious nodes, the Secure Multipath Routing protocol (SecMR). SecMR discovers the complete set of the existing non-cyclic, node-disjoint paths between a source and a target node, for a given maximum hop distance. The first phase of the SecMR protocol, the neighborhood authentication phase, involves the asynchronous mutual authentication of neighboring nodes. The second phase of the SecMR, the route discovery and maintenance phase, involves the establishment and maintenance of active routes.

time and its unique identifier that is included in its certifit t cate, i.e.: ni ⇒(t, IDi , sigi (t, IDi ), certi ), where X ⇒m denotes that a node X broadcasts a message m at time t. Thus, each node will generate one signature and will verify one signature for each one of its neighbors. The average cost for this phase is one signature generation per node and C signature verifications per node, where C is the average network connectivity. The duration of the time period of the neighborhood authentication phase is a system parameter and depends on the volatility of the environment. According to the frequency of changes in the connectivity, the time period should be as long as possible. After the verification phase, each node ni will generate a list of its neighborhood for the current time t, denoted as Nit, where a node identifier IDj ∈ Nit, 1 ≤ j 6= i ≤ L if at time period t, the node ni received an authentication message from node nj , containing a valid signature of nj on t, IDj . For simplicity we drop the time index, unless this is required for clarification. Thus, Nit = Ni . Note that the nodes do not re-broadcast the received authentication messages. Since authentication is performed in local neighborhoods and it is not executed simultaneously from all the nodes of the network , the cost is tolerable and it does not lead to the storm problem.

3.1

3.2

the routing path. Instead, the invisible node silently repeats the communication between two-hop away nodes, which assume that they communicate directly as one-hop (direct) neighbors. In this way a node may participate in many routing paths, even if the protocol requires authentication of intermediate nodes. Indeed, a node may legitimately participate in one routing path and may also participate “invisibly” in other routing paths. Authentication cannot help, since the invisible node just relays the authenticators.

3

Description of the SecMR Protocol

Neighborhood Authentication Phase

Let ni denote a node of a MANET. We assume that each node ni possesses a pair of public-secret keys, (P Ki , SKi ) respectively, of an Elliptic Curve Cryptosystem [12]. Furthermore, the public key of each node ni is certified through a public-key certificate certi , issued by a Certifying Authority CA. The certification and revocation of the public keys is out of the scope of this paper. Several existing approaches for certificate management in MANET can be used, such as [26, 10]. The certificate certi also contains a unique identifier IDi which is assigned by the CA to each node ni . According to the size of the MANET, the node identifier may be a relatively small number, e.g. 1 or 2bytes. Keeping identifiers as small-sized as possible, helps in maintaining small-sized lists inside the request queries. lkdsgjlds

Route Discovery and Maintenance Phase

The route discovery and maintenance phase consists of three algorithms. The route request query algorithm is used to discover the node-disjoint paths between a source node S and a target node T . The route reply algorithm is used to forward the routing paths back to the source node in order to allow future communication. Finally, the route error algorithm is used when a node discovers a flowed or a broken link within a routing path, in order to update the broken path with a new one. 3.2.1 Route Request Query Algorithm When a source node S wants to communicate with a target node T , it first checks whether it already has active routes in its routing table towards T . If not, it generates a route request query QS,T as follows:

ni denote a node t ni ⇒m denotes that a node ni broadcasts a message m at time t t ni ⇒(t, IDi , sigi (t, IDi ), certi ) QS,T = [IDS , IDT , seq, hopcnt, hopmax, EP KT (KS,T ), RouteList, ExcludeList, N extHop, hashKS,T (IDS , IDT , seq, hopmax )]

QS,T = [IDS , IDT , seq, hopcnt, hopmax , EP KT (KS,T ), RouteList, ExcludeList, N extHop, hashKS,T (IDS , IDT , seq, hopmax )], where: IDS , IDT , are the identifiers of S and T respectively, seq, is a counter used by S for each new query, hopcnt, is a counter that tracks the current number of hops, hopmax , is the maximum allowed hop distance, EP KT (KS,T ), is the encryption of the key KS,T with the

In periodic time intervals, each node ni broadcasts to its one-hop neighbors a signed message including the current 3

received query and stores the hashed value to its table for a reasonable time. Before processing a received request query QS,T , the node ni hashes QS,T and checks whether the hash value belongs to its route table (i.e., whether the specific instance of a route request has been already processed) in order to drop it. Note that this does not prevent the node 0 ni from processing a different instance (thread) QS,T of the query containing the same values IDS , IDT and seq, that reaches ni through a different path. Indeed, if the thread 0 QS,T reaches ni from a different path, then the RouteList, 0 ExcludeList and N extHop lists contained in QS,T will be different from the corresponding lists contained in QS,T . 0 Thus, hash(QS,T ) 6= hash(QS,T ) and each thread of the request coming from a different path will be processed once.

public key P KT of node T , RouteList, is a dynamically generated list of the intermediate nodes participating in a path between S and T , ExcludeList, is a dynamically generated list of nodes that are excluded for a particular thread of the query, N extHop, is the list containing the nodes that are allowed to be the next hop of the particular query, and hashKS,T (IDS , IDT , seq, hopmax ), is the result of a keyed hash function with the key KS,T . Source node S The source node S executes the algorithm shown in figure 1.

1) Set: hopcnt = 0 , hopmax = MAX, RouteList = Ø, ExcludeList = Ø, NextHop = NS

1) If (hash(QS,T)  RouteTable(ni))

/* Initialize the route request query */

/* Drop duplicates of the particular request query thread */

OR ((RouteList ˆ ExcludeList z Ø) OR (RouteList ˆ NextHop z Ø) OR (ExcludeList ˆ NextHop z Ø))

2) Select random KS,T /* The secret key (security association) to be shared between S and T */

3) Compute E PK T ( K S ,T ) and hash K S ,T ( ID S , IDT , seq , hop max )

/* Drop the query if a node identifier belongs to more than one list */

OR ((IDi  NextHop) OR ( LastElement(RouteList)  Ni) /* Drop the query if the previous node is not a neighbor of ni */

4) Construct and Broadcast QS ,T [ IDS , IDT , seq, hop cnt , hop max , E PKT ( K S ,T ),

then DROP(QS,T) else { 2) add(hash(QS,T), RouteTable(ni))

RouteList , ExcludeList , NextHop , hashK S ,T ( IDS , IDT , seq, hop max )]

/* ni marks the specific route request query as processed */

3)

If (IDi = IDT) then REPLY(QS,T)

4) 5)

else { hopcnt = hopcnt + 1 If (hopcnt > hopmax)

/* If ni is the target, execute the route reply algorithm and exit */

Figure 1. Route request query algorithm on the source node

/* Drop the query if it exceeds the maximum allowed hop-distance */

The source node S sets hopcnt = 0 and selects the maximum hop number hopmax , based on the current knowledge of the network such as its connectivity, the expected node density e.t.c. Then, it initializes the RouteList and the ExcludeList as null and it sets the initial list of the allowed next hops as N extHop = NS , where NS is the most recent neighborhood of S that has been computed in the previous phase. Finally, S selects a random key KS,T , computes the encryption of this key with the public key P KT of the target node and constructs and broadcasts the route request query QS,T as described above. For integrity check, the query also contains a keyed hash-value generated with the security association KS,T , over the static fields of QS,T .

then

6)

DROP(QS,T) else { RouteList = RouteList + IDi

7)

ExcludeList = ExcludeList + (NextHop – IDi)

/*Node ni adds itself to the RouteList */ /*Node ni excludes the rest of the neighbors of the previous node, from this particular thread of the route request query */

NextHop = Ni – (Ni ˆ RouteList) – (Ni ˆ ExcludeList)

8)

/* The allowed next hops of this query thread are the neighbors of ni, unless they already belong to the route list or the exclude list */

9)

Update and Broadcast Q S ,T

[ ID S , ID T , seq , hop cnt , hop max , Enc PK T ( K S ,T ), RouteList , ExcludeLis t , NextHop , hash K S ,T ( ID S , ID T , seq , hop max )]

/* Update the query with the new values and broadcast it */

}

Each intermediate node ni An intermediate node ni receiving a thread of the request query QS,T executes the algorithm shown in figure 2. Each node ni maintains a route table containing the current active routes towards other nodes. Furthermore, it maintains in the route table an index of the recently processed (and still not replied) queries, in order to avoid re-processing the same queries. To avoid maintenance of long route queries into the route table, each node that processes a query, it hashes the

} }

Figure 2. Route request query algorithm on intermediate nodes The algorithm prevents participation of a node identifier to more than one of the lists of a route request query. How4

ever, since this could happen due to faults or malicious acts, each node ni checks whether the lists of the received query have any common values, in order to drop such a query. At this point, the node ni checks whether it is identified in the received N extHop list of the request query, and also whether the sender of the request query, i.e. the last node identified in the received RouteList, belongs to its authenticated neighborhood Ni . If either of these checks fail, the request is dropped. This step provides dual authentication between any pair of intermediate nodes, as it is explained in the following section, which is critical for the protection against multiple identity attacks. After these checks, node ni is assured about the validity of the received request and is ready to process it. Node ni adds the specific thread of the query to its routing table, so as not to process it again. In case it is the target node, then the route request algorithm ends and the target node uses the route reply algorithm to reply to the request. Otherwise, node ni increases the hop counter hopcnt by one and checks the new value with the maximum allowed hop distance hopmax , in order to stop processing of long queries. This prevents the query from propagating in long distance areas of the MANET. Of course, this limitation will also prevent the discovery of any existing node-disjoint path that is more distant than hopmax hops. Thus, this parameter should be selected with care, taking under consideration the current knowledge of the network characteristics, the acceptable signaling delay e.t.c. The node ni processes the request query. The updated RouteList, is constructed by appending its identifier IDi to the received RouteList. The updated ExcludeList is generated by appending the rest of the nodes included in the received N extHop list, into the received ExcludeList (duplicates are removed). Finally, the updated N extHop list is generated as the list of identifiers included in its own neighborhood Ni (again, node identifiers already participating in another list are removed). Now, the node ni updates the query thread with the new values and broadcasts it. The use of the ExcludeList is a key element for the efficient propagation of a route request query. By dynamically generating threads of a request, the algorithm eventually discovers all the existing node-disjoint paths of at most hopmax distance. To clarify the threading of a request query, consider the following scenario. Let ni be the node that broadcasts the request QS,T to its neighbors nj , nk (figure 3). In order to distinguish the various threads of the request query, we denote as QS,T /x the thread that is processed by node nx . Thus, the thread QS,T /i broadcasted by node ni will contain the lists: RouteList = {X, IDi }, ExcludeList = {Y } and N extHop = {IDj , IDk }, where X and Y denote sequences of node identifiers. Both nodes nj and nk will process the request (supposing that IDj , IDk ∈ / X, Y ). Node nj will add its iden-

Q S ,T

/i

RouteList = {X, IDi} ExcludeList = {Y } NextHop = { ID j , ID k } Q S ,T

nj Q S ,T /

/ j

RouteList = {X, IDi, IDj } ExcludeList = {Y, IDk } NextHop = Nj

j

ni Q S ,T / i Q S ,T

/k

nk Q S ,T

/k

RouteList = {X, IDi, IDk } ExcludeList = { Y, IDj } NextHop = Nk

Figure 3. Threading of a route request query

tifier to the RouteList, add the identifier of nk to the ExcludeList and update the N extHop list with its own neighborhood. Thus, the updated threads of the request query will become QS,T /j , QS,T /k , containing the updated lists shown in figure 3. Each of these threads will propagate towards T , with the limitation that the thread QS,T /j is not allowed to pass from the node nk and vice versa. This forces the query to move only to more distant nodes of S towards T . The threads that return backwards tend to decline in a short time, when they reach a node closer to S that has been previously excluded. 3.2.2 Route Reply Algorithm When the target node T receives a thread of a route request query QS,T /i, it decrypts EP KT (KS,T ), obtains the key KS,T and checks the validity of the included keyed hashvalue. Then, it waits for a certain amount of time in order to receive any other threads of the same route request query coming from different paths. The keyed hash-value of each thread is also checked. Then, the target node T constructs the maximum set of node-disjoint paths M as follows: Say that T received m valid threads QS,T /1, ..., QS,T /m. From the corresponding lists RouteList1 , ..., RouteListm, node T computes the maximum set of lists with noncommon values. Without loss of generality, we may say that the maximum set of lists with Tknon-common values is {RouteList1 , ..., RouteListk | i=1 RouteListi = }, 1 ≤ k ≤ m. Then, the maximum set of nodedisjoint paths between S and T is M = {p1, ..., pk} = {(IDS , RouteList1 , IDT ), ..., (IDS , RouteListk , IDT )}. For each RouteListj ∈ M , node T constructs and broadcasts a route reply message as: RS,T /j = [IDS , IDT , seq, RouteListj , hashKS,T (IDS , IDT , seq, RouteListj )]. Each intermediate node ni that receives a route reply message RS,T /j , checks whether ni ∈ RS,T /i. If 5

4

not, then it drops the reply message. Otherwise, if IDi ∈ RouteListj , then node ni checks whether the nodes identified before and after IDi in RouteListj belong to Ni . In that case, node ni re-broadcasts the reply message RS,T /j as valid. Otherwise, it drops it. Finally, if IDi = IDS , then the node is the source node. In that case, the source node verifies the value hashKS,T (IDS , IDT , seq, RouteListj ) and if it is valid, it stores the path pj = (IDS , RouteListj , IDT ) as a valid path for communication with the target node T .

Security Analysis

We analyze the security properties of the SecMR protocol with respect to other multipath routing protocols with comparable security properties.

4.1

End-to-end route authentication

The route request is end-to-end authenticated with the security association KS,T that is exchanged. The keyed hash-value hashKS,T (IDS , IDT , seq, hopmax ) included in the initial query, allows the target node to authenticate the request query. Note that in order to link the security association KS,T with the source node S, it may be required that S also signs KS,T before encrypting it. However, the cost of public key cryptography is minimized since an Elliptic Curve Cryptosystem is used and only in an end-toend basis. Moreover, if each pair of nodes shares a security association prior to the communication (which is possible for small-sized MANETs), the nodes do not require to exchange KS,T during the route request query.

A source node may communicate with the target node through the node-disjoint routing paths in three modes of operation. In the single operation mode, the source node S uses only the shortest communication path from the set M . An alternative path is used if the path in use is broken. In the parallel operation mode the source node uses in parallel all the k valid node-disjoined paths it maintains towards T . This is the most expensive operation mode and also the most secure, since at least k nodes must be simultaneously compromised for a successful DoS attack. Finally, in the mixed operation mode, communication is performed in the single operation mode and it switches to parallel when either of the two end-nodes requests this, e.g. when the exchanged information is critical or in case where a DoS is suspected.

4.2

Link-to-link route authentication

The links of a routing path are also authenticated indirectly, due to the neighborhood authentication phase of the protocol. Since each node ni periodically authenticates its neighborhood, each node may verify the authenticity of its own links inside any routing path that it participates in. During the route request query propagation, each node ni accepts a request query, only if the last node identified in the partial RouteList of the received route query message, is an authenticated neighbor of node ni . Furthermore, during the route reply propagation, each node ni accepts and forwards a reply message, only if the two nodes identified before and after IDi in the routing path pj = (IDS , RouteListj , IDT ) of the reply message, are authenticated neighbors of ni. Note that these verifications are very efficient since no cryptographic actions are required. Each node ni only verifies if the node identifiers in concern belong to its current neighborhood Nit. The use of the authenticated neighborhood is very efficient, since the cryptographic actions are performed once during a time period, regardless of the number of route request queries and route replies that pass through an intermediate node. The duration of the time period is a system parameter that depends on how often the links between nodes are expected to break or to be established. One could argue that the indirect link authentication allows to a malicious node nM ∈ Ni that is a neighbor of node ni , to impersonate any other node nj ∈ Ni . Although indirect authentication makes such impersonation possible, note that the malicious node will not manage to exclude the

Remark 1. In order to avoid delays caused by the time required to compute the maximum set of node-disjoint paths, the target node T may use the first valid thread to construct a temporary path. When the set M of node-disjoint paths is computed, T may use all the corresponding paths.

3.2.3 Route Error Algorithm If a node ni realizes during neighborhood authentication at time t + 1 that an established link with a neighboring node nj during time t is now broken, then node ni broadcasts a route error message for any active route coming through ni , that is affected due to the destruction of the link (ni , nj ). The route error message is digitally signed by the node ni . If the error messages are not signed, malicious nodes might flood the network with fake error messages even for routes that they do not participate in, and in this way disable communication. The route error message is of the form: ES,T = [IDS , IDT , seq, IDi , RouteList, sigi (IDS , IDT , seq, IDi , RouteList)]. Any node that participates in the broken route marks the particular route as invalid and re-broadcasts the message until S and/or T are informed about the path breakage. According to the operation mode, an end node may restart the route request when: i) a single path, ii) a threshold number of paths or iii) all existing paths from S to T are broken. 6

the IEEE 802.11 Distributed Coordination Function (DCF) as the medium access control protocol. A traffic generator was developed to simulate constant bit rate sources. There are seventeen data sessions, and the sources and the destinations are randomly selected with uniform probabilities. The nodes are placed within the area as shown in figure 4, where an edge between denotes that the connected nodes have been mutually authenticated as dirtect neighbors during the authentication phase.

original node nj from the routing paths, since the protocol allows to node ni to process all different incoming threads of a request query coming from the same node. Thus, such an impersonation attack is useless.

4.3

End-to-end route integrity

The routing path is also integrity protected during the route reply propagation in an end-to-end basis. Indeed, each route reply message includes a keyed hash-value hashKS,T (IDS , IDT , seq, RouteListj ). Thus, if the routing path pj = (IDS , RouteListj , IDT ) has been altered, then the verification of the keyed hash-value will fail at node S and the fake path will not be used.

4.4

Protection against malicious collaborating nodes

This is the basic security property that the protocol is designed for and it is achieved through multipath routing. By using k node-disjoint paths of communication, an adversary should compromise at least k nodes - and more particularly at least one node in each route - in order to control the communication. According to the operation mode, SecMR offers different levels of protection. In parallel mode, the protocol is resilient against k − 1 collaborating malicious nodes. In single operation mode the adversary can disrupt communication by compromising only the active path. The time required to activate an alternative path is still much less than in single-path routing protocols, but there are cases where such disruption may be critical. The protection of the mixed operation mode lies between the single and parallel mode and may be more efficient for practical applications. Remark 2. This protocol does not fully protect from MIM and invisible node attacks. However, the SecMR protocol can be combined with lower-level multiple factor authentication mechanisms [7] to deal with these attacks. Remark 3. Protection of the actual communication can be performed after the establishment of the routing paths with standard cryptographic techniques and secure message transmission protocols, e.g. [18].

5

Figure 4. Network connectivity The simulation of the route discovery showed that both SecMR and the protocol of [4] discover all the existing node-disjoint paths (the set M ) for a given maximum hop number between two end nodes, while SRP [19] manages to discover about 45% of the paths belonging to the set M . Furthermore the route discovery of SecMR converges faster than the route discovery of [4]. On the other hand, SRP produces less redundant paths than the other two. The average number of paths (both node-disjoint and reduntant) that are discovered by each protocol are 3 for SRP [19], 10 for SecMR and 20 for [4]. From these paths, the redundunt ones are 57% for SRP [19], 73% for SecMR and 85% for [4], for a given maximum hop equal to 5. Regarding the number of the exchanged control messages, SRP is the lighter as expected, since it only processes the first request for a particular query. Statistical results have shown that the number of the exchanged control messages of SecMR is multiplied with a factor of 1.4 regarding the SRP, while this corresponding factor in [4] is 4. Figure 5 shows the paths discovered by the three protocols for a typical route request between nodes 18 and 20.

Efficiency Analysis

The efficiency analysis of SecMR is a work-in-progress. Our preliminary results involve a comparison of the route request query between the SecMR, the complete multipath routing protocol of [4] and the SRP protocol [19]. We implemented the simulator within the Ns2 library. Our simulation modelled a network of 50 hosts placed randomly within a 670x670m2 area. Each node has a radio propagation range of 250 meters and channel capacity was 1 Mb/s. Each run executed for 600 sec of simulation time. We used 7

[2] S. Bengio, G. Brassard, Y. Desmedt, C. Goutier, and J. Quisquater, Secure implementation of identification systems, J. of Cryptology 4 (1991), no. 3, 175-184.

The results are representative enough since the data session is the 15th generated session and the the simulated environment has reached to some stability.

[3] M. Burmester and Y. Desmedt, Secure communication in an unknown network using certificates, LNCS Vol. 1716, Springer, 1999, pp. 274–287.

Route Request 7

Multipath[3]

[4] M. Burmester and T. van Le, Secure multipath communication in mobile ad hoc networks , Proc. of ITCC’04 (Las Vegas), IEEE, April 2004.

6

time (sec)

5

SecMR 4

[5] L. Buttyan and J.P. Hubaux, Enforcing service availability in mobile ad hoc WANs, Proc. of the 1st MobiHoc Conference (BA, Massachusetts), August 2000.

3

2

SRP[19]

[6] J. R. Douceur, The sybil attack, In First International Workshop on Peer-to-Peer Systems (IPTPS ’02), American Mathematical Society, March 2002.

1

0

5

10

15

20

Number of Discovered Paths

[7] D. Glynos, P. Kotzanikolaou, and C. Douligeris, Preventing impersonation attacks in manet with multifactor authentication, Submitted, 2004.

Figure 5. Example of a route discovery

6

[8] Z.J Haas and M. Perlman, The performance of query control schemes for zone routing protocol, Proc. of SIGCOMM’98, 1998.

Discussion and Future Work

[9] Y-C. Hu, A. Perrig, and D.B. Johnson, Rushing attacks and defense in wireless ad hoc routing protocols , Proceedings of WiSe’03, 2003, pp. 30–40.

Multipath routing protocols provide resilience against collaborating malicious nodes. SecMR is a complete multipath protocol, in the sense that it discovers all existing node-disjoint paths up to a given maximum number of hops. The security of SecMR is mainly based on neighborhood authentication of the nodes, as well as on security associations, while the use of public key cryptography is minimized. The SecMR protocol can be integrated on top of existing on-demand routing protocols such as DSR, by using additional header messages. Our work in progress includes a thorough efficiency analysis of SecMR through simulations, in comparison with other multipath routing protocols [19, 4] with comparable security properties. Possible optimizations that are considered involve the minimization of the elements included in the lists. For example, in order to bound the size of the ExcludeList an upper limit can be set, after which the intermediate nodes will remove the elements of the list in a FIFO order. The impact of this on the route discovery process however, should be further investigated.

[10] J. Hubaux, L. Buttyan, and S. Capkun, The quest for security in mobile ad hoc networks, Proc. of the 2nd MobiHoc Conference, August 2001. [11] D. Johnson and D. Maltz, Dynamic source routing in ad-hoc wireless networks, Mobile Computing, Kluwer Academic Publishers, 1996, pp. 152–181. [12] N. Koblitz, Elliptic curve cryptosystems, Mathematics of Computation 48 (1997), 203–209. [13] Sung-Ju Lee and M. Gerla, Split multipath routing with maximally disjoint paths in ad hoc networks , Proc. of ICC’01, IEEE, June 2001, pp. 3201–3205. [14] M. Marina and S. Das, Ad hoc on-demand multipath distance vector routing, ACM Mobile Computing and Communications Review 6 (2002), no. 3. [15] J. Marshall, V. Thakur, and A. Yasinsac, Identifying flaws in the secure routing protocol, Proc. of the 22nd IPCC Conference, April 2003, pp. 167–174.

References

[16] S. Marti, T.J. Giuli, K. Lai, and M. Baker, Mitigating routing misbehavior in mobile ad hoc networks , Proc. of the 6th MobiCom Conference, ACM, August 2000.

[1] N. Asokan and P. Ginzboorg, Key-agreement in adhoc networks, Proc. of the 4th Nordic Workshop on Secure Computer Systems, 1999. 8

[17] A. Nasipuri and S.R. Das, On-demand multipath routing for mobile ad hoc networks, Proc. of INFOCOM99, IEEE, 1999, pp. 64–70. [18] P. Papadimitratos and Z. Haas, Secure message transmission in mobile ad hoc networks, Elsevier Ad Hoc Networks 1 (2003), 199–209. [19]

, Secure routing for mobile ad hoc networks, Proc. of the CNDS’02 (TX, San Antonio), January 2002.

[20] C. Perkins, E. Royer, and S. Das, Ad hoc on-demand distance vector routing, Proc. of IEEE Workshop on Mobile Computing Systems and Applications, IEEE, February 1999, pp. 90–100. [21] A-P Subramanian, A. J. Anto, J. Vasudevan, and P. Narayanasamy, Multipath power sensitive routing protocol for mobile ad hoc networks, LNCS Vol.2928, Springer, 2003, pp. 171–183. [22] Jie Wu, An extended dynamic source routing scheme in ad hoc wireless networks, Telecommunication Systems 22 (2003), no. 1-4, 61–75. [23] Hao Yang, Xiaoqiao Meng, and Songwu Lu, Selforganized network-layer security in mobile ad hoc networks, Proc. of the ACM workshop on Wireless security (Atlanta, GA), ACM, September 2002, pp. 11– 20. [24] S. Yi, P. Naldurg, and R. Kravets, Security-aware adhoc routing for wireless networks, Technical Report, UIUCDCS-R-2001-2241, June 2001. [25] Y. Zhang and W. Lee, Intrusion detection in wireless ad-hoc networks, Proc. of the 6th Conference on Mobile Computing and Networking (Boston, USA), ACM/IEEE, 2000. [26] L. Zhou and Z. Haas, Securing ad hoc networks, IEEE Network 13 (1999), no. 6, 24–30.

9