An Optimized Inter-Router Authentication Scheme for Ad hoc Networks

0 downloads 0 Views 84KB Size Report
Due to such characteristics these networks have much harder security requirements than .... our solutions, we would like to define the effect of possible attacks to routing protocols. ... version 4 (IPv4) and IP version 6 (IPv6). The IP ..... [2] William Stallings, Cryptography and Network Security : Principles and Practice, pp. 299–.
An Optimized Inter-Router Authentication Scheme for Ad hoc Networks Lakshmi Venkatraman, Dharma P Agrawal Center For Distributed and Mobile Computing Department of Electrical and Computer Engineering and Computer Science University of Cincinnati Email: lvenkatr,[email protected]

Abstract A mobile ad hoc network is a collection of wireless mobile nodes dynamically forming a network without the use of any fixed network infra-structure. Effective operation of ad hoc networks is dependent on maintaining appropriate routing information in a distributed fashion. The routing protocol can be easily compromised, if a malicious node disseminates false routing information, suppresses useful routing information or intentionally misroutes data packets. Since these hosts that act as routers are themselves moving, security schemes applicable to traditional wireless networks cannot be directly used in this environment. At the network layer, the most pressing issue is one of inter-router authentication prior to the exchange of network control information. In this paper, we have introduced a scheme for inter-router authentication that incurs minimal overhead and at the same time handles the replay problems that could prevail using the existing schemes. The scheme has been incorporated into the routing protocol so that security threats to routing protocols can be minimized. Our scheme is illustrated for AODV routing protocol and is equally applicable to other demand-driven routing protocols. The results of our simulation show the overhead incurred due to authentication, measured in terms of number of packets and the effects on throughput and end-to-end delay. The security achieved warrants these overheads.

1 INTRODUCTION An ad hoc network is a collection of mobile nodes that are arbitrarily located in such a manner that interconnections between nodes change dynamically. It consists of a group of mobile hosts that are not bound to any centralized control like base stations. Although this offers unrestricted mobility and connectivity to the users, the onus of network management is now entirely on the nodes which form the network. Such networks could be very useful in any situation where geographical, terrestrial or time constraints make it impossible to have base stations. This could be in battlefields or any other disaster situation where a network needs to be formed on an ad hoc basis without the support of any fixed infrastructure. In military applications, it is desirable to have a totally distributed 1

system so that the risk of the entire network being compromised due to a single central authority is effectively taken care of. Due to such characteristics these networks have much harder security requirements than the traditional, wired and static Internet. Efficient and effective routing is an especially hard task to accomplish securely, robustly and efficiently at the same time. The contemporary routing protocols do seem to manage the dynamically changing conditions rather well. In the contrary, they offer no security mechanisms at all, or have only partial solutions for protecting the routing. In this paper, we present a scheme for authenticating the control messages involved during routing and ensuring their integrity.

2 MOTIVATION The nature of ad hoc networks make them vulnerable to various forms of attack. Wireless networks are typically much easier to snoop on as only physical proximity is required to gain access to the medium. The impromptu nature of the ad hoc network formation makes it hard to distinguish between trusted and non-trusted nodes. These systems should therefore be robust against such attacks from adversaries. Two different security issues have been identified for ad hoc networks [1].The first is the attacks to the data packets transmitted. These include link-attacks like eavesdropping, impersonation and message distortion. The second potential threat, the problem that we are addressing, is to routing protocols. In conventional wireless networks with base stations, routing is carried out at the back-end that is always wired and static. Therefore the routers are not so easily susceptible to attacks from adversaries. In mobile ad hoc networks, every node acts as a router, transmitting messages from one neighbor to another. (Nodes that are within radio range of each other are termed “neighbors”.) Due to dynamically changing topology, frequent update messages need to be sent from one node to another. Moreover all these messages are transmitted through air. Any intruder could act as a malicious router, giving incorrect routing updates or prevent packets from being forwarded, resulting in indirect denial of service. This could also result in packets never reaching the rightful destination and therefore total failure of the network. In order to ensure end-to-end message transmission, it is imperative to incorporate certain security features in these nodes. Moreover, the nodes of an ad hoc network are roaming and more often in hostile environments. Therefore, they are susceptible to physical attacks too. Nodes with insufficient physical protection are likely to be captured/and compromised. These compromised nodes can disrupt the functioning of the routing protocol by not cooperating or behaving maliciously. These attacks are extremely dangerous as it is nearly impossible to prevent them. The attacks to routing protocols can further be classified into two types. They are External Attack: An attack that is caused by nodes that do not belong to the network. Internal Attacks: Attacks from nodes that belong to the network due to them getting compromised or captured. In this paper we present our scheme to prevent external attacks They are proactively prevented 2

