Chapter 3: Proposed Methodology

3.1 Background…………………………………………………………………………45
3.2 AODV Routing Attacks…………………………………………………………….46
3.2.1 Misuse Goals……………………………………………………………….46
3.2.2 Attacks………………………………………………………………………47
3.3 AODV Algorithm…………………………………………………………………...50
3.3.1 Path Discovery...……………………………………………………………52
3.3.2 Route Table Management…..……………………………………………….52
3.3.3 Path Maintenance…………………………………………………………...53
3.3.4 Local Connectivity Management...…………………………………………53
3.4 AODV Working …………………………………………………………………….54
3.5 Secure AODV (SAODV): Design Enhancement in AODV………………………...57
3.5.1 Packet Format……………………………………………………………….57
3.5.2 Algorithm…………………………………………………………………...59
3.6 Working of SAODV…………………………………………………………………64
3.7 Conclusion …………………………………………………………………………..66

3.1 Background
Ad hoc On-Demand Distance Vector (AODV) Routing is a popular routing protocol used in
mobile ad hoc networks (MANETs) and other wireless ad hoc networks. It was the joint
venture of Nokia Research Center, University of California, Santa Barbara and University of
Cincinnati by C. Perkins, E. Belding-Royer and S. Das [57]. The Ad-Hoc On-Demand
Distance Vector routing protocol is also available in RFC 3561[60]. The concept of AODV,
like all other reactive protocols, is based on topology information that is only transmitted by
nodes on-demand. Whenever, a node wants to send traffic to a destination, to which there is
no path, it will firstly send RREQ message to its entire neighbours. This process continues till
RREQ reaches to destination node. Therefore, to initiate such communication, an initial delay
occurs. When RREQ message gets in touch with the destination, or, an intermediate node
makes a valid route entry towards the destination, a path will be established. For as long as
this path remains active between two nodes, AODV stays in passive mode. Whenever the
path is broken or lost, again RREQ message will issue with the use of AODV protocol.
During establishment and maintenance of an ad hoc network, the Ad Hoc On-Demand

45
Distance Vector (AODV) protocol permits self starting, dynamic, multihop routing between
participating mobile nodes [131].

AODV lets mobile nodes to establish path rapidly for fresh destination and do not
allow nodes to keep routes to destinations that are not in use. As in [60, 132], AODV routing
protocol comes under reactive routing protocol category, therefore routes can be established
only when required. To discover and observe paths to neighbours, a node sends hello
messages and afterwards each node broadcasts a hello message periodically to all its
neighbours. If a node does not receive hello messages from a neighbour two or more times, a
link will be declared broken. After receiving RREQ message, each intermediate node creates
a route to the source. If the RREQ message is received by destination node, it sends RREP
message in unicast manner using hop by hop fashion towards the source. After receiving a
RREP message, each intermediate node creates a route to the destination. When RREP
message is received by the source node, it maintains the route to the destination and start
sending data. If more than one RREP messages are received by the source, the path with the
shortest hop count will be chosen. Wormhole attacker takes the benefit of this concept and
creates a wormhole link with the help of two malicious nodes or legitimate nodes nearer to
source and destination nodes.

3.2 AODV Routing Attacks

AODV gives lots of chances to attackers. There are a number of misuse objectives that an
inside attacker may desire to attain [59].

3.2.1 Misuse Goals

The misuse goals can be one or more of the following:

Route Disruption: In this, attacker involves in trying to break down an existing link or
stopping a new path from being set up. The aim is to target only route between two
endpoints.

46
Route Invasion: In this, an insider attack includes himself as a part of a route between
source and destination points of communication channel.

Node Isolation: In this, an attacker separates a particular node from network and prevent
node to participate in communication process with other nodes in the network. The aim is to
target all possible routes.

Resource Consumption: In this, an attacker tries to consume available bandwidth in the

network and storage space available at every node to disrupt transmission process. For
example, an inside attacker may consume the network bandwidth by flooding bogus
messages in the network.

