1. Centre for Wireless Communications University of Oulu, Finland
17/04/2017
Securing Ad Hoc Routing Protocols
Isameldin Suliman
Centre for Wireless Communications University of Oulu, Finland

2. 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

3. 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

4. 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

5. Ad Hoc Network Security Goals
Security is an important issue for ad hoc networks. The main goals of network security are:
Availability: Ensures the survivability of network services despite denial-of-service attacks
Confidentiality: Ensures that certain information is never disclosed to unauthorized entities
Integrity: Guarantees that a message being transferred is never corrupted
Authentication: Enables a node to ensure the identity of the peer node with which it is communicating
Non-repudiation: ensures that the origin of the message cannot deny having sent the message

6. Broadcast RREQ message
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
RREQ to their neighbors
The destination node sends a Route Reply
Message (RREP) back to the source node
An intermediate node may send a RREP provided
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 C D A S B
Broadcast RREQ message
RREP message

7. Routing Protocols Security Requirements
The paper considers the following security requirements:
Import autohrization: Only authorize route information if it concerns the node that is sending the information
Source authentication: Verify that the node is the one it claims to be
Integrity: routing information that is being sent has arrived unaltered
The source authentication and integrity combined build data authentication

8. Securing Ad Hoc Routing Protocols
There are two kinds of messages in ad hoc networks:
Routing Messages: Used for protocol signaling and sent to immediate neighbors, processed, possibly modified, and resent.
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

9. Security Flaws of AODV
AODV protocol is vulnerable to the following kinds of attacks by a malicious node M:
Impersonate a node S by forging a RREQ with its address as the originator address
Reduce the hop count field when forwarding RREQ generated by S
Impersonate a node D by forging a RREP with its address as a destination address
Selectively, not forward certain RREQs and RREPs, not reply certain RREPs, and not forward certain data messages
Forge a RERR messages pretending it is the node S and send it to its neighbor D
Set the sequence number of a node to a much bigger number.

10. 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.

11. SAODV Hash Chains
Generates a random number (seed)
Set the Max_Hop_Count field to the Time_To_Live value
Set the Hash field to the hash value
Set the Hash_Function field to the hash function identifier
Calculates Top_Hash by hashing seed Max_Hop_count times
Start
Stop
SAODV hash chains uses hash chains to authenticate the hop count field of RREQ and RREP messages
A hash chain is formed by applying a one-way hash function (e.g. MD5) repeatedly to a seed
When receiving RREQ and RREP messages, a node perform the following
Apply the hash function to verify the value contained in the Top Hash field
Before re-broadcasting RREQ or
forwarding RREP, apply the hash function
to hash the value in the signature
extension to account for the new hop
Type Length Hash Function Max Hop Count
Top Hash
Signature
Hash
RREQ (Single) Signature Extension

12. 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:

13. 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

14. SAODV Digital Signature (3)
Original information of the route is signed by the final destination and the lifetime is signed by the intermediate node
This leads to two different
SAODV extensions: single and
double signature extensions
When a node receives a RREP/
RREQ, it first verify the signature
before creating or updating a
route/ reverse route to the host
Type Length Hash Function Max Hop Count
Top Hash
Signature
Hash
RREQ Single Signature Extension
R A Reserved Prefix size
Signature for RREP
RREQ Double Signature Extension

15. 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

16. 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)

17. 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

18. 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

19. 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

20. 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