by using our authentication scheme that assumes mutual trust among all network nodes. We are also working on pro-active as well as reactive measures to handle internal attacks. Traditional authentication techniques [2, 3] cannot be directly applied to ad hoc networks due to the absence of a certification authority or a key distribution center. In these networks, each host therefore has to maintain a table containing information needed for authentication for all other nodes in the network. Our scheme addresses the following issues: Authentication: The receiver of a message MUST be able to ascertain who the source of the message is; thereby preventing an intruder from masquerading as a legitimate source of the message in question. The receiver should be able to differentiate between original and replayed messages. Integrity: An intruder MUST NOT be able to alter a message in transit. Key Management: In order to accurately enforce authentication and integrity some form of cryptography is necessary, which requires the distribution of encryption keys to the network nodes. Each routing protocol functions differently from another. We believe that the security features should be designed specifically for each routing protocol so that it works most optimally for the chosen protocol. Therefore, the schemes should be devised, keeping in mind the protocol under study. We have chosen AODV protocol for our study and have presented security schemes for it. It can be modified to work for other reactive protocols like DSR.

2.1 Overview of Routing Protocols Since the idea presented is closely related to the routing protocol that is used, we have first provided a brief overview of AODV. In AODV, whenever a route from source to a destination needs to be found, the route discovery process is initiated. For this purpose route requests are broadcast by the source and propagated through the entire network. When a destination or an intermediate node with route to the destination receives the route request, it sends back a reply to the initiator of the route request. These control messages that are sent during the route discovery phase, are responsible for updating the route table of the source, destination and all intermediate nodes. They are then used to route the data packets. The routing protocol has been extensively studied [4, 5, 6]. However we primarily focus on the methods to minimize the effect of attacks against these protocols. The security scheme presented in this paper is most suited for demand-driven protocols, although it could be used for any flat ad hoc network, independent of the routing protocol used. The implementation and thereby the overheads involved would accordingly differ for other routing protocols.

2.2 External Attacks In this subsection we identify the external attacks specific to AODV. The kinds of attacks would be applicable to other reactive protocols like DSR too. AODV routing protocol involves two aspects: 3

Route discovery and maintenance and Forwarding of data packets. The route discovery and maintenance involves frequent exchange of control packets. On the other hand, routing of data packets involves forwarding of a packet from one router to another. The routing protocol could be brought down by attacks to either of the two phases. Prior to presenting our solutions, we would like to define the effect of possible attacks to routing protocols. The nature of attacks may hold good for other protocols too. The external attacks that we have identified are listed below: Causing routing table inconsistencies: This would occur if, 1. A malicious node impersonates another node and sends routing updates. False route requests, replies and updates could cause inconsistencies in the routing table. 2. Replay of the control messages like route requests, route replies and route errors is also a critical issue to be taken care of. Misrouting of packets: Tampering of control messages could result in incorrect route information. The routing process is adversely affected if integrity of data is not ensured. For example, if the fields in the route request or reply are modified, the protocol functioning is considerably affected. Denial of Service: This can be done generating false broadcast packets like route requests. The network can be flooded with wasteful packets thereby preventing channel access to rightful users.

3 RELATED WORK Up to date there are very few security schemes (in open literature) proposed for ad hoc networks. The problems related to network security have been identified and the idea of using threshold cryptography has been suggested [1]. An architecture for distributed and cooperative intrusion detection was presented [7]. Experiments have been performed where authentication of MAC and IP address exchange has been tried [8]. The MANET authentication architecture has also been proposed where the emphasis is on building an hierarchy of trust in order to authenticate the IMEP messages [9]. This would be difficult to implement in practice. This is because in these networks, the nodes are constantly moving and there is no underlying infrastructure. Therefore it may be very difficult to find common certification authorities for any two communicating nodes. In wired networks IPSec security architecture [10, 11, 12] provides security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6). The IP Authentication header is designed to provide integrity and authentication without confidentiality to IP datagrams. Every pair of node needs to share a key and therefore the number of keys involved in the whole network is very high. This does not work well in the case of ad hoc networks. This is because the authentication header in IPSec has a sequence number that would take care of replay problems in wired networks. But it can not handle replay of control messages like route requests, replies etc. A malicious node could eavesdrop on 4