Denial of Service: In this, an attacker tries to stop legitimate nodes to utilize part of
network or whole network connection. Denial of service can be broadened itself to all layers
of protocol stack. They can attack on legitimate users' access to a service provider or service
availability [133].

3.2.2 Attacks

To achieve these goals that are described in previous section, the following misuse actions or
attacks may be performed:

Packet Dropping Attack

In a packet dropping attack, the received routing messages are simply dropped by the
attacker. This can be detected by monitoring whether a neighbor node is broadcasting packets
towards final destination or not. To enable the monitoring of neighbour nodes, it is required
to keep neighbor table. This attack is available in different forms. Various subcategories are
as follows:

If an attacker wants to apply packet dropping attack [134] on the RREQ messages it
receives, RREQ messages can also be selectively dropped by an inside attacker. Such types
of misuses by attackers are similar in nature to the selfish nodes. If an attacker concerns on

47
applying this attack on RREP messages, it can be the case of route disruption. This attack can
also apply on other data packet and will prevent affected node from taking data packets from
neighbouring nodes for a small period of time. After receiving RREQ message, an attacker
can make modifications like to increase RREQ ID, to change the destination IP address with
other IP address, to add the source sequence number by one, to put non-existent IP address in
place of source IP address. After doing this, fake message can be forwarded by an attacker.

When all neighbours of an attacker get the fake RREQ message, they modify the next
hop of the source node to the non-existent node because faked RREQ message have a larger
source sequence number. Because of non-existent destination IP address, the fake message
will travel to the extreme nodes in the ad hoc network. Whenever any node requires sending
data packets towards the source node, they will follow route created using the fake RREQ
message. Due to non-existent node, data packets may be dropped. With the help of local
repair mechanisms in the AODV protocol, this attack cannot totally separate the victim node.
Whenever a node observes unsuccessful delivery of data packets, nodes will again start route
discovery process.

Sequence Number Attack

The freshness of route coupled with a node will be indicated by using sequence number. If an
attacker transmits an AODV control packet with a large sequence number of the
compromised node, the route will be directed towards compromised node. The sequence
number may be reduced to restrain updating in the table or increased to renew other nodes'
reverse route tables. This attack can also be apply on both either Source Sequence Number or
the Destination Sequence Number. A RREQ message can be uniquely identified by RREQ ID
along with the source IP address. The combination of this shows the freshness of a RREQ
message. At any time, a node only considers the first copy of a RREQ message. If another
node accepts the increased RREQ ID along with source IP address, that means node will
accept faked RREQ message. Sequence number attack can only consider sequence number
field, available in RREQ message [135].

48
Field Modification Attack

As it is known that data packet will be sent with the header. In layering process, data packets
go through different layers and add headers accordingly. The field modification attack [129,
136] is responsible for changing the field values in header at network layer. As above,
sequence number attack is modifying sequence number field therefore it can be said that
sequence number attack is a part of field modification attack. The other fields that an attacker
can modify are highlighted below. The table given below will show impact of changed field
during normal routing process.

RREQ Message Field Modifications

RREQ ID To make faked RREQ message acceptable or unacceptable,
attacker increases or decrease RREQ ID.
Type Message type will be changed.
Hop Count To invalidate the update, hop count will be decreased or
increased to update other nodes' reverse routing tables.
Destination IP Address Replace with another IP address
Source IP Address Replace with another IP address to change the reverse route

Table3.1: Field Modification Attack on RREQ Message Field

When several fields have been modified by attacker, it shows immediate security
repercussions in the network. For ensuring loop freedom in AODV, a node after receiving
RREQ message modifies its reverse routing table. This modification occurs only if source
sequence number is greater than the value in its routing table or source sequence number is
equal but hop count value is smaller than that in the routing table for RREQ message. To
affect other node’s routing table, an inside attacker can also involve in changing these fields.
Same procedure will be used for a RREP message. In this, if the destination sequence number
in RREP message is greater than the value one in its routing table or destination sequence
number is the same but the hop count plus one is smaller than the value in routing table, a
source node or an intermediate node modifies its forward routing table. Now take attacker
point of view, if the destination sequence number in the RREP message is greater than the
one in its routing table, or the destination sequence numbers are the same, but the hop count
in the RREP message plus one is smaller than the one in its routing table, the attacker can
contain the legitimate RREP message by increasing the destination sequence number.

