idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-sec-03.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 (July 2, 2013) is 3941 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: January 3, 2014 T. Clausen 7 LIX, Ecole Polytechnique 8 July 2, 2013 10 Integrity Protection for Control Messages in NHDP and OLSRv2 11 draft-ietf-manet-nhdp-olsrv2-sec-03 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 January 3, 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 . . . . . . . . . . . . . . 8 69 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 70 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9 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 . . . . 11 74 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 12 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 12 78 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 12 79 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 12 80 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12 81 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 13 82 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 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 messages in 111 OLSRv2, the former also protecting the source address of the IP 112 datagram that contains the HELLO message. This is because the IP 113 datagram source address is used by NHDP to determine the address of a 114 neighbor interface, and is not necessarily otherwise contained in the 115 HELLO message, while OLSRv2's TC message is forwarded in a new 116 packet, and thus has no single IP datagram source address. 118 The mechanism specified in this document is placed in the packet/ 119 message processing flow as indicated in Figure 1. It exists between 120 the packet parsing/generation function of [RFC5444], and the message 121 processing/generation function of NHDP and OLSRv2. 123 | | 124 Incoming | /|\ Outgoing 125 packet \|/ | packet 126 | | 127 +--------------------------------+ 128 | | 129 | RFC5444 packet | 130 | parsing / generation | 131 | | 132 +--------------------------------+ 133 | | 134 Messages | /|\ Messages with 135 \|/ | added TLVs 136 | | 137 D +--------------------------------+ 138 R /__________________ | | 139 O \ Messages | This specification | 140 P (failed check) | | 141 +--------------------------------+ 142 | | 143 Messages | /|\ Messages 144 (passed check) \|/ | 145 | | 146 +--------------------------------+ 147 | | 148 | NHDP/OLSRv2 message | 149 | processing / generation | 150 | | 151 +--------------------------------+ 153 Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in 160 [RFC2119]. 162 Additionally, this document uses the terminology and notation of 163 [RFC5444], [RFC6130], [OLSRv2], and [RFC6622bis]. 165 3. Applicability Statement 167 [RFC6130] and [OLSRv2] enable extensions to recognize additional 168 reasons for rejecting a message as "badly formed and therefore 169 invalid for processing", and mention security (integrity protection) 170 as an explicit example. This document specifies a framework that 171 provides this functionality. 173 Implementations of [RFC6130] and [OLSRv2] MUST include this 174 framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this 175 framework, except for when a different security mechanism is more 176 appropriate. 178 The applicability of this framework is determined by its 179 characteristics, which are that it: 181 o Specifies a security framework that is required to be included in 182 conforming implementations of [RFC6130] and [OLSRv2]. 184 o Specifies an association of ICVs with protocol messages, and 185 specifies how to use a missing or invalid ICV as an reason to 186 reject a message as "badly formed and therefore invalid for 187 processing". 189 o Specifies the implementation of an ICV Message TLV, defined in 190 [RFC6622bis], using a SHA-256 based HMAC applied to the 191 appropriate message contents (and for HELLO messages also 192 including the IP datagram source address). Deployments of 193 [RFC6130] and [OLSRv2] using this framework SHOULD use an HMAC/ 194 SHA-256 ICV TLV, but MAY use different algorithms if more 195 appropriate in a deployment. An implementation MAY also use more 196 than one ICV TLV in a message, as long as they each use a 197 different algorithm to calculate the ICV. 199 o Specifies the implementation of a TIMESTAMP Message TLV, defined 200 in [RFC6622bis], to provide message replay protection. 201 Deployments of [RFC6130] and [OLSRv2] using this framework SHOULD 202 use a POSIX time based timestamp, if the clocks in all routers in 203 the network can be synchronized with sufficient precision. 205 o Assumes that a router that is able to generate correct integrity 206 check values is considered trusted. 208 This framework does not: 210 o Specify which key identifiers are to be used in a MANET in which 211 the routers share more than one secret key. (Such keys will be 212 differentiated using the field defined in an ICV TLV in 213 [RFC6622bis].) 215 o Specify how to distribute cryptographic material (shared secret 216 key(s)). 218 o Specify how to detect compromised routers with valid keys. 220 o Specify how to handle (revoke) compromised routers with valid 221 keys. 223 4. Protocol Overview and Functioning 225 The framework specified in this document provides the following 226 functionalities for use with messages owned by [RFC6130] and 227 [OLSRv2]: 229 o Generation of ICV Message TLVs (as defined in [RFC6622bis]) for 230 inclusion in an outgoing message. An implementation of [RFC6130] 231 and [OLSRv2] MAY use more than one ICV TLV in a message, even with 232 the same type extension, but these ICV TLVs MUST each use a 233 different algorithm to calculate the ICV, e.g., with different 234 hash and/or cryptographic functions when using type extension 1 or 235 2. An implementation of [RFC6130] and [OLSRv2] MUST at least be 236 able to generate an ICV TLV using HMAC/SHA-256 and one or more 237 secret keys shared by all 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 not with 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 framework: 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 framework, 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 framework, 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 6. Message Generation and Processing 349 This section specifies how messages are generated and processed by 350 [RFC6130] and [OLSRv2] when using this framework. 352 6.1. Message Content 354 Messages MUST have the content specified in [RFC6130] and [OLSRv2] 355 respectively. In addition, in order to conform to this framework, 356 each message MUST contain: 358 o At least one ICV Message TLV (as specified in [RFC6622bis]), 359 generated according to Section 6.2. Implementations of [RFC6130] 360 and [OLSRv2] MUST support the following version of the ICV TLV, 361 but other versions MAY be used instead, or in addition, in a 362 deployment, if more appropriate: 364 * For TC messages: 366 + type-extension := 1 368 * For HELLO messages: 370 + type-extension := 2 372 * hash-function := 3 (SHA-256) 374 * cryptographic-function := 3 (HMAC) 376 The ICV Value MAY be truncated as specified in [RFC6622bis]; the 377 selection of an appropriate length MAY be administratively 378 configured. A message MAY contain several ICV Message TLVs. 380 o At least one TIMESTAMP Message TLV (as specified in [RFC6622bis]), 381 generated according to Section 6.2. Implementations of [RFC6130] 382 and [OLSRv2] using this framework MUST support the following 383 version of the TIMESTAMP TLV, but other versions MAY be used 384 instead, or in addition, in a deployment, if more appropriate: 386 * type-extension := 1 388 6.2. Message Generation 390 After message generation (Section 11.1 of [RFC6130] and Section 16.1. 391 of [OLSRv2]) and before message transmission (Section 11.2 of 392 [RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs 393 specified in Section 6.1 MUST (unless already present) be added to an 394 outgoing message when using this framework. 396 The following processing steps (when using a single timestamp version 397 and a single ICV algorithm) MUST be performed for a cryptographic 398 algorithm that is used for generating an ICV for a message: 400 1. All ICV TLVs (if any) are temporarily removed from the message. 401 Any temporarily removed ICV TLVs MUST be stored, in order to be 402 reinserted into the message in step 5. The message size and 403 Message TLV Block size are updated accordingly. 405 2. and , if present, are temporarily 406 set to 0. 408 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to 409 the Message TLV Block. The message size and Message TLV block 410 size are updated accordingly. 412 4. A TLV of type ICV, as specified in Section 6.1, is added to the 413 Message TLV Block. The message size and Message TLV block size 414 are updated accordingly. 416 5. All ICV TLVs that were temporary removed in step 1, are restored. 417 The message size and Message TLV Block size are updated 418 accordingly. 420 6. and , if present, are restored to 421 their previous values. 423 An implementation MAY add either alternative TIMESTAMP and/or ICV 424 TLVs, or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs 425 MUST be inserted before adding ICV TLVs. 427 6.3. Message Processing 429 Both [RFC6130] and [OLSRv2] specify that: 431 "On receiving a ... message, a router MUST first check if the 432 message is invalid for processing by this router" 434 [RFC6130] and [OLSRv2] proceed to give a number of conditions that, 435 each, will lead to a rejection of the message as "badly formed and 436 therefore invalid for processing". When using a single timestamp 437 version, and a single ICV algorithm, the following conditions to that 438 list, each of which, if true, MUST cause NHDP or OLSRv2 (as 439 appropriate) to consider the message as invalid for processing when 440 using this framework: 442 1. The Message TLV Block of the message does not contain exactly one 443 TIMESTAMP TLV of the selected version. This version 444 specification includes the type extension. (The Message TLV 445 Block may also contain TIMESTAMP TLVs of other versions.) 447 2. The Message TLV block does not contain exactly one ICV TLV using 448 the selected algorithm and key identifier. This algorithm 449 specification includes the type extension, and for type 450 extensions 1 and 2, the hash function and cryptographic function. 451 (The Message TLV Block may also contain ICV TLVs using other 452 algorithms and key identifiers.) 454 3. Validation of the identified (in step 1) TIMESTAMP TLV in the 455 Message TLV block of the message fails, as according to 456 Section 6.3.1. 458 4. Validation of the identified (in step 2) ICV TLV in the Message 459 TLV block of the message fails, as according to Section 6.3.2. 461 An implementation MAY check the existence of, and verify, either 462 alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP 463 and/or ICV TLVs. 465 6.3.1. Validating a Message Based on Timestamp 467 For a TIMESTAMP Message TLV with type extension 1 (POSIX time) 468 identified as described in Section 6.2: 470 1. If the current POSIX time minus the value of that TIMESTAMP TLV 471 is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or 472 MAX_TC_TIMESTAMP_DIFF (for a TC message) then the message 473 validation fails. 475 2. Otherwise, the message validation succeeds. 477 If a deployment chooses to use a different type extension from 1, 478 appropriate measures MUST be taken to verify freshness of the 479 message. 481 6.3.2. Validating a Message Based on Integrity Check 483 For an ICV Message TLV identified as described in Section 6.2: 485 1. All ICV Message TLVs (including the identified ICV Message TLV) 486 are temporarily removed from the message, and the message size 487 and Message TLV block size are updated accordingly. 489 2. The message's and fields are 490 temporarily set to 0. 492 3. Calculate the integrity check value for the parameters specified 493 in the identified ICV Message TLV, as specified in [RFC6622bis]. 495 4. If this integrity check value differs from the value of 496 in the ICV Message TLV, then the message validation 497 fails. If the has been truncated (as specified in 498 [RFC6622bis], the integrity check value calculated in the 499 previous step MUST be truncated to the TLV length of the ICV 500 Message TLV before comparing it with the . 502 5. Otherwise, the message validation succeeds. The message's 503 and fields are restored to their 504 previous value, and the ICV Message TLVs are returned to the 505 message, whose size is updated accordingly. 507 7. Provisioning of Routers 509 Before a router using this framework is able to generate ICVs or 510 validate messages, it MUST acquire the shared secret key(s) to be 511 used by all routers that are to participate in the network. This 512 specification does not define how a router acquires secret keys. 513 Once a router has acquired suitable key(s) it MAY be configured to 514 use, or not use, this framework. 516 8. IANA Considerations 518 This document has no actions for IANA. 520 [This section may be removed by the RFC Editor.] 522 9. Security Considerations 524 This document specifies a security framework for use with NHDP and 525 OLSRv2 that allows for alleviating several security threats. 527 9.1. Alleviated Attacks 529 This section briefly summarizes security threats that are alleviated 530 by the framework presented in this document. 532 9.1.1. Identity Spoofing 534 As only routers possessing the selected shared secret key are able to 535 add a valid ICV TLV to a message, identity spoofing, where an 536 attacker falsely claims an identity of a valid router, is countered. 538 9.1.2. Link Spoofing 540 Link spoofing, where an attacker falsely represents the existence of 541 a non-existent link, or otherwise misrepresents a link's state, is 542 countered by the framework specified in this document, using the same 543 argument as in Section 9.1.1. 545 9.1.3. Replay Attack 547 Replay attacks are partly countered by the framework specified in 548 this document, but this depends on synchronized clocks of all routers 549 in the MANET. An attacker that records messages to replay them later 550 can only do so in the selected time interval after the timestamp that 551 is contained in message. As an attacker cannot modify the content of 552 this timestamp (as it is protected by the identity check value), an 553 attacker cannot replay messages after this time. Within this time 554 interval it is still possible to perform replay attacks, however the 555 limits on the time interval are specified so that this will have a 556 limited effect on the operation of the protocol. 558 9.2. Limitations 560 If no synchronized clocks are available in the MANET, replay attacks 561 cannot be countered by the framework provided by this document. An 562 alternative version of the TIMESTAMP TLV defined in [RFC6622bis], 563 with a monotonic sequence number, may have some partial value in this 564 case, but will necessitate adding state to record observed message 565 sequence number information. 567 The framework provided by this document does not avoid or detect 568 security attacks by routers possessing the shared secret key that is 569 used to generate integrity check values for messages. 571 This framework relies on an out-of-band protocol or mechanism for 572 distributing the shared secret key(s) (and if an alternative 573 integrity check value is used, any additional cryptographic 574 parameters). 576 This framework does not provide a key revocation mechanism. 578 10. Acknowledgments 580 The authors would like to gratefully acknowledge the following 581 people: Henning Rogge (Frauenhofer FKIE). 583 11. References 585 11.1. Normative References 587 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 588 "The Optimized Link State Routing Protocol version 2", 589 work in progress draft-ietf-manet-olsrv2-19, March 2013. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 595 "Generalized MANET Packet/Message Format", RFC 5444, 596 February 2009. 598 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 599 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 600 RFC 6130, April 2011. 602 [RFC6622bis] 603 Herberg, U., Clausen, T., and C. Dearlove, "Integrity 604 Check Value and Timestamp TLV Definitions for Mobile Ad 605 Hoc Networks (MANETs)", work in 606 progress draft-ietf-manet-rfc6622-bis-02, April 2013. 608 11.2. Informative References 610 [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter 611 Considerations in Mobile Ad Hoc Networks (MANETs)", 612 RFC 5148, February 2008. 614 Authors' Addresses 616 Ulrich Herberg 617 Fujitsu Laboratories of America 618 1240 E. Arques Ave. 619 Sunnyvale, CA, 94085, 620 USA 622 Email: ulrich@herberg.name 623 URI: http://www.herberg.name/ 625 Christopher Dearlove 626 BAE Systems Advanced Technology Centre 627 West Hanningfield Road 628 Great Baddow, Chelmsford 629 United Kingdom 631 Phone: +44 1245 242194 632 Email: chris.dearlove@baesystems.com 633 URI: http://www.baesystems.com/ 634 Thomas Heide Clausen 635 LIX, Ecole Polytechnique 636 91128 Palaiseau Cedex, 637 France 639 Phone: +33 6 6058 9349 640 Email: T.Clausen@computer.org 641 URI: http://www.thomasclausen.org/