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
|
<pre>Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 7474 Ionos Networks
Updates: <a href="./rfc2328">2328</a>, <a href="./rfc5709">5709</a> S. Hartman
Category: Standards Track Painless Security
ISSN: 2070-1721 D. Zhang
Huawei Technologies Co., Ltd.
A. Lindem, Ed.
Cisco
April 2015
<span class="h1">Security Extension for OSPFv2 When Using Manual Key Management</span>
Abstract
The current OSPFv2 cryptographic authentication mechanism as defined
in RFCs 2328 and 5709 is vulnerable to both inter-session and intra-
session replay attacks when using manual keying. Additionally, the
existing cryptographic authentication mechanism does not cover the IP
header. This omission can be exploited to carry out various types of
attacks.
This document defines changes to the authentication sequence number
mechanism that will protect OSPFv2 from both inter-session and intra-
session replay attacks when using manual keys for securing OSPFv2
protocol packets. Additionally, we also describe some changes in the
cryptographic hash computation that will eliminate attacks resulting
from OSPFv2 not protecting the IP header.
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/rfc7474">http://www.rfc-editor.org/info/rfc7474</a>.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
Copyright Notice
Copyright (c) 2015 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-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2">2</a>. Replay Protection Using Extended Sequence Numbers . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Key Selection for Unicast OSPF Packet Transmission . . . <a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Key Selection for Multicast OSPF Packet Transmission . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. Key Selection for OSPF Packet Reception . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. Securing the IP Header . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-7">7</a>. Backward Compatibility . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The OSPFv2 cryptographic authentication mechanism as described in
[<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] uses per-packet sequence numbers to provide protection
against replay attacks. The sequence numbers increase monotonically
so that attempts to replay stale packets can be thwarted. The
sequence number values are maintained as a part of neighbor adjacency
state. Therefore, if an adjacency is taken down, the associated
sequence numbers get reinitialized and neighbor adjacency formation
starts over again. Additionally, the cryptographic authentication
mechanism does not specify how to deal with the rollover of a
sequence number when its value wraps. These omissions can be
exploited by attackers to implement various replay attacks
([<a href="./rfc6039" title=""Issues with Existing Cryptographic Protection Methods for Routing Protocols"">RFC6039</a>]). In order to address these issues, we define extensions
to the authentication sequence number mechanism.
The cryptographic authentication as described in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>] and later
updated in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] does not include the IP header. This omission
can be exploited to launch several attacks as the source address in
the IP header is not protected. The OSPF specification, for
broadcast and NBMA (Non-Broadcast Multi-Access) networks, requires
implementations to use the source address in the IP header to
determine the neighbor from which the packet was received. Changing
the IP source address of a packet to a conflicting IP address can be
exploited to produce a number of denial-of-service attacks [<a href="./rfc6039" title=""Issues with Existing Cryptographic Protection Methods for Routing Protocols"">RFC6039</a>].
If the packet is interpreted as coming from a different neighbor, the
received sequence number state for that neighbor may be incorrectly
updated. This attack may disrupt communication with a legitimate
neighbor. Hello packets may be reflected to cause a neighbor to
appear to have one-way communication. Additionally, Database
Description packets may be reflected in cases where the per-packet
sequence numbers are sufficiently divergent in order to disrupt an
adjacency [<a href="./rfc6863" title=""Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide"">RFC6863</a>]. This is the IP-layer issue described in point
18 in <a href="./rfc6862#section-4">Section 4 of [RFC6862]</a>.
[<a id="ref-RFC2328">RFC2328</a>] states that implementations MUST offer keyed MD5
authentication. It is likely that this will be deprecated in favor
of the stronger algorithms described in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] and required in
[<a href="./rfc6094" title=""Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols"">RFC6094</a>].
This document defines a few simple changes to the cryptographic
authentication mechanism, as currently described in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>], to
prevent such IP-layer attacks.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
When used in lowercase, these words convey their typical use in
common language, and are not to be interpreted as described in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Replay Protection Using Extended Sequence Numbers</span>
In order to provide replay protection against both inter-session and
intra-session replay attacks, the OSPFv2 sequence number is expanded
to 64 bits with the least significant 32-bit value containing a
strictly increasing sequence number and the most significant 32-bit
value containing the boot count. OSPFv2 implementations are required
to retain the boot count in non-volatile storage for the deployment
life of the OSPF router. The requirement to preserve the boot count
is also placed on SNMP agents by the SNMPv3 security architecture
(refer to snmpEngineBoots in <a href="./rfc3414#section-2.2">Section 2.2 of [RFC3414]</a>).
Since there is no room in the OSPFv2 packet for a 64-bit sequence
number, it will occupy the 8 octets following the OSPFv2 packet and
MUST be included when calculating the OSPFv2 packet digest. These
additional 8 octets are not included in the OSPFv2 packet header
length but are included in the OSPFv2 header Authentication Data
length and the IPv4 packet header length.
The lower-order 32-bit sequence number MUST be incremented for every
OSPF packet sent by the OSPF router. Upon reception, the sequence
number MUST be greater than the sequence number in the last OSPF
packet of that type accepted from the sending OSPF neighbor.
Otherwise, the OSPF packet is considered a replayed packet and
dropped. OSPF packets of different types may arrive out of order if
they are prioritized as recommended in [<a href="./rfc4222" title=""Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance"">RFC4222</a>].
OSPF routers implementing this specification MUST use available
mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the OSPFv2 router (including cold
restarts). This is achieved by maintaining a boot count in non-
volatile storage and incrementing it each time the OSPF router loses
its prior sequence number state. The SNMPv3 snmpEngineBoots variable
[<a href="./rfc3414" title=""User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)"">RFC3414</a>] MAY be used for this purpose. However, maintaining a
separate boot count solely for OSPF sequence numbers has the
advantage of decoupling SNMP reinitialization and OSPF
reinitialization. Also, in the rare event that the lower-order
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
32-bit sequence number wraps, the boot count can be incremented to
preserve the strictly increasing property of the aggregate sequence
number. Hence, a separate OSPF boot count is RECOMMENDED.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. OSPF Packet Extensions</span>
The OSPF packet header includes an authentication type field, and 64
bits of data for use by the appropriate authentication scheme
(determined by the type field). Authentication types 0, 1, and 2 are
defined [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]. This section defines Authentication type 3.
When using this authentication scheme, the 64-bit Authentication
field (as defined in <a href="./rfc2328#appendix-D.3">Appendix D.3 of [RFC2328]</a>) in the OSPF packet
header (as defined in <a href="./rfc2328#appendix-A.3.1">Appendix A.3.1 of [RFC2328]</a> and [<a href="./rfc6549" title=""OSPFv2 Multi- Instance Extensions"">RFC6549</a>]) is
changed as shown in Figure 1. The sequence number is removed and the
Key ID is extended to 32 bits and moved to the former position of the
sequence number.
Additionally, the 64-bit sequence number is moved to the first 64
bits following the OSPFv2 packet and is protected by the
authentication digest. These additional 64 bits or 8 octets are
included in the IP header length but not the OSPF header packet
length.
Finally, the 0 field at the start of the OSPFv2 header authentication
is extended from 16 bits to 24 bits.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| OSPF Protocol Packet |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Boot Count) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Strictly Increasing Packet Counter) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authentication Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Sequence Number Packet Extensions
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. OSPF Packet Key Selection</span>
This section describes how this security solution selects long-lived
keys from key tables. [<a href="./rfc7210" title=""Database of Long-Lived Symmetric Cryptographic Keys"">RFC7210</a>]. In this context, we are selecting
the key and corresponding Security Association (SA) as defined in
<a href="./rfc5709#section-3.2">Section 3.2 of [RFC5709]</a>. Generally, a key used for OSPFv2 packet
authentication should satisfy the following requirements:
o For packet transmission, the key validity interval as defined by
SendLifetimeStart and SendLifetimeEnd must include the current
time.
o For packet reception, the key validity interval as defined by
AcceptLifetimeStart and AcceptLifetimeEnd must include the current
time.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
o The key must be valid for the desired security algorithm.
In the remainder of this section, additional requirements for keys
are enumerated for different scenarios.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Key Selection for Unicast OSPF Packet Transmission</span>
Assume that a router R1 tries to send a unicast OSPF packet from its
interface I1 to the interface I2 of a remote router R2 using security
protocol P via interface I at time T. First, consider the
circumstances where R1 and R2 are not connected with a virtual link.
R1 then needs to select a long-lived symmetric key from its key
table. Because the key should be shared by both R1 and R2 to protect
the communication between I1 and I2, the key should satisfy the
following requirements:
o The Peers field contains the area ID or, if no key containing the
area ID is present, the string "all".
o The Direction field is either "out" or "both".
o The Interfaces field matches I1 or "all".
o If multiple keys match the Interface field, keys that explicitly
match I1 should be preferred over keys matching "all". If there
are still multiple keys that match, the key with the most recent
SendLifetimeStart will be selected. This will facilitate graceful
key rollover.
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
set to the selected key's LocalKeyName.
When R1 and R2 are connected to a virtual link, the Peers field must
identify the virtual endpoint rather than the virtual link. Since
there may be virtual links to the same router, the transit area ID
must be part of the identifier. Hence, the key should satisfy the
following requirements:
o The Peers field includes both the virtual endpoint's OSPF router
ID and the transit area ID for the virtual link in the form of the
transit area ID, followed by a colon, followed by the router ID.
If no such key exists, then a key with the Peers field set to the
transit area ID is used, followed by a key with the Peers field
set to "all".
o The Interfaces field is not used for key selection on virtual
links.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
o The Direction field is either "out" or "both".
o If multiple keys match the Peers field, keys that explicitly match
the router ID should be preferred, followed by keys with a transit
area specified, followed by keys with the Peers field set to
"all". If there are still multiple keys that match, the key with
the most recent SendLifetimeStart will be selected. This will
facilitate graceful key rollover.
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
set to the selected key's LocalKeyName.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Key Selection for Multicast OSPF Packet Transmission</span>
If a router R1 sends an OSPF packet from its interface I1 to a
multicast address (i.e., AllSPFRouters or AllDRouters), it needs to
select a key according to the following requirements:
o First, try a key with the Peers field containing the area ID to
which the interface belongs. If no key exists, try a key with the
Peers field "all".
o The Interfaces field matches the interface over which the packet
is sent or "all".
o The Direction field is either "out" or "both".
o If multiple keys match the Interface field, keys that explicitly
match I1 should be preferred over keys matching "all". If there
are still multiple keys that match, the key with the most resent
SendLifetimeStart will be selected. This will facilitate graceful
key rollover.
o The Key ID field in the OSPFv2 header (refer to Figure 1) will be
set to the selected key's LocalKeyName.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Key Selection for OSPF Packet Reception</span>
When cryptographic authentication is used, the ID of the
authentication key is included in the authentication field of the
OSPF packet header. Using this Key ID, it is straight forward for a
receiver to locate the corresponding key. The simple requirements
are:
o The interface on which the key was received is associated with the
key's interface.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
o The Key ID obtained from the OSPFv2 packet header corresponds to
the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the
LocalKeyName and PeerKeyName for OSPFv2 keys will be identical.
Hence, the Key ID will be used to select the correct local key.
o The Direction field is either "in" or "both".
o The Peers field matches as described in Sections <a href="#section-4.1">Section 4.1</a> and
<a href="#section-4.2">Section 4.2</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Securing the IP Header</span>
This document updates the definition of the Apad constant, as it is
defined in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>], to include the IP source address from the IP
header of the OSPFv2 protocol packet. The overall cryptographic
authentication process defined in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] remains unchanged. To
reduce the potential for confusion, this section minimizes the
repetition of text from <a href="./rfc5709">RFC 5709</a> [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>]. The changes are:
<a href="./rfc5709#section-3.3">RFC 5709, Section 3.3</a> describes how the cryptographic authentication
must be computed. In <a href="./rfc5709">RFC 5709</a>, the First-Hash includes the OSPF
packet and Authentication Trailer. With this specification, the
64-bit sequence number will be included in the First-Hash along with
the Authentication Trailer and OSPF packet.
<a href="./rfc5709#section-3.3">RFC 5709, Section 3.3</a> also requires the OSPFv2 packet's
Authentication Trailer (which is the appendage described in <a href="./rfc2328#appendix-D.4.3">RFC 2328,
Appendix D.4.3</a>, page 233, items (6)(a) and (6)(d)) to be filled with
the value Apad. Apad is a hexadecimal constant with the value
0x878FE1F3 repeated (L/4) times, where L is the length of the hash
being used and is measured in octets rather than bits.
OSPF routers sending OSPF packets must initialize the first 4 octets
of Apad to the value of the IP source address that would be used when
sending the OSPFv2 packet. The remainder of Apad will contain the
value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of
the hash, measured in octets. The basic idea is to incorporate the
IP source address from the IP header in the cryptographic
authentication computation so that any change of IP source address in
a replayed packet can be detected.
When an OSPF packet is received, implementations MUST initialize the
first 4 octets of Apad to the IP source address from the IP header of
the incoming OSPFv2 packet. The remainder of Apad will contain the
value 0x878FE1F3 repeated (L - 4)/4 times, where L is the length of
the hash, measured in octets. Besides changing the value of Apad,
this document does not introduce any other changes to the
authentication mechanism described in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>]. This would prevent
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
all attacks where a rogue OSPF router changes the IP source address
of an OSPFv2 packet and replays it on the same multi-access interface
or another interface since the IP source address is now included in
the cryptographic hash computation and modification would result in
the OSPFv2 packet being dropped due to an authentication failure.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Mitigating Cross-Protocol Attacks</span>
In order to prevent cross-protocol replay attacks for protocols
sharing common keys, the two-octet OSPFv2 Cryptographic Protocol ID
is appended to the authentication key prior to use. Refer to the
IANA Considerations (<a href="#section-9">Section 9</a>).
<a href="./rfc5709#section-3.3">[RFC5709], Section 3.3</a> describes the mechanism to prepare the key
used in the hash computation. This document updates the text under
"(1) PREPARATION OF KEY" as follows:
The OSPFv2 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific Authentication
Key (Ks). In this application, Ko is always L octets long. While
[<a href="./rfc2104" title=""HMAC: Keyed- Hashing for Message Authentication"">RFC2104</a>] supports a key that is up to B octets long, this
application uses L as the Ks length consistent with [<a href="./rfc4822" title=""RIPv2 Cryptographic Authentication"">RFC4822</a>],
[<a href="./rfc5310" title=""IS-IS Generic Cryptographic Authentication"">RFC5310</a>], and [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>]. According to [<a href="#ref-FIPS-198">FIPS-198</a>], Section 3,
keys greater than L octets do not significantly increase the
function strength. Ks is computed as follows:
If the Protocol-Specific Authentication Key (Ks) is L octets long,
then Ko is equal to Ks. If the Protocol-Specific Authentication
Key (Ks) is more than L octets long, then Ko is set to H(Ks). If
the Protocol-Specific Authentication Key (Ks) is less than L
octets long, then Ko is set to the Protocol-Specific
Authentication Key (Ks) with zeros appended to the end of the
Protocol-Specific Authentication Key (Ks) such that Ko is L octets
long.
Once the cryptographic key (Ko) used with the hash algorithm is
derived, the rest of the authentication mechanism described in
[<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] remains unchanged other than one detail that was
unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with
zeros to the length of Ipad or Opad. It is expected that
implementations of [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] perform this padding implicitly.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Backward Compatibility</span>
This security extension uses a new authentication type, AuType in the
OSPFv2 header (refer to Figure 1). When an OSPFv2 packet is received
and the AuType doesn't match the configured authentication type for
the interface, the OSPFv2 packet will be dropped as specified in <a href="./rfc2328">RFC</a>
<a href="./rfc2328">2328</a> [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]. This guarantees backward-compatible behavior
consistent with any other authentication type mismatch.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document rectifies the manual key management procedure that
currently exists within OSPFv2, as part of Phase 1 of the KARP
Working Group. Therefore, only the OSPFv2 manual key management
mechanism is considered. Any solution that takes advantage of the
automatic key management mechanism is beyond the scope of this
document.
The described sequence number extension offers most of the benefits
of more complicated mechanisms without their attendant challenges.
There are, however, a couple drawbacks to this approach. First, it
requires the OSPF implementation to be able to save its boot count in
non-volatile storage. If the non-volatile storage is ever repaired
or upgraded such that the contents are lost or the OSPFv2 router is
replaced, the authentication keys MUST be changed to prevent replay
attacks.
Second, if a router is taken out of service completely (either
intentionally or due to a persistent failure), the potential exists
for reestablishment of an OSPFv2 adjacency by replaying the entire
OSPFv2 session establishment. However, this scenario is extremely
unlikely, since it would imply an identical OSPFv2 adjacency
formation packet exchange. Without adjacency formation, the replay
of OSPFv2 hello packets alone for an OSPFv2 router that has been
taken out of service should not result in any serious attack, as the
only consequence is superfluous processing. Of course, this attack
could also be thwarted by changing the relevant manual keys.
This document also provides a solution to prevent certain denial-of-
service attacks that can be launched by changing the source address
in the IP header of an OSPFv2 protocol packet.
Using a single crypto sequence number can leave the router vulnerable
to a replay attack where it uses the same source IP address on two
different point-to-point unnumbered links. In such environments
where an attacker can actively tap the point-to-point links, it's
recommended that the user employ different keys on each of those
unnumbered IP interfaces.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. IANA Considerations</span>
This document registers a new code point from the "OSPF Shortest Path
First (OSPF) Authentication Codes" registry:
o 3 - Cryptographic Authentication with Extended Sequence Numbers.
This document also registers a new code point from the
"Authentication Cryptographic Protocol ID" registry defined under
"Keying and Authentication for Routing Protocols (KARP) Parameters":
o 3 - OSPFv2.
<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 href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998,
<<a href="http://www.rfc-editor.org/info/rfc2328">http://www.rfc-editor.org/info/rfc2328</a>>.
[<a id="ref-RFC5709">RFC5709</a>] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", <a href="./rfc5709">RFC 5709</a>, October 2009,
<<a href="http://www.rfc-editor.org/info/rfc5709">http://www.rfc-editor.org/info/rfc5709</a>>.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-FIPS-198">FIPS-198</a>]
US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198-1, July 2008.
[<a id="ref-RFC2104">RFC2104</a>] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", <a href="./rfc2104">RFC 2104</a>, February
1997, <<a href="http://www.rfc-editor.org/info/rfc2104">http://www.rfc-editor.org/info/rfc2104</a>>.
[<a id="ref-RFC3414">RFC3414</a>] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, <a href="./rfc3414">RFC 3414</a>, December 2002,
<<a href="http://www.rfc-editor.org/info/rfc3414">http://www.rfc-editor.org/info/rfc3414</a>>.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
[<a id="ref-RFC4222">RFC4222</a>] Choudhury, G., Ed., "Prioritized Treatment of Specific
OSPF Version 2 Packets and Congestion Avoidance", <a href="https://www.rfc-editor.org/bcp/bcp112">BCP 112</a>,
<a href="./rfc4222">RFC 4222</a>, October 2005,
<<a href="http://www.rfc-editor.org/info/rfc4222">http://www.rfc-editor.org/info/rfc4222</a>>.
[<a id="ref-RFC4822">RFC4822</a>] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", <a href="./rfc4822">RFC 4822</a>, February 2007,
<<a href="http://www.rfc-editor.org/info/rfc4822">http://www.rfc-editor.org/info/rfc4822</a>>.
[<a id="ref-RFC5310">RFC5310</a>] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", <a href="./rfc5310">RFC 5310</a>, February 2009,
<<a href="http://www.rfc-editor.org/info/rfc5310">http://www.rfc-editor.org/info/rfc5310</a>>.
[<a id="ref-RFC6039">RFC6039</a>] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", <a href="./rfc6039">RFC 6039</a>, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc6039">http://www.rfc-editor.org/info/rfc6039</a>>.
[<a id="ref-RFC6094">RFC6094</a>] Bhatia, M. and V. Manral, "Summary of Cryptographic
Authentication Algorithm Implementation Requirements for
Routing Protocols", <a href="./rfc6094">RFC 6094</a>, February 2011,
<<a href="http://www.rfc-editor.org/info/rfc6094">http://www.rfc-editor.org/info/rfc6094</a>>.
[<a id="ref-RFC6549">RFC6549</a>] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", <a href="./rfc6549">RFC 6549</a>, March 2012,
<<a href="http://www.rfc-editor.org/info/rfc6549">http://www.rfc-editor.org/info/rfc6549</a>>.
[<a id="ref-RFC6862">RFC6862</a>] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", <a href="./rfc6862">RFC 6862</a>, March 2013,
<<a href="http://www.rfc-editor.org/info/rfc6862">http://www.rfc-editor.org/info/rfc6862</a>>.
[<a id="ref-RFC6863">RFC6863</a>] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", <a href="./rfc6863">RFC 6863</a>, March 2013,
<<a href="http://www.rfc-editor.org/info/rfc6863">http://www.rfc-editor.org/info/rfc6863</a>>.
[<a id="ref-RFC7210">RFC7210</a>] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", <a href="./rfc7210">RFC</a>
<a href="./rfc7210">7210</a>, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7210">http://www.rfc-editor.org/info/rfc7210</a>>.
<span class="grey">Bhatia, 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="./rfc7474">RFC 7474</a> OSPF Manual Key Management April 2015</span>
Acknowledgments
Thanks to Ran Atkinson for help in the analysis of errata for <a href="./rfc6506">RFC</a>
<a href="./rfc6506">6506</a>, which led to clarifications in this document.
Thanks to Gabi Nakibly for pointing out a possible attack on P2P
links.
Thanks to Suresh Krishnan for comments made during the Gen-Art
review. In particular, thanks for pointing out an ambiguity in the
initialization of Apad.
Thanks to Shaun Cooley for the security directorate review.
Thanks to Adrian Farrel for comments during the IESG last call.
Authors' Addresses
Manav Bhatia
Ionos Networks
Bangalore
India
EMail: manav@ionosnetworks.com
Sam Hartman
Painless Security
EMail: hartmans-ietf@mit.edu
Dacheng Zhang
Huawei Technologies Co., Ltd.
Beijing
China
EMail: dacheng.zhang@gmail.com
Acee Lindem (editor)
Cisco
United States
EMail: acee@cisco.com
Bhatia, et al. Standards Track [Page 14]
</pre>
|
