Securing Ad Hoc Routing

Protocols

Isameldin Suliman
isam@ee.oulu.fi

Centre for Wireless Communications

University of Oulu, Finland
 Overview
• Introduction
• Research objectives
• Ad hoc network security goals
• Motivations
• Ad hoc On Demand Distance Vector (AODV) Routing
Protocol
• Routing protocols security requirements
• Security flaws of AODV
• SAODV hash chains
• SAODV digital signature
• Other routing protocols
• Key management
• Discussion
• Conclusion 2
 Research Objectives
• The main goal of the paper is to incorporate
security mechanisms into ad hoc networks
routing protocols
• Discuss whether the algorithms would be
applicable to other ad hoc routing protocols
• Present how the key management scheme could
be used in conjunction with the proposed
algorithms
• AODV is used as an example of ad hoc routing

3
 Motivations
• Routing in ad hoc networks has interesting
security problems
• Use of wireless links renders an ad hoc network
susceptible to link attacks
• Nodes roaming in a hostile environment, with
relatively poor physical protection, have non
negligible probability of being compromised
• There is very little published prior work on the
security issues in ad hoc routing protocols

4
 Ad Hoc Network Security Goals

• Security is an important issue for ad hoc

networks. The main goals of network security are:
1. Availability: Ensures the survivability of network services
despite denial-of-service attacks
2. Confidentiality: Ensures that certain information is never
disclosed to unauthorized entities
3. Integrity: Guarantees that a message being transferred is
never corrupted
4. Authentication: Enables a node to ensure the identity of
the peer node with which it is communicating
5. Non-repudiation: ensures that the origin of the message
cannot deny having sent the message
5
 AODV Routing Protocol
• A source node S wishes to communicate with destination
node D broadcast a Route Request (RREQ) to its neighbors
• Intermediate nodes forward the D Broadcast RREQ
message
C B
RREQ to their neighbors RREP message

• The destination node sends a Route Reply S

Message (RREP) back to the source node

• An intermediate node may send a RREP provided A
that it knows a ‘fresh enough’ route to the destination
• Nodes maintain routing table entries only for active routes,
unused routes are removed from the routing table after
active_route_timeout interval
6
 Routing Protocols Security Requirements
• The paper considers the following security
requirements:
1. Import autohrization: Only authorize route information
if it concerns the node that is sending the information
2. Source authentication: Verify that the node is the one it
claims to be
3. Integrity: routing information that is being sent has
arrived unaltered
4. The source authentication and integrity combined
build data authentication

7
 Securing Ad Hoc Routing Protocols
• There are two kinds of messages in ad hoc networks:
1. Routing Messages: Used for protocol signaling and sent
to immediate neighbors, processed, possibly modified, and
resent.
2. Data Messages: Point-to-pint and can be protected with
any point-to-point security mechanism (like IPSec).
• Intermediate nodes need to be able to authenticate
routing messages.
• Routing messages can be distinguished in two
types of information:
• Mutable
• Non-mutable
8
 Security Flaws of AODV
• AODV protocol is vulnerable to the following kinds
of attacks by a malicious node M:
1. Impersonate a node S by forging a RREQ with its address as the
originator address
2. Reduce the hop count field when forwarding RREQ generated by
S
3. Impersonate a node D by forging a RREP with its address as a
destination address
4. Selectively, not forward certain RREQs and RREPs, not reply
certain RREPs, and not forward certain data messages
5. Forge a RERR messages pretending it is the node S and send it to
its neighbor D
6. Set the sequence number of a node to a much bigger number.
9
 Securing AODV Protocol (SAODV)
• It is assumed that there is a key management sub-
system that makes it possible for each ad hoc node to
obtain public keys from the other nodes of the
network.
• Two mechanisms are used to secure the AODV
routing messages:
• Digital signatures: To authenticate non-mutable fields of the
messages
• Hash chain: To secure the hop count field in mutable messages
• The information relative to the hash chains and the
signature is transmitted as “Signature Extension” with
the AODV messages.
10
 SAODV Hash Chains Start

• SAODV hash chains uses hash chains to Generates a random number

(seed)

authenticate the hop count field of RREQ Set the Max_Hop_Count field

and RREP messages to the Time_To_Live value

Set the Hash field to the hash

• A hash chain is formed by applying a one- value

way hash function (e.g. MD5) repeatedly Set the Hash_Function field to
the hash function identifier

