draft-ietf-pim-lasthop-threats-03.txt   draft-ietf-pim-lasthop-threats-04.txt 
PIM WG P. Savola PIM WG P. Savola
Internet-Draft CSC/FUNET Internet-Draft CSC/FUNET
Intended status: Informational J. Lingard Intended status: Informational J. Lingard
Expires: April 12, 2008 Arastra Expires: November 9, 2008 Arastra
October 10, 2007 May 8, 2008
Host Threats to Protocol Independent Multicast (PIM) Host Threats to Protocol Independent Multicast (PIM)
draft-ietf-pim-lasthop-threats-03.txt draft-ietf-pim-lasthop-threats-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2008. This Internet-Draft will expire on November 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo complements the list of multicast infrastructure security This memo complements the list of multicast infrastructure security
threat analysis documents by describing Protocol Independent threat analysis documents by describing Protocol Independent
Multicast (PIM) threats specific to router interfaces connecting Multicast (PIM) threats specific to router interfaces connecting
hosts. hosts.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Host-interface PIM Vulnerabilities . . . . . . . . . . . . . . 3 2. Host-interface PIM Vulnerabilities . . . . . . . . . . . . . . 3
2.1. Nodes May Send Unauthorized PIM Register Messages . . . . 4 2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 4
2.2. Nodes May Become Unauthorized PIM Neighbors . . . . . . . 4 2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 4
2.3. Routers May Accept PIM Messages From Non-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 or DF . 4 2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 4
2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 4 2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 4
2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4 2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4
2.5. A Node May Become an Unauthorized PIM Asserted 2.5. A Node May Become an Illegitimate PIM Asserted
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 5 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5 2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5
3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6
3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6
3.3. Confidentiality, Integrity or Authorization Violations . . 7 3.3. Confidentiality, Integrity or Authorization Violations . . 7
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 27 skipping to change at page 3, line 27
o Nodes using PIM to attack or deny service to hosts on the same o Nodes using PIM to attack or deny service to hosts on the same
link, link,
o Nodes using PIM to attack or deny service to valid multicast o Nodes using PIM to attack or deny service to valid multicast
routers on the link, or routers on the link, or
o Nodes using PIM (Register messages) to bypass the controls of o Nodes using PIM (Register messages) to bypass the controls of
multicast routers on the link. multicast routers on the link.
The attacking node is typically a host or a host acting as an The attacking node is typically a host or a host acting as an
unauthorized router. illegitimate router.
A node originating multicast data can disturb existing receivers of 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 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 is out of scope. Subverting legitimate routers is out of scope.
in [RFC4609]. Security implications on multicast routing infrastructure are
described in [RFC4609].
This document analyzes the PIM host-interface vulnerabilities, This document analyzes the PIM host-interface vulnerabilities,
formulates a few specific threats, proposes some potential ways to formulates a few specific threats, proposes some potential ways to
mitigate these problems and analyzes how well those methods mitigate these problems and analyzes how well those methods
accomplish fixing the issues. accomplish fixing the issues.
It is assumed that the reader is familiar with the basic concepts of It is assumed that the reader is familiar with the basic concepts of
PIM. PIM.
2. Host-interface PIM Vulnerabilities 2. Host-interface PIM Vulnerabilities
This section describes briefly the main attacks against host- This section describes briefly the main attacks against host-
interface PIM signalling, before we get to the actual threats and interface PIM signalling, before we get to the actual threats and
mitigation methods in the next sections. mitigation methods in the next sections.
The attacking node may be either a malicious host or an unauthorized The attacking node may be either a malicious host or an illegitimate
router. router.
2.1. Nodes May Send Unauthorized PIM Register Messages 2.1. Nodes May Send Illegitimate PIM Register Messages
PIM Register messages are sent by unicast, and contain encapsulated PIM Register messages are sent unicast, and contain encapsulated
multicast data packets. Malicious hosts or routers could also send multicast data packets. Malicious hosts or routers could also send
Register messages themselves, for example to get around rate-limits Register messages themselves, for example to get around rate-limits
or to interfere with foreign Rendezvous Points (RPs) as described in or to interfere with foreign Rendezvous Points (RPs) as described in
[RFC4609]. [RFC4609].
The Register message can be targeted to any IP address, whether in or 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 out of the local PIM domain. The source address may be spoofed
unless spoofing has been prevented [RFC3704], to create arbitrary unless spoofing has been prevented [RFC3704], to create arbitrary
state at the RPs. state at the RPs.
2.2. Nodes May Become Unauthorized PIM Neighbors 2.2. Nodes May Become Illegitimate PIM Neighbors
When PIM has been enabled on a router's host interface, any node can 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 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 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. to the router and may use those messages to attack the router.
2.3. Routers May Accept PIM Messages From Non-Neighbors 2.3. Routers May Accept PIM Messages From Non-Neighbors
The PIM-SM specification recommends that PIM messages other than The PIM-SM specification recommends that PIM messages other than
Hellos should not be accepted except from valid PIM neighbors. Hellos should not be accepted except from valid PIM neighbors.
BIDIR-PIM [I-D.ietf-pim-bidir] specification (Section 5.2) specifies BIDIR-PIM [RFC5015] specification (Section 5.2) specifies that
that packets from non-neighbors "SHOULD NOT" be accepted. However, packets from non-neighbors "SHOULD NOT" be accepted. However, the
the specification does not mandate this, and so some implementations specification does not mandate this, and so some implementations may
may be susceptible to attack from PIM messages sent by non-neighbors. be susceptible to attack from PIM messages sent by non-neighbors.
2.4. An Unauthorized Node May Be Elected as the PIM DR or DF 2.4. An Illegitimate Node May Be Elected as the PIM DR or DF
2.4.1. PIM-SM Designated Router Election 2.4.1. PIM-SM Designated Router Election
In PIM-SM, the Designated Router (DR) on a Local Area Network (LAN) In PIM-SM, the Designated Router (DR) on a Local Area Network (LAN)
is responsible for Register-encapsulating data from new sources on is responsible for Register-encapsulating data from new sources on
the LAN, and for generating PIM Join/Prune messages on behalf of the LAN, and for generating PIM Join/Prune messages on behalf of
group members on the LAN. group members on the LAN.
A node which can become a PIM neighbor can also cause itself to be 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 elected DR, whether or not the DR Priority option is being used in
PIM Hello messages on the LAN. PIM Hello messages on the LAN.
2.4.2. BIDIR-PIM Designated Forwarder Election 2.4.2. BIDIR-PIM Designated Forwarder Election
In BIDIR-PIM [I-D.ietf-pim-bidir] a Designated Forwarder (DF) is In BIDIR-PIM [RFC5015] a Designated Forwarder (DF) is elected per
elected per link. The DF is responsible for forwarding data link. The DF is responsible for forwarding data downstream onto the
downstream onto the link, and also for forwarding data from its link link, and also for forwarding data from its link upstream.
upstream.
A node which can become a BIDIR-PIM neighbor (this is just like A node which can become a BIDIR-PIM neighbor (this is just like
becoming a PIM neighbor, except that the PIM Hello messages must becoming a PIM neighbor, except that the PIM Hello messages must
include the Bidirectional Capable PIM-Hello option) can cause itself include the Bidirectional Capable PIM-Hello option) can cause itself
to be elected DF by sending DF Offer messages with a better metric to be elected DF by sending DF Offer messages with a better metric
than its neighbors. than its neighbors.
There are also some other BIDIR-PIM attacks related to DF election, There are also some other BIDIR-PIM attacks related to DF election,
including spoofing DF Offer and DF Winner messages (e.g., using a including spoofing DF Offer and DF Winner messages (e.g., using a
legitimate router's IP address), making all but the impersonated legitimate router's IP address), making all but the impersonated
router believe that router is the DF. Also an attacker might prevent router believe that router is the DF. Also an attacker might prevent
the DF election from converging by sending an infinite sequence of DF the DF election from converging by sending an infinite sequence of DF
Offer messages. Offer messages.
For further discussion of BIDIR-PIM threats we refer to the security For further discussion of BIDIR-PIM threats we refer to the security
considerations section in [I-D.ietf-pim-bidir]. considerations section in [RFC5015].
2.5. A Node May Become an Unauthorized PIM Asserted Forwarder 2.5. A Node May Become an Illegitimate PIM Asserted Forwarder
With a PIM Assert message, a router can be elected to be in charge of 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. forwarding all traffic for a particular (S,G) or (*,G) onto the LAN.
This overrides DR behaviour. This overrides DR behaviour.
The specification says that Assert messages should only be accepted The specification says that Assert messages should only be accepted
from known PIM neighbors, and "SHOULD" be discarded otherwise. So, from known PIM neighbors, and "SHOULD" be discarded otherwise. So,
either the node must be able to spoof an IP address of a current 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 neighbor, form a PIM adjacency first, or count on these checks being
disabled. disabled.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
The easiest attack is to deny the multicast service 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 This could mean either not forwarding all (or parts of) multicast
traffic from upstream onto the link, or not registering or forwarding traffic from upstream onto the link, or not registering or forwarding
upstream the multicast transmissions originated on the link. upstream the multicast transmissions originated on the link.
These attacks can be done multiple ways: the most typical one would These attacks can be done multiple ways: the most typical one would
be becoming the DR through becoming a neighbor with Hello messages be becoming the DR through becoming a neighbor with Hello messages
and winning the DR election. After that, one could for example: 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 send any PIM Join/Prune messages based on the IGMP reports, or
o Not forward or register any sourced packets, or o Not forward or register any sourced packets.
o Send PIM Prune messages to cut off existing transmissions because Sending PIM Prune messages may also be an effective attack vector
Prune messages are accepted from downstream interfaces even if the even if the attacking node is not elected DR, since PIM Prune
router is not a DR. 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 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 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 already been formed. For the particular (S,G) or (*,G) from the
Assert message, this creates the same result as getting elected as a Assert message, this creates the same result as getting elected as a
DR. With BIDIR-PIM similar attacks can be done by becoming the DF or DR. With BIDIR-PIM similar attacks can be done by becoming the DF or
by preventing the DF election from converging. by preventing the DF election from converging.
3.2. Denial-of-Service Attack on the Outside 3.2. Denial-of-Service Attack on the Outside
skipping to change at page 11, line 12 skipping to change at page 11, line 12
packets as well as unicast to prevent hosts using wrong source packets as well as unicast to prevent hosts using wrong source
addresses. addresses.
5. Acknowledgements 5. Acknowledgements
Greg Daley and Gopi Durup wrote an excellent analysis of MLD security Greg Daley and Gopi Durup wrote an excellent analysis of MLD security
issues [I-D.daley-magma-smld-prob], which gave inspiration in issues [I-D.daley-magma-smld-prob], which gave inspiration in
exploring the on-link PIM threats problem space. exploring the on-link PIM threats problem space.
Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci, Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci,
John Zwiebel, Stig Venaas, and Yiqun Cai provided good feedback for John Zwiebel, Stig Venaas, Yiqun Cai, and Eric Gray provided good
this memo. feedback for this memo.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This memo analyzes the threats to the PIM multicast routing protocol This memo analyzes the threats to the PIM multicast routing protocol
on host interfaces and proposes some possible mitigation techniques. on host interfaces and proposes some possible mitigation techniques.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-pim-bidir]
Handley, M., "Bi-directional Protocol Independent
Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-09 (work in
progress), February 2007.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
October 2006. October 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
8.2. Informative References 8.2. Informative References
[I-D.daley-magma-smld-prob] [I-D.daley-magma-smld-prob]
Daley, G. and G. Kurup, "Trust Models and Security in Daley, G. and G. Kurup, "Trust Models and Security in
Multicast Listener Discovery", Multicast Listener Discovery",
draft-daley-magma-smld-prob-00 (work in progress), draft-daley-magma-smld-prob-00 (work in progress),
July 2004. July 2004.
[I-D.hayashi-igap] [I-D.hayashi-igap]
Hayashi, T., "Internet Group membership Authentication Hayashi, T., "Internet Group membership Authentication
Protocol (IGAP)", draft-hayashi-igap-03 (work in Protocol (IGAP)", draft-hayashi-igap-03 (work in
progress), August 2003. progress), August 2003.
[I-D.ietf-pim-sm-linklocal] [I-D.ietf-pim-sm-linklocal]
Atwood, J. and S. Islam, "Security Issues in PIM-SM Link- Atwood, J., Islam, S., and M. Siami, "Authentication and
local Messages", draft-ietf-pim-sm-linklocal-01 (work in Confidentiality in PIM-SM Link-local Messages",
progress), July 2007. draft-ietf-pim-sm-linklocal-03 (work in progress),
February 2008.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004. Architecture", RFC 3740, March 2004.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
James Lingard James Lingard
Arastra, Inc. Arastra, Inc.
P.O. Box 10905 P.O. Box 10905
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: jchl@arastra.com Email: jchl@arastra.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 13, line 44 skipping to change at line 558
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 26 change blocks. 
46 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/