Access control & multicast (was RE: [AG-TECH] AG Security)

Robert Olson olson at mcs.anl.gov
Tue Jul 23 03:33:55 CDT 2002


>design something where the onus on attacking multicast is just as hard as 
>for unicast? I know that snooping broadcast traffic is a lot easier than 
>unicast :-) but why treat multicast as being closer to broadcast than to 
>unicast? Since multicast has a model of "you-join-to-get-traffic", it has 
>a hook that we could play with... Ultimately though it may be impossible 
>or "unscalable".

SSM helps this a bit; you at least aren't told by the routing 
infrastructure who the active senders are. However, I bet you could still 
go to the I2 router proxies and look at the active mroutes to find them.

>It's an access issue, which has AAA overtones, so it overlaps with 
>security in some aspects.

Ah, good point. I'm trying to remember enough PIM to see where the decision 
would have to be made to allow a join; seems like all the routeres along 
the distribution tree would have to know about the allowed access to the 
traffic.

Would ratelimiting at the router ahead of a slow link be an acceptable 
solution this particular problem? (Need the tools to recognize the RTCP 
feedback and do appropriate throttling of streams that report lots of 
loss). This becomes fairly important when we start playing with things like 
10Mbps per stream MJPEG video (which we've been working again, btw, looks 
really nice. If anyone has any insights on how to do proper deinterlacing 
in either the DirectDraw or Linux environments we'd be interested :-).

--bob




More information about the ag-tech mailing list