idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-sec-05.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 (September 10, 2013) is 3843 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: March 14, 2014 T. Clausen 7 LIX, Ecole Polytechnique 8 September 10, 2013 10 Integrity Protection for Control Messages in NHDP and OLSRv2 11 draft-ietf-manet-nhdp-olsrv2-sec-05 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 March 14, 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. Mitigated 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 . . . . . . . . . . . . . . . . . . 15 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 the 94 mandatory to implement security mechanisms (for integrity and replay 95 protection). A deployment of these protocols may choose to employ 96 alternative(s) to these mechanisms, in particular it may choose to 97 protect packets rather than messages, it may choose to use an 98 alternative integrity check value (ICV) with preferred properties, 99 and/or it may use an alternative timestamp. A deployment may choose 100 to use no such security mechanisms, but this is not recommended. 102 The mechanisms specified are the use of an ICV for protection of the 103 protocols' control messages, and the use of timestamps in those 104 messages to prevent replay attacks. Both use the TLV mechanism 105 specified in [RFC5444] to add this information to the messages. 106 These ICV and TIMESTAMP TLVs are defined in [RFC6622bis]. Different 107 ICV TLVs are used for HELLO messages in NHDP and TC (Topology 108 Control) messages in OLSRv2, the former also protecting the source 109 address of the IP datagram that contains the HELLO message. This is 110 because the IP datagram source address is used by NHDP to determine 111 the address of a neighbor interface, and is not necessarily otherwise 112 contained in the HELLO message, while OLSRv2's TC message is 113 forwarded in a new packet, and thus has no single IP datagram source 114 address. 116 The mechanism specified in this document is placed in the packet/ 117 message processing flow as indicated in Figure 1. It exists between 118 the packet parsing/generation function of [RFC5444], and the message 119 processing/generation function of NHDP and OLSRv2. 121 | | 122 Incoming | /|\ Outgoing 123 packet \|/ | packet 124 | | 125 +--------------------------------+ 126 | | 127 | RFC5444 packet | 128 | parsing / generation | 129 | | 130 +--------------------------------+ 131 | | 132 Messages | /|\ Messages with 133 \|/ | added TLVs 134 | | 135 D +--------------------------------+ 136 R /__________________ | Mechanism specified in | 137 O \ Messages | this document | 138 P (failed check) | | 139 +--------------------------------+ 140 | | 141 Messages | /|\ Messages 142 (passed check) \|/ | 143 | | 144 +--------------------------------+ 145 | | 146 | NHDP/OLSRv2 message | 147 | processing / generation | 148 | | 149 +--------------------------------+ 151 Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 [RFC2119]. 160 Additionally, this document uses the terminology and notation of 161 [RFC5444], [RFC6130], [OLSRv2], and [RFC6622bis]. 163 3. Applicability Statement 165 [RFC6130] and [OLSRv2] enable specifications of extensions to 166 recognize additional reasons for rejecting a message as "badly formed 167 and therefore invalid for processing", and mention security 168 (integrity protection) as an explicit example. This document 169 specifies a mechanism that provides this functionality. 171 Implementations of [RFC6130] and [OLSRv2] MUST include this 172 mechanism, and deployments of [RFC6130] and [OLSRv2] SHOULD use this 173 mechanism, except for when a different security mechanism is more 174 appropriate. 176 The applicability of this mechanism is determined by its 177 characteristics, which are that it: 179 o Specifies a security mechanism that is required to be included in 180 conforming implementations of [RFC6130] and [OLSRv2]. 182 o Specifies an association of ICVs with protocol messages, and 183 specifies how to use a missing or invalid ICV as an reason to 184 reject a message as "badly formed and therefore invalid for 185 processing". 187 o Specifies the implementation of an ICV Message TLV, defined in 188 [RFC6622bis], using a SHA-256 based HMAC applied to the 189 appropriate message contents (and for HELLO messages also 190 including the IP datagram source address). Implementations of 191 [RFC6130] and [OLSRv2] MUST support an HMAC-SHA-256 ICV TLV, and 192 deployment SHOULD use it except when use of a different algorithm 193 is more appropriate. An implementation MAY use more than one ICV 194 TLV in a message, as long as they each use a different algorithm 195 or key to calculate the ICV. 197 o Specifies the implementation of a TIMESTAMP Message TLV, defined 198 in [RFC6622bis], to provide message replay protection. 199 Implementations of [RFC6130] and [OLSRv2] using this mechanism 200 MUST support a POSIX time based timestamp, and deployments SHOULD 201 use it if the clocks in all routers in the network can be 202 synchronized with sufficient precision. 204 o Assumes that a router that is able to generate correct integrity 205 check values is considered trusted. 207 This mechanism does not: 209 o Specify which key identifiers are to be used in a MANET in which 210 the routers share more than one secret key. (Such keys will be 211 differentiated using the field defined in an ICV TLV in 212 [RFC6622bis].) 214 o Specify how to distribute cryptographic material (shared secret 215 key(s)). 217 o Specify how to detect compromised routers with valid keys. 219 o Specify how to handle (revoke) compromised routers with valid 220 keys. 222 4. Protocol Overview and Functioning 224 The mechanism specified in this document provides the following 225 functionalities for use with messages specified by [RFC6130] and 226 [OLSRv2]: 228 o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for 229 inclusion in an outgoing message. An implementation of [RFC6130] 230 and [OLSRv2] MAY use more than one ICV TLV in a message, even with 231 the same type extension, but these ICV TLVs MUST each use 232 different keys, or they MUST use a different algorithm to 233 calculate the ICV, e.g., with different hash and/or cryptographic 234 functions when using type extension 1 or 2. An implementation of 235 [RFC6130] and [OLSRv2] MUST at least be able to generate an ICV 236 TLV using HMAC-SHA-256 and one or more secret keys shared by all 237 routers. 239 o Generation of TIMESTAMP Message TLVs (as defined in [RFC6622bis]) 240 for inclusion in an outgoing message. An implementation of 241 [RFC6130] and [OLSRv2] MAY use more than one ICV TLV in a message, 242 but MUST NOT use the same type extension. An implementation of 243 [RFC6130] and [OLSRv2] that is able to synchronize the clocks in 244 all routers in the network with sufficient precision, MUST at 245 least be able to generate a TIMESTAMP TLV using POSIX time. 247 o Verification of ICV Message TLVs contained in a message, in order 248 to determine if this message MUST be rejected as "badly formed and 249 therefore invalid for processing" [RFC6130] [OLSRv2]. An 250 implementation of [RFC6130] and [OLSRv2] MUST at least be able to 251 verify an ICV TLV using HMAC/SHA-256 and one or more secret keys 252 shared by all routers. 254 o Verification of TIMESTAMP Message TLVs (as defined in 255 [RFC6622bis]) contained in a message, in order to determine if 256 this message MUST be rejected as "badly formed and therefore 257 invalid for processing" [RFC6130] [OLSRv2]. An implementation of 258 [RFC6130] and [OLSRv2] that is able to synchronize the clocks in 259 all routers in the network with sufficient precision, MUST at 260 least be able to verify a TIMESTAMP TLV using POSIX time. 262 ICV Packet TLVs (as defined in [RFC6622bis]) MAY be used by a 263 deployment of the multiplexing process defined in [RFC5444], either 264 as well as, or instead of, the protection of the NHDP and OLSRv2 265 messages. (Note that in the case of NHDP, the packet protection is 266 equally good, and also protects the packet header. In the case of 267 OLSRv2, the packet protection has different properties than the 268 message protection, especially for some forms of ICV. When packets 269 contain more than one message, the packet protection has lower 270 overheads in space and computation time.) 272 When a router generates a message on a MANET interface, this 273 mechanism: 275 o Specifies how to calculate an integrity check value for the 276 message. 278 o Specifies how to include that integrity check value using an ICV 279 Message TLV. 281 [RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to 282 processing by NHDP or OLSRv2. This mechanism, when used, specifies 283 that a message MUST be rejected if the ICV Message TLV is absent, or 284 its value cannot be verified. Note that this means that routers 285 whose implementation of NHDP and/or OLSRv2 does not include this 286 specification will be ignored by routers using this mechanism, and 287 these two sets of routers will, by design, form disjoint MANETs. 288 (The unsecured MANET will retain some information about the secured 289 MANET, but be unable to use it, not having any recognized symmetric 290 links with the secured MANET.) 292 5. Parameters 294 This following router parameters are specified for use by the two 295 protocols; the first is required only by NHDP, but may be visible to 296 OLSRv2, the second is required only by OLSRv2: 298 o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to 299 be validated may have. If the current POSIX time of the router 300 validating the HELLO message, minus the timestamp indicated in the 301 TIMESTAMP TLV of the HELLO message, is greater than 302 MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently 303 discarded. 305 o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be 306 validated may have. If the current POSIX time of the router 307 validating the TC message, minus the timestamp indicated in the 308 TIMESTAMP TLV of the TC message, is greater than 309 MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded. 311 The following constraints apply to these parameters: 313 o MAX_HELLO_TIMESTAMP_DIFF > 0 315 o MAX_TC_TIMESTAMP_DIFF > 0 317 These bounds are however insufficient, MAX_HELLO_TIMESTAMP_DIFF and 318 MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected 319 "age" of a message (i.e., the time difference between a message has 320 been sent by a router and received by all intended destinations). 321 For HELLO messages this needs only cover a single hop, but TC 322 messages may have been forwarded a number of times. In particular 323 for TC messages, if using jitter as specified in [OLSRv2] and 324 [RFC5148], the largest contribution the age may be a delay of up to 325 F_MAXJITTER per hop (except the final hop) that the message has 326 traveled. Other factors in the delay of both message types, per hop, 327 may include the link-layer that is used in the MANET, and CPU and 328 memory resources of routers (e.g., queuing delays, and delays for 329 processing ICVs). An implementation MAY set lower and/or upper 330 bounds on these parameters, if so, then these MUST allow values 331 meeting these requirements. An implementation MAY make its value of 332 MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC 333 message has traveled. 335 The above constraints assume ideal time synchronization of the clock 336 in all routers in the network. The parameters 337 MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any 338 constraints on them) MAY be increased to allow for expected timing 339 differences between routers (between neighboring routers for 340 MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but 341 usually not per hop, for MAX_TC_TIMESTAMP_DIFF). 343 Note that excessively large values of these parameters defeats their 344 objectives, so these parameters SHOULD be as large as is required, 345 but not significantly larger. 347 Using POSIX time allows a resolution of no more than one second. In 348 many MANET use cases, time synchronization much below one second is 349 not possible because of unreliable and high-delay channels, mobility, 350 interrupted communication, and possible limited resources. 352 In addition, when using the default message intervals and validity 353 times as specified in [RFC6130] and [OLSRv2], where the shortest 354 periodic message interval is 2 seconds, repeating the message within 355 a second is actually beneficial rather than harmful (at a small 356 bandwidth cost). Also, the use of [RFC5148] jitter can cause a 357 message to take that long or more to traverse the MANET, thus even in 358 a perfectly synchronized network, the TC maximum delay would usually 359 be greater than 1 second. 361 A finer granulatity than 1 second, and thus the use of an alternative 362 timestamp, is however RECOMMENDED in cases where, possibly due to 363 fast moving routers, message validity times are below 1 second. 365 6. Message Generation and Processing 367 This section specifies how messages are generated and processed by 368 [RFC6130] and [OLSRv2] when using this mechanism. 370 6.1. Message Content 372 Messages MUST have the content specified in [RFC6130] and [OLSRv2] 373 respectively. In addition, messages that conform to this mechanism 374 MUST contain: 376 o At least one ICV Message TLV (as specified in [RFC6622bis]), 377 generated according to Section 6.2. Implementations of [RFC6130] 378 and [OLSRv2] MUST support the following version of the ICV TLV, 379 but other versions MAY be used instead, or in addition, in a 380 deployment, if more appropriate: 382 * For TC messages: 384 + type-extension := 1 386 * For HELLO messages: 388 + type-extension := 2 390 * hash-function := 3 (SHA-256) 392 * cryptographic-function := 3 (HMAC) 394 The ICV Value MAY be truncated as specified in [RFC6622bis]; the 395 selection of an appropriate length MAY be administratively 396 configured. A message MAY contain several ICV Message TLVs. 398 o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]), 399 generated according to Section 6.2. Implementations of [RFC6130] 400 and [OLSRv2] using this mechanism MUST support the following 401 version of the TIMESTAMP TLV, but other versions MAY be used 402 instead, or in addition, in a deployment, if more appropriate: 404 * type-extension := 1 406 6.2. Message Generation 408 After message generation (Section 11.1 of [RFC6130] and Section 16.1. 409 of [OLSRv2]) and before message transmission (Section 11.2 of 410 [RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs 411 specified in Section 6.1 MUST (unless already present) be added to an 412 outgoing message when using this mechanism. 414 The following processing steps (when using a single timestamp version 415 and a single ICV algorithm) MUST be performed for a cryptographic 416 algorithm that is used for generating an ICV for a message: 418 1. All ICV TLVs (if any) are temporarily removed from the message. 419 Any temporarily removed ICV TLVs MUST be stored, in order to be 420 reinserted into the message in step 5. The message size and 421 Message TLV Block size are updated accordingly. 423 2. and , if present, are temporarily 424 set to 0. 426 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to 427 the Message TLV Block. The message size and Message TLV block 428 size are updated accordingly. 430 4. A TLV of type ICV, as specified in Section 6.1, is added to the 431 Message TLV Block. The message size and Message TLV block size 432 are updated accordingly. 434 5. All ICV TLVs that were temporary removed in step 1, are restored. 435 The message size and Message TLV Block size are updated 436 accordingly. 438 6. and , if present, are restored to 439 their previous values. 441 An implementation MAY add either alternative TIMESTAMP and/or ICV 442 TLVs, or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs 443 MUST be inserted before adding ICV TLVs. 445 6.3. Message Processing 447 Both [RFC6130] and [OLSRv2] specify that: 449 "On receiving a ... message, a router MUST first check if the 450 message is invalid for processing by this router" 452 [RFC6130] and [OLSRv2] proceed to give a number of conditions that, 453 each, will lead to a rejection of the message as "badly formed and 454 therefore invalid for processing". When using a single timestamp 455 version, and a single ICV algorithm, the following conditions to that 456 list, each of which, if true, MUST cause NHDP or OLSRv2 (as 457 appropriate) to consider the message as invalid for processing when 458 using this mechanism: 460 1. The Message TLV Block of the message does not contain exactly one 461 TIMESTAMP TLV of the selected version. This version 462 specification includes the type extension. (The Message TLV 463 Block may also contain TIMESTAMP TLVs of other versions.) 465 2. The Message TLV block does not contain exactly one ICV TLV using 466 the selected algorithm and key identifier. This algorithm 467 specification includes the type extension, and for type 468 extensions 1 and 2, the hash function and cryptographic function. 469 (The Message TLV Block may also contain ICV TLVs using other 470 algorithms and key identifiers.) 472 3. Validation of the identified (in step 1) TIMESTAMP TLV in the 473 Message TLV block of the message fails, as according to 474 Section 6.3.1. 476 4. Validation of the identified (in step 2) ICV TLV in the Message 477 TLV block of the message fails, as according to Section 6.3.2. 479 An implementation MAY check the existence of, and verify, either 480 alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP 481 and/or ICV TLVs. 483 6.3.1. Validating a Message Based on Timestamp 485 For a TIMESTAMP Message TLV with type extension 1 (POSIX time) 486 identified as described in Section 6.2: 488 1. If the current POSIX time minus the value of that TIMESTAMP TLV 489 is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or 490 MAX_TC_TIMESTAMP_DIFF (for a TC message) then the message 491 validation fails. 493 2. Otherwise, the message validation succeeds. 495 If a deployment chooses to use a different type extension from 1, 496 appropriate measures MUST be taken to verify freshness of the 497 message. 499 6.3.2. Validating a Message Based on Integrity Check 501 For an ICV Message TLV identified as described in Section 6.2: 503 1. All ICV Message TLVs (including the identified ICV Message TLV) 504 are temporarily removed from the message, and the message size 505 and Message TLV block size are updated accordingly. 507 2. The message's and fields are 508 temporarily set to 0. 510 3. Calculate the integrity check value for the parameters specified 511 in the identified ICV Message TLV, as specified in [RFC6622bis]. 513 4. If this integrity check value differs from the value of 514 in the ICV Message TLV, then the message validation 515 fails. If the has been truncated (as specified in 516 [RFC6622bis], the integrity check value calculated in the 517 previous step MUST be truncated to the TLV length of the ICV 518 Message TLV before comparing it with the . 520 5. Otherwise, the message validation succeeds. The message's 521 and fields are restored to their 522 previous value, and the ICV Message TLVs are returned to the 523 message, whose size is updated accordingly. 525 7. Provisioning of Routers 527 Before a router using this mechanism is able to generate ICVs or 528 validate messages, it MUST acquire the shared secret key(s) to be 529 used by all routers that are to participate in the network. This 530 specification does not define how a router acquires secret keys. 531 Once a router has acquired suitable key(s) it MAY be configured to 532 use, or not use, this mechanism. Section 23.6 of [OLSRv2] provides a 533 rationale based on [BCP107] why no key management is specified for 534 OLSRv2. 536 8. IANA Considerations 538 This document has no actions for IANA. 540 [This section may be removed by the RFC Editor.] 542 9. Security Considerations 544 This document specifies a security mechanism for use with NHDP and 545 OLSRv2 that allows for mitigating several security threats. 547 9.1. Mitigated Attacks 549 This section briefly summarizes security threats that are mitigated 550 by the mechanism presented in this document. 552 9.1.1. Identity Spoofing 554 As only routers possessing the selected shared secret key are able to 555 add a valid ICV TLV to a message, identity spoofing, where an 556 attacker falsely claims an identity of a valid router, is countered. 557 When using one or more shared keys for all routers in the MANET, it 558 is only possible to determine that it is a valid router in the 559 network, not to discern particular routers. Therefore, a malicious 560 router in possession of valid keys (e.g., a compromised router) may 561 still spoof the identity of another router using the same key. 563 9.1.2. Link Spoofing 565 Link spoofing, where an attacker falsely represents the existence of 566 a non-existent link, or otherwise misrepresents a link's state, is 567 countered by the mechanism specified in this document, using the same 568 argument as in Section 9.1.1. 570 9.1.3. Replay Attack 572 Replay attacks are partly countered by the mechanism specified in 573 this document, but this depends on synchronized clocks of all routers 574 in the MANET. An attacker that records messages to replay them later 575 can only do so in the selected time interval after the timestamp that 576 is contained in message. As an attacker cannot modify the content of 577 this timestamp (as it is protected by the identity check value), an 578 attacker cannot replay messages after this time. Within this time 579 interval it is still possible to perform replay attacks, however the 580 limits on the time interval are specified so that this will have a 581 limited effect on the operation of the protocol. 583 9.2. Limitations 585 If no synchronized clocks are available in the MANET, replay attacks 586 cannot be countered by the mechanism provided by this document. An 587 alternative version of the TIMESTAMP TLV defined in [RFC6622bis], 588 with a monotonic sequence number, may have some partial value in this 589 case, but will necessitate adding state to record observed message 590 sequence number information. 592 The mechanism provided by this document does not avoid or detect 593 security attacks by routers possessing the shared secret key that is 594 used to generate integrity check values for messages. 596 This mechanism relies on an out-of-band protocol or mechanism for 597 distributing the shared secret key(s) (and if an alternative 598 integrity check value is used, any additional cryptographic 599 parameters). 601 This mechanism does not provide a key management mechanism. Refer to 602 [OLSRv2], Section 23.6, for a detailed discussion why the automated 603 key management requirements specified in [BCP107] do not apply for 604 OLSRv2 and NHDP. 606 10. Acknowledgments 608 The authors would like to gratefully acknowledge the following 609 people: Justin Dean (NRL), and Henning Rogge (Frauenhofer FKIE). 611 11. References 613 11.1. Normative References 615 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 616 "The Optimized Link State Routing Protocol version 2", 617 work in progress draft-ietf-manet-olsrv2-19, March 2013. 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 623 "Generalized MANET Packet/Message Format", RFC 5444, 624 February 2009. 626 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 627 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 628 RFC 6130, April 2011. 630 [RFC6622bis] 631 Herberg, U., Clausen, T., and C. Dearlove, "Integrity 632 Check Value and Timestamp TLV Definitions for Mobile Ad 633 Hoc Networks (MANETs)", work in 634 progress draft-ietf-manet-rfc6622-bis-02, April 2013. 636 11.2. Informative References 638 [BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 639 Key Management", BCP 107, RFC 4107, June 2005. 641 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 642 Considerations in Mobile Ad Hoc Networks (MANETs)", 643 RFC 5148, February 2008. 645 Authors' Addresses 647 Ulrich Herberg 648 Fujitsu Laboratories of America 649 1240 E. Arques Ave. 650 Sunnyvale, CA, 94085, 651 USA 653 Email: ulrich@herberg.name 654 URI: http://www.herberg.name/ 656 Christopher Dearlove 657 BAE Systems Advanced Technology Centre 658 West Hanningfield Road 659 Great Baddow, Chelmsford 660 United Kingdom 662 Phone: +44 1245 242194 663 Email: chris.dearlove@baesystems.com 664 URI: http://www.baesystems.com/ 666 Thomas Heide Clausen 667 LIX, Ecole Polytechnique 668 91128 Palaiseau Cedex, 669 France 671 Phone: +33 6 6058 9349 672 Email: T.Clausen@computer.org 673 URI: http://www.thomasclausen.org/