[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

overcomplicated framework for multicast security without real value



My company is working on a project for Internet
streaming applications. I just finished reading "A
Framework for Group Key Management for Multicast
Security" and like to share some thoughts.

Although authors are aware of the challenges of
multicast security and understand the requirements
imposed by different multicast applications, this
framework is nearly useless in the real world.

It's too complicated to implement and deploy, and
provides little value in return for most applications.
While ISPs may celebrate the opportunity for
increasing the number on subscribers' monthly bill,
the introduction of "trunk region" complicates the
overall multicast security infrastructure and makes
secured data distribution more vulnerable since it
breaks the end-to-end security model. Some people may
not want any third-party (ISP) get involved in the
sensitive data transmission. And for most applications
(as I will discuss below), this approach doesn't
improve the scalability or performance after all.

Authors claim that the primary advantages of the
framework are (1) more scalable (2) reduced
complexity, and illustrate them on two examples:
Pay-per-view and Confidential Conferencing. Now let's
look at them one by one.

Case 1 - Pay-per-view (one-to-many): as the name says,
you have
to pay for per movie/live sport event/TV show and it's
not refundable once you make the payment (even you
change your mind after only ten minutes because the
movie sucks). After each show, you have to pay again
to register for another one. That means the lifetime
of membership is fixed. All the members have to renew
their session key for the complete next lifetime. In
another word, the application server or key
distribution server only has to maintain single
session key for everybody within a single life time
(bounded by show time) even some viewers may switch
channel or leave their computer. This type of service
is the majority of future multicast applications. The
nature of those applications is that all members have
to renew their group keys for each event. In this
case, the proposed framework doesn't provide any value
if not making it worse.

You may argue that different members may have
different lifetime, for example some couch potato may
register a whole year for every pay-per-view events
(if permitted by the ASP). But in this case, it makes
better sense for ASPs to create several different
membership levels and separate the management for each
level (within application-specific context).

In the near future, most streaming ASPs will most
likely offer two types of multicast streaming
services: monthly viewing service and pay-per-view.
Time Warner has been doing it for years in its cable
network. It seems this framework can be used to manage
monthly viewing service. Members may call up and
open/close their accounts anytime during the month.
But is it really worth going through all that trouble
while you can simply renew the key for everybody once
every day (you have to renew it sooner or later anyway
for security reason)? The point is that the timing
granularity requirement is loose.

Case 2 - Confidential Conferencing (many-to-many): the
framework fits better for this type of
application. But the nature of conference is that only
limited number of people will attend. So you don't
need scalability. You may ask: ever attend a meeting
with over hundred people? That will be a party, not a
conference. In a party, people usually gather into
smaller groups and talk about their friends' private
lives. In this case, people don't want their
conversation to be heard by everybody and it's
unnecessary for doing so. And still, even hundred
members can be
managed without any hierarchy. If the number
increases, the group/conference usually will be
divided into smaller groups each with different focus
(like how IETF divides its working groups). In most
cases the only event everybody participates may be
listening to the speech of a single member, this
becomes the one-to-many scenario.

The bottom line is that unless authors can identify
the services or applications (something requires
extreme quick response for membership change) where
this framework can
really make sense, in my opinion, we'd better be
thinking something else.

__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/