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