49
Field Addition Attack

In this attack, an attacker can build a RREQ message without receiving an RREQ message.
For launching this attack, there is a need to collect some basic information to build faked
RREQ messages (e.g., by listening to the traffic). In theory, to cause disruption in routing
process, the attacker may add any field in a RREQ message [59, 138].

3.3 AODV Algorithm

In this section, AODV algorithm is presented in brief. The ad hoc on demand distance vector
(AODV) routing algorithm [57, 60] is an on demand algorithm, intended for ad hoc mobile
networks. It is suitable for both multicast and unicast routing. Here on demand means that it
helps in building routes when source node wants to communicate with destination node or
target node. These routes will be maintained so long as they are required by the source. To
guarantee the freshness of route, the sequence number is used by AODV. With the help of
route request/route reply cycle, AODV builds routes. Whenever a source node wants to
communicate with destination node for which no route is existed, it broadcasts a route request
packet to all its neighbours. This process continues till route request packet reaches up to
destination node. After receiving route request packet, each node updates information for the
source node and establishes backward routes to the source node in the route tables.

RREQ packet contains source node’s IP address, current sequence number, broadcast
ID and most recent sequence number for the destination of which the initiator is aware. After
receiving RREQ packet, a node can send the route reply (RREP) packet only if it has either a
route to the destination with corresponding sequence number equal to or greater than that
contained in the RREQ or it is the destination node. At this point of time, RREP packet will
be unicasted back to the source. If any time error in transmission occurs, the RREQ packet
will be rebroadcasted. Each node maintains track of the broadcast ID and RREQ’s source IP
address. If any time nodes receive already processed RREQ packet, they reject the RREQ and
never forward it. Now, the RREP spreads back to the source and nodes will establish forward
pointers to the destination. After receiving a RREP packet by source node, source node will
start to send data packets to the destination. After this, if any point of time the source node
collects a RREP containing the same sequence number with smaller hop count or a greater
sequence number, it will update its routing table or the destination and start with the better

50
route. The route will be maintained as long as there are data packets to send from source to
destination.

If there are no data packets to send, the established route will be timed out and deleted
from routing tables of intermediate nodes. If route break takes place during transmission of
data packet, the node will propagate route error (RERR) packet to the source node to inform
about unreachable destination. After receiving the RERR, source node can reinitiate route
discovery process if there is any packet to send. This is the scenario for unicast route.
Multicast routes can also be established in a similar manner. These similar rules can be
applied for establishing multicast routes. Whenever, a node wants to connect a multicast
group, it broadcasts a RREQ with a destination IP address with appropriate field setting
Multicast and flag setting ‘J’ to indicate that it wants to join the group. Any node, which is
the member of the multicast group and has a sufficient sequence number, sends a RREP
packet. As the RREP packet circulates back to the originator node, the intermediate nodes
update pointers in their multicast route table. After receiving the RREPs, the source node
keeps follow of the route with the newest sequence number and minimum hop count to the
next multicast group member. Now, the source node unicasts a MACT (Multicast Activation)
message [139] to all selected next hop. This massage is sent to activate the route between
nodes.

If the intermediate nodes, which are part of the multicast group, do not obtain the
MACT message within required time, they remove pointer from their routing table. If nodes
which are not part of the multicast group receive MACT message, they will also keep track of
the RREPs message and unicast MACT to its entire next hops. This process continues till
message will reach to a node member of the multicast tree. AODV retains routes till the
route is active. This is requires to maintains multicast tree for the life of the multicast group
as the nodes in the network are mobile and during the lifetime of that route, many link
breakage can occur.

