idnits 2.17.1 draft-ietf-pim-lasthop-threats-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 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 460. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the 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 (October 15, 2006) is 6397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Intended status: Informational J. Lingard 5 Expires: April 18, 2007 Arastra 6 October 15, 2006 8 Last-hop Threats to Protocol Independent Multicast (PIM) 9 draft-ietf-pim-lasthop-threats-00.txt 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 An analysis of security threats has been done for some parts of the 43 multicast infrastructure, but the threats specific to the last-hop 44 ("Local Area Network") attacks by hosts on the PIM routing protocol 45 have not been well described in the past. This memo aims to fill 46 that gap. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Last-hop PIM Vulnerabilities . . . . . . . . . . . . . . . . . 3 52 2.1. Nodes May Send Unauthorized PIM Register Messages . . . . 3 53 2.2. Nodes May Become Unauthorized PIM Neighbors . . . . . . . 4 54 2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4 55 2.4. An Unauthorized Node May Be Elected as the PIM DR . . . . 4 56 2.5. A Node May Become an Unauthorized PIM Asserted 57 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5 60 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 5 61 3.3. Confidentiality, Integrity or Authorization Violations . . 6 62 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7 64 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7 65 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 7 66 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . . . 11 76 1. Introduction 78 There has been some analysis of the security threats to the multicast 79 routing infrastructures [RFC4609], some work on implementing 80 confidentiality, integrity and authorization in the multicast payload 81 [RFC3740], and also some analysis of security threats in IGMP/MLD 82 [I-D.daley-magma-smld-prob], but no comprehensive analysis of 83 security threats to PIM at the last-hop ("Local Area Network") links. 85 We define PIM last-hop threats to include: 87 o Nodes -- hosts or unauthorized routers -- using PIM to attack or 88 deny service to hosts on the same link, 90 o Nodes using PIM to attack or deny service to valid multicast 91 routers on the link, or 93 o Nodes using PIM (Register messages) to bypass the controls of 94 multicast routers on the link. 96 A node originating multicast data can disturb existing receivers of 97 the group on the same link, but this issue is not PIM-specific so it 98 is out of scope. The impact on the outside of the link is described 99 in [RFC4609]. 101 This document analyzes the last-hop PIM vulnerabilities, formulates a 102 few specific threats, proposes some potential ways to mitigate these 103 problems and analyzes how well those methods accomplish fixing the 104 issues. 106 It is assumed that the reader is familiar with the basic concepts of 107 PIM. 109 2. Last-hop PIM Vulnerabilities 111 This section describes briefly the main attacks against last-hop PIM 112 signalling, before we get to the actual threats and mitigation 113 methods in the next sections. 115 The attacking node may be either a malicious host or an unauthorized 116 router. 118 2.1. Nodes May Send Unauthorized PIM Register Messages 120 PIM Register messages are sent by unicast, and contain encapsulated 121 multicast data packets. Malicious hosts or routers could also send 122 Register messages themselves, for example to get around rate-limits 123 or to interfere with foreign Rendezvous Points (RPs) as described in 124 [RFC4609]. 126 The Register message can be targeted to any IP address, whether in or 127 out of the local PIM domain. The source address may be spoofed 128 unless spoofing has been prevented [RFC3704], to create arbitrary 129 state at the RPs. 131 2.2. Nodes May Become Unauthorized PIM Neighbors 133 When PIM has been enabled on a router's "host" interface, any node 134 can also become a PIM neighbor using PIM Hello messages. Having 135 become a PIM neighbor in this way, the node is able to send other PIM 136 messages to the router and may use those messages to attack the 137 router. 139 2.3. Routers May Accept PIM Messages From Non-Neighbors 141 The PIM-SM specification recommends that PIM messages other than 142 Hellos should not be accepted except from valid PIM neighbors. 143 However, the specification does not mandate this, and so some 144 implementations may be susceptible to attack from PIM messages sent 145 by non-neighbors. 147 2.4. An Unauthorized Node May Be Elected as the PIM DR 149 The Designated Router (DR) on a LAN is responsible for Register- 150 encapsulating data from new sources on the LAN, and for generating 151 PIM Join/Prune messages on behalf of group members on the LAN. 153 A node which can become a PIM neighbor can also cause itself to be 154 elected DR, whether or not the DR Priority option is being used in 155 PIM Hello messages on the LAN. 157 2.5. A Node May Become an Unauthorized PIM Asserted Forwarder 159 With a PIM Assert message, a router can be elected to be in charge of 160 forwarding all traffic for a particular (S,G) or (*,G) onto the LAN. 161 This overrides DR behaviour. 163 The specification says that Assert messages should only be accepted 164 from known PIM neighbors, and "SHOULD" be discarded otherwise. So, 165 either the node must be able to spoof an IP address of a current 166 neighbor, form a PIM adjacency first, or count on these checks being 167 disabled. 169 The Assert Timer, by default, is 3 minutes; the state must be 170 refreshed or it will be removed automatically. 172 As noted before, it is also possible to spoof an Assert (e.g., using 173 a legitimate router's IP address) to cause a temporary disruption on 174 the LAN. 176 3. On-link Threats 178 The previous section described some PIM vulnerabilities; this section 179 gives an overview of the more concrete threats exploiting those 180 vulnerabilities. 182 3.1. Denial-of-Service Attack on the Link 184 The easiest attack is to deny the multicast service on the link. 185 This could mean either not forwarding all (or parts of) multicast 186 traffic from upstream onto the link, or not registering or forwarding 187 upstream the multicast transmissions originated on the link. 189 These attacks can be done multiple ways: the most typical one would 190 be becoming the DR through becoming a neighbor with Hello messages 191 and winning the DR election. After that, one could for example: 193 o Not send any PIM Join/Prune messages based on the IGMP reports, 195 o Not forward or register any sourced packets, or 197 o Send PIM Prune messages to cut off existing transmissions because 198 Prune messages are accepted from downstream interfaces even if the 199 router is not a DR. 201 An alternative mechanism is to send a PIM Assert message, spoofed to 202 come from a valid PIM neighbor or non-spoofed if a PIM adjacency has 203 already been formed. For the particular (S,G) or (*,G) from the 204 Assert message, this creates the same result as getting elected as a 205 DR. 207 3.2. Denial-of-Service Attack on the Outside 209 It is also possible to perform Denial-of-Service attacks on nodes 210 beyond the link, especially in environments where a multicast router 211 and/or a DR is considered to be a trusted node. 213 In particular, if DRs perform some form of rate-limiting, for example 214 on new Join/Prune messages, becoming a DR and sending those messages 215 yourself allows one to subvert these restrictions: therefore rate- 216 limiting functions need to be deployed at multiple layers as 217 described in [RFC4609]. 219 In addition, any host can send PIM Register messages on their own, to 220 whichever RP it wants; further, if unicast RPF mechanisms [RFC3704] 221 have not been applied, the packet may be spoofed. This can be done 222 to get around rate-limits, and/or to attack remote RPs and/or to 223 interfere with the integrity of an ASM group. This attack is also 224 described in [RFC4609]. 226 3.3. Confidentiality, Integrity or Authorization Violations 228 Contrary to unicast, any node is able to legitimately receive all 229 multicast transmission on the link by just adjusting the appropriate 230 link-layer multicast filters. Confidentiality (if needed) must be 231 obtained by cryptography. 233 If a node can become a DR, it is able to violate the integrity of any 234 data streams sent by sources on the LAN, by modifying (possibly in 235 subtle, unnoticeable ways) the packets sent by the sources before 236 Register-encapsulating them. 238 If a node can form a PIM neighbor adjacency or spoof the IP address 239 of a current neighbor, then if it has external connectivity by some 240 other means other than the LAN, the node is able to violate the 241 integrity of any data streams sent by external sources onto the LAN. 242 It would do this by sending an appropriate Assert message onto the 243 LAN to prevent the genuine PIM routers forwarding the valid data, 244 obtaining the multicast traffic via its other connection, and 245 modifying those data packets before forwarding them onto the LAN. 247 In either of the above two cases, the node could operate as normal 248 for some traffic, while violating integrity for some other traffic. 250 A more elaborate attack is on authorization. There are some very 251 questionable models [I-D.hayashi-igap] where the current multicast 252 architecture is used to provide paid multicast service, and where the 253 authorization/authentication is added to the group management 254 protocols such as IGMP. Needless to say, if a host would be able to 255 act as a router, it might be possible to perform all kinds of 256 attacks: subscribe to multicast service without using IGMP (i.e., 257 without having to pay for it), deny the service for the others on the 258 same link, etc. In short, to be able to ensure authorization, a 259 better architecture should be used instead (e.g., [RFC3740]). 261 4. Mitigation Methods 263 This section lists some ways to mitigate the vulnerabilities and 264 threats listed in previous sections. 266 4.1. Passive Mode for PIM 268 The current PIM specification seems to mandate running the PIM Hello 269 protocol on all PIM-enabled interfaces. Most implementations require 270 PIM to be enabled on an interface in order to send PIM Register 271 messages for data sent by sources on that interface or to do any 272 other PIM processing. 274 As described in [RFC4609], running full PIM, with Hello messages and 275 all, is unnecessary for those stub networks for which only one router 276 is providing multicast service. Therefore such implementations 277 should provide an option to specify that the interface is "passive" 278 with regard to PIM: no PIM packets are sent or processed (if 279 received), but hosts can still send and receive multicast on that 280 interface. 282 4.2. Use of IPsec among PIM Routers 284 Instead of passive mode, or when multiple PIM routers exist on a 285 single link, one could also use IPsec to secure the PIM messaging, to 286 prevent anyone from subverting it. The actual procedures have been 287 described in [RFC4601] and [I-D.atwood-pim-sm-linklocal]. 289 However, it is worth noting that setting up IPsec Security 290 Associations (SAs) manually can be a very tedious process, and the 291 routers might not even support IPsec; further automatic key 292 negotiation may not be feasible in these scenarios either. A Group 293 Domain of Interpretation (GDOI) [RFC3547] server might be able to 294 mitigate this negotiation. 296 4.3. IP Filtering PIM Messages 298 To eliminate both the unicast and multicast PIM messages, in similar 299 scenarios to those for which PIM passive mode is applicable, it might 300 be possible to block IP protocol 103 (all PIM messages) in an input 301 access-list. This is more effective than PIM passive mode, as this 302 also blocks Register messages. 304 This is also acceptable when there is more than one PIM router on the 305 link if IPsec is used (because the access-list processing sees the 306 valid PIM messages as IPsec AH/ESP packets). However, this presumes 307 that the link is not used to transit unicast packets between the PIM 308 routers, or that the Register messages are also being sent with 309 IPsec. 311 4.4. Summary of Vulnerabilities and Mitigation Methods 313 This section summarizes the vulnerabilities, and how well the 314 mitigation methods are able to cope with them. 316 Summary of vulnerabilities and mitigations: 318 +-----+--------------------+-----------------+-----------------+ 319 | Sec | Vulnerability | One stub router | >1 stub routers | 320 | | | PASV|IPsec|Filt | PASV|IPsec|Filt | 321 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 322 | 2.1 | Hosts Registering | N | N+ | Y | N | N+ | * | 323 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 324 | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | * | 325 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 326 | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | * | 327 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 328 | 2.4 | Invalid DR | Y | Y | Y | * | Y | * | 329 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 330 | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | * | 331 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 333 Figure 1 335 "*" means Yes if IPsec is used in addition; No otherwise. 337 "N+" means that the use of IPsec between the on-link routers does not 338 protect from this; IPsec would have to be used at RPs. 340 To summarize, IP protocol filtering for all PIM messages appears to 341 be the most complete solution when coupled with the use of IPsec 342 between the real stub routers when there are more than one of them. 343 If hosts performing registering is not considered a serious problem, 344 IP protocol filtering and passive-mode PIM seem to be equivalent 345 approaches. 347 5. Acknowledgements 349 Greg Daley and Gopi Durup wrote an excellent analysis of MLD security 350 issues [I-D.daley-magma-smld-prob], which gave inspiration in 351 exploring the on-link PIM threats problem space. 353 Ayan Roy-Chowdhury, Beau Williamson, and Bharat Joshi provided good 354 feedback for this memo. 356 6. IANA Considerations 358 This memo includes no request to IANA. 360 7. Security Considerations 362 This memo analyzes the threats to the PIM multicast routing protocol 363 at the last-hop, and proposes some possible mitigation techniques. 365 8. References 367 8.1. Normative References 369 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 370 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 371 Protocol Specification (Revised)", RFC 4601, August 2006. 373 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 374 Independent Multicast - Sparse Mode (PIM-SM) Multicast 375 Routing Security Issues and Enhancements", RFC 4609, 376 October 2006. 378 8.2. Informative References 380 [I-D.atwood-pim-sm-linklocal] 381 Atwood, J. and S. Islam, "Security Issues in PIM-SM Link- 382 local Messages", draft-atwood-pim-sm-linklocal-01 (work in 383 progress), June 2006. 385 [I-D.daley-magma-smld-prob] 386 Daley, G. and G. Kurup, "Trust Models and Security in 387 Multicast Listener Discovery", 388 draft-daley-magma-smld-prob-00 (work in progress), 389 July 2004. 391 [I-D.hayashi-igap] 392 Hayashi, T., "Internet Group membership Authentication 393 Protocol (IGAP)", draft-hayashi-igap-03 (work in 394 progress), August 2003. 396 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 397 Group Domain of Interpretation", RFC 3547, July 2003. 399 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 400 Networks", BCP 84, RFC 3704, March 2004. 402 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 403 Architecture", RFC 3740, March 2004. 405 Authors' Addresses 407 Pekka Savola 408 CSC - Scientific Computing Ltd. 409 Espoo 410 Finland 412 Email: psavola@funet.fi 414 James Lingard 415 Arastra, Inc. 416 P.O. Box 10905 417 Palo Alto, CA 94303 418 USA 420 Email: jchl@arastra.com 422 Full Copyright Statement 424 Copyright (C) The Internet Society (2006). 426 This document is subject to the rights, licenses and restrictions 427 contained in BCP 78, and except as set forth therein, the authors 428 retain all their rights. 430 This document and the information contained herein are provided on an 431 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 432 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 433 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 434 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 435 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 436 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 438 Intellectual Property 440 The IETF takes no position regarding the validity or scope of any 441 Intellectual Property Rights or other rights that might be claimed to 442 pertain to the implementation or use of the technology described in 443 this document or the extent to which any license under such rights 444 might or might not be available; nor does it represent that it has 445 made any independent effort to identify any such rights. Information 446 on the procedures with respect to rights in RFC documents can be 447 found in BCP 78 and BCP 79. 449 Copies of IPR disclosures made to the IETF Secretariat and any 450 assurances of licenses to be made available, or the result of an 451 attempt made to obtain a general license or permission for the use of 452 such proprietary rights by implementers or users of this 453 specification can be obtained from the IETF on-line IPR repository at 454 http://www.ietf.org/ipr. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights that may cover technology that may be required to implement 459 this standard. Please address the information to the IETF at 460 ietf-ipr@ietf.org. 462 Acknowledgment 464 Funding for the RFC Editor function is provided by the IETF 465 Administrative Support Activity (IASA).