idnits 2.17.1 draft-atwood-pim-sm-linklocal-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 113: '...ti-replay option SHOULD be enabled for...' RFC 2119 keyword, line 121: '... implementation SHOULD NOT provide th...' RFC 2119 keyword, line 182: '...e sender address MUST be used in the S...' RFC 2119 keyword, line 207: '... mechanism SHOULD be activated while...' RFC 2119 keyword, line 208: '...ime a PIM router MUST maintain a diffe...' (4 more instances...) 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 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 (June 23, 2006) is 6518 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) ** Downref: Normative reference to an Informational RFC: RFC 3740 (ref. '4') ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 Expires: December 25, 2006 Concordia University/CSE 5 June 23, 2006 7 Security Issues in PIM-SM Link-local Messages 8 draft-atwood-pim-sm-linklocal-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 25, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document proposes some additions to the specification of the 42 Protocol Independent Multicast - Sparse Mode (PIM-SM) Protocol 43 regarding security issues of its link-local messages. Although the 44 new specifications for IPsec architecture (RFC 4301) and 45 Authorization Header (RFC 4302) permit the use of anti-replay, they 46 counsel against its use for multi-sender, multicast Security 47 Associations. This makes PIM-SM vulnerable to Denial of Service 48 (DoS) attack. In this document, a new proposal is presented to 49 protect PIM link-local messages while activating the anti-replay 50 mechanism as well. This proposal builds on the new Security 51 Association lookup method that has been specified in RFC 4301 and RFC 52 4302. 54 1. Introduction 56 All the PIM-SM [1] control messages have IP protocol number 103. 57 These messages are either unicast, or multicast with TTL = 1. The 58 source address used for unicast messages is a domain-wide reachable 59 address. For the multicast messages, a link-local address of the 60 interface on which the message is being sent is used as the source 61 address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 62 in IPv4 and ff02::d in IPv6) is used as the destination address. 63 These messages are called link-local messages. Hello, Join/Prune and 64 Assert messages are included in this category. A forged link-local 65 message may be sent to the ALL_PIM_ROUTERS multicast address by an 66 attacker. This type of message affects the construction of the 67 distribution tree [1]. The effects of these forged messages are 68 outlined in section 6.1 of [1]. Some of the effects are very severe, 69 whereas some are minor. 71 PIM-SM version 2 was originally specified in RFC 2117, and revised in 72 RFC 2362. A PIM-SM Internet Draft [1] has been approved by the IESG 73 for publication as an RFC. It is intended to obsolete RFC 2362, and 74 to correct a number of deficiencies. The Security Considerations 75 section of the PIM-SM Internet Draft is based primarily on the new 76 Authentication Header (AH) specification described in RFC 4302 [2]. 78 Securing the unicast messages can be achieved by the use of a normal 79 unicast IPsec Security Association between the two communicants. 80 Securing the user data exchanges is covered in RFC 3740 [4]. This 81 document focuses on the security issues of link-local messages. It 82 provides some guidelines to take advantage of the new permitted AH 83 functionality, and to bring the PIM-SM Internet Draft into alignment 84 with the new AH specification. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 90 and "OPTIONAL" are to be interpreted as described in RFC 2119 and 91 indicate requirement levels for compliant PIM-SM implementations. 93 3. Authentication according to the PIM-SM Internet-Draft 95 In the PIM-SM Internet Draft, IP Security (IPsec) [[3] transport mode 96 using Authentication Header (AH) [2] is recommended to prevent 97 attacks generated by forged control messages. The Network 98 Administrator will configure the specific AH authentication algorithm 99 and parameters, including the choice of authentication algorithm and 100 the choice of keys. The PIM-SM Internet Draft does not specify 101 protocols for establishing Security Associations. The PIM-SM 102 Internet Draft assumes that manual configuration of Security 103 Associations will be performed, although it does not preclude the use 104 of a negotiation protocol such as the Internet Key Exchange (IKE) [2] 105 to establish Security Associations. Once the Security Associations 106 have been established, all the control messages should go through the 107 IPsec authentication process. A PIM-SM router should authenticate a 108 control message before processing it, and should reject any 109 unauthorized PIM protocol messages. 111 Given that IPsec [3] provides protection against replayed unicast and 112 multicast messages, the PIM-SM Internet Draft further states that the 113 IPsec anti-replay option SHOULD be enabled for these Security 114 Associations. Unfortunately, the AH specification notes as follows: 116 "If the key used to compute an ICV is manually distributed, 117 correct provision of the anti-replay service would require correct 118 maintenance of the counter state at the sender, until the key is 119 replaced, and there would likely be no automated recovery 120 provision if counter overflow were imminent. Thus, a compliant 121 implementation SHOULD NOT provide this service in conjunction with 122 SAs that are manually keyed." 124 All the link-local messages of the PIM-SM protocol are sent to the 125 destination address, ALL_PIM_ROUTERS, which is a multicast address. 126 The Security Policy Database (SPD) within IPsec (see section 4.4.2 of 127 RFC 4301 [3]) is not capable of representing a policy for a multicast 128 Security Association. RFC 4301 provides no specification for an 129 automated way to create SAD entries for a multicast, inbound SA. 130 Only manually configured SAD entries can be created to accomodate 131 inbound, multicast traffic. As a result, the anti-replay option must 132 be disabled while using the IPsec AH protocol for security of link- 133 local messages. 135 4. Proposed Authentication Technique 137 The authentication mechanism [6][7] for PIM link-local messages 138 presented in this document has following two criteria to achieve: 140 o The anti-replay mechanism of Authetication Header protocol will be 141 activated while sending/receiving any PIM link-local message. 143 o To attain more flexibility, a PIM router will be able to deploy a 144 different authentication method for each directly connected PIM 145 router if necessary. In that case, a PIM router will maintain a 146 separate Security Association per peer PIM router. 148 4.1. Security Association Lookup 150 For an SA that carries unicast traffic, three parameters (SPI, 151 destination address and security protocol type (AH or ESP)) are used 152 in the Security Association lookup process for inbound packets. The 153 SPI is sufficient to specify an SA. However, an implementation may 154 use the SPI in conjunction with the IPsec protocol type (AH or ESP) 155 for the SA lookup process. According to RFC 4301 [3] and the AH 156 specification [2], for multicast SAs, in conjunction with the SPI, 157 the destination address or the destination address plus the sender 158 address may also be used in the SA lookup. The security protocol 159 field is not employed for a multicast SA lookup. 161 The reason for the various prohibitions in the IPsec RFCs concerning 162 multisender multicast SAs lies in the difficulty of coordinating the 163 multiple senders. However, if the use of multicast for link-local 164 messages is examined, it may be seen that in fact the communication 165 need not be coordinated---from the prospective of a receiving router, 166 each peer router is an independent sender. In effect, link-local 167 communication is an SSM communication that happens to use an ASM 168 address (which is shared among all the routers). Two possibilities 169 may be envisaged: 171 1. The address ALL_PIM_ROUTERS can be specified to operate as a set 172 of SSM Security Associations, when IPsec is enabled; 174 2. Secure Link-local communication can be specified to occur on an 175 SSM address, instead of ALL_PIM_ROUTERS. 177 Given that the sender address of an incoming packet will be 178 (globally) unique for a specific sender and in conjunction with the 179 SPI it will be possible for a receiver to sort out the associated SA 180 for that sender from all the SAD entries (even if a single SAD is 181 maintained regardless of the number of interfaces), we propose that 182 the SPI and the sender address MUST be used in the SA lookup process. 184 4.2. Activating the Anti-replay Mechanism 186 Although link-level messages on a link constitute a multiple-sender, 187 multiple-receiver group, the use of the sender address for SA lookup 188 essentially resolves the communication into a separate SA for each 189 sender/destination pair. Therefore, the statement in the AH RFC 190 (section 2.5 of [2]) that "for a multi-sender SA, the anti-replay 191 features are not available" becomes irrelevant to PIM-SM link-local 192 message exchange. 194 To activate the anti-replay mechanism in a unicast communication, the 195 receiver uses the sliding window protocol and it maintains a sequence 196 number for this protocol. This sequence number starts from zero. 197 Each time the sender sends a new packet, it increments this number by 198 one. In a multi-sender multicast group communication, a single 199 sequence number for the entire group would not be enough. 201 The whole scenario is different for PIM link-local messages. These 202 messages are sent to local links with TTL = 1. A link-local message 203 never propagates through one router to another. Given that the 204 number of peer routers is small, and given that the use of the sender 205 address for SA lookup converts the relationship from a multiple- 206 sender group to multiple single-sender associations, the anti-replay 207 mechanism SHOULD be activated while sending PIM link-local messages, 208 and at that time a PIM router MUST maintain a different sliding 209 window for each directly connected sender. 211 4.3. Implementing a Security Association Database per Interface 213 According to RFC 2401 [5], there is nominally a different Security 214 Association Database (SAD) for each router interface. However, RFC 215 4301 explicitly removes this requirement. The PIM-SM Internet Draft, 216 however, notes the possible utility of this feature. The proposal 217 above to use the source address to resolve the SAs implies that the 218 use of an SAD per interface is not necessary. 220 4.4. Manual Key Configuration 222 To establish the SAs at PIM-SM routers, manual key configuration will 223 be feasible, since the number of peers will be small. The Network 224 Administrator will configure a router manually during its boot up 225 process. At that time, the authentication method and the keys per 226 sender basis for each peer router SHOULD be configured. The SAD 227 entry for each sender connected with this router will be created. 228 The Network Admin will also configure the Security Policy Database of 229 a router to ensure the use of the associated SA while sending a link- 230 local message. 232 The addition of a new router to the set visible from a particular 233 router will clearly require a re-configuration of that router. 235 A negotiation protocol such as the Internet Key Exchange [2] MAY also 236 be used to negotiate and establish a suitable authentication method 237 and keys for the SA between two routers. However, a PIM router is 238 not expected to join/leave very frequently, so it is doubtful that 239 the overhead of automatic key configuration will be justified. In 240 any case, it will still be necessary to manually configure the basic 241 information that will allow the router to trust its peers. For these 242 reasons, manual key configuration SHOULD be used to establish SAs. 244 Unfortunately, the use of manual keying is called out in RFC 4302 as 245 a specific reason why anit-replay should be prohibited. It will be 246 necessary to either 248 1. explicitly override RFC 4302, or 250 2. design a negotiation protocol to deal with the case of counter 251 overrun. 253 Once the WG decides that the present proposal is an acceptable 254 direction to follow, the authors are prepared to work on the 255 development of such a negotiation protocol. 257 4.5. Extended Sequence Number 259 In the [2], there is a provision for a 64-bit Extended Sequence 260 Number (ESN) as the counter of the sliding window used in the anti- 261 replay protocol. Both the sender and the receiver maintain a 64-bit 262 counter for the sequence number, although only the lower order 32 263 bits is sent in the transmission. In other words, it will not affect 264 the present header format of AH. If ESN is used, a sender router can 265 send 2^64 -1 packets without any intervention. This number is very 266 large, and from a PIM router's point of view, a PIM router can never 267 exceed this number in its lifetime. This makes it reasonable to 268 permit manual configuration, since the sequence number will never 269 roll over. For this reason, when manual configuration is used, ESN 270 SHOULD be deployed as the sequence number for the sliding window 271 protocol. 273 5. Security Considerations 275 The whole document considers the security issues of PIM link-local 276 messages and proposes a mechanism to protect them. 278 6. References 280 [1] Fenner, B., "Protocol Independent Multicast-Sparse Mode 281 (PIM-SM): Protocol Specification(Revised), 282 draft-ietf-pim-sm-v2-new-12.txt", March 2006. 284 [2] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 286 [3] Kent, S. and K. Seo, "Security Architechture for the Internet 287 Protocol", RFC 4301, December 2005. 289 [4] Hardjono, T. and B. Weis, "The Multicast Group Security 290 Architecture", RFC 3740, March 2004. 292 [5] Kent, S. and R. Atkinson, "Security Architecture for the 293 Internet Protocol", RFC 2401, November 1998. 295 [6] Islam, S., "Security Issues in PIM-SM Link-local Messages, 296 Master's Thesis, Concordia University", December 2003. 298 [7] Islam, S., "Security Issues in PIM-SM Link-local Messages, 299 Proceedings of LCN 2004", November 2004. 301 Authors' Addresses 303 J. William Atwood 304 Concordia University/CSE 305 1455 de Maisonneuve Blvd, West 306 Montreal, QC H3G 1M8 307 Canada 309 Phone: +1(514)848-2424 ext3046 310 Email: bill@cse.concordia.ca 311 URI: http://www.cs.concordia.ca/~bill 313 Salekul Islam 314 Concordia University/CSE 315 1455 de Maisonneuve Blvd, West 316 Montreal, QC H3G 1M8 317 Canada 319 Intellectual Property Statement 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Disclaimer of Validity 345 This document and the information contained herein are provided on an 346 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 347 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 348 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 349 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 350 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 353 Copyright Statement 355 Copyright (C) The Internet Society (2006). This document is subject 356 to the rights, licenses and restrictions contained in BCP 78, and 357 except as set forth therein, the authors retain all their rights. 359 Acknowledgment 361 Funding for the RFC Editor function is currently provided by the 362 Internet Society.