Subject: RE: mboned: Source discovery draft for SSM

From: <[email-masked]>
Date: Fri, 13 Aug 2004 09:26:07 +0300

Thank Beau for constructive comments, my responses inline.

> -----Original Message-----
> From: Beau Williamson [mailto:[email-masked]]
>
> 3.1  Source functionality
>
> When new source, S1 wants to send to the same logical multicast
> group, G, it has to send MSDP SA message to the group controller, S.
> The message is sent to the unicast address of the group controller
> with TCP/IP using UDP port number 639.  
>
> The above is a bit unclear as to whether the source uses UDP or TCP
> to send (and periodically refresh) these messages to the controller. I
> would assume UDP so that the controller isn't burdened with maintaining
> numerous TCP connections.

ok, that was a spelling mistake from me, but it should be TCP instead of UDP. The idea was to have the normal TCP connectivity between sources and the group controller, mainly for the DoS purposes that you described in your mail. TCP prevents this source address spoofing trick by having the "return routability" functionality. It also gives some protection against attacks trying to flood in bogus MSDP traffic (UDP). What comes to the burden of maintaining numerous TCP connections, I would say that this shouldn't be problem in most cases (of course there is upper limit for simultaneous TCP connections).

>
>
> MSDP SA message MUST contain the following information:
>
>    Address of the group controller = S
>    Address of the logical multicast group = G
>    Address of the new active source = S1
>
> This brings up an issue regarding security and/or proxy MSDP source
> announcements.  It is possible that some host, S2, could send an
> MSDP-lite SA message for source S1, thereby functioning as a proxy for
> S1.  Should this be allowed?  
>
> My current thought is no, as this opens the door to a DDoS attack on the
> group by flooding the controller with "bogus" SA addresses. If
> the other members of the Logical Group respond by sending IGMPv3/MLDv2
> Joins for these bogus sources, we would generate state for all these
> bogus sources in the network. 

Proxy MSDP source announcements should be disallowed due to the reasons that you described.
 
>
> Of course, to some extent this is one of the weakness of SSM.  Any
> host can crank off bogus IGMPv3/MLDv2 joins and create state throughout
> the network. As a result, the idea of providing IGMP/MLD state limits per
> host is under consideration by equipment vendors. (Note that these sort
> of limits would effectively put an upper limit on the number of hosts
> that could participate in an SSM-based many-to-many multicast.

I'm happy to hear that you are working on providing decent tools for managing multicast networks. Evidently there will be tradeoff between multicast security and maximum number of sources per group.

>
> Possibly you want to add some text to Section 3.2, "Group Controller
> Functionality" regarding the policy decisions that clearly state
> that if the SA message [Source Address] field contains address S1, then
> it must be received from MSDP-Lite peer S1.  Unfortunately, there is
> no guarantee here either since source spoofing could be used by the
> attacker. Possibly some form of IPSec could be used here to authenticate
> the sending MSDP-lite peer.  

I'll add some text stating this. TCP already prevents the source spoofing possibility. If someone wants to use UDP for these source announcements, the IPSec authentication is clearly needed to prevent different form of DoS attacks.

>
> I would think that the draft would at least have text stating that the
> Controller "SHOULD" make use of IPSec for MSDP peer
> authentication to prevent this sort of DDoS attack.

Thanks, I'll add text regarding this.

- Rami

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Aug 2004 11:47:17 +0200

Very nice draft. I think some solution like this is needed. A very
similar approach is suggested in the expired draft
draft-hoerdt-mboned-multisource-ssm-00.txt

One advantage with your approach is that you're using TCP for the SAs
I think. The only small issue I see, is that it would require some
additional host infrastructure. Since it's using a privileged port,
you will some daemon that listens to this port and somehow notify
clients. I guess one could also consider kernel support, but I'm not
sure I like that. It would make it easy to join automatically as you
suggest which might be an interesting way of emulating SSM for old ASM
applications though.

I believe a host should be able to join two completely different
sessions (S,G) and (S',G) where the group is the same. That should
work fine though as long as the receiver checks the source address
in the IP header of the UDP MSDP SAs it receives. Else it wouldn't
know if an SA for a source belonged to (S,G) or (S',G) and hence it
wouldn't know which application/socket should join the new source.

Stig