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

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

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Monday, October 25, 2010 4:53 PM
> To: Ali C. Begen (abegen)
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
> 
> 
> 
> On 25/10/10 15:04, Ali C. Begen (abegen) wrote:
> > Hi Stephen,
> >
> > This time, hopefully a quick answer.
> 
> Let's keep it up while we can:-)
> 
> >> 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.).
> 
> Fair enough. I've no idea if this application is more likely
> to be used as a potential DoS vector, compared to others with
> the same issues.

We will see. IPTV is one of the mostly used multicast (SSM) application out there. So, RAMS will be a good test.
 
> > If we really need further explanation about SRTP, I will get together with my SRTP-savvy friends and work on this.
> 
> Don't think that's needed myself, its more whether or not
> SRTP is a real solution that'll be used, and as I say, I've
> no idea about that.
> 
> >> 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.
> 
> Sure. But I guess there are other situations where RFCs say
> e.g. "use s/mime" but we know that people just don't do that.

Indeed.
 
> >> 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 ;)
> 
> Right. And I assume that the AVT WG and the IESG might know
> if that hope is likely to be realised.
> 
> To be clear, I'm not asking for a change to -16 here, I'm really
> asking if -16's use of SRTP is likely to happen or not, and if
> not, (which you guys may know), then whether that's considered
> ok or not.

I don't have a concern at least for the applications we are considering RAMS for. If IESG will have, then I hope we will figure out something.
 
> >> 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 ;)
> 
> Well, hit by anyone else who can change a channel using
> that BRS, which presumably is more than just my friends.

The example was just funny and I could not resist sending :)
 
> > 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?
> 
> I guess so, though that then depends on each receiver having
> a key pair and cert, which is probably a deployment headache.

Yes, that would be a concern if the server needs to deal with e.g., 100K clients.

> Is there no other way that this protocol could be hardened
> against off-path DoS attempts? E.g. if messages contained a
> nonce that had to be present in each subsequent message if
> it was present in the first? Maybe the WG considered that
> and rejected it, I don't know.

Actually, there is a normative reference for RAMS, which is the port mapping stuff:
http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02
https://datatracker.ietf.org/idtracker/draft-begen-avt-token-for-portmapping/

These add a natural protection since they require a cookie or token validation (which verifies the address (and maybe the port) of the client). The work is still in progress but eventually, regardless of which approach is chosen, it will hopefully avoid somebody else using your cookie/token so in theory they cannot hijack your RAMS session.

Cheers, acbegen.