Kevin C. Almeroth wrote: >>>Multicast is necessarily a LOT weaker: >>> >>> 1) I can get a copy of packets by normal operation >>> (join a group). there is no equivalent for UDP, >>> notably for paths that aren't shared. >> > > Again, not in all cases. You over-simplify the effectiveness of scoping.
Scoping, like TTL, can limit the visibility of packet outside a boundary, but cannot do much about other users inside that boundary. PS - how can you know that the scope of ALL multicast exit paths have been properly scoped to limit access outside of some physical locale? > You can't have it both ways. Yes, there is a situation where you can obtain > a copy of a multicast packet through standard operation. But the fact > that scoping and addressing make it non-trivial and the fact that "normal" > operation doesn't prevent you from snooping UDP packets shrinks the > gap from a "LOT" weaker. And as I said before, if data security is important, > effectively there is no gap. Users without root can run programs that listen to multicast addresses. If that user is inside the scope boundary, game over. As I said, weakER. IMO, still quite a lot weaker than unicast. >>> 2) UDP has application, network, and tunnel encryption that >>> is both widely deployed and widely used. there is >>> no equivalent for multicast. > > I disagree... a number of commercial multicast apps have encryption. > Don't try and argue now that some relative percentage of multicast apps > have less encryption than unicast apps. You're comparing a protocol that > has been around a lot longer than multicast and trying to make an > apples-to-apples comparison based on less availability. I can argue relative percentages just fine; we're talking about strength today, not 'strength after X years of deployment'. > And for the record, multicast is UDP. As I was using it, agreed. (there are other protocols that use multicast as well) Joe
