idnits 2.17.1 draft-ietf-pim-sm-linklocal-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 713. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4601, but the abstract doesn't seem to directly say this. It does mention RFC4601 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4601, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 5994 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 630, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 633, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (ref. '1') (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 3740 (ref. '6') ** Obsolete normative reference: RFC 4305 (ref. '7') (Obsoleted by RFC 4835) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '8') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '11') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '13') (Obsoleted by RFC 6407) == Outdated reference: A later version (-04) exists of draft-ietf-pim-lasthop-threats-03 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group W. Atwood 3 Internet-Draft S. Islam 4 Updates: 4601 (if approved) Concordia University/CSE 5 Intended status: Standards Track November 18, 2007 6 Expires: May 21, 2008 8 Authentication and Confidentiality in PIM-SM Link-local Messages 9 draft-ietf-pim-sm-linklocal-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 RFC 4601 mandates the use of IPsec to ensure authentication of the 43 link-local messages in the Protocol Independent Multicast - Sparse 44 Mode (PIM-SM) routing protocol. This document specifies mechanisms 45 to authenticate the PIM-SM link local messages using the IP security 46 (IPsec) Authentication Header (AH) or Encapsulating Security Payload 47 (ESP). It specifies optional mechanisms to provide confidentiality 48 using the ESP. Manual keying is specified as the mandatory and 49 default group key management solution. To deal with issues of 50 scalability and security that exist with manual keying, an optional 51 automated group key management mechanism is specified. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 5 58 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 9 63 7.2. Automated Key Management . . . . . . . . . . . . . . . . . 9 64 7.3. Communications Patterns . . . . . . . . . . . . . . . . . 9 65 7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 11 66 8. Number of Security Associations . . . . . . . . . . . . . . . 12 67 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 14 69 9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 14 70 9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 14 71 10. IPsec Protection Barrier and SPD . . . . . . . . . . . . . . . 15 72 11. Security Association Lookup . . . . . . . . . . . . . . . . . 16 73 12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 17 74 13. Implementing a Security Association Database per Interface . . 19 75 14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 20 76 15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 79 16.2. Informative References . . . . . . . . . . . . . . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 81 Intellectual Property and Copyright Statements . . . . . . . . . . 25 83 1. Introduction 85 All the PIM-SM [1] control messages have IP protocol number 103. 86 These messages are either unicast, or multicast with TTL = 1. The 87 source address used for unicast messages is a domain-wide reachable 88 address. For the multicast messages, a link-local address of the 89 interface on which the message is being sent is used as the source 90 address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 91 in IPv4 and ff02::d in IPv6) is used as the destination address. 92 These messages are called link-local messages. Hello, Join/Prune and 93 Assert messages are included in this category. A forged link-local 94 message may be sent to the ALL_PIM_ROUTERS multicast address by an 95 attacker. This type of message affects the construction of the 96 distribution tree [1]. The effects of these forged messages are 97 outlined in section 6.1 of [1]. Some of the effects are very severe, 98 whereas some are minor. 100 PIM-SM version 2 was originally specified in RFC 2117, and revised in 101 RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a 102 number of deficiencies. The Security Considerations section of RFC 103 4601 is based primarily on the new Authentication Header (AH) 104 specification described in RFC 4302 [2]. 106 Securing the unicast messages can be achieved by the use of a normal 107 unicast IPsec Security Association between the two communicants. 108 Securing the user data exchanges is covered in RFC 3740 [6]. This 109 document focuses on the security issues for link-local messages. It 110 provides some guidelines to take advantage of the new permitted AH 111 functionality in RFC 4302, and to bring the PIM-SM specification into 112 alignment with the new AH specification. This document recommends 113 manual key management as mandatory to implement, i.e., that all 114 implementations MUST support, and begins the discussion of an 115 automated key management protocol that the PIM routers can use. 117 2. Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 122 indicate requirement levels for compliant PIM-SM implementations. 124 3. Transport Mode vs. Tunnel Mode 126 The transport mode Security Association (SA) is generally used 127 between two hosts or routers/gateways when they are acting as hosts. 128 The SA must be a tunnel mode SA if either end of the security 129 association is a router/gateway. Two hosts MAY establish a tunnel 130 mode SA between themselves. PIM-SM link-local messages are exchanged 131 between routers. However, since the packets are locally delivered, 132 the routers assume the role of hosts in the context of the tunnel 133 mode SA. All implementations conforming to this specification MUST 134 support transport mode SA to provide required IPsec security to 135 PIM-SM link-local messages. They MAY also support tunnel mode SA to 136 provide required IPsec security to PIM-SM link-local messages. 138 4. Authentication 140 Implementations conforming to this specification MUST support 141 authentication for PIM-SM link-local messages. 143 In order to provide authentication to PIM-SM link-local messages, 144 implementations MUST support ESP [5] and MAY support AH [2]. 146 If ESP in transport mode is used, it will only provide authentication 147 to PIM-SM protocol packets excluding the IPv6 header, extension 148 headers, and options. (Note: The IPv4 exclusions need to be listed 149 here as well.) 151 If AH in transport mode is used, it will provide authentication to 152 PIM-SM protocol packets, selected portions of the IPv6 header, 153 extension headers and options. (Note: the IPv4 coverage needs to be 154 listed here as well.) 156 When authentication for PIM-SM link-local messages is enabled, 158 o PIM-SM link-local packets that are not protected with AH or ESP 159 MUST be silently discarded. 161 o PIM-SM link-local packets that fail the authentication checks MUST 162 be silently discarded. 164 5. Confidentiality 166 Implementations conforming to this specification SHOULD support 167 confidentiality for PIM-SM. 169 If confidentiality is provided, ESP MUST be used. 171 When PIM-SM confidentiality is enabled, 173 o PIM-SM packets that are not protected with ESP MUST be silently 174 discarded. 176 o PIM-SM packets that fail the confidentiality checks MUST be 177 silently discarded. 179 6. IPsec Requirements 181 In order to implement this specification, the following IPsec 182 capabilities are required. 184 Transport mode 185 IPsec in transport mode MUST be supported. 187 Multiple Security Policy Databases (SPDs) 188 The implementation MUST support multiple SPDs with an SPD 189 selection function that provides an ability to choose a specific 190 SPD based on interface. 192 Selectors 193 The implementation MUST be able to use source address, destination 194 address, protocol, and direction as selectors in the SPD. 196 Interface ID tagging 197 The implementation MUST be able to tag the inbound packets with 198 the ID of the interface (physical or virtual) via which it 199 arrived. 201 Manual key support 202 Manually configured keys MUST be able to secure the specified 203 traffic. 205 Encryption and authentication algorithms 206 The implementation MUST NOT allow the user to choose stream 207 ciphers as the encryption algorithm for securing PIM-SM packets 208 since the stream ciphers are not suitable for manual keys. Except 209 when in conflict with the above statement, the key words "MUST", 210 "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in 211 RFC 4305 [7] for algorithms to be supported are to be interpreted 212 as described in RFC 2119 [3] for PIM-SM support as well. 214 Encapsulation of ESP packet 215 IP encapsulation of ESP packets MUST be supported. For 216 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 218 7. Key Management 220 All the implementations MUST support manual configuration of the SAs 221 that will be used to authenticate PIM-SM link-local messages. This 222 does not preclude the use of a negotiation protocol such as the 223 Internet Key Exchange (IKE) [11] or Group Secure Association Key 224 Management Protocol (GSAKMP) [12] to establish SAs. 226 7.1. Manual Key Management 228 To establish the SAs at PIM-SM routers, manual key configuration will 229 be feasible when the number of peers (directly connected routers) is 230 small. The Network Administrator will configure a router manually 231 during its boot up process. At that time, the authentication method 232 and the choice of keys SHOULD be configured. The SAD entry will be 233 created. The Network Administrator will also configure the Security 234 Policy Database of a router to ensure the use of the associated SA 235 while sending a link-local message. 237 7.2. Automated Key Management 239 All the link-local messages of the PIM-SM protocol are sent to the 240 destination address, ALL_PIM_ROUTERS, which is a multicast address. 241 By using the sender address in conjunction with the destination 242 address for Security Association lookup, link-local communication 243 turns to an SSM or "one to many" communication. Since IKE is based 244 on the Diffie-Hellman key agreement protocol and works only for two 245 communicating parties, it is not possible to use IKE for providing 246 the required "one to many" authentication. 248 One option is to use Group Domain Of Interpretation (GDOI) [13], 249 which enables a group of users or devices to exchange encrypted data 250 using IPsec data encryption. GDOI has been developed to be used in 251 multicast applications, where the number of end users or devices may 252 be large and the end users or devices can dynamically join/leave a 253 multicast group. However, a PIM router is not expected to join/leave 254 very frequently, and the number of routers is small when compared to 255 the possible number of users of a multicast application. Moreover, 256 most of the PIM routers will be located inside the same 257 administrative domain and are considered as trusted parties. It is 258 possible that a subset of GDOI functionalities will be sufficient. 260 7.3. Communications Patterns 262 Before discussing the set of security associations that are required 263 to properly manage a multicast region that is under the control of a 264 single administration, it is necessary to understand the 265 communications patterns that will exist among the routers in this 266 region. From the perspective of a speaking router, the information 267 from that router is sent (multicast) to all of its neighbors. From 268 the perspective of a listening router, the information coming from 269 each of its neighbors is distinct from the information coming from 270 every other router to which it is directly connected. Thus an 271 administrative region contains many (small) distinct groups, all of 272 which happen to be using the same multicast destination address 273 (e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is 274 centered on the associated speaking router. 276 Consider the example configuration as shown in Figure 1. 278 R2 R3 R4 R5 R6 279 | | | | | 280 | | | | | 281 --------- --------------- 282 | | 283 | | 284 \ / 285 R1 286 / \ 287 | | 288 | | 289 --------- -------------------- 290 | | | | | 291 | | | | | 292 R7 R8 R9 R10 R11 293 | | | | | 294 | 295 | 296 ------------- 297 | | | 298 | | | 299 R12 R13 R14 301 Figure 1: Set of router interconnections 303 In this configuration, router R1 has four interfaces, and is the 304 speaking router for a group whose listening routers are routers R2 305 through R11. Router R9 is the speaking router for a group whose 306 listening routers are routers R1, R8 and R10-R14. 308 From the perspective of R1 as a speaking router, if a Security 309 Association SA1 is assigned to protect outgoing packets from R1, then 310 it is necessary to distribute the key for this association to each of 311 the routers R2 through R11. Similarly, from the perspective of R9 as 312 a speaking router, if a Security Association is assigned to protect 313 the outgoing packets from R9, then it is necessary to distribute the 314 key for this association to each of the routers R1, R8, and R10 315 through R14. 317 From the perspective of R1 as a listening router, all packets 318 arriving from R2 through R11 need to be distinguished from each 319 other, to permit selecting the correct Security Association in the 320 SAD. (Packets from each of the peer routers (R2 through R11) 321 represent communication from a different speaker, even though they 322 are sent using the same destination address.) For a multicast 323 Security Association, RFC 4301 permits using the Source Address in 324 the selection function. If the source addresses used by routers R2 325 through R11 are globally unique, then the source addresses of the 326 peer routers are sufficient to achieve the differentiation. If the 327 sending routers use link-local addresses, then these addresses are 328 unique only on a per-interface basis, and it is necessary to use the 329 Interface ID tag as an additional selector, i.e., either the 330 selection function has to have the Interface ID tag as one of its 331 inputs, or separate SADs have to be maintained for each interface. 333 If the assumption of connectivity to the key server can be made 334 (which is true in the PIM-SM case), then the GC/KS can be centrally 335 located (and duplicated for reliability). If this assumption cannot 336 be made (i.e., in the case of adjacencies for a unicast router), then 337 some form of "local" key server must be available for each group. 338 Given that the listening routers are never more than one hop away 339 from the speaking router, the speaking router is the obvious place to 340 locate the "local" key server. This has the additional advantage 341 that there is no need to duplicate the local key server for 342 reliability, since if the key server is down, it is very likely that 343 the speaking router is also down. 345 7.4. Neighbor Relationships 347 Each distinct group consists of one speaker, and the set of directly 348 connected listeners. If the decision is made to maintain one 349 Security Association per speaker (see Section 8), then the key server 350 will need to be aware of the adjacencies of each speaker. Procedures 351 for doing this are under study. 353 8. Number of Security Associations 355 The number of Security Associations to be maintained by a PIM router 356 depends on the required security level and available key management. 357 This SHOULD be decided by the Network Administrator. Two different 358 ways are shown in Figure 2 and 3. It is assumed that A, B and C are 359 three PIM routers, where B and C are directly connected with A, and 360 there is no direct link between B and C. 362 | 363 B | 364 SAb ------------>| 365 SAa <------------| 366 | 367 A | 368 SAb <------------| 369 SAa ------------>| 370 SAc <------------| 371 | 372 C | 373 SAc ------------>| 374 SAa <------------| 375 | 376 Directly connected network 378 Figure 2: Activate unique Security Association for each peer 380 The first method, shown in Figure 2 is OPTIONAL to implement. In 381 this method, each node will use a unique SA for its outbound traffic. 382 A, B, and C will use SAa, SAb, and SAc, respectively for sending any 383 traffic. Each node will look up the SA to be used based on the 384 source address. A will use SAb and SAc for packets received from B 385 and C, respectively. The number of SAs to be activated and 386 maintained by a PIM router will be equal to the number of directly 387 connected routers plus one, for sending its own traffic. Also, the 388 addition of a PIM router in the network will require the addition of 389 another SA on every directly connected PIM router. This solution 390 will be scalable and practically feasible with an automated key 391 management protocol. However, it MAY be used with manual key 392 management, if the number of directly connected router(s) is small. 394 B | 395 SAo ------------>| 396 SAi <------------| 397 | 398 A | 399 SAo ------------>| 400 SAi <------------| 401 | 402 C | 403 SAo ------------>| 404 SAi <------------| 405 | 406 Directly connected network 408 Figure 3: Activate two Security Associations 410 The second method, shown in Figure 3, MUST be supported by every 411 implementation. In this simple method, all the nodes will use two 412 SAs, one for sending (SAo) and the other for receiving (SAi) traffic. 413 Thus, the number of SAs is always two and will not be affected by 414 addition of a PIM router. Although two different SAs are used in 415 this method, the encryption key for the two SAs is identical, i.e., 416 it is a single key shared among all the routers in an administrative 417 region. This document RECOMMENDS the above method for manual key 418 configuration. However, it MAY also be used with automated key 419 configuration. When manually configured, the method suffers from 420 impersonation attacks as mentioned in the Security Considerations 421 section. 423 9. Rekeying 425 This section will provide the rekeying rules. It will be written 426 once is is decided whether or not to specify a re-keying protocol as 427 part of this document. 429 9.1. Rekeying Procedure 431 TBD 433 9.2. KeyRollover Interval 435 TBD 437 9.3. Rekeying Interval 439 TBD 441 10. IPsec Protection Barrier and SPD 443 This section will provide the SPD selection function rules. It will 444 be written once it is decided whether to retain both confidentiality 445 and authentication, or to limit the recommendation to authentication. 447 11. Security Association Lookup 449 For an SA that carries unicast traffic, three parameters (SPI, 450 destination address and security protocol type (AH or ESP)) are used 451 in the Security Association lookup process for inbound packets. The 452 SPI is sufficient to specify an SA. However, an implementation may 453 use the SPI in conjunction with the IPsec protocol type (AH or ESP) 454 for the SA lookup process. According to RFC 4301 [4] and the AH 455 specification [2], for multicast SAs, in conjunction with the SPI, 456 the destination address or the destination address plus the sender 457 address may also be used in the SA lookup. The security protocol 458 field is not employed for a multicast SA lookup. 460 The reason for the various prohibitions in the IPsec RFCs concerning 461 multisender multicast SAs lies in the difficulty of coordinating the 462 multiple senders. However, if the use of multicast for link-local 463 messages is examined, it may be seen that in fact the communication 464 need not be coordinated---from the prospective of a receiving router, 465 each peer router is an independent sender. In effect, link-local 466 communication is an SSM communication that happens to use an ASM 467 address (which is shared among all the routers). 469 Given that it is always possible to distinguish a connection using 470 IPsec from a connection not using IPsec, it is recommended that the 471 address ALL_PIM_ROUTERS be used, to maintain consistency with present 472 practice. 474 Given that the sender address of an incoming packet may be only 475 locally unique (because of the use of link-local addresses), it will 476 be necessary for a receiver to use the interface ID tag to sort out 477 the associated SA for that sender. Therefore, this document mandates 478 that the interface ID tag, the SPI and the sender address MUST be 479 used in the SA lookup process. 481 12. Activating the Anti-replay Mechanism 483 Although link-level messages on a link constitute a multiple-sender, 484 multiple-receiver group, the use of the interface ID tag and sender 485 address for SA lookup essentially resolves the communication into a 486 separate SA for each sender/destination pair, even for the case where 487 only two SAs (and one shared key) are used for the entire 488 administrative region. Therefore, the statement in the AH RFC 489 (section 2.5 of [2]) that "for a multi-sender SA, the anti-replay 490 features are not available" becomes irrelevant to the PIM-SM link- 491 local message exchange. 493 To activate the anti-replay mechanism in a unicast communication, the 494 receiver uses the sliding window protocol and it maintains a sequence 495 number for this protocol. This sequence number starts from zero. 496 Each time the sender sends a new packet, it increments this number by 497 one. In a multi-sender multicast group communication, a single 498 sequence number for the entire group would not be enough. 500 The whole scenario is different for PIM link-local messages. These 501 messages are sent to local links with TTL = 1. A link-local message 502 never propagates through one router to another. The use of the 503 sender address and the interface ID tag for SA lookup converts the 504 relationship from a multiple-sender group to multiple single-sender 505 associations. This specification RECOMMENDS activation of the anti- 506 replay mechanism only if the SAs are assigned using an automated key 507 management. In manual key management, the anti-replay SHOULD NOT be 508 activated. If the number of router(s) to be assigned manually is 509 small, the Network Administrator MAY consider to activate anti- 510 replay. If anti-replay is activated a PIM router MUST maintain a 511 different sliding window for each directly connected sender. 513 If the SAs are activated according to Figure 3, that is all the nodes 514 use only two SAs, one SA for sending and the other is for receiving 515 traffic, a PIM router MAY still activate the anti-replay mechanism. 516 Instead of maintaining only two SAs, the router will maintain the 517 same number of SAs as explained in the first method (see Figure 2) 518 (because of the differentiation based on sender address). For each 519 active SA a corresponding sequence number MUST be maintained. Thus, 520 a PIM router will maintain a number of identical SAs, except that the 521 sender address, interface ID tag and the sequence number are 522 different for each SA. In this way a PIM router will be at least 523 free from all the attacks that can be performed by replaying PIM-SM 524 packets. 526 Note that when activating anti-replay with manual key configuration, 527 the following actions must be taken by the network administrator: 529 a. If a new router is added, the Network Administrator MUST add a 530 new SA entry in each peer router. 532 b. If an existing router has to restart, the Network Administrator 533 MUST refresh the counter (ESN, see Section 14) to zero for all 534 the peer routers. This implies deleting all the existing SAs and 535 adding a new SA with the same configuration and a re-initialized 536 counter. 538 13. Implementing a Security Association Database per Interface 540 RFC 4601 suggests that it may be desirable to implement a separate 541 Security Association Database (SAD) for each router interface. The 542 use of link-local addresses in certain circumstances implies that 543 differentiation of ambiguous speaker addresses requires the use of 544 the interface ID tag in the SA lookup. One way to do this is through 545 the use of multiple SADs. Alternatively, the interface ID tag may be 546 a specific component of the selector algorithm. This is in 547 conformance with RFC 4301, which explicitly removes the requirement 548 for separate SADs that was present in RFC 2401 [8]. 550 14. Extended Sequence Number 552 In the [2], there is a provision for a 64-bit Extended Sequence 553 Number (ESN) as the counter of the sliding window used in the anti- 554 replay protocol. Both the sender and the receiver maintain a 64-bit 555 counter for the sequence number, although only the lower order 32 556 bits is sent in the transmission. In other words, it will not affect 557 the present header format of AH. If ESN is used, a sender router can 558 send 2^64 -1 packets without any intervention. This number is very 559 large, and from a PIM router's point of view, a PIM router can never 560 exceed this number in its lifetime. This makes it reasonable to 561 permit manual configuration for a small number of PIM routers, since 562 the sequence number will never roll over. For this reason, when 563 manual configuration is used, ESN SHOULD be deployed as the sequence 564 number for the sliding window protocol. 566 15. Security Considerations 568 The whole document considers the security issues of PIM link-local 569 messages and proposes a mechanism to protect them. 571 Limitations of manual keys: 573 The following are some of the known limitations of the usage of 574 manual keys. 576 o If replay protection cannot be provided, the PIM routers will not 577 be secured against all the attacks that can be performed by 578 replaying PIM packets. 580 o Manual keys are usually long lived (changing them often is a 581 tedious task). This gives an attacker enough time to discover the 582 keys. 584 o As the administrator is manually configuring the keys, there is a 585 chance that the configured keys are weak (there are known weak 586 keys for DES/3DES at least). 588 Impersonation attacks: 590 The usage of the same key on all the PIM routers connected to a link 591 leaves them all insecure against impersonation attacks if any one of 592 the PIM routers is compromised, malfunctioning, or misconfigured. 594 Detailed analysis of various vulnerabilities of routing protocols is 595 provided in RFC 4593 [14]. For further discussion of PIM-SM and 596 multicast security the reader is referred to [15], RFC 4609 [16] and 597 the Security Considerations section of RFC 4601 [1]. 599 16. References 601 16.1. Normative References 603 [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 604 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 605 Protocol Specification (Revised)", RFC 4601, August 2006. 607 [2] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 609 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 610 Levels", BCP 14, RFC 2119, March 1997. 612 [4] Kent, S. and K. Seo, "Security Architecture for the Internet 613 Protocol", RFC 4301, December 2005. 615 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 616 December 2005. 618 [6] Hardjono, T. and B. Weis, "The Multicast Group Security 619 Architecture", RFC 3740, March 2004. 621 [7] Eastlake, D., "Cryptographic Algorithm Implementation 622 Requirements for Encapsulating Security Payload (ESP) and 623 Authentication Header (AH)", RFC 4305, December 2005. 625 16.2. Informative References 627 [8] Kent, S. and R. Atkinson, "Security Architecture for the 628 Internet Protocol", RFC 2401, November 1998. 630 [9] Islam, S., "Security Issues in PIM-SM Link-local Messages, 631 Master's Thesis, Concordia University", December 2003. 633 [10] Islam, S., "Security Issues in PIM-SM Link-local Messages, 634 Proceedings of LCN 2004", November 2004. 636 [11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 637 RFC 4306, December 2005. 639 [12] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 640 Group Secure Association Key Management Protocol", RFC 4535, 641 June 2006. 643 [13] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 644 Domain of Interpretation", RFC 3547, July 2003. 646 [14] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 647 Routing Protocols", RFC 4593, October 2006. 649 [15] Savola, P. and J. Lingard, "Host Threats to Protocol 650 Independent Multicast (PIM)", draft-ietf-pim-lasthop-threats-03 651 (work in progress), October 2007. 653 [16] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent 654 Multicast - Sparse Mode (PIM-SM) Multicast Routing Security 655 Issues and Enhancements", RFC 4609, October 2006. 657 Authors' Addresses 659 J. William Atwood 660 Concordia University/CSE 661 1455 de Maisonneuve Blvd, West 662 Montreal, QC H3G 1M8 663 Canada 665 Phone: +1(514)848-2424 ext3046 666 Email: bill@cse.concordia.ca 667 URI: http://users.encs.concordia.ca/~bill 669 Salekul Islam 670 Concordia University/CSE 671 1455 de Maisonneuve Blvd, West 672 Montreal, QC H3G 1M8 673 Canada 675 Full Copyright Statement 677 Copyright (C) The IETF Trust (2007). 679 This document is subject to the rights, licenses and restrictions 680 contained in BCP 78, and except as set forth therein, the authors 681 retain all their rights. 683 This document and the information contained herein are provided on an 684 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 685 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 686 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 687 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 688 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 689 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 691 Intellectual Property 693 The IETF takes no position regarding the validity or scope of any 694 Intellectual Property Rights or other rights that might be claimed to 695 pertain to the implementation or use of the technology described in 696 this document or the extent to which any license under such rights 697 might or might not be available; nor does it represent that it has 698 made any independent effort to identify any such rights. Information 699 on the procedures with respect to rights in RFC documents can be 700 found in BCP 78 and BCP 79. 702 Copies of IPR disclosures made to the IETF Secretariat and any 703 assurances of licenses to be made available, or the result of an 704 attempt made to obtain a general license or permission for the use of 705 such proprietary rights by implementers or users of this 706 specification can be obtained from the IETF on-line IPR repository at 707 http://www.ietf.org/ipr. 709 The IETF invites any interested party to bring to its attention any 710 copyrights, patents or patent applications, or other proprietary 711 rights that may cover technology that may be required to implement 712 this standard. Please address the information to the IETF at 713 ietf-ipr@ietf.org. 715 Acknowledgment 717 Funding for the RFC Editor function is provided by the IETF 718 Administrative Support Activity (IASA).