#include This document defines a way for multicast receivers (e.g. IPTV clients) to rapidly acquire the reference information required to make sense of the session data. Reference information is usually only sent periodically within the session, so this document defines how to setup a new unicast session with a server that transmits the reference information to the client on request so as a result the client doesn't have to wait so long. Overall, I'm a bit concerned that this might create new DoS exploit potential, but I could be wrong (don't know enough about multicast) and I see there has been a separate thread on ietf-discuss that had some mention of that. (I've not read that thread in detail.) If an off-path attacker could insert RAMS-* messages with values that are likely to result in things happening then that, I think, would be quite bad, but I'm not quite sure. Detailed security-related issues/questions: - How does the client know that it has the right FT/BRS? (Does it always get that from SDP?) What would happen if it has a bogus FT/BRS? (Is that likely?) - P17 says that the BRS may reject the RAMS-R request. Are there security reasons that might cause rejection? If so, what? - P18 says that the BRS can replace the SSRC from the RAMS-R with something else. Wouldn't that allow a bad BRS to redirect an RTP_Rx to some dodgy stream, instead of the one requested? Should the RTP_Rx react to that somehow? - How are updated RAMS-R and RAMS-I related to originals? Is there a way to insert these (maybe from off-path?) If there is, could a fake RAMS-I mount a DoS on the RTP-Rx? (E.g. by supplying crap information.) - Could I send a fake RTCP BYE pretending to be from some RTP_Rx in order to DoS that client? - Could I send a RAMS-R requesting a very high bitrate for a burst as a way to DoS someone local to the (claimed) source of the RAMS-R? (The max is 2^64 I guess) - p31: the Min RAMS buffer fill requirement seems to allow RTP-Rx to request almost 50 days (2^32ms) of content in the unicast burst. That seems too much, from the p-o-v of potential DoS exploits. Maybe say that the BRS SHOULD impose some limit as part of DoS mitigation? - p35: the earliest join time is also a 32 bit millisecond counter. Should the RTP_Rx also have some kind of sanity check if asked to wait days? Same comment wrt burst duration. - p42: Saying "adequate" security measures are "RECOMMENDED" to protect SDP description, without saying what they might be, is very vague. What's an implementer supposed to do? - p43 mentions SRTP as a SHOULD. How widely is that deployed and does it make sense for this use-case? I think that should be clear. (If SRTP isn't really used, or if its not going to be used here, then its not a real countermeasure.) - p43 says RAMS itself brings no new attacks, but surely it does create some new off-path DoS potential, if messages could be guessed? - p43: what does "consider the security of such SRTP key sharing mean?" I think this spec should say. Nits/Non-security things: - p8: CNAME is used without being defined. - p15: AVPF is used before being defined/expanded. - p18: Saying "If the RTP_Rx will issue a ..." seems confusing. Would that be clear to an implementer? In other words ought the spec say SHOULD somewhere here? (In which case, it'd also presumably say when its ok not to follow the SHOULD.) - p19: This says that if the BRS has given a 504 etc. reject, then the RTP_Rx MUST NOT retry. Does that mean just for this stream or for any stream? Its not clear to me if the "MUST NOT" is scoped to one "channel change" button press, or many, and if many, how that'd ever be reset, though that might be my ignorance of the use-case and multicast in general:-) - p20 says the BRS "can" use the updated RAMS-R - that's not 2119 language, so I assume you mean "MAY" and the intent is to allow implementers to handle updated RAMS-R in whatever way suits best, given their internal state when the update arrives? - p21 says "there is no need" to send RAMS-T for rejected stuff. Maybe that'd be better as a MUST NOT or SHOULD NOT? - p21: the mix of SHALL and MUST looks odd, I at least, would prefer just MUSTs. - p21, typo s/and started/and has started/ - p21, OSN-minus-one as a signal for the BRS to stop - can that OSN wrap around? - p34: what are "the regular wrapping rules" for MSN and how does that work with an 8 bit field that is only zero when a new RAMS-R is received? - p38: saying support for rfc5576 "can also be needed" seems vague. Better to specifically say when its needed. Regards, Stephen.