[secdir] secdir review of draft-ietf-mmusic-delayed-duplication

[Radia Perlman <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document is about allowing a sender of a multicast stream to advertise
that it will be sending duplicate streams offset in time, so that receivers
can receive multiple copies...so that if packets are lost they will
hopefully receive it from the later stream(s).

>From a security point of view, there's no reason to complain.  However, I'm
really dubious about what this will be used for, and whether this is the
best way to solve the problem.  How does one cope with loss?  For
instance...
a) request retransmissions of specific missing pieces, perhaps not from the
original source, but from a redistribution point (e.g., zillions of
scalable reliable multicast protocols that were talked about/published
years ago)
b) send forward error correction so that the data can be reconstructed
(e.g., Digital Fountain)
c) cope with glitches on your video when in rare cases, e.g., network
topology changes, some data gets lost

I'm not sure multicast is used so much anyway.  What are the applications
today?  It seems like most video is individual on-demand rather than
multicast.  And if there were some sort of multicast thing (like a sporting
event), it seems like any combination of a), b), and c) above would be
preferable to multicasting everything multiple times.

A specific comment:  In the security considerations section it says "the
SDP description needs to be integrity protected..."  Is this MUST be?
 SHOULD be?

Radia