Re: [rtcweb] Summary of ICE discussion

Harald Alvestrand <harald@alvestrand.no> Wed, 05 October 2011 12:19 UTC

Return-Path: <harald@alvestrand.no>
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 23F9321F8CA8 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.563
X-Spam-Level:
X-Spam-Status: No, score=-108.563 tagged_above=-999 required=5 tests=[AWL=2.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 XUQ2WJ8U9M7Z for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:19:29 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1E21F8CA9 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 05:19:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3B07439E0A7 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:22:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yk9GShJdke8E for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:22:35 +0200 (CEST)
Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5EB9439E048 for <rtcweb@ietf.org>; Wed, 5 Oct 2011 14:22:35 +0200 (CEST)
Message-ID: <4E8C4C0A.4090408@alvestrand.no>
Date: Wed, 05 Oct 2011 14:22:34 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E8B192E.80809@ericsson.com>, <CALiegfmnxO+BrfycOmL=hptBFdcEpsLeBn=zsJTX=ivKBBumWw@mail.gmail.com> <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl>
In-Reply-To: <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl>
Content-Type: multipart/alternative; boundary="------------060009060301060809050602"
Subject: Re: [rtcweb] Summary of ICE discussion
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: Wed, 05 Oct 2011 12:19:31 -0000

On 10/04/2011 06:28 PM, Bernard Aboba wrote:
> I think this is a good summary of where we are with respect to ICE, and
> since there are no good alternatives on the table, it seems reasonable to
> move on to the next step.
>
> IMHO, this would involve a more detailed analysis of the threats and what
> needs to be done to resolve them.
>
> In particular, the statement "STUN Connectivity Check MUST have 
> succeeded" is
> necessary but not sufficient.   We need to get into a discussion of 
> the specific
> conditions under which media can be sent, and what attacks are still
> possible.
....
> Also, it would be desirable to prevent a browser from sending much more
> bandwidth than the receiver has consented to;  however, because signaling
> is largely opaque to the browser, it is not obvious (at least to me) 
> how to
> prevent this.
Note - at the moment, the PeerConnection proposal has a lot of the 
signalling happening within the browser. So the browser knows what 
bandwidths have been negotiated and so on, and can police accordingly. 
An implementation that followed the "low level" model and did 
negotiation in (untrusted) Javascript would have less insight.

This helps less than it might - the messages are sent in the clear, and 
unprotected against intermediaries, and they have to be that way to 
enable signalling gateways to do their thing, so the browser has no way 
of verifying that a reply that comes back with the suggestion "let's 
send 100 Mbits/sec" was actually what the remote end consented to; a 
malevolent (or even just broken) signalling relay could easily change 
this parameter.

I suspect that the solutions here may have to involve congestion control 
and slow start; for instance, ubiquitous, browser-policed support of a 
TMMBR-like mechanism where the recipient states what it's willing to 
receive over the RTCP channel would reduce the attack window of this 
particular attack to something that we might consider acceptable.

                  Harald