idnits 2.17.1 draft-ietf-pim-sm-linklocal-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 528. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC4601, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4601, updated by this document, for RFC5378 checks: 2000-07-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2006) is 6403 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: '7' is defined on line 442, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 445, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 451, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (ref. '1') (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 3740 (ref. '5') -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '6') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. '9') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '11') (Obsoleted by RFC 6407) Summary: 7 errors (**), 0 flaws (~~), 5 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 October 15, 2006 6 Expires: April 18, 2007 8 Security Issues in PIM-SM Link-local Messages 9 draft-ietf-pim-sm-linklocal-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 18, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document outlines the security issues for the link-local 43 messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) 44 routing protocol. It provides mechanisms to authenticate the PIM-SM 45 link local messages using the IP security (IPsec) Authentication 46 Header (AH). 48 1. Introduction 50 All the PIM-SM [1] control messages have IP protocol number 103. 51 These messages are either unicast, or multicast with TTL = 1. The 52 source address used for unicast messages is a domain-wide reachable 53 address. For the multicast messages, a link-local address of the 54 interface on which the message is being sent is used as the source 55 address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 56 in IPv4 and ff02::d in IPv6) is used as the destination address. 57 These messages are called link-local messages. Hello, Join/Prune and 58 Assert messages are included in this category. A forged link-local 59 message may be sent to the ALL_PIM_ROUTERS multicast address by an 60 attacker. This type of message affects the construction of the 61 distribution tree [1]. The effects of these forged messages are 62 outlined in section 6.1 of [1]. Some of the effects are very severe, 63 whereas some are minor. 65 PIM-SM version 2 was originally specified in RFC 2117, and revised in 66 RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a 67 number of deficiencies. The Security Considerations section of RFC 68 4601 is based primarily on the new Authentication Header (AH) 69 specification described in RFC 4302 [2]. 71 Securing the unicast messages can be achieved by the use of a normal 72 unicast IPsec Security Association between the two communicants. 73 Securing the user data exchanges is covered in RFC 3740 [5]. This 74 document focuses on the security issues for link-local messages. It 75 provides some guidelines to take advantage of the new permitted AH 76 functionality in RFC 4302, and to bring the PIM-SM specification into 77 alignment with the new AH specification. This document recommends 78 manual key management as mandatory to implement, i.e., that all 79 implementations MUST support, and discusses the need to develop a 80 simple light-weight automated key management protocol that the PIM 81 routers can use. 83 2. Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 87 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and 88 indicate requirement levels for compliant PIM-SM implementations. 90 3. Transport Mode vs. Tunnel Mode 92 The transport mode Security Association (SA) is generally used 93 between two hosts or routers/gateways when they are acting as hosts. 94 The SA must be a tunnel mode SA if either end of the security 95 association is a router/gateway. Two hosts MAY establish a tunnel 96 mode SA between themselves. PIM-SM link-local messages are exchanged 97 between routers. However, since the packets are locally delivered, 98 the routers assume the role of hosts in the context of the tunnel 99 mode SA. All implementations conforming to this specification MUST 100 support transport mode SA to provide required IPsec security to 101 PIM-SM link-local messages. They MAY also support tunnel mode SA to 102 provide required IPsec security to PIM-SM link-local messages. 104 4. Authentication 106 Implementations conforming to this specification MUST support 107 authentication for PIM-SM link-local messages. In order to provide 108 authentication to PIM-SM link-local messages, implementations MUST 109 support AH in transport mode. 111 When authentication for PIM-SM link-local messages is enabled, 113 o PIM-SM link-local packets that are not protected with AH MUST be 114 silently discarded. 116 o PIM-SM link-local packets that fail the authentication checks MUST 117 be silently discarded. 119 5. IPsec Requirements 121 In order to implement this specification, the following IPsec 122 capabilities are required. 124 Transport mode 125 IPsec in transport mode MUST be supported. 127 Selectors 128 The implementation MUST be able to use source address and SPI as 129 selectors in the SPD. 131 Manual key management 132 Manually configured keys MUST be able to secure the specified 133 traffic. 135 6. Key Management 137 All the implementations MUST support manual configuration of the SAs 138 that will be used to authenticate PIM-SM link-local messages. This 139 does not preclude the use of a negotiation protocol such as the 140 Internet Key Exchange (IKE) [9] or Group Secure Association Key 141 Management Protocol (GSAKMP) [10]to establish SAs. 143 6.1. Manual Key Management 145 To establish the SAs at PIM-SM routers, manual key configuration will 146 be feasible when the number of peers (directly connected routers) is 147 small. The Network Administrator will configure a router manually 148 during its boot up process. At that time, the authentication method 149 and the choice of keys SHOULD be configured. The SAD entry will be 150 created. The Network Administrator will also configure the Security 151 Policy Database of a router to ensure the use of the associated SA 152 while sending a link-local message. 154 6.2. Automated Key Management 156 All the link-local messages of the PIM-SM protocol are sent to the 157 destination address, ALL_PIM_ROUTERS, which is a multicast address. 158 By using the sender address in conjunction with the destination 159 address for Security Association lookup, link-local communication 160 turns to an SSM or "one to many" communication. Since IKE is based 161 on the Diffie-Hellman key agreement protocol and works only for two 162 communicating parties, it is not possible to use IKE for providing 163 the required "one to many" authentication. 165 The other option is to use Group Domain Of Interpretation (GDOI) 166 [11], which enables a group of users or devices to exchange encrypted 167 data using IPsec data encryption. GDOI has been developed to be used 168 in multicast applications, where the number of end users or devices 169 may be large and the end users or devices can dynamically join/leave 170 a multicast group. However, a PIM router is not expected to join/ 171 leave very frequently, and the number of routers is small when 172 compared to the possible number of users of a multicast application. 173 Moreover, most of the PIM routers will be located inside the same 174 administrative domain and are considered as trusted parties. 175 Probably, a GDOI-lite with a subset of GDOI functionalities should be 176 designed by the PIM working group. 178 7. Number of Security Associations 180 The number of Security Associations to be maintained by a PIM router 181 depends on the required security level and available key management. 182 This SHOULD be decided by the Network Administrator. Two different 183 ways are shown in Figure 1 and 2. It is assumed that A, B and C are 184 three PIM routers, where B and C are directly connected with A, and 185 there is no direct link between B and C. 187 A | 188 SAa ------------>| 189 SAb <------------| 190 SAc <------------| 191 | 192 B | 193 SAb ------------>| 194 SAa <------------| 195 | 196 C | 197 SAc ------------>| 198 SAa <------------| 199 | 200 Directly connected network 202 Figure 1: Activate unique Security Association for each peer 204 The first method, shown in Figure 1 is OPTIONAL to implement. In 205 this method, each node will use a unique SA for its outbound traffic. 206 A, B, and C will use SAa, SAb, and SAc, respectively for sending any 207 traffic. Each node will look up the SA to be used based on the 208 source address. A will use SAb and SAc for packets received from B 209 and C, respectively. The number of SAs to be activated and 210 maintained by a PIM router will be equal to the number of directly 211 connected routers plus one, for sending its own traffic. Also, the 212 addition of a PIM router in the network will require the addition of 213 another SA on every directly connected PIM router. This solution 214 will be scalable and practically feasible with an automated key 215 management protocol. However, it MAY be used with manual key 216 management, if the number of directly connected router(s) is small. 218 A | 219 SAo ------------>| 220 SAi <------------| 221 | 222 B | 223 SAo ------------>| 224 SAi <------------| 225 | 226 C | 227 SAo ------------>| 228 SAi <------------| 229 | 230 Directly connected network 232 Figure 2: Activate two Security Associations 234 The second method, shown in Figure 2, MUST be supported by every 235 implementation. In this simple method, all the nodes will use two 236 SAs, one for sending (SAo) and the other for receiving (SAi) traffic. 237 Thus, the number of SAs is always two and will not be affected by 238 addition of a PIM router. This document RECOMMENDS the above method 239 for manual key configuration. However, it MAY also be used with 240 automated key configuration. When manually configured, the method 241 suffers from impersonation attacks as mentioned in the Security 242 Considerations section. 244 8. Rekeying 246 This section will provide the rekeying rules. It will be written 247 once is is decided whether or not to specify a re-keying protocol as 248 part of this document. 250 8.1. Rekeying Procedure 252 TBD 254 8.2. KeyRolloverInterval 256 TBD 258 8.3. Rekeying Interval 260 TBD 262 9. IPsec Protection Barrier and SPD 264 This section will provide the SPD selection function rules. It will 265 be written once it is decided whether we need confidentiality in 266 addition to authentication. 268 10. Security Association Lookup 270 For an SA that carries unicast traffic, three parameters (SPI, 271 destination address and security protocol type (AH or ESP)) are used 272 in the Security Association lookup process for inbound packets. The 273 SPI is sufficient to specify an SA. However, an implementation may 274 use the SPI in conjunction with the IPsec protocol type (AH or ESP) 275 for the SA lookup process. According to RFC 4301 [4] and the AH 276 specification [2], for multicast SAs, in conjunction with the SPI, 277 the destination address or the destination address plus the sender 278 address may also be used in the SA lookup. The security protocol 279 field is not employed for a multicast SA lookup. 281 The reason for the various prohibitions in the IPsec RFCs concerning 282 multisender multicast SAs lies in the difficulty of coordinating the 283 multiple senders. However, if the use of multicast for link-local 284 messages is examined, it may be seen that in fact the communication 285 need not be coordinated---from the prospective of a receiving router, 286 each peer router is an independent sender. In effect, link-local 287 communication is an SSM communication that happens to use an ASM 288 address (which is shared among all the routers). Two possibilities 289 may be envisaged: 291 1. The address ALL_PIM_ROUTERS can be specified to operate as a set 292 of SSM Security Associations, when IPsec is enabled; 294 2. Secure Link-local communication can be specified to occur on an 295 SSM address, instead of ALL_PIM_ROUTERS. 297 Given that the sender address of an incoming packet will be 298 (globally) unique for a specific sender and in conjunction with the 299 SPI it will be possible for a receiver to sort out the associated SA 300 for that sender from all the SAD entries (even if a single SAD is 301 maintained regardless of the number of interfaces), this document 302 mandates that the SPI and the sender address MUST be used in the SA 303 lookup process. 305 11. Activating the Anti-replay Mechanism 307 Although link-level messages on a link constitute a multiple-sender, 308 multiple-receiver group, the use of the sender address for SA lookup 309 essentially resolves the communication into a separate SA for each 310 sender/destination pair, even for the case where only two SAs are 311 used for the entire administrative region. Therefore, the statement 312 in the AH RFC (section 2.5 of [2]) that "for a multi-sender SA, the 313 anti-replay features are not available" becomes irrelevant to the 314 PIM-SM link-local message exchange. 316 To activate the anti-replay mechanism in a unicast communication, the 317 receiver uses the sliding window protocol and it maintains a sequence 318 number for this protocol. This sequence number starts from zero. 319 Each time the sender sends a new packet, it increments this number by 320 one. In a multi-sender multicast group communication, a single 321 sequence number for the entire group would not be enough. 323 The whole scenario is different for PIM link-local messages. These 324 messages are sent to local links with TTL = 1. A link-local message 325 never propagates through one router to another. The use of the 326 sender address for SA lookup converts the relationship from a 327 multiple-sender group to multiple single-sender associations. This 328 specification RECOMMENDS activation of the anti-replay mechanism only 329 if the SAs are assigned using an automated key management. In manual 330 key management, the anti-replay SHOULD NOT be activated. If the 331 number of router(s) to be assigned manually is small, the Network 332 Administrator MAY consider to activate anti-replay. If anti-replay 333 is activated a PIM router MUST maintain a different sliding window 334 for each directly connected sender. 336 If the SAs are activated according to Figure 2, that is all the nodes 337 use only two SAs, one SA for sending and the other is for receiving 338 traffic, a PIM router MAY still activate the anti-replay mechanism. 339 Instead of maintaining only two SAs, the router will maintain the 340 same number of SAs as explained in the first method (see Figure 1) 341 (because of the differentiation based on sender address). For each 342 active SA a corresponding sequence number MUST be maintained. Thus, 343 a PIM router will maintain a number of identical SAs, except that the 344 sender address and the sequence number are different for each SA. In 345 this way a PIM router will be at least free from all the attacks that 346 can be performed by replaying PIM-SM packets. 348 Note that when activating anti-replay with manual key configuration, 349 the following actions must be taken by the network administrator: 351 a. If a new router is added, the Network Administrator MUST add a 352 new SA entry in each peer router. 354 b. If an existing router has to restart, the Network Administrator 355 MUST refresh the counter (ESN, see section 13) to zero for all 356 the peer routers. This implies deleting all the existing SAs and 357 adding a new SA with the same configuration and a re-initialized 358 counter. 360 12. Implementing a Security Association Database per Interface 362 RFC 4601 suggests that it may be desirable to implement a separate 363 Security Association Database (SPD) for each router interface. The 364 use of the source address to resolve the SAs implies that the use of 365 an SAD per interface is not necessary. This is in conformance with 366 RFC 4301, which explicitly removes the requirement for separate SPDs 367 that was present in RFC 2401 [6]. 369 13. Extended Sequence Number 371 In the [2], there is a provision for a 64-bit Extended Sequence 372 Number (ESN) as the counter of the sliding window used in the anti- 373 replay protocol. Both the sender and the receiver maintain a 64-bit 374 counter for the sequence number, although only the lower order 32 375 bits is sent in the transmission. In other words, it will not affect 376 the present header format of AH. If ESN is used, a sender router can 377 send 2^64 -1 packets without any intervention. This number is very 378 large, and from a PIM router's point of view, a PIM router can never 379 exceed this number in its lifetime. This makes it reasonable to 380 permit manual configuration for a small number of PIM routers, since 381 the sequence number will never roll over. For this reason, when 382 manual configuration is used, ESN SHOULD be deployed as the sequence 383 number for the sliding window protocol. 385 14. Security Considerations 387 The whole document considers the security issues of PIM link-local 388 messages and proposes a mechanism to protect them. 390 Limitations of manual keys: 392 The following are some of the known limitations of the usage of 393 manual keys. 395 o If the replay protection cannot be provided, the PIM routers will 396 not be secured against all the attacks that can be performed by 397 replaying PIM packets. 399 o Manual keys are usually long lived (changing them often is a 400 tedious task). This gives an attacker enough time to discover the 401 keys. 403 o As the administrator is manually configuring the keys, there is a 404 chance that the configured keys are weak (there are known weak 405 keys for DES/3DES at least). 407 Impersonation attacks: 409 The usage of the same key on all the PIM routers connected to a link 410 leaves them all insecure against impersonation attacks if any one of 411 the PIM routers is compromised, malfunctioning, or misconfigured. 413 Detailed analysis of various vulnerabilities of routing protocols is 414 provided in [12]. For further discussion of PIM-SM and multicast 415 security the reader is referred to [13], [14] and the Security 416 Considerations section of RFC 4601. 418 15. References 420 15.1. Normative References 422 [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 423 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 424 Specification (Revised)", RFC 4601, August 2006. 426 [2] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 428 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 429 Levels", BCP 14, RFC 2119, March 1997. 431 [4] Kent, S. and K. Seo, "Security Architecture for the Internet 432 Protocol", RFC 4301, December 2005. 434 [5] Hardjono, T. and B. Weis, "The Multicast Group Security 435 Architecture", RFC 3740, March 2004. 437 15.2. Informative References 439 [6] Kent, S. and R. Atkinson, "Security Architecture for the 440 Internet Protocol", RFC 2401, November 1998. 442 [7] Islam, S., "Security Issues in PIM-SM Link-local Messages, 443 Master's Thesis, Concordia University", December 2003. 445 [8] Islam, S., "Security Issues in PIM-SM Link-local Messages, 446 Proceedings of LCN 2004", November 2004. 448 [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 449 RFC 4306, December 2005. 451 [10] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 452 Group Secure Association Key Management Protocol", RFC 4535, 453 June 2006. 455 [11] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 456 Domain of Interpretation", RFC 3547, July 2003. 458 [12] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 459 Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work 460 in progress), October 2004. 462 [13] Lingard, J. and P. Savola, "Last-hop Threats to Protocol 463 Independent Multicast (PIM)", 464 draft-savola-pim-lasthop-threats-02 (work in progress), 465 June 2006. 467 [14] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 468 Routing Security Issues and Enhancements", 469 draft-ietf-mboned-mroutesec-04 (work in progress), 470 October 2004. 472 Authors' Addresses 474 J. William Atwood 475 Concordia University/CSE 476 1455 de Maisonneuve Blvd, West 477 Montreal, QC H3G 1M8 478 Canada 480 Phone: +1(514)848-2424 ext3046 481 Email: bill@cse.concordia.ca 482 URI: http://www.cs.concordia.ca/~bill 484 Salekul Islam 485 Concordia University/CSE 486 1455 de Maisonneuve Blvd, West 487 Montreal, QC H3G 1M8 488 Canada 490 Full Copyright Statement 492 Copyright (C) The Internet Society (2006). 494 This document is subject to the rights, licenses and restrictions 495 contained in BCP 78, and except as set forth therein, the authors 496 retain all their rights. 498 This document and the information contained herein are provided on an 499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 501 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 502 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 503 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 506 Intellectual Property 508 The IETF takes no position regarding the validity or scope of any 509 Intellectual Property Rights or other rights that might be claimed to 510 pertain to the implementation or use of the technology described in 511 this document or the extent to which any license under such rights 512 might or might not be available; nor does it represent that it has 513 made any independent effort to identify any such rights. Information 514 on the procedures with respect to rights in RFC documents can be 515 found in BCP 78 and BCP 79. 517 Copies of IPR disclosures made to the IETF Secretariat and any 518 assurances of licenses to be made available, or the result of an 519 attempt made to obtain a general license or permission for the use of 520 such proprietary rights by implementers or users of this 521 specification can be obtained from the IETF on-line IPR repository at 522 http://www.ietf.org/ipr. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights that may cover technology that may be required to implement 527 this standard. Please address the information to the IETF at 528 ietf-ipr@ietf.org. 530 Acknowledgment 532 Funding for the RFC Editor function is provided by the IETF 533 Administrative Support Activity (IASA).