Subject: [rtcweb] Consent freshness - revisiting the RTCP option

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 May 2012 23:54:32 +0200

Just because I realized I didnt understand something, I ask.....

We rejected RTCP RR as a consent freshness mechanism because RR is 
trivial to fake.
But - now we have SRTP as mandatory-to-use, which means that all RTCP 
RRs are integrity protected, origin authenticated and replay protected 
(do I have that right?).

What is the reason why this is not sufficient protection to use RTCP RR 
as a consent freshness mechanism?

                         Harald

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 May 2012 14:59:44 -0700

On Tue, May 8, 2012 at 2:54 PM, Harald Alvestrand <[email-masked]> wrote:
> We rejected RTCP RR as a consent freshness mechanism because RR is trivial
> to fake.
> But - now we have SRTP as mandatory-to-use, which means that all RTCP RRs
> are integrity protected, origin authenticated and replay protected (do I
> have that right?).
>
> What is the reason why this is not sufficient protection to use RTCP RR as a
> consent freshness mechanism?

This isn't a complete analysis, but if you are using SDES for key management,
then the site knows the SRTCP keys, so I don't *think* SRTCP is buying you
much. I haven't thought through this completely though, so maybe there is
still some additional value.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 May 2012 08:56:12 +0200

On 05/08/2012 11:59 PM, Eric Rescorla wrote:
> On Tue, May 8, 2012 at 2:54 PM, Harald Alvestrand<[email-masked]>  wrote:
Ah - had forgotten that the attacker is assumed to observe the 
signalling path. Thanks.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 May 2012 09:31:13 +0200

> as a consent freshness mechanism?

I agree that SRTP will not really buy you much. Even using DTLS-SRTP
there are attack vectors for the case where the attacker is willing to
start in the attacked network and then move his signalling and crypto
state to an off-path source address spoofing consent freshness
generating bot. Thus leaving the stream alive for a long time.

The issue with RTCP is the amount of entropy in each RTCP packets that
are hard to guess given an off-path attacker and which the media sender
verifying consent can determine correctly.

Revisiting the discussion from September last year on this topic.
Especially my estimate of entropy sources in RTCP that can't be guessed:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html

The only two fields that an off-path attacker can't easily spoof in an
RTCP RR are:
- last SR (LSR)
- Extended highest sequence number

And here the first one is the one that is more valuable as it is the
senders RTCP SR NTP timestamp field. Yes, it will increase as time goes
one, but the lower bits of this field when the actual RTCP SR was sent
is difficult to spoof correctly.

The sequence number is also a bit difficult to spoof if you don't see
the packets being sent. However, as this is not a field copied directly
from the latest received RTCP SR packet and thus need to be tolerant to
packet losses etc and thus accept a window of the from the latest
actually sent any sent the last few seconds.

I do think we can have consent freshness based on that three RTCP
packets in a time window of 30 seconds or some number of reporting
intervals that do not contain a clear error an actual receiver wouldn't
do, would keep the media stream alive. I would probably also add in
cases I get 3 RTCP packets in a row that matches security but contains
errors would directly kill the stream. Here actually SRTCP does help.
Because you can use SRTCP to ensure that the denial of service vector on
this second rule can't be triggered by someone outside of the security
context.

However, the question about consent freshness I think needs to consider
also if this RTCP rule is in fact reasonable for legacy interworking
cases. For a gateway responding to STUN messages are probably easier
than in addition to being able to do ICE initially also need a full RTP
stack to generate RTCP reports for any legacy end-point that doesn't
implement RTCP. This may however be a mote point depending on what
requirements on congestion control we put on the legacy interworking
gateway.

My personal perspective is that we actually need to consider all the
aspects and see if in the end there is any advantage of either using
RTCP or only using STUN.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 9 May 2012 13:04:56 +0530

More reasons why RTCP may not be suitable for consent freshness:
1. RTCP (as described in RFC3550) is receiver based, so the browser
can't explicitly request for consent. If consent freshness fails (for
e.g, RTCP packets temporarily lost because of network flapping), the
browser would have to wait for the peer to send RTCP before it can start
transmitting media. Worst, if the peer isn't an active sender it may not
send any RTCP RR until it receives media. It could send a bare minimum
RTCP RR (an RR with RC=0 and SDES with CNAME), but that has zero
entropy:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01497.html

2. There are still some endpoints that don't send / pay attention to
RTCP:
http://www.ietf.org/mail-archive/web/rai/current/msg01257.html

For these cases an intermediary like an SBC would have to manufacture
them. Manufacturing them for just consent freshness would be expensive
compared to generating STUN request/response.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Harald Alvestrand
|Sent: Wednesday, May 09, 2012 12:26 PM
|To: Eric Rescorla
|Cc: [email-masked]
|Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option
|
|On 05/08/2012 11:59 PM, Eric Rescorla wrote:
|> On Tue, May 8, 2012 at 2:54 PM, Harald
Alvestrand<[email-masked]>  wrote:
|>> Just because I realized I didnt understand something, I ask.....
|>>
|>> We rejected RTCP RR as a consent freshness mechanism because RR is
trivial
|>> to fake.
|>> But - now we have SRTP as mandatory-to-use, which means that all
RTCP RRs
|>> are integrity protected, origin authenticated and replay protected
(do I
|>> have that right?).
|>>
|>> What is the reason why this is not sufficient protection to use RTCP
RR as a
|>> consent freshness mechanism?
|> This isn't a complete analysis, but if you are using SDES for key
management,
|> then the site knows the SRTCP keys, so I don't *think* SRTCP is
buying you
|> much. I haven't thought through this completely though, so maybe
there is
|> still some additional value.
|Ah - had forgotten that the attacker is assumed to observe the
|signalling path. Thanks.
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 May 2012 11:59:47 +0200

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01497.html
Of course endpoints are expected to be RFC 3550 compliant, which 
includes obeying the diktat of section 6.3.5: "Every SSRC that hasn't 
sent an RTP or RTCP packet for 5*5 seconds is dead".
> compared to generating STUN request/response.

For non-RTCP entities, we need an RTCP-generating gateway in order to 
interwork.
End of story.
(My opinion.)