Re: [rtcweb] STUN for keep-alive

[Randell Jesup <[e-mail]>]

On 9/19/2011 10:39 AM, Magnus Westerlund wrote:
> Hi,
>
> As an individual I like to provide some analyze of the entropy in
> RTP/RTCP. Please consider, comment and provide opinion about the number
> of bits.
Thanks for the excellent analysis, Magnus.

> On 2011-09-16 20:30, Eric Rescorla wrote:
>>> The RTCP receiver reports should be adequate for 'consent freshness', no?
>>> If I still like receiving the traffic, I'll report that I'm receiving it.
>>> If I have crashed or disconnected or am not listening on that port, I won't.
>> I believe so, though I'd have to make sure there's enough entropy. And of course
>> some implementations may not do RTCP...
>>
> So one case of attack is the one when the webserver S uses the connected
> clients to attack target T by instructing client C to send to target T.
> So the Server or some server controlled entity A needs to send RTCP to C
> that makes C believe T is responding, i.e. spoofed source address that
> are T's plus the content of the RTCP RR. Please note that SRTP will not
> provide any protection if the webserver knows the key. Thus if security
> description is allowed, which appear reasonable if supporting legacy is
> the goal, which is the reason for this whole proposal.

I would disagree with one aspect of that: I don't know that we need to
support SDES, and if we do, we only need to support it for "legacy"
connections, not true webrtc browser-to-browser connections, which I
assert should always be DTLS.  Of course, non-encrypted RTP to a legacy
device would have no protection against spoofing of return RTCP at all.

Note that we need to complete a valid ICE exchange with the target
per the current spec, so T can only be attacked to begin with if the ICE
exchange can be spoofed.  The original scenario from Eric was about "how
do I determine if the recipient wants to *continue* to receive data
after a valid exchange (for example after ending the call or
rebooting/crashing).  I haven't checked the properties of ICE and the
ability to spoof it, but before analyzing the entropy required to attack
the return RTCP 'freshness' state, we need to show that the attack could
be begun, or state that ICE is not mandatory for some connections.

As you mention, if we need extra entropy it might be possible to add it,
but not if we are assuming that the other side is a legacy SDES device.


-- 
Randell Jesup
[e-mail]