Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06

Magnus Westerlund <> Mon, 24 February 2014 10:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 16A2D1A0439 for <>; Mon, 24 Feb 2014 02:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M6BFNP0T0h53 for <>; Mon, 24 Feb 2014 02:05:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DF7121A0865 for <>; Mon, 24 Feb 2014 02:05:04 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-39-530b194f1ad8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6F.DA.04249.F491B035; Mon, 24 Feb 2014 11:05:03 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 24 Feb 2014 11:05:02 +0100
Message-ID: <>
Date: Mon, 24 Feb 2014 11:05:03 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Martin Thomson <>, Ted Hardie <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvja6/JHewwb/jRhbXzvxjtFj7r53d onGunQOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV0f54JVPBI5GK+Rua2RsYvwp0MXJw SAiYSBzbn9/FyAlkiklcuLeerYuRi0NI4AijxNWHX1khnOWMEm82rWAGaeAV0JY43eUK0sAi oCqx/9dxRhCbTcBC4uaPRjYQW1QgWGLngd9gcV4BQYmTM5+wgNgiAn4SN7uPg9nMAuoSdxaf YwexhQXsJR7cfc4EYgsJzGCS2HcKrJdTIFBi0559zBB3ikv0NAZBtGpKtG7/zQ5hy0s0b53N DNGqLdHQ1ME6gVFoFpLNs5C0zELSsoCReRUjR3FqcVJuupHBJkZgwB7c8ttiB+PlvzaHGKU5 WJTEeT++dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiV4GJheEzZ4ESQbsOTLyGatv1z dYOqfhus+7rS6Lz02sT7TxVf//z54c8xEwGFzWFzzoizrg46+2L6m9e6ilrnjsx+/NDycu07 ZtZ5Aarpoj/uZu6puDt5zdyVlpLz7YJ4dXJK58jwZZiIv7h8Zn+wi/J7k7UBU+VKT/9+66lg +KzWRuBS0GElluKMREMt5qLiRADNh/+rJgIAAA==
Cc: "" <>
Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-security-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2014 10:05:08 -0000

On 2014-02-22 02:14, Martin Thomson wrote:
> On 21 February 2014 17:02, Ted Hardie <> wrote:
>> Sorry for my apparent failure to understand here, but we're still dealing
>> with
>> traffic to which the parties consent, right?  That is, you're thinking of
>> malicious
>> JS that sends channels worth of nonsense to blast the network while
>> something
>> the user cares about happens? (Two-player flappy bird but with a terrabit of
>> nonsense
>> screaming in the background?)

Yes, that would be the attack. And the target of the attack is the
networks in the middle, not the endpoints, they are simply tools for this.

> Maybe Magnus is looking for the mechanism described in
> which might allow for control below the limit that the congestion
> control permits.  I basically abandoned this, because it's small
> potatoes. It's trivial to revoke consent if you notice a misbehaving
> peer and then you only have to wait until the consent timer runs out
> on the sender.  30s.

My position is that the above mitigation is unlikely to have significant
impact on this attack. This as it is difficult to know what values to
set. They vary over time and depending on network attachment, what
services the user tries to use etc.

There are two reasons I wanted this attack to be considered. First, it
provides a clear requirement on having congestion control as first level

Secondly, I think this could become a significant issue as data channel
PeerConnections can be opened without user consent. A malicious JS that
is sufficient well spread with a well working find and connect could
establish a large mesh of peer connections that could come close to
saturate each endpoints local access link, resulting in very heavy loads
on the network, even with congestion control. With congestion control
you can likely prevent congestion collapse, but you should be fully
capable of driving a network into a state of "mostly useless",
especially a network suffering from buffer bloat inside of the ingress


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: