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
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
|
<pre>Internet Engineering Task Force (IETF) M. Bhatia
Request for Comments: 6506 Alcatel-Lucent
Category: Standards Track V. Manral
ISSN: 2070-1721 Hewlett Packard
A. Lindem
Ericsson
February 2012
<span class="h1">Supporting Authentication Trailer for OSPFv3</span>
Abstract
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
for authenticating protocol packets. This behavior is different from
authentication mechanisms present in other routing protocols (OSPFv2,
Intermediate System to Intermediate System (IS-IS), RIP, and Routing
Information Protocol Next Generation (RIPng)). In some environments,
it has been found that IPsec is difficult to configure and maintain
and thus cannot be used. This document defines an alternative
mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
not only depend upon IPsec for authentication.
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/rfc6506">http://www.rfc-editor.org/info/rfc6506</a>.
Copyright Notice
Copyright (c) 2012 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
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
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-2">2</a>
<a href="#section-1.1">1.1</a>. Requirements ...............................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Proposed Solution ...............................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. AT-Bit in Options Field ....................................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Basic Operation ............................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. IPv6 Source Address Protection .............................<a href="#page-5">5</a>
<a href="#section-3">3</a>. OSPFv3 Security Association .....................................<a href="#page-6">6</a>
<a href="#section-4">4</a>. Authentication Procedure ........................................<a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Authentication Trailer .....................................<a href="#page-8">8</a>
<a href="#section-4.1.1">4.1.1</a>. Sequence Number Wrap ...............................<a href="#page-10">10</a>
<a href="#section-4.2">4.2</a>. OSPFv3 Header Checksum ....................................<a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. Cryptographic Authentication Procedure ....................<a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Cross-Protocol Attack Mitigation ..........................<a href="#page-11">11</a>
<a href="#section-4.5">4.5</a>. Cryptographic Aspects .....................................<a href="#page-11">11</a>
<a href="#section-4.6">4.6</a>. Message Verification ......................................<a href="#page-13">13</a>
<a href="#section-5">5</a>. Migration and Backward Compatibility ...........................<a href="#page-15">15</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-15">15</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-16">16</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-17">17</a>
<a href="#appendix-A">Appendix A</a>. Acknowledgments ......................................<a href="#page-19">19</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Unlike Open Shortest Path First version 2 (OSPFv2) [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], OSPF
for IPv6 (OSPFv3) [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>] does not include the AuType and
Authentication fields in its headers for authenticating protocol
packets. Instead, OSPFv3 relies on the IPsec protocols
Authentication Header (AH) [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>] and Encapsulating Security
Payload (ESP) [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] to provide integrity, authentication, and/or
confidentiality.
[<a id="ref-RFC4552">RFC4552</a>] describes how IPv6 AH and ESP extension headers can be used
to provide authentication and/or confidentiality to OSPFv3.
However, there are some environments, e.g., Mobile Ad Hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and
this mechanism cannot be used.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
[<a id="ref-RFC4552">RFC4552</a>] discusses, at length, the reasoning behind using manually
configured keys, rather than some automated key management protocol
such as Internet Key Exchange version 2 (IKEv2) [<a href="./rfc5996" title=""Internet Key Exchange Protocol Version 2 (IKEv2)"">RFC5996</a>]. The
primary problem is the lack of a suitable key management mechanism,
as OSPFv3 adjacencies are formed on a one-to-many basis and most key
management mechanisms are designed for a one-to-one communication
model. This forces the system administrator to use manually
configured security associations (SAs) and cryptographic keys to
provide the authentication and, if desired, confidentiality services.
Regarding replay protection, [<a href="./rfc4552" title=""Authentication/Confidentiality for OSPFv3"">RFC4552</a>] states that:
Since it is not possible using the current standards to provide
complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks.
Since there is no replay protection provided there are a number of
vulnerabilities in OSPFv3 that have been discussed in [<a href="./rfc6039" title=""Issues with Existing Cryptographic Protection Methods for Routing Protocols"">RFC6039</a>].
Since there is no deterministic way to differentiate between
encrypted and unencrypted ESP packets by simply examining the packet,
it could be difficult for some implementations to prioritize certain
OSPFv3 packet types, e.g., Hello packets, over the other types.
This document defines a new mechanism that works similarly to OSPFv2
[<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] to provide authentication to the OSPFv3 packets and
attempts to solve the problems related to replay protection and
deterministically disambiguating different OSPFv3 packets as
described above.
This document adds support for the Secure Hash Algorithms (SHAs)
defined in the US NIST Secure Hash Standard (SHS), which is specified
by NIST FIPS 180-3. [<a href="#ref-FIPS-180-3" title=""Secure Hash Standard (SHS)"">FIPS-180-3</a>] includes SHA-1, SHA-224, SHA-256,
SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC)
authentication mode defined in NIST FIPS 198-1 [<a href="#ref-FIPS-198-1" title=""The Keyed-Hash Message Authentication Code (HMAC)"">FIPS-198-1</a>] is used.
It is believed that HMAC as defined in [<a href="./rfc2104" title=""HMAC: Keyed-Hashing for Message Authentication"">RFC2104</a>] is mathematically
identical to [<a href="#ref-FIPS-198-1" title=""The Keyed-Hash Message Authentication Code (HMAC)"">FIPS-198-1</a>]; it is also believed that algorithms in
[<a href="./rfc6234" title=""US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"">RFC6234</a>] are mathematically identical to [<a href="#ref-FIPS-198-1" title=""The Keyed-Hash Message Authentication Code (HMAC)"">FIPS-198-1</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements</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>].
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Proposed Solution</span>
To perform non-IPsec Cryptographic Authentication, OSPFv3 routers
append a special data block, henceforth referred to as the
Authentication Trailer, to the end of the OSPFv3 packets. The length
of the Authentication Trailer is not included in the length of the
OSPFv3 packet but is included in the IPv6 payload length, as shown in
Figure 1.
+---------------------+ -- -- +----------------------+
| IPv6 Payload Length | ^ ^ | IPv6 Payload Length |
| PL = OL + LL | | | | PL = OL + LL + AL |
| | v v | |
+---------------------+ -- -- +----------------------+
| OSPFv3 Header | ^ ^ | OSPFv3 Header |
| Length = OL | | | | Length = OL |
| | | OSPFv3 | | |
|.....................| | Packet | |......................|
| | | Length | | |
| OSPFv3 Packet | | | | OSPFv3 Packet |
| | v v | |
+---------------------+ -- -- +----------------------+
| | ^ ^ | |
| Optional LLS | | LLS Data | | Optional LLS |
| LLS Block Len = LL | | Block | | LLS Block Len = LL |
| | v Length v | |
+---------------------+ -- -- +----------------------+
^ | |
AL = PL - (OL + LL) | | Authentication |
| | AL = Fixed Trailer + |
v | Digest Length |
-- +----------------------+
Figure 1: Authentication Trailer in OSPFv3
The presence of the Link-Local Signaling (LLS) [<a href="./rfc5613" title=""OSPF Link-Local Signaling"">RFC5613</a>] block is
determined by the L-bit setting in the OSPFv3 Options field in OSPFv3
Hello and Database Description packets. If present, the LLS data
block is included along with the OSPFv3 packet in the Cryptographic
Authentication computation.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. AT-Bit in Options Field</span>
A new AT-bit (AT stands for Authentication Trailer) is introduced
into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in
OSPFv3 Hello and Database Description packets to indicate that all
the packets on this link will include an Authentication Trailer. For
OSPFv3 Hello and Database Description packets, the AT-bit indicates
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
the AT is present. For other OSPFv3 packet types, the OSPFv3 AT-bit
setting from the OSPFv3 Hello/Database Description setting is
preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types
that don't include an OSPFv3 Options field will use the setting from
the neighbor data structure to determine whether or not the AT is
expected.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
Figure 2: OSPFv3 Options Field
The AT-bit, as shown in the figure above, MUST be set in all OSPFv3
Hello and Database Description packets that contain an Authentication
Trailer.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Basic Operation</span>
The procedure followed for computing the Authentication Trailer is
much the same as described in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] and [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]. One
difference is that the LLS data block, if present, is included in the
Cryptographic Authentication computation.
The way the authentication data is carried in the Authentication
Trailer is very similar to how it is done in case of [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>]. The
only difference between the OSPFv2 Authentication Trailer and the
OSPFv3 Authentication Trailer is that information in addition to the
message digest is included. The additional information in the OSPFv3
Authentication Trailer is included in the message digest computation
and is therefore protected by OSPFv3 Cryptographic Authentication as
described herein.
Consistent with OSPFv2 Cryptographic Authentication [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], both
OSPFv3 header checksum calculation and verification are omitted when
the OSPFv3 authentication mechanism described in this specification
is used.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. IPv6 Source Address Protection</span>
While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors,
the IPv6 source address is learned from OSPFv3 Hello packets and
copied into the neighbor data structure [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>]. Hence, OSPFv3 is
susceptible to Man-in-the-Middle attacks where the IPv6 source
address is modified. To thwart such attacks, the IPv6 source address
will be included in the message digest calculation and protected by
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
OSPFv3 authentication. Refer to <a href="#section-4.5">Section 4.5</a> for details. This is
different than the procedure specified in [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>] but consistent
with [<a href="#ref-MANUAL-KEY" title=""Security Extension for OSPFv2 when using Manual Key Management"">MANUAL-KEY</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. OSPFv3 Security Association</span>
An OSPFv3 Security Association (SA) contains a set of parameters
shared between any two legitimate OSPFv3 speakers.
Parameters associated with an OSPFv3 SA are as follows:
o Security Association Identifier (SA ID)
This is a 16-bit unsigned integer used to uniquely identify an
OSPFv3 SA, as manually configured by the network operator.
The receiver determines the active SA by looking at the SA ID
field in the incoming protocol packet.
The sender, based on the active configuration, selects an SA to
use and puts the correct Key ID value associated with the SA in
the OSPFv3 protocol packet. If multiple valid and active OSPFv3
SAs exist for a given interface, the sender may use any of those
SAs to protect the packet.
Using SA IDs makes changing keys while maintaining protocol
operation convenient. Each SA ID specifies two independent parts,
the authentication algorithm and the Authentication Key, as
explained below.
Normally, an implementation would allow the network operator to
configure a set of keys in a key chain, with each key in the chain
having a fixed lifetime. The actual operation of these mechanisms
is outside the scope of this document.
Note that each SA ID can indicate a key with a different
authentication algorithm. This allows the introduction of new
authentication mechanisms without disrupting existing OSPFv3
adjacencies.
o Authentication Algorithm
This signifies the authentication algorithm to be used with this
OSPFv3 SA. This information is never sent in clear text over the
wire. Because this information is not sent on the wire, the
implementer chooses an implementation-specific representation for
this information.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
Currently, the following algorithms are supported:
* HMAC-SHA-1,
* HMAC-SHA-256,
* HMAC-SHA-384, and
* HMAC-SHA-512.
o Authentication Key
This value denotes the Cryptographic Authentication Key associated
with this OSPFv3 SA. The length of this key is variable and
depends upon the authentication algorithm specified by the OSPFv3
SA.
o KeyStartAccept
The time that this OSPFv3 router will accept packets that have
been created with this OSPFv3 SA.
o KeyStartGenerate
The time that this OSPFv3 router will begin using this OSPFv3 SA
for OSPFv3 packet generation.
o KeyStopGenerate
The time that this OSPFv3 router will stop using this OSPFv3 SA
for OSPFv3 packet generation.
o KeyStopAccept
The time that this OSPFv3 router will stop accepting packets
generated with this OSPFv3 SA.
In order to achieve smooth key transition, KeyStartAccept SHOULD be
less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than
KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left
unspecified, the time will default to 0, and the key will be used
immediately. If KeyStopGenerate or KeyStopAccept are left
unspecified, the time will default to infinity, and the key's
lifetime will be infinite. When a new key replaces an old, the
KeyStartGenerate time for the new key MUST be less than or equal to
the KeyStopGenerate time of the old key.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
Key storage SHOULD persist across a system restart, warm or cold, to
avoid operational issues. In the event that the last key associated
with an interface expires, it is unacceptable to revert to an
unauthenticated condition and not advisable to disrupt routing.
Therefore, the router SHOULD send a "last Authentication Key
expiration" notification to the network operator and treat the key as
having an infinite lifetime until the lifetime is extended, the key
is deleted by the network operator, or a new key is configured.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Authentication Procedure</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Authentication Trailer</span>
The Authentication Trailer that is appended to the OSPFv3 protocol
packet is described below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Authentication Trailer Format
The various fields in the Authentication Trailer are:
o Authentication Type
16-bit field identifying the type of authentication. The
following values are defined in this specification:
0 - Reserved.
1 - HMAC Cryptographic Authentication as described herein.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
o Auth Data Len
The length in octets of the Authentication Trailer (AT) including
both the 16-octet fixed header and the variable length message
digest.
o Reserved
This field is reserved. It SHOULD be set to 0 when sending
protocol packets and MUST be ignored when receiving protocol
packets.
o Security Association Identifier (SA ID)
16-bit field that maps to the authentication algorithm and the
secret key used to create the message digest appended to the
OSPFv3 protocol packet.
Though the SA ID implicitly implies the algorithm, the HMAC output
size should not be used by implementers as an implicit hint
because additional algorithms may be defined in the future that
have the same output size.
o Cryptographic Sequence Number
64-bit strictly increasing sequence number that is used to guard
against replay attacks. The 64-bit sequence number MUST be
incremented for every OSPFv3 packet sent by the OSPFv3 router.
Upon reception, the sequence number MUST be greater than the
sequence number in the last OSPFv3 packet accepted from the
sending OSPFv3 neighbor. Otherwise, the OSPFv3 packet is
considered a replayed packet and dropped.
OSPFv3 routers implementing this specification MUST use available
mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the OSPFv3 router (including
cold restarts). One mechanism for accomplishing this would be to
use the high-order 32 bits of the sequence number as a wrap/boot
count that is incremented anytime the OSPFv3 router loses its
sequence number state. Sequence number wrap is described in
<a href="#section-4.1.1">Section 4.1.1</a>.
o Authentication Data
Variable data that is carrying the digest for the protocol packet
and optional LLS data block.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Sequence Number Wrap</span>
When incrementing the sequence number for each transmitted OSPFv3
packet, the sequence number should be treated as an unsigned 64-bit
value. If the lower-order 32-bit value wraps, the higher-order
32-bit value should be incremented and saved in non-volatile storage.
If by some chance the OSPFv3 router is deployed long enough that
there is a possibility that the 64-bit sequence number may wrap, all
keys, independent of their key distribution mechanism, MUST be reset
to avoid the possibility of replay attacks. Once the keys have been
changed, the higher-order sequence number can be reset to 0 and saved
to non-volatile storage.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. OSPFv3 Header Checksum</span>
Both OSPFv3 header checksum calculation and verification are omitted
when the OSPFv3 authentication mechanism described in this
specification is used. This implies:
o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum
computation is omitted, and the OSPFv3 header checksum SHOULD be
set to 0 prior to computation of the OSPFv3 Authentication Trailer
message digest.
o For received OSPFv3 packets including an OSPFv3 Authentication
Trailer, OSPFv3 header checksum verification MUST be omitted.
However, if the OSPFv3 packet does include a non-zero OSPFv3
header checksum, it will not be modified by the receiver and will
simply be included in the OSPFv3 Authentication Trailer message
digest verification.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Cryptographic Authentication Procedure</span>
As noted earlier, the SA ID maps to the authentication algorithm and
the secret key used to generate and verify the message digest. This
specification discusses the computation of OSPFv3 Cryptographic
Authentication data when any of the NIST SHS family of algorithms is
used in the Hashed Message Authentication Code (HMAC) mode.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
The currently valid algorithms (including mode) for OSPFv3
Cryptographic Authentication include:
o HMAC-SHA-1,
o HMAC-SHA-256,
o HMAC-SHA-384, and
o HMAC-SHA-512.
Of the above, implementations of this specification MUST include
support for at least HMAC-SHA-256 and SHOULD include support for
HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and
HMAC-SHA-512.
Implementations of this specification MUST use HMAC-SHA-256 as the
default authentication algorithm.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Cross-Protocol Attack Mitigation</span>
In order to prevent cross-protocol replay attacks for protocols
sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID
is appended to the Authentication Key prior to use. Other protocols
using Cryptographic Authentication as specified herein MUST similarly
append their respective Cryptographic Protocol IDs to their keys in
this step. Refer to the IANA Considerations (<a href="#section-7">Section 7</a>).
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Cryptographic Aspects</span>
In the algorithm description below, the following nomenclature, which
is consistent with [<a href="#ref-FIPS-198-1" title=""The Keyed-Hash Message Authentication Code (HMAC)"">FIPS-198-1</a>], is used:
H is the specific hashing algorithm (e.g., SHA-256).
K is the Authentication Key from the OSPFv3 Security Association.
Ks is a Protocol-Specific Authentication Key obtained by appending
Authentication Key (K) with the two-octet OSPFv3 Cryptographic
Protocol ID.
Ko is the cryptographic key used with the hash algorithm.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
B is the block size of H, measured in octets rather than bits. Note
that B is the internal block size, not the hash size.
For SHA-1 and SHA-256: B == 64
For SHA-384 and SHA-512: B == 128
L is the length of the hash, measured in octets rather than bits.
XOR is the exclusive-or operation.
Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times.
Apad is a value that is the same length as the hash output or message
digest. The first 16 octets contain the IPv6 source address followed
by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This
implies that hash output is always a length of at least 16 octets.
1. Preparation of the Key
The OSPFv3 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 and is computed as follows:
If the Protocol-Specific Authentication Key (Ks) is L octets
long, then Ko is equal to K. 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.
2. First-Hash
First, the OSPFv3 packet's Authentication Data field in the
Authentication Trailer is filled with the value Apad. This is
very similar to the appendage described in [<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], Section
D.4.3, Items (6)(a) and (6)(d)).
Then, a First-Hash, also known as the inner hash, is computed as
follows:
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
Implementation Note: The First-Hash above includes the
Authentication Trailer, as well as the OSPFv3 packet, as per
[<a href="./rfc2328" title=""OSPF Version 2"">RFC2328</a>], Section D.4.3, and, if present, the LLS data block
[<a href="./rfc5613" title=""OSPF Link-Local Signaling"">RFC5613</a>].
The definition of Apad (above) ensures it is always the same
length as the hash output. This is consistent with <a href="./rfc2328">RFC 2328</a>.
Note that the "(OSPFv3 Packet)" referenced in the First-Hash
function above includes both the optional LLS data block and the
OSPFv3 Authentication Trailer.
The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets;
for SHA-384, 48 octets; and for SHA-512, 64 octets.
3. Second-Hash
Then a Second-Hash, also known as the outer hash, is computed as
follows:
Second-Hash = H(Ko XOR Opad || First-Hash)
4. Result
The resulting Second-Hash becomes the authentication data that is
sent in the Authentication Trailer of the OSPFv3 packet. The
length of the authentication data is always identical to the
message digest size of the specific hash function H that is being
used.
This also means that the use of hash functions with larger output
sizes will also increase the size of the OSPFv3 packet as
transmitted on the wire.
Implementation Note: <a href="./rfc2328#appendix-D">[RFC2328], Appendix D</a> specifies that the
Authentication Trailer is not counted in the OSPF packet's own
Length field but is included in the packet's IP Length field.
Similar to this, the Authentication Trailer is not included in
the OSPFv3 header length but is included in the IPv6 header
payload length.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Message Verification</span>
A router would determine that OSPFv3 is using an Authentication
trailer by examining the AT-bit in the Options field in the OSPFv3
header for Hello and Database Description packets. The specification
in the Hello and Database Description options indicates that other
OSPFv3 packets will include the Authentication Trailer.
<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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
The Authentication Trailer (AT) is accessed using the OSPFv3 packet
header length to access the data after the OSPFv3 packet and, if an
LLS data block [<a href="./rfc5613" title=""OSPF Link-Local Signaling"">RFC5613</a>] is present, using the LLS data block length
to access the data after the LLS data block. The L-bit in the OSPFv3
options in Hello and Database Description packets is examined to
determine if an LLS data block is present. If an LLS data block is
present (as specified by the L-bit), it is included along with the
OSPFv3 Hello or Database Description packet in the cryptographic
authentication computation.
Due to the placement of the AT following the LLS data block and the
fact that the LLS data block is included in the Cryptographic
Authentication computation, OSPFv3 routers supporting this
specification MUST minimally support examining the L-bit in the
OSPFv3 options and using the length in the LLS data block to access
the AT. It is RECOMMENDED that OSPFv3 routers supporting this
specification fully support OSPFv3 Link-Local Signaling [<a href="./rfc5613" title=""OSPF Link-Local Signaling"">RFC5613</a>].
If usage of the Authentication Trailer (AT), as specified herein, is
configured for an OSPFv3 link, OSPFv3 Hello and Database Description
packets with the AT-bit clear in the options will be dropped. All
OSPFv3 packet types will be dropped if AT is configured for the link
and the IPv6 header length is less than the amount necessary to
include an Authentication Trailer.
If the cryptographic sequence number in the AT is less than or equal
to the last sequence number successfully received from the neighbor,
the OSPFv3 packet MUST be dropped, and an error event SHOULD be
logged.
Authentication-algorithm-dependent processing needs to be performed,
using the algorithm specified by the appropriate OSPFv3 SA for the
received packet.
Before an implementation performs any processing, it needs to save
the values of the Authentication Data field from the Authentication
Trailer appended to the OSPFv3 packet.
It should then set the Authentication Data field with Apad before the
authentication data is computed (as described in <a href="#section-4.5">Section 4.5</a>). The
calculated data is compared with the received authentication data in
the Authentication Trailer. If the two do not match, the packet MUST
be discarded and an error event SHOULD be logged.
After the OSPFv3 packet has been successfully authenticated,
implementations MUST store the 64-bit cryptographic sequence number
for future replay checks.
<span class="grey">Bhatia, 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="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Migration and Backward Compatibility</span>
All OSPFv3 routers participating on a link SHOULD be migrated to
OSPFv3 Authentication at the same time. As with OSPFv2
authentication, a mismatch in the SA ID, Authentication Type, or
message digest will result in failure to form an adjacency. For
multi-access links, communities of OSPFv3 routers could be migrated
using different Interface Instance IDs. However, at least one router
would need to form adjacencies between both the OSPFv3 routers
including and not including the Authentication Trailer. This would
result in sub-optimal routing as well as added complexity and is only
recommended in cases where authentication is desired on the link and
migrating all the routers on the link at the same time isn't
feasible.
In support of uninterrupted deployment, an OSPFv3 router implementing
this specification MAY implement a transition mode where it includes
the Authentication Trailer in transmitted packets but does not verify
this information in received packets. This is provided as a
transition aid for networks in the process of migrating to the
authentication mechanism described in this specification.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The document proposes extensions to OSPFv3 that would make it more
secure than [<a href="./rfc5340" title=""OSPF for IPv6"">RFC5340</a>]. It does not provide confidentiality as a
routing protocol contains information that does not need to be kept
secret. It does, however, provide means to authenticate the sender
of the packets that are of interest. It addresses all the security
issues that have been identified in [<a href="./rfc6039" title=""Issues with Existing Cryptographic Protection Methods for Routing Protocols"">RFC6039</a>].
It should be noted that the authentication method described in this
document is not being used to authenticate the specific originator of
a packet but is rather being used to confirm that the packet has
indeed been issued by a router that has access to the Authentication
Key.
Deployments SHOULD use sufficiently long and random values for the
Authentication Key so that guessing and other cryptographic attacks
on the key are not feasible in their environments. Furthermore, it
is RECOMMENDED that Authentication Keys incorporate at least 128
pseudo-random bits to minimize the risk of such attacks. In support
of these recommendations, management systems SHOULD support
hexadecimal input of Authentication Keys.
<span class="grey">Bhatia, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
The mechanism described herein is not perfect and does not need to be
perfect. Instead, this mechanism represents a significant increase
in the effort required for an adversary to successfully attack the
OSPFv3 protocol while not causing undue implementation, deployment,
or operational complexity.
Refer to [<a href="./rfc4552" title=""Authentication/Confidentiality for OSPFv3"">RFC4552</a>] for additional considerations on manual keying.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24
bits)" registry as described in <a href="#section-2.1">Section 2.1</a>.
IANA has created the "OSPFv3 Authentication Trailer Options"
registry. This new registry initially includes the "OSPFv3
Authentication Types" registry, which defines valid values for the
Authentication Type field in the OSPFv3 Authentication Trailer. The
registration procedure is Standards Action.
+-------------+-----------------------------------+
| Value/Range | Designation |
+-------------+-----------------------------------+
| 0 | Reserved |
| | |
| 1 | HMAC Cryptographic Authentication |
| | |
| 2-65535 | Unassigned |
+-------------+-----------------------------------+
OSPFv3 Authentication Types
<span class="grey">Bhatia, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
Finally, IANA has created the "Keying and Authentication for Routing
Protocols (KARP) Parameters" category. This new category initially
includes the "Authentication Cryptographic Protocol ID" registry,
which provides unique protocol-specific values for cryptographic
applications, such as but not limited to, prevention of cross-
protocol replay attacks. Values can be assigned for both native
IPv4/IPv6 protocols and UDP/TCP protocols. The registration
procedure is Standards Action.
+-------------+----------------------+
| Value/Range | Designation |
+-------------+----------------------+
| 0 | Reserved |
| | |
| 1 | OSPFv3 |
| | |
| 2-65535 | Unassigned |
+-------------+----------------------+
Cryptographic Protocol ID
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.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-RFC2328">RFC2328</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>,
April 1998.
[<a id="ref-RFC5340">RFC5340</a>] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", <a href="./rfc5340">RFC 5340</a>, July 2008.
[<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.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-FIPS-180-3">FIPS-180-3</a>] US National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", FIPS PUB 180-3,
October 2008.
[<a id="ref-FIPS-198-1">FIPS-198-1</a>] US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS
PUB 198, July 2008.
<span class="grey">Bhatia, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
[<a id="ref-MANUAL-KEY">MANUAL-KEY</a>] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,
"Security Extension for OSPFv2 when using Manual Key
Management", Work in Progress, October 2011.
[<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 id="ref-RFC4302">RFC4302</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>,
December 2005.
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC4552">RFC4552</a>] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", <a href="./rfc4552">RFC 4552</a>, June 2006.
[<a id="ref-RFC5613">RFC5613</a>] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", <a href="./rfc5613">RFC 5613</a>,
August 2009.
[<a id="ref-RFC5996">RFC5996</a>] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
<a href="./rfc5996">RFC 5996</a>, September 2010.
[<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 id="ref-RFC6234">RFC6234</a>] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", <a href="./rfc6234">RFC 6234</a>, May 2011.
<span class="grey">Bhatia, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Acknowledgments</span>
First and foremost, thanks to the authors of <a href="./rfc5709">RFC 5709</a> [<a href="./rfc5709" title=""OSPFv2 HMAC-SHA Cryptographic Authentication"">RFC5709</a>], from
which this work was derived.
Thanks to Sam Hartman for discussions on replay mitigation and the
use of a 64-bit strictly increasing sequence number. Also, thanks to
Sam for comments during IETF last call with respect to the OSPFv3 SA
and sharing of key between protocols.
Thanks to Michael Barnes for numerous comments and strong input on
the coverage of LLS by the Authentication Trailer (AT).
Thanks to Rajesh Shetty for numerous comments, including the
suggestion to include an Authentication Type field in the
Authentication Trailer for extendibility.
Thanks to Uma Chunduri for suggesting that we may want to protect the
IPv6 source address even though OSPFv3 uses the Router ID for
neighbor identification.
Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan
Ratliff, and Glen Kent for their support and review comments.
Thanks to Alia Atlas for comments made under the purview of the
Routing Directorate review.
Thanks to Stephen Farrell for comments during the IESG review.
Stephen was also involved in the discussion of cross-protocol
attacks.
<span class="grey">Bhatia, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6506">RFC 6506</a> Authentication Trailer for OSPFv3 February 2012</span>
Authors' Addresses
Manav Bhatia
Alcatel-Lucent
Bangalore
India
EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral
Hewlett Packard
USA
EMail: vishwas.manral@hp.com
Acee Lindem
Ericsson
102 Carric Bend Court
Cary, NC 27519
USA
EMail: acee.lindem@ericsson.com
Bhatia, et al. Standards Track [Page 20]
</pre>
|
