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

[Stephen Farrell <[e-mail]>]

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:[e-mail]]
>> Sent: Monday, October 04, 2010 12:59 PM
>> To: [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> 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.
>>
> 
>