Subject: Re: private multicast groups

From: Jeff Smith <[email-masked]>
Date: Thu, 28 Aug 1997 13:48:23 -0700

Would it not be possible to engineer a sparse-mode/shared-tree where
the joins to the RP/core require a key?

js

|Hi:
|
|I am looking at ways to implement a  "private" multicast capability which 
|would allow an organization to use native multicast for private
|multicast sessions between multiple sites connected to the same 
|ISP. More specifically the ability to use addresses from the 
|Organization Local Scope 239.192.0.0/14 (or some other reserved address 
|space not conflicting with the public mbone usage) across an ISP's backbone.

---

From: Petri Helenius <[email-masked]>
Date: Fri, 29 Aug 1997 00:57:42 +0300 (EEST)

> the joins to the RP/core require a key?
Depending on the location of current receivers the joins might not
ever reach the RP.

Pete

---

From: Jeff Smith <[email-masked]>
Date: Thu, 28 Aug 1997 16:46:12 -0700

|Jeff Smith writes:
| > Would it not be possible to engineer a sparse-mode/shared-tree where
| > the joins to the RP/core require a key?
| > 
|Depending on the location of current receivers the joins might not
|ever reach the RP.

I didn't read carefully enough, and didn't construct my comment
carefully enough...

assume the use of "global multicast" addresses and limit the delivery
(formation of the tree) by requiring a key in the join message to the
RP.

Is this reasonable or possible using current technology?

|
|Pete
|
| > 
| > |Hi:
| > |
| > |I am looking at ways to implement a  "private" multicast capability which 
| > |would allow an organization to use native multicast for private
| > |multicast sessions between multiple sites connected to the same 
| > |ISP. More specifically the ability to use addresses from the 
| > |Organization Local Scope 239.192.0.0/14 (or some other reserved address 
| > |space not conflicting with the public mbone usage) across an ISP's backbone.  
| >   
| >

---

From: Petri Helenius <[email-masked]>
Date: Fri, 29 Aug 1997 07:32:08 +0300 (EEST)

> Is this reasonable or possible using current technology?
That would either need the routers to be able to verify the key or
everybody to forward it up to the RP which does not scale.

It's much better to encrypt the content and distribute key information
out-of-band.

Pete

---

From: Jeff Smith <[email-masked]>
Date: Fri, 29 Aug 1997 08:16:09 -0700

|Jeff Smith writes:
|
| > |Depending on the location of current receivers the joins might not
| > |ever reach the RP.
| > 
| > I didn't read carefully enough, and didn't construct my comment
| > carefully enough...
| > 
| > assume the use of "global multicast" addresses and limit the delivery
| > (formation of the tree) by requiring a key in the join message to the
| > RP.
| > 
| > Is this reasonable or possible using current technology?
| > 
|That would either need the routers to be able to verify the key or
|everybody to forward it up to the RP which does not scale.
|
|It's much better to encrypt the content and distribute key information
|out-of-band.
|
|Pete

But the point, I thought, was to limit delivery of the packets in the
first place - this would be possible with a restraint on (keyed) join
in a shared tree.

Maybe I'm not making sense because this is a problem I was thinking
about before - how to have a virtual network via multicast without
tunneling (essentially a tree for only those who "should" join) -
privacy/encryption was/is orthogonal to creating this tree and
allowing only authorized users to even receive the packets in the
first place.

Oh well, it was an idea anyways and I've never received a satisfactory
answer as to why this could(n't) work.  The scaling issue - maybe I
don't understand - I guess I'll go back and read the specs and see if
I'm totally insane...

js