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

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Oct 2010 17:58:48 +0100

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 19 Oct 2010 08:18:40 -0700

Sorry for not responding to this email earlier. 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:[email-masked]]
> Sent: Monday, October 04, 2010 12:59 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-15
> 
> 

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.
 
> always get that from SDP?) What would happen if it has a bogus FT/BRS?

The SDP should be only accepted from reliable sources. So, authentication and integrity checks are recommended. This applies to any application using SDP.
 
> 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.
 
> some dodgy stream, instead of the one requested? Should the RTP_Rx

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.
 
> 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.).
 
> 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.
 
> a way to DoS someone local to the (claimed) source of the RAMS-R? (The

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.
 
> 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.
 
> days? Same comment wrt burst duration.

Yes, see the new text in section 10.

> What's an implementer supposed to do?

This really depends on how SDP is distributed. It could be HTTP(S), RTSP or something else. 
 
> isn't really used, or if its not going to be used here, then its not a

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. 
 
> some new off-path DoS potential, if messages could be guessed?

And we tried to explain these *new* attacks in Section 10.
 
> I think this spec should say.

We revised that part. See the new text to see whether it works.
 
> - p8: CNAME is used without being defined.

Done.
 
> - p15: AVPF is used before being defined/expanded.

Done.
 
> its ok not to follow the SHOULD.)

Rephrased this part.
 
> though that might be my ignorance of the use-case and multicast in

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

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

Sure it does since it is an RTP seqnum and all rtp seqnum rules apply to it as well.
 
> that work with an 8 bit field that is only zero when a new RAMS-R is

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).
 
> Better to specifically say when its needed.

Expanded the text to say when it would be needed.

Thanks much for the careful review.

-acbegen

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Oct 2010 14:46:04 +0100

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, 
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Oct 2010 15:53:27 +0100

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:-)

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

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

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

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

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

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

Cheers,
S.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 25 Oct 2010 07:04:41 -0700

Hi Stephen,

> Sent: Monday, October 25, 2010 3:46 PM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
> 
> 
> Hi Ali,
> 

Good.

 

 

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 25 Oct 2010 08:15:04 -0700

> Sent: Monday, October 25, 2010 4:53 PM
> Subject: Re: secdir review of draft-ietf-avt-rapid-acquisition-for-rtp-16
> 
> 
> 
> > 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.).
> 

We will see. IPTV is one of the mostly used multicast (SSM) application out there. So, RAMS will be a good test.
 
> > 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.
> >

Indeed.
 
> not, (which you guys may know), then whether that's considered

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

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

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