draft-ietf-pim-lasthop-threats-04.txt   rfc5294.txt 
PIM WG P. Savola Network Working Group P. Savola
Internet-Draft CSC/FUNET Request for Comments: 5294 CSC/FUNET
Intended status: Informational J. Lingard Category: Informational J. Lingard
Expires: November 9, 2008 Arastra Arastra
May 8, 2008 August 2008
Host Threats to Protocol Independent Multicast (PIM) Host Threats to Protocol Independent Multicast (PIM)
draft-ietf-pim-lasthop-threats-04.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 Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 9, 2008. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Host-interface PIM Vulnerabilities . . . . . . . . . . . . . . 3 2. Host-Interface PIM Vulnerabilities . . . . . . . . . . . . . . 2
2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 4 2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 3
2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 4 2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 3
2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4 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 . 4 2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 3
2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 4 2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 3
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 Illegitimate PIM Asserted 2.5. A Node May Become an Illegitimate PIM Asserted
Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 5 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 4
2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5 2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 4
3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6 3. On-Link Threats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 5
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 . 6
4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 7
4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 7
4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8
4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 9 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
There has been some analysis of the security threats to the multicast There has been some analysis of the security threats to the multicast
routing infrastructures [RFC4609], some work on implementing routing infrastructures [RFC4609], some work on implementing
confidentiality, integrity and authorization in the multicast payload confidentiality, integrity, and authorization in the multicast
[RFC3740], and also some analysis of security threats in IGMP/MLD payload [RFC3740], and also some analysis of security threats in
[I-D.daley-magma-smld-prob], but no comprehensive analysis of Internet Group Management Protocol/Multicast Listener Discovery
security threats to PIM at the host-connecting (typically "Local Area (IGMP/MLD) [DALEY-MAGMA], but no comprehensive analysis of security
threats to PIM at the host-connecting (typically "Local Area
Network") links. Network") links.
We define these PIM host threats to include: We define these PIM host threats to include:
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
skipping to change at page 3, line 37 skipping to change at page 2, line 38
illegitimate 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. Subverting legitimate routers is out of scope. is out of scope. Subverting legitimate routers is out of scope.
Security implications on multicast routing infrastructure are Security implications on multicast routing infrastructure are
described in [RFC4609]. 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 Analysis of PIM-DM [RFC3973] is out of scope of this document.
This section describes briefly the main attacks against host- 2. Host-Interface PIM Vulnerabilities
interface PIM signalling, before we get to the actual threats and
This section briefly describes the main attacks against host-
interface PIM signaling, 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 illegitimate The attacking node may be either a malicious host or an illegitimate
router. router.
2.1. Nodes May Send Illegitimate PIM Register Messages 2.1. Nodes May Send Illegitimate PIM Register Messages
PIM Register messages are sent 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 Illegitimate 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 (Sparse Mode) specification recommends that PIM messages
Hellos should not be accepted except from valid PIM neighbors. other than Hellos should not be accepted, except from valid PIM
BIDIR-PIM [RFC5015] specification (Section 5.2) specifies that neighbors. The Bidirectional-PIM (BIDIR-PIM) specification specifies
packets from non-neighbors "SHOULD NOT" be accepted. However, the that packets from non-neighbors "SHOULD NOT" be accepted; see Section
specification does not mandate this, and so some implementations may 5.2 of [RFC5015]. However, the specification does not mandate this,
be susceptible to attack from PIM messages sent by non-neighbors. so some implementations may be susceptible to attack from PIM
messages sent by non-neighbors.
2.4. An Illegitimate 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 that 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 [RFC5015] a Designated Forwarder (DF) is elected per In BIDIR-PIM [RFC5015], a Designated Forwarder (DF) is elected per
link. The DF is responsible for forwarding data downstream onto the link. The DF is responsible for forwarding data downstream onto the
link, and also for forwarding data from its link upstream. link, and also for forwarding data from its link upstream.
A node which can become a BIDIR-PIM neighbor (this is just like A node that 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
the DF election from converging by sending an infinite sequence of DF prevent the DF election from converging by sending an infinite
Offer messages. sequence of DF 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 [RFC5015]. Considerations section in [RFC5015].
2.5. A Node May Become an Illegitimate 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 behavior.
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.
The Assert Timer, by default, is 3 minutes; the state must be The Assert Timer, by default, is 3 minutes; the state must be
refreshed or it will be removed automatically. refreshed or it will be removed automatically.
As noted before, it is also possible to spoof an Assert (e.g., using 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 a legitimate router's IP address) to cause a temporary disruption on
the LAN. the LAN.
2.6. BIDIR-PIM Does Not Use RPF Check 2.6. BIDIR-PIM Does Not Use RPF Check
PIM protocols do not perform RPF check on the shared tree (e.g., in PIM protocols do not perform Reverse Path Forwarding (RPF) check on
PIM-SM from the RP to local receivers). On the other hand, RPF check the shared tree (e.g., in PIM-SM from the RP to local receivers). On
is performed e.g., on stub host interfaces. Because all forwarding the other hand, RPF check is performed, e.g., on stub host
in BIDIR-PIM is based on the shared tree principle, it does not use interfaces. Because all forwarding in BIDIR-PIM is based on the
RPF check to verify that the forwarded packets are being received shared tree principle, it does not use RPF check to verify that the
from a "topologically correct" direction. This has two immediately forwarded packets are being received from a "topologically correct"
obvious implications: direction. This has two immediately obvious implications:
1. A node may maintain a forwarding loop until the TTL runs out by 1. A node may maintain a forwarding loop until the Time to Live
passing packets from interface A to B. This is not believed to (TTL) runs out by passing packets from interface A to B. This is
cause significant new risk as with a similar ease such a node not believed to cause significant new risk as with a similar ease
could generate original packets which would loop back to its such a node could generate original packets that would loop back
another interface. to its other interface.
2. A node may spoof source IP addresses in multicast packets it 2. A node may spoof source IP addresses in multicast packets it
sends. Other PIM protocols drop such packets when performing the sends. Other PIM protocols drop such packets when performing the
RPF check. BIDIR-PIM accepts such packets allowing easier DoS RPF check. BIDIR-PIM accepts such packets, allowing easier
attacks on the multicast delivery tree and making the attacker Denial-of-Service (DoS) attacks on the multicast delivery tree
less traceable. and making the attacker less traceable.
3. On-link Threats 3. On-Link Threats
The previous section described some PIM vulnerabilities; this section The previous section described some PIM vulnerabilities; this section
gives an overview of the more concrete threats exploiting those gives an overview of the more concrete threats exploiting those
vulnerabilities. vulnerabilities.
3.1. Denial-of-Service Attack on the Link 3.1. Denial-of-Service Attack on the Link
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 in multiple ways: the most typical one
be becoming the DR through becoming a neighbor with Hello messages would be becoming the DR through becoming a neighbor with Hello
and winning the DR election. After that, one could for example: 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, or o Not send any PIM Join/Prune messages based on the IGMP reports, or
o Not forward or register any sourced packets. o Not forward or register any sourced packets.
Sending PIM Prune messages may also be an effective attack vector Sending PIM Prune messages may also be an effective attack vector
even if the attacking node is not elected DR, since PIM Prune even if the attacking node is not elected DR, since PIM Prune
messages are accepted from downstream interfaces even if the router messages are accepted from downstream interfaces even if the router
is not a DR. 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
by preventing the DF election from converging. or 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
It is also possible to perform Denial-of-Service attacks on nodes It is also possible to perform Denial-of-Service attacks on nodes
beyond the link, especially in environments where a multicast router beyond the link, especially in environments where a multicast router
and/or a DR is considered to be a trusted node. and/or a DR is considered to be a trusted node.
In particular, if DRs perform some form of rate-limiting, for example In particular, if DRs perform some form of rate-limiting, for
on new Join/Prune messages, becoming a DR and sending those messages example, on new Join/Prune messages, becoming a DR and sending those
yourself allows one to subvert these restrictions: therefore rate- messages yourself allows one to subvert these restrictions;
limiting functions need to be deployed at multiple layers as therefore, rate-limiting functions need to be deployed at multiple
described in [RFC4609]. layers, as described in [RFC4609].
In addition, any host can send PIM Register messages on their own, to In addition, any host can send PIM Register messages on their own, to
whichever RP it wants; further, if unicast RPF (Reverse Path whichever RP it wants; further, if unicast RPF (Reverse Path
Forwarding) mechanisms [RFC3704] have not been applied, the packet Forwarding) mechanisms [RFC3704] have not been applied, the packet
may be spoofed. This can be done to get around rate-limits, and/or 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 to attack remote RPs, and/or to interfere with the integrity of an
group. This attack is also described in [RFC4609]. ASM group. This attack is also described in [RFC4609].
Also, BIDIR-PIM does not prevent nodes from using topologically Also, BIDIR-PIM does not prevent nodes from using topologically
incorrect addresses (source address spoofing) making such an attack incorrect addresses (source address spoofing) making such an attack
more difficulty to trace. more difficult to trace.
3.3. Confidentiality, Integrity or Authorization Violations 3.3. Confidentiality, Integrity, or Authorization Violations
Contrary to unicast, any node is able to legitimately receive all Contrary to unicast, any node is able to legitimately receive all
multicast transmission on the link by just adjusting the appropriate multicast transmission on the link by just adjusting the appropriate
link-layer multicast filters. Confidentiality (if needed) must be link-layer multicast filters. Confidentiality (if needed) must be
obtained by cryptography. obtained by cryptography.
If a node can become a DR, it is able to violate the integrity of any 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 data streams sent by sources on the LAN, by modifying (possibly in
subtle, unnoticeable ways) the packets sent by the sources before subtle, unnoticeable ways) the packets sent by the sources before
Register-encapsulating them. Register-encapsulating them.
skipping to change at page 7, line 47 skipping to change at page 7, line 6
integrity of any data streams sent by external sources onto the LAN. integrity of any data streams sent by external sources onto the LAN.
It would do this by sending an appropriate Assert message onto the It would do this by sending an appropriate Assert message onto the
LAN to prevent the genuine PIM routers forwarding the valid data, LAN to prevent the genuine PIM routers forwarding the valid data,
obtaining the multicast traffic via its other connection, and obtaining the multicast traffic via its other connection, and
modifying those data packets before forwarding them onto the LAN. modifying those data packets before forwarding them onto the LAN.
In either of the above two cases, the node could operate as normal In either of the above two cases, the node could operate as normal
for some traffic, while violating integrity for some other traffic. for some traffic, while violating integrity for some other traffic.
A more elaborate attack is on authorization. There are some very A more elaborate attack is on authorization. There are some very
questionable models [I-D.hayashi-igap] where the current multicast questionable models [HAYASHI] where the current multicast
architecture is used to provide paid multicast service, and where the architecture is used to provide paid multicast service, and where the
authorization/authentication is added to the group management authorization/authentication is added to the group management
protocols such as IGMP. Needless to say, if a host would be able to 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 act as a router, it might be possible to perform all kinds of
attacks: subscribe to multicast service without using IGMP (i.e., attacks: subscribe to multicast service without using IGMP (i.e.,
without having to pay for it), deny the service for the others on the 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 same link, etc. In short, to be able to ensure authorization, a
better architecture should be used instead (e.g., [RFC3740]). better architecture should be used instead (e.g., [RFC3740]).
4. Mitigation Methods 4. Mitigation Methods
skipping to change at page 8, line 23 skipping to change at page 7, line 31
4.1. Passive Mode for PIM 4.1. Passive Mode for PIM
The current PIM specification seems to mandate running the PIM Hello The current PIM specification seems to mandate running the PIM Hello
protocol on all PIM-enabled interfaces. Most implementations require protocol on all PIM-enabled interfaces. Most implementations require
PIM to be enabled on an interface in order to send PIM Register 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 messages for data sent by sources on that interface or to do any
other PIM processing. other PIM processing.
As described in [RFC4609], running full PIM, with Hello messages and As described in [RFC4609], running full PIM, with Hello messages and
all, is unnecessary for those stub networks for which only one router all, is unnecessary for those stub networks for which only one router
is providing multicast service. Therefore such implementations is providing multicast service. Therefore, such implementations
should provide an option to specify that the interface is "passive" should provide an option to specify that the interface is "passive"
with regard to PIM: no PIM packets are sent or processed (if with regard to PIM: no PIM packets are sent or processed (if
received), but hosts can still send and receive multicast on that received), but hosts can still send and receive multicast on that
interface. interface.
4.2. Use of IPsec among PIM Routers 4.2. Use of IPsec among PIM Routers
Instead of passive mode, or when multiple PIM routers exist on a 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 single link, one could also use IPsec to secure the PIM messaging, to
prevent anyone from subverting it. The actual procedures have been prevent anyone from subverting it. The actual procedures have been
described in [RFC4601] and [I-D.ietf-pim-sm-linklocal]. described in [RFC4601] and [LINKLOCAL].
However, it is worth noting that setting up IPsec Security However, it is worth noting that setting up IPsec Security
Associations (SAs) manually can be a very tedious process, and the Associations (SAs) manually can be a very tedious process, and the
routers might not even support IPsec; further automatic key routers might not even support IPsec; further automatic key
negotiation may not be feasible in these scenarios either. A Group negotiation may not be feasible in these scenarios either. A Group
Domain of Interpretation (GDOI) [RFC3547] server might be able to Domain of Interpretation (GDOI) [RFC3547] server might be able to
mitigate this negotiation. mitigate this negotiation.
4.3. IP Filtering PIM Messages 4.3. IP Filtering PIM Messages
To eliminate both the unicast and multicast PIM messages, in similar To eliminate both the unicast and multicast PIM messages, in similar
scenarios to those for which PIM passive mode is applicable, it might 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 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 access list. This is more effective than PIM passive mode, as this
also blocks Register messages. also blocks Register messages.
This is also acceptable when there is more than one PIM router on the 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 link if IPsec is used (because the access-list processing sees the
valid PIM messages as IPsec AH/ESP packets). However, this presumes valid PIM messages as IPsec AH/ESP packets). In this case, unicast
that the link is not used to transit unicast packets between the PIM Register messages must also be protected with IPsec or the routing
routers, or that the Register messages are also being sent with topology must be such that the link is never used to originate, or
IPsec. transit unicast Register messages.
When multiple routers exist on a link, IPsec is not required if it is When multiple routers exist on a link, IPsec is not required if it is
possible to prevent hosts from sending PIM messages at Ethernet possible to prevent hosts from sending PIM messages at the Ethernet
switch (or equivalent) host ports. This could be accomplished in at switch (or equivalent) host ports. This could be accomplished in at
least two ways: least two ways:
1. Use IP access lists on the stub routers to allow PIM messages 1. Use IP access lists on the stub routers to allow PIM messages
from the valid neighbor IP addresses only, and implement IP from the valid neighbor IP addresses only, and implement IP
spoofing prevention at Ethernet switch port level using spoofing prevention at the Ethernet-switch-port level using
proprietary mechanisms, or proprietary mechanisms, or
2. Filter out all PIM messages at configured host ports on Ethernet 2. Filter out all PIM messages at configured host ports on Ethernet
switches instead of doing it on the routers. switches instead of doing it on the routers.
The main benefit of this approach is that multiple stub routers can The main benefit of this approach is that multiple stub routers can
still communicate through the LAN without IPsec but hosts are not still communicate through the LAN without IPsec but hosts are not
able to disturb the PIM protocol. The drawback is that Ethernet able to disturb the PIM protocol. The drawback is that Ethernet
switches need to implement much finer-grained IP layer filtering and switches need to implement much finer-grained IP layer filtering, and
the operational requirements of carefully maintaining these filters the operational requirements of carefully maintaining these filters
could be significant. could be significant.
4.4. Summary of Vulnerabilities and Mitigation Methods 4.4. Summary of Vulnerabilities and Mitigation Methods
This section summarizes the vulnerabilities, and how well the This section summarizes the vulnerabilities, and how well the
mitigation methods are able to cope with them. mitigation methods are able to cope with them.
Summary of vulnerabilities and mitigations: Summary of vulnerabilities and mitigations:
skipping to change at page 10, line 26 skipping to change at page 9, line 26
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.4 | Invalid DR /DF | 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.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw |
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
| 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x | | 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x |
+-----+---------------------+-----+-----+-----+-----+-----+-----+ +-----+---------------------+-----+-----+-----+-----+-----+-----+
Figure 1 Figure 1
"*" means Yes if IPsec is used in addition; No otherwise "*" means Yes if IPsec is used in addition; No otherwise.
"Ysw" means Yes if IPsec is used in addition or IP filtering is done "Ysw" means Yes if IPsec is used in addition or IP filtering is done
on Ethernet switches on all host ports; No otherwise. on Ethernet switches on all host ports; No otherwise.
"N+" means that the use of IPsec between the on-link routers does not "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. protect from this; IPsec would have to be used at RPs.
"x" means that with BIDIR-PIM, IP access lists or RPF mechanisms need "x" means that, with BIDIR-PIM, IP access lists or RPF mechanisms
to be applied in stub interfaces to prevent originating packets with need to be applied in stub interfaces to prevent originating packets
topologically incorrect source addresses. This needs to be done in with topologically incorrect source addresses. This needs to be done
addition to any other chosen approach. in addition to any other chosen approach.
To summarize, IP protocol filtering for all PIM messages appears to To summarize, IP protocol filtering for all PIM messages appears to
be the most complete solution when coupled with the use of IPsec 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. between the real stub routers when there are more than one of them.
However, IPsec is not required if PIM message filtering or certain 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 kind of IP spoofing prevention is applied on all the host ports on
Ethernet switches. If hosts performing registering is not considered Ethernet switches. If hosts performing registering is not considered
a serious problem, IP protocol filtering and passive-mode PIM seem to a serious problem, IP protocol filtering and passive-mode PIM seem to
be equivalent approaches. Additionally if BIDIR-PIM is used, ingress be equivalent approaches. Additionally, if BIDIR-PIM is used,
filtering will need to be applied in stub interfaces to multicast ingress filtering will need to be applied in stub interfaces to
packets as well as unicast to prevent hosts using wrong source multicast packets, as well as unicast, to prevent hosts using wrong
addresses. source 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 [DALEY-MAGMA], which gave inspiration in exploring the on-link
exploring the on-link PIM threats problem space. 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, Yiqun Cai, and Eric Gray provided good John Zwiebel, Stig Venaas, Yiqun Cai, and Eric Gray provided good
feedback for this memo. feedback for this memo.
6. IANA Considerations 6. Security Considerations
This memo includes no request to IANA.
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 7. References
8.1. Normative References 7.1. Normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I.
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Kouvelas, "Protocol Independent Multicast - Sparse
Protocol Specification (Revised)", RFC 4601, August 2006. Mode (PIM-SM): 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, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L.
"Bidirectional Protocol Independent Multicast (BIDIR- Vicisano, "Bidirectional Protocol Independent
PIM)", RFC 5015, October 2007. Multicast (BIDIR-PIM)", RFC 5015, October 2007.
8.2. Informative References 7.2. Informative References
[I-D.daley-magma-smld-prob] [DALEY-MAGMA] Daley, G. and J. Combes, "Securing Neighbour Discovery
Daley, G. and G. Kurup, "Trust Models and Security in Proxy Problem Statement", Work in Progress,
Multicast Listener Discovery", February 2008.
draft-daley-magma-smld-prob-00 (work in progress),
July 2004.
[I-D.hayashi-igap] [HAYASHI] Hayashi, T., "Internet Group membership Authentication
Hayashi, T., "Internet Group membership Authentication Protocol (IGAP)", Work in Progress, August 2003.
Protocol (IGAP)", draft-hayashi-igap-03 (work in
progress), August 2003.
[I-D.ietf-pim-sm-linklocal] [LINKLOCAL] Atwood, J., Islam, S., and M. Siami, "Authentication
Atwood, J., Islam, S., and M. Siami, "Authentication and and Confidentiality in PIM-SM Link-local Messages",
Confidentiality in PIM-SM Link-local Messages", Work in Progress, February 2008.
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,
Group Domain of Interpretation", RFC 3547, July 2003. "The 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
Networks", BCP 84, RFC 3704, March 2004. Multihomed 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
Architecture", RFC 3740, March 2004. 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.
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC - Scientific Computing Ltd. CSC - Scientific Computing Ltd.
Espoo Espoo
Finland Finland
Email: psavola@funet.fi EMail: psavola@funet.fi
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 (2008). 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
 End of changes. 59 change blocks. 
169 lines changed or deleted 147 lines changed or added

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