route requests or any control message from node “A” and move else where and replay the packet to another node “B”. The node “B” then considers “X” as the next hop to “A” and forwards all packets meant for “A” to “X”. This kind of a situation is undesirable and can’t be prevented using sequence numbers. Although the example presented is specific to AODV, these kinds of attacks are possible on any other routing protocols. The most secure way for mutual authentication would need multiple exchange of messages between the communicating nodes and is termed strong authentication. In our scheme we only verify the authenticity of a packet that would result in modification of routing table. If the message would not affect the routing table, it would have no bearing on the routing of subsequent data packets.

4 PROPOSED SOLUTION In order to address the aforementioned attacks, we have proposed an authentication scheme that can prevent the external attacks that we have identified. The scheme is specifically for AODV routing protocol. The scheme is based on the following assumptions. 1. The network consists of a group of mutually trusting nodes. This can be safely assumed because the formation of the network itself is after the approval of some governing body or managing authority that created the network. Although nodes could be compromised, we have schemes to detect them. 2. All links between the nodes are bi-directional. 3. Although hosts can get into promiscuous receive mode, they make no changes to route cache based on this, because relying on unauthenticated messages could jeopardize security. 4. The nodes are computationally powerful enough to execute encryption algorithms. 5. Device technology has made memory extremely cheap. The assumption therefore is that each node has sufficient memory to store information about many other nodes. This is a reasonable assumption because ad hoc networks are expected to be comprised of a few hundred nodes.

4.1 Design Criteria Our solution has taken into account the following design criteria so that the security requirements are met within the existing constraints. Complete Security: The routing protocol should be absolutely secure and should satisfy the security attributes like Availability, Integrity and Authentication [13, 3]. Minimal Overhead: The overhead in terms of number of packets or traffic in the network should be minimal. This would ensure minimal increase in demand on bandwidth. 5

Network Performance: The network performance, in terms of throughput and average end-to-end delay, should only be affected to a tolerable extent. Efficient Key Exchange and Management: This is important because the nodes need to mutually authenticate one another without the intervention of any central authority. The keys required for this purpose need to be available. Node Mobility: Since the network topology constantly changes due to movement of nodes, each node should be capable of mutually authenticating even a new node that has recently moved into its neighborhood.

4.2 Key Distribution Scheme Since these networks don’t have a centralized control, management of keys is a challenging issue. Our scheme is based on public key cryptography. The governing authority that creates the network is the only entity that has the system private key. Each node is given a public/private key pair by the authority. The system private key is used to sign the public keys of all the nodes. This signing of the public key takes place off-line before the node can join the network. This can be done securely by making use of traditional security schemes for wired networks or can be physically incorporated into the nodes. Each node is also given the system public key. Whenever two nodes interact for the first time, the certified public keys are exchanged. Since the nodes have the system public key, the authenticity of the certificate can be confirmed. The nodes can then mutually authenticate one another using their individual public/private keys as shown in the Figure 3. Since only the governing authority has the system private key, it is secure. Moreover this authority be well protected since it is not mobile like the other nodes. Once considerable time has elapsed, and if the node mobility were extremely high, each node might need to store the public key of large number of nodes, potentially all system nodes. However this is the worst case and might never occur in actual practice. If it is detected that any of the nodes has been compromised, then a key revocation list containing the key of the compromised nodes is propagated into the network.

4.3 Overview of our Approach We have introduced a new security scheme for AODV routing protocol. AODV is an on demand routing protocol that performs well even conditions of very high node mobility. This could be easily incorporated into DSR [14] with a little modification. Whenever the route from a source ‘A’ to a destination ‘B’ needs to be found, the route discovery process is initiated. For this purpose route requests are broadcast by the source and propagated through the network. When the destination or an intermediate node with route to the destination receives the route request, it sends back a route reply to the initiator of the route request. These control messages that are sent during the route discovery phase, are responsible for updating the route table of the source, destination and 6

the intermediate nodes. These messages therefore need to be authenticated before the route tables are modified, to ensure that the route tables do not contain any incorrect information provided by malicious nodes. Our scheme performs authentication between every pair of nodes because every intermediate node updates its routing table based on the control messages that it receives.

