1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) U. Herberg
Request for Comments: 7183 Fujitsu Laboratories of America
Updates: <a href="./rfc6130">6130</a>, <a href="./rfc7181">7181</a> C. Dearlove
Category: Standards Track BAE Systems ATC
ISSN: 2070-1721 T. Clausen
LIX, Ecole Polytechnique
April 2014
Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and
Optimized Link State Routing Protocol Version 2 (OLSRv2)
Abstract
This document specifies integrity and replay protection for the
Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
and the Optimized Link State Routing Protocol version 2 (OLSRv2).
This protection is achieved by using an HMAC-SHA-256 Integrity Check
Value (ICV) TLV and a Timestamp TLV based on Portable Operating
System Interface (POSIX) time.
The mechanism in this specification can also be used for other
protocols that use the generalized packet/message format described in
<a href="./rfc5444">RFC 5444</a>.
This document updates <a href="./rfc6130">RFC 6130</a> and <a href="./rfc7181">RFC 7181</a> by mandating the
implementation of this integrity and replay protection in NHDP and
OLSRv2.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7183">http://www.rfc-editor.org/info/rfc7183</a>.
<span class="grey">Herberg, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Applicability Statement .........................................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Protocol Overview and Functioning ...............................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Parameters ......................................................<a href="#page-7">7</a>
<a href="#section-6">6</a>. Message Generation and Processing ...............................<a href="#page-9">9</a>
<a href="#section-6.1">6.1</a>. Message Content ............................................<a href="#page-9">9</a>
<a href="#section-6.2">6.2</a>. Message Generation ........................................<a href="#page-10">10</a>
<a href="#section-6.3">6.3</a>. Message Processing ........................................<a href="#page-11">11</a>
<a href="#section-6.3.1">6.3.1</a>. Validating a Message Based on Timestamp ............<a href="#page-11">11</a>
<a href="#section-6.3.2">6.3.2</a>. Validating a Message Based on Integrity Check ......<a href="#page-12">12</a>
<a href="#section-7">7</a>. Provisioning of Routers ........................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. Mitigated Attacks .........................................<a href="#page-13">13</a>
<a href="#section-8.1.1">8.1.1</a>. Identity Spoofing ..................................<a href="#page-13">13</a>
<a href="#section-8.1.2">8.1.2</a>. Link Spoofing ......................................<a href="#page-13">13</a>
<a href="#section-8.1.3">8.1.3</a>. Replay Attack ......................................<a href="#page-13">13</a>
<a href="#section-8.2">8.2</a>. Limitations ...............................................<a href="#page-13">13</a>
<a href="#section-9">9</a>. Acknowledgments ................................................<a href="#page-14">14</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-14">14</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-14">14</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-14">14</a>
<span class="grey">Herberg, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This specification updates [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] by defining
mandatory-to-implement security mechanisms (for integrity and replay
protection). A deployment of these protocols may choose to employ an
alternative(s) to these mechanisms; in particular, it may choose to
protect packets rather than messages, it may choose to use an
alternative Integrity Check Value (ICV) with preferred properties,
and/or it may use an alternative timestamp. A deployment may choose
to use no such security mechanisms, but this is not recommended.
The mechanisms specified are the use of an ICV for protection of the
protocols' control messages and the use of timestamps in those
messages to prevent replay attacks. Both use the TLV mechanism
specified in [<a href="./rfc5444" title=""Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"">RFC5444</a>] to add this information to the messages.
These ICV and TIMESTAMP TLVs are defined in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]. Different ICV
TLVs are used for HELLO messages in NHDP and TC (Topology Control)
messages in OLSRv2, the former also protecting the source address of
the IP datagram that contains the HELLO message. This is because the
IP datagram source address is used by NHDP to determine the address
of a neighbor interface, and it is not necessarily otherwise
contained in the HELLO message, while OLSRv2's TC message is
forwarded in a new packet; thus, it has no single IP datagram source
address.
The mechanism specified in this document is placed in the packet/
message processing flow as indicated in Figure 1. It exists between
the packet parsing/generation function of [<a href="./rfc5444" title=""Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"">RFC5444</a>] and the message
processing/generation function of NHDP and OLSRv2.
<span class="grey">Herberg, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
| |
Incoming | /|\ Outgoing
packet \|/ | packet
| |
+--------------------------------+
| |
| <a href="./rfc5444">RFC 5444</a> packet |
| parsing/generation |
| |
+--------------------------------+
| |
Messages | /|\ Messages with
\|/ | added TLVs
| |
D +--------------------------------+
R /__________________ | |
O \ Messages | Mechanism specified in |
P (failed check) | this document |
| |
+--------------------------------+
| |
Messages | /|\ Messages
(passed check) \|/ |
| |
+--------------------------------+
| |
| NHDP/OLSRv2 message |
| processing/generation |
| |
+--------------------------------+
Figure 1: Relationship with <a href="./rfc5444">RFC 5444</a> and NHDP/OLSRv2
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
Additionally, this document uses the terminology and notation of
[<a href="./rfc5444" title=""Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"">RFC5444</a>], [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>], [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>], and [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>].
<span class="grey">Herberg, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Applicability Statement</span>
[<a id="ref-RFC6130">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] enable specifications of extensions to
recognize additional reasons for rejecting a message as "badly formed
and therefore invalid for processing", and mention security
(integrity protection) as an explicit example. This document
specifies a mechanism that provides this functionality.
Implementations of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MUST include this
mechanism, and deployments of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] SHOULD use this
mechanism, except when a different security mechanism is more
appropriate.
The applicability of this mechanism is determined by its
characteristics, which are that it:
o Specifies a security mechanism that is required to be included in
conforming implementations of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>].
o Specifies an association of ICVs with protocol messages, and
specifies how to use a missing or invalid ICV as a reason to
reject a message as "badly formed and therefore invalid for
processing".
o Specifies the implementation of an ICV Message TLV, defined in
[<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>], using a SHA-256-based Hashed Message Authentication
Code (HMAC) applied to the appropriate message contents (and for
HELLO messages also including the IP datagram source address).
Implementations of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MUST support an
HMAC-SHA-256 ICV TLV, and deployments SHOULD use it except when
use of a different algorithm is more appropriate. An
implementation MAY use more than one ICV TLV in a message, as long
as they each use a different algorithm or key to calculate the
ICV.
o Specifies the implementation of a TIMESTAMP Message TLV, defined
in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>], to provide message replay protection.
Implementations of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] using this mechanism
MUST support a timestamp based on POSIX time, and deployments
SHOULD use it if the clocks in all routers in the network can be
synchronized with sufficient precision.
o Assumes that a router that is able to generate correct integrity
check values is considered trusted.
<span class="grey">Herberg, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
This mechanism does not:
o Specify which key identifiers are to be used in a MANET in which
the routers share more than one secret key. (Such keys will be
differentiated using the <key-id> field defined in an ICV TLV in
[<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>].)
o Specify how to distribute cryptographic material (shared secret
key(s)).
o Specify how to detect compromised routers with valid keys.
o Specify how to handle (revoke) compromised routers with valid
keys.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Protocol Overview and Functioning</span>
The mechanism specified in this document provides the following
functionalities for use with messages specified by [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and
[<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]:
o Generation of ICV Message TLVs (as defined in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]) for
inclusion in an outgoing message. An implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]
and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MAY use more than one ICV TLV in a message, even
with the same type extension, but these ICV TLVs MUST each use
different keys or they MUST use a different algorithm to calculate
the ICV, e.g., with different hash and/or cryptographic functions
when using type extension 1 or 2. An implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]
and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MUST at least be able to generate an ICV TLV using
HMAC-SHA-256 and one or more secret keys shared by all routers.
o Generation of TIMESTAMP Message TLVs (as defined in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]) for
inclusion in an outgoing message. An implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]
and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MAY use more than one ICV TLV in a message, but it
MUST NOT use the same type extension. An implementation of
[<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] that is able to synchronize the clocks in
all routers in the network with sufficient precision MUST at least
be able to generate a TIMESTAMP TLV using POSIX time.
o Verification of ICV Message TLVs contained in a message, in order
to determine if this message MUST be rejected as "badly formed and
therefore invalid for processing" [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]. An
implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MUST at least be able to
verify an ICV TLV using HMAC/SHA-256 and one or more secret keys
shared by all routers.
<span class="grey">Herberg, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
o Verification of TIMESTAMP Message TLVs (as defined in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>])
contained in a message, in order to determine if this message MUST
be rejected as "badly formed and therefore invalid for processing"
[<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]. An implementation of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>]
that is able to synchronize the clocks in all routers in the
network with sufficient precision MUST at least be able to verify
a TIMESTAMP TLV using POSIX time.
ICV Packet TLVs (as defined in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]) MAY be used by a deployment
of the multiplexing process defined in [<a href="./rfc5444" title=""Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format"">RFC5444</a>], either as well as
or instead of the protection of the NHDP and OLSRv2 messages. (Note
that in the case of NHDP, the packet protection is equally good, and
also protects the packet header. In the case of OLSRv2, the packet
protection has different properties than the message protection,
especially for some forms of ICV. When packets contain more than one
message, the packet protection has lower overheads in space and
computation time.)
When a router generates a message on a MANET interface, this
mechanism:
o Specifies how to calculate an ICV for the message.
o Specifies how to include that ICV using an ICV Message TLV.
[<a id="ref-RFC6130">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] allow for the rejection of incoming messages
prior to processing by NHDP or OLSRv2. This mechanism, when used,
specifies that a message MUST be rejected if the ICV Message TLV is
absent, or its value cannot be verified. Note that this means that
routers whose implementation of NHDP and/or OLSRv2 does not include
this specification will be ignored by routers using this mechanism,
and these two sets of routers will, by design, form disjoint MANETs.
(The unsecured MANET will retain some information about the secured
MANET, but be unable to use it, not having any recognized symmetric
links with the secured MANET.)
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Parameters</span>
The following router parameters are specified for use by the two
protocols; the first is required only by NHDP, but may be visible to
OLSRv2, the second is required only by OLSRv2:
o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to
be validated may have. If the current POSIX time of the router
validating the HELLO message, minus the timestamp indicated in the
TIMESTAMP TLV of the HELLO message, is greater than
MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently
discarded.
<span class="grey">Herberg, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be
validated may have. If the current POSIX time of the router
validating the TC message, minus the timestamp indicated in the
TIMESTAMP TLV of the TC message, is greater than
MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded.
The following constraints apply to these parameters:
o MAX_HELLO_TIMESTAMP_DIFF > 0
o MAX_TC_TIMESTAMP_DIFF > 0
However, these bounds are insufficient: MAX_HELLO_TIMESTAMP_DIFF and
MAX_TC_TIMESTAMP_DIFF MUST be least as great as the maximum expected
"age" of a message (i.e., the time difference between a message has
been sent by a router and received by all intended destinations).
For HELLO messages, this needs only cover a single hop, but TC
messages may have been forwarded a number of times. In particular,
for TC messages, if using jitter as specified in [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] and
[<a href="./rfc5148" title=""Jitter Considerations in Mobile Ad Hoc Networks (MANETs)"">RFC5148</a>], the largest contribution the age may be a delay of up to
F_MAXJITTER per hop (except the final hop) that the message has
traveled. Other factors in the delay of both message types, per hop,
may include the link-layer that is used in the MANET, and CPU and
memory resources of routers (e.g., queuing delays, and delays for
processing ICVs). An implementation MAY set lower and/or upper
bounds on these parameters, if so, then these MUST allow values
meeting these requirements. An implementation MAY make its value of
MAX_TC_TIMESTAMP_DIFF dependent on the number of hops that a TC
message has traveled.
The above constraints assume ideal time synchronization of the clock
in all routers in the network. The parameters
MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF (and any
constraints on them) MAY be increased to allow for expected timing
differences between routers (between neighboring routers for
MAX_HELLO_TIMESTAMP_DIFF, allowing for greater separation, but
usually not per hop, for MAX_TC_TIMESTAMP_DIFF).
Note that excessively large values of these parameters defeats their
objectives, so these parameters SHOULD be as large as is required,
but not significantly larger.
Using POSIX time allows a resolution of no more than one second. In
many MANET use cases, time synchronization much below one second is
not possible because of unreliable and high-delay channels, mobility,
interrupted communication, and possible resource limitations.
<span class="grey">Herberg, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
In addition, when using the default message intervals and validity
times as specified in [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>], where the shortest
periodic message interval is 2 seconds, repeating the message within
a second is actually beneficial rather than harmful (at a small
bandwidth cost). Also, the use of [<a href="./rfc5148" title=""Jitter Considerations in Mobile Ad Hoc Networks (MANETs)"">RFC5148</a>] jitter can cause a
message to take that long or longer to traverse the MANET, thus even
in a perfectly synchronized network, the TC maximum delay would
usually be greater than 1 second.
A finer granularity than 1 second, and thus the use of an alternative
timestamp, is however RECOMMENDED in cases where, possibly due to
fast moving routers, message validity times are below 1 second.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Message Generation and Processing</span>
This section specifies how messages are generated and processed by
[<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] when using this mechanism.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Message Content</span>
Messages MUST have the content specified in [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>],
respectively. In addition, messages that conform to this mechanism
MUST contain:
o At least one ICV Message TLV (as specified in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]),
generated according to <a href="#section-6.2">Section 6.2</a>. Implementations of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]
and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] MUST support the following version of the ICV TLV,
but other versions MAY be used instead, or in addition, in a
deployment, if more appropriate:
* For TC messages:
+ type-extension := 1
* For HELLO messages:
+ type-extension := 2
* hash-function := 3 (SHA-256)
* cryptographic-function := 3 (HMAC)
The ICV Value MAY be truncated as specified in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]; the
selection of an appropriate length MAY be administratively
configured. A message MAY contain several ICV Message TLVs.
<span class="grey">Herberg, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
o At least one TIMESTAMP Message TLV (as specified in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>]),
generated according to <a href="#section-6.2">Section 6.2</a>. Implementations of [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>]
and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] using this mechanism MUST support the following
version of the TIMESTAMP TLV, but other versions MAY be used
instead, or in addition, in a deployment, if more appropriate:
* type-extension := 1
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Message Generation</span>
After message generation (<a href="./rfc6130#section-11.1">Section 11.1 of [RFC6130]</a> and <a href="./rfc7181#section-16.1">Section 16.1.
of [RFC7181]</a>) and before message transmission (<a href="./rfc6130#section-11.2">Section 11.2 of
[RFC6130]</a> and <a href="./rfc7181#section-16.2">Section 16.2 of [RFC7181]</a>), the additional TLVs
specified in <a href="#section-6.1">Section 6.1</a> MUST (unless already present) be added to an
outgoing message when using this mechanism.
The following processing steps (when using a single timestamp version
and a single ICV algorithm) MUST be performed for a cryptographic
algorithm that is used for generating an ICV for a message:
1. All ICV TLVs (if any) are temporarily removed from the message.
Any temporarily removed ICV TLVs MUST be stored, in order to be
reinserted into the message in step 5. The message size and
Message TLV Block size are updated accordingly.
2. <msg-hop-count> and <msg-hop-limit>, if present, are temporarily
set to 0.
3. A TLV of type TIMESTAMP, as specified in <a href="#section-6.1">Section 6.1</a>, is added to
the Message TLV Block. The message size and Message TLV Block
size are updated accordingly.
4. A TLV of type ICV, as specified in <a href="#section-6.1">Section 6.1</a>, is added to the
Message TLV Block. The message size and Message TLV Block size
are updated accordingly.
5. All ICV TLVs that were temporary removed in step 1, are restored.
The message size and Message TLV Block size are updated
accordingly.
6. <msg-hop-count> and <msg-hop-limit>, if present, are restored to
their previous values.
An implementation MAY add either alternative TIMESTAMP and/or ICV
TLVs or more than one TIMESTAMP and/or ICV TLVs. All TIMESTAMP TLVs
MUST be inserted before adding ICV TLVs.
<span class="grey">Herberg, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Message Processing</span>
Both [<a href="./rfc6130" title=""Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)"">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] specify that:
On receiving a ... message, a router MUST first check if the
message is invalid for processing by this router
[<a id="ref-RFC6130">RFC6130</a>] and [<a href="./rfc7181" title=""The Optimized Link State Routing Protocol Version 2"">RFC7181</a>] proceed to give a number of conditions that,
each, will lead to a rejection of the message as "badly formed and
therefore invalid for processing". When using a single timestamp
version, and a single ICV algorithm, add the following conditions to
that list, each of which, if true, MUST cause NHDP or OLSRv2 (as
appropriate) to consider the message as invalid for processing when
using this mechanism:
1. The Message TLV Block of the message does not contain exactly one
TIMESTAMP TLV of the selected version. This version
specification includes the type extension. (The Message TLV
Block may also contain TIMESTAMP TLVs of other versions.)
2. The Message TLV Block does not contain exactly one ICV TLV using
the selected algorithm and key identifier. This algorithm
specification includes the type extension, and for type
extensions 1 and 2, the hash function and cryptographic function.
(The Message TLV Block may also contain ICV TLVs using other
algorithms and key identifiers.)
3. Validation of the identified (in step 1) TIMESTAMP TLV in the
Message TLV Block of the message fails, as according to
<a href="#section-6.3.1">Section 6.3.1</a>.
4. Validation of the identified (in step 2) ICV TLV in the Message
TLV Block of the message fails, as according to <a href="#section-6.3.2">Section 6.3.2</a>.
An implementation MAY check the existence of, and verify, either an
alternative TIMESTAMP and/or ICV TLVs or more than one TIMESTAMP and/
or ICV TLVs.
<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>. Validating a Message Based on Timestamp</span>
For a TIMESTAMP Message TLV with type extension 1 (POSIX time)
identified as described in <a href="#section-6.2">Section 6.2</a>:
1. If the current POSIX time minus the value of that TIMESTAMP TLV
is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or
MAX_TC_TIMESTAMP_DIFF (for a TC message), then the message
validation fails.
<span class="grey">Herberg, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
2. Otherwise, the message validation succeeds.
If a deployment chooses to use a different type extension from 1,
appropriate measures MUST be taken to verify freshness of the
message.
<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>. Validating a Message Based on Integrity Check</span>
For an ICV Message TLV identified as described in <a href="#section-6.2">Section 6.2</a>:
1. All ICV Message TLVs (including the identified ICV Message TLV)
are temporarily removed from the message, and the message size
and Message TLV Block size are updated accordingly.
2. The message's <msg-hop-count> and <msg-hop-limit> fields are
temporarily set to 0.
3. Calculate the ICV for the parameters specified in the identified
ICV Message TLV, as specified in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>].
4. If this ICV differs from the value of <ICV-data> in the ICV
Message TLV, then the message validation fails. If the
<ICV-data> has been truncated (as specified in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>], the ICV
calculated in the previous step MUST be truncated to the TLV
length of the ICV Message TLV before comparing it with the
<ICV-data>.
5. Otherwise, the message validation succeeds. The message's
<msg-hop-count> and <msg-hop-limit> fields are restored to their
previous value, and the ICV Message TLVs are returned to the
message, whose size is updated accordingly.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Provisioning of Routers</span>
Before a router using this mechanism is able to generate ICVs or
validate messages, it MUST acquire the shared secret key(s) to be
used by all routers that are to participate in the network. This
specification does not define how a router acquires secret keys.
Once a router has acquired suitable key(s), it MAY be configured to
use, or not use, this mechanism. <a href="./rfc7181#section-23.6">Section 23.6 of [RFC7181]</a> provides
a rationale based on [<a href="#ref-BCP107" title=""Guidelines for Cryptographic Key Management"">BCP107</a>] why no key management is specified for
OLSRv2.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document specifies a security mechanism for use with NHDP and
OLSRv2 that allows for mitigating several security threats.
<span class="grey">Herberg, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Mitigated Attacks</span>
This section briefly summarizes security threats that are mitigated
by the mechanism presented in this document.
<span class="h4"><a class="selflink" id="section-8.1.1" href="#section-8.1.1">8.1.1</a>. Identity Spoofing</span>
As only routers possessing the selected shared secret key are able to
add a valid ICV TLV to a message, identity spoofing, where an
attacker falsely claims an identity of a valid router, is countered.
When using one or more shared keys for all routers in the MANET, it
is only possible to determine that it is a valid router in the
network, not to discern particular routers. Therefore, a malicious
router in possession of valid keys (e.g., a compromised router) may
still spoof the identity of another router using the same key.
<span class="h4"><a class="selflink" id="section-8.1.2" href="#section-8.1.2">8.1.2</a>. Link Spoofing</span>
Link spoofing, where an attacker falsely represents the existence of
a nonexistent link, or otherwise misrepresents a link's state, is
countered by the mechanism specified in this document, using the same
argument as in <a href="#section-8.1.1">Section 8.1.1</a>.
<span class="h4"><a class="selflink" id="section-8.1.3" href="#section-8.1.3">8.1.3</a>. Replay Attack</span>
Replay attacks are partly countered by the mechanism specified in
this document, but this depends on synchronized clocks of all routers
in the MANET. An attacker that records messages to replay them later
can only do so in the selected time interval after the timestamp that
is contained in message. As an attacker cannot modify the content of
this timestamp (as it is protected by the identity check value), an
attacker cannot replay messages after this time. Within this time
interval, it is still possible to perform replay attacks; however,
the limits on the time interval are specified so that this will have
a limited effect on the operation of the protocol.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Limitations</span>
If no synchronized clocks are available in the MANET, replay attacks
cannot be countered by the mechanism provided by this document. An
alternative version of the TIMESTAMP TLV defined in [<a href="./rfc7182" title=""Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)"">RFC7182</a>], with a
monotonic sequence number, may have some partial value in this case,
but will necessitate adding state to record observed message sequence
number information.
The mechanism provided by this document does not avoid or detect
security attacks by routers possessing the shared secret key that is
used to generate integrity check values for messages.
<span class="grey">Herberg, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
This mechanism relies on an out-of-band protocol or mechanism for
distributing the shared secret key(s) (and if an alternative
integrity check value is used, any additional cryptographic
parameters).
This mechanism does not provide a key management mechanism. Refer to
<a href="./rfc7181#section-23.6">Section 23.6 of [RFC7181]</a> for a detailed discussion why the automated
key management requirements specified in [<a href="#ref-BCP107" title=""Guidelines for Cryptographic Key Management"">BCP107</a>] do not apply for
OLSRv2 and NHDP.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
The authors would like to gratefully acknowledge the following
people: Justin Dean (NRL) and Henning Rogge (Frauenhofer FKIE).
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5444">RFC5444</a>] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", <a href="./rfc5444">RFC 5444</a>, February 2009.
[<a id="ref-RFC6130">RFC6130</a>] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
<a href="./rfc6130">RFC 6130</a>, April 2011.
[<a id="ref-RFC7181">RFC7181</a>] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol Version 2", <a href="./rfc7181">RFC</a>
<a href="./rfc7181">7181</a>, April 2014.
[<a id="ref-RFC7182">RFC7182</a>] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", <a href="./rfc7182">RFC 7182</a>, April 2014.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-BCP107">BCP107</a>] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", <a href="https://www.rfc-editor.org/bcp/bcp107">BCP 107</a>, <a href="./rfc4107">RFC 4107</a>, June 2005.
[<a id="ref-RFC5148">RFC5148</a>] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", <a href="./rfc5148">RFC</a>
<a href="./rfc5148">5148</a>, February 2008.
<span class="grey">Herberg, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7183">RFC 7183</a> Integrity Protection for NHDP and OLSRv2 April 2014</span>
Authors' Addresses
Ulrich Herberg
Fujitsu Laboratories of America
1240 E. Arques Ave.
Sunnyvale, CA, 94085
USA
EMail: ulrich@herberg.name
URI: <a href="http://www.herberg.name/">http://www.herberg.name/</a>
Christopher Dearlove
BAE Systems Advanced Technology Centre
West Hanningfield Road
Great Baddow, Chelmsford
United Kingdom
Phone: +44 1245 242194
EMail: chris.dearlove@baesystems.com
URI: <a href="http://www.baesystems.com/">http://www.baesystems.com/</a>
Thomas Heide Clausen
LIX, Ecole Polytechnique
91128 Palaiseau Cedex
France
Phone: +33 6 6058 9349
EMail: T.Clausen@computer.org
URI: <a href="http://www.thomasclausen.org/">http://www.thomasclausen.org/</a>
Herberg, et al. Standards Track [Page 15]
</pre>
|
