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

Randell Jesup <> Tue, 25 February 2014 22:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 41A7F1A0298 for <>; Tue, 25 Feb 2014 14:24:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FTQuwTjr0s3g for <>; Tue, 25 Feb 2014 14:24:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C43AF1A02AF for <>; Tue, 25 Feb 2014 14:24:06 -0800 (PST)
Received: from ([]:4948 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from <>) id 1WIQQ1-000EVs-O0 for; Tue, 25 Feb 2014 16:24:05 -0600
Message-ID: <>
Date: Tue, 25 Feb 2014 17:22:49 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; 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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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: Tue, 25 Feb 2014 22:24:11 -0000

On 2/24/2014 5:05 AM, Magnus Westerlund wrote:
> On 2014-02-22 02:14, Martin Thomson wrote:
>> 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
> mitigation.
> 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
> nodes.

Of course, any smart attacker could do the same today by opening large 
numbers of http or WebSocket connections that cross the same networks, 
especially if the target isn't the remote endpoint but intermediary 
networks as you indicated.  A difference is that it may be harder to 
find destination nodes that will accept such connections and return or 
accept data across the link you want to attack, though the open requests 
themselves can be an attack. However, in real terms, there are usually 
nodes in an access network that return some data to requests (such as 
routers with remote admin turned on, servers (or rogue servers), 
especially on non-standard ports (not 80), etc.  Simply finding routers 
that respond on 80 or 8080, etc and you can send large bogus HTTP 
request to or get to return static images repeatedly might be enough to 
construct an equivalent attack.  (Even more-so perhaps with IW10).

So: congestion control: of course.  Perhaps this makes it a little 
simpler to set up certain types of indirect attacks - but I don't think 
it adds a fundamental class of attacks.

Randell Jesup -- rjesup a t mozilla d o t com