A1261709106XFDkO

1
Securing OLSR Daniele Raffo INRIA /
HIPERCOM 22-10-2004
2
Possible attacks against OLSR
Incorrect control traffic generation Identity
spoofing (spoofed HELLOs or TCs) Wrong
topology Incorrect information (false HELLOs or
TCs) Connectivity loss / Wrong or incomplete
MPR selection Incorrect control traffic
relaying Failure in forwarding traffic
Connectivity loss Packet tampering Wrong
topology / Denial of service
3
Standard OLSR packet format
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
------- Packet Length
Packet Sequence Number
-------------------------
------- Message Type Vtime
Message Size
-------------------------
-------
Originator Address
-------------------------
------- Time To Live Hop
Count Message Sequence Number
-------------------------
-------

MESSAGE


-------------------------
------- Message Type Vtime
Message Size
-------------------------
-------
Originator Address
-------------------------
------- Time To Live Hop
Count Message Sequence Number
-------------------------
-------

MESSAGE


-------------------------
-------

(etc.) (IP and UDP headers are omitted)
4
OLSR signature message format - 1
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Sign. Method
Reserved MSN Referrer



Timestamp





Signature



Message Type is set to
SIGNATURE_MESSAGE Sign. Method contains
informations about key type and hashing
function MSN Referrer matches the Message
Sequence Number
5
OLSR signature message format - 2

• 0 1 2
  3
• 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
  1 2 3 4 5 6 7 8 9 0 1
• 
  
• Sign. Method Reserved
  MSN Referrer
• 
  
• 
  
• Timestamp
  
• 
  
• 
  
• 
  
• Signature
  
• 
  
• 
  
• The Signature is computed on the sequence of
  bytes from
• the TC or HELLO message
• the Timestamp

6
Signature verification protocol

• Upon receiving a HELLO or TC control message, a
  node waits for the corresponding
  SIGNATURE_MESSAGE
• Upon receiving a SIGNATURE_MESSAGE, the node
• couples it with the corresponding HELLO or TC
  (matching Originator Address and MSN Referrer
  Message Sequence Number)
• checks that the Signature is correct, using the
  public key of Originator Address
• verifies that the Timestamp is fresh (this
  avoids replay attacks)
• If all tests pass, the control message is
  accepted and processed

7
System requirements

• Valid timestamps. Options
• embedded clocks
• clock synchronization
• timestamps exchange
• Public Key Infrastructure. Options
• centralized Signing Authority
• distributed Signing Authority
• public key distribution at boot-up

8

• References
• Thomas Clausen (ed.) and Philippe Jacquet (ed.),
  Optimized Link State Routing Protocol, RFC
  3626, October 2003
• Cédric Adjih, Thomas Clausen, Philippe Jacquet,
  Anis Laouiti, Paul Mühlethaler, and Daniele
  Raffo, Securing the OLSR Protocol, in
  Proceedings of Med-Hoc-Net 2003, June 25-27, 2003