Securing AODV Routing Protocolin Mobile Ad-hoc Networks
Phung Huu Phu, Myeongjae Yi, and Myung-Kyun Kim
Network-based Automation Research Center andSchool of Computer Engineering and Information Technology
University of Ulsan, Ulsan Metropolitan City, 680-749, Republic of Korea
Seventh Annual International Working Conference on Active and Programmable Networks November 21-23 2005CICA, Sophia Antipolis, French Riviera, La Cote d'Azur, FRANCE
Network-based Automation Research Center
Slide 2
Contents
Motivation and Goals
The proposed security schema
Security analysis
Conclusions and future work
Slide 3
Motivations
The AODV routing protocol is under consideration by
IETF for MANET routing protocol standardization
Security aspects for AODV also have been studied in
other researches
Based on unrealistic assumptions about the availability of key
management infrastructures
=> Alternative solutions more suitable to ad hoc
networks are needed
Slide 4
Goals
Consider two related works: ARAN and SAODV
These schemas do not consider intermediate
nodes during the routing steps
nodes may perform fabrication attacks.
The goal: design a schema which performs
point-to-point message authentication without a
deployed key management infrastructure
Slide 5
The proposed security schema (1/4)
Principle:
messages in AODV must be authenticated to guarantee the
integrity and non-repudiation
Each node maintains table for security info; a record
contains:
neighbor address, neighbor public key, and a shared secret key
The authentication is executed by checking hashed
message which is hashed by the shared key
Slide 6
The proposed security schema (2/4)
Key agreement process
1. Broadcast : <AGREEMENT_REQ, request_id,sender_addr,eS>
2. For each received message
3. If message_type=AGREEMENT_REQ
4. send <AGREEMENT_REP, request_id, sender_addr, neighbor_addr,eR>
5. ElseIf message_type=AGREEMENT_REP
6. generate a shared key Ks;
7. send <KEY_OFFER, encrypt (Ks)>
8. ElseIf message_type= KEY_OFFER
9. decrypte to get the shared key Ks;
10. End if;
11. End for;
eS and eR are the public key of the sender node and replying node
eR
Slide 7
The proposed security schema (3/4)
Route request
Hased value = hashKs(RREQ) the hashed value of RREQ message by the shared key Ks between the two nodes.
Ik D
Slide 8
The proposed security schema (4/4)
Route reply and route maintenance
Route replies (RREP) in AODV also need to be authenticated; the
request and reply for authentication:
• <AUTHEN_RREP_REQ, dest_addr,dest_seq_#>;
• <AUTHEN_RREP_REP, dest_addr, dest_seq_#, hashKs(RREP)>
Authentication for route error report message (RERR)
• <AUTHEN_RERR_REQ,unreachable_dest_addr,
unreachable_dest_seq_#>;
• <AUTHEN_RERR_REP, unreachable_dest_addr,
unreachable_dest_seq_#, hashKs(RERR)>
Slide 9
Security analysis (1/2)
The proposed schema is a new fully distributed
authentication process
does not require any third parties
provides the integrity and non-repudiation of messages
The schema uses point-to-point authentication process
can authenticate intermediate nodes in routing steps
does not require a certificate server (like ARAN) or assumption of
key distribution (SAODV).
Slide 10
Security analysis (2/2)
By supplying integrity of exchanging messages, our
schema can prevent against attacks
A malicious node can not forms loops by spoofing nodes
can prevent falsified error messages or modification attacks
during route discovery process
However,
The end-to-end authentication process has not been considered
yet
Slide 11
Conclusions
A security schema for AODV has been proposed to prevent common kinds of attacks and compensate for the security flaws of recent related works
Exchanging messages in AODV are required to be authenticated in point-to-point step by using hash chains during a transaction
Shortcomings
Some kinds of attacks (tunneling attacks or selfishness problems) have
not been considered in this work
end-to-end authentication process has not been considered yet
Slide 12
Future work
The end-to-end authentication procedure will be
added to the current approach
Trust self-management in the schema will be
studied
The implementation and simulation of the
schema has been investigating on GloMoSim
simulation tool
Slide 13
Impersonate attacksImpersonate attacks A malicious node impersonates the source nodeA malicious node impersonates the source node A malicious node impersonates the destination A malicious node impersonates the destination
nodenodeForging a RREP with its address as a destination nodeForging a RREP with its address as a destination nodeAssociating with modifying sequence number with a Associating with modifying sequence number with a
big value big value
Impersonates the neighbor of destinationImpersonates the neighbor of destination A malicious node forms loops by spoofing nodesA malicious node forms loops by spoofing nodes
Modification attacksModification attacks
Modify hop count fieldModify hop count fieldReduce the hop count field in RREQ messagesReduce the hop count field in RREQ messages
The malicious node is included on a newly created The malicious node is included on a newly created routeroute
Modify destination_seq_# fieldModify destination_seq_# fieldafter re-broadcasting a RREQ, a malicious after re-broadcasting a RREQ, a malicious
node creates a falsified RREQ with increased node creates a falsified RREQ with increased destination_seq_# destination_seq_#
Falsifying Route ErrorsFalsifying Route Errors
A malicious node can falsifies a fabrication A malicious node can falsifies a fabrication route error messageroute error messageA malicious node M spoofs node B and send to A malicious node M spoofs node B and send to
node A (previous hop of B in a route to a node A (previous hop of B in a route to a destination) a error message indicating a destination) a error message indicating a broken link between node B and the destinationbroken link between node B and the destination
Node A delete the table entry for the Node A delete the table entry for the destination and forward the route error destination and forward the route error messagemessage
AB
S D
MFalsified RERR