to a seed Calculates Top_Hash by hashing

seed Max_Hop_count times

• When receiving RREQ and RREP Stop

messages, a node perform the following

• Apply the hash function to verify the value
contained in the Top Hash field Type Length Hash Function Max Hop Count

• Before re-broadcasting RREQ or Top Hash

forwarding RREP, apply the hash function Signature

to hash the value in the signature Hash
extension to account for the new hop 11
RREQ (Single) Signature Extension
 SAODV Digital Signature (1)
• Digital signatures (DS) are used to protect the integrity
of non-mutable data in RREQ and RREP messages
• They sign every thing but the hop count of the AODV
message and the hash from SAODV extension
• The main problem in applying DS is that AODV
allows intermediate nodes to reply RREQ messages if
they have a route to the destination (i.e. intermediate nodes
should be able to sign the RREP on behalf of the final destination )
• To solve this problem, the paper offers two
alternatives:

12
 SAODV Digital Signature (2)
• The first solution is that if an intermediate node
cannot reply to a RREQ (because it cannot properly signs
its RREP), it just behave as if it didn’t have the route
and forwards the RREQ message
• The second one is that, a node generating a RREQ
message, includes the RREP flags, the prefix size,
and the signature that can be used to create RREP
• When an intermediate node generates a RREP, the
route life time will change from the original one
• The intermediate node should include both life
times and sign the new lifetime
13
 SAODV Digital Signature (3)
• Original information of the route is signed by the final
destination and the lifetime is signed by the intermediate
node Type Length Hash Function Max Hop Count

• This leads to two different Top Hash

SAODV extensions: single and Signature

Hash
double signature extensions RREQ Single Signature Extension

• When a node receives a RREP/ Type Length Hash Function Max Hop Count
RREQ, it first verify the signature R A Reserved Prefix size

before creating or updating a Top Hash

Signature
route/ reverse route to the host
Signature for RREP

Hash
14
RREQ Double Signature Extension
 SAODV Error Messages
• Route Error (RERR) messages are generated by a
neighbor node to other nodes informing that it is not
able to route messages to certain destination anymore
• Every node (generating or forwarding a RERR message) uses
digital signature to sign the whole message
• Any neighbors that receives the RERR verifies the
signature
• Verify that the sender of the RERR message is really
the one that it claims to be

15
 Other Routing Protocols
• In principle SAODV could be used to create “secure
version” of other routing protocols
• If the routing protocol has some other mutable information,
intermediate nodes that mutate part of the messages also
have to sign it.
• Dynamic Source Routing (DSR) has been used as an
example for other routing protocols
• DSR includes in its routing message the IP addresses of all
intermediate nodes
• Signing the message by each intermediate nodes reduces the
routing pereformance (due to additional cryptographic
computations)
16
 Key Management
• It is assumed that each node has a trustworthy means of
checking the association between the addresses and
signatures of other nodes
• This association (binding) is typically achieved by
using public key certificates issued by a certification
authority (CA)
• This can work if ad hoc nodes could have permanent
addresses
• One secure and potentially expensive solution would
be to pick a key pair, and map the public key to a
tentative address . If there is a collision, pick a new key
pair and try again 17
 Discussion (1)
• Ad hoc networks are inherently vulnerable so security
attacks and need security mechanisms
• The paper relies on public key management. It is not
realistic to assume that nodes in ad hoc networks will
have access to public key infrastructure to obtain public
key certificates
• Distribution of certificates by CA implies huge
overhead, and it is not effective in the presence of
partitions and high mobility
• The hash chain algorithm only addresses single mutable
information (hop count), it would be more complex if
more mutable information is to be addressed 18
 Discussion (2)

• The authors reported that SAODV cannot detect

tunneling attacks
• More work is needed to apply the proposed
security algoritms to other ad hoc routing
protocols
• Th use of asymmetric cryptography adds more
overhead to the processing power requirements of
the SAODV

19
 Conclusion
• The paper presents two security mechanism for
protecting ad hoc routing protocols (AODV in
particular)
• The proposed algorithms do not require modification to
the AODV protocol, they are added as an extension to
the existing AODV message formats
• An effective mechanism is needed to address the
problem of key certificates distribution
• The paper tries to provide a general mechanism that
could be applied to different routing protocols.
However, it would more effectient to extend the
algorimths and define separate meachanisms for
different ad hoc routing protocols 20