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

Magnus Westerlund <> Fri, 21 February 2014 08:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3590D1A04BD for <>; Fri, 21 Feb 2014 00:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1R-n6kqCNgeZ for <>; Fri, 21 Feb 2014 00:09:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9F47E1A005B for <>; Fri, 21 Feb 2014 00:08:59 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-77-53070996d0d6
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E7.62.10875.69907035; Fri, 21 Feb 2014 09:08:55 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Fri, 21 Feb 2014 09:08:54 +0100
Message-ID: <>
Date: Fri, 21 Feb 2014 09:08:54 +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: Ted Hardie <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvje50TvZggyVruSxWvD7HbrH2Xzu7 ReNcOwdmj52z7rJ7LFnyk8lj8uM25gDmKC6blNSczLLUIn27BK6MWWuvMBbsE6nYeJ63gXG9 QBcjJ4eEgInEob0fWCFsMYkL99azdTFycQgJHGKUuHl7J5SznFHiwOTt7CBVvALaEh+f32Hs YuTgYBFQleieYQ4SZhOwkLj5o5ENxBYVCJbYeeA3I0S5oMTJmU9YQGwRAWWJvVd2gNUwC1hL nJ2wCywuLGAv8eDucyaQkUICeRItB9JAwpwCgRIPW2aCbZIQEJfoaQyC6NSTmHK1hRHClpdo 3jqbGcQWAjqsoamDdQKj0Cwki2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAsD245bfuDsZT50QO MUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTGqvb4v2WOWwcOOLbrGAhd/ rl464dHE3/+PTWcXvyGwdKLsRw+H/WeeKu4Sv2D48k56aqOOcsvqEpW2y1aF7otlV7/dxrqj QmiPjo7W2QPqv/4cnPfJ4ntlK+fJs6+eONl6Tr32ON3dkDdcMWq1tIff9VR73yOJy5osBGXe mAbN9fl3pNvwfJISS3FGoqEWc1FxIgCe+IJJKQIAAA==
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: Fri, 21 Feb 2014 08:09:02 -0000

On 2014-02-20 18:13, Ted Hardie wrote:
> On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund
> < <>>
> wrote:
>     Hi,
>     I think a potential issue that isn't discussed in this document is the
>     security threat of driving data volumes into a network beyond ones
>     "fair" share. This would simply be to illustrate that communication
>     consent is not sufficient, to protect other users of a shared network
>     the WebRTC endpoint MUST prevent transmission of data volumes far
>     outside of the fair share.
> Magnus, I'm not sure why you think that issue should be dealt with in
> this document.
> This document should deal with cases where a malicious script could send
> transmissions
> that are not intended or not welcome.  Bbut managing network capacity
> for *intended*
> and *welcome* transmissions is not a security concern.  It's a
> congestion management
> issue, at least as I see it.
> Am I missing something about your concern?

My concern is that a malicious individual wants to DDoS a particular
network. I buy AD time from on of the network or in any other way ensure
that the mailicious JS identifies when each client is topologically
right for me to connect it to another client to drive traffic through my
targets network. Then I ensure these clients establish a peer connection
and I try to blast as much traffic through the network as possible. From
the point of the attack this doesn't matter if is real-time media or
data traffic. The point is to drive as much traffic into the network as
possible. From that perspective any traffic that is sent in the context
of a peerconnection needs to be congestion controlled. That at least
keeps the traffic down to a "fair" share.

We are mitigating this attack, however what I was really wondering over
is if the security considerations document should make note that lack of
appropriate congestion control is a security vulnerability and enables
certain type of load attacks.

Does this make my concern clearer?


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: