SECURING AODV PROTOCOL

SUDARSHAN D 1, SHIVA AMRIT A1

SUMANTH K1, VAMSI KRISHNA B1
REVATHI VENKATARAMAN N1, PUSHPALATHA M1
1. DEPARTMENT OF COMPUTER SCIENCE ENGINEERING, SRM UNIVERSITY

AbstractAn adhoc network is infrastructure less and selfconfiguring providing mobility. This mobility comes with
restrictions, making the entire process of adhoc communication
complex. All the routing actions are performed in accordance
with protocols like AODV.The two major concerns relating to
adhoc networks are Security and overhead of routing table
maintenance. Securing data in all forms whether it the
communication data or data as a message is of primary
importance. This paper emphasizes on implementation of
message integrity and authentication to make AODV protocol
more reliable and efficient for communication. In this
implementation, the nodes are authenticated before a route is
established. The information generated during the authentication
is encrypted using AES algorithm for confidentiality and
subsequently hashed using MD-5 for integrity.
Keywordssecurity, manet, AODV, OpenSSL, Diffie-Hellman,
encryption, decryption, hashing, MD-5, AES.

1. Introduction
Ad hoc networks are a temporary requirement based networks,
in which any node with a need for communication joins the
network which then uses other nodes as agents for forwarding
data packets it has generated. Since they are infrastructure less
networks, every node has a capability to move within the
range of the network and continue to have a seamless
communication. Every node maintains a Routing Table which
stores details of all the other nodes available for
communication. This is done with the help of Routing
Protocols like AODV.
Many of the implementations of this protocol are not secure.
Most of these ad-hoc routing protocols assume that there is an
implicit trust-your-neighbor relationship in which all the
neighboring nodes behave properly.
However, real MANETs are subject to attacks by malicious
users, who try to paralyze the network by manipulating the
messages. Adding security features like message integrity,
authentication of peer nodes will make this protocol more
reliable and efficient for communication.
The Key Exchange mechanism for secure transfer of public
keys is Diffie-Hellman. The public keys are used to generate
secret keys which are then used to encrypt packets using AES
encryption with OpenSSL [10] Tools.

2. Related works

There is a smaller amount of published prior work on the

security issues in adhoc network routing protocols. There are
some works on securing the routing protocols of the fixed
networks.
First based on a thesis by Perlman, a proposal of a link state
routing protocol that achieves Byzantine Robustness was
given. Although this protocol is highly efficient and will work
under many conditions, its requirements include a very high
overhead associated with public key encryption.
A work on providing secure routing protocols to ad hoc
networks was proposed earlier by Zhou and Haas.Their
method includes key management primarily. They entirely use
a section to secure routing but conclude that nodes can
protect routing information in the same way they protect data
traffic. They also propose that the denial-of-service attacks
on the routing would be treated as damage and consequently
routed around [7].
Some similar work has been done to secure ad hoc networks
by using a new parameter- misbehaviour detection
schemes.This approach has two main problems. First It wont
be able to detect all misbehaving schemes mentioned and the
new ones may be created. And second, it has no real means to
guarantee the integrity and authentication of the routing
messages [6].
Papadimitratos and Haas proposed a protocol (SRP) that can
be applied to many latest existing routing protocols.SRP
requires, for every route discovery, source and destination
must have a security association between them. Therefore,
they are not protected, and any malicious node can just forge
error messages with other nodes as source [5].
SAR protocol joins the trust level of a node and the security
Properties of a route to which would help in providing an
integrated security System for the route. A Vector called as
Quality of Protection (QoP) vector is used here. It can be
defined as a combination of security level and cryptographic
Methodologies. It uses the timestamps and the sequence
numbers which will then be used to stop the replay attacks.
Interception by other nodes and other threats can be prevented
by trust level key authentication. Attacks like modification can
be stopped by verifying the digital signatures of the each and
every transmitted packet. The major drawbacks of using SAR
are that it requires excess of encrypting and decrypting at each
hop available during the discovery of path. The discovered
route might not be the shortest route in the terms of hop-count,
but it is very well secured [1],[2].