4.4 Details of Our Scheme We explain our scheme with the help of an example.

M I J

K

I

B

A

C

E

D

G

F

H Figure 1: Example of Route Request Propagation in Ad hoc Networks

Figure 1 shows an ad hoc network where the edges represent a bi-directional link between the nodes. In the example a route from node A to node D is discovered. The arrows in Figure 1 show the path along which the route requests propagate. When a node receives a route request from its neighbor it updates the route table entry for the source of the request. The neighbor who sent the request is stored as the next hop for the request source. For example, in the above case, E is stored as the next hop by F for all messages intended for A. When destination D receives the request it sends back a reply to the first request it receives. Nodes J and F reply to the request as they already have in their table an entry for node D, resulting from earlier route discoveries. The reply paths are as shown in Figure 2. 7

M L

J

K

I

B

A

C

E

D

G

F

H Figure 2: Example of Route Reply in Ad hoc Networks

When the route replies are received all the intermediate nodes update the route table entry for the destination (D in the example). This is similar to the route table updating done during propagation of requests, except that it is performed for the reverse direction. Since the route tables are updated by route requests as well as route replies, all the nodes that send and receive these messages SHOULD mutually authenticate one another. This will ensure the correctness of information present in the route table. For strong authentication between nodes, challenges have to be sent back and forth for each of these messages. Every packet carrying control data would result in at least two more packet exchanges between each pair of nodes. This packet overhead would be extremely high for route requests because the network is flooded with the requests. Moreover these requests are broadcast packets. Therefore authentication needs to be performed between one sender and several receivers. This results in convergence of packets towards a single node, causing excessive collisions. We have therefore adopted a different approach that handles these issues and also keeps the overheads very low. In our scheme, we do not perform strong authentication during propagation of route requests. The integrity of the route requests is ensured by making use of Message authentication codes. The hash of the message is computed and then encrypted with the sender’s private key for authentication. The HMAC algorithm is used in conjunction with MD 5 for this purpose. When the neighbors receive the route request, the validity of the node is verified using the sender’s public key. Even though 8

Pre-Reply + challenge1 Encrypt(challenge1) + challenge2 Reply + Encrypt(challenge2) Figure 3: Three way communication during Route Reply

message authentication code is used, the updated the entry is marked as unauthenticated. This is because message authentication code can only check for integrity, but can not prevent the replay problem. It may be noted that unauthenticated routes may be used ONLY for sending insensitive data. Strong authentication is performed between ALL adjacent pairs that transmit route replies. The route reply sent from any node to its neighbor happens as shown in Figure 3. A node sends a Pre-reply to inform its neighbor that it wishes to send a reply. The pre-reply has a field that contains a random challenge string for the neighbor. The neighbor that receives the pre-reply generates a new challenge sends it to the node that sent the pre-reply. It also appends to the challenge the string obtained by encrypting the received challenge with its private key. If the two neighbors do not know each other’s public key, i.e., if they are interacting for the first time, the certified public keys are also exchanged. The challenges are small in size to keep the overhead low. If an authentication fails during the route request, the packet is dropped. If an intruder is detected during the strong authentication of reply, the path established by the reply is purged. Since the replies are authenticated, these routes are valid and can be used for sending data packets. When the authenticated reply is received the route tables entry for the source, that was marked as unauthenticated, is now marked as valid. Therefore all intermediate nodes in the reply path have a valid route to the source too. The nodes that are not in the reply paths (nodes K, H, L, G, M in our example) have unauthenticated route entries for the source (A in our example). If they need to use the unauthenticated routes to send critical data, they would send a unicast route request along the unauthenticated route to confirm its validity. Since the request is not flooded, there is considerable reduction in the packet overhead. This is shown in Figure 4 where node M needs to send data to node A. If authentication along the reply path fails, it implies that the request that was sent was an invalid one. Therefore, the modifications made in the route tables of intermediate nodes in the reply path due to the propagation of reply packet is purged. In order to achieve this a control packet called Purgereplyroute is sent by the node that discovers the attack. The third kind of control message is Route error message. This error message is sent when ever a node detects a break in the link with its neighbor. It is sent to all neighbors that use the link for routing. The break in the link is realized by using MAC layer detection. We have not used hello messages because this by itself is an overhead and authentication of these messages would result in a huge packet overhead. The route error messages need to be authenticated too because they 9

