All things related to multicast

[Pavlin Radoslavov <>]

> The problems with MSDP state are well known and some knobs have already
> been added by vendors to reduce impact there.  However, there are also
> potential problems with IGMP and PIM state.  PIM being probably the more
> critical protocol to be concerned about initially.
> 
> Within a PIM domain, an attacker or broken application could generate
> packets destined to 224/4 networks.  Presuming no PIM filters in place,
> significant PIM state could be put into PIM domain routers.  If nothing
> else, state gets setup between the first hop PIM router and the RP for
> registration messages.  If packets to these addresses are repeated or
> purposely kept active, PIM routers in between almost certainly become
> victim to state attacks as well.

I presume you are talking about the (S,G) state that is created
between the RP and the first-hop PIM router for the sender.
Usually, this state is created by the (S,G) Join originated by the
RP (unless there is an (S,G) Join by some other downstream
router).
Typically, the RP originates the (S,G) join after the first data
packet from the sender, but if the RP is configured to originate the
Join after the sender's bandwidth is above a threshold, then the
(S,G) state between the RP and the first-hop router will be created
only for high-bandwidth senders.
Indeed, this solution has the drawback that the RP then would have
to do the extra work for Register decapsulation for the
low-bandwidth senders, so there is a tradeoff between adding extra
state to the network or adding extra work to the RP.

> Note, the problem lies in the fact that end hosts can create (and
> destroy?) forwarding state in internetwork devices, something unicast
> routing does not inherently allow.  I'm ignoring layer 2 table address
> flooding on LAN bridges/switches, which is another problem.
> 
> My initial thought was that knobs could be added to limit and/or rate
> limit the number of PIM registers for any unique source IP.  Timers
> could also be used to aggressively time-out state.

I doubt that this will really solve the problem. It may reduce the
impact, but it is more likely it will create just more headaches.


There is an alternative solution for the PIM Register processing,
and the (S,G) state between the RP and the first-hop routers for
each sender:
  Bi-directional PIM-SM (see draft-ietf-pim-bidir-04.{ps,txt}).

No more PIM Register encap/decap, and no (S,G) state, or even (*,G)
state between the RP and the first-hop routers for the
senders. E.g., Section 3.3.1 in the above draft says:

<CITE>
3.3.1.  Source-Only Branches

Source-only branches of the distribution tree for a group G are branches
which do not lead to any receivers, but which are used to forward
packets traveling upstream from sources towards the RP.  Routers along
source-only branches only have the RPF_interface to the RP in their
olist for G and hence do not need to maintain any group specific state.
Upstream forwarding can be performed using RP state.  An implementation
may decide to maintain group state for source-only branches for
accounting or performance reasons.
</CITE>

Of course, Bidir-PIM solves the routing state and CPU problem for
malicious senders, but it doesn't solve the problem for malicious
receivers that may trigger a huge number of Join state/messages
toward the RP. That is a problem that probably should be solved at
the edges like you suggest (e.g., by limiting the IGMP requests per
host/subnet or something like this).

Regards,
Pavlin

> Similarly, IGMP requests to join a group could be used to cause IGMP
> state at edge routers and possibly to cause a 'pull' flooding attack. 
> Similar knobs to limit and/or rate limit IGMP messages could be used.