Network Working Group P. Savola Request for Comments: 5294 CSC/FUNET Category: Informational J. Lingard Arastra August 2008 Host Threats to Protocol Independent Multicast (PIM) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol Independent Multicast (PIM) threats specific to router interfaces connecting hosts. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Host-Interface PIM Vulnerabilities . . . . . . . . . . . . . . 2 2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 3 2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 3 2.3. Routers May Accept PIM Messages from Non-Neighbors . . . . 3 2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 3 2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 3 2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4 2.5. A Node May Become an Illegitimate PIM Asserted Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4 2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 4 3. On-Link Threats . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6 3.3. Confidentiality, Integrity, or Authorization Violations . 6 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
RFC4609], some work on implementing confidentiality, integrity, and authorization in the multicast payload [RFC3740], and also some analysis of security threats in Internet Group Management Protocol/Multicast Listener Discovery (IGMP/MLD) [DALEY-MAGMA], but no comprehensive analysis of security threats to PIM at the host-connecting (typically "Local Area Network") links. We define these PIM host threats to include: o Nodes using PIM to attack or deny service to hosts on the same link, o Nodes using PIM to attack or deny service to valid multicast routers on the link, or o Nodes using PIM (Register messages) to bypass the controls of multicast routers on the link. The attacking node is typically a host or a host acting as an illegitimate router. A node originating multicast data can disturb existing receivers of the group on the same link, but this issue is not PIM-specific so it is out of scope. Subverting legitimate routers is out of scope. Security implications on multicast routing infrastructure are described in [RFC4609]. This document analyzes the PIM host-interface vulnerabilities, formulates a few specific threats, proposes some potential ways to mitigate these problems, and analyzes how well those methods accomplish fixing the issues. It is assumed that the reader is familiar with the basic concepts of PIM. Analysis of PIM-DM [RFC3973] is out of scope of this document.
The attacking node may be either a malicious host or an illegitimate router. RFC4609]. The Register message can be targeted to any IP address, whether in or out of the local PIM domain. The source address may be spoofed, unless spoofing has been prevented [RFC3704], to create arbitrary state at the RPs. Section 5.2 of [RFC5015]. However, the specification does not mandate this, so some implementations may be susceptible to attack from PIM messages sent by non-neighbors.
RFC5015], a Designated Forwarder (DF) is elected per link. The DF is responsible for forwarding data downstream onto the link, and also for forwarding data from its link upstream. A node that can become a BIDIR-PIM neighbor (this is just like becoming a PIM neighbor, except that the PIM Hello messages must include the Bidirectional Capable PIM-Hello option) can cause itself to be elected DF by sending DF Offer messages with a better metric than its neighbors. There are also some other BIDIR-PIM attacks related to DF election, including spoofing DF Offer and DF Winner messages (e.g., using a legitimate router's IP address), making all but the impersonated router believe that router is the DF. Also, an attacker might prevent the DF election from converging by sending an infinite sequence of DF Offer messages. For further discussion of BIDIR-PIM threats, we refer to the Security Considerations section in [RFC5015].
forwarded packets are being received from a "topologically correct" direction. This has two immediately obvious implications: 1. A node may maintain a forwarding loop until the Time to Live (TTL) runs out by passing packets from interface A to B. This is not believed to cause significant new risk as with a similar ease such a node could generate original packets that would loop back to its other interface. 2. A node may spoof source IP addresses in multicast packets it sends. Other PIM protocols drop such packets when performing the RPF check. BIDIR-PIM accepts such packets, allowing easier Denial-of-Service (DoS) attacks on the multicast delivery tree and making the attacker less traceable.
RFC4609]. In addition, any host can send PIM Register messages on their own, to whichever RP it wants; further, if unicast RPF (Reverse Path Forwarding) mechanisms [RFC3704] have not been applied, the packet may be spoofed. This can be done to get around rate-limits, and/or to attack remote RPs, and/or to interfere with the integrity of an ASM group. This attack is also described in [RFC4609]. Also, BIDIR-PIM does not prevent nodes from using topologically incorrect addresses (source address spoofing) making such an attack more difficult to trace.
A more elaborate attack is on authorization. There are some very questionable models [HAYASHI] where the current multicast architecture is used to provide paid multicast service, and where the authorization/authentication is added to the group management protocols such as IGMP. Needless to say, if a host would be able to act as a router, it might be possible to perform all kinds of attacks: subscribe to multicast service without using IGMP (i.e., without having to pay for it), deny the service for the others on the same link, etc. In short, to be able to ensure authorization, a better architecture should be used instead (e.g., [RFC3740]). RFC4609], running full PIM, with Hello messages and all, is unnecessary for those stub networks for which only one router is providing multicast service. Therefore, such implementations should provide an option to specify that the interface is "passive" with regard to PIM: no PIM packets are sent or processed (if received), but hosts can still send and receive multicast on that interface. RFC4601] and [LINKLOCAL]. However, it is worth noting that setting up IPsec Security Associations (SAs) manually can be a very tedious process, and the routers might not even support IPsec; further automatic key negotiation may not be feasible in these scenarios either. A Group Domain of Interpretation (GDOI) [RFC3547] server might be able to mitigate this negotiation.
Summary of vulnerabilities and mitigations: +-----+---------------------+-----------------+-----------------+ | Sec | Vulnerability | One stub router | >1 stub routers | | | | PASV|IPsec|Filt | PASV|IPsec|Filt | +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw | +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw | +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw | +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw | +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw | +-----+---------------------+-----+-----+-----+-----+-----+-----+ | 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x | +-----+---------------------+-----+-----+-----+-----+-----+-----+ Figure 1 "*" means Yes if IPsec is used in addition; No otherwise. "Ysw" means Yes if IPsec is used in addition or IP filtering is done on Ethernet switches on all host ports; No otherwise. "N+" means that the use of IPsec between the on-link routers does not protect from this; IPsec would have to be used at RPs. "x" means that, with BIDIR-PIM, IP access lists or RPF mechanisms need to be applied in stub interfaces to prevent originating packets with topologically incorrect source addresses. This needs to be done in addition to any other chosen approach. To summarize, IP protocol filtering for all PIM messages appears to be the most complete solution when coupled with the use of IPsec between the real stub routers when there are more than one of them. However, IPsec is not required if PIM message filtering or a certain kind of IP spoofing prevention is applied on all the host ports on Ethernet switches. If hosts performing registering is not considered a serious problem, IP protocol filtering and passive-mode PIM seem to be equivalent approaches. Additionally, if BIDIR-PIM is used, ingress filtering will need to be applied in stub interfaces to multicast packets, as well as unicast, to prevent hosts using wrong source addresses.
DALEY-MAGMA], which gave inspiration in exploring the on-link PIM threats problem space. Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci, John Zwiebel, Stig Venaas, Yiqun Cai, and Eric Gray provided good feedback for this memo. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. [DALEY-MAGMA] Daley, G. and J. Combes, "Securing Neighbour Discovery Proxy Problem Statement", Work in Progress, February 2008. [HAYASHI] Hayashi, T., "Internet Group membership Authentication Protocol (IGAP)", Work in Progress, August 2003. [LINKLOCAL] Atwood, J., Islam, S., and M. Siami, "Authentication and Confidentiality in PIM-SM Link-local Messages", Work in Progress, February 2008.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.