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

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2016 15:46:14 +0000

Hi,

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

5245bis is a complex document to read, so whatever suggestions you have for making things more clear I am happy to hear :) 

For example, regarding the difference between check list and valid list, perhaps we could add some more text to the definitions in section 3?

Regards,

Christer

> On Oct 4, 2016, at 02:58, Christer Holmberg <[email-masked]> wrote:
> 
> 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: Christer Holmberg <[email-masked]>
Date: Sun, 6 Nov 2016 13:50:20 +0000

Hi,

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

The spec does allow updating of the check list when peer reflexive candidates have been discovered. But, currently they won't be pruned.

Could we say that pruning occur when the local candidate doesn't match the base? That would cover both server reflexive and peer reflexive candidates.

Regards,

Christer

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 15 Nov 2016 16:51:10 -0800

Hi Christer,

public shaming in WG meetings works :-)
Sorry for going into hibernation early...

> On Nov 3, 2016, at 08:46, Christer Holmberg <[email-masked]> wrote:
> 

I don’t think that would have helped in my case. My suggestion would be something like this at the end of section 6.1.3.2.2:

  The pair is then added to the VALID LIST, but not to the CHECK LIST.

BTW while we are on the topic of check vs valid list. Is there any reason why the list names sometimes capitalized and sometimes not?
If not it would be nice to make the names consistent in one way or the other throughout the whole document.

Best
  Nils

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Nov 2016 00:58:13 +0000

Hi,

I am not aware of sometimes using capitalized list names and sometimes not, and I intend to align the list names throughout the document.

Regards,

Christer

-----Original Message-----
From: Ice [mailto:[email-masked]] On Behalf Of Nils Ohlmeier
Sent: 16 November 2016 02:51
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ice] Triggered checks are missing peer reflexive

Hi Christer,

>> 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.
> 
> 5245bis is a complex document to read, so whatever suggestions you 
> have for making things more clear I am happy to hear :)
> 

Best
  Nils

>>>> 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:
>>>> 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.
>>>> 
>>>> - Host candidates get exchanged  and candidate pairs A:B and B:A 
>>>> get created on both sides
>>>> their foundation and if that list contains a pair which is marked 
>>>> as successful already assume no triggered check is needed. So far I 

_______________________________________________
Ice mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ice

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 15 Nov 2016 17:04:02 -0800

Hi Christer,

> On Nov 6, 2016, at 05:50, Christer Holmberg <[email-masked]> wrote:

Yes I think it would be help to broaden the scope of pruning like that. So I would vote for Alt #2 from your slides in Seoul.

Although I guess the real reason why pruning does not mention peer reflexive is that the valid pair which resulted from the peer reflexive discovery never enters the check list, and pruning only applies to the check list, but not the valid list. I guess this makes the whole topic void?!

Best
  Nils Ohlmeier

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Nov 2016 01:09:29 +0000

Hi,

>>> 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).
>> 
> Although I guess the real reason why pruning does not mention peer reflexive is that the valid pair which resulted from the peer reflexive discovery never enters the check > list, and pruning only applies to the check list, but not the valid list. I guess this makes the whole topic void?!

It is true that the INITIAL check list does not contain peer reflexive candidates. But, the spec says that, once peer reflexive candidates are detected, the check list MAY be updated (and sent to the peer) with those candidates. When such update occurs, I assume the check list will be pruned again - eventhough that is currently not explicitly said in the spec afaik (it would probably be good to add text about that).

Regards,

Christer

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 15 Nov 2016 17:16:20 -0800

> On Nov 15, 2016, at 17:09, Christer Holmberg <[email-masked]> wrote:
>> 

Now I got it.
Yes for the special case of updating and sending your new list to the peer you should prune that before handing it out. Probably would be good to mention that explicitly in that paragraph.

Best
  Nils