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