idnits 2.17.1 draft-ietf-pim-sm-linklocal-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. 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 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 (February 25, 2008) is 5877 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 706, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 709, 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 4835 (ref. '7') (Obsoleted by RFC 7321) -- 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 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-00 == Outdated reference: A later version (-09) exists of draft-ietf-msec-ipsec-extensions-08 Summary: 4 errors (**), 0 flaws (~~), 7 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 M. Siami 6 Expires: August 28, 2008 Concordia University/CIISE 7 February 25, 2008 9 Authentication and Confidentiality in PIM-SM Link-local Messages 10 draft-ietf-pim-sm-linklocal-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 28, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 RFC 4601 mandates the use of IPsec to ensure authentication of the 44 link-local messages in the Protocol Independent Multicast - Sparse 45 Mode (PIM-SM) routing protocol. This document specifies mechanisms 46 to authenticate the PIM-SM link local messages using the IP security 47 (IPsec) Authentication Header (AH) or Encapsulating Security Payload 48 (ESP). It specifies optional mechanisms to provide confidentiality 49 using the ESP. Manual keying is specified as the mandatory and 50 default group key management solution. To deal with issues of 51 scalability and security that exist with manual keying, an optional 52 automated group key management mechanism is specified. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 6 59 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 10 64 7.2. Automated Key Management . . . . . . . . . . . . . . . . . 10 65 7.3. Communications Patterns . . . . . . . . . . . . . . . . . 11 66 7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 12 67 8. Number of Security Associations . . . . . . . . . . . . . . . 13 68 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 15 70 9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 15 71 9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 15 72 10. IPsec Protection Barrier and GSPD . . . . . . . . . . . . . . 16 73 10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 16 74 10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 16 75 10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 16 76 10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 16 77 10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 16 78 10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 16 79 10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 17 80 11. Security Association Lookup . . . . . . . . . . . . . . . . . 18 81 12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 19 82 13. Implementing a Security Association Database per Interface . . 21 83 14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 22 84 15. Security Considerations . . . . . . . . . . . . . . . . . . . 23 85 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 88 17.2. Informative References . . . . . . . . . . . . . . . . . . 25 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 90 Intellectual Property and Copyright Statements . . . . . . . . . . 28 92 1. Introduction 94 All the PIM-SM [1] control messages have IP protocol number 103. 95 These messages are either unicast, or multicast with TTL = 1. The 96 source address used for unicast messages is a domain-wide reachable 97 address. For the multicast messages, a link-local address of the 98 interface on which the message is being sent is used as the source 99 address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 100 in IPv4 and ff02::d in IPv6) is used as the destination address. 101 These messages are called link-local messages. Hello, Join/Prune and 102 Assert messages are included in this category. A forged link-local 103 message may be sent to the ALL_PIM_ROUTERS multicast address by an 104 attacker. This type of message affects the construction of the 105 distribution tree [1]. The effects of these forged messages are 106 outlined in section 6.1 of [1]. Some of the effects are very severe, 107 whereas some are minor. 109 PIM-SM version 2 was originally specified in RFC 2117, and revised in 110 RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a 111 number of deficiencies. The Security Considerations section of RFC 112 4601 is based primarily on the new Authentication Header (AH) 113 specification described in RFC 4302 [2]. 115 Securing the unicast messages can be achieved by the use of a normal 116 unicast IPsec Security Association between the two communicants. 117 Securing the user data exchanges is covered in RFC 3740 [6]. This 118 document focuses on the security issues for link-local messages. It 119 provides some guidelines to take advantage of the new permitted AH 120 functionality in RFC 4302, and to bring the PIM-SM specification into 121 alignment with the new AH specification. This document recommends 122 manual key management as mandatory to implement, i.e., that all 123 implementations MUST support, and begins the discussion of an 124 automated key management protocol that the PIM routers can use. 126 2. Terminology 128 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 129 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 130 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 131 indicate requirement levels for compliant PIM-SM implementations. 133 3. Transport Mode vs. Tunnel Mode 135 The transport mode Security Association (SA) is generally used 136 between two hosts or routers/gateways when they are acting as hosts. 137 The SA must be a tunnel mode SA if either end of the security 138 association is a router/gateway. Two hosts MAY establish a tunnel 139 mode SA between themselves. PIM-SM link-local messages are exchanged 140 between routers. However, since the packets are locally delivered, 141 the routers assume the role of hosts in the context of the tunnel 142 mode SA. All implementations conforming to this specification MUST 143 support transport mode SA to provide required IPsec security to 144 PIM-SM link-local messages. They MAY also support tunnel mode SA to 145 provide required IPsec security to PIM-SM link-local messages. 147 4. Authentication 149 Implementations conforming to this specification MUST support 150 authentication for PIM-SM link-local messages. 152 In order to provide authentication to PIM-SM link-local messages, 153 implementations MUST support ESP [5] and MAY support AH [2]. 155 If ESP in transport mode is used, it will only provide authentication 156 to PIM-SM protocol packets excluding the IPv6 header, extension 157 headers, and options. (Note: The IPv4 exclusions need to be listed 158 here as well.) 160 If AH in transport mode is used, it will provide authentication to 161 PIM-SM protocol packets, selected portions of the IPv6 header, 162 extension headers and options. (Note: the IPv4 coverage needs to be 163 listed here as well.) 165 When authentication for PIM-SM link-local messages is enabled, 167 o PIM-SM link-local packets that are not protected with AH or ESP 168 MUST be silently discarded. 170 o PIM-SM link-local packets that fail the authentication checks MUST 171 be silently discarded. 173 5. Confidentiality 175 Implementations conforming to this specification SHOULD support 176 confidentiality for PIM-SM. 178 If confidentiality is provided, ESP MUST be used. 180 When PIM-SM confidentiality is enabled, 182 o PIM-SM packets that are not protected with ESP MUST be silently 183 discarded. 185 o PIM-SM packets that fail the confidentiality checks MUST be 186 silently discarded. 188 6. IPsec Requirements 190 In order to implement this specification, the following IPsec 191 capabilities are required. 193 Transport mode 194 IPsec in transport mode MUST be supported. 196 Multiple Security Policy Databases (SPDs) 197 The implementation MUST support multiple SPDs with an SPD 198 selection function that provides an ability to choose a specific 199 SPD based on interface. 201 Selectors 202 The implementation MUST be able to use source address, destination 203 address, protocol, and direction as selectors in the SPD. 205 Interface ID tagging 206 The implementation MUST be able to tag the inbound packets with 207 the ID of the interface (physical or virtual) via which it 208 arrived. 210 Manual key support 211 Manually configured keys MUST be able to secure the specified 212 traffic. 214 Encryption and authentication algorithms 215 The implementation MUST NOT allow the user to choose stream 216 ciphers as the encryption algorithm for securing PIM-SM packets 217 since the stream ciphers are not suitable for manual keys. Except 218 when in conflict with the above statement, the key words "MUST", 219 "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in 220 RFC 4835 [7] for algorithms to be supported are to be interpreted 221 as described in RFC 2119 [3] for PIM-SM support as well. 223 Encapsulation of ESP packet 224 IP encapsulation of ESP packets MUST be supported. For 225 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 227 7. Key Management 229 All the implementations MUST support manual configuration of the SAs 230 that will be used to authenticate PIM-SM link-local messages. This 231 does not preclude the use of a negotiation protocol such as the 232 Internet Key Exchange (IKE) [11] or Group Secure Association Key 233 Management Protocol (GSAKMP) [12] to establish SAs. 235 7.1. Manual Key Management 237 To establish the SAs at PIM-SM routers, manual key configuration will 238 be feasible when the number of peers (directly connected routers) is 239 small. The Network Administrator will configure a router manually 240 during its boot up process. At that time, the authentication method 241 and the choice of keys SHOULD be configured. The SAD entry will be 242 created. The Network Administrator will also configure the Security 243 Policy Database of a router to ensure the use of the associated SA 244 while sending a link-local message. 246 7.2. Automated Key Management 248 All the link-local messages of the PIM-SM protocol are sent to the 249 destination address, ALL_PIM_ROUTERS, which is a multicast address. 250 By using the sender address in conjunction with the destination 251 address for Security Association lookup, link-local communication 252 turns to an SSM or "one to many" communication. Since IKE is based 253 on the Diffie-Hellman key agreement protocol and works only for two 254 communicating parties, it is not possible to use IKE for providing 255 the required "one to many" authentication. 257 One option is to use Group Domain Of Interpretation (GDOI) [13], 258 which enables a group of users or devices to exchange encrypted data 259 using IPsec data encryption. GDOI has been developed to be used in 260 multicast applications, where the number of end users or devices may 261 be large and the end users or devices can dynamically join/leave a 262 multicast group. However, a PIM router is not expected to join/leave 263 very frequently, and the number of routers is small when compared to 264 the possible number of users of a multicast application. Moreover, 265 most of the PIM routers will be located inside the same 266 administrative domain and are considered as trusted parties. It is 267 possible that a subset of GDOI functionalities will be sufficient. 269 A framework for automating key management for RSVP is given in [17]. 270 A companion modification for GDOI is presented in [18]. NOTE: A 271 similar pair of documents will be prepared for PIM-SM. 273 7.3. Communications Patterns 275 Before discussing the set of security associations that are required 276 to properly manage a multicast region that is under the control of a 277 single administration, it is necessary to understand the 278 communications patterns that will exist among the routers in this 279 region. From the perspective of a speaking router, the information 280 from that router is sent (multicast) to all of its neighbors. From 281 the perspective of a listening router, the information coming from 282 each of its neighbors is distinct from the information coming from 283 every other router to which it is directly connected. Thus an 284 administrative region contains many (small) distinct groups, all of 285 which happen to be using the same multicast destination address 286 (e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is 287 centered on the associated speaking router. 289 Consider the example configuration as shown in Figure 1. 291 R2 R3 R4 R5 R6 292 | | | | | 293 | | | | | 294 --------- --------------- 295 | | 296 | | 297 \ / 298 R1 299 / \ 300 | | 301 | | 302 --------- -------------------- 303 | | | | | 304 | | | | | 305 R7 R8 R9 R10 R11 306 | | | | | 307 | 308 | 309 ------------- 310 | | | 311 | | | 312 R12 R13 R14 314 Figure 1: Set of router interconnections 316 In this configuration, router R1 has four interfaces, and is the 317 speaking router for a group whose listening routers are routers R2 318 through R11. Router R9 is the speaking router for a group whose 319 listening routers are routers R1, R8 and R10-R14. 321 From the perspective of R1 as a speaking router, if a Security 322 Association SA1 is assigned to protect outgoing packets from R1, then 323 it is necessary to distribute the key for this association to each of 324 the routers R2 through R11. Similarly, from the perspective of R9 as 325 a speaking router, if a Security Association is assigned to protect 326 the outgoing packets from R9, then it is necessary to distribute the 327 key for this association to each of the routers R1, R8, and R10 328 through R14. 330 From the perspective of R1 as a listening router, all packets 331 arriving from R2 through R11 need to be distinguished from each 332 other, to permit selecting the correct Security Association in the 333 SAD. (Packets from each of the peer routers (R2 through R11) 334 represent communication from a different speaker, even though they 335 are sent using the same destination address.) For a multicast 336 Security Association, RFC 4301 permits using the Source Address in 337 the selection function. If the source addresses used by routers R2 338 through R11 are globally unique, then the source addresses of the 339 peer routers are sufficient to achieve the differentiation. If the 340 sending routers use link-local addresses, then these addresses are 341 unique only on a per-interface basis, and it is necessary to use the 342 Interface ID tag as an additional selector, i.e., either the 343 selection function has to have the Interface ID tag as one of its 344 inputs, or separate SADs have to be maintained for each interface. 346 If the assumption of connectivity to the key server can be made 347 (which is true in the PIM-SM case), then the GC/KS can be centrally 348 located (and duplicated for reliability). If this assumption cannot 349 be made (i.e., in the case of adjacencies for a unicast router), then 350 some form of "local" key server must be available for each group. 351 Given that the listening routers are never more than one hop away 352 from the speaking router, the speaking router is the obvious place to 353 locate the "local" key server. This has the additional advantage 354 that there is no need to duplicate the local key server for 355 reliability, since if the key server is down, it is very likely that 356 the speaking router is also down. 358 7.4. Neighbor Relationships 360 Each distinct group consists of one speaker, and the set of directly 361 connected listeners. If the decision is made to maintain one 362 Security Association per speaker (see Section 8), then the key server 363 will need to be aware of the adjacencies of each speaker. Procedures 364 for doing this are under study. 366 8. Number of Security Associations 368 The number of Security Associations to be maintained by a PIM router 369 depends on the required security level and available key management. 370 This SHOULD be decided by the Network Administrator. Two different 371 ways are shown in Figure 2 and 3. It is assumed that A, B and C are 372 three PIM routers, where B and C are directly connected with A, and 373 there is no direct link between B and C. 375 | 376 B | 377 SAb ------------>| 378 SAa <------------| 379 | 380 A | 381 SAb <------------| 382 SAa ------------>| 383 SAc <------------| 384 | 385 C | 386 SAc ------------>| 387 SAa <------------| 388 | 389 Directly connected network 391 Figure 2: Activate unique Security Association for each peer 393 The first method, shown in Figure 2 is OPTIONAL to implement. In 394 this method, each node will use a unique SA for its outbound traffic. 395 A, B, and C will use SAa, SAb, and SAc, respectively for sending any 396 traffic. Each node will look up the SA to be used based on the 397 source address. A will use SAb and SAc for packets received from B 398 and C, respectively. The number of SAs to be activated and 399 maintained by a PIM router will be equal to the number of directly 400 connected routers plus one, for sending its own traffic. Also, the 401 addition of a PIM router in the network will require the addition of 402 another SA on every directly connected PIM router. This solution 403 will be scalable and practically feasible with an automated key 404 management protocol. However, it MAY be used with manual key 405 management, if the number of directly connected router(s) is small. 407 B | 408 SAo ------------>| 409 SAi <------------| 410 | 411 A | 412 SAo ------------>| 413 SAi <------------| 414 | 415 C | 416 SAo ------------>| 417 SAi <------------| 418 | 419 Directly connected network 421 Figure 3: Activate two Security Associations 423 The second method, shown in Figure 3, MUST be supported by every 424 implementation. In this simple method, all the nodes will use two 425 SAs, one for sending (SAo) and the other for receiving (SAi) traffic. 426 Thus, the number of SAs is always two and will not be affected by 427 addition of a PIM router. Although two different SAs are used in 428 this method, the SA parameters (keys, SPI, etc.) for the two SAs are 429 identical, i.e., the same information is shared among all the routers 430 in an administrative region. This document RECOMMENDS the above 431 method for manual key configuration. However, it MAY also be used 432 with automated key configuration. When manually configured, the 433 method suffers from impersonation attacks as mentioned in the 434 Security Considerations section. 436 9. Rekeying 438 This section will provide the rekeying rules. It will be written 439 once is is decided whether or not to specify a re-keying protocol as 440 part of this document. 442 9.1. Rekeying Procedure 444 TBD 446 9.2. KeyRollover Interval 448 TBD 450 9.3. Rekeying Interval 452 TBD 454 10. IPsec Protection Barrier and GSPD 456 10.1. Manual Keying 458 10.1.1. SAD Entries 460 The Administrator must configure the necessary Security Associations. 461 Each SA entry has the Source Address of an authorized peer, and a 462 Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the 463 manually configured SAs MUST be assigned by the Administrator, to 464 ensure that the SPI does not conflict with existing SPI values in the 465 SAD. 467 10.1.2. SPD Entries 469 The Administrator must configure the necessary SPD entries. The SPD 470 entry must ensure that any outbound IP traffic packet traversing the 471 IPsec boundary, with PIM as its next layer protocol, PIM message type 472 of Hello, Join/Prune, bootstrap or Assert, sent to the Destination 473 Address of ALL_PIM_ROUTERS, is protected by AH. If the IPsec 474 implementation does not identify PIM message types as a selector, the 475 "local port" selector can be used, with suitable adjustment. 477 10.2. Automatic Keying 479 When automatic keying is used, the SA creation is done dynamically 480 using a group key management protocol. The GSPD and PAD tables are 481 configured by the Administrator. The PAD table provides the link 482 between the IPsec subsystem and the group key management protocol. 483 For automatic keying, the implementation MUST support the multicast 484 extensions described in [19]. 486 10.2.1. SAD Entries 488 All PIM routers participate in an authentication scheme that 489 identifies permitted neighbors and achieves peer authentication 490 during SA negotiation, leading to child SAs being established and 491 saved in the SAD. 493 10.2.2. GSPD Entries 495 The Administrator must configure the necessary GSPD entries for "send 496 only" directionality. This rule MUST trigger the group key 497 management protocol for a registration exchange. This exchange will 498 set up the outbound SAD entry that encrypts the multicast PIM control 499 message. Considering that this rule is "sender only", no inbound SA 500 is created in the reverse direction. 502 In addition, the registration exchange will install GSPD entries 503 corresponding to each legitimate peer router, with direction "receive 504 only". 506 To account for new, legitimate neighbors, the Administrator MUST 507 configure a GSPD entry for "any" peer router, destined to the 508 ALL_PIM_ROUTERS address. This entry will trigger a query to the 509 group key management protocol, to establish the legitimacy (or lack 510 of it) of the new peer, and install the necessary SAD "receive only" 511 entry. 513 10.2.3. PAD Entries 515 The PAD must be configured by the Administrator with information to 516 permit identification of legitimate group members and senders. This 517 will be detailed in a companion document (to be written). 519 11. Security Association Lookup 521 For an SA that carries unicast traffic, three parameters (SPI, 522 destination address and security protocol type (AH or ESP)) are used 523 in the Security Association lookup process for inbound packets. The 524 SPI is sufficient to specify an SA. However, an implementation may 525 use the SPI in conjunction with the IPsec protocol type (AH or ESP) 526 for the SA lookup process. According to RFC 4301 [4] and the AH 527 specification [2], for multicast SAs, in conjunction with the SPI, 528 the destination address or the destination address plus the sender 529 address may also be used in the SA lookup. The security protocol 530 field is not employed for a multicast SA lookup. 532 The reason for the various prohibitions in the IPsec RFCs concerning 533 multisender multicast SAs lies in the difficulty of coordinating the 534 multiple senders. However, if the use of multicast for link-local 535 messages is examined, it may be seen that in fact the communication 536 need not be coordinated---from the prospective of a receiving router, 537 each peer router is an independent sender. In effect, link-local 538 communication is an SSM communication that happens to use an ASM 539 address (which is shared among all the routers). 541 Given that it is always possible to distinguish a connection using 542 IPsec from a connection not using IPsec, it is recommended that the 543 address ALL_PIM_ROUTERS be used, to maintain consistency with present 544 practice. 546 Given that the sender address of an incoming packet may be only 547 locally unique (because of the use of link-local addresses), it will 548 be necessary for a receiver to use the interface ID tag to sort out 549 the associated SA for that sender. Therefore, this document mandates 550 that the interface ID tag, the SPI and the sender address MUST be 551 used in the SA lookup process. 553 12. Activating the Anti-replay Mechanism 555 Although link-level messages on a link constitute a multiple-sender, 556 multiple-receiver group, the use of the interface ID tag and sender 557 address for SA lookup essentially resolves the communication into a 558 separate SA for each sender/destination pair, even for the case where 559 only two SAs (with identical SA parameters) are used for the entire 560 administrative region. Therefore, the statement in the AH RFC 561 (section 2.5 of [2]) that "for a multi-sender SA, the anti-replay 562 features are not available" becomes irrelevant to the PIM-SM link- 563 local message exchange. 565 To activate the anti-replay mechanism in a unicast communication, the 566 receiver uses the sliding window protocol and it maintains a sequence 567 number for this protocol. This sequence number starts from zero. 568 Each time the sender sends a new packet, it increments this number by 569 one. In a multi-sender multicast group communication, a single 570 sequence number for the entire group would not be enough. 572 The whole scenario is different for PIM link-local messages. These 573 messages are sent to local links with TTL = 1. A link-local message 574 never propagates through one router to another. The use of the 575 sender address and the interface ID tag for SA lookup converts the 576 relationship from a multiple-sender group to multiple single-sender 577 associations. This specification RECOMMENDS activation of the anti- 578 replay mechanism only if the SAs are assigned using an automated key 579 management procedure. In manual key management, the anti-replay 580 SHOULD NOT be activated. If the number of router(s) to be assigned 581 manually is small, the Network Administrator MAY consider to activate 582 anti-replay. If anti-replay is activated a PIM router MUST maintain 583 a different sliding window for each directly connected sender. 585 If the SAs are activated according to Figure 3, that is all the nodes 586 use only two SAs, one SA for sending and the other is for receiving 587 traffic, a PIM router MAY still activate the anti-replay mechanism. 588 Instead of maintaining only two SAs, the router will maintain the 589 same number of SAs as explained in the first method (see Figure 2) 590 (because of the differentiation based on sender address). For each 591 active SA a corresponding sequence number MUST be maintained. Thus, 592 a PIM router will maintain a number of identical SAs, except that the 593 sender address, interface ID tag and the sequence number are 594 different for each SA. In this way a PIM router will be at least 595 free from all the attacks that can be performed by replaying PIM-SM 596 packets. 598 Note that when activating anti-replay with manual key configuration, 599 the following actions must be taken by the network administrator: 601 a. If a new router is added, the Network Administrator MUST add a 602 new SA entry in each peer router. 604 b. If an existing router has to restart, the Network Administrator 605 MUST refresh the counter (ESN, see Section 14) to zero for all 606 the peer routers. This implies deleting all the existing SAs and 607 adding a new SA with the same configuration and a re-initialized 608 counter. 610 13. Implementing a Security Association Database per Interface 612 RFC 4601 suggests that it may be desirable to implement a separate 613 Security Association Database (SAD) for each router interface. The 614 use of link-local addresses in certain circumstances implies that 615 differentiation of ambiguous speaker addresses requires the use of 616 the interface ID tag in the SA lookup. One way to do this is through 617 the use of multiple SADs. Alternatively, the interface ID tag may be 618 a specific component of the selector algorithm. This is in 619 conformance with RFC 4301, which explicitly removes the requirement 620 for separate SADs that was present in RFC 2401 [8]. 622 14. Extended Sequence Number 624 In the [2], there is a provision for a 64-bit Extended Sequence 625 Number (ESN) as the counter of the sliding window used in the anti- 626 replay protocol. Both the sender and the receiver maintain a 64-bit 627 counter for the sequence number, although only the lower order 32 628 bits is sent in the transmission. In other words, it will not affect 629 the present header format of AH. If ESN is used, a sender router can 630 send 2^64 -1 packets without any intervention. This number is very 631 large, and from a PIM router's point of view, a PIM router can never 632 exceed this number in its lifetime. This makes it reasonable to 633 permit manual configuration for a small number of PIM routers, since 634 the sequence number will never roll over. For this reason, when 635 manual configuration is used, ESN SHOULD be deployed as the sequence 636 number for the sliding window protocol. 638 15. Security Considerations 640 The whole document considers the security issues of PIM link-local 641 messages and proposes a mechanism to protect them. 643 Limitations of manual keys: 645 The following are some of the known limitations of the usage of 646 manual keys. 648 o If replay protection cannot be provided, the PIM routers will not 649 be secured against all the attacks that can be performed by 650 replaying PIM packets. 652 o Manual keys are usually long lived (changing them often is a 653 tedious task). This gives an attacker enough time to discover the 654 keys. 656 o As the administrator is manually configuring the keys, there is a 657 chance that the configured keys are weak (there are known weak 658 keys for DES/3DES at least). 660 Impersonation attacks: 662 The usage of the same key on all the PIM routers connected to a link 663 leaves them all insecure against impersonation attacks if any one of 664 the PIM routers is compromised, malfunctioning, or misconfigured. 666 Detailed analysis of various vulnerabilities of routing protocols is 667 provided in RFC 4593 [14]. For further discussion of PIM-SM and 668 multicast security the reader is referred to [15], RFC 4609 [16] and 669 the Security Considerations section of RFC 4601 [1]. 671 16. IANA Considerations 673 This document has no actions for IANA. 675 17. References 677 17.1. Normative References 679 [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 680 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 681 Protocol Specification (Revised)", RFC 4601, August 2006. 683 [2] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 685 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 686 Levels", BCP 14, RFC 2119, March 1997. 688 [4] Kent, S. and K. Seo, "Security Architecture for the Internet 689 Protocol", RFC 4301, December 2005. 691 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 692 December 2005. 694 [6] Hardjono, T. and B. Weis, "The Multicast Group Security 695 Architecture", RFC 3740, March 2004. 697 [7] Manral, V., "Cryptographic Algorithm Implementation 698 Requirements for Encapsulating Security Payload (ESP) and 699 Authentication Header (AH)", RFC 4835, April 2007. 701 17.2. Informative References 703 [8] Kent, S. and R. Atkinson, "Security Architecture for the 704 Internet Protocol", RFC 2401, November 1998. 706 [9] Islam, S., "Security Issues in PIM-SM Link-local Messages, 707 Master's Thesis, Concordia University", December 2003. 709 [10] Islam, S., "Security Issues in PIM-SM Link-local Messages, 710 Proceedings of LCN 2004", November 2004. 712 [11] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 713 RFC 4306, December 2005. 715 [12] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 716 Group Secure Association Key Management Protocol", RFC 4535, 717 June 2006. 719 [13] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 720 Domain of Interpretation", RFC 3547, July 2003. 722 [14] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 723 Routing Protocols", RFC 4593, October 2006. 725 [15] Savola, P. and J. Lingard, "Host Threats to Protocol 726 Independent Multicast (PIM)", draft-ietf-pim-lasthop-threats-03 727 (work in progress), October 2007. 729 [16] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent 730 Multicast - Sparse Mode (PIM-SM) Multicast Routing Security 731 Issues and Enhancements", RFC 4609, October 2006. 733 [17] Behringer, M. and F. Faucheur, "Applicability of Keying Methods 734 for RSVP Security", 735 draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in 736 progress), February 2008. 738 [18] Weis, B., "Group Domain of Interpretation (GDOI) support for 739 RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress), 740 February 2008. 742 [19] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to 743 the Security Architecture for the Internet Protocol", 744 draft-ietf-msec-ipsec-extensions-08 (work in progress), 745 February 2008. 747 Authors' Addresses 749 J. William Atwood 750 Concordia University/CSE 751 1455 de Maisonneuve Blvd, West 752 Montreal, QC H3G 1M8 753 Canada 755 Phone: +1(514)848-2424 ext3046 756 Email: bill@cse.concordia.ca 757 URI: http://users.encs.concordia.ca/~bill 759 Salekul Islam 760 Concordia University/CSE 761 1455 de Maisonneuve Blvd, West 762 Montreal, QC H3G 1M8 763 Canada 765 Email: salek_is@cse.concordia.ca 766 URI: http://users.encs.concordia.ca/~salek_is 768 Maziar Siami 769 Concordia University/CIISE 770 1455 de Maisonneuve Blvd, West 771 Montreal, QC H3G 1M8 772 Canada 774 Email: m_siamis@ciise.concordia.ca 776 Full Copyright Statement 778 Copyright (C) The IETF Trust (2008). 780 This document is subject to the rights, licenses and restrictions 781 contained in BCP 78, and except as set forth therein, the authors 782 retain all their rights. 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 787 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 788 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 789 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Intellectual Property 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Acknowledgment 818 Funding for the RFC Editor function is provided by the IETF 819 Administrative Support Activity (IASA).