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
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
|
<pre>Internet Engineering Task Force (IETF) W. Atwood
Request for Comments: 5796 Concordia University/CSE
Updates: <a href="./rfc4601">4601</a> S. Islam
Category: Standards Track IRS-EMT
ISSN: 2070-1721 M. Siami
Concordia University/CIISE
March 2010
<span class="h1">Authentication and Confidentiality in</span>
Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages
Abstract
<a href="./rfc4601">RFC 4601</a> mandates the use of IPsec to ensure authentication of the
link-local messages in the Protocol Independent Multicast - Sparse
Mode (PIM-SM) routing protocol. This document specifies mechanisms
to authenticate the PIM-SM link-local messages using the IP security
(IPsec) Encapsulating Security Payload (ESP) or (optionally) the
Authentication Header (AH). It specifies optional mechanisms to
provide confidentiality using the ESP. Manual keying is specified as
the mandatory and default group key management solution. To deal
with issues of scalability and security that exist with manual
keying, optional support for an automated group key management
mechanism is provided. However, the procedures for implementing
automated group key management are left to other documents. This
document updates <a href="./rfc4601">RFC 4601</a>.
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/rfc5796">http://www.rfc-editor.org/info/rfc5796</a>.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
Copyright Notice
Copyright (c) 2010 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.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Goals and Non-Goals ........................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. Transport Mode versus Tunnel Mode ...............................<a href="#page-5">5</a>
<a href="#section-4">4</a>. Authentication ..................................................<a href="#page-5">5</a>
<a href="#section-5">5</a>. Confidentiality .................................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. IPsec Requirements ..............................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. Key Management ..................................................<a href="#page-8">8</a>
<a href="#section-7.1">7.1</a>. Manual Key Management ......................................<a href="#page-8">8</a>
<a href="#section-7.2">7.2</a>. Automated Key Management ...................................<a href="#page-8">8</a>
<a href="#section-7.3">7.3</a>. Communications Patterns ....................................<a href="#page-9">9</a>
<a href="#section-7.4">7.4</a>. Neighbor Relationships ....................................<a href="#page-10">10</a>
<a href="#section-8">8</a>. Number of Security Associations ................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. Rekeying .......................................................<a href="#page-12">12</a>
<a href="#section-9.1">9.1</a>. Manual Rekeying Procedure .................................<a href="#page-13">13</a>
<a href="#section-9.2">9.2</a>. KeyRolloverInterval .......................................<a href="#page-14">14</a>
<a href="#section-9.3">9.3</a>. Rekeying Interval .........................................<a href="#page-14">14</a>
<a href="#section-10">10</a>. IPsec Protection Barrier and SPD/GSPD .........................<a href="#page-14">14</a>
<a href="#section-10.1">10.1</a>. Manual Keying ............................................<a href="#page-14">14</a>
<a href="#section-10.1.1">10.1.1</a>. SAD Entries .......................................<a href="#page-14">14</a>
<a href="#section-10.1.2">10.1.2</a>. SPD Entries .......................................<a href="#page-14">14</a>
<a href="#section-10.2">10.2</a>. Automatic Keying .........................................<a href="#page-15">15</a>
<a href="#section-10.2.1">10.2.1</a>. SAD Entries .......................................<a href="#page-15">15</a>
<a href="#section-10.2.2">10.2.2</a>. GSPD Entries ......................................<a href="#page-15">15</a>
<a href="#section-10.2.3">10.2.3</a>. PAD Entries .......................................<a href="#page-15">15</a>
<a href="#section-11">11</a>. Security Association Lookup ...................................<a href="#page-16">16</a>
<a href="#section-12">12</a>. Activating the Anti-Replay Mechanism ..........................<a href="#page-16">16</a>
<a href="#section-13">13</a>. Implementing a Security Policy Database per Interface .........<a href="#page-17">17</a>
<a href="#section-14">14</a>. Extended Sequence Number ......................................<a href="#page-17">17</a>
<a href="#section-15">15</a>. Security Considerations .......................................<a href="#page-18">18</a>
<a href="#section-16">16</a>. Acknowledgements ..............................................<a href="#page-18">18</a>
<a href="#section-17">17</a>. References ....................................................<a href="#page-19">19</a>
<a href="#section-17.1">17.1</a>. Normative References .....................................<a href="#page-19">19</a>
<a href="#section-17.2">17.2</a>. Informative References ...................................<a href="#page-19">19</a>
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
All the PIM-SM [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>] control messages have IP protocol number
103. Some control messages are unicast; the rest are multicast with
Time to Live (TTL) = 1. The source address used for unicast messages
is a domain-wide reachable address. For the multicast messages, a
link-local address of the interface on which the message is being
sent is used as the source address and a special multicast address,
ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as
the destination address. These messages are called link-local
messages. Hello, Join/Prune, and Assert messages are included in
this category. A forged link-local message may be sent to the
ALL_PIM_ROUTERS multicast address by an attacker. This type of
message affects the construction of the distribution tree [<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>].
The effects of these forged messages are outlined in <a href="./rfc4601#section-6.1">Section 6.1 of
[RFC4601]</a>. Some of the effects are very severe, whereas some are
minor.
PIM-SM version 2 was originally specified in <a href="./rfc2117">RFC 2117</a> [<a href="./rfc2117" title=""Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification"">RFC2117</a>], and
revised in <a href="./rfc2362">RFC 2362</a> [<a href="./rfc2362" title=""Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification"">RFC2362</a>] and <a href="./rfc4601">RFC 4601</a>. <a href="./rfc4601">RFC 4601</a> obsoletes <a href="./rfc2362">RFC</a>
<a href="./rfc2362">2362</a>, and corrects a number of deficiencies. The "Security
Considerations" section of <a href="./rfc4601">RFC 4601</a> is based primarily on the
Authentication Header (AH) specification described in <a href="./rfc4302">RFC 4302</a>
[<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>].
Securing the unicast messages can be achieved by the use of a normal
unicast IPsec Security Association (SA) between the two communicants.
This document focuses on the security issues for link-local messages.
It provides some guidelines to take advantage of the new permitted AH
functionality in <a href="./rfc4302">RFC 4302</a> and the new permitted ESP functionality in
<a href="./rfc4303">RFC 4303</a> [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>], and to bring the PIM-SM specification into
alignment with the new AH and ESP specifications. In particular, in
accordance with <a href="./rfc4301">RFC 4301</a>, the use of ESP is made mandatory and AH is
specified as optional. This document specifies manual key management
as mandatory to implement, i.e., that all implementations MUST
support, and provides the necessary structure for an automated key
management protocol that the PIM routers may use.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Goals and Non-Goals</span>
The primary goal for link-local security is to provide data origin
authentication for each link-local message. A secondary goal is to
ensure that communication only happens between legitimate peers
(i.e., adjacent routers). An optional goal is to provide data
confidentiality for the link-local messages.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
The first goal implies that each router has a unique identity. It is
possible (but not mandatory) that this identity will be based on the
unicast identity of the router. (The unicast identity could be, for
example, based on some individually configured property of the
router, or be part of a region-wide public key infrastructure.) The
existence of this unique identity is assumed in this specification,
but procedures for establishing it are out of scope for this
document.
The second goal implies that there is some form of "adjacency matrix"
that controls the establishment of Security Associations among
adjacent multicast routers. For manual keying, this control will be
exercised by the Administrator of the router(s), through the setting
of initialization parameters. For automated keying, the existence of
this control will be reflected by the contents of the Peer
Authorization Database (PAD) (see <a href="./rfc4301">RFC 4301</a> [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>]) or the Group
Security Policy Database (GSPD) (see <a href="./rfc5374">RFC 5374</a> [<a href="./rfc5374" title=""Multicast Extensions to the Security Architecture for the Internet Protocol"">RFC5374</a>]) in each
router. Procedures for controlling the adjacency and building the
associated PAD and GSPD are out of scope for this document.
<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", "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>].
They indicate requirement levels for compliant PIM-SM
implementations.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Transport Mode versus Tunnel Mode</span>
All implementations conforming to this specification MUST support SA
in transport mode to provide required IPsec security to PIM-SM link-
local messages. They MAY also support SA in tunnel mode to provide
required IPsec security to PIM-SM link-local messages. If tunnel
mode is used, both destination address preservation and source
address preservation MUST be used, as described in Section 3.1 of <a href="./rfc5374">RFC</a>
<a href="./rfc5374">5374</a> [<a href="./rfc5374" title=""Multicast Extensions to the Security Architecture for the Internet Protocol"">RFC5374</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Authentication</span>
Implementations conforming to this specification MUST support
authentication for PIM-SM link-local messages. Implementations
conforming to this specification MUST support HMAC-SHA1 [<a href="./rfc2404" title=""The Use of HMAC-SHA-1-96 within ESP and AH"">RFC2404</a>].
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
In order to provide authentication of PIM-SM link-local messages,
implementations MUST support ESP [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] and MAY support AH
[<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>].
If ESP in transport mode is used, it will only provide authentication
to PIM-SM protocol packets excluding the IP header, extension
headers, and options.
If AH in transport mode is used, it will provide authentication to
PIM-SM protocol packets, selected portions of the IP header,
extension headers and options.
Note: when authentication for PIM-SM link-local messages is enabled,
o PIM-SM link-local packets that are not protected with AH or ESP
will be silently discarded by IPsec, although the implementation
of IPsec may maintain a counter of such packets.
o PIM-SM link-local packets that fail the authentication checks will
be silently discarded by IPsec, although the implementation of
IPsec may maintain a counter of such packets.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Confidentiality</span>
Implementations conforming to this specification SHOULD support
confidentiality for PIM-SM. Implementations supporting
confidentiality MUST support AES-CBC [<a href="./rfc3602" title=""The AES-CBC Cipher Algorithm and Its Use with IPsec"">RFC3602</a>] with a 128-bit key.
If confidentiality is provided, ESP MUST be used.
Since authentication MUST be supported by a conforming
implementation, an implementation MUST NOT generate the combination
of NON-NULL Encryption and NULL Authentication.
Note: when confidentiality for PIM-SM link-local packets is enabled,
o PIM-SM packets that are not protected with ESP will be silently
discarded by IPsec, although the implementation of IPsec may
maintain a counter of such packets.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IPsec Requirements</span>
In order to implement this specification, the following IPsec
capabilities are required.
Transport mode
IPsec in transport mode MUST be supported.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
Multiple Security Policy Databases (SPDs)
The implementation MUST support multiple SPDs with an SPD
selection function that provides an ability to choose a specific
SPD based on interface.
Selectors
The implementation MUST be able to use source address, destination
address, protocol, and direction as selectors in the SPD.
Interface ID tagging
The implementation MUST be able to tag the inbound packets with
the ID of the interface (physical or virtual) on which they
arrived.
Manual key support
It MUST be possible to use manually configured keys to secure the
specified traffic.
Encryption and authentication algorithms
Encryption and authentication algorithm requirements described in
<a href="./rfc4835">RFC 4835</a> [<a href="./rfc4835" title=""Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)"">RFC4835</a>] apply when ESP and AH are used to protect
PIM-SM. Implementations MUST support ESP-NULL, and if providing
confidentiality, MUST support the ESP transforms providing
confidentiality required by [<a href="./rfc4835" title=""Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)"">RFC4835</a>]. However, in any case,
implementations MUST NOT allow the user to choose a stream cipher
or block mode cipher in counter mode for use with manual keys.
Encapsulation of ESP packets
IP encapsulation of ESP packets MUST be supported. For
simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
If the automatic keying features of this specification are
implemented, the following additional IPsec capabilities are
required:
Group Security Policy Database (GSPD)
The implementation MUST support the GSPD that is described in <a href="./rfc5374">RFC</a>
<a href="./rfc5374">5374</a> [<a href="./rfc5374" title=""Multicast Extensions to the Security Architecture for the Internet Protocol"">RFC5374</a>].
Multiple Group Security Policy Databases
The implementation MUST support multiple GSPDs with a GSPD
selection function that provides an ability to choose a specific
GSPD based on interface.
Selectors
The implementation MUST be able to use source address, destination
address, protocol and direction as selectors in the GSPD.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Key Management</span>
All the implementations MUST support manual configuration of the
Security Associations (SAs) that will be used to authenticate PIM-SM
link-local messages. This does not preclude the use of a negotiation
protocol such as the Group Domain Of Interpretation (GDOI) [<a href="./rfc3547" title=""The Group Domain of Interpretation"">RFC3547</a>]
or Group Secure Association Key Management Protocol (GSAKMP)
[<a href="./rfc4535" title=""GSAKMP: Group Secure Association Key Management Protocol"">RFC4535</a>] to establish these SAs.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Manual Key Management</span>
To establish the SAs at PIM-SM routers, manual key configuration will
be feasible when the number of peers (directly connected routers) is
small. The Network Administrator will configure a router manually.
At that time, the authentication method and the choice of keys SHOULD
be configured. The parameters for the Security Association Database
(SAD) will be entered. The Network Administrator will also configure
the Security Policy Database of a router to ensure the use of the
associated SA while sending a link-local message.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Automated Key Management</span>
All the link-local messages of the PIM-SM protocol are sent to the
destination address, ALL_PIM_ROUTERS, which is a multicast address.
By using the sender address in conjunction with the destination
address for Security Association lookup, link-local communication
turns into a Source-Specific Multicast (SSM) or "one-to-many"
communication.
The procedures for automated key management are not specified in this
document.
One option is to use Group Domain Of Interpretation (GDOI) [<a href="./rfc3547" title=""The Group Domain of Interpretation"">RFC3547</a>],
which enables a group of users or devices to exchange encrypted data
using IPsec data encryption. GDOI has been developed to be used in
multicast applications, where the number of end users or devices may
be large and the end users or devices can dynamically join/leave a
multicast group. However, a PIM router is not expected to join/leave
very frequently, and the number of routers is small when compared to
the possible number of users of a multicast application. Moreover,
most of the PIM routers will be located inside the same
administrative domain and are considered to be trusted parties. It
is possible that a subset of GDOI functionalities will be sufficient.
Another option is to use the Group Secure Association Key Management
Protocol (GSAKMP) [<a href="./rfc4535" title=""GSAKMP: Group Secure Association Key Management Protocol"">RFC4535</a>].
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Communications Patterns</span>
Before discussing the set of Security Associations that are required
to properly manage a multicast region that is under the control of a
single administration, it is necessary to understand the
communications patterns that will exist among the routers in this
region. From the perspective of a speaking router, the information
from that router is sent (multicast) to all of its neighbors. From
the perspective of a listening router, the information coming from
each of its neighbors is distinct from the information coming from
every other router to which it is directly connected. Thus, an
administrative region contains many (small) distinct groups, all of
which happen to be using the same multicast destination address
(e.g., ALL_PIM_ROUTERS, see <a href="#section-11">Section 11</a>), and each of which is
centered on the associated speaking router.
Consider the example configuration as shown in Figure 1.
R2 R3 R4 R5 R6
| | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
Figure 1: Set of router interconnections
In this configuration, router R1 has four interfaces, and is the
speaking router for a group whose listening routers are routers R2
through R11. Router R9 is the speaking router for a group whose
listening routers are routers R1, R8, and R10-R14.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
From the perspective of R1 as a speaking router, if a Security
Association SA1 is assigned to protect outgoing packets from R1, then
it is necessary to distribute the key for this association to each of
the routers R2 through R11. Similarly, from the perspective of R9 as
a speaking router, if a Security Association is assigned to protect
the outgoing packets from R9, then it is necessary to distribute the
key for this association to each of the routers R1, R8, and R10
through R14.
From the perspective of R1 as a listening router, all packets
arriving from R2 through R11 need to be distinguished from each
other, to permit selecting the correct Security Association in the
SAD. (Packets from each of the peer routers (R2 through R11)
represent communication from a different speaker, with a separate
sequence-number space, even though they are sent using the same
destination address.) For a multicast Security Association, <a href="./rfc4301">RFC 4301</a>
permits using the source address in the selection function. If the
source addresses used by routers R2 through R11 are globally unique,
then the source addresses of the peer routers are sufficient to
achieve the differentiation. If the sending routers use link-local
addresses, then these addresses are unique only on a per-interface
basis, and it is necessary to use the Interface ID tag as an
additional selector, i.e., either the selection function has to have
the Interface ID tag as one of its inputs or separate SADs have to be
maintained for each interface.
If the assumption of connectivity to the key server can be made
(which is true in the PIM-SM case), then the Group Controller/Key
Server (GC/KS) that is used for the management of the keys can be
centrally located (and duplicated for reliability). If this
assumption cannot be made (i.e., in the case of adjacencies for a
unicast router), then some form of "local" key server must be
available for each group. Given that the listening routers are never
more than one hop away from the speaking router, the speaking router
is the obvious place to locate the "local" key server. As such, this
may be a useful approach even in the PIM-SM case. This approach has
the additional advantage that there is no need to duplicate the local
key server for reliability, since if the key server is down, it is
very likely that the speaking router is also down.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Neighbor Relationships</span>
Each distinct group consists of one speaker, and the set of directly
connected listeners. If the decision is made to maintain one
Security Association per speaker (see <a href="#section-8">Section 8</a>), then the key server
will need to be aware of the adjacencies of each speaker. Procedures
for managing and distributing these adjacencies are out of scope for
this document.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Number of Security Associations</span>
The number of Security Associations to be maintained by a PIM router
depends on the required security level and available key management.
This SHOULD be decided by the Network Administrator. Two different
ways are shown in Figures 2 and 3. It is assumed that A, B, and C
are three PIM routers, where B and C are directly connected with A,
and there is no direct link between B and C.
|
+++++ |
+ B + SAb ------------>|
+ + SAa <------------|
+++++ |
|
+++++ SAb <------------|
+ + ---->|
+ + /
+ A + SAa -------
+ + \
+ + ---->|
+++++ SAc <------------|
|
+++++ |
+ C + SAc ------------>|
+ + SAa <------------|
+++++ |
|
Directly connected network
Figure 2: Activate unique Security Association for each peer
The first method, shown in Figure 2, SHOULD be supported by every
implementation. In this method, each node will use a unique SA for
its outbound traffic. A, B, and C will use SAa, SAb, and SAc,
respectively, for sending any traffic. Each node will include the
source address when searching the SAD for a match. Router A will use
SAb and SAc for packets received from B and C, respectively. The
number of SAs to be activated and maintained by a PIM router will be
equal to the number of directly connected routers, plus one for
sending its own traffic. Also, the addition of a PIM router in the
network will require the addition of another SA on every directly
connected PIM router. This solution will be scalable and practically
feasible with an automated key management protocol. However, it MAY
be used with manual key management, if the number of directly
connected routers is small.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
|
+++++ |
+ B + SAo ------------>|
+ + SAi <------------|
+++++ |
|
+++++ SAi <------------|
+ + ---->|
+ + /
+ A + SAo -------
+ + \
+ + ---->|
+++++ SAi <------------|
|
+++++ |
+ C + SAo ------------>|
+ + SAi <------------|
+++++ |
|
Directly connected network
Figure 3: Activate two Security Associations
The second method, shown in Figure 3, MUST be supported by every
implementation. In this simple method, all the nodes will use two
SAs, one for sending (SAo) and the other for receiving (SAi) traffic.
Thus, the number of SAs is always two and will not be affected by
addition of a PIM router. Although two different SAs (i.e., SAo and
SAi) are used in this method, the SA parameters (keys, Security
Parameter Index (SPI), etc.) for the two SAs are identical, i.e., the
same information is shared among all the routers in an administrative
region. This document RECOMMENDS this second method for manual key
configuration. However, it MAY also be used with automated key
configuration.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Rekeying</span>
An analysis of the considerations for key management is provided in
<a href="./rfc4107">RFC 4107</a> [<a href="./rfc4107" title=""Guidelines for Cryptographic Key Management"">RFC4107</a>].
In PIM-SM deployments it is expected that secure sessions will be
relatively long-lived, and it is not expected that keys will be
significantly exposed through normal operational activity. Manual
keying is judged acceptable in the light of the relatively low rate
of change that is required.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
To maintain the security of a link, the authentication and encryption
key values SHOULD be changed periodically, to limit the risk of
undetected key disclosure. Keys SHOULD also be changed when there is
a change of trusted personnel.
Manual keying offers the ability to change keys in a coordinated way,
but it has several drawbacks in PIM-SM systems. Some of these are
listed in <a href="#section-15">Section 15</a> ("Security Considerations") of this document.
According to an analysis in line with <a href="./rfc4107">RFC 4107</a> [<a href="./rfc4107" title=""Guidelines for Cryptographic Key Management"">RFC4107</a>], PIM-SM
would benefit from automated key management and roll over because all
the disadvantages of manual keys listed in <a href="#section-15">Section 15</a> would be
eliminated. However, suitable techniques for automated key
management do not currently exist. Work is in hand in the IETF to
develop suitable solutions. In the meantime, implementations MUST
support manual rekeying as described below. Implementers and
deployers need to be aware of the requirement to upgrade to support
automated key management as soon as suitable techniques are
available.
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Manual Rekeying Procedure</span>
In accordance with the requirements of <a href="./rfc4107">RFC 4107</a> [<a href="./rfc4107" title=""Guidelines for Cryptographic Key Management"">RFC4107</a>], the
following three-step procedure provides a possible mechanism to rekey
the routers on a link without dropping PIM-SM protocol packets or
disrupting the adjacency, while ensuring that it is always clear
which key is being used.
1. For every router on the link, create an additional inbound SA for
the interface being rekeyed using a new SPI and the new key.
2. For every router on the link, replace the original outbound SA
with one using the new SPI and key values. The SA replacement
operation MUST be atomic with respect to sending PIM-SM packets
on the link, so that no PIM-SM packets are sent without
authentication/encryption
3. For every router on the link, remove the original inbound SA.
Note that all routers on the link MUST complete step 1 before any
begin step 2. Likewise, all the routers on the link MUST complete
step 2 before any begin step 3.
One way to control the progression from one step to another is for
each router to have a configurable time constant KeyRolloverInterval.
After the router begins step 1 on a given link, it waits for this
interval and then moves to step 2. Likewise, after moving to step 2,
it waits for this interval and then moves to step 3.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
In order to achieve smooth key transition, all routers on a link MUST
use the same value for KeyRolloverInterval and MUST initiate the key
rollover process within this time period.
At the end of this time period, all the routers on the link will have
a single inbound and outbound SA for PIM-SM with the new SPI and key
values.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. KeyRolloverInterval</span>
The configured value of KeyRolloverInterval needs to be long enough
to allow the Administrator to change keys on all the PIM-SM routers.
As this value can vary significantly depending on the implementation
and the deployment, it is left to the Administrator to choose an
appropriate value.
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Rekeying Interval</span>
In keeping with the goal of reducing key exposure, the encryption and
authentication keys SHOULD be changed at least every 90 days.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IPsec Protection Barrier and SPD/GSPD</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Manual Keying</span>
<span class="h4"><a class="selflink" id="section-10.1.1" href="#section-10.1.1">10.1.1</a>. SAD Entries</span>
The Administrator must configure the necessary Security Associations.
Each SA entry has the source address of an authorized peer, and a
Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the
manually configured SAs MUST be assigned by the Administrator to
ensure that the SPI does not conflict with existing SPI values in the
SAD.
<span class="h4"><a class="selflink" id="section-10.1.2" href="#section-10.1.2">10.1.2</a>. SPD Entries</span>
The Administrator must configure the necessary SPD entries. The SPD
entry must ensure that any outbound IP traffic packet traversing the
IPsec boundary, with PIM as its next layer protocol and sent to the
Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH.
Note that this characterization includes all the link-local messages
(Hello, Join/Prune, Bootstrap, Assert).
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Automatic Keying</span>
When automatic keying is used, the SA creation is done dynamically
using a group key management protocol. The GSPD and PAD tables are
configured by the Administrator. The PAD table provides the link
between the IPsec subsystem and the group key management protocol.
For automatic keying, the implementation MUST support the multicast
extensions described in [<a href="./rfc5374" title=""Multicast Extensions to the Security Architecture for the Internet Protocol"">RFC5374</a>].
<span class="h4"><a class="selflink" id="section-10.2.1" href="#section-10.2.1">10.2.1</a>. SAD Entries</span>
All PIM routers participate in an authentication scheme that
identifies permitted neighbors and achieves peer authentication
during SA negotiation, leading to child SAs being established and
saved in the SAD.
<span class="h4"><a class="selflink" id="section-10.2.2" href="#section-10.2.2">10.2.2</a>. GSPD Entries</span>
The Administrator must configure the necessary GSPD entries for
"sender only" directionality. This rule MUST trigger the group key
management protocol for a registration exchange. This exchange will
set up the outbound SAD entry that encrypts the multicast PIM control
message. Considering that this rule is "sender only", no inbound SA
is created in the reverse direction.
In addition, the registration exchange will trigger the installation
of the GSPD entries corresponding to each legitimate peer router,
with direction "receiver only". Procedures for achieving the
registration exchange are out of scope for this document.
A router SHOULD NOT dynamically detect new neighbors as the result of
receiving an unauthenticated PIM-SM link-local message or an IPsec
packet that fails an SAD lookup. An automated key management
protocol SHOULD provide a means of notifying a router of new,
legitimate neighbors.
<span class="h4"><a class="selflink" id="section-10.2.3" href="#section-10.2.3">10.2.3</a>. PAD Entries</span>
The PAD will be configured with information to permit identification
of legitimate group members and senders (i.e., to control the
adjacency). Procedures for doing this are out of scope for this
document.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Security Association Lookup</span>
For an SA that carries unicast traffic, three parameters (SPI,
destination address, and security protocol type (AH or ESP)) are used
in the Security Association lookup process for inbound packets. The
SPI is sufficient to specify an SA. However, an implementation may
use the SPI in conjunction with the IPsec protocol type (AH or ESP)
for the SA lookup process. According to <a href="./rfc4301">RFC 4301</a> [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>], for
multicast SAs, in conjunction with the SPI, the destination address
or the destination address plus the sender address may also be used
in the SA lookup. This applies to both ESP and AH. The security
protocol field is not employed for a multicast SA lookup.
Given that, from the prospective of a receiving router, each peer
router is an independent sender and given that the destination
address will be the same for all senders, the receiving router MUST
use SPI plus destination address plus sender address when performing
the SA lookup. In effect, link-local communication is an SSM
communication that happens to use an Any-Source Multicast (ASM)
address (which is shared among all the routers).
Given that it is always possible to distinguish a connection using
IPsec from a connection not using IPsec, it is recommended that the
address ALL_PIM_ROUTERS be used, to maintain consistency with present
practice.
Given that the sender address of an incoming packet may be only
locally unique (because of the use of link-local addresses), it is
necessary for a receiver to use the interface ID tag to determine the
associated SA for that sender. Therefore, this document mandates
that the interface ID tag, the SPI, and the sender address MUST be
used in the SA lookup process.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Activating the Anti-Replay Mechanism</span>
Although link-level messages on a link constitute a multiple-sender,
multiple-receiver group, the use of the interface ID tag and sender
address for SA lookup essentially resolves the communication into a
separate SA for each sender/destination pair, even for the case where
only two SAs (with identical SA parameters) are used for the entire
administrative region. Therefore, the statement in the AH RFC
(<a href="./rfc4302#section-2.5">Section 2.5 of [RFC4302]</a>) that "for a multi-sender SA, the anti-
replay features are not available" becomes irrelevant to the PIM-SM
link-local message exchange.
To activate the anti-replay mechanism in a unicast communication, the
receiver uses the sliding window protocol and it maintains a sequence
number for this protocol. This sequence number starts from zero.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
Each time the sender sends a new packet, it increments this number by
one. In a multi-sender multicast group communication, a single
sequence number for the entire group would not be enough.
The whole scenario is different for PIM link-local messages. These
messages are sent to local links with TTL = 1. A link-local message
never propagates through one router to another. The use of the
sender address and the interface ID tag for SA lookup converts the
relationship from a multiple-sender group to multiple single-sender
associations. This specification RECOMMENDS activation of the anti-
replay mechanism only if the SAs are assigned using an automated key
management procedure. If manual key management is used, the anti-
replay SHOULD NOT be activated.
If an existing router has to restart, in accordance with <a href="./rfc4303">RFC 4303</a>
[<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>], the sequence-number counter at the sender MUST be
correctly maintained across local reboots, etc., until the key is
replaced.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Implementing a Security Policy Database per Interface</span>
<a href="./rfc4601">RFC 4601</a> suggests that it may be desirable to implement a separate
Security Policy Database (SPD) for each router interface. The use of
link-local addresses in certain circumstances implies that
differentiation of ambiguous speaker addresses requires the use of
the interface ID tag in the SA lookup. One way to do this is through
the use of multiple SPDs. Alternatively, the interface ID tag may be
a specific component of the selector algorithm. This is in
conformance with <a href="./rfc4301">RFC 4301</a>, which explicitly removes the requirement
for separate SPDs that was present in <a href="./rfc2401">RFC 2401</a> [<a href="./rfc2401" title=""Security Architecture for the Internet Protocol"">RFC2401</a>].
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Extended Sequence Number</span>
In the [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>], there is a provision for a 64-bit Extended Sequence
Number (ESN) as the counter of the sliding window used in the anti-
replay protocol. Both the sender and the receiver maintain a 64-bit
counter for the sequence number, although only the lower order 32
bits are sent in the transmission. In other words, it will not
affect the present header format of AH. If ESN is used, a sender
router can send 2^64 -1 packets without any intervention. This
number is very large, and from a PIM router's point of view, a PIM
router can never exceed this number in its lifetime. This makes it
reasonable to permit manual configuration for a small number of PIM
routers, since the sequence number will never roll over. For this
reason, when manual configuration is used, ESN SHOULD be deployed as
the sequence number for the sliding window protocol. In addition,
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
when an ESN is used with a manually keyed SA, it MUST be saved over a
reboot, along with an indication of which sequence numbers have been
used.
<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>. Security Considerations</span>
The whole document considers the security issues of PIM link-local
messages and proposes a mechanism to protect them.
Limitations of manual keys:
The following are some of the known limitations of the usage of
manual keys.
o If replay protection cannot be provided, the PIM routers will not
be secured against all the attacks that can be performed by
replaying PIM packets.
o Manual keys are usually long lived (changing them often is a
tedious task). This gives an attacker enough time to discover the
keys.
o As the Administrator is manually configuring the keys, there is a
chance that the configured keys are weak (there are known weak
keys for DES/3DES at least).
Impersonation attacks:
The usage of the same key on all the PIM routers connected to a link
leaves them all insecure against impersonation attacks if any one of
the PIM routers is compromised, malfunctioning, or misconfigured.
Detailed analysis of various vulnerabilities of routing protocols is
provided in <a href="./rfc4593">RFC 4593</a> [<a href="./rfc4593" title=""Generic Threats to Routing Protocols"">RFC4593</a>]. For further discussion of PIM-SM and
multicast security, the reader is referred to <a href="./rfc5294">RFC 5294</a> [<a href="./rfc5294" title=""Host Threats to Protocol Independent Multicast (PIM)"">RFC5294</a>], <a href="./rfc4609">RFC</a>
<a href="./rfc4609">4609</a> [<a href="./rfc4609" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements"">RFC4609</a>], and the Security Considerations section of <a href="./rfc4601">RFC 4601</a>
[<a href="./rfc4601" title=""Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)"">RFC4601</a>].
<span class="h2"><a class="selflink" id="section-16" href="#section-16">16</a>. Acknowledgements</span>
The structure and text of this document draw heavily from <a href="./rfc4552">RFC 4552</a>
[<a href="./rfc4552" title=""Authentication/Confidentiality for OSPFv3"">RFC4552</a>]. The authors of this document thank M. Gupta and N. Melam
for permission to do this.
The quality of this document was substantially improved after SECDIR
pre-review by Brian Weis, and after AD review by Adrian Farrel.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
<span class="h2"><a class="selflink" id="section-17" href="#section-17">17</a>. References</span>
<span class="h3"><a class="selflink" id="section-17.1" href="#section-17.1">17.1</a>. Normative References</span>
[<a id="ref-RFC4601">RFC4601</a>] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", <a href="./rfc4601">RFC 4601</a>, August 2006.
[<a id="ref-RFC4302">RFC4302</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>,
December 2005.
[<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-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</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-RFC4835">RFC4835</a>] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", <a href="./rfc4835">RFC 4835</a>, April 2007.
[<a id="ref-RFC5374">RFC5374</a>] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", <a href="./rfc5374">RFC 5374</a>, November 2008.
[<a id="ref-RFC2404">RFC2404</a>] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", <a href="./rfc2404">RFC 2404</a>, November 1998.
[<a id="ref-RFC3602">RFC3602</a>] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", <a href="./rfc3602">RFC 3602</a>,
September 2003.
<span class="h3"><a class="selflink" id="section-17.2" href="#section-17.2">17.2</a>. Informative References</span>
[<a id="ref-RFC2117">RFC2117</a>] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", <a href="./rfc2117">RFC 2117</a>, June 1997.
[<a id="ref-RFC2362">RFC2362</a>] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., and V. Jacobson, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification",
<a href="./rfc2362">RFC 2362</a>, June 1998.
<span class="grey">Atwood, 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="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
[<a id="ref-RFC2401">RFC2401</a>] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.
[<a id="ref-RFC4535">RFC4535</a>] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", <a href="./rfc4535">RFC 4535</a>, June 2006.
[<a id="ref-RFC3547">RFC3547</a>] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", <a href="./rfc3547">RFC 3547</a>, July 2003.
[<a id="ref-RFC4593">RFC4593</a>] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", <a href="./rfc4593">RFC 4593</a>, October 2006.
[<a id="ref-RFC5294">RFC5294</a>] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", <a href="./rfc5294">RFC 5294</a>, August 2008.
[<a id="ref-RFC4609">RFC4609</a>] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", <a href="./rfc4609">RFC 4609</a>,
October 2006.
[<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-RFC4107">RFC4107</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.
<span class="grey">Atwood, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5796">RFC 5796</a> PIM-SM Link-local Security March 2010</span>
Authors' Addresses
J. William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd. West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
EMail: bill@cse.concordia.ca
URI: <a href="http://users.encs.concordia.ca/~bill">http://users.encs.concordia.ca/~bill</a>
Salekul Islam
INRS Energie, Materiaux et Telecommunications
800 de La Gauchetiere, Suite 800
Montreal, QC H5A 1K6
Canada
EMail: Salekul.Islam@emt.inrs.ca
URI: <a href="http://users.encs.concordia.ca/~salek_is">http://users.encs.concordia.ca/~salek_is</a>
Maziar Siami
Concordia University/CIISE
1455 de Maisonneuve Blvd. West
Montreal, QC H3G 1M8
Canada
EMail: mzrsm@yahoo.ca
Atwood, et al. Standards Track [Page 21]
</pre>
|