Therefore, the section is going to tell about the steps involved in AODV routing algorithm
below:-

Path Discovery
Forward Path Setup

51
 Reverse Path Setup
Route Table Management
Path Maintenance
Local Connectivity Management

3.3.1 Path Discovery

Done When No Information on Some Node to Which Communication Is Requested

Each Node Has Two Counters
Node sequence number
Broadcast ID
Path Discovery Process
Source Node broadcasts a Route Request (RREQ) Packet to its neighbors
Neighbors forward the Request to their neighbors, and so on until either the
Destination or an Intermediate Node with a “Fresh Enough” Route to the
Destination is located
broadcast_id is incremented for new RREQ
RREQ from same Node with same broadcast_id will not be broadcasted more
than once
RREQ generates Backward Path to Source
RREP generates Forward Path to Destination

3.3.2 Route Table Management

Route Request Expiration Timer

Cleans Reverse Paths that do not lie on Active Route
active_route_timeout
Is used to determine if Neighboring Node is Active i.e. Sends at least one packet
in this time
Route Cache Timer
Cleans Inactive Routes
Each Route Table Entry Contains
Destination
Next Hop

52
 Number of Hops
Sequence Number for the Destination
Active Neighbors for This Route
Expiration/Termination Time for the Route Table Entry
When a Route Entry is used to transmit data from Source to Destination, Timeout for
each entry is reset to Current Time + active_route_timeout
When a new Route is available, Route Table will be updated only if new route has
Larger dest_sequence_#
Or
identical dest_sequence_# but with lesser hop_cnt to the Destination

3.3.3 Path Maintenance

If Source Node travels during an Active Session

It can redo Path Discovery
If Destination or Intermediate Nodes travel
A particular RREP is sent to affected Source Node
On link breakage, affected node propagates an unsolicited
RREP < dest_sequence_#+1, ∞> to all active neighbors
Source may resurrect Route Discovery procedure

3.3.4 Local Connectivity Management

Two Approaches for a node to find its neighbors
Receiving transmit from its neighbors
Send its neighbors Hello Messages having its Identity and Sequence Number
o Sequence number is not changed for hello message
o Nodes cannot rebroadcast hello messages (TTL=1)
Local Connectivity is changed if
getting a Hello or a Broadcast from a New Node
Failing to Receive allowed_hello_loss Consecutive Hello Message from a Node
previously in the neighborhood
Neighbors only communicate when heard each other’s Hello Message
It ensures the Link is Bidirectional

53
3.4 AODV Working
Full form of AODV is Ad hoc On Demand Distance Vector routing. It is network layer
protocol. This protocol comes under the category of on demand routing protocols. This
protocol can be used even there is no paths available between sender and receiver. The
working of AODV is very simple. Because of its simplicity, this protocol is very popular and
many researches are going on. Various modified versions of AODV [91] are available in
literature. To understand these modified versions, it is necessary to know the working of
basic AODV.

Therefore to understand the working of AODV, an example is presented. In AODV

[60], when a source node A wants to send data for a destination node B, node A firstly find
out the availability of route in its cache table. If there is no route between node A and B, A
will transmit a RREQ message through all its neighbour nodes and intermediate nodes for B.
whenever any node between A to B receive RREQ message, the intermediate nodes will
rebroadcast the RREQ messages. This process will continue till RREQ reaches destination
node B. During the process every intermediate node checks if it is not the destination node,
whether there is a cached route to B, whether first time they are receiving RREQ, and the
value for TTL field is not equal to zero. Each node will also record the uniqueness of the one-
hop neighbours that will further broadcast the RREQ. Once the RREQ message reaches the
destination node B, B replies with a RREP message. Node A send RREQ in broadcast
manner while replying with RREP is a unicast manner.

