A SpecificationBased Intrusion Detection System For AODV

1
A Specification-Based Intrusion Detection System
For AODV

• Chin-Yang Tseng, Poornima Balasubramanyam, Calvin
  Ko (NAI),  Rattapon Limprasittiporn,
• Jeff Rowe, and Karl Levitt
• (Submitted to SASN 03 Workshop)

2
Introduction to AODV

• Request on demand routing protocol
• Stateless protocol using distance vector
• Main control messages
• RREQ (Request), RREP (Response), RERR (Error)
• Explore routes only when needed
• Source broadcast RREQ with unique RREQ ID
• Destination or any intermediate node knowing the
  route responses RREP and it will be forwarded to
  source
• RERR will be sent if any local active link is
  broken

3
Introduction to AODV Contd

• Sequence number (SN)
• The freshness of the route
• Each node owns its SN and maintains SN itself
• Increase 1 if new RREQ or RREP is generated by
  itself
• Update the route
• Only when sequence number of source is greater
• Or SN is equal and hop count is smaller
• Update reverse route (to source) when receiving
  RREQ
• Update forward route (to destination) when
  receiving RREP
• Hop count is increased 1(starting from 0) if
  message forwarded each hop

RREQ
RREP
Destination
Node
Source
Forward Route
Reverse Route
4
Challenges of IDS in AODV

• Critical fields in AODVcontrol messages
• Not protected in AODV
• Misuse would cause AODV to malfunction and result
  in potential attacks
• Monitoring AODV packets
• One single node cannot monitor the whole network
• Ad hoc network is a dynamic changing environment
• Requirements of IDS for AODV
• Detect unknown attacks
• Low false positives and negatives
• Monitor the whole network efficiently and
  effectively

5
Misuse critical fields in AODVcontrol messages

• Sequence number (SN) of source and destination
  addresses
• Increase it to update other nodes' forward route
  tables, or decrease it to suppress its update.
• Hop Count (HC)
• If sequence number is the same, decrease it to
  update other nodes' forwarding tables, or
  increase it to invalidate the update.
• IP Headers as well as AODV Source and Destination
  IP Addresses
• Replace it with another or invalid IP address.
• RREQ ID
• Increase to create a new RREQ request.

6
Example Attacks

• Man in the middle attack
• M send m1(RREQ) with high SN(A) to take over b1
  and divert reverse route (C to M)
• M send m2(RREP) with high SN(D) to take over c2
  and divert forward route (B to M)
• New route is ABMCD instead of ABCD

b2
c2
d2
A
B
C
D
a1
b1
c1
m2
m1
a1,b1,c1 RREQ b2,c2,d3 RREP
M
Diverted Route
7
Specification-Based Monitoring of AODV

• Cooperative Network Monitors Architecture
• Run-time monitor a request-reply flow
• Construct and provide sufficient monitoring data
• Finite-State Machine Constraints
• Define the normal and abnormal behavior in AODV
• Report anomaly if it goes to alarm state

8
Basic Assumptions

• The MAC addresses and IP addresses of all mobile
  nodes are registered in network monitors and
  remain unchanged.
• MAC addresses cannot be forged.
• Every network monitor and its messages are secure
  and authenticated.
• Every node must forward or respond to the
  messages according to the protocol within some
  finite period of time.
• Network monitors are well selected to be able to
  cover all nodes and perform all required
  functionality.
• If a node is out of range of a network monitor,
  it must be in the range of neighboring monitors.
• If some nodes do not respond to broadcast
  messages, this will not cause serious problems.

9
Run-time Monitoring of Request-Reply Flow

• Network Monitor
• Perform all IDS functionality
• Passively listen to wireless media to monitor
  AODV packets
• Exchange data only when needed
• Request-Reply Flow
• Start from the source node initiating RREQ and
  end at the source node receiving RREP
• Session tree
• Hold a request-replay flow and its braches on the
  fly
• Forwarding tables of NM
• Forwarding tables of the nodes within the range
  of NM
• Used to verify RREP replying from a intermediate
  node

10
Finite-State Machine Constraints

• Three kinds of States
• Normal States
• Suspicious States
• Alarm States
• Each branch of the session tree uses one unique
  state machine

11
(No Transcript)
12
(No Transcript)
13
Matching Current and Previous Messages

• RREP Unicasting Message
• Identify by Source and destination address in IP
  Header.
• RREQ Broadcasting Message
• Destination is unknown
• Add Previous node field in RREQ

c1
b1
a1
d2
c2
b2
14
Construction and Processing of the Session Trees

• RREQ
• RetrieveTree(M.AODVSrc, M.RRID, SessionTreeList,
  T)
• RetrivePrevMsg(M.PrevNode, PrevM)
• CheckConsistency(M, PrevM)
• AddTreeNode(M, T)
• UpdateForwardingTable (M,F)
• RREP
• RetrieveTree(M.AODVSrc,M.AODVDst,SessionTreeList,T
  )
• if (InitRREP(M,T) and NotDst(M,T))
• VerifyRREP(M,F)
• else if (ForwardedRREP(M,T))
• RetrivePrevMsg(M.IPSrc, PrevM)
• CheckConsistency(M, PrevM)
• AddRREPPath(M, T)
• UpdateForwardingTable(M,F)
• Example Scenario as following slide

15
Example AODV Scenario with Network Monitors (NM,
N1 and N2)
Packets Seen by NM in Each Time Slot
Session Tree built by NM in Each Time Slot ( -
RREQ only RREQ and RREP)
16
Examples of Detecting Attacks

• Man in the middle attack
• SN(A) in m1 and SN(D) are larger than N1 and N2
  have
• And the sender of m1 and m2, M, is not the owner
  of SN (A or D)
• SN forged alarm is triggered and the attack is
  detected
• m1 and m2 is not able to fit in the session tree
  that active forged alarms will be triggered.

17
Future Work

• Profile normal network QoS in order to verify
  RERR and packet loss
• Introduce P2P to refine the NM architecture
• Experimentation and verification
• Ns 2
• AODV-UU and implementation