Re: [rtcweb] STUN for keep-alive

Randell Jesup <randell-ietf@jesup.org> Mon, 19 September 2011 17:37 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4848821F8C65 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 10:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.541
X-Spam-Level:
X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J0k02FIOiEj for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 10:37:37 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CB30D21F8C64 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 10:37:31 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R5hox-0003Ax-2m for rtcweb@ietf.org; Mon, 19 Sep 2011 12:39:55 -0500
Message-ID: <4E777DA0.80201@jesup.org>
Date: Mon, 19 Sep 2011 13:36:32 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E77543E.1040704@ericsson.com>
In-Reply-To: <4E77543E.1040704@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] STUN for keep-alive
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 17:37:38 -0000

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
randell-ietf@jesup.org