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