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