idnits 2.17.1 draft-savola-pim-lasthop-threats-02.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 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 (June 14, 2006) is 6520 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-atwood-pim-sm-linklocal-00 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 16, 2006 June 14, 2006 7 Last-hop Threats to Protocol Independent Multicast (PIM) 8 draft-savola-pim-lasthop-threats-02.txt 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 16, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 An analysis of security threats has been done for some parts of the 42 multicast infrastructure, but the threats specific to the last-hop 43 ("Local Area Network") attacks by hosts on the PIM routing protocol 44 have not been well described in the past. This memo aims to fill 45 that gap. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Last-hop PIM Vulnerabilities . . . . . . . . . . . . . . . . . 3 51 2.1. Nodes May Send Unauthorized PIM Register Messages . . . . 3 52 2.2. Nodes May Become Unauthorized PIM Neighbors . . . . . . . 4 53 2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4 54 2.4. An Unauthorized Node May Be Elected as the PIM DR . . . . 4 55 2.5. A Node May Become an Unauthorized PIM Asserted 56 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5 59 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 5 60 3.3. Confidentiality, Integrity or Authorization Violations . . 6 61 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7 63 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7 64 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 7 65 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . . . 11 75 1. Introduction 77 There has been some analysis of the security threats to the multicast 78 routing infrastructures [I-D.ietf-mboned-mroutesec], some work on 79 implementing confidentiality, integrity and authorization in the 80 multicast payload [RFC3740], and also some analysis of security 81 threats in IGMP/MLD [I-D.daley-magma-smld-prob], but no comprehensive 82 analysis of security threats to PIM at the last-hop ("Local Area 83 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 [I-D.ietf-mboned-mroutesec]. 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 [I-D.ietf-mboned-mroutesec]. 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 oneself allows one to subvert these restrictions: therefore rate- 216 limiting functions need to be deployed at multiple layers as 217 described in [I-D.ietf-mboned-mroutesec]. 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 [I-D.ietf-mboned-mroutesec]. 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 get to be a DR, it is able to violate the integrity of 234 any data streams sent by sources on the LAN, by modifying (possibly 235 in 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 [I-D.ietf-mboned-mroutesec], running full PIM, with 275 Hello messages and all, is unnecessary for those stub networks for 276 which only one router is providing multicast service. Therefore such 277 implementations should provide an option to specify that the 278 interface is "passive" with regard to PIM: no PIM packets are sent or 279 processed (if received), but hosts can still send and receive 280 multicast on that 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 [I-D.ietf-pim-sm-v2-new] and 288 [I-D.atwood-pim-sm-linklocal]. 290 However, it is worth noting that setting up IPsec Security 291 Associations (SAs) manually can be a very tedious process, and the 292 routers might not even support IPsec; further automatic key 293 negotiation may not be feasible in these scenarios either. A Group 294 Domain of Interpretation (GDOI) [RFC3547] server might be able to 295 mitigate this negotiation. 297 4.3. IP Filtering PIM Messages 299 To eliminate both the unicast and multicast PIM messages, in similar 300 scenarios to those for which PIM passive mode is applicable, it might 301 be possible to block IP protocol 103 (all PIM messages) in an input 302 access-list. This is more effective than PIM passive mode, as this 303 also blocks Register messages. 305 This is also acceptable when there is more than one PIM router on the 306 link if IPsec is used (because the access-list processing sees the 307 valid PIM messages as IPsec AH/ESP packets). However, this presumes 308 that the link is not used to transit unicast packets between the PIM 309 routers, or that the Register messages are also being sent with 310 IPsec. 312 4.4. Summary of Vulnerabilities and Mitigation Methods 314 This section summarizes the vulnerabilities, and how well the 315 mitigation methods are able to cope with them. 317 Summary of vulnerabilities and mitigations: 319 +-----+--------------------+-----------------+-----------------+ 320 | Sec | Vulnerability | One stub router | >1 stub routers | 321 | | | PASV|IPsec|Filt | PASV|IPsec|Filt | 322 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 323 | 2.1 | Hosts Registering | N | N+ | Y | N | N+ | * | 324 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 325 | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | * | 326 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 327 | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | * | 328 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 329 | 2.4 | Invalid DR | Y | Y | Y | * | Y | * | 330 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 331 | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | * | 332 +-----+--------------------+-----+-----+-----+-----+-----+-----+ 334 Figure 1 336 "*" means Yes if IPsec is used in addition; No otherwise. 338 "N+" means that the use of IPsec between the on-link routers does not 339 protect from this; IPsec would have to be used at RPs. 341 To summarize, IP protocol filtering for all PIM messages appears to 342 be the most complete solution when coupled with the use of IPsec 343 between the real stub routers when there are more than one of them. 344 If hosts performing registering is not considered a serious problem, 345 IP protocol filtering and passive-mode PIM seem to be equivalent 346 approaches. 348 5. Acknowledgements 350 Greg Daley and Gopi Durup wrote an excellent analysis of MLD security 351 issues [I-D.daley-magma-smld-prob], which gave inspiration in 352 exploring the on-link PIM threats problem space. 354 Ayan Roy-Chowdhury, Beau Williamson, and Bharat Joshi provided good 355 feedback for this memo. 357 6. IANA Considerations 359 This memo includes no request to IANA. 361 7. Security Considerations 363 This memo analyzes the threats to the PIM multicast routing protocol 364 at the last-hop, and proposes some possible mitigation techniques. 366 8. References 368 8.1. Normative References 370 [I-D.ietf-mboned-mroutesec] 371 Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast 372 Routing Security Issues and Enhancements", 373 draft-ietf-mboned-mroutesec-04 (work in progress), 374 October 2004. 376 [I-D.ietf-pim-sm-v2-new] 377 Fenner, B., "Protocol Independent Multicast - Sparse Mode 378 (PIM-SM): Protocol Specification (Revised)", 379 draft-ietf-pim-sm-v2-new-12 (work in progress), 380 March 2006. 382 8.2. Informative References 384 [I-D.atwood-pim-sm-linklocal] 385 Atwood, J., "Security Issues in PIM-SM Link-local 386 Messages", draft-atwood-pim-sm-linklocal-00 (work in 387 progress), October 2004. 389 [I-D.daley-magma-smld-prob] 390 Daley, G. and G. Kurup, "Trust Models and Security in 391 Multicast Listener Discovery", 392 draft-daley-magma-smld-prob-00 (work in progress), 393 July 2004. 395 [I-D.hayashi-igap] 396 Hayashi, T., "Internet Group membership Authentication 397 Protocol (IGAP)", draft-hayashi-igap-03 (work in 398 progress), August 2003. 400 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 401 Group Domain of Interpretation", RFC 3547, July 2003. 403 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 404 Networks", BCP 84, RFC 3704, March 2004. 406 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 407 Architecture", RFC 3740, March 2004. 409 Authors' Addresses 411 Pekka Savola 412 CSC - Scientific Computing Ltd. 413 Espoo 414 Finland 416 Email: psavola@funet.fi 418 James Lingard 420 Email: james@lingard.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).