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

[Magnus Westerlund <[e-mail]>]

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.

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