INTERNET-DRAFT Thomas Clausen (ed.)
IETF MANET Working Group Emmanuel Baccelli (ed.)
Expiration: 14 August 2005 LIX, Ecole Polytechnique, France
14 February 2005
Securing OLSR Problem Statement
draft-clausen-manet-solsr-ps-00.txt
Status of this Memo
This document is a submission to the Mobile Adhoc NETworks (MANET)
Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the manet@ietf.org mailing list.
Distribution of this memo is unlimited.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this draft, we examine security issues related to proactive
routing protocols for MANETs. Specifically, we investigate security
properties of OLSR and describe possible attacks against the
integrity of the network routing infrastructure.
Solutions exist, which address the vulnerabilities discussed in this
draft. The intent of this draft is not to discuss various solutions,
Clausen (ed.), Baccelli (ed.) [Page 1]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
however to outline the vulnerabilities which a proactive manet
routing protocol is sensitive to. The design of a proactive manet
routing protocol should be flexible enough to accommodate a large
selection of the possible solutions.
Clausen (ed.), Baccelli (ed.) [Page 2]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Incorrect Traffic Generation . . . . . . . . . . . . . . . . . 7
2.2.1. Incorrect HELLO Message Generation . . . . . . . . . . . . . 7
2.2.2. Incorrect TC Message Generation . . . . . . . . . . . . . . . 9
2.3. Incorrect Traffic Relaying . . . . . . . . . . . . . . . . . . 10
2.3.1. Incorrect Control Traffic Relaying . . . . . . . . . . . . . 11
2.3.2. Replay attack . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Incorrect Data Traffic Relaying . . . . . . . . . . . . . . . 11
3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Clausen (ed.), Baccelli (ed.) [Page 3]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
1. Introduction
A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are
able to connect on a wireless medium forming an arbitrary and dynamic
network. Implicitly herein is the ability for the network topology to
change over time as links in the network appear and disappear.
In order to enable communication between any two nodes in such a
MANET, a routing protocol is employed. The abstract task of the rout-
ing protocol is to discover the topology (and, as the network is
dynamic, continuing changes to the topology) to ensure that each node
is able to acquire a recent image of the network topology for con-
structing routes.
Currently, two complementary classes of routing protocols exist in
the MANET world. Reactive protocols acquire routes on demand through
flooding a ``route request'' (which typically also records the path
taken) and receiving a ``route reply'' (typically signaling the path
taken by the route request to arrive at the destination node). I.e.
the required parts of the topology graph is constructed in a node
only when needed for data traffic communication. Reactive MANET rout-
ing protocols include AODV [4] and DSR [6].
The other class of MANET routing protocols is proactive, i.e. the
routing protocol ensures that all nodes at all times have sufficient
topological information to construct routes to all destinations in
the network. This is achieved through periodic message exchange.
Proactive MANET routing protocols include OLSR [1] and TBRPF [5].
A significant issue in the ad-hoc domain is that of the integrity of
the network itself. AODV, DSR, OLSR and TBRPF allow, according to
their specifications, any node to participate in the network - the
assumption being that all nodes are well-behaving and welcome. If
that assumptions fails - if the network may count malicious nodes -
the integrity of the network may fail.
An orthogonal security issue is that of maintaining confidentiality
and integrity of the data being exchanged between communications end-
points in the network (e.g. between a mail server and a mail client).
The task of ensuring end-to-end security of data communications in
MANETs is equivalent to that of securing end-to-end security in tra-
ditional wire-line networks, and is not considered further in this
draft.
The primary issue with respect to securing MANET routing protocols is
thus ensuring the network integrity, even in presence of malicious
nodes. Security extensions to the reactive protocols AODV and DSR
exist, in form of SAODV [7] and Ariadne [8]. Assuming that a
Clausen (ed.), Baccelli (ed.) [Page 4]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
mechanism for key distribution is in place, these extensions employ
digital signatures on the route request and route reply messages. The
basic principle being that each node verifies the signature of a mes-
sage and - if valid - modifies the message (if applicable), signing
it itself before forwarding the message.
In this draft, we investigate the issues with security in proactive
MANET routing protocols in general, and OLSR in particular.
We point out, that there are different approaches to securing a
proactive MANET routing protocol in general, and OLSR in particular.
One such approach is to ensure that only ``trusted'' nodes are admit-
ted into the network and, subsequently, that these are the only nodes
used for forwarding traffic. This approach relies on an assumption
that a trusted node is not, at the same time, misbehaving -- much
like a company, handing out a key to each employee, assuming that any
theft will be committed by people outside to the company. Complimen-
tary to this trusted/non-trusted discrimination of nodes, is the
ability to detect and deal with the situation where a trusted node
has become compromised. Specifically, to take a trusted node, detect
that it is misbehaving and then decide to classify that node as "non-
trusted" for exclusion from the network. This, however, opens an
additional vulnerability: a node can be malicious in that it
"denounces" other (non-malicious) nodes and manages to get these
excluded from the network.
While we do not, in the present version of this draft, concern our-
self with the solution-space, we do point out that any solutions must
be carefully scrutinized to prevent that they themselves introduce
other vulnerabilities.
1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].
1.2. Applicability
This document aims at discussing the issues with securing proactive
MANET routing protocols in general and OLSR in particular.
Clausen (ed.), Baccelli (ed.) [Page 5]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
2. Proactive MANET Routing Protocols and OLSR Vulnerabilities
In this section, we will discuss various security vulnerabilities in
proactive routing protocol for ad hoc networks. We will specifically
enumerate vulnerabilities in OLSR, however we point out that this
section does not emphasize ``flaws'' in the OLSR protocol. Rather,
the vulnerabilities are instances of what all proactive routing pro-
tocols are subject to.
When an ad hoc network is operating under a proactive routing proto-
col, each node has two different (but related) responsibilities.
Firstly, each node must correctly generate routing protocol control
traffic, conforming to the protocol specification. Secondly, each
node is responsible for forwarding routing protocol control traffic
on behalf of other nodes in the network. Thus incorrect behavior of a
node can result from either a node generating incorrect control mes-
sages or from incorrect relaying of control traffic from other nodes.
Correctly generating and forwarding control traffic can be considered
as a criterion for having a correctly functioning routing. In other
words, that the routing protocol is able to consistently provide a
correct view of the network topology in each network node. This
assumption implies that all nodes in the network correctly implement
the routing protocol - specifically that each node correctly pro-
cesses and emits control traffic. Note that this, in and by itself,
is not sufficient to ensure that data packets are being correctly
routed in the network. Indeed, independently of the routing protocol
being proactive or reactive, a misbehaving node may generate, process
and relay control traffic correctly while actually not perform data
traffic forwarding.
In the remainder of this section, we will investigate how these
incorrect behaviors may appear in OLSR. We note, that while we employ
OLSR for the purpose of our descriptions, much of the following
applies equally for other proactive routing protocols.
2.1. Jamming
One vulnerability, common for all routing protocols operating a wire-
less ad hoc network, is that of ``jamming'' - i.e. that a node gener-
ates massive amounts of interfering radio transmissions, which will
prevent legitimate traffic (e.g. control traffic for the routing pro-
tocol as well as data traffic) on part of a network. This vulnerabil-
ity cannot be dealt with at the routing protocol level (if at all),
leaving the network without the ability to maintain connectivity.
Jamming is somewhat similar to that of network overload and
Clausen (ed.), Baccelli (ed.) [Page 6]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
subsequent denial of service: a sufficiently significant amount of
routing protocol control traffic is lost, preventing routes to be
constructed in the network.
2.2. Incorrect Traffic Generation
OLSR employs, basically, two different kinds of control traffic:
HELLO messages and TC messages. While there are other types of OLSR
messages (such as MID or HNA), they don't introduce any fundamentally
different issues, and we therefore concentrate on HELLOs and TCs. In
this section, we will describe how a non-conforming node may affect
the network connectivity through incorrect generation of HELLO and TC
messages.
In general, we observe that with respect to control traffic genera-
tion, a node may misbehave in two different ways: through generating
control traffic ``pretending'' to be another node (i.e. Identity
Spoofing) or through advertising incorrect information (links) in the
control messages (i.e. Link Spoofing). In both cases, the net effect
is, that incorrect link-state information is introduced into the net-
work. This incorrect information then leads to the algorithms of the
routing protocol to operate on incorrect data-sets and, possibly,
yield incorrect results as a concequence.
2.2.1. Incorrect HELLO Message Generation
In terms of HELLO messages, identity spoofing implies that a node
sends HELLO messages pretending to have the identity of another node.
E.g. node X sends HELLO messages with the originator address set to
that of node A, as illustrated in Figure 1. This may result in the
network containing conflicting routes to node A. Specifically, node X
will choose MPRs from among its neighbors, signaling this selection
pretending to have the identity of node A. The MPRs will, subse-
quently, advertise that they can provide ``last hop'' to node A in
their TC messages. Conflicting routes to node A, with possible loops,
may result from this.
Clausen (ed.), Baccelli (ed.) [Page 7]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
----------
| |
| Node A |
| |
----------
|
|
---------- ---------- ----------
| | | | | |
| Node 1 |--| Node 2 |--| Node 3 |
| | | | | |
---------- ---------- ----------
| |
| |
---------- ---------- ----------
| | | | | |
| Node 4 |--| Node 5 |--| Node 6 |
| | | | | |
---------- ---------- ----------
| |
| |
---------- ----------
| | | |
| Node B |----------------| Node C |
| |\ /| |
---------- \ / ----------
\----------/
| |
| Node X |
| |
----------
Figure 1: Identity Spoofing of Hello messages. Node X assumes
the identity of node A for sending HELLO messages. Node B and
node C may subsequently announce reachability to node A through
their TC messages.
Similarly, link spoofing implies that a node sends HELLO messages,
signaling an incorrect set of neighbors. This may take either of two
forms: if the set is incomplete, i.e. a node ``ignores'' some neigh-
bors, the network may be without connectivity to these ``ignored''
neighbors.
Alternatively, a compromised node advertising a neighbor-relationship
to non-present nodes may cause inaccurate MPR selection with the
result that some nodes may not be reachable in the network.
Clausen (ed.), Baccelli (ed.) [Page 8]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
2.2.2. Incorrect TC Message Generation
As for HELLO messages, identity spoofing with respect to TC messages
implies that a node sends TC messages, pretending to have the iden-
tity of another node. Effectively, this implies link spoofing since a
node assuming the identity of another node effectively advertises
incorrect links to the network.
Similarly, link spoofing implies that a node sends TC messages,
advertising an incorrect set of links. This may take either of two
forms: if the set is incomplete, i.e. a node ``ignores'' links to
some nodes in its MPR selector set, the network may be without con-
nectivity to these ``ignored'' neighbors - as well as to neighbors
which are reachable only through the ``ignored'' neighbors. A node
may also include non-existing links (i.e. links to non-neighbor
nodes) in a TC message. This is illustrated in Figure 2. Link spoof-
ing in TC messages may yield routing loops and conflicting routes in
the network.
A node could also simply fail to produce TC control traffic: a node
may correctly generate HELLO messages, be selected as MPR by other
nodes, and then not generate the TC messages that indicate it has MPR
selectors. The net concequence is, that some destinations may not be
advertised throughout the network and.
Clausen (ed.), Baccelli (ed.) [Page 9]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
----------
| |
| Node A |
| |
----------
|
|
---------- ---------- ----------
| | | | | |
| Node 1 |--| Node 2 |--| Node 3 |
| | | | | |
---------- ---------- ----------
| |
| |
---------- ---------- ----------
| | | | | |
| Node 4 |--| Node 5 |--| Node 6 |
| | | | | |
---------- ---------- ----------
^ |
^ |
---------- ----------
| |->> ------------| |
| Node X | | Node 7 |
| |>> /| |
---------- \ / ----------
\----------/
| |
| Node 8 |
| |
----------
Figure 2: Identity Spoofing of TC messages. Node X
generates incorrect TC messages, e.g. advertising
a link between node X and node A.
2.3. Incorrect Traffic Relaying
Nodes in a MANET relays two types of traffic: routing protocol con-
trol traffic and data traffic. A node may misbehave through failing
to forward either type of traffic correctly.
Clausen (ed.), Baccelli (ed.) [Page 10]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
2.3.1. Incorrect Control Traffic Relaying
If TC messages (or routing protocol control messages in general) are
not properly relayed, connectivity loss may result. In networks where
no redundancy exists (e.g. in a ``strip'' network), connectivity loss
will surely result, while other topologies may provide redundant con-
nectivity. Similarly if a node does not forward data packets (e.g. if
intra-node forwarding is impaired), loss of connectivity may result.
2.3.2. Replay attack
A replay attack is, simply, where control traffic from one region of
the network is recorded and replayed in a different region (this type
of attack is also known as the Wormhole attack) This may, for exam-
ple, happen when two nodes collaborate on an attack, one recording
traffic in its proximity and tunneling it to the other node, which
replays the traffic. In a protocol where links are discovered by
testing reception, this will result in extraneous link creation
(basically, a link between the two ``attacking'' nodes).
While this may result from an attack, we note that it may also be
intentional: if data-traffic too is relayed over the virtual link
over the ``tunnel'', the link being detected is, indeed valid. This
is, for instance, used in wireless repeaters. If data traffic is not
carried over the virtual link, an imaginary, compromised, link has
been created.
Replay attacks can be especially damaging if coupled with spoofing
and playing with sequence numbers in the replayed messages, poten-
tially destroying some important topology information in nodes all
over the network.
2.3.3. Incorrect Data Traffic Relaying
Even a node correctly generating, processing and forwarding control
traffic as required, may act in a malicious way through not forward-
ing data traffic. The node thereby breaks connectivity in the network
(data traffic cannot get through) however this connectivity loss is
not detected by the routing protocol (control traffic is correctly
relayed).
While this indeed may be due to an attack, this type of situation is
also encountered simply due to misconfigured nodes: routing
Clausen (ed.), Baccelli (ed.) [Page 11]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
capabilities (through IP forwarding) are typically disabled by
default in most operating systems, and must manually be enabled.
Failing to do so, effectively, triggers the situation where data
traffic is not forwarded/routed while control-traffic (which is for-
warded by action of the routing daemon) is transmitted correctly.
3. Authors' Addresses
Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org
Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: Emmanuel.Baccelli@inria.fr
4. Contributors
Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org
Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Clausen (ed.), Baccelli (ed.) [Page 12]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: Emmanuel.Baccelli@inria.fr
Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5215, Email:
Cedric.Adjih@inria.fr
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email:
Philippe.Jacquet@inria.fr
Anis Laouiti, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5088, Email:
Anis.Laouiti@inria.fr
Paul Muhlethaler, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email:
Paul.Muhlethaler@inria.fr
Daniele Raffo, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5856, Email:
Daniele.Raffo@inria.fr
Christopher Dearlove, BAE SYSTEMS Advanced Technology Centre, Great
Baddow, Chelmsford, UK. Phone: +44 1245 242194 Email:
chris.dearlove@baesystems.com
5. References
[1] T. Clausen, P. Jacquet, RFC 3626: Optimized Link State Routing Pro-
tocol. Request for Comments (Experimental), Internet Engineering
Task Force, October 2003.
[2] T. Clausen, C. Adjih, P. Jacquet, A. Laouiti, P. Muhlethaler, D.
Raffo, Securing the OLSR Protocol. Proceeding of IFIP Med-Hoc-Net
2003, June 2003.
Clausen (ed.), Baccelli (ed.) [Page 13]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
[3] T. Clausen, P. Jacquet, L. Viennot, Investigating the Impact of Par-
ital Topology in Proactive MANET Routing Protocols. Proceedings of
the Fifth Wireless Personal Multimedia Communications, November
2002.
[4] C. E. Perkins, E. M. Royer, S. R. Das, RFC 3561: Ad Hoc On-Demand
Distance Vector Routing. Internet Engineering Task Force, Request
For Comments (experimental), July 2003.
[5] R. Ogier, F. Templin, M. Lewis, RFC 3684: Topology Dissemination
Based on Reverse-Path Forwarding. Internet Engineering Task Force,
Request For Comments (experimental), February 2004.
[6] D. Johnson, D. Maltz, Y. Hu, draft-ietf-manet-dsr-10.txt: The
Dynamic Source Routing Protocol for Mobile Ad Hoc Networks. Inter-
net Engineering Task Force, Internet Draft (Work in Progress), July
2004.
[7] M. Zapata, draft-guerrero-manet-saodv-00.txt: Secure Ad Hoc On-
Demand Distance Vector Routing. Internet Engineering Task Force,
Internet Draft (Work in Progress), October 2002.
[8] Y. Hu, A. Perrig, D. Johnson, A Secure On-Demand Routing Protocol
for Ad Hoc Networks (Ariadne). Proceedings of MobiCom 2002,
September 2002.
[9] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized
Link State Routing Protocol - Evaluation Through Experiments and
Simulation. Proceedings of the Fourth Wireless Personal Multimedia
Communications, September 2001.
[10] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Effi-
cient Technique for Flooding in Mobile Wireless Networks. INRIA
Research Report RR-3898, Project Hipercom, March 2000.
6. Changes
This is the initial version of this specification.
7. IANA Considerations
This document does currently not specify IANA considerations.
8. Security Considerations
This document does not specify a protocol or a procedure. The docu-
ment is, however, reflections on security considerations for a class
of MANET routing protocols.
Clausen (ed.), Baccelli (ed.) [Page 14]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
9. Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
On 15 Feb 2005, at 20:28, Dinara Suleymanova wrote:
The file name is too long. Please fix the problem by decreasing the number of
words and resubmit.
Thanks.
At 07:49 AM 2/14/2005, Thomas Heide clausen wrote:
Dear IETF Secretariat,
Please find attached the draft "Securing OLSR Problem Statement"
(draft-clausen-manet-securing-olsr-problem-statement-00.txt)
This draft aims at summarizing the security considerations, resulting from various
experience with OLSR (RFC3626). The draft aims as a starting point for considering
security in proactive manet routing -- mandated by the wg charter: "Routing
security requirements and issues will also be addressed" for future std. track
protocols.
If there are any questions or comments, please do not hesitate to contact me.
Sincerely,
--thomas
INTERNET-DRAFT Thomas Clausen (ed.)
IETF MANET Working Group Emmanuel Baccelli (ed.)
Expiration: 14 August 2005 LIX, Ecole Polytechnique, France
14 February 2005
Securing OLSR Problem Statement
draft-clausen-manet-securing-olsr-problem-statement-00.txt
Status of this Memo
This document is a submission to the Mobile Adhoc NETworks (MANET)
Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the manet@ietf.org mailing list.
Distribution of this memo is unlimited.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this draft, we examine security issues related to proactive
routing protocols for MANETs. Specifically, we investigate security
properties of OLSR and describe possible attacks against the
integrity of the network routing infrastructure.
Solutions exist, which address the vulnerabilities discussed in this
draft. The intent of this draft is not to discuss various solutions,
Clausen (ed.), Baccelli (ed.)
[Page 1]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
however to outline the vulnerabilities which a proactive manet
routing protocol is sensitive to. The design of a proactive manet
routing protocol should be flexible enough to accommodate a large
selection of the possible solutions.
Clausen (ed.), Baccelli (ed.)
[Page 2]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .
5
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2. Incorrect Traffic Generation . . . . . . . . . . . . . . . . .
7
2.2.1. Incorrect HELLO Message Generation . . . . . . . . . . . . .
7
2.2.2. Incorrect TC Message Generation . . . . . . . . . . . . . . .
9
2.3. Incorrect Traffic Relaying . . . . . . . . . . . . . . . . . .
10
2.3.1. Incorrect Control Traffic Relaying . . . . . . . . . . . . .
11
2.3.2. Replay attack . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.3. Incorrect Data Traffic Relaying . . . . . . . . . . . . . . .
11
3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .
12
4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . .
12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . .
14
8. Security Considerations . . . . . . . . . . . . . . . . . . . . .
14
9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Clausen (ed.), Baccelli (ed.)
[Page 3]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
1. Introduction
A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are
able to connect on a wireless medium forming an arbitrary and dynamic
network. Implicitly herein is the ability for the network topology to
change over time as links in the network appear and disappear.
In order to enable communication between any two nodes in such a
MANET, a routing protocol is employed. The abstract task of the rout-
ing protocol is to discover the topology (and, as the network is
dynamic, continuing changes to the topology) to ensure that each node
is able to acquire a recent image of the network topology for con-
structing routes.
Currently, two complementary classes of routing protocols exist in
the MANET world. Reactive protocols acquire routes on demand through
flooding a ``route request'' (which typically also records the path
taken) and receiving a ``route reply'' (typically signaling the path
taken by the route request to arrive at the destination node). I.e.
the required parts of the topology graph is constructed in a node
only when needed for data traffic communication. Reactive MANET rout-
ing protocols include AODV [4] and DSR [6].
The other class of MANET routing protocols is proactive, i.e. the
routing protocol ensures that all nodes at all times have sufficient
topological information to construct routes to all destinations in
the network. This is achieved through periodic message exchange.
Proactive MANET routing protocols include OLSR [1] and TBRPF [5].
A significant issue in the ad-hoc domain is that of the integrity of
the network itself. AODV, DSR, OLSR and TBRPF allow, according to
their specifications, any node to participate in the network - the
assumption being that all nodes are well-behaving and welcome. If
that assumptions fails - if the network may count malicious nodes -
the integrity of the network may fail.
An orthogonal security issue is that of maintaining confidentiality
and integrity of the data being exchanged between communications end-
points in the network (e.g. between a mail server and a mail client).
The task of ensuring end-to-end security of data communications in
MANETs is equivalent to that of securing end-to-end security in tra-
ditional wire-line networks, and is not considered further in this
draft.
The primary issue with respect to securing MANET routing protocols is
thus ensuring the network integrity, even in presence of malicious
nodes. Security extensions to the reactive protocols AODV and DSR
exist, in form of SAODV [7] and Ariadne [8]. Assuming that a
Clausen (ed.), Baccelli (ed.)
[Page 4]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
mechanism for key distribution is in place, these extensions employ
digital signatures on the route request and route reply messages. The
basic principle being that each node verifies the signature of a mes-
sage and - if valid - modifies the message (if applicable), signing
it itself before forwarding the message.
In this draft, we investigate the issues with security in proactive
MANET routing protocols in general, and OLSR in particular.
We point out, that there are different approaches to securing a
proactive MANET routing protocol in general, and OLSR in particular.
One such approach is to ensure that only ``trusted'' nodes are admit-
ted into the network and, subsequently, that these are the only nodes
used for forwarding traffic. This approach relies on an assumption
that a trusted node is not, at the same time, misbehaving -- much
like a company, handing out a key to each employee, assuming that any
theft will be committed by people outside to the company. Complimen-
tary to this trusted/non-trusted discrimination of nodes, is the
ability to detect and deal with the situation where a trusted node
has become compromised. Specifically, to take a trusted node, detect
that it is misbehaving and then decide to classify that node as "non-
trusted" for exclusion from the network. This, however, opens an
additional vulnerability: a node can be malicious in that it
"denounces" other (non-malicious) nodes and manages to get these
excluded from the network.
While we do not, in the present version of this draft, concern our-
self with the solution-space, we do point out that any solutions must
be carefully scrutinized to prevent that they themselves introduce
other vulnerabilities.
1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].
1.2. Applicability
This document aims at discussing the issues with securing proactive
MANET routing protocols in general and OLSR in particular.
Clausen (ed.), Baccelli (ed.)
[Page 5]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
2. Proactive MANET Routing Protocols and OLSR Vulnerabilities
In this section, we will discuss various security vulnerabilities in
proactive routing protocol for ad hoc networks. We will specifically
enumerate vulnerabilities in OLSR, however we point out that this
section does not emphasize ``flaws'' in the OLSR protocol. Rather,
the vulnerabilities are instances of what all proactive routing pro-
tocols are subject to.
When an ad hoc network is operating under a proactive routing proto-
col, each node has two different (but related) responsibilities.
Firstly, each node must correctly generate routing protocol control
traffic, conforming to the protocol specification. Secondly, each
node is responsible for forwarding routing protocol control traffic
on behalf of other nodes in the network. Thus incorrect behavior of a
node can result from either a node generating incorrect control mes-
sages or from incorrect relaying of control traffic from other nodes.
Correctly generating and forwarding control traffic can be considered
as a criterion for having a correctly functioning routing. In other
words, that the routing protocol is able to consistently provide a
correct view of the network topology in each network node. This
assumption implies that all nodes in the network correctly implement
the routing protocol - specifically that each node correctly pro-
cesses and emits control traffic. Note that this, in and by itself,
is not sufficient to ensure that data packets are being correctly
routed in the network. Indeed, independently of the routing protocol
being proactive or reactive, a misbehaving node may generate, process
and relay control traffic correctly while actually not perform data
traffic forwarding.
In the remainder of this section, we will investigate how these
incorrect behaviors may appear in OLSR. We note, that while we employ
OLSR for the purpose of our descriptions, much of the following
applies equally for other proactive routing protocols.
2.1. Jamming
One vulnerability, common for all routing protocols operating a wire-
less ad hoc network, is that of ``jamming'' - i.e. that a node gener-
ates massive amounts of interfering radio transmissions, which will
prevent legitimate traffic (e.g. control traffic for the routing pro-
tocol as well as data traffic) on part of a network. This vulnerabil-
ity cannot be dealt with at the routing protocol level (if at all),
leaving the network without the ability to maintain connectivity.
Jamming is somewhat similar to that of network overload and
Clausen (ed.), Baccelli (ed.)
[Page 6]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
subsequent denial of service: a sufficiently significant amount of
routing protocol control traffic is lost, preventing routes to be
constructed in the network.
2.2. Incorrect Traffic Generation
OLSR employs, basically, two different kinds of control traffic:
HELLO messages and TC messages. While there are other types of OLSR
messages (such as MID or HNA), they don't introduce any fundamentally
different issues, and we therefore concentrate on HELLOs and TCs.
In
this section, we will describe how a non-conforming node may affect
the network connectivity through incorrect generation of HELLO and TC
messages.
In general, we observe that with respect to control traffic genera-
tion, a node may misbehave in two different ways: through generating
control traffic ``pretending'' to be another node (i.e. Identity
Spoofing) or through advertising incorrect information (links) in the
control messages (i.e. Link Spoofing). In both cases, the net effect
is, that incorrect link-state information is introduced into the net-
work. This incorrect information then leads to the algorithms of the
routing protocol to operate on incorrect data-sets and, possibly,
yield incorrect results as a concequence.
2.2.1. Incorrect HELLO Message Generation
In terms of HELLO messages, identity spoofing implies that a node
sends HELLO messages pretending to have the identity of another node.
E.g. node X sends HELLO messages with the originator address set to
that of node A, as illustrated in Figure 1. This may result in the
network containing conflicting routes to node A. Specifically, node X
will choose MPRs from among its neighbors, signaling this selection
pretending to have the identity of node A. The MPRs will, subse-
quently, advertise that they can provide ``last hop'' to node A in
their TC messages. Conflicting routes to node A, with possible loops,
may result from this.
Clausen (ed.), Baccelli (ed.)
[Page 7]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
----------
| |
| Node A |
| |
----------
|
|
---------- ---------- ----------
| | | | | |
| Node 1 |--| Node 2 |--| Node 3 |
| | | | | |
---------- ---------- ----------
| |
| |
---------- ---------- ----------
| | | | | |
| Node 4 |--| Node 5 |--| Node 6 |
| | | | | |
---------- ---------- ----------
| |
| |
---------- ----------
| | | |
| Node B |----------------| Node C |
| |\ /| |
---------- \ / ----------
\----------/
| |
| Node X |
| |
----------
Figure 1: Identity Spoofing of Hello messages. Node X assumes
the identity of node A for sending HELLO messages. Node B and
node C may subsequently announce reachability to node A through
their TC messages.
Similarly, link spoofing implies that a node sends HELLO messages,
signaling an incorrect set of neighbors. This may take either of two
forms: if the set is incomplete, i.e. a node ``ignores'' some neigh-
bors, the network may be without connectivity to these ``ignored''
neighbors.
Alternatively, a compromised node advertising a neighbor-relationship
to non-present nodes may cause inaccurate MPR selection with the
result that some nodes may not be reachable in the network.
Clausen (ed.), Baccelli (ed.)
[Page 8]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
2.2.2. Incorrect TC Message Generation
As for HELLO messages, identity spoofing with respect to TC messages
implies that a node sends TC messages, pretending to have the iden-
tity of another node. Effectively, this implies link spoofing since a
node assuming the identity of another node effectively advertises
incorrect links to the network.
Similarly, link spoofing implies that a node sends TC messages,
advertising an incorrect set of links. This may take either of two
forms: if the set is incomplete, i.e. a node ``ignores'' links to
some nodes in its MPR selector set, the network may be without con-
nectivity to these ``ignored'' neighbors - as well as to neighbors
which are reachable only through the ``ignored'' neighbors. A node
may also include non-existing links (i.e. links to non-neighbor
nodes) in a TC message. This is illustrated in Figure 2. Link spoof-
ing in TC messages may yield routing loops and conflicting routes in
the network.
A node could also simply fail to produce TC control traffic: a node
may correctly generate HELLO messages, be selected as MPR by other
nodes, and then not generate the TC messages that indicate it has MPR
selectors. The net concequence is, that some destinations may not be
advertised throughout the network and.
Clausen (ed.), Baccelli (ed.)
[Page 9]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
----------
| |
| Node A |
| |
----------
|
|
---------- ---------- ----------
| | | | | |
| Node 1 |--| Node 2 |--| Node 3 |
| | | | | |
---------- ---------- ----------
| |
| |
---------- ---------- ----------
| | | | | |
| Node 4 |--| Node 5 |--| Node 6 |
| | | | | |
---------- ---------- ----------
^ |
^ |
---------- ----------
| |->> ------------| |
| Node X | | Node 7 |
| |>> /| |
---------- \ / ----------
\----------/
| |
| Node 8 |
| |
----------
Figure 2: Identity Spoofing of TC messages. Node X
generates incorrect TC messages, e.g. advertising
a link between node X and node A.
2.3. Incorrect Traffic Relaying
Nodes in a MANET relays two types of traffic: routing protocol con-
trol traffic and data traffic. A node may misbehave through failing
to forward either type of traffic correctly.
Clausen (ed.), Baccelli (ed.)
[Page 10]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
2.3.1. Incorrect Control Traffic Relaying
If TC messages (or routing protocol control messages in general) are
not properly relayed, connectivity loss may result. In networks where
no redundancy exists (e.g. in a ``strip'' network), connectivity loss
will surely result, while other topologies may provide redundant con-
nectivity. Similarly if a node does not forward data packets (e.g. if
intra-node forwarding is impaired), loss of connectivity may result.
2.3.2. Replay attack
A replay attack is, simply, where control traffic from one region of
the network is recorded and replayed in a different region (this type
of attack is also known as the Wormhole attack) This may, for exam-
ple, happen when two nodes collaborate on an attack, one recording
traffic in its proximity and tunneling it to the other node, which
replays the traffic. In a protocol where links are discovered by
testing reception, this will result in extraneous link creation
(basically, a link between the two ``attacking'' nodes).
While this may result from an attack, we note that it may also be
intentional: if data-traffic too is relayed over the virtual link
over the ``tunnel'', the link being detected is, indeed valid. This
is, for instance, used in wireless repeaters. If data traffic is not
carried over the virtual link, an imaginary, compromised, link has
been created.
Replay attacks can be especially damaging if coupled with spoofing
and playing with sequence numbers in the replayed messages, poten-
tially destroying some important topology information in nodes all
over the network.
2.3.3. Incorrect Data Traffic Relaying
Even a node correctly generating, processing and forwarding control
traffic as required, may act in a malicious way through not forward-
ing data traffic. The node thereby breaks connectivity in the network
(data traffic cannot get through) however this connectivity loss is
not detected by the routing protocol (control traffic is correctly
relayed).
While this indeed may be due to an attack, this type of situation is
also encountered simply due to misconfigured nodes: routing
Clausen (ed.), Baccelli (ed.)
[Page 11]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
capabilities (through IP forwarding) are typically disabled by
default in most operating systems, and must manually be enabled.
Failing to do so, effectively, triggers the situation where data
traffic is not forwarded/routed while control-traffic (which is for-
warded by action of the routing daemon) is transmitted correctly.
3. Authors' Addresses
Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org
Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: Emmanuel.Baccelli@inria.fr
4. Contributors
Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org
Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Clausen (ed.), Baccelli (ed.)
[Page 12]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: Emmanuel.Baccelli@inria.fr
Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5215, Email:
Cedric.Adjih@inria.fr
Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email:
Philippe.Jacquet@inria.fr
Anis Laouiti, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5088, Email:
Anis.Laouiti@inria.fr
Paul Muhlethaler, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153
Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email:
Paul.Muhlethaler@inria.fr
Daniele Raffo, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le
Chesnay Cedex, France, Phone: +33 1 3963 5856, Email:
Daniele.Raffo@inria.fr
Christopher Dearlove, BAE SYSTEMS Advanced Technology Centre, Great
Baddow, Chelmsford, UK. Phone: +44 1245 242194 Email:
chris.dearlove@baesystems.com
5. References
[1] T. Clausen, P. Jacquet, RFC 3626: Optimized Link State Routing Pro-
tocol. Request for Comments (Experimental), Internet Engineering
Task Force, October 2003.
[2] T. Clausen, C. Adjih, P. Jacquet, A. Laouiti, P. Muhlethaler, D.
Raffo, Securing the OLSR Protocol. Proceeding of IFIP Med-Hoc-Net
2003, June 2003.
Clausen (ed.), Baccelli (ed.)
[Page 13]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
[3] T. Clausen, P. Jacquet, L. Viennot, Investigating the Impact of Par-
ital Topology in Proactive MANET Routing Protocols. Proceedings of
the Fifth Wireless Personal Multimedia Communications, November
2002.
[4] C. E. Perkins, E. M. Royer, S. R. Das, RFC 3561: Ad Hoc On-Demand
Distance Vector Routing. Internet Engineering Task Force, Request
For Comments (experimental), July 2003.
[5] R. Ogier, F. Templin, M. Lewis, RFC 3684: Topology Dissemination
Based on Reverse-Path Forwarding. Internet Engineering Task Force,
Request For Comments (experimental), February 2004.
[6] D. Johnson, D. Maltz, Y. Hu, draft-ietf-manet-dsr-10.txt: The
Dynamic Source Routing Protocol for Mobile Ad Hoc Networks.
Inter-
net Engineering Task Force, Internet Draft (Work in Progress), July
2004.
[7] M. Zapata, draft-guerrero-manet-saodv-00.txt: Secure Ad Hoc On-
Demand Distance Vector Routing. Internet Engineering Task Force,
Internet Draft (Work in Progress), October 2002.
[8] Y. Hu, A. Perrig, D. Johnson, A Secure On-Demand Routing Protocol
for Ad Hoc Networks (Ariadne). Proceedings of MobiCom 2002,
September 2002.
[9] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized
Link State Routing Protocol - Evaluation Through Experiments and
Simulation. Proceedings of the Fourth Wireless Personal Multimedia
Communications, September 2001.
[10] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Effi-
cient Technique for Flooding in Mobile Wireless Networks. INRIA
Research Report RR-3898, Project Hipercom, March 2000.
6. Changes
This is the initial version of this specification.
7. IANA Considerations
This document does currently not specify IANA considerations.
8. Security Considerations
This document does not specify a protocol or a procedure. The docu-
ment is, however, reflections on security considerations for a class
of MANET routing protocols.
Clausen (ed.), Baccelli (ed.)
[Page 14]
INTERNET-DRAFT Securing OLSR Problem Statement 14 February 2005
9. Copyright
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.