Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Feb 2018 20:37:54 +0000

Hi,

I had a closer look at the role conflict issue.

First, the draft already covers the case when the tie-breaker values are identical. It is described in section 7.3.1.1:

   “If the agent's tie-breaker value is larger than or equal to…”

…the agent sends 487.

Then, according to section 7.2.5.1., when an agent receives the 487 response it will change its role.

Now, if BOTH agents send 487, it means BOTH agents will switch their roles, and try again. Now, since both agents switch their role, and keep the same tie-breaker value, the result will again be the same (only with different roles).

But, if both agents also change their tie-breaker value, most likely only one agent will send 487, and things will work.

(Section 7.2.5.1 actually already allows changing the tie-breaker value, which contradicts the must-not-change rule in Section 16.1)

So, based on the idea above, the changes would be:

Section 7.2.5.1:
=============

OLD:

Once the agent has switched its role, the agent MUST add the
candidate pair whose check generated the 487 error response to the
triggered check queue associated with the check list to which the
pair belongs, and set the candidate pair state to Waiting.  When the
triggered connectivity check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED attribute of the Binding request will indicate the
agent's new role.  The agent MAY change the tie-breaker value.

NEW:

Once the agent has switched its role, the agent MUST add the
candidate pair whose check generated the 487 error response to the
triggered check queue associated with the check list to which the
pair belongs, and set the candidate pair state to Waiting.  When the
triggered connectivity check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED attribute of the Binding request will indicate the
agent's new role.  The agent MUST change the tie-breaker value.

Section 16.1:
===========

OLD:

An ICE agent MUST use the same number for all
Binding requests, for all streams, within an ICE session. The agent
MAY change the number when an ICE restart occurs.

NEW:

An ICE agent MUST use the same number for all
Binding requests, for all streams, within an ICE session, unless
it receives a 487 response, in which case it MUST change the
number (Section 7.2.5.1). The agent MAY change the number when
an ICE restart occurs.

Problem solved? :)

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 21 February 2018 01:07
To: Taylor Brandstetter <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Ben Campbell <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)

I wouldn't object if someone produced a principled fix. I just don't want to create a lot of work for people

On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:
The tie-breaker collision problem has come up a few times before, actually. As I've said, I believe it could be fixed very easily by saying "pick a new tie-breaker if this happens."

As for the "MUST not change tie-breaker" rule in section 16.1, requiring an ICE restart is overkill. We can just change it to "MUST not change tie-breaker unless there's a collision."

On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

...

>>>> IF we really want to solve this, one simple solution be to say that, if this happens, and endpoint simply calculates a
>>>> new tie-breaker value, and tries again? BUT, then we would have to change section 16.1, which says that a new value can only be calculated at an ICE restart.
>>>>
>>>> So, could we simply say that, if this happens, the agent MUST do an ICE restart, and it MUST calculate a new tie-breaker value?
>>>
>>> Now both sides might do a simultaneous restart. Is that going to work?
>>
>> We could say that the initiating agent MUST do the restart.
>
> In this scenario, don't both sides believe they are the initiating peer, hence the need for the tiebreaker?

Probably...

But, then I don't see what we could do. If both agents send a check, and receive 487, we can't define a procedure for one of the agents.

Perhaps we should then change the must-not-change-the-value-unless-restart and say that an agent changes the tie-breaker value and try again.

As you say, the problem is inherently that the situation is symmetrical.

At this point in the design process, I don't think it's worth trying to actually make the call succeed; a 2^{-64} failure rate is much lower than organic call failure rates from other causes, even in non-3PCC scenarios. Rather, I think the spec should just prescribe a clean failure mode via a new error code, rather than having both sides wildly oscillate between controlled and controlling

-Ekr

Regards,

Christer

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Feb 2018 12:52:44 -0800

On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <
[email-masked]> wrote:

> First, the draft already covers the case when the tie-breaker values are
> identical. It is described in section 7.3.1.1:
>
>
>
>    “If the agent's tie-breaker value is larger than *or equal to*…”
>

Yes. My point is that this is broken.

> Now, if BOTH agents send 487, it means BOTH agents will switch their
> roles, and try again. Now, since both agents switch their role, and keep
> the same tie-breaker value, the result will again be the same (only with
> different roles).
>

Yes, so they oscillate back and forth.

Section 7.2.5.1:
> agent's new role.  The agent *MAY* change the tie-breaker value.
>
>
>
>
>
> NEW:
>
>
>
> agent's new role.  The agent *MUST* change the tie-breaker value.
>
>
>
>
>
> Section 16.1:
>
> ===========
>
>
>
> OLD:
>
>
>
> Binding requests, for all streams, within an ICE session*, unless *
>
> *it receives a 487 response, in which case it MUST change the*
>
> *number (Section 7.2.5.1).* The agent MAY change the number when
>
> an ICE restart occurs.
>
>
>
> Problem solved? :)
>

This would be fine with me, but presumably needs WG signoff.

-Ekr

>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* 21 February 2018 01:07
> *To:* Taylor Brandstetter <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Ben Campbell <
> [email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; The IESG <
> [email-masked]>
> *Subject:* Re: [Ice] Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations)
>
>
>
> On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter <[email-masked]>
> wrote:
>
> The tie-breaker collision problem has come up a few times before,
> actually. As I've said, I believe it could be fixed very easily by saying
> "pick a new tie-breaker if this happens."
>
>
>
> As for the "MUST not change tie-breaker" rule in section 16.1, requiring
> an ICE restart is overkill. We can just change it to "MUST not change
> tie-breaker* unless there's a collision*."
>
>
>
> On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
>
>
> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
> [email-masked]> wrote:
>
> Hi,
>
> ...
>
> >>>> IF we really want to solve this, one simple solution be to say that,
> if this happens, and endpoint simply calculates a
> >>>> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated at
> an ICE restart.
> >>>>
> >>>> So, could we simply say that, if this happens, the agent MUST do an
> ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> But, then I don't see what we could do. If both agents send a check, and
> receive 487, we can't define a procedure for one of the agents.
>
> Perhaps we should then change the must-not-change-the-value-unless-restart
> and say that an agent changes the tie-breaker value and try again.
>
>
>
> At this point in the design process, I don't think it's worth trying to
> actually make the call succeed; a 2^{-64} failure rate is much lower than
> organic call failure rates from other causes, even in non-3PCC scenarios.
> Rather, I think the spec should just prescribe a clean failure mode via a
> new error code, rather than having both sides wildly oscillate between
> controlled and controlling
>
>
>
> -Ekr
>
>
>
>
> Regards,
>
> Christer
>
>
>
>
>
> [email-masked]