Subject: RE: [MSEC] De-registration protocol?

From: Ran Canetti <[email-masked]>
Date: Thu, 5 Jul 2001 15:12:51 -0400

Sandro, you're right that this business model of pay-until-you-say-enough
is susceptible to this type of failures. This is indeed something that the
application will have to deal with... but this business model seems to be 
attractive in some cases nonetheless. (one way to mitigate this is to put 
a cap on the payment amount,  on the duration, etc. for instance in a boxing 
show you never pay more than the full 12 rounds.) 

Ran

> From [email-masked] Mon Jul  2 06:18:31 2001
> 
> 
> Ran,
> 
> Applications are prone to crash when you least expect :(. When that occurs,
> paying members may pay much more then they are supposed to for the simple
> reason that the de-registration/leave command was never issued.
> De-registration/leave command is not enough to control the time a member is
> participating in the group...
> 
> Sandro.
> 
> |  BTW, Mark, in a model where a member pays acording to the
> |  time elapsed
> |  between registration and de-registration, the
> |  de-registration mechanism
> |  is not just for being nice. And this is true regardless of how these
> |  protocols are called...
> 
> 

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: "Carl F. Muckenhirn" <[email-masked]>
Date: Thu, 5 Jul 2001 15:31:56 -0400

It seems to me that this question of business model has nothing at 
all to do with key management. One could just as easily saddle the 
multicast transport system with these requirements. (Seems we are 
falling into the typical security trap of "well no one else is doing 
it, why not security!")

Ran's comment on mitigations, points the way to a solution, use an 
application service to manage the billing. One could then effect 
their service delivery decisions through key management. That seems 
much more straightforward than trying to effect billing decisions 
through key management.

carl.

-- 
Carl F. Muckenhirn
Division Manager
SPARTA, Inc.
Security Engineering Division
9861 Broken Land Parkway, Suite 300
Columbia, Maryland  21046
410.381.9400 x208
410.381.5559 (fax)

---

From: Mark Baugher <[email-masked]>
Date: Thu, 05 Jul 2001 14:55:48 -0700

I agree.

Mark
At 03:31 PM 7/5/2001 -0400, Carl F. Muckenhirn wrote:
>It seems to me that this question of business model has nothing at all to 
>do with key management. One could just as easily saddle the multicast 
>transport system with these requirements. (Seems we are falling into the 
>typical security trap of "well no one else is doing it, why not security!")
>
>application service to manage the billing. One could then effect their 
>service delivery decisions through key management. That seems much more 
>straightforward than trying to effect billing decisions through key management.
>
>carl.
>