M I J

K

I

B

A

C

E

D

G

F

H

Figure 4: Route Request Unicast Along Unauthenticated Route

affect the routing table. The overhead due to this authentication is at best marginal because in a network with average mobility, the number of route error packets sent is very small. Moreover, the error messages propagate to very small distances i.e. a few hops. They have negligible effect on the results, we have therefore ignored it and have used message authentication codes for them too.

5 Experiments and Performance Evaluation In this section we describe the experiments and present our results.

5.1 Simulation Environment We have used the ns-2 simulator [15] for our implementation. The IEEE 802.11 [16] is used for the MAC layer. The AODV protocol simulation is available as a part of the simulator. We have modified the existing code in order to make it secure. The protocol maintains a send buffer of 64 packets. It buffers all data packets waiting for a route. Packets are dropped if the waiting time exceeds 50 seconds. This is done so that packets are not indefinitely buffered. The transport protocol that we used for our simulations is UDP.

10

5.1.1

Traffic and Mobility Models

Traffic sources used are Constant-Bit-Rate (CBR). The traffic files were generated such that the source and destination pairs are randomly spread over the entire network. The rate of packet generation and the number of sources are varied to get different data rates and traffic patterns. Each data packet is 512 bytes long. The scenario files determine the mobility of the nodes. These scenario files have been generated using the scene generator of the simulator. The mobility model uses random waypoint [5] model in a rectangular field. The field configuration is 1500m x 300m with 50 nodes. These nodes move from a random starting point to a random destination with a speed that is randomly chosen (the speed is uniformly distributed between 0 - 20 m/sec). Once the destination is reached another random destination is targeted after a pause time. The pause times are varied to change the mobility of the nodes. A pause time of 0 seconds indicates maximum mobility. Each simulation is performed for 900 seconds. The simulation has been performed for the AODV protocol with our security scheme as well as for the original AODV protocol using similar conditions. The results for both cases have been observed. 5.1.2

Performance Metrics

We used the following metrics to evaluate the performance of our scheme. Packet Delivery Fraction: This is the ratio of CBR packets delivered to that generated and is the measured throughput. This fraction is affected by two factors: the number of packets dropped and the end-to-end delay. For a fixed time period, if the delay increases the number of packets received at the destination would be lower. Routing Overhead: The number of routing packets transmitted per data packet. Each hop of the routing packet is treated as a packet. We have used the normalized routing load for our comparison, which is the ratio of routing packets to the data packets. Average end-to-end delay: This is the average of delays of all packets successfully transmitted. Number of data packets dropped: We have recorded the number of data packets dropped in both the cases. This is important because if the drop increases, the throughput would decrease. The metrics mentioned above are important determinants of network performance. We have used them to compare the network performance of our scheme with that achieved using the original protocol. We have done this study to show that our scheme enhances the security of the routing protocol without causing substantial degradation in network performance.

11

5.2 Results We have observed the effect of our scheme on the network by varying the data rate and the mobility. In the following paragraphs, we present the results obtained for our test cases. The recorded values are obtained by averaging over three runs for each test case. 5.2.1

Varying Mobility

We performed simulations [6] for a network of 50 with 10 data sources. The simulation has been carried out for 900 seconds. The mobility of the nodes is varied by varying pause times from 0 to 900 seconds in steps of 100 seconds. The data rate is maintained constant at 4 packets/sec. The graphs in Figure 5 compare the performance of the routing protocol without security scheme and with our security scheme. We observe from Figure 5 that the routing load increases due to incorporation of security. It also shows how our scheme affects the packet delivery fraction and end-to-end delay. The packet delivery fraction is marginally reduced. 5.2.2

Varying Load

We have performed experiments for networks with 50 nodes. The number of data sources were still maintained at 10. We have chosen the highest mobility for our simulation by setting the pause time to zero seconds. This is with the intention of carrying the tests under most challenging conditions. The offered load is varied by changing the rate at which the source sends the packet. Test cases have been excepted for data rates ranging from 20 packets/sec to 4 packets/sec. Each packet length is 512 bytes. Therefore, the offered load varies from 819 kbits/sec to 10 kbits/sec. The graphs in Figure 6 compares the network performance for different load conditions and using the two routing protocols, the original AODV and AODV with security scheme incorporated. The comparison graphs show that the overhead in terms of routing load is substantially low. The effect on throughput which is measured as the packet delivery fraction is negligible. There is a small increase in the end-to-end delay and this is due to the exchange of packets during authentication.

