Re: [MBONED] Adoption Call: draft-jholland-mboned-ambi-04

["Manfredi (US), Albert E" <[e-mail]>]

-----Original Message-----
From: Holland, Jake <[e-mail]> 

> For scale.  If you're sending full-sized (~1500-byte) multicast packets, the
authenticated manifest stream is only 1-3% of the data stream, so even with
unicast manifests you get a substantial benefit.

Thanks for the quick reply, Jake. Hmm. I get the packet size, but I thought that a manifest packet has to be sent for each multicast data packet? Is that wrong? That's the crux of my questioning. To me, the packets per unit time could become more of a scaling problem than packet size. This is what led me to believe that there is one manifest packet per data packet, although I admit, it's not 100% clear if this is the intention:

https://tools.ietf.org/html/draft-jholland-mboned-ambi-04

2.1.  Overview

   In order to authenticate a data packet, AMBI receivers need to hold
   these three pieces of information at the same time:

   o  the data packet; and

   o  an authenticated manifest containing the packet digest for the
      data packet; and

   o  a digest profile defining the transformation from the data packet
      to its packet digest.

   The manifests are delivered as a stream of manifests over an
   authenticated data channel.  Manifest contents MUST be authenticated
   before they can be used to authenticate data packets.

   The manifest stream is composed of an ordered sequence of manifests
   that each contain an ordered sequence of packet digests,
   corresponding to the original packets as sent from their origin, in
   the same order.

2.2.  Buffering and Validation Windows

   ... While holding a data packet, if the corresponding packet digest for
   that packet arrives in the manifest stream and can be authenticated,
   the data packet is authenticated.


>> Conversely, for authenticated or encrypted multicast traffic, is it not simpler to use a symmetric key stream cipher, with wide enough packet sequence numbers to permit the new secret key to be sent to all multicast group members, out of band, at a relatively low rate? If you can show that the sequence number never repeats, with a given secret key, you're done. Let's say, update the secret key daily, using any low data rate key exchange protocol.
>
> The problem with this is that the receivers do not trust each other, for instance
in a video broadcast scenario.

Good answer! My own solution, even in AMT, if this problem that receivers don't trust each other exists, is to filter every received multicast for the correct source IP address. It does make AMT more like SSM, however the filter is simple enough to implement, when security becomes a concern. I would think this approach is much more lightweight and direct, no?

Bert