Telechat Review of draft-ietf-avt-rapid-acquisition-for-rtp-
review-ietf-avt-rapid-acquisition-for-rtp-secdir-telechat-farrell-2010-10-29-00

Hi Ali,

On 19/10/10 16:18, Ali C. Begen (abegen) wrote:
> Sorry for not responding to this email earlier.

Me too:-)

draft-ietf-avt-rapid-acquisition-for-rtp-16 seems to me to do a good
job of addressing my comments on -15, except, perhaps, for two.

The first is that this protocol is vulnerable to off-path DoS attacks
unless SRTP is used, and even where SRTP is used, additional (though
minor) constraints on how it is used are required to prevent
authorized receivers messing with one another.

The -16 version is clear enough (I think) about this, so my only
remaining question is whether or not SRTP, with the additional
constraints specified, is likely to be deployed or not.

I have no idea myself, but if its unlikely to really be deployed,
then the vulnerability could probably easily be exploited which
would be bad and would lead me at least to wonder whether it would
be wiser to try to design this so that it is less vulnerable to
off-path attacks. (Assuming that such a solution exists of course.)

The second one relates to the additional SRTP constraints. The new
text says that the BRS needs to keep a list of receiver certs (which
seems unlikely) or else must ensure that all receivers are certified
by some "trusted" CA. I don't think that really works - if the
problem is that authorized receivers could DoS one another then I
don't see how this fixes that. Or am I missing something?

S.

PS: The text quoted is from the response to my review of -15, I
guess it makes life easier to change the subject line to -16 for
this re-review but I might be wrong. If so, sorry;-)

> I thought I did. Thanks to Robert for reminding me.
>
> All,
>
> We tried to address all the issues mentioned below in the latest version. I
will respond line by line below. > >> -----Original Message----- >> From:
Stephen Farrell [

mailto:stephen.farrell

 at cs.tcd.ie]
>> Sent: Monday, October 04, 2010 12:59 PM
>> To: draft-ietf-avt-rapid-acquisition-for-rtp.all at tools.ietf.org; sec-ads
at ietf.org >> Cc: secdir at ietf.org; avt-chairs at ietf.org >> Subject:
secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15 >> >> >> #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. > > Yes, things may go wrong if an attacker sends RAMS
control messages on behalf of others or an attacker modifies others' messages.
We ack this problem and provide some solutions to deal with it. > >> 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?) > > The SDP should be only accepted
from reliable sources. So, authentication and integrity checks are recommended.
This applies to any application using SDP. > >> - P17 says that the BRS may
reject the RAMS-R request. Are there >> security reasons that might cause
rejection? If so, what? > > Not really. The rejection reasons are mostly
related to the ones already listed in section 7.3.1. > >> - 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? > > We need to have
this since the SSRC that is known by the RTP_Rx may have changed and it has to
trust to the server for the most up-to-date SSRC. Note that here we assume the
server side (BRS) is not compromised. If it is, it does not matter. It can send
junk data w/o changing the SSRC. > >> - 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.) > > First of all, supporting the updated messages
is an optional feature, which is highly discouraged anyway (due to various
other reasons). In case, an implementation supports it, the security
considerations are not much different. Section 10 makes some proposals to deal
with this (e.g., source address validation, SRTP, policing, etc.). > >> - Could
I send a fake RTCP BYE pretending to be from some RTP_Rx in >> order to DoS
that client? > > You can but you need to know the CNAME (which is possible).
However, if RTCP messages are authenticated and source address is validated,
you will fail. > >> - 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) > > Yeah, we added a text for it. The server
should pay attention to what the client mentioned in that field. In any case,
that is an upper limit and the server can transmit at much slower pace if it
wants to. > >> - 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? > > Yes, we
added text about this as well. The server can naturally reject the decision
anyway if it computes that the client is better off by joining the mcast
immediately (rather than first receiving the burst and then joining). The
client then can join and build up a buffer as long as it wants to. > >> - 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. > > Yes, see the new text in section 10. > >> >> -
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? > > This really depends on how SDP is distributed.
It could be HTTP(S), RTSP or something else. > >> - 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.) > >
Well, in managed networks such as IPTV networks, servers and clients are known
by the system admin, configured properly, etc. so one may not need to implement
SRTP. In non-managed environments, SRTP is a good tool and if they want
protection, they better use it. > >> - p43 says RAMS itself brings no new
attacks, but surely it does create >> some new off-path DoS potential, if
messages could be guessed? > > And we tried to explain these *new* attacks in
Section 10. > >> - p43: what does "consider the security of such SRTP key
sharing mean?" >> I think this spec should say. > > We revised that part. See
the new text to see whether it works. > >> Nits/Non-security things: >> >> -
p8: CNAME is used without being defined. > > Done. > >> - p15: AVPF is used
before being defined/expanded. > > Done. > >> - 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.) > > Rephrased
this part. > >> - 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:-) > > The response codes have their own scopes. A client may not be
authorized for any RAMS operation, or maybe RAMS is not enabled only for that
stream. We explicitly say this now in the text. > >> - 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?
> > For some reason, we did not wanna use 2119 language here (I don't recall it
now). But, the idea is that it is really up to the server whether to use the
updated request or ignore it. > >> - 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? > >
Why do we need to say any 2119 language here. The server is not expecting a
RAMS-T for them, but the client could still send one. > >> - p21: the mix of
SHALL and MUST looks odd, I at least, would prefer >> just MUSTs. > > Fixed. >
>> - p21, typo s/and started/and has started/ > > Fixed. > >> - p21,
OSN-minus-one as a signal for the BRS to stop - can that OSN >> wrap around? >
> Sure it does since it is an RTP seqnum and all rtp seqnum rules apply to it
as well. > >> - 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? > > Wrapping rules are known in general I think since nobody has
asked before what they were :) and MSN is usually 0, but if it keeps
increasing, after it has reached the max value, it will naturally wrap around
(which is very unlikely to happen). > >> - p38: saying support for rfc5576 "can
also be needed" seems vague. >> Better to specifically say when its needed. > >
Expanded the text to say when it would be needed. > > Thanks much for the
careful review. > > -acbegen > >> Regards, >> Stephen. >> > >