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

["Holland, Jake" <[e-mail]>]

Hi Bert,

Thanks for taking a look and for asking questions!

On 3/8/20, 6:15 PM, "Manfredi (US), Albert E" <[e-mail]> wrote:
>    If the manifests, in AMBI's current incarnation, are unicast, then why bother with the multicast stream at all? Why not unicast the data in authenticated or encrypted packets, the same way as the manifests have to be unicast?

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.

We do also hope eventually to publish a way to send the manifests over multicast
with a one-way asymmetric signature scheme, but that's not as far along yet, and
we think we can get a big efficiency gain even with the simpler unicast manifest
stream.

I went over this a bit in Singapore, if you want a slightly longer explanation:
https://www.youtube.com/watch?v=ttGJyd5is2w&t=1h07m45s

I maybe should also add a paragraph or 2 to the draft if this isn't clear from the
text, thanks for raising it.

>    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.

So if all the receivers share a secret, there's a problem if any of those receivers
are able to inject traffic into the data stream, and that's not as hard as one might
wish if you're using AMT for ingest, or if the network itself injects traffic for its
end users (evidently this has happened before in some flavors of ad-hijacking, but
could also be used for things like packets of death that could compromise receivers).

This is addressed in one of the references from the intro section of AMBI describing
the motivation, but maybe I should import the description of that issue for a better
in-line explanation if it isn't clear.  But this section of TESLA gives an explanation:
https://tools.ietf.org/html/rfc4082#section-1

Best regards,
Jake