Therefore, RREP message is unicasted to the one-hop neighbour of node B that has
forwarded the RREQ first. In the similar manner, the RREP will be unicasted back to the
source node A, using the recorded one-hop neighbours that originated the RREQ. In the
AODV route finding process, the path nodes do not fully aware of the path from the source to
the destination, including the source and the destination node. Because the review module
requires knowledge of personal security domain, the path can become be familiar with after it
established, as an auxiliary service. An example of the route discovery process outlined in
algorithm in section 3.3 is shown below –

54
 Node 3 wants to communicate with node 8

1 4 5 8

2 6 9

3 7 10

Figure3.1: Example of AODV in a MANET

In the figure 3.1 it is clear that there are ten mobile nodes in a network. Now, node 3 wants to
transmit data packets to node 8 with the use of AODV routing protocol. Now, Node 3 will
check the availability of route in its cache table. If there is no route between node 3 and 8,
node 3 will transmit a RREQ message through all its neighbour nodes and intermediate nodes
for node 8.

Node 3 floods RREQ packet

RREQ RREQ

1 RREQ RREQ 4 5 8
RREQ

RREQ

2 6 9
RREQ RREQ
RREQ

3 7 10

Figure3.2: Example of AODV in a MANET – Route Request

55
In the figure 3.2, node 3 is broadcasting the RREQ message to its one hop neighbours. After receiving
RREQ messages, neighbours will also further forward RREQ message. This process continues till
RREQ will reach to destination node. Sending RREQ message is a broadcast process.

Node 8 replies with RREP packet

RREQ RREQ
RREP RREP
1 RREQ 4 5 8
RREQ
RREQ
RREP

RREQ

2 6 9
RREP
RREQ RREQ
RREQ

3 7 10

Figure3.3: Example of AODV in a MANET – Route Reply

In the figure 3.3, after receiving RREQ by destination node 8, node 8 will send back reply with RREP
message to the source node 3. As before, this source node sends RREQ message in broadcast manner
while RREP message will be sent in unicast manner. Therefore, node 8 is replying back with RREP in
unicast manner to node 3.

During communication between source node and the destination node, three types of
control messages can be sent. These messages are given below:-

RREQ - A route request message (Source node initiate communication by

sending RREQ message)
RREP - A route reply message (after receiving RREQ, destination node reply
back RREP message)
RERR - A route error message (it is generated when any fault occurs during
transmission)

56
AODV uses the following fields with each route table entry in the AODV Routing Table:

Routing table of each node maintains

Next-Hop (Node Pointer)
Sequence number (Integer)
Hop Count (Integer)
Values updated on receipt of RREQ, RREP, or RRER
Partial order constraint.
Seq(A) < Seq(B) or
Seq(A) = Seq(B) ^ HopCount(A) > HopCount(B)
Intermediate node (B) either has a newer route to endpoint than the
start node, or it has a shorter route that is equally recent.
Destination IP Address
Other state and routing flags (e.g., valid, invalid, repairable, being repaired)
Network Interface
List of Precursors
Lifetime : Expiration or deletion time of the route
Active neighbor list : Neighbour nodes that are actively using this route entry
Request buffer : Makes sure that a request is only processed once

3.5 Secure AODV (SAODV): Design Enhancement in

AODV
The secure AODV is the extended version of AODV. The objective of SAODV is to provide
secure environment during transmission between source to destination. As AODV is mostly
used because of its speed of transmission but it does not provide security during transmission.
Therefore, there is a need of secure environment to send data packets between two nodes.
Researcher is presenting a protocol with adding security feature. This is called ‘Secure
AODV’.

3.5.1 Packet Format

In AODV, there are four types of packet formats available in literature [60]. Those are Route
Request (RREQ) Message Format, Route Reply (RREP) Message Format, Route Error

57
(RERR) Message Format and Route Reply Acknowledgement (RREP-ACK) Message
Format. Researcher is not going to elaborate on all types of packet format except Route
Request (RREQ) Message Format as it is modified to detect and prevent wormhole attack
during transmission process. In AODV, RREQ message format is used when sender node
wants to establish the path with destination node.

