Securing AODV Routing Protocol in Mobile Ad-hoc Networks Phung Huu Phu, Myeongjae Yi, and Myung-Kyun Kim Network-based Automation Research Center and School of Computer Engineering and Information Technology University of Ulsan, Ulsan Metropolitan

1
Securing AODV Routing Protocolin Mobile Ad-hoc
NetworksPhung Huu Phu, Myeongjae Yi, and
Myung-Kyun KimNetwork-based Automation Research
Center andSchool of Computer Engineering and
Information TechnologyUniversity of Ulsan, Ulsan
Metropolitan City, 680-749, Republic of Korea

• Seventh Annual International Working Conference
  on Active and Programmable Networks
• November 21-23 2005
• CICA, Sophia Antipolis, French Riviera, La Cote
  d'Azur, FRANCE

Network-based Automation Research Center
2
Contents

• Motivation and Goals
• The proposed security schema
• Security analysis
• Conclusions and future work

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
• gt Alternative solutions more suitable to ad hoc
  networks are needed

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

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

6
The proposed security schema (2/4)

• Key agreement process
• 1. Broadcast ltAGREEMENT_REQ, request_id,sender_a
  ddr,eSgt
• 2. For each received message
• 3. If message_typeAGREEMENT_REQ
• 4. send ltAGREEMENT_REP, request_id,
  sender_addr, neighbor_addr,eRgt
• 5. ElseIf message_typeAGREEMENT_REP
• 6. generate a shared key Ks
• 7. send ltKEY_OFFER, encrypt (Ks)gt
• 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
7
The proposed security schema (3/4)

• Route request

Ik
D
Hased value hashKs(RREQ) the hashed value of
RREQ message by the shared key Ks between the two
nodes.
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
• ltAUTHEN_RREP_REQ, dest_addr,dest_seq_gt
• ltAUTHEN_RREP_REP, dest_addr, dest_seq_,
  hashKs(RREP)gt
• Authentication for route error report message
  (RERR)
• ltAUTHEN_RERR_REQ,unreachable_dest_addr,
  unreachable_dest_seq_gt
• ltAUTHEN_RERR_REP, unreachable_dest_addr,
  unreachable_dest_seq_, hashKs(RERR)gt

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

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

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

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

13
Thank you!
14
Impersonate attacks

• A malicious node impersonates the source node
• A malicious node impersonates the destination
  node
• Forging a RREP with its address as a destination
  node
• Associating with modifying sequence number with a
  big value
• Impersonates the neighbor of destination
• A malicious node forms loops by spoofing nodes

15
Modification attacks

• Modify hop count field
• Reduce the hop count field in RREQ messages
• The malicious node is included on a newly created
  route
• Modify destination_seq_ field
• after re-broadcasting a RREQ, a malicious node
  creates a falsified RREQ with increased
  destination_seq_

16
Falsifying Route Errors

• A malicious node can falsifies a fabrication
  route error message
• A malicious node M spoofs node B and send to node
  A (previous hop of B in a route to a destination)
  a error message indicating a broken link between
  node B and the destination
• Node A delete the table entry for the destination
  and forward the route error message

B
A
S
D
M
Falsified RERR