[secdir] secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15

[Stephen Farrell <[e-mail]>]

#include <secdir-review-boilerplate.h>

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.