Internet Engineering Task ForcePIM WG P. Savola Internet-Draft CSC/FUNET Intended status: Informational J. Lingard Expires: April 18,December 17, 2007 Arastra OctoberJune 15, 20062007 Last-hop Threats to Protocol Independent Multicast (PIM) draft-ietf-pim-lasthop-threats-00.txtdraft-ietf-pim-lasthop-threats-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18,December 17, 2007. Copyright Notice Copyright (C) The Internet Society (2006).IETF Trust (2007). Abstract An analysis of security threats has been done for some parts of the multicast infrastructure, but the threats specific to the last-hop ("Local Area Network") attacks by hosts on the PIM routing protocol have not been well described in the past. This memo aims to fill that gap. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Last-hop PIM Vulnerabilities . . . . . . . . . . . . . . . . . 3 2.1. Nodes May Send Unauthorized PIM Register Messages . . . . 3 2.2. Nodes May Become Unauthorized PIM Neighbors . . . . . . . 4 2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4 2.4. An Unauthorized Node May Be Elected as the PIM DR . . . . 4 2.5. A Node May Become an Unauthorized PIM Asserted Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 5 3.3. Confidentiality, Integrity or Authorization Violations . . 6 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 7 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 910 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 1. Introduction There has been some analysis of the security threats to the multicast routing infrastructures [RFC4609], some work on implementing confidentiality, integrity and authorization in the multicast payload [RFC3740], and also some analysis of security threats in IGMP/MLD [I-D.daley-magma-smld-prob], but no comprehensive analysis of security threats to PIM at the last-hop ("Local Area Network") links. We define PIM last-hop threats to include: o Nodes -- hosts or unauthorized routers -- 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. 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. The impact on the outside of the link is described in [RFC4609]. This document analyzes the last-hop PIM 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. 2. Last-hop PIM Vulnerabilities This section describes briefly the main attacks against last-hop PIM signalling, before we get to the actual threats and mitigation methods in the next sections. The attacking node may be either a malicious host or an unauthorized router. 2.1. Nodes May Send Unauthorized PIM Register Messages PIM Register messages are sent by unicast, and contain encapsulated multicast data packets. Malicious hosts or routers could also send Register messages themselves, for example to get around rate-limits or to interfere with foreign Rendezvous Points (RPs) as described in [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. 2.2. Nodes May Become Unauthorized PIM Neighbors When PIM has been enabled on a router's "host" interface, any node can also become a PIM neighbor using PIM Hello messages. Having become a PIM neighbor in this way, the node is able to send other PIM messages to the router and may use those messages to attack the router. 2.3. Routers May Accept PIM Messages From Non-Neighbors The PIM-SM specification recommends that PIM messages other than Hellos should not be accepted except from valid PIM neighbors. However, the specification does not mandate this, and so some implementations may be susceptible to attack from PIM messages sent by non-neighbors. 2.4. An Unauthorized Node May Be Elected as the PIM DR The Designated Router (DR) on a LANLocal Area Network (LAN) is responsible for Register- encapsulatingRegister-encapsulating data from new sources on the LAN, and for generating PIM Join/Prune messages on behalf of group members on the LAN. A node which can become a PIM neighbor can also cause itself to be elected DR, whether or not the DR Priority option is being used in PIM Hello messages on the LAN. 2.5. A Node May Become an Unauthorized PIM Asserted Forwarder With a PIM Assert message, a router can be elected to be in charge of forwarding all traffic for a particular (S,G) or (*,G) onto the LAN. This overrides DR behaviour. The specification says that Assert messages should only be accepted from known PIM neighbors, and "SHOULD" be discarded otherwise. So, either the node must be able to spoof an IP address of a current neighbor, form a PIM adjacency first, or count on these checks being disabled. The Assert Timer, by default, is 3 minutes; the state must be refreshed or it will be removed automatically. As noted before, it is also possible to spoof an Assert (e.g., using a legitimate router's IP address) to cause a temporary disruption on the LAN. 3. On-link Threats The previous section described some PIM vulnerabilities; this section gives an overview of the more concrete threats exploiting those vulnerabilities. 3.1. Denial-of-Service Attack on the Link The easiest attack is to deny the multicast service on the link. This could mean either not forwarding all (or parts of) multicast traffic from upstream onto the link, or not registering or forwarding upstream the multicast transmissions originated on the link. These attacks can be done multiple ways: the most typical one would be becoming the DR through becoming a neighbor with Hello messages and winning the DR election. After that, one could for example: o Not send any PIM Join/Prune messages based on the IGMP reports, o Not forward or register any sourced packets, or o Send PIM Prune messages to cut off existing transmissions because Prune messages are accepted from downstream interfaces even if the router is not a DR. An alternative mechanism is to send a PIM Assert message, spoofed to come from a valid PIM neighbor or non-spoofed if a PIM adjacency has already been formed. For the particular (S,G) or (*,G) from the Assert message, this creates the same result as getting elected as a DR. 3.2. Denial-of-Service Attack on the Outside It is also possible to perform Denial-of-Service attacks on nodes beyond the link, especially in environments where a multicast router and/or a DR is considered to be a trusted node. In particular, if DRs perform some form of rate-limiting, for example on new Join/Prune messages, becoming a DR and sending those messages yourself allows one to subvert these restrictions: therefore rate- limiting functions need to be deployed at multiple layers as described in [RFC4609]. In addition, any host can send PIM Register messages on their own, to whichever RP it wants; further, if unicast RPF 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]. 3.3. Confidentiality, Integrity or Authorization Violations Contrary to unicast, any node is able to legitimately receive all multicast transmission on the link by just adjusting the appropriate link-layer multicast filters. Confidentiality (if needed) must be obtained by cryptography. If a node can become a DR, it is able to violate the integrity of any data streams sent by sources on the LAN, by modifying (possibly in subtle, unnoticeable ways) the packets sent by the sources before Register-encapsulating them. If a node can form a PIM neighbor adjacency or spoof the IP address of a current neighbor, then if it has external connectivity by some other means other than the LAN, the node is able to violate the integrity of any data streams sent by external sources onto the LAN. It would do this by sending an appropriate Assert message onto the LAN to prevent the genuine PIM routers forwarding the valid data, obtaining the multicast traffic via its other connection, and modifying those data packets before forwarding them onto the LAN. In either of the above two cases, the node could operate as normal for some traffic, while violating integrity for some other traffic. A more elaborate attack is on authorization. There are some very questionable models [I-D.hayashi-igap] 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]). 4. Mitigation Methods This section lists some ways to mitigate the vulnerabilities and threats listed in previous sections. 4.1. Passive Mode for PIM The current PIM specification seems to mandate running the PIM Hello protocol on all PIM-enabled interfaces. Most implementations require PIM to be enabled on an interface in order to send PIM Register messages for data sent by sources on that interface or to do any other PIM processing. As described in [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. 4.2. Use of IPsec among PIM Routers Instead of passive mode, or when multiple PIM routers exist on a single link, one could also use IPsec to secure the PIM messaging, to prevent anyone from subverting it. The actual procedures have been described in [RFC4601] and [I-D.atwood-pim-sm-linklocal].[I-D.ietf-pim-sm-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. 4.3. IP Filtering PIM Messages To eliminate both the unicast and multicast PIM messages, in similar scenarios to those for which PIM passive mode is applicable, it might be possible to block IP protocol 103 (all PIM messages) in an input access-list. This is more effective than PIM passive mode, as this also blocks Register messages. This is also acceptable when there is more than one PIM router on the link if IPsec is used (because the access-list processing sees the valid PIM messages as IPsec AH/ESP packets). However, this presumes that the link is not used to transit unicast packets between the PIM routers, or that the Register messages are also being sent with IPsec. When multiple routers exist on a link, IPsec is not required if it is possible to prevent hosts from sending PIM messages at Ethernet switch (or equivalent) host ports. This could be accomplished in at least two ways: 1. Use IP access lists on the stub routers to allow PIM messages from the valid neighbor IP addresses only, and implement IP spoofing prevention at Ethernet switch port level using proprietary mechanisms, or 2. Filter out all PIM messages at configured host ports on Ethernet switches instead of doing it on the routers. The main benefit of this approach is that multiple stub routers can still communicate through the LAN without IPsec but hosts are not able to disturb the PIM protocol. The drawback is that Ethernet switches need to implement much finer-grained IP layer filtering and the operational requirements of carefully maintaining these filters could be significant. 4.4. Summary of Vulnerabilities and Mitigation Methods This section summarizes the vulnerabilities, and how well the mitigation methods are able to cope with them. 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 | Y | Y | Y | * | Y | *Ysw | +-----+--------------------+-----+-----+-----+-----+-----+-----+ | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | *Ysw | +-----+--------------------+-----+-----+-----+-----+-----+-----+ 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. 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 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. 5. Acknowledgements Greg Daley and Gopi Durup wrote an excellent analysis of MLD security issues [I-D.daley-magma-smld-prob], which gave inspiration in exploring the on-link PIM threats problem space. Ayan Roy-Chowdhury, Beau Williamson, andBharat JoshiJoshi, and Dino Farinacci provided good feedback for this memo. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations This memo analyzes the threats to the PIM multicast routing protocol at the last-hop, and proposes some possible mitigation techniques. 8. References 8.1. Normative References [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. 8.2. Informative References [I-D.atwood-pim-sm-linklocal] Atwood, J. and S. Islam, "Security Issues in PIM-SM Link- local Messages", draft-atwood-pim-sm-linklocal-01 (work in progress), June 2006.[I-D.daley-magma-smld-prob] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", draft-daley-magma-smld-prob-00 (work in progress), July 2004. [I-D.hayashi-igap] Hayashi, T., "Internet Group membership Authentication Protocol (IGAP)", draft-hayashi-igap-03 (work in progress), August 2003. [I-D.ietf-pim-sm-linklocal] Atwood, J. and S. Islam, "Security Issues in PIM-SM Link- local Messages", draft-ietf-pim-sm-linklocal-00 (work in progress), October 2006. [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. Authors' Addresses Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland Email: email@example.com James Lingard Arastra, Inc. P.O. Box 10905 Palo Alto, CA 94303 USA Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (2006).IETF Trust (2007). 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 SOCIETYSOCIETY, 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).