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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Stephen,

This time, hopefully a quick answer. 

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Monday, October 25, 2010 3:46 PM
> To: Ali C. Begen (abegen)
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
> 
> 
> 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.

Good.
 
> 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.

First of all, while RAMS could be favored more by the attackers due to the damage it can make, the same set of problems exist in any scenario where a feedback target (receiving feedback from multicast receivers) is supposed to act on them (doing retransmissions, or asking the actual media source to slow down, speed up, etc.).

If we really need further explanation about SRTP, I will get together with my SRTP-savvy friends and work on this.
 
> 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.

Well, I think we are only responsible to mention the problems and possible solutions. We cannot force vendors to implement everything from A to Z. The first deployment that RAMS has is the IPTV networks (for fast channel change). In such environments, the networks are managed and clients are deployed by the operator anyway. So, many of these concerns are not even relevant. I'd imagine they would not care much about SRTP.

In other areas, SRTP could be needed, but will it be always used? It is not up to me.
 
> 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.)

I would not say it is very unlikely as SRTP exists today in many VoIP applications. So, the code is available. It is not rocket science, either. So, there is hope ;)
 
> 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?

Hit by your friends? E.g., the wife's set-top can attack the husband's set-top if her channel changes are getting slower. That is a tough problem to fix, though ;)

I think this can be only solved if each unicast session is associated with the initial requestor's cert. So, only the messages with the right cert can cause changes in that session. Would that solve the problem?

-acbegen
 
> 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;-)