5.3 Observations and Inferences In this subsection we discuss the significance of the results that we have presented. Routing Load: The number of packets needed for routing increases when our scheme is incorporated. This is an obvious occurrence because the authentication of route reply packets involves exchange of additional packets. We have brought down the packet overhead by restricting authentication to route replies alone. The increase in routing load is higher at higher mobilities and reduces for lower mobilities. This is because at higher mobilities, routes need to be found more frequently and therefore more authentications are needed. The difference in the routing overhead for the rout-

12

Normalized Routing Load Vs Pause Times 1.4 with authentication Without authentication 1.2

normalized routing load

1

0.8

0.6

0.4

0.2

0 0

100

200

300

400 500 pause times (sec)

600

700

800

900

Packet Delivery Fraction vs Pause Time 1 with authentication without authentication

packet delivery fraction

0.8

0.6

0.4

0.2

0 0

100

200

300

400 500 pause times(sec)

600

700

800

900

Average end-to-end delay vs pause times 0.1 with authentication without authentication

average end-to-end delay

0.08

0.06

0.04

0.02

0 0

100

200

300

400 500 pause time on seconds

600

700

800

900

Figure 5: Comparison graphs of routing load and 13 throughput in a network with 50 nodes and 10 data sources obtained by varying pause times

Normalized Routing Load vs Data Rates 11 with authentication without authentication

10 9

normalized routing load

8 7 6 5 4 3 2 1 0 0

100

200

300

400 500 data rates (kbits/sec)

600

700

800

900

Packet Delivery Fraction vs Data Rates 1 with authentication without authentication

packet delivery fraction

0.8

0.6

0.4

0.2

0 0

100

200

300

400 500 data rates (kbits/sec)

600

700

800

900

Average end-to-end delay vs data rates 0.9 with authentication without authentication 0.8

average end-to-end delay

0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0

100

200

300

400 500 data rates in kbits/sec

600

700

800

900

Figure 6: Comparison Graphs for a network with14 50 nodes and 10 data sources obtained by varying offered load

ing protocol with and without authentication is negligibly low for higher data rates. On the whole, varying data rates does not significantly affect the authentication overhead because this does not cause any additional route discoveries. Packet delivery Fraction: This is a measure of the throughput of the network. For most cases of mobilities the throughput achieved after incorporation of our scheme is lower. But the decrease in throughput is around 2 %. As the number of routing packets increase, the number of data packets reaching the destination becomes lower. Again, varying the data rates does not affect the packet delivery fraction significantly. Data packets dropped: Though the number of packets dropped increases by incorporation of our scheme, the increase is not very high. This drop is caused by drops in buffers due to timeouts. The delay introduced in route discovery causes this timeout. This could be improved by having higher timeouts for packets buffered for route discovery. Average End-to-End delay: This is the average delays of all data packets. The delays of only the data packets that wait for route discovery increases where as delays for all other data packets is unaffected. Therefore the increase in the end-to-end delay is fairly low.

5.4 Appraisal of Our Scheme The scheme meets the targeted goal of authentication. Since any packet that could potentially modify the routing table is authenticated, it is not possible for an intruder to inject erroneous routing updates. We present the appraisal of the scheme by analyzing its performance when faced with different attacks. 1. A malicious node impersonates another node and sends routing updates. False route requests, replies and updates could cause inconsistencies in the routing table. This would not be possible because a node that does not belong to the network can not have the certified key. Therefore, it would be unable to produce the right message authentication code. 2. Replay of the control messages like route requests, route replies and route errors. Although the broadcast packets propagate, the route tables are unaffected because this will be detected while performing strong authentication along the route reply path. 3. Misrouting of packets: Tampering of control messages could result in incorrect route information. The routing process is adversely affected if integrity of data is not ensured. For example, if the fields in the route request or reply are modified, the protocol functioning is considerably affected. This is not possible because presence of message authentication code ensures data integrity. Every node maintains a list of public keys of many other nodes. It acquires these keys over a period of time. No flooding or broadcasting is required for this purpose. During the first encounter, the 15

