Subject: RE: mboned: Source discovery draft for SSM

From: <[email-masked]>
Date: Fri, 13 Aug 2004 14:15:15 +0300

> > No need to go to kernel level, but a general source 
> discovery library would be nice to have (implementation under 
> construction).
> 
> Yes, no need for kernel support, but you will at least need something
> that has root privileges to listen to that port and communicate with
> applications. An application library is useful, but you shouldn't
> require applications to have root privileges. This of course depends
> a bit on operating systems etc and is an implementation 
> detail. I think
> this issue need to be considered though.

Ok, I have to consider of changing the port number in the draft.

> 
> > > 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.
> > 
> > It's possible to have two different sessions with the same 
> group address, although then the logical multicast group 
> concept is not valid anymore. Then you also lose the ability 
> to leave all sources with simple IGMP/MLD Leave (*,G) message 
> (which isn't a big thing, but...). In IPv6 there shouldn't be 
> any need to have same group address for two different 
> sessions, in IPv4 there might be some need, do you have some 
> requirement behind your proposal? It's similar to ASM in that 
> context that the group address define the multicast session 
> (at least in network level, where UDP port numbers are not 
> considered).
> 
> I guess I agree. There is a tiny risk though that two independent
> sessions use the same group, so I think it's good to handle that case
> if you can. It's not a big concern, but I think it's worth having in
> mind. You may want to check the IP header source address of the UDP SA
> packets anyway to be sure they came from the controller. Else you're
> vulnerable to DoS attacks.

You are right that the check should be part of the functionality as it is in the source - group controller interface. Have to add that into the next revision of the draft.

> Another thing that perhaps should be considered, is whether you can
> have a controller that is not itself a data source for the virtual
> group. That is, only announcing sources, not sending any other data.
> I see at least some possible uses for that. But I think that is doable
> with your approach.

Yes, the group controller is not required to send any multicast data in addition to source discovery related signalling.

> 
> I think the main problem with approaches like yours (and that other
> draft) compared to ASM, is that you require someone to "own" the
> session. That is, you need to pick one source to be responsible for
> the control function, and you have a problem if that one source
> becomes unreachable, crashes or simply wants to leave. This might be
> problematic if you have long lasting sessions with no-one in 
> particular
> being the owner. You have some of the same issues with 
> Embedded-RP too.
> I think that is hard to overcome, and it's perhaps an acceptable
> limitation.

You could implement the group controller as a separate functionality (not sourcing any traffic) and put it in place, which guarantees high availability to overcome the problem. If you want to do the change for some reason, you have to consider that fact that there could be also some access lists implemented within the group controller that allows only some hosts to source traffic to the multicast group. That makes it harder to change the group controller functionality to some other source, because you have to share also additional policy information. In cases where there is no source control, this could be possible to implement, but complicates the overall functionality quite a lot. One problem is that receivers perhaps only trust to the group controller that they have specified in their (C, G) joins from the application (C meaning group controller address) and they are not willing to accept any signalling from the other hosts (possible DoS attack here as well).

> 
> I've been mulling a bit over possible solutions to this. What 
> I have in
> mind is designating another source as a backup controller, so that if
> the controller goes away, the sources know they should establish MSDP
> peerings with another particular source, and the receivers 
> are ready to
> accept the UDP SAs. One could even consider solutions where any source
> can be a controller, so that as long as you have sources you also have
> at least one controller... If the protocol had supported a way for a
> source to say whether it's willing to be a backup controller, and
> perhaps some priority value... One problem is of course session
> announcements. People need somehow to know what the current controller
> channel is to join the session. Well, this is just some idle
> speculations, I'm not sure whether it's worth considering.

If you come up with some decent solution to that, I would be happy to hear about it.

- Rami

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

---

From: Beau Williamson <[email-masked]>
Date: Fri, 13 Aug 2004 10:05:36 -0500

At 8/13/2004 06:15 AM, [email-masked] wrote:

>You could implement the group controller as a separate functionality (not 
>sourcing any traffic) and put it in place, which guarantees high 
>availability to overcome the problem. If you want to do the change for 
>some reason, you have to consider that fact that there could be also some 
>access lists implemented within the group controller that allows only some 
>hosts to source traffic to the multicast group. That makes it harder to 
>change the group controller functionality to some other source, because 
>you have to share also additional policy information. In cases where there 
>is no source control, this could be possible to implement, but complicates 
>the overall functionality quite a lot. One problem is that receivers 
>perhaps only trust to the group controller that they have specified in 
>their (C, G) joins from the application (C meaning group controller 
>address) and they are not willing to accept any signalling from the other 
>hosts (possible DoS attack here as well).
>
> >
> > perhaps some priority value...

Maybe you extend the policy definition to include which nodes are "trusted" 
as backup controllers.  This is no different than we have now with C-RP's 
who may be configured with policy filters.  It is the responsibility of the 
network administrator to insure they are configured correctly and then 
apply filters to ignore any bogus C-RP's.

Of course I'm primarily thinking within the Enterprise space here where a 
single administrator controls the entire domain.  However, you could still 
make this work inter-domain if you coordinated with the other domain admins 
regarding backup controller policy definition.

Another solution would be to use IPSec to authenticate the Backup 
controller and then check to see if the policy allowed this node to be 
Backup controller.  If so, then the Main Controller could transfer the 
current policy to the Backup controller; again using IPSec.

Of course all of this is taking the protocol from the light-weight category 
to something a bit more complex.  Maybe for the first go-round you just 
skip all of these policy mechanisms and add them to the protocol down the road.

>One problem is of course session

How is this solved now?  It isn't.  Or at least it is the responsibility of 
the application to figure this out by manual configuration, well-known 
group address or some "other" method.  Not sure you want to tackle this 
problem as part of your draft since "Session Discovery" has always tended 
to be outside of the scope of the actual multicast mechanisms.

Beau Williamson