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

[Magnus Westerlund <[e-mail]>]

On 2014-02-22 02:14, Martin Thomson wrote:
> On 21 February 2014 17:02, Ted Hardie <[e-mail]> 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
> http://tools.ietf.org/html/draft-thomson-mmusic-rtcweb-bw-consent-00,
> 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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------