2
Trusted Ad-hoc On-demand distance vector Routing
(TAODV) This is another way of Securing the AODV
Protocol.TAODV is secure routing protocol which uses
cryptography technologies and methodologies which are
recommended to take effect before nodes in the network
establish trust relationships among one another. The main
salient feature of TAODV is that it removes the reverification
of certificates which improves the efficiency and saves time.It
uses trust relationships among nodes, so there is no need for a
node to request and verify certificates all the time.
TAODV (Trusted AODV) has several important features:
a. Nodes perform trusted routing behaviours mainly according
to the trust relationships among them.
b. A node that performs malicious behaviours will eventually
be detected and denied or removed from the whole network.
c. The performance of system will be improved by avoiding
requesting ,verifying certificates at every routing step [3],[4].
Dahill et proposed ARAN, a routing protocol for ad hoc
networks that uses authentication and requires the use of a
trusted certificate server. In this ARAN, each and every node
that forwards a route discovery message or a route reply
message must also sign that message when transferring(which
is very computing power consuming and causes the size of the
routing messages to increase at each hop). In addition, it is
prone to reply attacks using error messages unless the nodes
have time synchronization [8].
Hash chains have been used as an efficient way to perform
authentication in several approaches that tried to secure the
routing protocols. They use the min order to provide delayed
key disclosure. Hash chains are mainly used to create one-time
signatures that can be verified immediately. The main
drawback of all the above approaches is that all of them
require clock synchronization [9].

3. Proposed methodology
In this section, we first provide a detailed description of the
flow and then we define and describe the key aspects of the
total process.
The first step involves the introduction of the term node. Node
with respect to this implementation will refer to a laptop on
which the protocol is implemented. Initially the nodes are
choreographed in an assumed topology. This topology can be
generic. The implementation uses an existing AODV protocol
which has been updated and tailored with respect to our
implementation for the Linux Kernel version 3.8. For ensuring
security, we use Diffie Hellman key Exchange along with
other hashing techniques.
The nodes have to be authenticated before a route can be
established between them The authentication is performed to
realize that the node is not an intruder. For this the HELLO
messages are exchanged between the nodes. These messages
contain the public key of corresponding nodes. Now each of
these nodes generates a secret key by using its own private
key. The secret keys generated must be matched upon which
the authentication is completed.

As this process is executed in parallel for the nodes once

authenticated, the nodes start sending RREQ packets. Even
these are secured. Hence these are encrypted using AES for
confidentiality. And for Integrity Hashing Technique MD-5 is
used.
After encrypting the request packet a hash value is generated.
Then the Packet is Encrypted using AES, this packet along
with the hash value is sent to the other node. The receiving
node decrypts the packet and performs hashing over the
decrypted packet. This hash value is compared to the received
hash value to check for integrity of data.
This reception is acknowledged using Reply packets which are
also secured. Before encrypting the reply packet a hash value
is generated. Then the packet is encrypted using AES.This
packet along with the hash value is sent to the other node. The
receiving node decrypts the packet and performs hashing over
the decrypted packet. This hash value is compared to the
received hash value to check for integrity of data. After this
acknowledgment the route is successfully established between
the nodes.
If two nodes are not in range, then an intermediate node can be
used to facilitate the transfer of these request and reply
messages between the Sender (Node A) and receiver nodes
(Node C). The sender node sends the Request packet along
with its public key, say Ka to the intermediate node (Node B)
by encrypting using the private key Ka-b which is shared
between the Sender node and the intermediate node. This
Encrypted message is decrypted by the Intermediate node by
using the Ka-b. Now the node encrypts it again using Kb-c the
private key shared between the intermediate and the receiver
nodes, and forwards to the Receiver.
The same path is used to send the Reply packet along with the
public key of the receiver node Kb to the Sender node where
the intermediate node is used for transfer.

4. Implementation
For the purpose of encryption, decryption and hashing we use
OpenSSL [10]. The AES algorithm is used for encryption
and MD-5 is used for Hashing installation of OpenSSL [10]
libcdev is the prerequisite for the process to take place.

4.1 Encryption Process

Two methods from the OpenSSL [10] package is used for
encryptions of the RREQ, RREP, RREP forward and RREQ
forward.
The
first
of
these
is
the
int
AES_set_encrypt_key(const unsigned char *userKey, const
int bits, AES_KEY *key).The second function is void
AES_cbc_encrypt(const unsigned char *in, unsigned char
*out,const unsigned long length, const AES_KEY
*key,unsigned char *ivec, const int enc).Post the encryption
process of say, the rreq packet, we will subject the resultant
output to hashing .

4.2 Hashing Process