In response to RREQ, destination node use RREP message format to reply sender’s
RREQ. Apart from these two formats RREQ and RREP, RERR is used when any time link
break occurs during transmission. At this time, the destination node becomes unreachable
from one or more of the node’s neighbors. The Route Reply Acknowledgment (RREP-ACK)
message format is used in reaction to a RREP message with the ‘A’ bit set. This is done
whenever there is risk of unidirectional links preventing the completion of Route Discovery
Cycle. For SAODV, the modified RREQ message format is given below. In the modified
RREQ message format, all fields are same except Destination IP Address and Destination
Sequence Number. In place of destination IP address, researcher is using address for false
node that means address of nonexistent node in the network.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address for False Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
Figure3.4: Modified Route Request (RREQ) Message Format

The format of the Modified Route Request message is illustrated in figure3.4, and contains
the following fields:
Type 1
J Join flag; reserved for multicast.

58
 R Repair flag; reserved for multicast.
G Gratuitous RREP flag; indicates whether a
gratuitous RREP should be unicast to the
node specified in the Destination IP Address
field.
D Destination only flag; indicates only the
destination may respond to this RREQ.
U Unknown sequence number; indicates the
destination sequence number is unknown.
Reserved Sent as 0; ignored on reception.
Hop Count The number of hops from the Originator IP
Address to the node handling the request.
RREQ ID A sequence number uniquely identifying the
particular RREQ when taken in conjunction
with the originating node's IP address.
Destination IP Address for false node The IP address of the false destination node
for which a route is desired.
Destination Sequence Number The latest sequence number received in the
past by the originator for any route towards
the false destination.
Originator IP Address The IP address of the node which originated
the Route Request.
Originator Sequence Number The current sequence number to be used in the
route entry pointing towards the originator of
the route request.

3.5.2 Algorithm

In this section, the algorithm of SAODV is given. Steps are as under:-

Secure-AODV (SAODV) Protocol

Notations Used:
SN : Source Node
DN : Destination Node

59
IN : Intermediate Node
FN : False Node
RREQ : Route Request
RREP : Route Reply
Functions Used:
initiateRREQ() : Source node Initiates route establishment process by
sending initiateRREQ().
acceptRREQ() : intermediate node receiving acceptRREQ for
destination node.
createRouteEntry() : nods create or update the route entry in the routing table

validateRREQ() : check if node knows the route to FN

promoteRREQ() : Forwarding RREQ for FN
initiateRREP(DN) : Generating RREP by DN
promoteRREP(DN) : Forwarding RREP from DN
acceptRREP(DN) : Receiving RREP from DN
includeBlackListTable(DN) : Insert DN into BlackListTable
confirmBlackListTable(DN) : Check Values of DN in BlackListTable
hinderRoute(DN) : Disable Route for DN
Tables Used:
RoutingTable : Stores route entry for valid routes
BlackListTable : Stores entry of black-listed (Wormhole) nodes
Functions Description:
Source Node SN:
a. initiateRREQ(FN)
Step 1. CHECK IF no route exists
Step 2. THEN
Step 3. check request buffer for requests already sent for destination
Step 4. CHECK IF no request sent already
Step 5. THEN
Step 6. create a RREQ packet
Step 7. add values of destination address, broadcast ID to request
buffer
Step 8. locally broadcast RREQ
60
 Step 9. set timer for RREP_WAIT_TIME before rebroadcasting
