Re: [rtcweb] Summary of ICE discussion

[Harald Alvestrand <[e-mail]>]

On 10/05/2011 05:35 PM, Bernard Aboba wrote:
> What I was trying to point out was that there are very specific conditions
> under which the browser will consider the STUN exchange to be 
> "successful" that
> will not be met by a public STUN server, which typically will not 
> support ICE
> extensions.   If we articulate this, it would not be possible to DoS a 
> public STUN
> server with *media*, which has been the bar we've been applying so far.
Indeed, a public STUN server will not be configured with an username / 
password (RFC 5245 section 7.1.2.3), and thus its answers will not pass 
the ICE check for a correct MIC.
>
> It should be understood that when the "answer" is not directly 
> available to the
> offering browser,  the STUN exchange is only able to verify the 
> willingness
> to receive on a particular IP address/port combination.  Without 
> multi-plexing,
> this should ensure that the receiver has consented to each media type.
> Assuming that we can satisfactorily handle "continuing consent" 
> determination,
> I'm not sure that we would need ICE extensions to address the issue.
> This seems like a slippery slope that could result in a continuing 
> stream of
> ICE extensions.
>
> IMHO, the "congestion control" problem is separable.  Since
> it seems inevitable that RTCWeb implementations will support
> non-adaptive codecs, I don't believe we can rely on "congestion
> control" for DoS avoidance.

The control I was thinking of is that when a Javascript DoS attacker 
attempts to send media to a DoS victim at some significant traffic 
volume, the DoS victim can send back a TMMBR saying "I only want this 
much data" (where "this much" is a reasonable amount for the media types 
it's been expecting). That won't solve large scale DDoS attacks, of 
course, but at least it is pushback against the "I said yes to 32 Kbits 
and you hit me with 2 Mbits" attacks.

>
>
> > Date: Wed, 5 Oct 2011 10:09:32 +0200
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]; [e-mail]
> > Subject: Re: [rtcweb] Summary of ICE discussion
> >
> > Hi,
> >
> > good that my summary lets us move forward.
> >
> > A question on this attack. How common is it that these STUN servers use
> > other ports than 3478? Would a rule about that port mitigate the issue,
> > even if it could result in connectivity failures in cases where the NAT
> > external port is 3478 by chance?
> >
> > In addition does these public servers use the username and password
> > convention from ICE? Isn't that what prevents STUN server deployed for
> > just determining your server reflexive candidate from actually respond
> > correctly to a connectivity check? As ICE do concatenate one part
> > generated by one peer with a part generated by the other peer I don't
> > see this as an issue as long as the random username fragment is
> > generated by the browser not the JS.
> >
> > Cheers
> >
> > Magnus Westerlund
> >
> > ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > ----------------------------------------------------------------------
> > Ericsson AB | Phone [phone]
> > Färögatan 6 | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > ----------------------------------------------------------------------
> >
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb