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