idnits 2.17.1 draft-ietf-pim-sm-linklocal-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (October 26, 2009) is 5296 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) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group W. Atwood 3 Internet-Draft Concordia University/CSE 4 Updates: 4601 (if approved) S. Islam 5 Intended status: Standards Track INRS Energie, Materiaux et 6 Expires: April 29, 2010 Telecommunications 7 M. Siami 8 Concordia University/CIISE 9 October 26, 2009 11 Authentication and Confidentiality in PIM-SM Link-local Messages 12 draft-ietf-pim-sm-linklocal-09 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and 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 April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 RFC 4601 mandates the use of IPsec to ensure authentication of the 51 link-local messages in the Protocol Independent Multicast - Sparse 52 Mode (PIM-SM) routing protocol. This document specifies mechanisms 53 to authenticate the PIM-SM link-local messages using the IP security 54 (IPsec) Encapsulating Security Payload (ESP) or (optionally) the 55 Authentication Header (AH). It specifies optional mechanisms to 56 provide confidentiality using the ESP. Manual keying is specified as 57 the mandatory and default group key management solution. To deal 58 with issues of scalability and security that exist with manual 59 keying, an optional support for automated group key management 60 mechanism is provided. However, the procedures for implementing 61 automated group key management are left to other documents. This 62 document updates RFC 4601. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Goals and Non-goals . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 5 70 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8 75 7.2. Automated Key Management . . . . . . . . . . . . . . . . . 8 76 7.3. Communications Patterns . . . . . . . . . . . . . . . . . 9 77 7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 11 78 8. Number of Security Associations . . . . . . . . . . . . . . . 11 79 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9.1. Manual Rekeying Procedure . . . . . . . . . . . . . . . . 14 81 9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 15 82 9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 15 83 10. IPsec Protection Barrier and SPD/GSPD . . . . . . . . . . . . 15 84 10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 15 85 10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 15 86 10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 15 87 10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 15 88 10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 16 89 10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 16 90 10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 16 91 11. Security Association Lookup . . . . . . . . . . . . . . . . . 16 92 12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 17 93 13. Implementing a Security Policy Database per Interface . . . . 18 94 14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 18 95 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 96 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 98 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 18.1. Normative References . . . . . . . . . . . . . . . . . . . 20 100 18.2. Informative References . . . . . . . . . . . . . . . . . . 20 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 103 1. Introduction 105 All the PIM-SM [RFC4601] control messages have IP protocol number 106 103. These messages are either unicast, or multicast with TTL = 1. 107 The source address used for unicast messages is a domain-wide 108 reachable address. For the multicast messages, a link-local address 109 of the interface on which the message is being sent is used as the 110 source address and a special multicast address, ALL_PIM_ROUTERS 111 (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination 112 address. These messages are called link-local messages. Hello, 113 Join/Prune and Assert messages are included in this category. A 114 forged link-local message may be sent to the ALL_PIM_ROUTERS 115 multicast address by an attacker. This type of message affects the 116 construction of the distribution tree [RFC4601]. The effects of 117 these forged messages are outlined in section 6.1 of [RFC4601]. Some 118 of the effects are very severe, whereas some are minor. 120 PIM-SM version 2 was originally specified in RFC 2117, and revised in 121 RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a 122 number of deficiencies. The Security Considerations section of RFC 123 4601 is based primarily on the Authentication Header (AH) 124 specification described in RFC 4302 [RFC4302]. 126 Securing the unicast messages can be achieved by the use of a normal 127 unicast IPsec Security Association between the two communicants. 129 This document focuses on the security issues for link-local messages. 130 It provides some guidelines to take advantage of the new permitted AH 131 functionality in RFC 4302 and the new permitted ESP functionality in 132 RFC 4303 [RFC4303], and to bring the PIM-SM specification into 133 alignment with the new AH and ESP specifications. In particular, in 134 accordance with RFC 4301, the use of ESP is made mandatory and AH is 135 specified as optional. This document specifies manual key management 136 as mandatory to implement, i.e., that all implementations MUST 137 support, and provides the necessary structure for an automated key 138 management protocol that the PIM routers may use. 140 1.1. Goals and Non-goals 142 The primary goal for link-local security is to provide data origin 143 authentication for each link-local message. A secondary goal is to 144 ensure that communication only happens between legitimate peers 145 (i.e., adjacent routers). An optional goal is to provide data 146 confidentiality for the link-local messages. 148 The first goal implies that each router has a unique identity. It is 149 possible (but not mandatory) that this identity will be based on the 150 unicast identity of the router. (The unicast identity could be, for 151 example, based on some individually-configured property of the 152 router, or be part of a region-wide public key infrastructure.) The 153 existence of this unique identity is assumed in this specification, 154 but procedures for establishing it are out-of-scope for this 155 document. 157 The second goal implies that there is some form of "adjacency matrix" 158 that controls the establishment of security associations among 159 adjacent multicast routers. For manual keying, this control will be 160 exercised by the Administrator of the router(s), through the setting 161 of initialization parameters. For automated keying, the existence of 162 this control will be reflected by the contents of the Peer 163 Authorization Database (PAD) (see RFC 4301 [RFC4301]) or the Group 164 Security Policy Database (GSPD) (see RFC 5374 [RFC5374]) in each 165 router. Procedures for controling the adjacency and building the 166 asssociated PAD and GSPD are out-of-scope for this document. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 They indicate requirement levels for compliant PIM-SM 174 implementations. 176 3. Transport Mode vs. Tunnel Mode 178 All implementations conforming to this specification MUST support 179 transport mode SA to provide required IPsec security to PIM-SM link- 180 local messages. They MAY also support tunnel mode SA to provide 181 required IPsec security to PIM-SM link-local messages. If tunnel 182 mode is used, both destination address preservation and source 183 address preservation MUST be used, as described in Section 3.1 of RFC 184 5374 [RFC5374]. 186 4. Authentication 188 Implementations conforming to this specification MUST support 189 authentication for PIM-SM link-local messages. Implementations 190 conforming to this specification MUST support HMAC-SHA1. 192 In order to provide authentication of PIM-SM link-local messages, 193 implementations MUST support ESP [RFC4303] and MAY support AH 194 [RFC4302]. 196 If ESP in transport mode is used, it will only provide authentication 197 to PIM-SM protocol packets excluding the IP header, extension 198 headers, and options. 200 If AH in transport mode is used, it will provide authentication to 201 PIM-SM protocol packets, selected portions of the IP header, 202 extension headers and options. 204 When authentication for PIM-SM link-local messages is enabled, 206 o PIM-SM link-local packets that are not protected with AH or ESP 207 MUST be silently discarded, although an implementation MAY 208 maintain a counter of such packets. 210 o PIM-SM link-local packets that fail the authentication checks MUST 211 be silently discarded, although an implementation is RECOMMENDED 212 to maintain a counter of such packets. Note: this is an auditable 213 event as described in RFC 4302 [RFC4302] and RFC 4303 [RFC4303]. 215 5. Confidentiality 217 Implementations conforming to this specification SHOULD support 218 confidentiality for PIM-SM. Implementations supporting 219 confidentiality MUST support AES-CBC with a 128-bit key. 221 If confidentiality is provided, ESP MUST be used. 223 When PIM-SM confidentiality is enabled, 225 o PIM-SM packets that are not protected with ESP MUST be silently 226 discarded, although an implementation MAY maintain a counter of 227 such packets. 229 o PIM-SM packets that fail the confidentiality checks MUST be 230 silently discarded, although an implementation is RECOMMENDED to 231 maintain a counter of such packets. Note: this is an auditable 232 event as described in RFC 4302 [RFC4302] and RFC 4303 [RFC4303]. 234 Note that since authentication MUST be supported by a conforming 235 implementation, an implementation MUST NOT generate the combination 236 of NON-NULL Encryption and NULL Authentication. 238 6. IPsec Requirements 240 In order to implement this specification, the following IPsec 241 capabilities are required. 243 Transport mode 244 IPsec in transport mode MUST be supported. 246 Multiple Security Policy Databases (SPDs) 247 The implementation MUST support multiple SPDs with an SPD 248 selection function that provides an ability to choose a specific 249 SPD based on interface. 251 Selectors 252 The implementation MUST be able to use source address, destination 253 address, protocol, and direction as selectors in the SPD. 255 Interface ID tagging 256 The implementation MUST be able to tag the inbound packets with 257 the ID of the interface (physical or virtual) on which they 258 arrived. 260 Manual key support 261 It MUST be possible to use manually configured keys to secure the 262 specified traffic. 264 Encryption and authentication algorithms 265 Encryption and authentication algorithm requirements described in 266 RFC 4835 [RFC4835] apply when ESP and AH are used to protect 267 PIM-SM. Implementations MUST support ESP-NULL, and if providing 268 confidentiality MUST support the RFC4835 [RFC4835] required ESP 269 transforms providing confidentiality. However, in any case, 270 implementations MUST NOT allow the user to choose a stream cipher 271 or block mode cipher in counter mode for use with manual keys. 273 Encapsulation of ESP packet 274 IP encapsulation of ESP packets MUST be supported. For 275 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 277 If the automatic keying features of this specification are 278 implemented, the following additional IPsec capabilities are 279 required: 281 Group Security Policy Database (GSPD) 282 The implementation MUST support the GSPD that is described in RFC 283 5374 [RFC5374]. 285 Multiple Group Security Policy Databases 286 The implementation MUST support multiple GSPDs with a GSPD 287 selection function that provides an ability to choose a specific 288 GSPD based on interface. 290 Selectors 291 The implementation MUST be able to use source address, destination 292 address, protocol and direction as selectors in the GSPD. 294 7. Key Management 296 All the implementations MUST support manual configuration of the 297 Security Associations (SAs) that will be used to authenticate PIM-SM 298 link-local messages. This does not preclude the use of a negotiation 299 protocol such as the Group Domain Of Interpretation (GDOI) [RFC3547] 300 or Group Secure Association Key Management Protocol (GSAKMP) 301 [RFC4535] to establish these SAs. 303 7.1. Manual Key Management 305 To establish the SAs at PIM-SM routers, manual key configuration will 306 be feasible when the number of peers (directly connected routers) is 307 small. The Network Administrator will configure a router manually. 308 At that time, the authentication method and the choice of keys SHOULD 309 be configured. The parameters for the Security Association Database 310 (SAD) will be entered. The Network Administrator will also configure 311 the Security Policy Database of a router to ensure the use of the 312 associated SA while sending a link-local message. 314 7.2. Automated Key Management 316 All the link-local messages of the PIM-SM protocol are sent to the 317 destination address, ALL_PIM_ROUTERS, which is a multicast address. 318 By using the sender address in conjunction with the destination 319 address for Security Association lookup, link-local communication 320 turns into an SSM or "one to many" communication. 322 The procedures for automated key management are not specified in this 323 document. 325 One option is to use Group Domain Of Interpretation (GDOI) [RFC3547], 326 which enables a group of users or devices to exchange encrypted data 327 using IPsec data encryption. GDOI has been developed to be used in 328 multicast applications, where the number of end users or devices may 329 be large and the end users or devices can dynamically join/leave a 330 multicast group. However, a PIM router is not expected to join/leave 331 very frequently, and the number of routers is small when compared to 332 the possible number of users of a multicast application. Moreover, 333 most of the PIM routers will be located inside the same 334 administrative domain and are considered as trusted parties. It is 335 possible that a subset of GDOI functionalities will be sufficient. 337 Another option is to use the Group Secure Association Key Management 338 Protocol (GSAKMP) [RFC4535]. 340 7.3. Communications Patterns 342 Before discussing the set of security associations that are required 343 to properly manage a multicast region that is under the control of a 344 single administration, it is necessary to understand the 345 communications patterns that will exist among the routers in this 346 region. From the perspective of a speaking router, the information 347 from that router is sent (multicast) to all of its neighbors. From 348 the perspective of a listening router, the information coming from 349 each of its neighbors is distinct from the information coming from 350 every other router to which it is directly connected. Thus an 351 administrative region contains many (small) distinct groups, all of 352 which happen to be using the same multicast destination address 353 (e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is 354 centered on the associated speaking router. 356 Consider the example configuration as shown in Figure 1. 358 R2 R3 R4 R5 R6 359 | | | | | 360 | | | | | 361 --------- --------------- 362 | | 363 | | 364 \ / 365 R1 366 / \ 367 | | 368 | | 369 --------- -------------------- 370 | | | | | 371 | | | | | 372 R7 R8 R9 R10 R11 373 | | | | | 374 | 375 | 376 ------------- 377 | | | 378 | | | 379 R12 R13 R14 381 Figure 1: Set of router interconnections 383 In this configuration, router R1 has four interfaces, and is the 384 speaking router for a group whose listening routers are routers R2 385 through R11. Router R9 is the speaking router for a group whose 386 listening routers are routers R1, R8 and R10-R14. 388 From the perspective of R1 as a speaking router, if a Security 389 Association SA1 is assigned to protect outgoing packets from R1, then 390 it is necessary to distribute the key for this association to each of 391 the routers R2 through R11. Similarly, from the perspective of R9 as 392 a speaking router, if a Security Association is assigned to protect 393 the outgoing packets from R9, then it is necessary to distribute the 394 key for this association to each of the routers R1, R8, and R10 395 through R14. 397 From the perspective of R1 as a listening router, all packets 398 arriving from R2 through R11 need to be distinguished from each 399 other, to permit selecting the correct Security Association in the 400 SAD. (Packets from each of the peer routers (R2 through R11) 401 represent communication from a different speaker, with a separate 402 sequence number space, even though they are sent using the same 403 destination address.) For a multicast Security Association, RFC 4301 404 permits using the Source Address in the selection function. If the 405 source addresses used by routers R2 through R11 are globally unique, 406 then the source addresses of the peer routers are sufficient to 407 achieve the differentiation. If the sending routers use link-local 408 addresses, then these addresses are unique only on a per-interface 409 basis, and it is necessary to use the Interface ID tag as an 410 additional selector, i.e., either the selection function has to have 411 the Interface ID tag as one of its inputs, or separate SADs have to 412 be maintained for each interface. 414 If the assumption of connectivity to the key server can be made 415 (which is true in the PIM-SM case), then the Group Controller/Key 416 Server (GC/KS) that is used for the management of the keys can be 417 centrally located (and duplicated for reliability). If this 418 assumption cannot be made (i.e., in the case of adjacencies for a 419 unicast router), then some form of "local" key server must be 420 available for each group. Given that the listening routers are never 421 more than one hop away from the speaking router, the speaking router 422 is the obvious place to locate the "local" key server. As such, this 423 may be a useful approach even in the PIM-SM case. This approach has 424 the additional advantage that there is no need to duplicate the local 425 key server for reliability, since if the key server is down, it is 426 very likely that the speaking router is also down. 428 7.4. Neighbor Relationships 430 Each distinct group consists of one speaker, and the set of directly 431 connected listeners. If the decision is made to maintain one 432 Security Association per speaker (see Section 8), then the key server 433 will need to be aware of the adjacencies of each speaker. Procedures 434 for managing and distributing these adjacencies are out-of-scope for 435 this document. 437 8. Number of Security Associations 439 The number of Security Associations to be maintained by a PIM router 440 depends on the required security level and available key management. 441 This SHOULD be decided by the Network Administrator. Two different 442 ways are shown in Figure 2 and 3. It is assumed that A, B and C are 443 three PIM routers, where B and C are directly connected with A, and 444 there is no direct link between B and C. 446 | 447 +++++ | 448 + B + SAb ------------>| 449 + + SAa <------------| 450 +++++ | 451 | 452 +++++ SAb <------------| 453 + + ---->| 454 + + / 455 + A + SAa ------- 456 + + \ 457 + + ---->| 458 +++++ SAc <------------| 459 | 460 +++++ | 461 + C + SAc ------------>| 462 + + SAa <------------| 463 +++++ | 464 | 465 Directly connected network 467 Figure 2: Activate unique Security Association for each peer 469 The first method, shown in Figure 2, is OPTIONAL to implement. In 470 this method, each node will use a unique SA for its outbound traffic. 471 A, B, and C will use SAa, SAb, and SAc, respectively for sending any 472 traffic. Each node will include the source address when searching 473 the SAD for a match. A will use SAb and SAc for packets received 474 from B and C, respectively. The number of SAs to be activated and 475 maintained by a PIM router will be equal to the number of directly 476 connected routers, plus one for sending its own traffic. Also, the 477 addition of a PIM router in the network will require the addition of 478 another SA on every directly connected PIM router. This solution 479 will be scalable and practically feasible with an automated key 480 management protocol. However, it MAY be used with manual key 481 management, if the number of directly connected routers is small. 483 | 484 +++++ | 485 + B + SAo ------------>| 486 + + SAi <------------| 487 +++++ | 488 | 489 +++++ SAi <------------| 490 + + ---->| 491 + + / 492 + A + SAo ------- 493 + + \ 494 + + ---->| 495 +++++ SAi <------------| 496 | 497 +++++ | 498 + C + SAo ------------>| 499 + + SAi <------------| 500 +++++ | 501 | 502 Directly connected network 504 Figure 3: Activate two Security Associations 506 The second method, shown in Figure 3, MUST be supported by every 507 implementation. In this simple method, all the nodes will use two 508 SAs, one for sending (SAo) and the other for receiving (SAi) traffic. 509 Thus, the number of SAs is always two and will not be affected by 510 addition of a PIM router. Although two different SAs (i.e., SAo and 511 SAi) are used in this method, the SA parameters (keys, Security 512 Parameter Index (SPI), etc.) for the two SAs are identical, i.e., the 513 same information is shared among all the routers in an administrative 514 region. This document RECOMMENDS this second method for manual key 515 configuration. However, it MAY also be used with automated key 516 configuration. 518 9. Rekeying 520 Ananalysis of the considerations for key management is provided in 521 RFC 4107 [RFC4107]. 523 In PIM-SM deployments it is expected that secure sessions will be 524 relatively long-lived, and it is not expected that keys will be 525 significantly exposed through normal operational activity. Manual 526 keying is judged acceptable in the light of the relatively low rate 527 of change that is required. 529 To maintain the security of a link, the authentication and encryption 530 key values SHOULD be changed periodically, to limit the risk of 531 undetected key disclosure. Keys SHOULD also be changed when there is 532 a change of trusted personnel. 534 Manual keying offers the ability to change keys in a coordinated way, 535 but it has several drawback in PIM-SM systems. Some of these are 536 listed in Section 15 (Security Considerations) of this document. 538 According to an analysis in line with RFC 4107 [RFC4107], PIM-SM 539 would benefit from automated key management and roll over because all 540 the disadvantages of manual keys listed in Section 15 would be 541 eliminated. However, suitable techniques for automated key 542 management do not currently exist. Work is in hand in the IETF to 543 develop suitable solutions. In the mean time, implementations MUST 544 support manual rekeying as described below. Implementers and 545 deployers need to be aware of the requirement to upgrade to support 546 automated key management as soon as suitable techniques are 547 available. 549 9.1. Manual Rekeying Procedure 551 In accordance with the requirements of RFC 4107 [RFC4107], the 552 following three-step procedure provides a possible mechanism to rekey 553 the routers on a link without dropping PIM-SM protocol packets or 554 disrupting the adjacency, while ensuring that it is always clear 555 which key is being used. 557 1. For every router on the link, create an additional inbound SA for 558 the interface being rekeyed using a new SPI and the new key. 560 2. For every router on the link, replace the original outbound SA 561 with one using the new SPI and key values. The SA replacement 562 operation MUST be atomic with respect to sending PIM-SM packets 563 on the link, so that no PIM-SM packets are sent without 564 authentication/encryption 566 3. For every router on the link, remove the original inbound SA. 568 Note that all routers on the link MUST complete step 1 before any 569 begin step 2. Likewise, all the routers on the link MUST complete 570 step 2 before any begin step 3. 572 One way to control the progression from one step to another is for 573 each router to have a configurable time constant KeyRolloverInterval. 574 After the router begins step 1 on a given link, it waits for this 575 interval and then moves to step 2. Likewise, after moving to step 2, 576 it waits for this interval and then moves to step 3. 578 In order to achieve smooth key transition, all routers on a link MUST 579 use the same value for KeyRolloverInterval and MUST initiate the key 580 rollover process within this time period. 582 At the end of this time period, all the routers on the link will have 583 a single inbound and outbound SA for PIM-SM with the new SPI and key 584 values. 586 9.2. KeyRollover Interval 588 The configured value of KeyRolloverInterval needs to be long enough 589 to allow the administrator to change keys on all the PIM-SM routers. 590 As this value can vary significantly depending on the implementation 591 and the deployment, it is left to the administrator to choose an 592 appropriate value. 594 9.3. Rekeying Interval 596 In keeping with the goal of reducing key exposure, the encryption and 597 authentication keys SHOULD be changed at least every 90 days. 599 10. IPsec Protection Barrier and SPD/GSPD 601 10.1. Manual Keying 603 10.1.1. SAD Entries 605 The Administrator must configure the necessary Security Associations. 606 Each SA entry has the Source Address of an authorized peer, and a 607 Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the 608 manually configured SAs MUST be assigned by the Administrator, to 609 ensure that the SPI does not conflict with existing SPI values in the 610 SAD. 612 10.1.2. SPD Entries 614 The Administrator must configure the necessary SPD entries. The SPD 615 entry must ensure that any outbound IP traffic packet traversing the 616 IPsec boundary, with PIM as its next layer protocol, and sent to the 617 Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH. 618 Note that this characterization includes all the link-local messages 619 (Hello, Join/Prune, Bootstrap, Assert). 621 10.2. Automatic Keying 623 When automatic keying is used, the SA creation is done dynamically 624 using a group key management protocol. The GSPD and PAD tables are 625 configured by the Administrator. The PAD table provides the link 626 between the IPsec subsystem and the group key management protocol. 627 For automatic keying, the implementation MUST support the multicast 628 extensions described in [RFC5374]. 630 10.2.1. SAD Entries 632 All PIM routers participate in an authentication scheme that 633 identifies permitted neighbors and achieves peer authentication 634 during SA negotiation, leading to child SAs being established and 635 saved in the SAD. 637 10.2.2. GSPD Entries 639 The Administrator must configure the necessary GSPD entries for "send 640 only" directionality. This rule MUST trigger the group key 641 management protocol for a registration exchange. This exchange will 642 set up the outbound SAD entry that encrypts the multicast PIM control 643 message. Considering that this rule is "sender only", no inbound SA 644 is created in the reverse direction. 646 In addition, the registration exchange will trigger the installation 647 of the GSPD entries corresponding to each legitimate peer router, 648 with direction "receive only". Procedures for achieving the 649 registration exchange are out-of-scope for this document. 651 A router SHOULD NOT dynamically detect new neighbors as the result of 652 receiving an unauthenticated PIM-SM link-local message or an IPsec 653 packet that fails an SAD lookup. An automated key management 654 protocol SHOULD provide a means of notifying a router of new, 655 legitimate neighbors. 657 10.2.3. PAD Entries 659 The PAD will be configured with information to permit identification 660 of legitimate group members and senders (i.e., to control the 661 adjacency). Procedures for doing this are out-of-scope for this 662 document. 664 11. Security Association Lookup 666 For an SA that carries unicast traffic, three parameters (SPI, 667 destination address and security protocol type (AH or ESP)) are used 668 in the Security Association lookup process for inbound packets. The 669 SPI is sufficient to specify an SA. However, an implementation may 670 use the SPI in conjunction with the IPsec protocol type (AH or ESP) 671 for the SA lookup process. According to RFC 4301 [RFC4301], for 672 multicast SAs, in conjunction with the SPI, the destination address 673 or the destination address plus the sender address may also be used 674 in the SA lookup. This applies to both ESP and AH. The security 675 protocol field is not employed for a multicast SA lookup. 677 Given that, from the prospective of a receiving router, each peer 678 router is an independent sender and given that the destination 679 address will be the same for all senders, the receiving router MUST 680 use SPI plus destination address plus sender address when performing 681 the SA lookup. In effect, link-local communication is an SSM 682 communication that happens to use an ASM address (which is shared 683 among all the routers). 685 Given that it is always possible to distinguish a connection using 686 IPsec from a connection not using IPsec, it is recommended that the 687 address ALL_PIM_ROUTERS be used, to maintain consistency with present 688 practice. 690 Given that the sender address of an incoming packet may be only 691 locally unique (because of the use of link-local addresses), it is 692 necessary for a receiver to use the interface ID tag to determine the 693 associated SA for that sender. Therefore, this document mandates 694 that the interface ID tag, the SPI and the sender address MUST be 695 used in the SA lookup process. 697 12. Activating the Anti-replay Mechanism 699 Although link-level messages on a link constitute a multiple-sender, 700 multiple-receiver group, the use of the interface ID tag and sender 701 address for SA lookup essentially resolves the communication into a 702 separate SA for each sender/destination pair, even for the case where 703 only two SAs (with identical SA parameters) are used for the entire 704 administrative region. Therefore, the statement in the AH RFC 705 (section 2.5 of [RFC4302]) that "for a multi-sender SA, the anti- 706 replay features are not available" becomes irrelevant to the PIM-SM 707 link-local message exchange. 709 To activate the anti-replay mechanism in a unicast communication, the 710 receiver uses the sliding window protocol and it maintains a sequence 711 number for this protocol. This sequence number starts from zero. 712 Each time the sender sends a new packet, it increments this number by 713 one. In a multi-sender multicast group communication, a single 714 sequence number for the entire group would not be enough. 716 The whole scenario is different for PIM link-local messages. These 717 messages are sent to local links with TTL = 1. A link-local message 718 never propagates through one router to another. The use of the 719 sender address and the interface ID tag for SA lookup converts the 720 relationship from a multiple-sender group to multiple single-sender 721 associations. This specification RECOMMENDS activation of the anti- 722 replay mechanism only if the SAs are assigned using an automated key 723 management procedure. If manual key management is used, the anti- 724 replay SHOULD NOT be activated. 726 If an existing router has to restart, in accordance with RFC 4303 727 [RFC4303], the sequence number counter at the sender MUST be 728 correctly maintained across local reboots, etc., until the key is 729 replaced. 731 13. Implementing a Security Policy Database per Interface 733 RFC 4601 suggests that it may be desirable to implement a separate 734 Security Policy Database (SPD) for each router interface. The use of 735 link-local addresses in certain circumstances implies that 736 differentiation of ambiguous speaker addresses requires the use of 737 the interface ID tag in the SA lookup. One way to do this is through 738 the use of multiple SPDs. Alternatively, the interface ID tag may be 739 a specific component of the selector algorithm. This is in 740 conformance with RFC 4301, which explicitly removes the requirement 741 for separate SPDs that was present in RFC 2401 [RFC2401]. 743 14. Extended Sequence Number 745 In the [RFC4302], there is a provision for a 64-bit Extended Sequence 746 Number (ESN) as the counter of the sliding window used in the anti- 747 replay protocol. Both the sender and the receiver maintain a 64-bit 748 counter for the sequence number, although only the lower order 32 749 bits are sent in the transmission. In other words, it will not 750 affect the present header format of AH. If ESN is used, a sender 751 router can send 2^64 -1 packets without any intervention. This 752 number is very large, and from a PIM router's point of view, a PIM 753 router can never exceed this number in its lifetime. This makes it 754 reasonable to permit manual configuration for a small number of PIM 755 routers, since the sequence number will never roll over. For this 756 reason, when manual configuration is used, ESN SHOULD be deployed as 757 the sequence number for the sliding window protocol. In addition, 758 when an ESN is used with a manually-keyed SA, it MUST be saved over a 759 reboot, along with an indication of which sequence numbers have been 760 used. 762 15. Security Considerations 764 The whole document considers the security issues of PIM link-local 765 messages and proposes a mechanism to protect them. 767 Limitations of manual keys: 769 The following are some of the known limitations of the usage of 770 manual keys. 772 o If replay protection cannot be provided, the PIM routers will not 773 be secured against all the attacks that can be performed by 774 replaying PIM packets. 776 o Manual keys are usually long lived (changing them often is a 777 tedious task). This gives an attacker enough time to discover the 778 keys. 780 o As the administrator is manually configuring the keys, there is a 781 chance that the configured keys are weak (there are known weak 782 keys for DES/3DES at least). 784 Impersonation attacks: 786 The usage of the same key on all the PIM routers connected to a link 787 leaves them all insecure against impersonation attacks if any one of 788 the PIM routers is compromised, malfunctioning, or misconfigured. 790 Detailed analysis of various vulnerabilities of routing protocols is 791 provided in RFC 4593 [RFC4593]. For further discussion of PIM-SM and 792 multicast security the reader is referred to RFC 5294 [RFC5294], RFC 793 4609 [RFC4609] and the Security Considerations section of RFC 4601 794 [RFC4601]. 796 16. IANA Considerations 798 This document has no actions for IANA. 800 17. Acknowledgements 802 The structure and text of this document draw heavily from RFC 4552 803 [RFC4552]. The authors of this document thank M. Gupta and N. Melam 804 for permisison to do this. 806 The quality of this document was substiantially improved after SECDIR 807 pre-review by Brian Weis, and after AD review by Adrian Farrel. 809 18. References 811 18.1. Normative References 813 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 814 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 815 Protocol Specification (Revised)", RFC 4601, August 2006. 817 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 818 December 2005. 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, March 1997. 823 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 824 Internet Protocol", RFC 4301, December 2005. 826 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 827 RFC 4303, December 2005. 829 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 830 Requirements for Encapsulating Security Payload (ESP) and 831 Authentication Header (AH)", RFC 4835, April 2007. 833 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 834 Extensions to the Security Architecture for the Internet 835 Protocol", RFC 5374, November 2008. 837 18.2. Informative References 839 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 840 Internet Protocol", RFC 2401, November 1998. 842 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 843 "GSAKMP: Group Secure Association Key Management 844 Protocol", RFC 4535, June 2006. 846 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 847 Group Domain of Interpretation", RFC 3547, July 2003. 849 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 850 Routing Protocols", RFC 4593, October 2006. 852 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 853 Independent Multicast (PIM)", RFC 5294, August 2008. 855 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 856 Independent Multicast - Sparse Mode (PIM-SM) Multicast 857 Routing Security Issues and Enhancements", RFC 4609, 858 October 2006. 860 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 861 for OSPFv3", RFC 4552, June 2006. 863 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 864 Key Management", BCP 107, RFC 4107, June 2005. 866 Authors' Addresses 868 J. William Atwood 869 Concordia University/CSE 870 1455 de Maisonneuve Blvd, West 871 Montreal, QC H3G 1M8 872 Canada 874 Phone: +1(514)848-2424 ext3046 875 Email: bill@cse.concordia.ca 876 URI: http://users.encs.concordia.ca/~bill 878 Salekul Islam 879 INRS Energie, Materiaux et Telecommunications 880 800, de La Gauchetiere, suite 800 881 Montreal, QC H5A 1K6 882 Canada 884 Email: Salekul.Islam@emt.inrs.ca 885 URI: http://users.encs.concordia.ca/~salek_is 887 Maziar Siami 888 Concordia University/CIISE 889 1455 de Maisonneuve Blvd, West 890 Montreal, QC H3G 1M8 891 Canada 893 Email: m_siamis@ciise.concordia.ca