idnits 2.17.1 draft-clausen-manet-solsr-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 595. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 1) being 98 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 107 has weird spacing: '...umption being...' == Line 706 has weird spacing: '...umption being...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 February 2005) is 7001 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1103, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1135, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 3626 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Experimental RFC: RFC 3561 (ref. '4') ** Downref: Normative reference to an Experimental RFC: RFC 3684 (ref. '5') ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '6') == Outdated reference: A later version (-06) exists of draft-guerrero-manet-saodv-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Clausen (ed.) 2 IETF MANET Working Group Emmanuel Baccelli (ed.) 3 Expiration: 14 August 2005 LIX, Ecole Polytechnique, France 4 14 February 2005 6 Securing OLSR Problem Statement 7 draft-clausen-manet-solsr-ps-00.txt 9 Status of this Memo 11 This document is a submission to the Mobile Adhoc NETworks (MANET) 12 Working Group of the Internet Engineering Task Force (IETF). Comments 13 should be submitted to the manet@ietf.org mailing list. 15 Distribution of this memo is unlimited. 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 or will be disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC 2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 In this draft, we examine security issues related to proactive 43 routing protocols for MANETs. Specifically, we investigate security 44 properties of OLSR and describe possible attacks against the 45 integrity of the network routing infrastructure. 47 Solutions exist, which address the vulnerabilities discussed in this 48 draft. The intent of this draft is not to discuss various solutions, 49 however to outline the vulnerabilities which a proactive manet 50 routing protocol is sensitive to. The design of a proactive manet 51 routing protocol should be flexible enough to accommodate a large 52 selection of the possible solutions. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Incorrect Traffic Generation . . . . . . . . . . . . . . . . . 7 62 2.2.1. Incorrect HELLO Message Generation . . . . . . . . . . . . . 7 63 2.2.2. Incorrect TC Message Generation . . . . . . . . . . . . . . . 9 64 2.3. Incorrect Traffic Relaying . . . . . . . . . . . . . . . . . . 10 65 2.3.1. Incorrect Control Traffic Relaying . . . . . . . . . . . . . 11 66 2.3.2. Replay attack . . . . . . . . . . . . . . . . . . . . . . . . 11 67 2.3.3. Incorrect Data Traffic Relaying . . . . . . . . . . . . . . . 11 68 3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are 78 able to connect on a wireless medium forming an arbitrary and dynamic 79 network. Implicitly herein is the ability for the network topology to 80 change over time as links in the network appear and disappear. 82 In order to enable communication between any two nodes in such a 83 MANET, a routing protocol is employed. The abstract task of the rout- 84 ing protocol is to discover the topology (and, as the network is 85 dynamic, continuing changes to the topology) to ensure that each node 86 is able to acquire a recent image of the network topology for con- 87 structing routes. 89 Currently, two complementary classes of routing protocols exist in 90 the MANET world. Reactive protocols acquire routes on demand through 91 flooding a ``route request'' (which typically also records the path 92 taken) and receiving a ``route reply'' (typically signaling the path 93 taken by the route request to arrive at the destination node). I.e. 94 the required parts of the topology graph is constructed in a node 95 only when needed for data traffic communication. Reactive MANET rout- 96 ing protocols include AODV [4] and DSR [6]. 98 The other class of MANET routing protocols is proactive, i.e. the 99 routing protocol ensures that all nodes at all times have sufficient 100 topological information to construct routes to all destinations in 101 the network. This is achieved through periodic message exchange. 102 Proactive MANET routing protocols include OLSR [1] and TBRPF [5]. 104 A significant issue in the ad-hoc domain is that of the integrity of 105 the network itself. AODV, DSR, OLSR and TBRPF allow, according to 106 their specifications, any node to participate in the network - the 107 assumption being that all nodes are well-behaving and welcome. If 108 that assumptions fails - if the network may count malicious nodes - 109 the integrity of the network may fail. 111 An orthogonal security issue is that of maintaining confidentiality 112 and integrity of the data being exchanged between communications end- 113 points in the network (e.g. between a mail server and a mail client). 114 The task of ensuring end-to-end security of data communications in 115 MANETs is equivalent to that of securing end-to-end security in tra- 116 ditional wire-line networks, and is not considered further in this 117 draft. 119 The primary issue with respect to securing MANET routing protocols is 120 thus ensuring the network integrity, even in presence of malicious 121 nodes. Security extensions to the reactive protocols AODV and DSR 122 exist, in form of SAODV [7] and Ariadne [8]. Assuming that a 123 mechanism for key distribution is in place, these extensions employ 124 digital signatures on the route request and route reply messages. The 125 basic principle being that each node verifies the signature of a mes- 126 sage and - if valid - modifies the message (if applicable), signing 127 it itself before forwarding the message. 129 In this draft, we investigate the issues with security in proactive 130 MANET routing protocols in general, and OLSR in particular. 132 We point out, that there are different approaches to securing a 133 proactive MANET routing protocol in general, and OLSR in particular. 134 One such approach is to ensure that only ``trusted'' nodes are admit- 135 ted into the network and, subsequently, that these are the only nodes 136 used for forwarding traffic. This approach relies on an assumption 137 that a trusted node is not, at the same time, misbehaving -- much 138 like a company, handing out a key to each employee, assuming that any 139 theft will be committed by people outside to the company. Complimen- 140 tary to this trusted/non-trusted discrimination of nodes, is the 141 ability to detect and deal with the situation where a trusted node 142 has become compromised. Specifically, to take a trusted node, detect 143 that it is misbehaving and then decide to classify that node as "non- 144 trusted" for exclusion from the network. This, however, opens an 145 additional vulnerability: a node can be malicious in that it 146 "denounces" other (non-malicious) nodes and manages to get these 147 excluded from the network. 149 While we do not, in the present version of this draft, concern our- 150 self with the solution-space, we do point out that any solutions must 151 be carefully scrutinized to prevent that they themselves introduce 152 other vulnerabilities. 154 1.1. Terminology 156 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC2119 [5]. 160 1.2. Applicability 162 This document aims at discussing the issues with securing proactive 163 MANET routing protocols in general and OLSR in particular. 165 2. Proactive MANET Routing Protocols and OLSR Vulnerabilities 167 In this section, we will discuss various security vulnerabilities in 168 proactive routing protocol for ad hoc networks. We will specifically 169 enumerate vulnerabilities in OLSR, however we point out that this 170 section does not emphasize ``flaws'' in the OLSR protocol. Rather, 171 the vulnerabilities are instances of what all proactive routing pro- 172 tocols are subject to. 174 When an ad hoc network is operating under a proactive routing proto- 175 col, each node has two different (but related) responsibilities. 176 Firstly, each node must correctly generate routing protocol control 177 traffic, conforming to the protocol specification. Secondly, each 178 node is responsible for forwarding routing protocol control traffic 179 on behalf of other nodes in the network. Thus incorrect behavior of a 180 node can result from either a node generating incorrect control mes- 181 sages or from incorrect relaying of control traffic from other nodes. 183 Correctly generating and forwarding control traffic can be considered 184 as a criterion for having a correctly functioning routing. In other 185 words, that the routing protocol is able to consistently provide a 186 correct view of the network topology in each network node. This 187 assumption implies that all nodes in the network correctly implement 188 the routing protocol - specifically that each node correctly pro- 189 cesses and emits control traffic. Note that this, in and by itself, 190 is not sufficient to ensure that data packets are being correctly 191 routed in the network. Indeed, independently of the routing protocol 192 being proactive or reactive, a misbehaving node may generate, process 193 and relay control traffic correctly while actually not perform data 194 traffic forwarding. 196 In the remainder of this section, we will investigate how these 197 incorrect behaviors may appear in OLSR. We note, that while we employ 198 OLSR for the purpose of our descriptions, much of the following 199 applies equally for other proactive routing protocols. 201 2.1. Jamming 203 One vulnerability, common for all routing protocols operating a wire- 204 less ad hoc network, is that of ``jamming'' - i.e. that a node gener- 205 ates massive amounts of interfering radio transmissions, which will 206 prevent legitimate traffic (e.g. control traffic for the routing pro- 207 tocol as well as data traffic) on part of a network. This vulnerabil- 208 ity cannot be dealt with at the routing protocol level (if at all), 209 leaving the network without the ability to maintain connectivity. 210 Jamming is somewhat similar to that of network overload and 211 subsequent denial of service: a sufficiently significant amount of 212 routing protocol control traffic is lost, preventing routes to be 213 constructed in the network. 215 2.2. Incorrect Traffic Generation 217 OLSR employs, basically, two different kinds of control traffic: 218 HELLO messages and TC messages. While there are other types of OLSR 219 messages (such as MID or HNA), they don't introduce any fundamentally 220 different issues, and we therefore concentrate on HELLOs and TCs. In 221 this section, we will describe how a non-conforming node may affect 222 the network connectivity through incorrect generation of HELLO and TC 223 messages. 225 In general, we observe that with respect to control traffic genera- 226 tion, a node may misbehave in two different ways: through generating 227 control traffic ``pretending'' to be another node (i.e. Identity 228 Spoofing) or through advertising incorrect information (links) in the 229 control messages (i.e. Link Spoofing). In both cases, the net effect 230 is, that incorrect link-state information is introduced into the net- 231 work. This incorrect information then leads to the algorithms of the 232 routing protocol to operate on incorrect data-sets and, possibly, 233 yield incorrect results as a concequence. 235 2.2.1. Incorrect HELLO Message Generation 237 In terms of HELLO messages, identity spoofing implies that a node 238 sends HELLO messages pretending to have the identity of another node. 239 E.g. node X sends HELLO messages with the originator address set to 240 that of node A, as illustrated in Figure 1. This may result in the 241 network containing conflicting routes to node A. Specifically, node X 242 will choose MPRs from among its neighbors, signaling this selection 243 pretending to have the identity of node A. The MPRs will, subse- 244 quently, advertise that they can provide ``last hop'' to node A in 245 their TC messages. Conflicting routes to node A, with possible loops, 246 may result from this. 248 ---------- 249 | | 250 | Node A | 251 | | 252 ---------- 253 | 254 | 255 ---------- ---------- ---------- 256 | | | | | | 257 | Node 1 |--| Node 2 |--| Node 3 | 258 | | | | | | 259 ---------- ---------- ---------- 260 | | 261 | | 262 ---------- ---------- ---------- 263 | | | | | | 264 | Node 4 |--| Node 5 |--| Node 6 | 265 | | | | | | 266 ---------- ---------- ---------- 267 | | 268 | | 269 ---------- ---------- 270 | | | | 271 | Node B |----------------| Node C | 272 | |\ /| | 273 ---------- \ / ---------- 274 \----------/ 275 | | 276 | Node X | 277 | | 278 ---------- 280 Figure 1: Identity Spoofing of Hello messages. Node X assumes 281 the identity of node A for sending HELLO messages. Node B and 282 node C may subsequently announce reachability to node A through 283 their TC messages. 285 Similarly, link spoofing implies that a node sends HELLO messages, 286 signaling an incorrect set of neighbors. This may take either of two 287 forms: if the set is incomplete, i.e. a node ``ignores'' some neigh- 288 bors, the network may be without connectivity to these ``ignored'' 289 neighbors. 291 Alternatively, a compromised node advertising a neighbor-relationship 292 to non-present nodes may cause inaccurate MPR selection with the 293 result that some nodes may not be reachable in the network. 295 2.2.2. Incorrect TC Message Generation 297 As for HELLO messages, identity spoofing with respect to TC messages 298 implies that a node sends TC messages, pretending to have the iden- 299 tity of another node. Effectively, this implies link spoofing since a 300 node assuming the identity of another node effectively advertises 301 incorrect links to the network. 303 Similarly, link spoofing implies that a node sends TC messages, 304 advertising an incorrect set of links. This may take either of two 305 forms: if the set is incomplete, i.e. a node ``ignores'' links to 306 some nodes in its MPR selector set, the network may be without con- 307 nectivity to these ``ignored'' neighbors - as well as to neighbors 308 which are reachable only through the ``ignored'' neighbors. A node 309 may also include non-existing links (i.e. links to non-neighbor 310 nodes) in a TC message. This is illustrated in Figure 2. Link spoof- 311 ing in TC messages may yield routing loops and conflicting routes in 312 the network. 314 A node could also simply fail to produce TC control traffic: a node 315 may correctly generate HELLO messages, be selected as MPR by other 316 nodes, and then not generate the TC messages that indicate it has MPR 317 selectors. The net concequence is, that some destinations may not be 318 advertised throughout the network and. 320 ---------- 321 | | 322 | Node A | 323 | | 324 ---------- 325 | 326 | 327 ---------- ---------- ---------- 328 | | | | | | 329 | Node 1 |--| Node 2 |--| Node 3 | 330 | | | | | | 331 ---------- ---------- ---------- 332 | | 333 | | 334 ---------- ---------- ---------- 335 | | | | | | 336 | Node 4 |--| Node 5 |--| Node 6 | 337 | | | | | | 338 ---------- ---------- ---------- 339 ^ | 340 ^ | 341 ---------- ---------- 342 | |->> ------------| | 343 | Node X | | Node 7 | 344 | |>> /| | 345 ---------- \ / ---------- 346 \----------/ 347 | | 348 | Node 8 | 349 | | 350 ---------- 352 Figure 2: Identity Spoofing of TC messages. Node X 353 generates incorrect TC messages, e.g. advertising 354 a link between node X and node A. 356 2.3. Incorrect Traffic Relaying 358 Nodes in a MANET relays two types of traffic: routing protocol con- 359 trol traffic and data traffic. A node may misbehave through failing 360 to forward either type of traffic correctly. 362 2.3.1. Incorrect Control Traffic Relaying 364 If TC messages (or routing protocol control messages in general) are 365 not properly relayed, connectivity loss may result. In networks where 366 no redundancy exists (e.g. in a ``strip'' network), connectivity loss 367 will surely result, while other topologies may provide redundant con- 368 nectivity. Similarly if a node does not forward data packets (e.g. if 369 intra-node forwarding is impaired), loss of connectivity may result. 371 2.3.2. Replay attack 373 A replay attack is, simply, where control traffic from one region of 374 the network is recorded and replayed in a different region (this type 375 of attack is also known as the Wormhole attack) This may, for exam- 376 ple, happen when two nodes collaborate on an attack, one recording 377 traffic in its proximity and tunneling it to the other node, which 378 replays the traffic. In a protocol where links are discovered by 379 testing reception, this will result in extraneous link creation 380 (basically, a link between the two ``attacking'' nodes). 382 While this may result from an attack, we note that it may also be 383 intentional: if data-traffic too is relayed over the virtual link 384 over the ``tunnel'', the link being detected is, indeed valid. This 385 is, for instance, used in wireless repeaters. If data traffic is not 386 carried over the virtual link, an imaginary, compromised, link has 387 been created. 389 Replay attacks can be especially damaging if coupled with spoofing 390 and playing with sequence numbers in the replayed messages, poten- 391 tially destroying some important topology information in nodes all 392 over the network. 394 2.3.3. Incorrect Data Traffic Relaying 396 Even a node correctly generating, processing and forwarding control 397 traffic as required, may act in a malicious way through not forward- 398 ing data traffic. The node thereby breaks connectivity in the network 399 (data traffic cannot get through) however this connectivity loss is 400 not detected by the routing protocol (control traffic is correctly 401 relayed). 403 While this indeed may be due to an attack, this type of situation is 404 also encountered simply due to misconfigured nodes: routing 405 capabilities (through IP forwarding) are typically disabled by 406 default in most operating systems, and must manually be enabled. 407 Failing to do so, effectively, triggers the situation where data 408 traffic is not forwarded/routed while control-traffic (which is for- 409 warded by action of the routing daemon) is transmitted correctly. 411 3. Authors' Addresses 413 Thomas Heide Clausen, 414 Project PCRI 415 Pole Commun de Recherche en Informatique du plateau de Saclay, 416 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 417 Ecole polytechnique, 418 Laboratoire d'informatique, 419 91128 Palaiseau Cedex, France 420 Phone: +33 1 69 33 40 73, 421 Email: T.Clausen@computer.org 423 Emmanuel Baccelli 424 HITACHI Labs Europe/ Project PCRI, 425 Pole Commun de Recherche en Informatique du plateau de Saclay, 426 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 427 Ecole polytechnique, 428 Laboratoire d'informatique, 429 91128 Palaiseau Cedex, France 430 Phone: +33 1 69 33 40 73, 431 Email: Emmanuel.Baccelli@inria.fr 433 4. Contributors 435 Thomas Heide Clausen, 436 Project PCRI 437 Pole Commun de Recherche en Informatique du plateau de Saclay, 438 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 439 Ecole polytechnique, 440 Laboratoire d'informatique, 441 91128 Palaiseau Cedex, France 442 Phone: +33 1 69 33 40 73, 443 Email: T.Clausen@computer.org 445 Emmanuel Baccelli 446 HITACHI Labs Europe/ Project PCRI, 447 Pole Commun de Recherche en Informatique du plateau de Saclay, 448 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 449 Ecole polytechnique, 450 Laboratoire d'informatique, 451 91128 Palaiseau Cedex, France 452 Phone: +33 1 69 33 40 73, 453 Email: Emmanuel.Baccelli@inria.fr 455 Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 456 Chesnay Cedex, France, Phone: +33 1 3963 5215, Email: 457 Cedric.Adjih@inria.fr 459 Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 460 Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: 461 Philippe.Jacquet@inria.fr 463 Anis Laouiti, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 464 Chesnay Cedex, France, Phone: +33 1 3963 5088, Email: 465 Anis.Laouiti@inria.fr 467 Paul Muhlethaler, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 468 Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email: 469 Paul.Muhlethaler@inria.fr 471 Daniele Raffo, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 472 Chesnay Cedex, France, Phone: +33 1 3963 5856, Email: 473 Daniele.Raffo@inria.fr 475 Christopher Dearlove, BAE SYSTEMS Advanced Technology Centre, Great 476 Baddow, Chelmsford, UK. Phone: +44 1245 242194 Email: 477 chris.dearlove@baesystems.com 479 5. References 481 [1] T. Clausen, P. Jacquet, RFC 3626: Optimized Link State Routing Pro- 482 tocol. Request for Comments (Experimental), Internet Engineering 483 Task Force, October 2003. 485 [2] T. Clausen, C. Adjih, P. Jacquet, A. Laouiti, P. Muhlethaler, D. 486 Raffo, Securing the OLSR Protocol. Proceeding of IFIP Med-Hoc-Net 487 2003, June 2003. 489 [3] T. Clausen, P. Jacquet, L. Viennot, Investigating the Impact of Par- 490 ital Topology in Proactive MANET Routing Protocols. Proceedings of 491 the Fifth Wireless Personal Multimedia Communications, November 492 2002. 494 [4] C. E. Perkins, E. M. Royer, S. R. Das, RFC 3561: Ad Hoc On-Demand 495 Distance Vector Routing. Internet Engineering Task Force, Request 496 For Comments (experimental), July 2003. 498 [5] R. Ogier, F. Templin, M. Lewis, RFC 3684: Topology Dissemination 499 Based on Reverse-Path Forwarding. Internet Engineering Task Force, 500 Request For Comments (experimental), February 2004. 502 [6] D. Johnson, D. Maltz, Y. Hu, draft-ietf-manet-dsr-10.txt: The 503 Dynamic Source Routing Protocol for Mobile Ad Hoc Networks. Inter- 504 net Engineering Task Force, Internet Draft (Work in Progress), July 505 2004. 507 [7] M. Zapata, draft-guerrero-manet-saodv-00.txt: Secure Ad Hoc On- 508 Demand Distance Vector Routing. Internet Engineering Task Force, 509 Internet Draft (Work in Progress), October 2002. 511 [8] Y. Hu, A. Perrig, D. Johnson, A Secure On-Demand Routing Protocol 512 for Ad Hoc Networks (Ariadne). Proceedings of MobiCom 2002, 513 September 2002. 515 [9] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized 516 Link State Routing Protocol - Evaluation Through Experiments and 517 Simulation. Proceedings of the Fourth Wireless Personal Multimedia 518 Communications, September 2001. 520 [10] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Effi- 521 cient Technique for Flooding in Mobile Wireless Networks. INRIA 522 Research Report RR-3898, Project Hipercom, March 2000. 524 6. Changes 526 This is the initial version of this specification. 528 7. IANA Considerations 530 This document does currently not specify IANA considerations. 532 8. Security Considerations 534 This document does not specify a protocol or a procedure. The docu- 535 ment is, however, reflections on security considerations for a class 536 of MANET routing protocols. 538 9. Copyright 540 Copyright (C) The Internet Society (2004). This document is subject 541 to the rights, licenses and restrictions contained in BCP 78, and 542 except as set forth therein, the authors retain all their rights. 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 547 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 548 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 549 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 550 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 On 15 Feb 2005, at 20:28, Dinara Suleymanova wrote: 554 The file name is too long. Please fix the problem by decreasing the number of 555 words and resubmit. 557 Thanks. 559 At 07:49 AM 2/14/2005, Thomas Heide clausen wrote: 560 Dear IETF Secretariat, 562 Please find attached the draft "Securing OLSR Problem Statement" 563 (draft-clausen-manet-securing-olsr-problem-statement-00.txt) 565 This draft aims at summarizing the security considerations, resulting from various 566 experience with OLSR (RFC3626). The draft aims as a starting point for considering 567 security in proactive manet routing -- mandated by the wg charter: "Routing 568 security requirements and issues will also be addressed" for future std. track 569 protocols. 571 If there are any questions or comments, please do not hesitate to contact me. 573 Sincerely, 575 --thomas 577 IETF MANET Working Group Emmanuel Baccelli (ed.) 578 Expiration: 14 August 2005 LIX, Ecole Polytechnique, France 579 14 February 2005 581 Securing OLSR Problem Statement 582 draft-clausen-manet-securing-olsr-problem-statement-00.txt 584 Status of this Memo 586 This document is a submission to the Mobile Adhoc NETworks (MANET) 587 Working Group of the Internet Engineering Task Force (IETF). Comments 588 should be submitted to the manet@ietf.org mailing list. 590 Distribution of this memo is unlimited. 592 By submitting this Internet-Draft, I certify that any applicable 593 patent or other IPR claims of which I am aware have been disclosed, 594 or will be disclosed, and any of which I become aware will be 595 disclosed, in accordance with RFC 3668. 597 This document is an Internet-Draft and is in full conformance with 598 all provisions of Section 10 of RFC 2026. 600 Internet-Drafts are working documents of the Internet Engineering 601 Task Force (IETF), its areas, and its working groups. Note that other 602 groups may also distribute working documents as Internet-Drafts. 604 Internet-Drafts are draft documents valid for a maximum of six months 605 and may be updated, replaced, or obsoleted by other documents at any 606 time. It is inappropriate to use Internet-Drafts as reference 607 material or to cite them other than as "work in progress." 609 The list of current Internet-Drafts can be accessed at 610 http://www.ietf.org/ietf/1id-abstracts.txt 612 The list of Internet-Draft Shadow Directories can be accessed at 613 http://www.ietf.org/shadow.html. 615 Abstract 617 In this draft, we examine security issues related to proactive 618 routing protocols for MANETs. Specifically, we investigate security 619 properties of OLSR and describe possible attacks against the 620 integrity of the network routing infrastructure. 622 Solutions exist, which address the vulnerabilities discussed in this 623 draft. The intent of this draft is not to discuss various solutions, 625 Clausen (ed.), Baccelli (ed.) 626 however to outline the vulnerabilities which a proactive manet 627 routing protocol is sensitive to. The design of a proactive manet 628 routing protocol should be flexible enough to accommodate a large 629 selection of the possible solutions. 631 Clausen (ed.), Baccelli (ed.) 632 Table of Contents 634 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 635 4 636 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 637 5 638 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 639 5 640 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641 6 642 2.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643 6 644 2.2. Incorrect Traffic Generation . . . . . . . . . . . . . . . . . 645 7 646 2.2.1. Incorrect HELLO Message Generation . . . . . . . . . . . . . 647 7 648 2.2.2. Incorrect TC Message Generation . . . . . . . . . . . . . . . 649 9 650 2.3. Incorrect Traffic Relaying . . . . . . . . . . . . . . . . . . 651 10 652 2.3.1. Incorrect Control Traffic Relaying . . . . . . . . . . . . . 653 11 654 2.3.2. Replay attack . . . . . . . . . . . . . . . . . . . . . . . . 655 11 656 2.3.3. Incorrect Data Traffic Relaying . . . . . . . . . . . . . . . 657 11 658 3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 659 12 660 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 661 12 662 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 663 13 664 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665 14 666 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 667 14 668 8. Security Considerations . . . . . . . . . . . . . . . . . . . . . 669 14 670 9. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671 15 673 Clausen (ed.), Baccelli (ed.) 674 1. Introduction 676 A Mobile Ad-hoc NETwork (MANET) is a collection of nodes which are 677 able to connect on a wireless medium forming an arbitrary and dynamic 678 network. Implicitly herein is the ability for the network topology to 679 change over time as links in the network appear and disappear. 681 In order to enable communication between any two nodes in such a 682 MANET, a routing protocol is employed. The abstract task of the rout- 683 ing protocol is to discover the topology (and, as the network is 684 dynamic, continuing changes to the topology) to ensure that each node 685 is able to acquire a recent image of the network topology for con- 686 structing routes. 688 Currently, two complementary classes of routing protocols exist in 689 the MANET world. Reactive protocols acquire routes on demand through 690 flooding a ``route request'' (which typically also records the path 691 taken) and receiving a ``route reply'' (typically signaling the path 692 taken by the route request to arrive at the destination node). I.e. 693 the required parts of the topology graph is constructed in a node 694 only when needed for data traffic communication. Reactive MANET rout- 695 ing protocols include AODV [4] and DSR [6]. 697 The other class of MANET routing protocols is proactive, i.e. the 698 routing protocol ensures that all nodes at all times have sufficient 699 topological information to construct routes to all destinations in 700 the network. This is achieved through periodic message exchange. 701 Proactive MANET routing protocols include OLSR [1] and TBRPF [5]. 703 A significant issue in the ad-hoc domain is that of the integrity of 704 the network itself. AODV, DSR, OLSR and TBRPF allow, according to 705 their specifications, any node to participate in the network - the 706 assumption being that all nodes are well-behaving and welcome. If 707 that assumptions fails - if the network may count malicious nodes - 708 the integrity of the network may fail. 710 An orthogonal security issue is that of maintaining confidentiality 711 and integrity of the data being exchanged between communications end- 712 points in the network (e.g. between a mail server and a mail client). 713 The task of ensuring end-to-end security of data communications in 714 MANETs is equivalent to that of securing end-to-end security in tra- 715 ditional wire-line networks, and is not considered further in this 716 draft. 718 The primary issue with respect to securing MANET routing protocols is 719 thus ensuring the network integrity, even in presence of malicious 720 nodes. Security extensions to the reactive protocols AODV and DSR 721 exist, in form of SAODV [7] and Ariadne [8]. Assuming that a 723 Clausen (ed.), Baccelli (ed.) 724 mechanism for key distribution is in place, these extensions employ 725 digital signatures on the route request and route reply messages. The 726 basic principle being that each node verifies the signature of a mes- 727 sage and - if valid - modifies the message (if applicable), signing 728 it itself before forwarding the message. 730 In this draft, we investigate the issues with security in proactive 731 MANET routing protocols in general, and OLSR in particular. 733 We point out, that there are different approaches to securing a 734 proactive MANET routing protocol in general, and OLSR in particular. 735 One such approach is to ensure that only ``trusted'' nodes are admit- 736 ted into the network and, subsequently, that these are the only nodes 737 used for forwarding traffic. This approach relies on an assumption 738 that a trusted node is not, at the same time, misbehaving -- much 739 like a company, handing out a key to each employee, assuming that any 740 theft will be committed by people outside to the company. Complimen- 741 tary to this trusted/non-trusted discrimination of nodes, is the 742 ability to detect and deal with the situation where a trusted node 743 has become compromised. Specifically, to take a trusted node, detect 744 that it is misbehaving and then decide to classify that node as "non- 745 trusted" for exclusion from the network. This, however, opens an 746 additional vulnerability: a node can be malicious in that it 747 "denounces" other (non-malicious) nodes and manages to get these 748 excluded from the network. 750 While we do not, in the present version of this draft, concern our- 751 self with the solution-space, we do point out that any solutions must 752 be carefully scrutinized to prevent that they themselves introduce 753 other vulnerabilities. 755 1.1. Terminology 757 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 758 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 759 document are to be interpreted as described in RFC2119 [5]. 761 1.2. Applicability 763 This document aims at discussing the issues with securing proactive 764 MANET routing protocols in general and OLSR in particular. 766 Clausen (ed.), Baccelli (ed.) 767 2. Proactive MANET Routing Protocols and OLSR Vulnerabilities 769 In this section, we will discuss various security vulnerabilities in 770 proactive routing protocol for ad hoc networks. We will specifically 771 enumerate vulnerabilities in OLSR, however we point out that this 772 section does not emphasize ``flaws'' in the OLSR protocol. Rather, 773 the vulnerabilities are instances of what all proactive routing pro- 774 tocols are subject to. 776 When an ad hoc network is operating under a proactive routing proto- 777 col, each node has two different (but related) responsibilities. 778 Firstly, each node must correctly generate routing protocol control 779 traffic, conforming to the protocol specification. Secondly, each 780 node is responsible for forwarding routing protocol control traffic 781 on behalf of other nodes in the network. Thus incorrect behavior of a 782 node can result from either a node generating incorrect control mes- 783 sages or from incorrect relaying of control traffic from other nodes. 785 Correctly generating and forwarding control traffic can be considered 786 as a criterion for having a correctly functioning routing. In other 787 words, that the routing protocol is able to consistently provide a 788 correct view of the network topology in each network node. This 789 assumption implies that all nodes in the network correctly implement 790 the routing protocol - specifically that each node correctly pro- 791 cesses and emits control traffic. Note that this, in and by itself, 792 is not sufficient to ensure that data packets are being correctly 793 routed in the network. Indeed, independently of the routing protocol 794 being proactive or reactive, a misbehaving node may generate, process 795 and relay control traffic correctly while actually not perform data 796 traffic forwarding. 798 In the remainder of this section, we will investigate how these 799 incorrect behaviors may appear in OLSR. We note, that while we employ 800 OLSR for the purpose of our descriptions, much of the following 801 applies equally for other proactive routing protocols. 803 2.1. Jamming 805 One vulnerability, common for all routing protocols operating a wire- 806 less ad hoc network, is that of ``jamming'' - i.e. that a node gener- 807 ates massive amounts of interfering radio transmissions, which will 808 prevent legitimate traffic (e.g. control traffic for the routing pro- 809 tocol as well as data traffic) on part of a network. This vulnerabil- 810 ity cannot be dealt with at the routing protocol level (if at all), 811 leaving the network without the ability to maintain connectivity. 812 Jamming is somewhat similar to that of network overload and 814 Clausen (ed.), Baccelli (ed.) 815 subsequent denial of service: a sufficiently significant amount of 816 routing protocol control traffic is lost, preventing routes to be 817 constructed in the network. 819 2.2. Incorrect Traffic Generation 821 OLSR employs, basically, two different kinds of control traffic: 822 HELLO messages and TC messages. While there are other types of OLSR 823 messages (such as MID or HNA), they don't introduce any fundamentally 824 different issues, and we therefore concentrate on HELLOs and TCs. 825 In 826 this section, we will describe how a non-conforming node may affect 827 the network connectivity through incorrect generation of HELLO and TC 828 messages. 830 In general, we observe that with respect to control traffic genera- 831 tion, a node may misbehave in two different ways: through generating 832 control traffic ``pretending'' to be another node (i.e. Identity 833 Spoofing) or through advertising incorrect information (links) in the 834 control messages (i.e. Link Spoofing). In both cases, the net effect 835 is, that incorrect link-state information is introduced into the net- 836 work. This incorrect information then leads to the algorithms of the 837 routing protocol to operate on incorrect data-sets and, possibly, 838 yield incorrect results as a concequence. 840 2.2.1. Incorrect HELLO Message Generation 842 In terms of HELLO messages, identity spoofing implies that a node 843 sends HELLO messages pretending to have the identity of another node. 844 E.g. node X sends HELLO messages with the originator address set to 845 that of node A, as illustrated in Figure 1. This may result in the 846 network containing conflicting routes to node A. Specifically, node X 847 will choose MPRs from among its neighbors, signaling this selection 848 pretending to have the identity of node A. The MPRs will, subse- 849 quently, advertise that they can provide ``last hop'' to node A in 850 their TC messages. Conflicting routes to node A, with possible loops, 851 may result from this. 853 Clausen (ed.), Baccelli (ed.) 854 ---------- 855 | | 856 | Node A | 857 | | 858 ---------- 859 | 860 | 861 ---------- ---------- ---------- 862 | | | | | | 863 | Node 1 |--| Node 2 |--| Node 3 | 864 | | | | | | 865 ---------- ---------- ---------- 866 | | 867 | | 868 ---------- ---------- ---------- 869 | | | | | | 870 | Node 4 |--| Node 5 |--| Node 6 | 871 | | | | | | 872 ---------- ---------- ---------- 873 | | 874 | | 875 ---------- ---------- 876 | | | | 877 | Node B |----------------| Node C | 878 | |\ /| | 879 ---------- \ / ---------- 880 \----------/ 881 | | 882 | Node X | 883 | | 884 ---------- 886 Figure 1: Identity Spoofing of Hello messages. Node X assumes 887 the identity of node A for sending HELLO messages. Node B and 888 node C may subsequently announce reachability to node A through 889 their TC messages. 891 Similarly, link spoofing implies that a node sends HELLO messages, 892 signaling an incorrect set of neighbors. This may take either of two 893 forms: if the set is incomplete, i.e. a node ``ignores'' some neigh- 894 bors, the network may be without connectivity to these ``ignored'' 895 neighbors. 897 Alternatively, a compromised node advertising a neighbor-relationship 898 to non-present nodes may cause inaccurate MPR selection with the 899 result that some nodes may not be reachable in the network. 901 Clausen (ed.), Baccelli (ed.) 902 2.2.2. Incorrect TC Message Generation 904 As for HELLO messages, identity spoofing with respect to TC messages 905 implies that a node sends TC messages, pretending to have the iden- 906 tity of another node. Effectively, this implies link spoofing since a 907 node assuming the identity of another node effectively advertises 908 incorrect links to the network. 910 Similarly, link spoofing implies that a node sends TC messages, 911 advertising an incorrect set of links. This may take either of two 912 forms: if the set is incomplete, i.e. a node ``ignores'' links to 913 some nodes in its MPR selector set, the network may be without con- 914 nectivity to these ``ignored'' neighbors - as well as to neighbors 915 which are reachable only through the ``ignored'' neighbors. A node 916 may also include non-existing links (i.e. links to non-neighbor 917 nodes) in a TC message. This is illustrated in Figure 2. Link spoof- 918 ing in TC messages may yield routing loops and conflicting routes in 919 the network. 921 A node could also simply fail to produce TC control traffic: a node 922 may correctly generate HELLO messages, be selected as MPR by other 923 nodes, and then not generate the TC messages that indicate it has MPR 924 selectors. The net concequence is, that some destinations may not be 925 advertised throughout the network and. 927 Clausen (ed.), Baccelli (ed.) 928 ---------- 929 | | 930 | Node A | 931 | | 932 ---------- 933 | 934 | 935 ---------- ---------- ---------- 936 | | | | | | 937 | Node 1 |--| Node 2 |--| Node 3 | 938 | | | | | | 939 ---------- ---------- ---------- 940 | | 941 | | 942 ---------- ---------- ---------- 943 | | | | | | 944 | Node 4 |--| Node 5 |--| Node 6 | 945 | | | | | | 946 ---------- ---------- ---------- 947 ^ | 948 ^ | 949 ---------- ---------- 950 | |->> ------------| | 951 | Node X | | Node 7 | 952 | |>> /| | 953 ---------- \ / ---------- 954 \----------/ 955 | | 956 | Node 8 | 957 | | 958 ---------- 960 Figure 2: Identity Spoofing of TC messages. Node X 961 generates incorrect TC messages, e.g. advertising 962 a link between node X and node A. 964 2.3. Incorrect Traffic Relaying 966 Nodes in a MANET relays two types of traffic: routing protocol con- 967 trol traffic and data traffic. A node may misbehave through failing 968 to forward either type of traffic correctly. 970 Clausen (ed.), Baccelli (ed.) 971 2.3.1. Incorrect Control Traffic Relaying 973 If TC messages (or routing protocol control messages in general) are 974 not properly relayed, connectivity loss may result. In networks where 975 no redundancy exists (e.g. in a ``strip'' network), connectivity loss 976 will surely result, while other topologies may provide redundant con- 977 nectivity. Similarly if a node does not forward data packets (e.g. if 978 intra-node forwarding is impaired), loss of connectivity may result. 980 2.3.2. Replay attack 982 A replay attack is, simply, where control traffic from one region of 983 the network is recorded and replayed in a different region (this type 984 of attack is also known as the Wormhole attack) This may, for exam- 985 ple, happen when two nodes collaborate on an attack, one recording 986 traffic in its proximity and tunneling it to the other node, which 987 replays the traffic. In a protocol where links are discovered by 988 testing reception, this will result in extraneous link creation 989 (basically, a link between the two ``attacking'' nodes). 991 While this may result from an attack, we note that it may also be 992 intentional: if data-traffic too is relayed over the virtual link 993 over the ``tunnel'', the link being detected is, indeed valid. This 994 is, for instance, used in wireless repeaters. If data traffic is not 995 carried over the virtual link, an imaginary, compromised, link has 996 been created. 998 Replay attacks can be especially damaging if coupled with spoofing 999 and playing with sequence numbers in the replayed messages, poten- 1000 tially destroying some important topology information in nodes all 1001 over the network. 1003 2.3.3. Incorrect Data Traffic Relaying 1005 Even a node correctly generating, processing and forwarding control 1006 traffic as required, may act in a malicious way through not forward- 1007 ing data traffic. The node thereby breaks connectivity in the network 1008 (data traffic cannot get through) however this connectivity loss is 1009 not detected by the routing protocol (control traffic is correctly 1010 relayed). 1012 While this indeed may be due to an attack, this type of situation is 1013 also encountered simply due to misconfigured nodes: routing 1015 Clausen (ed.), Baccelli (ed.) 1016 capabilities (through IP forwarding) are typically disabled by 1017 default in most operating systems, and must manually be enabled. 1018 Failing to do so, effectively, triggers the situation where data 1019 traffic is not forwarded/routed while control-traffic (which is for- 1020 warded by action of the routing daemon) is transmitted correctly. 1022 3. Authors' Addresses 1024 Thomas Heide Clausen, 1025 Project PCRI 1026 Pole Commun de Recherche en Informatique du plateau de Saclay, 1027 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 1028 Ecole polytechnique, 1029 Laboratoire d'informatique, 1030 91128 Palaiseau Cedex, France 1031 Phone: +33 1 69 33 40 73, 1032 Email: T.Clausen@computer.org 1034 Emmanuel Baccelli 1035 HITACHI Labs Europe/ Project PCRI, 1036 Pole Commun de Recherche en Informatique du plateau de Saclay, 1037 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 1038 Ecole polytechnique, 1039 Laboratoire d'informatique, 1040 91128 Palaiseau Cedex, France 1041 Phone: +33 1 69 33 40 73, 1042 Email: Emmanuel.Baccelli@inria.fr 1044 4. Contributors 1046 Thomas Heide Clausen, 1047 Project PCRI 1048 Pole Commun de Recherche en Informatique du plateau de Saclay, 1049 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 1050 Ecole polytechnique, 1051 Laboratoire d'informatique, 1052 91128 Palaiseau Cedex, France 1053 Phone: +33 1 69 33 40 73, 1054 Email: T.Clausen@computer.org 1056 Emmanuel Baccelli 1057 HITACHI Labs Europe/ Project PCRI, 1059 Clausen (ed.), Baccelli (ed.) 1060 Pole Commun de Recherche en Informatique du plateau de Saclay, 1061 CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud, 1062 Ecole polytechnique, 1063 Laboratoire d'informatique, 1064 91128 Palaiseau Cedex, France 1065 Phone: +33 1 69 33 40 73, 1066 Email: Emmanuel.Baccelli@inria.fr 1068 Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 1069 Chesnay Cedex, France, Phone: +33 1 3963 5215, Email: 1070 Cedric.Adjih@inria.fr 1072 Philippe Jacquet, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 1073 Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: 1074 Philippe.Jacquet@inria.fr 1076 Anis Laouiti, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 1077 Chesnay Cedex, France, Phone: +33 1 3963 5088, Email: 1078 Anis.Laouiti@inria.fr 1080 Paul Muhlethaler, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 1081 Le Chesnay Cedex, France, Phone: +33 1 3963 5278, Email: 1082 Paul.Muhlethaler@inria.fr 1084 Daniele Raffo, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le 1085 Chesnay Cedex, France, Phone: +33 1 3963 5856, Email: 1086 Daniele.Raffo@inria.fr 1088 Christopher Dearlove, BAE SYSTEMS Advanced Technology Centre, Great 1089 Baddow, Chelmsford, UK. Phone: +44 1245 242194 Email: 1090 chris.dearlove@baesystems.com 1092 5. References 1094 [1] T. Clausen, P. Jacquet, RFC 3626: Optimized Link State Routing Pro- 1095 tocol. Request for Comments (Experimental), Internet Engineering 1096 Task Force, October 2003. 1098 [2] T. Clausen, C. Adjih, P. Jacquet, A. Laouiti, P. Muhlethaler, D. 1099 Raffo, Securing the OLSR Protocol. Proceeding of IFIP Med-Hoc-Net 1100 2003, June 2003. 1102 Clausen (ed.), Baccelli (ed.) 1103 [3] T. Clausen, P. Jacquet, L. Viennot, Investigating the Impact of Par- 1104 ital Topology in Proactive MANET Routing Protocols. Proceedings of 1105 the Fifth Wireless Personal Multimedia Communications, November 1106 2002. 1108 [4] C. E. Perkins, E. M. Royer, S. R. Das, RFC 3561: Ad Hoc On-Demand 1109 Distance Vector Routing. Internet Engineering Task Force, Request 1110 For Comments (experimental), July 2003. 1112 [5] R. Ogier, F. Templin, M. Lewis, RFC 3684: Topology Dissemination 1113 Based on Reverse-Path Forwarding. Internet Engineering Task Force, 1114 Request For Comments (experimental), February 2004. 1116 [6] D. Johnson, D. Maltz, Y. Hu, draft-ietf-manet-dsr-10.txt: The 1117 Dynamic Source Routing Protocol for Mobile Ad Hoc Networks. 1118 Inter- 1119 net Engineering Task Force, Internet Draft (Work in Progress), July 1120 2004. 1122 [7] M. Zapata, draft-guerrero-manet-saodv-00.txt: Secure Ad Hoc On- 1123 Demand Distance Vector Routing. Internet Engineering Task Force, 1124 Internet Draft (Work in Progress), October 2002. 1126 [8] Y. Hu, A. Perrig, D. Johnson, A Secure On-Demand Routing Protocol 1127 for Ad Hoc Networks (Ariadne). Proceedings of MobiCom 2002, 1128 September 2002. 1130 [9] T. Clausen, G. Hansen, L. Christensen, G. Behrmann, The Optimized 1131 Link State Routing Protocol - Evaluation Through Experiments and 1132 Simulation. Proceedings of the Fourth Wireless Personal Multimedia 1133 Communications, September 2001. 1135 [10] A. Qayyum, L. Viennot, A. Laouiti, Multipoint relaying: An Effi- 1136 cient Technique for Flooding in Mobile Wireless Networks. INRIA 1137 Research Report RR-3898, Project Hipercom, March 2000. 1139 6. Changes 1141 This is the initial version of this specification. 1143 7. IANA Considerations 1145 This document does currently not specify IANA considerations. 1147 8. Security Considerations 1149 This document does not specify a protocol or a procedure. The docu- 1150 ment is, however, reflections on security considerations for a class 1151 of MANET routing protocols. 1153 Clausen (ed.), Baccelli (ed.) 1154 9. Copyright 1156 Copyright (C) The Internet Society (2004). This document is subject 1157 to the rights, licenses and restrictions contained in BCP 78, and 1158 except as set forth therein, the authors retain all their rights. 1160 This document and the information contained herein are provided on an 1161 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1162 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1163 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1164 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 1165 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 1166 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.