idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-sec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6130, updated by this document, for RFC5378 checks: 2006-06-21) -- 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 (August 14, 2013) is 3879 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) == Outdated reference: A later version (-06) exists of draft-ietf-manet-rfc6622-bis-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) U. Herberg 3 Internet-Draft Fujitsu Laboratories of America 4 Updates: 6130, xxxx (if approved) C. Dearlove 5 Intended status: Standards Track BAE Systems ATC 6 Expires: February 15, 2014 T. Clausen 7 LIX, Ecole Polytechnique 8 August 14, 2013 10 Integrity Protection for Control Messages in NHDP and OLSRv2 11 draft-ietf-manet-nhdp-olsrv2-sec-04 13 Abstract 15 This document specifies integrity and replay protection for the MANET 16 Neighborhood Discovery Protocol (NHDP) and the Optimized Link State 17 Routing Protocol version 2 (OLSRv2). This protection is achieved by 18 using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp 19 TLV based on POSIX time. 21 The mechanism in this specification can also be used for other 22 protocols that use the generalized packet/message format described in 23 RFC 5444. 25 This document updates RFC 6130 and RFC xxxx by mandating the 26 implementation of this integrity and replay protection in NHDP and 27 OLSRv2. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 15, 2014. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 66 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 67 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Message Generation and Processing . . . . . . . . . . . . . . 9 69 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 9 70 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 10 71 6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 10 72 6.3.1. Validating a Message Based on Timestamp . . . . . . . 11 73 6.3.2. Validating a Message Based on Integrity Check . . . . 12 74 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 12 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 13 78 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 13 79 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 13 80 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 13 81 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 [RFC Editor note: Please replace "xxxx" throughout this document with 91 the RFC number assigned to [OLSRv2], and remove this note.] 93 This specification updates [RFC6130] and [OLSRv2] by defining a 94 framework of security mechanisms (for integrity and replay 95 protection) that must be included in conforming implementations of 96 those protocols (the Neighborhood Discovery Protocol, NHDP, and the 97 Optimized Link State Routing Protocol version 2, OLSRv2). A 98 deployment of these protocols may choose to employ alternative(s) to 99 these mechanisms, in particular it may choose to protect packets 100 rather than messages, it may choose to use an alternative integrity 101 check value (ICV) with preferred properties, and/or it may use an 102 alternative timestamp. A deployment may choose to use no such 103 security mechanisms, but this is not recommended. 105 The mechanisms specified are the use of an ICV for protection of the 106 protocols' control messages, and the use of timestamps in those 107 messages to prevent replay attacks. Both use the TLV mechanism 108 specified in [RFC5444] to add this information to the messages. 109 These ICV and TIMESTAMP TLVs are defined in [RFC6622bis]. Different 110 ICV TLVs are used for HELLO messages in NHDP and TC (Topology 111 Control) messages in OLSRv2, the former also protecting the source 112 address of the IP datagram that contains the HELLO message. This is 113 because the IP datagram source address is used by NHDP to determine 114 the address of a neighbor interface, and is not necessarily otherwise 115 contained in the HELLO message, while OLSRv2's TC message is 116 forwarded in a new packet, and thus has no single IP datagram source 117 address. 119 The mechanism specified in this document is placed in the packet/ 120 message processing flow as indicated in Figure 1. It exists between 121 the packet parsing/generation function of [RFC5444], and the message 122 processing/generation function of NHDP and OLSRv2. 124 | | 125 Incoming | /|\ Outgoing 126 packet \|/ | packet 127 | | 128 +--------------------------------+ 129 | | 130 | RFC5444 packet | 131 | parsing / generation | 132 | | 133 +--------------------------------+ 134 | | 135 Messages | /|\ Messages with 136 \|/ | added TLVs 137 | | 138 D +--------------------------------+ 139 R /__________________ | Mechanism specified in | 140 O \ Messages | this document | 141 P (failed check) | | 142 +--------------------------------+ 143 | | 144 Messages | /|\ Messages 145 (passed check) \|/ | 146 | | 147 +--------------------------------+ 148 | | 149 | NHDP/OLSRv2 message | 150 | processing / generation | 151 | | 152 +--------------------------------+ 154 Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 [RFC2119]. 163 Additionally, this document uses the terminology and notation of 164 [RFC5444], [RFC6130], [OLSRv2], and [RFC6622bis]. 166 3. Applicability Statement 168 [RFC6130] and [OLSRv2] enable specifications of extensions to 169 recognize additional reasons for rejecting a message as "badly formed 170 and therefore invalid for processing", and mention security 171 (integrity protection) as an explicit example. This document 172 specifies a framework that provides this functionality. 174 Implementations of [RFC6130] and [OLSRv2] MUST include this 175 framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this 176 framework, except for when a different security mechanism is more 177 appropriate. 179 The applicability of this framework is determined by its 180 characteristics, which are that it: 182 o Specifies a security framework that is required to be included in 183 conforming implementations of [RFC6130] and [OLSRv2]. 185 o Specifies an association of ICVs with protocol messages, and 186 specifies how to use a missing or invalid ICV as an reason to 187 reject a message as "badly formed and therefore invalid for 188 processing". 190 o Specifies the implementation of an ICV Message TLV, defined in 191 [RFC6622bis], using a SHA-256 based HMAC applied to the 192 appropriate message contents (and for HELLO messages also 193 including the IP datagram source address). Deployments of 194 [RFC6130] and [OLSRv2] using this framework SHOULD use an HMAC/ 195 SHA-256 ICV TLV, except when use of a different algorithm is more 196 appropriate in a deployment. An implementation MAY use more than 197 one ICV TLV in a message, as long as they each use a different 198 algorithm to calculate the ICV. 200 o Specifies the implementation of a TIMESTAMP Message TLV, defined 201 in [RFC6622bis], to provide message replay protection. 202 Deployments of [RFC6130] and [OLSRv2] using this framework SHOULD 203 use a POSIX time based timestamp, if the clocks in all routers in 204 the network can be synchronized with sufficient precision. 206 o Assumes that a router that is able to generate correct integrity 207 check values is considered trusted. 209 This framework does not: 211 o Specify which key identifiers are to be used in a MANET in which 212 the routers share more than one secret key. (Such keys will be 213 differentiated using the field defined in an ICV TLV in 214 [RFC6622bis].) 216 o Specify how to distribute cryptographic material (shared secret 217 key(s)). 219 o Specify how to detect compromised routers with valid keys. 221 o Specify how to handle (revoke) compromised routers with valid 222 keys. 224 4. Protocol Overview and Functioning 226 The framework specified in this document provides the following 227 functionalities for use with messages specified by [RFC6130] and 228 [OLSRv2]: 230 o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for 231 inclusion in an outgoing message. An implementation of [RFC6130] 232 and [OLSRv2] MAY use more than one ICV TLV in a message, even with 233 the same type extension, but these ICV TLVs MUST each use a 234 different algorithm to calculate the ICV, e.g., with different 235 hash and/or cryptographic functions when using type extension 1 or 236 2. An implementation of [RFC6130] and [OLSRv2] MUST at least be 237 able to generate an ICV TLV using HMAC/SHA-256 and one or more 238 secret keys shared by all routers. 240 o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis]) 241 for inclusion in an outgoing message. An implementation of 242 [RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message, 243 but MUST NOT use the same type extension. An implementation of 244 [RFC6130] and [OLSRv2] that is able to synchronize the clocks in 245 all routers in the network with sufficient precision, MUST at 246 least be able to generate a TIMESTAMP TLV using POSIX time. 248 o Verification of ICV Message TLVs contained in a message, in order 249 to determine if this message MUST be rejected as "badly formed and 250 therefore invalid for processing" [RFC6130] [OLSRv2]. An 251 implementation of [RFC6130] and [OLSRv2] MUST at least be able to 252 verify an ICV TLV using HMAC/SHA-256 and one or more secret keys 253 shared by all routers. 255 o Verification of TIMESTAMP Message TLVs (as defined in 256 [RFC6622bis]) contained in a message, in order to determine if 257 this message MUST be rejected as "badly formed and therefore 258 invalid for processing" [RFC6130] [OLSRv2]. An implementation of 259 [RFC6130] and [OLSRv2] that is able to synchronize the clocks in 260 all routers in the network with sufficient precision, MUST at 261 least be able to verify a TIMESTAMP TLV using POSIX time. 263 ICV Packet TLVs (as defined in [RFC6622bis]) MAY be used by a 264 deployment of the multiplexing process defined in [RFC5444], either 265 as well as, or instead of, the protection of the NHDP and OLSRv2 266 messages. (Note that in the case of NHDP, the packet protection is 267 equally good, and also protects the packet header. In the case of 268 OLSRv2, the packet protection has different properties than the 269 message protection, especially for some forms of ICV. When packets 270 contain more than one message, the packet protection has lower 271 overheads in space and computation time.) 273 When a router generates a message on a MANET interface, this 274 framework: 276 o Specifies how to calculate an integrity check value for the 277 message. 279 o Specifies how to include that integrity check value using an ICV 280 Message TLV. 282 [RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to 283 processing by NHDP or OLSRv2. This framework, when used, specifies 284 that a message MUST be rejected if the ICV Message TLV is absent, or 285 its value cannot be verified. Note that this means that routers 286 whose implementation of NHDP and/or OLSRv2 does not include this 287 specification will be ignored by routers using this framework, and 288 these two sets of routers will, by design, form disjoint MANETs. 289 (The unsecured MANET will retain some information about the secured 290 MANET, but be unable to use it, not having any recognized symmetric 291 links with the secured MANET.) 293 5. Parameters 295 This following router parameters are specified for use by the two 296 protocols; the first is required only by NHDP, but may be visible to 297 OLSRv2, the second is required only by OLSRv2: 299 o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to 300 be validated may have. If the current POSIX time of the router 301 validating the HELLO message, minus the timestamp indicated in the 302 TIMESTAMP TLV of the HELLO message, is greater than 303 MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently 304 discarded. 306 o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be 307 validated may have. If the current POSIX time of the router 308 validating the TC message, minus the timestamp indicated in the 309 TIMESTAMP TLV of the TC message, is greater than 310 MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded. 312 The following constraints apply to these parameters: 314 o MAX_HELLO_TIMESTAMP_DIFF > 0 316 o MAX_TC_TIMESTAMP_DIFF > 0 318 These bounds are however insufficient, MAX_HELLO_TIMESTAMP_DIFF and 319 MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected 320 "age" of a message (i.e., the time difference between a message has 321 been sent by a router and received by all intended destinations). 322 For HELLO messages this needs only cover a single hop, but TC 323 messages may have been forwarded a number of times. In particular 324 for TC messages, if using jitter as specified in [OLSRv2] and 325 [RFC5148], the largest contribution the age may be a delay of up to 326 F_MAXJITTER per hop (except the final hop) that the message has 327 traveled. Other factors in the delay of both message types, per hop, 328 may include the link-layer that is used in the MANET, and CPU and 329 memory resources of routers (e.g., queuing delays, and delays for 330 processing ICVs). An implementation MAY set lower and/or upper 331 bounds on these parameters, if so, then these MUST allow values 332 meeting these requirements. An implementation MAY make its value of 333 MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC 334 message has traveled. 336 The above constraints assume ideal time synchronization of the clock 337 in all routers in the network. The parameters 338 MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any 339 constraints on them) MAY be increased to allow for expected timing 340 differences between routers (between neighboring routers for 341 MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but 342 usually not per hop, for MAX_TC_TIMESTAMP_DIFF). 344 Note that excessively large values of these parameters defeats their 345 objectives, so these parameters SHOULD be as large as is required, 346 but not significantly larger. 348 Using POSIX time allows a resolution of no more than one second. In 349 many MANET use cases, time synchronization much below one second is 350 not possible because of unreliable and high-delay channels, mobility, 351 interrupted communication, and possible limited resources. 353 In addition, when using the default message intervals and validity 354 times as specified in [RFC6130] and [OLSRv2], where the shortest 355 periodic message interval is 2 seconds, repeating the message within 356 a second is actually beneficial rather than harmful (at a small 357 bandwidth cost). Also, the use of [RFC5148] jitter can cause a 358 message to take that long or more to traverse the MANET, thus even in 359 a perfectly synchronized network, the TC maximum delay would usually 360 be greater than 1 second. 362 A finer granulatity than 1 second, and thus the use of an alternative 363 timestamp, is however RECOMMENDED in cases where, possibly due to 364 fast moving routers, message validity times are below 1 second. 366 6. Message Generation and Processing 368 This section specifies how messages are generated and processed by 369 [RFC6130] and [OLSRv2] when using this framework. 371 6.1. Message Content 373 Messages MUST have the content specified in [RFC6130] and [OLSRv2] 374 respectively. In addition, messages that conform to this framework 375 will contain: 377 o At least one ICV Message TLV (as specified in [RFC6622bis]), 378 generated according to Section 6.2. Implementations of [RFC6130] 379 and [OLSRv2] MUST support the following version of the ICV TLV, 380 but other versions MAY be used instead, or in addition, in a 381 deployment, if more appropriate: 383 * For TC messages: 385 + type-extension := 1 387 * For HELLO messages: 389 + type-extension := 2 391 * hash-function := 3 (SHA-256) 393 * cryptographic-function := 3 (HMAC) 395 The ICV Value MAY be truncated as specified in [RFC6622bis]; the 396 selection of an appropriate length MAY be administratively 397 configured. A message MAY contain several ICV Message TLVs. 399 o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]), 400 generated according to Section 6.2. Implementations of [RFC6130] 401 and [OLSRv2] using this framework MUST support the following 402 version of the TIMESTAMP TLV, but other versions MAY be used 403 instead, or in addition, in a deployment, if more appropriate: 405 * type-extension := 1 407 6.2. Message Generation 409 After message generation (Section 11.1 of [RFC6130] and Section 16.1. 410 of [OLSRv2]) and before message transmission (Section 11.2 of 411 [RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs 412 specified in Section 6.1 MUST (unless already present) be added to an 413 outgoing message when using this framework. 415 The following processing steps (when using a single timestamp version 416 and a single ICV algorithm) MUST be performed for a cryptographic 417 algorithm that is used for generating an ICV for a message: 419 1. All ICV TLVs (if any) are temporarily removed from the message. 420 Any temporarily removed ICV TLVs MUST be stored, in order to be 421 reinserted into the message in step 5. The message size and 422 Message TLV Block size are updated accordingly. 424 2. and , if present, are temporarily 425 set to 0. 427 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to 428 the Message TLV Block. The message size and Message TLV block 429 size are updated accordingly. 431 4. A TLV of type ICV, as specified in Section 6.1, is added to the 432 Message TLV Block. The message size and Message TLV block size 433 are updated accordingly. 435 5. All ICV TLVs that were temporary removed in step 1, are restored. 436 The message size and Message TLV Block size are updated 437 accordingly. 439 6. and , if present, are restored to 440 their previous values. 442 An implementation MAY add either alternative TIMESTAMP and/or ICV 443 TLVs, or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs 444 MUST be inserted before adding ICV TLVs. 446 6.3. Message Processing 448 Both [RFC6130] and [OLSRv2] specify that: 450 "On receiving a ... message, a router MUST first check if the 451 message is invalid for processing by this router" 453 [RFC6130] and [OLSRv2] proceed to give a number of conditions that, 454 each, will lead to a rejection of the message as "badly formed and 455 therefore invalid for processing". When using a single timestamp 456 version, and a single ICV algorithm, the following conditions to that 457 list, each of which, if true, MUST cause NHDP or OLSRv2 (as 458 appropriate) to consider the message as invalid for processing when 459 using this framework: 461 1. The Message TLV Block of the message does not contain exactly one 462 TIMESTAMP TLV of the selected version. This version 463 specification includes the type extension. (The Message TLV 464 Block may also contain TIMESTAMP TLVs of other versions.) 466 2. The Message TLV block does not contain exactly one ICV TLV using 467 the selected algorithm and key identifier. This algorithm 468 specification includes the type extension, and for type 469 extensions 1 and 2, the hash function and cryptographic function. 470 (The Message TLV Block may also contain ICV TLVs using other 471 algorithms and key identifiers.) 473 3. Validation of the identified (in step 1) TIMESTAMP TLV in the 474 Message TLV block of the message fails, as according to 475 Section 6.3.1. 477 4. Validation of the identified (in step 2) ICV TLV in the Message 478 TLV block of the message fails, as according to Section 6.3.2. 480 An implementation MAY check the existence of, and verify, either 481 alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP 482 and/or ICV TLVs. 484 6.3.1. Validating a Message Based on Timestamp 486 For a TIMESTAMP Message TLV with type extension 1 (POSIX time) 487 identified as described in Section 6.2: 489 1. If the current POSIX time minus the value of that TIMESTAMP TLV 490 is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or 491 MAX_TC_TIMESTAMP_DIFF (for a TC message) then the message 492 validation fails. 494 2. Otherwise, the message validation succeeds. 496 If a deployment chooses to use a different type extension from 1, 497 appropriate measures MUST be taken to verify freshness of the 498 message. 500 6.3.2. Validating a Message Based on Integrity Check 502 For an ICV Message TLV identified as described in Section 6.2: 504 1. All ICV Message TLVs (including the identified ICV Message TLV) 505 are temporarily removed from the message, and the message size 506 and Message TLV block size are updated accordingly. 508 2. The message's and fields are 509 temporarily set to 0. 511 3. Calculate the integrity check value for the parameters specified 512 in the identified ICV Message TLV, as specified in [RFC6622bis]. 514 4. If this integrity check value differs from the value of 515 in the ICV Message TLV, then the message validation 516 fails. If the has been truncated (as specified in 517 [RFC6622bis], the integrity check value calculated in the 518 previous step MUST be truncated to the TLV length of the ICV 519 Message TLV before comparing it with the . 521 5. Otherwise, the message validation succeeds. The message's 522 and fields are restored to their 523 previous value, and the ICV Message TLVs are returned to the 524 message, whose size is updated accordingly. 526 7. Provisioning of Routers 528 Before a router using this framework is able to generate ICVs or 529 validate messages, it MUST acquire the shared secret key(s) to be 530 used by all routers that are to participate in the network. This 531 specification does not define how a router acquires secret keys. 532 Once a router has acquired suitable key(s) it MAY be configured to 533 use, or not use, this framework. Section 23.6 of [OLSRv2] provides a 534 rationale based on [BCP107] why no key management is specified for 535 OLSRv2. 537 8. IANA Considerations 539 This document has no actions for IANA. 541 [This section may be removed by the RFC Editor.] 543 9. Security Considerations 545 This document specifies a security framework for use with NHDP and 546 OLSRv2 that allows for alleviating several security threats. 548 9.1. Alleviated Attacks 550 This section briefly summarizes security threats that are alleviated 551 by the framework presented in this document. 553 9.1.1. Identity Spoofing 555 As only routers possessing the selected shared secret key are able to 556 add a valid ICV TLV to a message, identity spoofing, where an 557 attacker falsely claims an identity of a valid router, is countered. 559 9.1.2. Link Spoofing 561 Link spoofing, where an attacker falsely represents the existence of 562 a non-existent link, or otherwise misrepresents a link's state, is 563 countered by the framework specified in this document, using the same 564 argument as in Section 9.1.1. 566 9.1.3. Replay Attack 568 Replay attacks are partly countered by the framework specified in 569 this document, but this depends on synchronized clocks of all routers 570 in the MANET. An attacker that records messages to replay them later 571 can only do so in the selected time interval after the timestamp that 572 is contained in message. As an attacker cannot modify the content of 573 this timestamp (as it is protected by the identity check value), an 574 attacker cannot replay messages after this time. Within this time 575 interval it is still possible to perform replay attacks, however the 576 limits on the time interval are specified so that this will have a 577 limited effect on the operation of the protocol. 579 9.2. Limitations 581 If no synchronized clocks are available in the MANET, replay attacks 582 cannot be countered by the framework provided by this document. An 583 alternative version of the TIMESTAMP TLV defined in [RFC6622bis], 584 with a monotonic sequence number, may have some partial value in this 585 case, but will necessitate adding state to record observed message 586 sequence number information. 588 The framework provided by this document does not avoid or detect 589 security attacks by routers possessing the shared secret key that is 590 used to generate integrity check values for messages. 592 This framework relies on an out-of-band protocol or mechanism for 593 distributing the shared secret key(s) (and if an alternative 594 integrity check value is used, any additional cryptographic 595 parameters). 597 This framework does not provide a key revocation mechanism. 599 10. Acknowledgments 601 The authors would like to gratefully acknowledge the following 602 people: Henning Rogge (Frauenhofer FKIE). 604 11. References 606 11.1. Normative References 608 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 609 "The Optimized Link State Routing Protocol version 2", 610 work in progress draft-ietf-manet-olsrv2-19, March 2013. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 616 "Generalized MANET Packet/Message Format", RFC 5444, 617 February 2009. 619 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 620 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 621 RFC 6130, April 2011. 623 [RFC6622bis] 624 Herberg, U., Clausen, T., and C. Dearlove, "Integrity 625 Check Value and Timestamp TLV Definitions for Mobile Ad 626 Hoc Networks (MANETs)", work in 627 progress draft-ietf-manet-rfc6622-bis-02, April 2013. 629 11.2. Informative References 631 [BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 632 Key Management", BCP 107, RFC 4107, June 2005. 634 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 635 Considerations in Mobile Ad Hoc Networks (MANETs)", 636 RFC 5148, February 2008. 638 Authors' Addresses 640 Ulrich Herberg 641 Fujitsu Laboratories of America 642 1240 E. Arques Ave. 643 Sunnyvale, CA, 94085, 644 USA 646 Email: ulrich@herberg.name 647 URI: http://www.herberg.name/ 649 Christopher Dearlove 650 BAE Systems Advanced Technology Centre 651 West Hanningfield Road 652 Great Baddow, Chelmsford 653 United Kingdom 655 Phone: +44 1245 242194 656 Email: chris.dearlove@baesystems.com 657 URI: http://www.baesystems.com/ 659 Thomas Heide Clausen 660 LIX, Ecole Polytechnique 661 91128 Palaiseau Cedex, 662 France 664 Phone: +33 6 6058 9349 665 Email: T.Clausen@computer.org 666 URI: http://www.thomasclausen.org/