Similar to the pre-requisite of encryption, to facilitate hashing,
OpenSSL must be installed. MD-5 length is selected as per the
requirement, for this implementation, we have used 128 bit
length unsigned char digest [SHA_DIGEST_LENGTH]. The

3
hashed value is stored in a string which is then encapsulated in
a structure along with the original encrypted message.

SAODV Implementation
Request Graph

4.3 Receiving End

At the receiving end the hash value of the encrypted message
is calculated and compared with the value in the received
message. If equality is found to be maintained then it
continues with the decryption process.

5. Performance Analysis
A series of experiments were conducted with two computers
acting as nodes. A third computer was used for monitoring
purposes. For the monitoring purpose, wireshark is used. The
distance between the two nodes is about 40 meters .The
experiments are done for a span of 10 minutes. The following
information is obtained.

Figure 3
Reply Graph

AODV Implementation
Request Graph

Figure 1

Figure 4

Reply Graph

These graphs represent the measurements for the first two

minutes of the experiment.
The average packets sent per second is found to be 3.203 for
route request and1.386 for reply.
The experimental results are presented in Table 2.

Figure 2
The average packets sent per second is found to be 4.178 for
route request and 1.202 for route reply.
The experimental results are presented in Table 1.

From the two tables we can infer that though there is not much
deviation in the performance parameters, the number of
packets sent in SAODV is slightly less when compared to
AODV . This is attributed to the extra processing required for
the encryption.

Traffic

Request

Reply

Traffic

Request

Reply

Packets

2421

681

Packets

1944

834

Avg Packets/sec

4.178

1.202

Avg Packets/sec

3.203

1.386

Avg Packet Size

122 bytes

118 bytes

Avg Packet Size

122 bytes

118 bytes

Avg Mbit/sec

0.004

0.001

Avg Mbit/sec

0.003

0.001

Table 1

Table 2

6. Conclusion
Initially it was thought that there would be performance
deviation in terms of time, size and other parameters, but from
the data collected, it can be concluded that there is negligible
difference in the parameters i.e., there is very less overhead
involved in the encryption and decryption process.

7. Acknowledgement
This work is funded in part by the Defence Research and
Development Organization under grant no:
ERIP/ER/1203090/M/01/1474.

8. References
Shilpa S G, Mrs. N.R. Sunitha, B.B. Amberker, A Trust
Model for Secure and QoS Routing in MANETS,
INTERNATIONAL JOURNAL OF INNOVATIVE
TECHNOLOGY & CREATIVE ENGINEERING
(ISSN:2045-8711) VOL.1 NO.5MAY 2011, pp 22-31.
2. Victor, C., Francisco, J., Pedro, M. 2009, Simulationbased Study of Common Issues in VANET Routing
Protocols. IEEE 69th Vehicular Technology Conference,
VTC2000.
3. R. S. Mangrulkar, Pallavi V Chavan and S. N. Dagadkar,
Improving Route Selection Mechanism using Trust
Factor in AODV Routing Protocol for MaNeT,
International Journal of Computer Applications (0975
8887) Volume 7 No.10, October 2010, pp 36-39.
4. Ming Yu, Mengchu Zhou, and Wei Su, A Secure
Routing Protocol against Byzantine Attacks for
MANETs in Adversarial Environments, IEEE
TRANSACTIONS ON VEHICULAR TECHNOLOGY,
VOL. 58, NO. 1, JANUARY 2009.
5. P.Papadimitratos and Z.J.Haas. Secure routing for mobile
adhoc networks. SCS Communication Networks and
Distributed Systems Modeling and Simulation
Conference (CNDS2002) , Jan2002.
6. S. Marti, T. J. Giuli, K. Lai, and M. Baker. Mitigating
routing misbehavior in mobile ad hoc networks. In
Proceedings of the 6th Annual International Conference
on Mobile Computing And Networking, pages 255265,
2000.
7. L. Zhou and Z. J. Haas. Securing ad hoc networks. IEEE
Network Magazine, 13(6):2430, November/December
1999.
8. B. Dahill, B. N. Levine, E. Royer, and C. Shields. A
secure routing protocol for ad hoc networks. Technical
Report UM-CS-2001-037, University of Massachusetts,
Department of Computer Science, Aug. 2001.
9. K. Zhang, Efficient protocols for signing routing
messages, in Proceedings of the Symposium on
Network and Distributed Systems Security (NDSS98),
July 2001
10. http://en.wikipedia.org/wiki/OpenSSL
1.