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

[Ari Keränen <[e-mail]>]

Hi Magnus,

Thanks for clarifying the background on this! Some comments and 
questions inline.

On 2/14/13 5:51 PM, Magnus Westerlund wrote:
> 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.

I'd guess the 20 ms interval is quite OK for the RTP since, as Dan 
noted, you can't go much faster without overwhelming the NATs.

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

Would you have any recommendation for a good, less conservative value? 
If the bandwidth of the non-RTP stream is known, I guess that could be 
used in a similar way as with RTP to calculate Ta (with lower bound of 
20ms). For cases where the bw is not known, we could perhaps 
RFC2119-recommend some fairly-conservative value (say, around 100ms?) 
and "MUST NOT" for below 20ms?


Cheers,
Ari
(as individual)

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