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

[Randell Jesup <[e-mail]>]

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
>> 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.

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