>>> First point: not necessarily. Not necessarily means there is an existance proof. The point was that there are more ways to snoop traffic than having access to a router. >>It only requires being on a non-IGMP'd switch or a hub; at that point, >>you can snoop the traffic and see any packet going to any multicast group. >> >>It's much harder to snoop UDP; for non-broadcast, you'd have to be >>in-line (on the wire, effectively) or on a hub. While hubs are becoming >>less common, they're often being replaced with cheaper non-IGMP-capable >>switches. Which means that they're still hubs, as far as multicast >>traffic is concerned. Without a dobut you are right, though I think the degree of difference is awful small. Through hosts with root on switches or through wireless into the mix and you are back to being roughly equivalent. However, for any reasonable content provider the difference shouldn't matter. If you have sensitive/valuable content, whether it is unicast or multicast, it should be protected. To say that multicast isn't being used because there isn't security is a non-sequitor. >>Alternately, if you're on a non-IGMP'd switch or a hub, and someone else >>on the LAN is a member of the group, then you don't have a 28-bit key. >>You can snoop and see the list of addresses in use, a much smaller set. >> >>Finally, there are rules that hint at how to use subsets of addresses >>for different uses (notably different scopes), e.g., RFC2365, a BCP. >>That makes finding the 'needle in the haystack' much easier, e.g., if >>you're hunting for teleconferencing, unless overrides are used, the >>space is 15 bits, not 28. Better yet, try RFC3171. Bottom-line: there are weak links in the chain. But, if those weak links weren't there, other links would be weak links, and THOSE weak links would still be weak enough to require using encryption. It just so happens that the weak multicast links are only a bit weaker than the unicast links. Understand that convoluted logic? :-) -Kevin