Subject: Re: [Ice] Triggered checks are missing peer reflexive

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Oct 2016 09:58:34 +0000

Hi Nils,

Sorry for the late reply.

If I understand the issue correctly, this could only happen with trickle.
Because, in normal cases pruning would take care of it.

Or?

Regards,

Christer

On 20/09/16 06:46, "Ice on behalf of Nils Ohlmeier" <[email-masked]
on behalf of [email-masked]> wrote:

>After reading up on how the current Trickle ICE draft proposes to handle
>peer reflexive candidates it appears to me that my scenario below is
>relevant for ICE 5245bis if there is no STUN server.
>And if there is a STUN server then it should only happen if B has
>trickled his public host candidate to A already. And A receives its
>binding response from B before it discovers his own server reflexive by
>receiving a binding response from the STUN server.
>
>Even if we don¹t bother do try to optimize the useless/redundant trigger
>check away I think we should:
>- include peer reflexive candidates into the paragraph of 5245 which
>talks about trigger checks
>- extend the paragraph in the trickle draft to not only mention
>discovering peer reflexive candidates via STUN binding request, but also
>from binding responses.
>
>I would appreciate some feedback on this before trying to propose
>improved wording for both specs.
>
>Best
>  Nils Ohlmeier
>
>> On Sep 2, 2016, at 13:34, Nils Ohlmeier <[email-masked]> wrote:
>> 
>> Hello,
>> 
>> I have identified something which I would be interested to hear the
>>opinions of the ICE experts about.
>> 
>> In RFC 5245 (section 7.2.1.4) and also in bis-04 (section 6.1.3.1.4)
>>claim the following regarding receiving triggered checks:
>>   The local candidate will either be a host candidate (...) or a
>>relayed candidate (Š). The local candidate can never be a server
>>reflexive candidate.
>> 
>> Which I think is missing the case where the local candidate can also a
>>be a peer reflexive. And this is actually causing unnecessary extra
>>checks to be made.
>> 
>> Consider the following scenario:
>> 
>> - A sits behind symmetric NAT
>> - B is on a publicly routable address with no NAT or firewall
>> - No STUN servers (just makes the scenario less complex)
>> - Host candidates get exchanged  and candidate pairs A:B and B:A get
>>created on both sides
>> - A sends binding request to B
>> - B receives binding request with transport address A¹
>> - B creates a peer reflexive candidate for A¹ and the a new pair B:A¹
>>and puts that new pair into its trigger check queue
>> - B sends binding response to A¹
>> - A receives binding response, learns about A¹ and creates A¹:B and
>>marks it as successful
>> - Now B sends a binding request for it trigger check queue entry to A¹
>> - When A receives this binding request is has no way to match this to
>>the successful pair A¹:B
>> - Because of the wording in the above mentioned sections it will match
>>the request to the pair A:B
>> - Which then in turn causes another triggered check to be created
>>because A:B is not in the success state
>> 
>> This additional triggered check from A is just waste of time and
>>resources. It does not hurt. But I¹m wondering how this could be avoided.
>> 
>> If people agree I think section 6.1.3.1.4 should at least mention the
>>scenario that incoming binding requests can also match a peer reflexive
>>candidate.
>> 
>> As the incoming binding request does not contain the destination
>>address it got send to there is obviously no way for A to clearly
>>distinguish if the request got send to A or A¹.
>> 
>> For avoiding the additional triggered check on A¹s side the only
>>solution I see right now is to go through the pairs which have A as
>>their foundation and if that list contains a pair which is marked as
>>successful already assume no triggered check is needed. So far I have
>>not been able to identify a scenario where it hurts to skip this extra
>>round of triggered checks on A¹s side.
>> 
>> Best
>>  Nils Ohlmeier
>> 
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 7 Oct 2016 21:19:12 -0700

Hi Christer,

Thanks for your reply. I don’t think that there is any pruning happening when you discover peer reflexive candidates (you are suppose to check for an existing equal pair, not sure if you consider that as pruning at that step).

But the repeated reading of the sections about discovering peer reflexive candidates made me actually realize that we have a not standard compliant implementation and therefore my whole scenario is void if your implementation adheres to either version of the standard. So please dis-regard my concerns.

The only bit left is that if it took me that many readings to understand the difference between the check list and the valid list we might be interested in making the wording in that sections a little bit stronger or more clear to prevent other readers from wasting more time on this like I did.

Best regards
  Nils Ohlmeier

> On Oct 4, 2016, at 02:58, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Nils,
>