Mitigating Route Request Flooding Attacks in Mobile Ad Hoc Networks Zhi Ang EU1,2 and Winston Khoon Guan SEAH2,1 1
School of Computing, National University of Singapore
[email protected] 2 Networking Department, Institute for Infocomm Research, A*STAR
[email protected]
Abstract. A mobile ad hoc network is set up with a group of mobile wireless nodes without the use of any dedicated routers or base stations. Each node acts as an end node as well as a router for other nodes. There are generally two types of ad hoc routing protocols, reactive and proactive routing protocols. The focus of this paper centers on reactive routing protocols which establish routes between communicating nodes when needed using a route discovery process involving Route Requests and Route Replies, a process which can be easily misused for denial-of-service attacks. In this paper, we will describe one such attack, the Route Request Flooding Attack (RRFA) targeted at reactive routing protocols used in mobile ad hoc networks. Then, we propose the Route Request Flooding Defence (RRFD) mechanism that is designed to reduce the impact of RRFA. Finally, we present simulation results to show the detrimental effects of RRFA and the effectiveness of RRFD.
1 Introduction A mobile ad hoc network (MANET) consists of a group of mobile wireless nodes that allow data communications beyond direct radio transmission through the use of intermediate nodes that will help to forward data packets. In MANETs, there is no central entity to coordinate the operations of the network, therefore there are more security challenges as compared to wired networks. Due to the nature of the wireless medium, malicious nodes or trusted nodes infected by viruses or worms can disrupt the operations of ad hoc networks by injecting wrong routing information or forging data packets. In this paper, we aim to address the problem of malicious flooding of route requests and present our solution using a popular reactive MANET routing protocol, the Ad hoc On-Demand Distance Vector (AODV) [1], as an example. This paper is organized as follows. Section 2 gives an introduction to the basic features of AODV and describes a particular denial-of-service attack against MANETs that use reactive routing protocols – Route Request Flooding Attack (RRFA). Section 3 gives related work on security for AODV and lists some of the existing measures that can reduce the impact of RRFA. Section 4 describes our solution, the Route Request Flooding Defence (RRFD) that aims to reduce the impact of RRFA. We present some simulation results in Section 5, which demonstrates the impact of RRFA and the performance improvement when RRFD is used. Section 6 concludes this paper.
2 AODV and RRFA The Ad hoc On-Demand Distance Vector (AODV) is a reactive MANET routing protocol. If a node wants to send data packets to a destination that is not in its routing table, it will buffer the data packets and broadcast a Route Request (RREQ) into the network. The RREQ packet will be forwarded by other intermediate AODV nodes to the intended destination node. The destination node, upon receiving the RREQ, will send a Route Reply (RREP) on the reverse route back to the source node. After a RREQ is sent, the node will wait for a period of time for the RREP, namely, NET_TRAVERSAL_TIME milliseconds. If a RREP is not received within that time period, another RREQ will be sent, and for every RREQ sent, the waiting time for the RREP would be doubled. If no RREP is received after a fixed number of attempts, the data packets from the buffer will be dropped. If more data packets are received from the application layer, a new route discovery process will be initiated. In this paper, for the purpose of analysis, we assume that expanding ring search is not being utilized. If expanding ring search is used, the impact on the network will be similar since the reduction in transmission radius of the RREQ is offset by the increased rate at which RREQs are broadcast. The Route Request Flooding Attack (RRFA) is a denial-of-service attack which aims to flood the network with a large number of RREQs to non-existent destinations in the network. In this attack, the malicious node will generate a large number of RREQs, possibly in the region of hundreds or thousands of RREQs, into the network until the network is saturated with RREQs and unable to transmit data packets. RRFA can be classified into two types: breadth-RRFA and depth-RRFA. In breadth-RRFA, an attacker would initiate route discoveries to a large number of unreachable destinations. There are two possible ways to implement this attack. The first method is from the application layer. If the maximum allowable number of RREQs sent per second (RREQ_RATELMIT) is set to a very large value, the attacker can send a large number of data packets (e.g. PING packets) continuously into the network layer, resulting in a large number of RREQs originating from the node. In the second method, the attacker can modify the routing protocol or use malicious code to send out large numbers of RREQs to unreachable destinations. In depth-RRFA, the attacker will send out a large number of RREQs repeatedly. Only one unreachable destination is needed as compared to many for breadth-RRFA. Reactive routing protocols generally require less routing overhead than proactive routing protocols because routes need not be maintained through periodic route updates even when there is no data traffic. Proactive routing protocols are not affected by RRFA as data packets are dropped at the source or any intermediate nodes if the destinations are not found. However, RRFA can seriously degrade the performance of reactive routing protocols and affect a node in the following ways: 1. The buffer used by the routing protocol may overflow since a reactive protocol has to buffer data packets during the route discovery process. Furthermore, if a large number of data packets originating from the application layer are actually unreachable, genuine data packets in the buffer may be replaced by these unreachable data packets, depending on the buffer management scheme used. 2. Depending on the design of the wireless interface, the buffer used by the wireless network interface card may overflow due to the large number of RREQs to be sent.
Similarly, genuine data packets may be dropped if routing packets have priority over data packets. 3. Since RREQ packets are broadcast into the entire network, the increased number of RREQ packets in the network results in more MAC layer collisions and consequently, congestion in the network as well as delays for the data packets. Higher level protocols like TCP which is sensitive to round trip times and congestion in the network will be affected. 4. Since MANET nodes are likely to be power and bandwidth constrained, RRFA can reduce the lifetime of the network through useless RREQ transmissions as well as additional overheads of authenticating a large number of RREQs, if used.
3 Related Work The salient features of MANETs make them extremely vulnerable to malicious node behaviour resulting in performance degradation [2]. A summary of some security measures for MANETs in general is provided in [3] while security problems in AODV and specific attacks against AODV are addressed in [4] and [5]. A secure AODV that makes use of digital signatures and hash chains to protect routing packets is described in [6]. Intrusion detection systems described in [7], [8] and [9] are able to detect RRFA since there would be a significant increase in the number of RREQ packets. Once nodes are detected to be malicious, they are usually excluded from the network. However, this does not work well against worms or viruses that are able to spread through the network to infect other nodes. We do not propose to exclude nodes from the network once they are detected to be malicious. Instead, we try to reduce their negative impact on the network since they may still be willing to forward data packets. We now examine five current approaches used against RRFA: 1. Address filtering for RREQs. If the nodes know the IP addresses of all the nodes in the network, they can drop RREQs for destinations that are not in the network. However, this approach requires the nodes to have global knowledge of the network. Since nodes may fail, leave or join the network at any time, it is difficult to know all the valid IP addresses of the nodes at all times. The impact of depthRRFA will not be affected as long as there exists at least one unused IP address. 2. The AODV RFC[1] specifies that a node should not originate more than RREQ_RATELIMIT RREQs per second. This can prevent attacks from the application layer but does not prevent the attacker from modifying the routing protocol to set RREQ_RATELIMIT to a very large value. Furthermore, genuine RREQ attempts to reachable destinations can be hindered since they may be dropped when RREQ_RATELIMIT is always reached due to excessive forged RREQs. 3. In Ariadne[10] which is designed for DSR networks, route discovery chains are used to rate-limit the number of route discoveries. Each route discovery needs a key from the route discovery chain and the release of keys can be regulated. This limits the impact of RRFA on the network but a fixed number of forged RREQs can still be injected into the entire network. Furthermore, genuine RREQ attempts from a compromised node to reachable destinations may never be sent if the number of forged RREQs generated by it is large.
4. In [11], an adaptive statistical packet dropping mechanism is proposed to defend against malicious control packet floods like RRFA but the mechanism does not distinguish between genuine and forged RREQs from the malicious or victim node. Furthermore, the effectiveness of the mechanism depends on the network conditions. 5. In [12], a priority system is used to determine the transmission priority of RREQs. When the malicious node broadcast excessive RREQs, the priorities of its RREQs are reduced. Similarly, this method does not distinguish between genuine and forged RREQs from the malicious or victim nodes.
4 Route Request Flooding Defence (RRFD) In this paper, we assume that there exists a security mechanism, such as public key cryptography and digital signatures that enables a node to authenticate routing messages from any node in the network. Therefore, a malicious node cannot spoof the originator and destination IP addresses in a RREQ packet although the destination IP address may not be reachable in the network. To alleviate the impact of RRFA on the overall performance of the network, we propose the Route Request Flooding Defence (RRFD) mechanism that aims to do the following: 1. Minimize the impact of breadth-RRFA and depth-RRFA on the entire network. Neighbours of a malicious node will not rebroadcast most of the forged RREQs from that node, thus confining the impact to the neighbours of that malicious node. 2. Identify forged RREQs to a very high accuracy. This is achieved by observing the RREQs received. If there are many RREQs with the same source and destination sent within a short period of time, then it is highly likely to be forged. 3. Allow the malicious node to maintain or establish valid data communications to reachable destinations. Since the user of the malicious node may not know that the node has been compromised, it would be beneficial to allow the malicious node to continue its communication with other nodes in the network. 4. Subject the packets to two rounds of examination before they are retransmitted into the network. Firstly, the RREQ is examined to determine if it is forged using RRFA. If the RREQ is forged, it will be dropped with no further authentication. Otherwise, if the RREQ is deemed to be genuine, then it will be authenticated to ensure that the RREQ is not forged. 4.1
RRFD Design
RRFD consists of three components: RREQ binary exponential backoff, Route Discovery Cycle (RDC) binary exponential backoff and Fast Recovery. In RREQ binary exponential backoff, each node will ensure that its neighbour follows a binary exponential backoff when sending RREQs in a RDC. If RREQs are sent faster than what is allowed, excess RREQs are dropped. This ensures that the generation of RREQs in a RDC follows a binary exponential backoff as stated in the AODV specifications [1]. Fig. 1 illustrates the earliest times in which RREQs are allowed to be sent in a RDC if the number of RREQ retries is set to 2.
Start of RDC 1st RREQ retry
2nd RREQ retry
End of RDC
NET_TRAVERSAL_TIME Length of a RDC Fig. 1. Illustration of a Route Discovery Cycle (RDC)
In RDC binary exponential backoff, each node will ensure that its neighbour follows a binary exponential backoff when initiating another RDC. The waiting time between successive RDCs will be doubled after each successful RDC. Using RDC binary exponential backoff, the impact of RRFA would be reduced exponentially if the attacker persists in sending forged RREQs. Fig. 2 illustrates the earliest times in which a new RDC is allowed to proceed if a node keeps receiving RREQs with the same pair of source and destination node in every RDC. 1st RDC
2nd RDC
1 RDC backoff
3rd RDC
2 RDCs backoff
4th RDC
4 RDCs backoff
Fig. 2. Illustration of RDC binary exponential backoff
In Fast Recovery, the number of RDCs that a node will need to wait before initiating another RDC will be reduced exponentially if it does not initiate another RDC for at least one RDC period. Due to node movement, link breakages may occur after a period of time. Therefore, Fast Recovery ensures that nodes that send genuine RREQs do not get penalized by RRFD. By using RDC binary exponential backoff in conjunction with Fast Recovery, the aim of identifying forged RREQs to a very high accuracy is achieved since we drop most of the forged RREQs without affecting the transmission of genuine RREQs. To implement RRFD, each node maintains an entry in a RREQ database for every unique pair of originator and destination nodes. It is not sufficient to maintain an entry for just every originator that is a neighbour of each node as collusion might occur in the case of two or more neighbouring malicious nodes. When a RREQ is received, we search the RREQ database for an entry. If an entry is not found, we create a new entry, start a new RDC and rebroadcast the RREQ. If an entry exists, this indicates that there was a previous RREQ with the same originator and destination. If the RREQ is in a current RDC, the backoff time will be determined based on the number of RREQs already forwarded by the node in the current RDC. If we have reached the end of the RDC after forwarding the RREQ, the RDC backoff would be set to twice the previous value subject to a predetermined maximum value (we set this value to 64 in our work). If the RREQ is not in a RDC, the backoff time will depend on the number of RDCs to backoff, which may be reduced according to the Fast Recovery algorithm (if a node has not transmitted a similar RREQ for at least one RDC).
4.2
RRFD Analysis
To provide a simple mathematical analysis of the success of RRFD against breadthRRFA, we define a metric S as: Number of forged RREQs forwarded by node if RRFD is used
S = 1−
Total number of forged RREQs forwarded by node if RRFD is not used
which refers to the ratio of forged RREQs that are dropped by node A when RRFD is used against the number of forged RREQs forwarded by node A when RRFD is not used. Therefore, S measures the success ratio of RRFD against RRFA. The value of S depends on the type of attacks and changes over time. Therefore, we define Sn as the success rate before the (n+1)th successful RDC by an attacker, M. Let Ri be the success rate of the node in using RRFD to defend against RRFA by M during the interval between the start of the ith and (i+1)th successful RDC. Also, let x be the number of RREQs transmitted in one RDC. Therefore, 1 x Ri = 1 − = 1− i − 1 (1 + min(2 ,64)) x (1 + min(2 i −1 ,64)) R1 is
1 2
since one RDC of RREQs is dropped during the interval between the start
of the first and just before the start of the second successful RDC by M. The maxi64 65 n
mum value of Ri is Sn =
since we set the maximum number of RDC backoff to be 64.
∑ Ri * (1 + min(2
i −1
i =1
n
∑ (1 + min(2
i =1
i −1
,64)) * x = 1−
,64)) * x
nx n
nx + ∑ min(2 i −1 ,64) * x i =1
For values of n ≥7, Sn = 1−
nx = 1− (n + 1 + 2 + 4 + 8 + 16 + 32 + 64 + (n − 7)64) x
1 321 65 − n
1 64 = 65 65 Therefore, the upper bound of S is about 98%. To provide a lower bound of S, we need to consider how M may reduce the impact of RRFD on his attack. To maximize the impact of the attack to counter RRFD, M will stop sending RREQs for at least one RDC after a successful RDC. This ensures that the number of RDCs that M has to wait before initiating another successful RDC will be 1. nx 1 S min = 1 − = 2nx 2 Since M will not send any RREQ at least for one RDC after a RDC has ended, the lower bound of S is at least 50%. Therefore, we have proven that RRFD is at least 50% effective against a breadth-RRFA. Similarly, to find out the success of RRFD against depth-RRFA, we assume that M broadcasts y RREQs per RDC with each RREQ spaced equally apart and x is the number of RREQs sent in a RDC. We then define Sn as: S max = lim S n = 1 − n →∞
Sn = 1−
nx n
ny + ∑ min(2 i −1 ,64) * y i =1
This equation is the same as the equation in the breadth-RRFA analysis except that the number of RREQ transmitted in a RDC is y instead of x. For values of n ≥7, nx x Sn =1 − =1− 321 (n + 1 + 2 + 4 + 8 + 16 + 32 + 64 + (n − 7)64) y (65 − )y n S max = lim S n = 1 n →∞ , y →∞
When y is much larger than x, RRFD is very effective against RRFA and the success rate approaches 100%. To maximize the number of RREQs forwarded by A, M will stop sending RREQs for at least one RDC after a RDC. Therefore, nx x Sn = 1− = 1− 2ny 2y In a depth-RRFA, y will be at least equal to x. Therefore, the lower bound of S is 50%. If y is much larger than x, then S min = lim S n = 1 y →∞
Therefore, RRFD is very effective against depth-RRFA as the success rate can approach 100% if the attacker is very aggressive in sending large number of RREQs.
5 Simulation Results To determine the effectiveness of RRFD against depth-RRFA and breadth-RRFA, we simulated various scenarios of 100 nodes randomly placed in a 1600m×1600m area. The nodes use the random waypoint mobility model with speeds 0~20m/s and pause time of 10 secs. Constant Bit Rate (CBR) data sources are used with a rate of 2 pkts/sec and 512 bytes/pkt. The MAC layer used is based on the IEEE 802.11 with data rate of 2Mbps. For comparison, we evaluated RRFD and RREQ-Rate-Limit subject to breadthRRFA and depth-RRFA by one malicious node which is not restricted in the number of RREQs it can originate. In RREQ-Rate-Limit, a node will transmit at most n RREQs per second (we set n = 10 in our simulations). Each set of simulations is run for 5min each, and repeated using 5 different scenarios. The packet delivery ratio (PDR) measures the number of successfully delivered data packets against the total number sent. The routing overhead includes all the routing control packets, namely, RREQs, RREPs and RERRs. The average end-to-end delay is the average time taken for data packets to travel from source to destination.
Breadth-RRFA Analysis
5.1
4.5E+07
80%
4.0E+07
70%
3.5E+07
60%
3.0E+07
50%
2.5E+07
40% 30%
Normal AODV
20%
RREQ-Rate-Limit
10%
RRFD
0%
2.5 Normal AODV RREQ-Rate-Limit RRFD
2
2.0E+07 1.5E+07
1.5
1.0E+07 5.0E+06
1
0.0E+00
0
20 40 60 80 100 120 140 160 180 200 Number of unreachable destinations
Packet Delivery Ratio
Normal AODV RREQ-Rate-Limit RRFD
T im e (s)
90%
By tes
Percentage
First, we investigate the impact of breadth-RRFA by one malicious node on the network performance. A total of 20 valid random connections are made from any source to destination, excluding the malicious node. In each simulation, the number of unreachable destinations varies from 0 to 200. The results in Fig. 3 show that both RRFD and RREQ-Rate-Limit outperform normal AODV with increasing number of forged RREQs. However, when there is no RRFA, using RRFD results in a loss of about 10% of the data packets. This is the result of genuine RREQs being dropped due to fast link breakages on some routes. The routing overhead is greatly reduced when RRFD and RREQ-Rate-Limit is used. RREQ-Rate-Limit performs better than RRFD in terms of the routing overhead in most cases as RREQ-Rate-Limit places an upper limit on the number RREQs being retransmitted while RRFD allows more RREQs to be retransmitted when the number of unreachable destinations increases. Nevertheless, RRFD still outperforms the normal AODV in terms of PDR and has lower routing overhead as the number of unreachable destinations increases. In all cases, the end-to-end delays for RREQ-RateLimit and RRFD are lower as compared to the normal AODV.
0
20 40 60 80 100 120 140 160 180 200 Number of unreachable destinations
Routing Overhead
0
20
40 60 80 100 120 140 160 180 200 Number of unreachable destinations
End-to-End Delay
Fig. 3. Comparison of RRFD and RREQ-Rate-Limit against normal AODV in breadth-RRFA
5.2
Depth-RRFA Analysis
Next, we will investigate the impact of depth-RRFA from one malicious node. A total of 20 valid random connections are made from any source to destination, excluding the malicious node. In each simulation, the number of RREQs sent per second from the malicious node varies from 0 to 12. The results in Fig. 4 show that RRFD performs much better than RREQ-Rate-Limit and normal AODV. The PDR remains consistently above 70% despite the transmission of more forged RREQs, while the performance of normal AODV and RREQRate-Limit decreases with increasing forged RREQs. When there is no RRFA, using RRFD results in a loss of about 10% of the data packets, as in the previous case. For RRFD, the routing overhead incurred is significantly lower than RREQ-Rate-Limit as RRFD ensures that the surrounding nodes drop forged RREQs from the malicious node while RREQ-Rate-Limit will continue to rebroadcast them until the limit of 10 RREQs per second is reached. In most cases, the end-to-end delay experienced when
90%
4.0E+07
80%
3.5E+07
70%
3.0E+07
60%
3 Normal AODV RREQ-Rate-Limit RRFD
RRFD
Normal AODV
30%
RREQ-Rate-Limit
2.0E+07 1.5E+07
2 1.5
1.0E+07
RRFD
20%
T im e (s)
40%
Normal AODV RREQ-Rate-Limit
2.5
2.5E+07
50%
By tes
Percen tag e
using RRFD is also significantly lower than RREQ-Rate-Limit and normal AODV. Depth-RRFA can be considered to be more critical as typical methods like address filtering is not effective against it. Hence, there is a need for better protection against depth-RRFA, which RRFD can provide.
1
5.0E+06
10%
0.5
0.0E+00
0% 0
2 4 6 8 10 Number of RREQ per second
0
12
Packet Delivery Ratio
2 4 6 8 10 Number of RREQ per second
12
0
Routing Overhead
2 4 6 8 10 Number of RREQ per second
12
End-to-End Delay
Fig. 4. Comparison of RRFD and RREQ Rate Limit against normal AODV in a depth-RRFA
Increasing Good Throughput
5.3
The simulations in Section 5.1 and Section 5.2 do not include any data flow from the malicious node. It is desirable that valid data communications from the malicious node is allowed to continue so that it may receive information from other nodes if it is a compromised node. For example, if the node is infected by a Trojan horse, virus or a worm, it is desirable that the victim can obtain patches or warning messages from other nodes in order to recover from the compromised status. Using depth-RRFA, we aim to determine whether RRFD or RREQ-Rate-Limit is more effective in allowing malicious nodes to send genuine RREQs while dropping forged RREQs originating from the malicious nodes. In each simulation, the number of forged RREQs sent per second from the malicious node varies from 0 to 20. The results in Fig. 5 show that RRFD is better than RREQ-Rate-Limit when the number of forged RREQs sent increases. For RRFD, the PDR remains constant despite an increase in the number of forged RREQs in the network. However, when there is no RRFA, using RRFD results in a loss of about 4% of the data packets. RRFD outperforms RREQ-Rate-Limit with lower routing overheads and end-to-end delays. 80%
2.0E+07
70%
1.8E+07
2
1.6E+07
60%
1.4E+07
50%
1.8
40% 30%
RREQ-Rate-Limit
1.0E+07
RRFD
1.6
RREQ-Rate-Limit
8.0E+06 RRFD
6.0E+06
20%
T im e (s)
1.2E+07 Bytes
Percen tag e
2.2
4.0E+06
10%
RREQ-Rate-Limit
1.4
RRFD
1.2
2.0E+06
1
0.0E+00
0% 0
5 10 15 Number of RREQ per second
Packet Delivery Ratio
20
0
5 10 15 Number of RREQ per second
Routing Overhead
Fig. 5. RRFD vs RREQ-Rate-Limit in depth-RRFA
20
0
5 10 15 Number of RREQ per second
End-to-End Delay
20
6 Conclusion In this paper, we have presented an effective mechanism, the RRFD, to mitigate the effect of denial-of-service attacks from malicious nodes by flooding the network with RREQs to unreachable destinations. Although RREQ-Rate-Limit performs better than RRFD in breadth-RRFA, RRFD outperforms RREQ-Rate-Limit in depth-RRFA and allowing the victim node to communicate with other nodes. Breadth-RRFA is not as critical as depth-RRFA as it can be easily mitigated by schemes like address filtering. As the simulation time used in the current study is rather short (only 5 minutes), we believe that RRFD will perform even better as time increases because more forged RREQs will be dropped. In terms of scalability, RRFD works well regardless of the size of the network since the total number of RREQs in the network is not restricted while the effectiveness of RREQ-Rate-Limit will depend greatly on the size of the network since each node is allowed only to transmit a fixed number of RREQs.
References 1.
C. Perkins, E. Belding-Royer and S. Das, “Ad hoc On-Demand Distance Vector (AODV) Routing”, RFC3561, July 2003 2. M. Hollick, J. Schmitt, C. Seipl and R. Steinmetz, “On the Effect of Node Misbehavior in Ad Hoc Networks”, Proceedings of the IEEE International Conference on Communications, pages 3759-3763, June 2004 3. L. Buttyán and J.-P. Hubaux, “Report on a Working Session on Security in Wireless Ad Hoc Networks“, ACM SIGMOBILE Mobile Computing and Communications Review, Vol. 7, Issue 1, pages 74-94, January 2003 4. P. Ning and K. Sun, “How to Misuse AODV: A Case Study of Insider Attacks against Mobile Ad-hoc Routing Protocols”, Proceedings of the 2003 Annual IEEE Information Assurance Workshop, pages 60-67, June 2003 5. W. Wang, Y. Lu and B. Bhargava, “On Security Study of Two Distance Vector Routing Protocols for Mobile Ad Hoc Networks”, Proceedings of the First IEEE International Conference on Pervasive Computing and Communications, pages 179-186, March 2003 6. M. G. Zapata and N. Asokan, “Securing Ad hoc Routing Protocols”, Proceedings of the ACM Workshop on Wireless Security (WiSe 2002), pages 1-10, September 2002 7. Y. Huang and W. Lee, “A Cooperative Intrusion Detection System for Ad Hoc Networks”, Proceedings of the 1st ACM Workshop on Security of Ad Hoc and Sensor Networks, pages 135-147, October 2003 8. A. Mishra, K. Nadkarni and A. Patcha, “Intrusion Detection in Wireless Ad Hoc Networks”, IEEE Wireless Communications, Vol. 11, Issue 1, pages 48-60, February 2004 9. G. Vigna, S. Gwalani, K. Srinivasan, E. M. Belding-Royer and R. A. Kemmerer, “An Intrusion Detection Tool for AODV-based Ad hoc Wireless Networks”, Proceedings of the 20th Annual Computer Security Applications Conference, December 2004 10. Y. Hu, A. Perrig and D. B. Johnson, “Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks”, Proceedings of the 8th Annual International Conference on Mobile Computing and Networking (MobiCom 2002), pages 12-23, September 2002 11. S. Desilva and R.V. Boppana, “Mitigating Malicious Control Packet Floods in Ad Hoc Networks”, Proceedings of 2005 IEEE Wireless Communications and Networking Conference (WCNC), pages 2112-2117, March 2005 12. P. Yi, Z. Dai, Y. Zhong and S. Zhang, “Resisting Flooding Attacks in Ad Hoc Networks”, Proceedings of International Conference on Information Technology: Coding and Computing (ITCC’05), pages 657-662, April 2005