RREQ
Step 10. increment broadcast ID
Step 11. ELSE
Step 12. buffer packet from stream or discard, according to need
Intermediate Node IN:
a. acceptRREQ (FN)
Step 1. CHECK IF source address, broadcast ID exists in request buffer
Step 2. THEN
Step 3. discard request -- already heard and processed
Step 4. ELSE
Step 5. add source address, broadcast ID to request buffer
Step 6. Call createRouteEntry(FN)
b. createRouteEntry(FN)
Step 1. CHECK IF no route to source address exists in RoutingTable
Step 2. THEN
Step 3. create a route entry in RoutingTable for source address
Step 4. ELSE CHECK IF source seqno in RREQ > source seqno in RoutingTable
Step 5. THEN
Step 6. update route entry in RoutingTable for source address
Step 7. ELSE CHECK IF source seqno in RREQ = source seqno in RoutingTable
AND hop count in RREQ < hop count in RoutingTable
Step 8. THEN
Step 9. update route entry in RoutingTable for source address
Step 10. Call promoteRREQ(FN)
c. validateRREQ(FN)
Step 1. CHECK IF current node is destination of RREQ
Step 2. THEN
Step 3. create a RREP packet
Step 4. unicast RREP to source of request
Step 5. ELSE CHECK IF exists route to destination AND
destination seqno in RoutingTable >= destination seqno in RREQ
Step 6. THEN
Step 7. create a RREP packet
61
 Step 8. unicast RREP to source of request
Step 9. ELSE
Step 10. Call promoteRREQ
d. promoteRREQ (FN)
Step 1. CHECK IF current node is destination of RREQ
Step 2. THEN
Step 3. create a RREQ packet
Step 4. copy all fields from received RREQ into new packet
Step 5. increment hop count field
Step 6. locally broadcast new RREQ packet
Step 7. discard received RREQ
Destination (Worm holeNode) DN:
a. initiateRREP(DN)
Step 1. create a RREP packet
Step 2. unicast RREP to source of request
Intermediate Node IN:
a. promoteRREP (DN)
Step 1. CHECK IF route to requested destination does not exist
Step 2. THEN
Step 3. create a route entry in RoutingTable for requested destination
Step 4. ELSE CHECK IF destination seqno in RREP >
destination seqno in RoutingTable
Step 5. THEN
Step 6. update route entry in RoutingTable for requested destination
Step 7. ELSE CHECK IF destination seqno in RREP =
destination seqno in RoutingTable
AND
hop count in RREP < hop count in
RoutingTable entry
Step 8. THEN
Step 9. update route entry for requested destination
Step 10. CHECK IF route to requesting source exists
Step 11. THEN
Step 12. Call promoteRREP (requesting source)
62
Source Node SN:
a. acceptRREP (DN)
Step 1. CHECK IF route to destination does not exist
Step 2. THEN
Step 3. create a route entry for destination
Step 4. ELSE CHECK IF destination seqno in RREP >
destination seqno in RoutingTable
Step 5. THEN
Step 6. Call BlackListTable(DN)
Step 7. ELSE CHECK IF destination seqno in RREP =
destination seqno in RoutingTable AND
hop count in RREP < hop count in entry
Step 8. THEN
Step 9. Call BlackListTable(DN)
Step 10. ELSE
Step 11. discard RREP
b. includeBlackListTable (DN)
Step 1. find insertion point in BlackListTable
Step 2. CHECK IF entry is already there in the precursors list
Step 3. THEN
Step 4. don't need to add another
Step 5. ELSE
Step 6. increment size of blacklistTable
Step 7. allocate memory for newNode
Step 8. assign address of Nn to newNode
Step 9. insert newNode in blacklistTable

Intermediate Node IN:

a. confirmBlackListTable (DN)
Step 1. search for destination address in blackListTable
Step 2. CHECK IF current address = destination address
Step 3. THEN
Step 4. Call hinderRoute (DN)
Step 5. return TRUE
63
 Step 6. ELSE
Step 7. return FALSE

b. hinderRoute (DN)
Step 1. set destination to DN
Step 2. empty the precursors table for the route
Step 3. set last hop count to hop count
Step 4. set destination hopCount to INFINITY
Step 5. set destination activated to FALSE
Step 6. set destination lifetime to DELETE_PERIOD
Step 7. increment destination sequence number
Step 8. check and set routeExpireHead and routeExpireTail to correct position
Therefore, the above given algorithm is suitable for detecting wormhole nodes present in the
data transmission process.

