idnits 2.17.1 draft-ietf-pim-sm-linklocal-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 916. 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 (Using the creation date from RFC4601, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 03, 2008) is 5651 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: 'IslamThesis' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'IslamLCN2004' is defined on line 810, but no explicit reference was found in the text ** 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 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-02 Summary: 3 errors (**), 0 flaws (~~), 4 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 Concordia University/CSE 4 Updates: 4601 (if approved) S. Islam 5 Intended status: Standards Track INRS Energie, Materiaux et 6 Expires: May 7, 2009 Telecommunications 7 M. Siami 8 Concordia University/CIISE 9 November 03, 2008 11 Authentication and Confidentiality in PIM-SM Link-local Messages 12 draft-ietf-pim-sm-linklocal-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 7, 2009. 39 Abstract 41 RFC 4601 mandates the use of IPsec to ensure authentication of the 42 link-local messages in the Protocol Independent Multicast - Sparse 43 Mode (PIM-SM) routing protocol. This document specifies mechanisms 44 to authenticate the PIM-SM link local messages using the IP security 45 (IPsec) Authentication Header (AH) or Encapsulating Security Payload 46 (ESP). It specifies optional mechanisms to provide confidentiality 47 using the ESP. Manual keying is specified as the mandatory and 48 default group key management solution. To deal with issues of 49 scalability and security that exist with manual keying, an optional 50 automated group key management mechanism is specified. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Transport Mode vs. Tunnel Mode . . . . . . . . . . . . . . . . 7 57 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 9 59 6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . . 10 60 7. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7.1. Manual Key Management . . . . . . . . . . . . . . . . . . 11 62 7.2. Automated Key Management . . . . . . . . . . . . . . . . . 11 63 7.3. Communications Patterns . . . . . . . . . . . . . . . . . 12 64 7.4. Neighbor Relationships . . . . . . . . . . . . . . . . . . 13 65 8. Number of Security Associations . . . . . . . . . . . . . . . 14 66 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 9.1. Rekeying Procedure . . . . . . . . . . . . . . . . . . . . 16 68 9.2. KeyRollover Interval . . . . . . . . . . . . . . . . . . . 16 69 9.3. Rekeying Interval . . . . . . . . . . . . . . . . . . . . 17 70 10. IPsec Protection Barrier and GSPD . . . . . . . . . . . . . . 18 71 10.1. Manual Keying . . . . . . . . . . . . . . . . . . . . . . 18 72 10.1.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 18 73 10.1.2. SPD Entries . . . . . . . . . . . . . . . . . . . . . 18 74 10.2. Automatic Keying . . . . . . . . . . . . . . . . . . . . . 18 75 10.2.1. SAD Entries . . . . . . . . . . . . . . . . . . . . . 18 76 10.2.2. GSPD Entries . . . . . . . . . . . . . . . . . . . . 18 77 10.2.3. PAD Entries . . . . . . . . . . . . . . . . . . . . . 19 78 11. Security Association Lookup . . . . . . . . . . . . . . . . . 20 79 12. Activating the Anti-replay Mechanism . . . . . . . . . . . . . 21 80 13. Implementing a Security Association Database per Interface . . 23 81 14. Extended Sequence Number . . . . . . . . . . . . . . . . . . . 24 82 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 83 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 84 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 17.1. Normative References . . . . . . . . . . . . . . . . . . . 27 86 17.2. Informative References . . . . . . . . . . . . . . . . . . 27 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 88 Intellectual Property and Copyright Statements . . . . . . . . . . 30 90 1. Introduction 92 All the PIM-SM [RFC4601] control messages have IP protocol number 93 103. These messages are either unicast, or multicast with TTL = 1. 94 The source address used for unicast messages is a domain-wide 95 reachable address. For the multicast messages, a link-local address 96 of the interface on which the message is being sent is used as the 97 source address and a special multicast address, ALL_PIM_ROUTERS 98 (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination 99 address. These messages are called link-local messages. Hello, 100 Join/Prune and Assert messages are included in this category. A 101 forged link-local message may be sent to the ALL_PIM_ROUTERS 102 multicast address by an attacker. This type of message affects the 103 construction of the distribution tree [RFC4601]. The effects of 104 these forged messages are outlined in section 6.1 of [RFC4601]. Some 105 of the effects are very severe, whereas some are minor. 107 PIM-SM version 2 was originally specified in RFC 2117, and revised in 108 RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a 109 number of deficiencies. The Security Considerations section of RFC 110 4601 is based primarily on the new Authentication Header (AH) 111 specification described in RFC 4302 [RFC4302]. 113 Securing the unicast messages can be achieved by the use of a normal 114 unicast IPsec Security Association between the two communicants. 115 Securing the user data exchanges is covered in RFC 3740 [RFC3740]. 117 This document focuses on the security issues for link-local messages. 118 It provides some guidelines to take advantage of the new permitted AH 119 functionality in RFC 4302 and the new permitted ESP functionality in 120 RFC 4303, and to bring the PIM-SM specification into alignment with 121 the new AH and ESP specifications. This document recommends manual 122 key management as mandatory to implement, i.e., that all 123 implementations MUST support, and provides the necessary structure 124 for an automated key management protocol that the PIM routers may 125 use. 127 The primary goal for link-local security is to provide data origin 128 authentication for each link-local message. A secondary goal is to 129 ensure that communication only happens between legitimate peers 130 (i.e., adjacent routers). An optional goal is to provide data 131 confidentiality for the link-local messages. 133 The first goal implies that each router has a unique identity. It is 134 likely (but not mandatory) that this identity will be based on the 135 unicast identity of the router. (The unicast identity could be, for 136 example, based on some individually-configured property of the 137 router, or be part of a region-wide public key infrastructure.) The 138 existence of this identity is assumed in this specification, but 139 procedures for establishing it are out-of-scope for this document. 141 The second goal implies that there is some form of "adjacency matrix" 142 that controls the establishment of security associations among 143 adjacent multicast routers. For manual keying, this control will be 144 exercised by the Administrator of the router(s), through the setting 145 of initialization parameters. For automated keying, the existence of 146 this control will be reflected by the contents of the Group Security 147 Policy Database (GSPD) in each router. Procedures for building this 148 GSPD are out-of-scope for this document. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 They indicate requirement levels for compliant PIM-SM 156 implementations. 158 3. Transport Mode vs. Tunnel Mode 160 The transport mode Security Association (SA) is generally used 161 between two hosts or routers/gateways when they are acting as hosts. 162 The SA must be a tunnel mode SA if either end of the security 163 association is a router/gateway. Two hosts MAY establish a tunnel 164 mode SA between themselves. PIM-SM link-local messages are exchanged 165 between routers. However, since the packets are locally delivered, 166 the routers assume the role of hosts in the context of the tunnel 167 mode SA. All implementations conforming to this specification MUST 168 support transport mode SA to provide required IPsec security to 169 PIM-SM link-local messages. They MAY also support tunnel mode SA to 170 provide required IPsec security to PIM-SM link-local messages. 172 4. Authentication 174 Implementations conforming to this specification MUST support 175 authentication for PIM-SM link-local messages. 177 In order to provide authentication to PIM-SM link-local messages, 178 implementations MUST support ESP [RFC4303] and MAY support AH 179 [RFC4302]. 181 If ESP in transport mode is used, it will only provide authentication 182 to PIM-SM protocol packets excluding the IPv6 header, extension 183 headers, and options. (Note: The IPv4 exclusions need to be listed 184 here as well.) 186 If AH in transport mode is used, it will provide authentication to 187 PIM-SM protocol packets, selected portions of the IPv6 header, 188 extension headers and options. (Note: the IPv4 coverage needs to be 189 listed here as well.) 191 When authentication for PIM-SM link-local messages is enabled, 193 o PIM-SM link-local packets that are not protected with AH or ESP 194 MUST be silently discarded. 196 o PIM-SM link-local packets that fail the authentication checks MUST 197 be silently discarded. 199 5. Confidentiality 201 Implementations conforming to this specification SHOULD support 202 confidentiality for PIM-SM. 204 If confidentiality is provided, ESP MUST be used. 206 When PIM-SM confidentiality is enabled, 208 o PIM-SM packets that are not protected with ESP MUST be silently 209 discarded. 211 o PIM-SM packets that fail the confidentiality checks MUST be 212 silently discarded. 214 6. IPsec Requirements 216 In order to implement this specification, the following IPsec 217 capabilities are required. 219 Transport mode 220 IPsec in transport mode MUST be supported. 222 Multiple Security Policy Databases (SPDs) 223 The implementation MUST support multiple SPDs with an SPD 224 selection function that provides an ability to choose a specific 225 SPD based on interface. 227 Selectors 228 The implementation MUST be able to use source address, destination 229 address, protocol, and direction as selectors in the SPD. 231 Interface ID tagging 232 The implementation MUST be able to tag the inbound packets with 233 the ID of the interface (physical or virtual) via which it 234 arrived. 236 Manual key support 237 Manually configured keys MUST be able to secure the specified 238 traffic. 240 Encryption and authentication algorithms 241 The implementation MUST NOT allow the user to choose stream 242 ciphers as the encryption algorithm for securing PIM-SM packets 243 since the stream ciphers are not suitable for manual keys. Except 244 when in conflict with the above statement, the key words "MUST", 245 "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that appear in 246 RFC 4835 [RFC4835] for algorithms to be supported are to be 247 interpreted as described in RFC 2119 [RFC2119] for PIM-SM support 248 as well. 250 Encapsulation of ESP packet 251 IP encapsulation of ESP packets MUST be supported. For 252 simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 254 7. Key Management 256 All the implementations MUST support manual configuration of the SAs 257 that will be used to authenticate PIM-SM link-local messages. This 258 does not preclude the use of a negotiation protocol such as the 259 Internet Key Exchange (IKE) [RFC4306] or Group Secure Association Key 260 Management Protocol (GSAKMP) [RFC4535] to establish SAs. 262 7.1. Manual Key Management 264 To establish the SAs at PIM-SM routers, manual key configuration will 265 be feasible when the number of peers (directly connected routers) is 266 small. The Network Administrator will configure a router manually 267 during its boot up process. At that time, the authentication method 268 and the choice of keys SHOULD be configured. The SAD entry will be 269 created. The Network Administrator will also configure the Security 270 Policy Database of a router to ensure the use of the associated SA 271 while sending a link-local message. 273 7.2. Automated Key Management 275 All the link-local messages of the PIM-SM protocol are sent to the 276 destination address, ALL_PIM_ROUTERS, which is a multicast address. 277 By using the sender address in conjunction with the destination 278 address for Security Association lookup, link-local communication 279 turns to an SSM or "one to many" communication. Since IKE is based 280 on the Diffie-Hellman key agreement protocol and works only for two 281 communicating parties, it is not possible to use IKE for providing 282 the required "one to many" authentication. 284 One option is to use Group Domain Of Interpretation (GDOI) [RFC3547], 285 which enables a group of users or devices to exchange encrypted data 286 using IPsec data encryption. GDOI has been developed to be used in 287 multicast applications, where the number of end users or devices may 288 be large and the end users or devices can dynamically join/leave a 289 multicast group. However, a PIM router is not expected to join/leave 290 very frequently, and the number of routers is small when compared to 291 the possible number of users of a multicast application. Moreover, 292 most of the PIM routers will be located inside the same 293 administrative domain and are considered as trusted parties. It is 294 possible that a subset of GDOI functionalities will be sufficient. 296 A framework for automating key management for RSVP is given in 297 [I-D.ietf-tsvwg-rsvp-security-groupkeying]. A companion modification 298 for GDOI is presented in [I-D.weis-gdoi-for-rsvp]. 300 Another option is to use the Group Secure Association Key Management 301 Protocol (GSAKMP) [RFC4535]. 303 7.3. Communications Patterns 305 Before discussing the set of security associations that are required 306 to properly manage a multicast region that is under the control of a 307 single administration, it is necessary to understand the 308 communications patterns that will exist among the routers in this 309 region. From the perspective of a speaking router, the information 310 from that router is sent (multicast) to all of its neighbors. From 311 the perspective of a listening router, the information coming from 312 each of its neighbors is distinct from the information coming from 313 every other router to which it is directly connected. Thus an 314 administrative region contains many (small) distinct groups, all of 315 which happen to be using the same multicast destination address 316 (e.g., ALL_PIM_ROUTERS, see Section 11), and each of which is 317 centered on the associated speaking router. 319 Consider the example configuration as shown in Figure 1. 321 R2 R3 R4 R5 R6 322 | | | | | 323 | | | | | 324 --------- --------------- 325 | | 326 | | 327 \ / 328 R1 329 / \ 330 | | 331 | | 332 --------- -------------------- 333 | | | | | 334 | | | | | 335 R7 R8 R9 R10 R11 336 | | | | | 337 | 338 | 339 ------------- 340 | | | 341 | | | 342 R12 R13 R14 344 Figure 1: Set of router interconnections 346 In this configuration, router R1 has four interfaces, and is the 347 speaking router for a group whose listening routers are routers R2 348 through R11. Router R9 is the speaking router for a group whose 349 listening routers are routers R1, R8 and R10-R14. 351 From the perspective of R1 as a speaking router, if a Security 352 Association SA1 is assigned to protect outgoing packets from R1, then 353 it is necessary to distribute the key for this association to each of 354 the routers R2 through R11. Similarly, from the perspective of R9 as 355 a speaking router, if a Security Association is assigned to protect 356 the outgoing packets from R9, then it is necessary to distribute the 357 key for this association to each of the routers R1, R8, and R10 358 through R14. 360 From the perspective of R1 as a listening router, all packets 361 arriving from R2 through R11 need to be distinguished from each 362 other, to permit selecting the correct Security Association in the 363 SAD. (Packets from each of the peer routers (R2 through R11) 364 represent communication from a different speaker, even though they 365 are sent using the same destination address.) For a multicast 366 Security Association, RFC 4301 permits using the Source Address in 367 the selection function. If the source addresses used by routers R2 368 through R11 are globally unique, then the source addresses of the 369 peer routers are sufficient to achieve the differentiation. If the 370 sending routers use link-local addresses, then these addresses are 371 unique only on a per-interface basis, and it is necessary to use the 372 Interface ID tag as an additional selector, i.e., either the 373 selection function has to have the Interface ID tag as one of its 374 inputs, or separate SADs have to be maintained for each interface. 376 If the assumption of connectivity to the key server can be made 377 (which is true in the PIM-SM case), then the GC/KS can be centrally 378 located (and duplicated for reliability). If this assumption cannot 379 be made (i.e., in the case of adjacencies for a unicast router), then 380 some form of "local" key server must be available for each group. 381 Given that the listening routers are never more than one hop away 382 from the speaking router, the speaking router is the obvious place to 383 locate the "local" key server. This has the additional advantage 384 that there is no need to duplicate the local key server for 385 reliability, since if the key server is down, it is very likely that 386 the speaking router is also down. 388 7.4. Neighbor Relationships 390 Each distinct group consists of one speaker, and the set of directly 391 connected listeners. If the decision is made to maintain one 392 Security Association per speaker (see Section 8), then the key server 393 will need to be aware of the adjacencies of each speaker. Procedures 394 for doing this are out-of-scope for this document. 396 8. Number of Security Associations 398 The number of Security Associations to be maintained by a PIM router 399 depends on the required security level and available key management. 400 This SHOULD be decided by the Network Administrator. Two different 401 ways are shown in Figure 2 and 3. It is assumed that A, B and C are 402 three PIM routers, where B and C are directly connected with A, and 403 there is no direct link between B and C. 405 | 406 B | 407 SAb ------------>| 408 SAa <------------| 409 | 410 A | 411 SAb <------------| 412 SAa ------------>| 413 SAc <------------| 414 | 415 C | 416 SAc ------------>| 417 SAa <------------| 418 | 419 Directly connected network 421 Figure 2: Activate unique Security Association for each peer 423 The first method, shown in Figure 2 is OPTIONAL to implement. In 424 this method, each node will use a unique SA for its outbound traffic. 425 A, B, and C will use SAa, SAb, and SAc, respectively for sending any 426 traffic. Each node will look up the SA to be used based on the 427 source address. A will use SAb and SAc for packets received from B 428 and C, respectively. The number of SAs to be activated and 429 maintained by a PIM router will be equal to the number of directly 430 connected routers plus one, for sending its own traffic. Also, the 431 addition of a PIM router in the network will require the addition of 432 another SA on every directly connected PIM router. This solution 433 will be scalable and practically feasible with an automated key 434 management protocol. However, it MAY be used with manual key 435 management, if the number of directly connected router(s) is small. 437 B | 438 SAo ------------>| 439 SAi <------------| 440 | 441 A | 442 SAo ------------>| 443 SAi <------------| 444 | 445 C | 446 SAo ------------>| 447 SAi <------------| 448 | 449 Directly connected network 451 Figure 3: Activate two Security Associations 453 The second method, shown in Figure 3, MUST be supported by every 454 implementation. In this simple method, all the nodes will use two 455 SAs, one for sending (SAo) and the other for receiving (SAi) traffic. 456 Thus, the number of SAs is always two and will not be affected by 457 addition of a PIM router. Although two different SAs are used in 458 this method, the SA parameters (keys, SPI, etc.) for the two SAs are 459 identical, i.e., the same information is shared among all the routers 460 in an administrative region. This document RECOMMENDS the above 461 method for manual key configuration. However, it MAY also be used 462 with automated key configuration. When manually configured, the 463 method suffers from impersonation attacks as mentioned in the 464 Security Considerations section. 466 9. Rekeying 468 To maintain the security of a link, the authentication and encryption 469 key values SHOULD be changed periodically. 471 9.1. Rekeying Procedure 473 The following three-step procedure SHOULD be provided to rekey the 474 routers on a link without dropping PIM-SM protocol packets or 475 disrupting the adjacency. 477 1. For every router on the link, create an additional inbound SA for 478 the interface being rekeyed using a new SPI and the new key. 480 2. For every router on the link, replace the original outbound SA 481 with one using the new SPI and key values. The SA replacement 482 operation should be atomic with respect to sending PIM-SM packets 483 on the link, so that no PIM-SM packets are sent without 484 authentication/encryption 486 3. For every router on the link, remove the original inbound SA. 488 Note that all routers on the link must complete step 1 before any 489 begin step 2. Likewise, all the routers on the link must complete 490 step 2 before any begin step 3. 492 One way to control the progression from one step to another is for 493 each router to have a configurable time constant KeyRolloverInterval. 494 After the router begins step 1 on a given link, it waits for this 495 interval and then moves to step 2. Likewise, after moving to step 2, 496 it waits for this interval and then moves to step 3. 498 In order to achieve smooth key transition, all routers on a link 499 should use the same value for KeyRolloverInterval and should initiate 500 the key rollover process within this time period. 502 At the end of this time period, all the routers on the link will have 503 a single inbound and outbound SA for PIM-SM with the new SPI and key 504 values. 506 9.2. KeyRollover Interval 508 The configured value of KeyRolloverInterval should be long enough to 509 allow the administrator to change keys on all the PIM-SM routers. As 510 this value can vary significantly depending on the implementation and 511 the deployment, it is left to the administrator to choose an 512 appropriate value. 514 9.3. Rekeying Interval 516 This section analyzes the security provided by manual keying and 517 recommends that the encryption and authentication keys SHOULD be 518 changed at least every 90 days. 520 The weakest security provided by the security mechanisms discussed in 521 this specification is when NULL encryption (for ESP) or no encryption 522 (for AH) is used with the HMAC-MD5 authentication. Any other 523 algorithm combinations will be at least as hard to break as the ones 524 mentioned above. This is shown by the following reasonable 525 assumptions: 527 o NULL Encryption and HMAC-SHA-1 Authentication will be more secure 528 as HMAC-SHA-1 is considered to be more secure than HMAC-MD5. 530 o NON-NULL Encryption and NULL Authentication combination is not 531 applicable as this specification mandates authentication when 532 PIM-SM security is enabled. 534 o Data Encryption Security (DES) Encryption and HMAC-MD5 535 Authentication will be more secure because of the additional 536 security provided by DES. 538 o Other encryption algorithms such as 3DES and the Advanced 539 Encryption Standard (AES) will be more secure than DES. 541 RFC 3562 [RFC3562] analyzes the rekeying requirements for the TCP MD5 542 signature option. The analysis provided in RFC 3562 is also 543 applicable to this specification as the analysis is independent of 544 data patterns. 546 10. IPsec Protection Barrier and GSPD 548 10.1. Manual Keying 550 10.1.1. SAD Entries 552 The Administrator must configure the necessary Security Associations. 553 Each SA entry has the Source Address of an authorized peer, and a 554 Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the 555 manually configured SAs MUST be assigned by the Administrator, to 556 ensure that the SPI does not conflict with existing SPI values in the 557 SAD. 559 10.1.2. SPD Entries 561 The Administrator must configure the necessary SPD entries. The SPD 562 entry must ensure that any outbound IP traffic packet traversing the 563 IPsec boundary, with PIM as its next layer protocol, PIM message type 564 of Hello, Join/Prune, bootstrap or Assert, sent to the Destination 565 Address of ALL_PIM_ROUTERS, is protected by AH. If the IPsec 566 implementation does not identify PIM message types as a selector, the 567 "local port" selector can be used, with suitable adjustment. 569 10.2. Automatic Keying 571 When automatic keying is used, the SA creation is done dynamically 572 using a group key management protocol. The GSPD and PAD tables are 573 configured by the Administrator. The PAD table provides the link 574 between the IPsec subsystem and the group key management protocol. 575 For automatic keying, the implementation MUST support the multicast 576 extensions described in [I-D.ietf-msec-ipsec-extensions]. 578 10.2.1. SAD Entries 580 All PIM routers participate in an authentication scheme that 581 identifies permitted neighbors and achieves peer authentication 582 during SA negotiation, leading to child SAs being established and 583 saved in the SAD. 585 10.2.2. GSPD Entries 587 The Administrator must configure the necessary GSPD entries for "send 588 only" directionality. This rule MUST trigger the group key 589 management protocol for a registration exchange. This exchange will 590 set up the outbound SAD entry that encrypts the multicast PIM control 591 message. Considering that this rule is "sender only", no inbound SA 592 is created in the reverse direction. 594 In addition, the registration exchange will install GSPD entries 595 corresponding to each legitimate peer router, with direction "receive 596 only". 598 To account for new, legitimate neighbors, the Administrator MUST 599 configure a GSPD entry for "any" peer router, destined to the 600 ALL_PIM_ROUTERS address. This entry will trigger a query to the 601 group key management protocol, to establish the legitimacy (or lack 602 of it) of the new peer, and install the necessary SAD "receive only" 603 entry. 605 10.2.3. PAD Entries 607 The PAD will be configured with information to permit identification 608 of legitimate group members and senders. Procedures for doing this 609 are out-of-scope for this document. 611 11. Security Association Lookup 613 For an SA that carries unicast traffic, three parameters (SPI, 614 destination address and security protocol type (AH or ESP)) are used 615 in the Security Association lookup process for inbound packets. The 616 SPI is sufficient to specify an SA. However, an implementation may 617 use the SPI in conjunction with the IPsec protocol type (AH or ESP) 618 for the SA lookup process. According to RFC 4301 [RFC4301] and the 619 AH specification [RFC4302], for multicast SAs, in conjunction with 620 the SPI, the destination address or the destination address plus the 621 sender address may also be used in the SA lookup. The security 622 protocol field is not employed for a multicast SA lookup. 624 The reason for the various prohibitions in the IPsec RFCs concerning 625 multisender multicast SAs lies in the difficulty of coordinating the 626 multiple senders. However, if the use of multicast for link-local 627 messages is examined, it may be seen that in fact the communication 628 need not be coordinated---from the prospective of a receiving router, 629 each peer router is an independent sender. In effect, link-local 630 communication is an SSM communication that happens to use an ASM 631 address (which is shared among all the routers). 633 Given that it is always possible to distinguish a connection using 634 IPsec from a connection not using IPsec, it is recommended that the 635 address ALL_PIM_ROUTERS be used, to maintain consistency with present 636 practice. 638 Given that the sender address of an incoming packet may be only 639 locally unique (because of the use of link-local addresses), it will 640 be necessary for a receiver to use the interface ID tag to sort out 641 the associated SA for that sender. Therefore, this document mandates 642 that the interface ID tag, the SPI and the sender address MUST be 643 used in the SA lookup process. 645 12. Activating the Anti-replay Mechanism 647 Although link-level messages on a link constitute a multiple-sender, 648 multiple-receiver group, the use of the interface ID tag and sender 649 address for SA lookup essentially resolves the communication into a 650 separate SA for each sender/destination pair, even for the case where 651 only two SAs (with identical SA parameters) are used for the entire 652 administrative region. Therefore, the statement in the AH RFC 653 (section 2.5 of [RFC4302]) that "for a multi-sender SA, the anti- 654 replay features are not available" becomes irrelevant to the PIM-SM 655 link-local message exchange. 657 To activate the anti-replay mechanism in a unicast communication, the 658 receiver uses the sliding window protocol and it maintains a sequence 659 number for this protocol. This sequence number starts from zero. 660 Each time the sender sends a new packet, it increments this number by 661 one. In a multi-sender multicast group communication, a single 662 sequence number for the entire group would not be enough. 664 The whole scenario is different for PIM link-local messages. These 665 messages are sent to local links with TTL = 1. A link-local message 666 never propagates through one router to another. The use of the 667 sender address and the interface ID tag for SA lookup converts the 668 relationship from a multiple-sender group to multiple single-sender 669 associations. This specification RECOMMENDS activation of the anti- 670 replay mechanism only if the SAs are assigned using an automated key 671 management procedure. In manual key management, the anti-replay 672 SHOULD NOT be activated. If the number of router(s) to be assigned 673 manually is small, the Network Administrator MAY consider to activate 674 anti-replay. If anti-replay is activated a PIM router MUST maintain 675 a different sliding window for each directly connected sender. 677 If the SAs are activated according to Figure 3, that is all the nodes 678 use only two SAs, one SA for sending and the other is for receiving 679 traffic, a PIM router MAY still activate the anti-replay mechanism. 680 Instead of maintaining only two SAs, the router will maintain the 681 same number of SAs as explained in the first method (see Figure 2) 682 (because of the differentiation based on sender address). For each 683 active SA a corresponding sequence number MUST be maintained. Thus, 684 a PIM router will maintain a number of identical SAs, except that the 685 sender address, interface ID tag and the sequence number are 686 different for each SA. In this way a PIM router will be at least 687 free from all the attacks that can be performed by replaying PIM-SM 688 packets. 690 Note that when activating anti-replay with manual key configuration, 691 the following actions must be taken by the network administrator: 693 a. If a new router is added, the Network Administrator MUST add a 694 new SA entry in each peer router. 696 b. If an existing router has to restart, the Network Administrator 697 MUST refresh the counter (ESN, see Section 14) to zero for all 698 the peer routers. This implies deleting all the existing SAs and 699 adding a new SA with the same configuration and a re-initialized 700 counter. 702 13. Implementing a Security Association Database per Interface 704 RFC 4601 suggests that it may be desirable to implement a separate 705 Security Association Database (SAD) for each router interface. The 706 use of link-local addresses in certain circumstances implies that 707 differentiation of ambiguous speaker addresses requires the use of 708 the interface ID tag in the SA lookup. One way to do this is through 709 the use of multiple SADs. Alternatively, the interface ID tag may be 710 a specific component of the selector algorithm. This is in 711 conformance with RFC 4301, which explicitly removes the requirement 712 for separate SADs that was present in RFC 2401 [RFC2401]. 714 14. Extended Sequence Number 716 In the [RFC4302], there is a provision for a 64-bit Extended Sequence 717 Number (ESN) as the counter of the sliding window used in the anti- 718 replay protocol. Both the sender and the receiver maintain a 64-bit 719 counter for the sequence number, although only the lower order 32 720 bits is sent in the transmission. In other words, it will not affect 721 the present header format of AH. If ESN is used, a sender router can 722 send 2^64 -1 packets without any intervention. This number is very 723 large, and from a PIM router's point of view, a PIM router can never 724 exceed this number in its lifetime. This makes it reasonable to 725 permit manual configuration for a small number of PIM routers, since 726 the sequence number will never roll over. For this reason, when 727 manual configuration is used, ESN SHOULD be deployed as the sequence 728 number for the sliding window protocol. 730 15. Security Considerations 732 The whole document considers the security issues of PIM link-local 733 messages and proposes a mechanism to protect them. 735 Limitations of manual keys: 737 The following are some of the known limitations of the usage of 738 manual keys. 740 o If replay protection cannot be provided, the PIM routers will not 741 be secured against all the attacks that can be performed by 742 replaying PIM packets. 744 o Manual keys are usually long lived (changing them often is a 745 tedious task). This gives an attacker enough time to discover the 746 keys. 748 o As the administrator is manually configuring the keys, there is a 749 chance that the configured keys are weak (there are known weak 750 keys for DES/3DES at least). 752 Impersonation attacks: 754 The usage of the same key on all the PIM routers connected to a link 755 leaves them all insecure against impersonation attacks if any one of 756 the PIM routers is compromised, malfunctioning, or misconfigured. 758 Detailed analysis of various vulnerabilities of routing protocols is 759 provided in RFC 4593 [RFC4593]. For further discussion of PIM-SM and 760 multicast security the reader is referred to RFC 5294 [RFC5294], RFC 761 4609 [RFC4609] and the Security Considerations section of RFC 4601 762 [RFC4601]. 764 16. IANA Considerations 766 This document has no actions for IANA. 768 17. References 770 17.1. Normative References 772 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 773 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 774 Protocol Specification (Revised)", RFC 4601, August 2006. 776 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 777 December 2005. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 783 Internet Protocol", RFC 4301, December 2005. 785 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 786 RFC 4303, December 2005. 788 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 789 Requirements for Encapsulating Security Payload (ESP) and 790 Authentication Header (AH)", RFC 4835, April 2007. 792 [I-D.ietf-msec-ipsec-extensions] 793 Weis, B., Gross, G., and D. Ignjatic, "Multicast 794 Extensions to the Security Architecture for the Internet 795 Protocol", draft-ietf-msec-ipsec-extensions-09 (work in 796 progress), June 2008. 798 17.2. Informative References 800 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 801 Internet Protocol", RFC 2401, November 1998. 803 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 804 Signature Option", RFC 3562, July 2003. 806 [IslamThesis] 807 Islam, S., "Security Issues in PIM-SM Link-local Messages, 808 Master's Thesis, Concordia University", December 2003. 810 [IslamLCN2004] 811 Islam, S., "Security Issues in PIM-SM Link-local Messages, 812 Proceedings of LCN 2004", November 2004. 814 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 815 RFC 4306, December 2005. 817 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 818 "GSAKMP: Group Secure Association Key Management 819 Protocol", RFC 4535, June 2006. 821 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 822 Group Domain of Interpretation", RFC 3547, July 2003. 824 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 825 Routing Protocols", RFC 4593, October 2006. 827 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 828 Architecture", RFC 3740, March 2004. 830 [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol 831 Independent Multicast (PIM)", RFC 5294, August 2008. 833 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 834 Independent Multicast - Sparse Mode (PIM-SM) Multicast 835 Routing Security Issues and Enhancements", RFC 4609, 836 October 2006. 838 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 839 Behringer, M. and F. Faucheur, "Applicability of Keying 840 Methods for RSVP Security", 841 draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in 842 progress), November 2008. 844 [I-D.weis-gdoi-for-rsvp] 845 Weis, B., "Group Domain of Interpretation (GDOI) support 846 for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress), 847 February 2008. 849 Authors' Addresses 851 J. William Atwood 852 Concordia University/CSE 853 1455 de Maisonneuve Blvd, West 854 Montreal, QC H3G 1M8 855 Canada 857 Phone: +1(514)848-2424 ext3046 858 Email: bill@cse.concordia.ca 859 URI: http://users.encs.concordia.ca/~bill 861 Salekul Islam 862 INRS Energie, Materiaux et Telecommunications 863 800, de La Gauchetiere, suite 800 864 Montreal, QC H5A 1K6 865 Canada 867 Email: Salekul.Islam@emt.inrs.ca 868 URI: http://users.encs.concordia.ca/~salek_is 870 Maziar Siami 871 Concordia University/CIISE 872 1455 de Maisonneuve Blvd, West 873 Montreal, QC H3G 1M8 874 Canada 876 Email: m_siamis@ciise.concordia.ca 878 Full Copyright Statement 880 Copyright (C) The IETF Trust (2008). 882 This document is subject to the rights, licenses and restrictions 883 contained in BCP 78, and except as set forth therein, the authors 884 retain all their rights. 886 This document and the information contained herein are provided on an 887 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 888 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 889 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 890 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 891 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 892 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 894 Intellectual Property 896 The IETF takes no position regarding the validity or scope of any 897 Intellectual Property Rights or other rights that might be claimed to 898 pertain to the implementation or use of the technology described in 899 this document or the extent to which any license under such rights 900 might or might not be available; nor does it represent that it has 901 made any independent effort to identify any such rights. Information 902 on the procedures with respect to rights in RFC documents can be 903 found in BCP 78 and BCP 79. 905 Copies of IPR disclosures made to the IETF Secretariat and any 906 assurances of licenses to be made available, or the result of an 907 attempt made to obtain a general license or permission for the use of 908 such proprietary rights by implementers or users of this 909 specification can be obtained from the IETF on-line IPR repository at 910 http://www.ietf.org/ipr. 912 The IETF invites any interested party to bring to its attention any 913 copyrights, patents or patent applications, or other proprietary 914 rights that may cover technology that may be required to implement 915 this standard. Please address the information to the IETF at 916 ietf-ipr@ietf.org.