certified public keys are exchanged. These keys are then noted into a table. Thus, the table in each node consists of public keys of nodes with whom it has communicated at least once. Although there is a considerable demand on memory, key management is efficient as it does not involve any additional packet overhead. The results of our simulations show that or secured routing protocol functions very similarly to the existing one when there are no external attacks. Whenever an attack occurs additional packets need to be sent to purge the routes established by the spurious control packets.

6 Limitations Our scheme is most suited for on-demand routing protocols. If the scheme is introduced for a tabledriven protocol, the overheads would be too high, thereby affecting network performance. This is because in table- driven protocols any change in topology is propagated even if the specific route is not used. These messages that contain the topology information HAVE to be authenticated and would result in extremely high overhead. If broadcast packets like route requests are replayed by an external node, they are detected only when the reply is received. The scheme is not suited for any protocol where exchange of hello messages is mandatory. The overheads due to authentication of periodic hello messages would cause considerable degradation in network performance. If the broadcast packets like route requests are replayed, the intrusion is detected only after the reply is received. This may result in unnecessary flooding of the network and thereby consume network resources.

7 Conclusions and Future Work We have proposed a security architecture for routing protocols. We have presented a scheme to proactively prevent external attacks. The attacks and the presented solutions have been targeted for on-demand routing protocols, specifically AODV. The scheme ensure authentication and integrity of control messages, the key management required for this purpose is also done without involving significant overheads. The results of our implementation show that the effect of the overheads caused by our scheme is marginal and has negligible effects on network performance. We propose to introduce schemes to detect compromised nodes. We also plan to modify the authentication scheme to suit table-driven protocols.

16

References [1] L. Zhou and Z.J. Haas, “Securing ad hoc networks,” IEEE Network Magazine, vol. vol. 13, Nov/Dec 1999. [2] William Stallings, Cryptography and Network Security : Principles and Practice, pp. 299– 353, Second edition. [3] N Haller and R Atkinson, “On http://www.sunsite.dk/RFC/rfc/rfc1704.html, Oct 1994.

internet

authentication,”

[4] Charles E. Perkins and Elizabeth Royer, “Ad-hoc on-demand distance vector routing,” in 2nd IEEE Workshop on Mobile Computing Systems and Applications, Feb 1999, pp. 90–100. [5] J Broch, D.A. Maltz, D.B. Johnson, Y-C. Hu, and J. Jetcheva, “A performance comparison of multi-hop wireless ad hoc network routing protocols,” in 4th International Conference on Mobile Computing and Networking (ACM MOBICOM’98), Oct 1998, pp. 85–97. [6] Samir R. Das, Charles E. Perkins, and Elizabeth M. Royer, “Performance comparison of two on-demand routing protocols for ad hoc networks,” in IEEE Conference on Computer Communications (INFOCOM), mar 2000, pp. 3–12. [7] Yonguang Zhang and Wenke Lee, “Intrusion detection in wireless ad-hoc networks,” in 6th International Conference on Mobile Computing and Networking (MOBICOM’00), Aug 2000, pp. 275–283. [8] James Binkley, “Authenticated ad hoc routing at the link layer for mobile systems,” http://citeseer.nj.nec.com/cachedpage/121413/1. [9] M. S. Corson Stuart Jacobs, “Manet authentication architecture,” http://www.ietf.org/internetdrafts/draft-jacobs-imep-auth-arch-00.txt, Aug 1998. [10] S. Kent and R. Atkinson, “Security architecture for the internet protocol,” http://www.sunsite.dk/RFC/rfc/rfc2401.html, Nov 1998. [11] S. Kent and R. Atkinson, “Ip http://www.sunsite.dk/RFC/rfc/rfc2402.html, Nov 1998.

authentication

headerl,”

[12] C Madson and R Glenn, “The use of hmac-md5-96 within esp and ah,” http://www.sunsite.dk/RFC/rfc/rfc2403.html, Nov 1998. [13] William Stallings, Cryptography and Network Security : Principles and Practice, pp. 3–12, Second edition. [14] Josh Broch, David B. Johnson, and David A. Maltz, “The dynamic source routing protocol for mobile ad hoc networks,” http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietfmanet-dsr-02.txt, Jun 1999. 17

[15] Kevin Fall and Kannan Varadhan (Eds.), mash.cs.berkely.edu/ns/, 1999.

“ns notes and documentation,” http://www-

[16] Wireless LAN medium access control (MAC) and physical layer (PHY) specifications, IEEE standard 802.11-1997, 1997.

18