Access control & multicast (was RE: [AG-TECH] AG Security)

[Bill Nickless]

(This is a very interesting discussion.  Please excuse my high latency on 
response; I plead infirm health!)

At 12:52 PM 7/25/2002 +1000, Markus Buchhorn wrote:
>That's what I initially thought. Now though I wonder (and I'm sure 
>somebody's already considered it) if it can be done totally at the edge, 
>where your IGMP join request goes to your first hop router. If that first 
>router can somehow check your AAA details (how are they best provided? - 
>S-IGMP?) against some profile or standard (in-band information in the 
>session, or an ldap lookup, or ...?), it could just drop the request and 
>never forward it up the tree. Hence no other routers need to make a 
>decision - since they won't be asked in the first place. That'd scale 
>linearly with the number of requesting receivers, and be distributed 
>across the number of sites. It can also be revoked, so you can kick off 
>problem sites in real time - which then also turns the AAA issue around to 
>the revoking site.

As I understand it, you're protecting against a very limited threat model: 
to wit, keeping unauthorized joiners on their subnets from attaching the to 
the distribution tree: It doesn't cover:

  - Local router compromise
  - Legitimate listener traffic sniffed by attacker on the local subnet

It also requires inter-domain AAA to be operating properly.  That's a 
pretty tough requirement; last I knew inter-domain AAA was an IRTG topic.

[Bob asks about rate-limiting multicast streams.]

>I don't know what the vendors allow you to do now (Bill?).

Based on what I've seen in the reliable multicast working groups at the 
IETF, it appears that the Digital Fountain approach for rate control is 
most dominant.  It's a very clever idea--let me see if I can summarize it:

At time zero, a source starts transmitting to a group at a relatively small 
rate.  The rate increases over time, peaking out at some high 
value.  Receivers join the group as the source is transmitting at a small 
rate, and then as the source transmission rate increases (and loss starts 
being detected) the receivers drop out.

Of course, a source is not restricted to transmitting on a single group; it 
can be transmitting at different rates to different groups.  By clever 
ordering of packets, and forward error correction, you end up with a high 
bandwidth path from the source to those receivers capable of accepting high 
bandwidth traffic.  However, you still have more moderate bandwidth 
available to those receivers that are on the other end of limited links.

Now: consider a video codec that provided multiple streams of output, at 
different bandwidths.  The source would transmit the low-bandwidth packets 
to the group first, followed by the intermediate bandwidth packets, 
followed by the high-bandwidth packets.  Receivers would get the 
low-bandwidth packets and render the basic parts of the image.  If and when 
higher-bandwidth packets arrive they could fill in the detail.

As you can imagine, there are a number of variations on this basic 
theme.  You could dispense with the active joins and leaves, simply letting 
receivers choose which multicast group to receive from based on available 
bandwidth (as determined from loss statistics).  An integrated AG control 
system could watch the audio traffic loss statistics and reduce the 
incoming multicast bandwidth of video traffic as needed.

The key idea for the AG, however, is for the video sources to encode their 
data at multiple levels of complexity, and transmit them all.  Receivers 
then should be able to choose what level of bandwidth they wish to receive 
from each source.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at mcs.anl.gov