Subject: [Ice] Triggered checks are missing peer reflexive

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 2 Sep 2016 13:34:09 -0700

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: Mon, 19 Sep 2016 20:46:18 -0700

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