Re: [MMUSIC] Updating the pacing of ICE connectivity checks

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Thursday, February 14, 2013 7:51 AM
> To: Emil Ivov
> Cc: Ari Keränen; 'mmusic'; Dan Wing
> Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks
> 
> On 2013-02-14 16:36, Emil Ivov wrote:
> > Any idea why there had to be different pacing for RTP and non-RTP
> > flows in the first place?
> 
> I think our arguments where that in the context of a non-congestion
> controlled voice application it would send with 20 ms interval anyway.
> For other transports and protocols it was not obvious for what intended
> environment it would be used. For example a low power network
> application that sends beyond 30 kbps could be problematic. Thus we took
> one of our conservative values from the transport books, i.e. 500 ms.
> 
> I would point out that this is a difficult transport issue. Compared to
> TCP IW10, that burst occurs first after the initial handshake when one
> has actually established that there is a responder.
> 
> With ICE there is a clear issue with an attacker bloating a offer/answer
> with candidates that recreates the voice hammer attack using ICE's STUN
> checks towards a target address or domain.
> 
> Also the STUN checks will have different source address pairs which in
> it self could be an issue for attack prevention firewalls etc.
> 
> Thus I would be careful with speeding up Ta for RTP to much, and I think
> someone needs to fine empiric data that it would work.
> 
> For the the 500 ms that can likely be significantly lowered without any
> issues. But some considerations around the wider usage needs to be taken
> into account.

Most of those concerns are for the ICE connectivity checks (to the remote
peer).  There are different concerns for the initial STUN (and TURN) 
communications to the STUN/TURN servers, which are the communications
that create the NAT (or firewall) mappings.  I noticed the two different
concerns are nicely written in
http://tools.ietf.org/html/rfc5245#appendix-B.1

Question, playing devil's advocate:  is the voice hammer attack (or a
STUN connectivity check hammer attack) worse than a web page full of
HTML IMG tags pointing at a victim's web server, which I believe has
no protection or pacing?  Has such an HTML IMG attack been a real
problem, or do we consider it will be a problem?

-d

> Cheers
> 
> Magnus
> One of the ADs responsible for the pacing in ICE.
> 
> >
> > Emil
> >
> > On 14.02.13, 16:32, Ari Keränen wrote:
> >> On 2/14/13 5:20 PM, Dan Wing wrote:
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of Ari Keränen
> >>>> Sent: Thursday, February 14, 2013 5:49 AM
> >>>> To: mmusic
> >>>> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for
> >>>> background, see [1] and [2]), as discussed at the Atlanta meeting,
> >>>> will be one of the important changes in the new version of ICE.
> >>>>
> >>>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be
> >>>> configurable, SHOULD have a default of 500 ms, and MUST NOT be
> >>>> configurable to be less than 500 ms."
> >>>>
> >>>> This results in very slow pace of starting connectivity checks if
> >>>> ICE is used with non-RTP traffic. With RTP, the Ta is calculated
> >>>> based on the expected bandwidth used by the RTP stream and can be
> down to 20 ms.
> >>>> Therefore, many current implementations apparently ignore the "MUST
> NOT"
> >>>> above and set Ta to something lower.
> >>>
> >>> That would explain failures claimed to justify the desire for
> >>> running over one port.
> >>
> >> Interesting point. Does anyone know what kind of pacing was actually
> >> used when these failures were observed?
> >>
> >>> The 20ms threshold for the initial connectivity checks is because
> >>> some NATs could not create new mappings quickly.  This problems
> >>> appears to persist today, considering that both Chrome and Windows 8
> >>> limit their number of outstanding DNS queries in an apparent attempt
> >>> to work around that very same NAT UDP mapping behavior.
> >>>
> >>> If trying to create NAT mappings with 0ms pacing, it will certainly
> >>> cause NAT mapping failures and force retries.
> >>
> >> Yes, definitely. So we shouldn't go below 20ms with non-RTP either.
> >> Perhaps need to add some more justification/warning text about this
> too.
> >>
> >>>> The quite conservative value of 500 ms was originally chosen
> >>>> because of the fear of congesting the links with the connectivity
> check messages.
> >>>> This is obviously still a valid concern, but would suggesting
> >>>> something lower still make sense? How low would it be reasonably
> >>>> safe to go? What is currently used in practice? Can we come up with
> >>>> a formula similar to RTP (perhaps based on expected bandwidth
> usage)?
> >>>
> >>> A good question for the transport area, which is the origination of
> >>> the suggestion to send ICE connectivity checks paced to not exceed
> >>> the bandwidth of the subsequent media.  Perhaps the arguments that
> >>> TCP
> >>> IW=10 is not harmful could be brought to the party.
> >>
> >> FYI, I forwarded the original mail to the Transport ADs too.
> >>
> >>
> >> Cheers,
> >> Ari
> >>
> >>>>
> >>>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1
> >>>> [2] http://tools.ietf.org/html/rfc5245#section-16.2
> >>>> _______________________________________________
> >>>> mmusic mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >>
> >
> 
> 
> --
> 
> 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]
> ----------------------------------------------------------------------