3.6 Working of SAODV

The full form of SAODV is Secure Ad hoc On Demand Distance Vector. It is the extension
of already available routing protocol AODV. It is based on the algorithm given in section
3.5.2. The aim of this protocol is to detect and prevent wormhole attack during transmission
between sender and destination nodes. Whenever, sender wants to communicate with any
node in the network, it will firstly send the Modified RREQ message that contains the IP
address of the false node, which is not present in the network, to the all its neighbors.

All neighbors checks whether they are destination nodes or not. If they are not
destination node, they forward this modified RREQ message to all its neighbors. If suppose
there is a wormhole tunnel during communication then the nodes creating tunnel will reply
that they have path towards the destination node. By this they will be trapped and prevented
to send packets in future. This can also be understood by the figure3.5 given below:-

64
 SOURCE NODE INTERMEDIATE NODE DESTINATION NODE

InitiateRREQ (FN) AcceptRREQ (FN)

CreateRouteEntry (FN)

ValidateRREQ (FN)

PromoteRREQ (FN) InitiateRREP (DN)

AcceptRREP (DN) PromoteRREP (DN)

IncludeBlackListTable (DN) ConfirmBlackListTable (DN)

HinderRoute (DN)

Figure3.5: Flow Chart showing Working of SAODV

In this protocol, Security is considered in two parts. Firstly, when communication

takes place within the network which is called local communication. Secondly, when two
nodes, that belongs to different networks are communicating. This is called as inter network
communication. When local communication is continuing, at that time source node broadcast
the RREQ packet which contains the IP address of false node. Now the message will be
received by the direct neighbours. They check their entries in the table if they are not
wormhole node than they will forward message to the next neighbour. If the malicious node
present in the network it will give immediate response to the source node by the intermediate
node. As it will give response, the source node catches it as a wormhole node and blocks the
wormhole node. After this, the source node sends information to the direct neighbour for
updating their entries.

65
 Here, the both type of security that means for local communication and for inter
network communication have implemented. Suppose, N1, N2, N3, ………., Nn-1 are the nodes
between the source N0 and the destination Nn in a network (it is considered, Ni and Nj are
wormhole nodes and making wormhole tunnel). The algorithm works as-

To detect wormhole node, origin N0 sends modified RREQ packet which contains the
address of the false node, to the nearest node N2. It will check its table for entry of false
node. If it is not in its table it will propagate this RREQ message to the intermediate nodes till
Ni node. As Ni node receives the RREQ message, it will reply that it has the shortest route to
destination false node through Nj node. Because of this declaration by Ni node, the whole
traffic will diverted through the Ni node and Nj node. Ni node and Nj node are connected with
each other through tunnel. Whenever, the Ni node declares against the modified RREQ packet
that it has shortest route to destination false node with the help of RREP packet, the Ni node
will be detected as wormhole node and prevented further involvement in communication.
After receiving RREP packet, N0 node will broadcast BLOCK (Ni, Nj)AODV packet
information to all other nodes in the network for Ni node and Nj node as wormhole nodes.
Each node other than Ni node and Nj node will update entries in their table.

The same procedure will be followed for inter network communication. Therefore,
from the above discussion it can be said that this algorithm may be helpful for detecting and
preventing wormhole node.

3.7 Conclusion
This chapter outlines about various types of routing attacks present in mobile ad hoc
networks. Out of all the available attacks, the wormhole attack is described in an explorative
manner. With the wormhole problem, solution that can protect MANETs is also given in the
form of algorithm. The proposed algorithm is based on the AODV algorithm. Therefore, the
already available AODV is described followed by the SAODV. The aim of the SAODV is to
detect and prevent wormhole attack during transmission in mobile ad hoc networks. In the
next chapter, implementation of SAODV is shown. It is shown that SAODV is compatible
for both the scenarios whether it is local communication or inter network communication.

66