Subject: [pim] last-hop threats by hosts to PIM (fwd)

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Jan 2005 20:46:05 +0200 (EET)

I received no comments to this, so re-sending again..

Please, do read and send comments for:
http://www.ietf.org/internet-drafts/draft-savola-pim-lasthop-threats-00.txt

It's very short, only about 5 pages, but could be very useful work as 
Informational.

---------- Forwarded message ----------
Date: Tue, 23 Nov 2004 11:51:06 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: [pim] last-hop threats by hosts to PIM

Hi,

Based on the discussions on the list, and encouragement from a couple of 
people, plus a suggestion that it might make sense to try to attack this 
problem separately from the IGMP/MLD perspective, I've written a short I-D 
(only 10 pages, including the boilerplates!) on the last-hop threats by hosts 
to PIM:

Abstract
    Security threats analysis has been done on some parts of the
    multicast infrastructure, but the threats specific to the last-hop
    attacks by hosts on the PIM routing protocol have not been well
    described in the past.  This memo aims to fill that gap.

It has been submitted, but in the interim, available at:

http://www.netcore.fi/pekkas/ietf/draft-savola-pim-lasthop-threats-00.txt

This complements I-D.ietf-mboned-mroutesec and I-D.daley-magma-smld-prob.

Feedback is welcome!

In particular, I would be interested in getting expert opinion on the following 
XXX points:

    It seems that a DR can send PIM messages (like Prune/Join) to the
    non-DR to be forwarded upstream on behalf of directly connected (to
    both DR and non-DR) sources.  In other words, a host on a stub LAN
    can be elected as a DR and act as a "man-in-the-middle" between the
    other hosts and the real PIM router.  [XXX: Is this correct?  Should
    non-DRs reject forwarding upstream messages from downstream LAN's
    DRs, because a real DR should have its own upstream connectivity?]
...
    With a PIM Assert, a router can be elected to be in charge of
    handling all traffic from a particular (S,G) (where S might also be
    all of S? [XXX: true?]).  This overrides DR behaviour.
...
    As noted before, it is also possible to spoof an Assert on someone
    else's behalf to cause a temporary disruption on the LAN.  However,
    it is not 100% clear what happens when the router which was spoofed
    receives "it's own assert" and CouldAssert(S,G,I) is False?  [XXX: a
    PIM expert should say something?  Is this an issue in the state
    machine?]

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Beau Williamson <[email-masked]>
Date: Tue, 04 Jan 2005 20:10:45 -0600

>It's very short, only about 5 pages, but could be very useful work as 

Pekka,

Comments below.

Section 2.1 Sending PIM Register Messages on Your Own

PIM Register messages are sent as unicast-encapsulated messages. 
Maliscious[sic] hosts could also send registers themselves for example to 
get around the rate-limiters, to interfere with foreign RPs, etc.

You might want to expand this a bit.  A malicious host could even spoof the 
IP address of the current DR in the Register message. If this is done for 
an active group that has receivers in the PIM domain, this would result in 
bogus (S,G) state being setup to the spoofed DR.  Possibly even worse, if 
the host begins sweeping ranges of local source addresses (i.e. addresses 
on the same subnet) along with group ranges, it could bring the RP to its 
knees by creating massive amounts of (S,G) state at the RP.  Even if state 
limits are in effect on the RP, this could deny valid (S,G) sources from 
getting registered.

Section 2.3 Becoming an Illegitimate PIM DR

Yes, this is correct.  There are valid cases (IMHO) that can result in the 
DR not having upstream connectivity.  Hence, I believe that this is a valid 
attack scenario.
Section 2.4 Becoming an Illegitimate PIM Asserted Forwarder

Yes, this is also true.

3.3  Confidentiality, Integrity or Authorization Violations

...

A more elaborate attack is on authorization.  There are some 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 of the others on the 
same link, etc.

[soap-box]
This is a perfect example where I think reliance on network layer protocols 
(i.e. IGMP/MLD with extensions] to guarantee access to paid multicast 
service such as video content is sheer folly.  If you have such content, it 
must be encrypted to have any hopes of providing Conditional Access.  Period.
[/soap-box]

4.2  Use of IPsec among PIM Routers

Instead of Passive mode, or when multiple PIM routers exist for 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 
[I-D.ietf-pim-sm-v2-new] and[I-D.atwood-pim-sm-linklocal].

However, it is worth noting that setting up IPsec 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.

Yep.  Basically, what is needed is GDOI for the PIM Control plane so that 
all routers authenticate themselves to the GDOI server and get the current 
control plane keys.  These keys would be used to provide IPSec on all 
224.0.0.13 link-local PIM control packets.

4.3  IP Filtering PIM Messages

To eliminate the PIM messages, and other PIM signalling, in the similar 
scenarios as with PIM Passive Mode, it might be possible to block IP 
protocol 103 (all PIM messages) as an input access-list.

True, but Filtering all PIM messages and likewise PIM Passive Mode may not 
be too useful in the real world since most networks provide some form of 
redundancy, hence the need to see the other PIM router on the link.

4.4  Summary of Vulnerabilities and Mitigation Methods

Unless I'm missing something, I think your Figure 1 has a mistake.  The use 
of IPSec should be effective against bogus Registers to the RP.  Therefore, 
you should change the "N" in the first row under IPSec to "Y".

Finally, I'm not sure I agree that "filtering" is a valid solution against 
a malicious host attack.  It should work well against "misconfigured" 
routers but a truly malicious host can spoof source IP addresses and 
generate chaos in the PIM domain and potentially outside of it.

IMHO, IPSec is the "only" solution here.

BTW, this document is a double-edge sword.  We are quite nicely documenting 
how to attack a network via multicast.  We've been lucky so far but I would 
suspect that these sort of attacks will eventually be tried by someone.

Beau Williamson