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

[Ted Hardie <[e-mail]>]

On Fri, Feb 21, 2014 at 12:08 AM, Magnus Westerlund <
[e-mail]> wrote:

> On 2014-02-20 18:13, Ted Hardie wrote:
> > On Thu, Feb 20, 2014 at 8:05 AM, Magnus Westerlund
> > <[e-mail] <mailto:[e-mail]>>
> > 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.


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?)



> 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.
>
>
So my take as an individual is that congestion control is a known desirable
property, and that we're addressing its lack as we can.  Adding that note to
the security document doesn't seem to me to add much to this story.

Ted




> Does this make my concern clearer?
>
> 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]
> ----------------------------------------------------------------------
>
>