Subject: [Ice] ICE change in role conflict ([was: 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: Sun, 25 Feb 2018 10:08:31 +0000

Hi,

I ask the community to take a look at the suggested change below, and indicate whether you have any issues.

NUTSHELL:

What’s the problem?

In case both agents assume the same role (might happen in certain 3PCC scenarios), AND use the same tie-breaker value (unlikely to happen, but possible in theory), which may cause both endpoints to send a 487 response.

The 487 response will cause both endpoints and change their roles, and try again. But, unless they also change the tie-breaker value, the result will be the same: both will assume the same role (since both received 487), and might use the same tie-breaker values.

What’s the solution?

Specify that, when an endpoint receives 487, and changes its role, it MUST also change the tie-breaker value. That way, when both endpoints again try, unless the endpoints again choose the same tie-breaker value (even more unlikely) only one should send a 487, and the role conflict will be solved.

What if I don’t like the suggested solution?

Suggest something better (read: provide actual text change/removal/additions).

DETAILS:

Please see discussion thread below.

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 24 February 2018 22:53
To: Christer Holmberg <[email-masked]>
Cc: Taylor Brandstetter <[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) - Role conflict issue

On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
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<http://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.

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

Yes, so they oscillate back and forth.

Section 7.2.5.1<http://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? :)

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

-Ekr

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 21 February 2018 01:07
To: Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Ben Campbell <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[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: Ted Hardie <[email-masked]>
Date: Mon, 26 Feb 2018 11:44:25 -0800

Hi Christer,

On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <
[email-masked]> wrote:

> *NUTSHELL:*
> *What’s the problem?*
> In case both agents assume the same role (might happen in certain 3PCC
> scenarios), AND use the same tie-breaker value (unlikely to happen, but
> possible in theory), which may cause both endpoints to send a 487 response.
>
>
>
> The 487 response will cause both endpoints and change their roles, and try
> again. But, unless they also change the tie-breaker value, the result will
> be the same: both will assume the same role (since both received 487), and
> might use the same tie-breaker values.
>
>
>
>
>
> *What’s the solution?*
>
>
>
> Specify that, when an endpoint receives 487, and changes its role, it MUST
> also change the tie-breaker value. That way, when both endpoints again try,
> unless the endpoints again choose the same tie-breaker value (even more
> unlikely) only one should send a 487, and the role conflict will be solved.
>
>
>

So, I propose something even simpler.  In the very rare case that the peers
see that the tie-breaker values are the same, both sides should restart
ICE.  Restarting ICE results in new tie-breaker values being selected in
any case.

My logic here is this:  this occurs pretty rarely to start with,
essentially only in the case of third-party call control.  In that subset
of cases, the two sides have to select the same value out of a 4-billion
odd range.   So, at least hopefully, this is not a common occurrence.  Code
covering uncommon occurrences tends to bit rot.  Using "re-start ICE" means
re-using code that will be maintained for other reasons, where re-start
with a new tie-breaker value will not be.

I am willing to accept your current solution, though, if other folks are
not concerned about the complexity.

Ted

>
>
> *What if I don’t like the suggested solution?*
>
>
>
> *DETAILS:*
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* 24 February 2018 22:53
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Taylor Brandstetter <[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) - Role conflict issue
>
>
>
>
>
>
>
> On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <
> [email-masked]> wrote:
>
> Hi,
>
>
>
> 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*…”
>
>
>
> 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).
>
>
>
> 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? :)
>
>
>
> *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]
> [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Feb 2018 19:59:14 +0000

Hi Ted,

ICE re-start was suggested earlier, but people didn’t like it.

I don’t think the solution adds very much complexity. It’s more or less supported already, the only difference is that we change “MAY pick a new tie-breaker value” to “MUST pick a new tie-breaker value”.

And, even if only one of the endpoints actually do pick a new value, and the other keeps the old value, things will still work :)

Regards,

Christer

From: Ted Hardie [mailto:[email-masked]]
Sent: 26 February 2018 21:44
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; Ben Campbell <[email-masked]>; [email-masked]
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)

Hi Christer,

On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

NUTSHELL:

What’s the problem?

What’s the solution?

So, I propose something even simpler.  In the very rare case that the peers see that the tie-breaker values are the same, both sides should restart ICE.  Restarting ICE results in new tie-breaker values being selected in any case.
My logic here is this:  this occurs pretty rarely to start with, essentially only in the case of third-party call control.  In that subset of cases, the two sides have to select the same value out of a 4-billion odd range.   So, at least hopefully, this is not a common occurrence.  Code covering uncommon occurrences tends to bit rot.  Using "re-start ICE" means re-using code that will be maintained for other reasons, where re-start with a new tie-breaker value will not be.
I am willing to accept your current solution, though, if other folks are not concerned about the complexity.
Ted

DETAILS:

Regards,

Christer

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

…the agent sends 487.

OLD:

NEW:

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

OLD:

NEW:

Problem solved? :)

-Ekr

Regards,

Christer

...

Probably...

-Ekr

Regards,

Christer

---

From: Ted Hardie <[email-masked]>
Date: Mon, 26 Feb 2018 12:02:53 -0800

> ICE re-start was suggested earlier, but people didn’t like it.
I missed that, my apologies for re-raising it then.

>
>
> I don’t think the solution adds very much complexity. It’s more or less
> supported already, the only difference is that we change “MAY pick a new
> tie-breaker value” to “MUST pick a new tie-breaker value”.
>
>
>
> And, even if only one of the endpoints actually do pick a new value, and
> the other keeps the old value, things will still work :)
>
>
>

It sounds like this is the preferred way forward, and given the rarity, it
seems like an acceptable risk.

Move me into the "sounds okay" column,

thanks,

Ted

> Regards,
>
>
>
> Christer
>
>
>
> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* 26 February 2018 21:44
> *Cc:* [email-masked]; Ben Campbell <[email-masked]>; [email-masked]
> *Subject:* Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's
> No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding
> Security Considerations) - Role conflict issue)
>
>
>
> Hi Christer,
>
>
>
> So, I propose something even simpler.  In the very rare case that the
> peers see that the tie-breaker values are the same, both sides should
> restart ICE.  Restarting ICE results in new tie-breaker values being
> selected in any case.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Feb 2018 20:07:41 +0000

Hi,

> I missed that, my apologies for re-raising it then.
 
Don't worry - it's nice to see that there are still people around who actually care about the draft :)

Regards,

Christer

Hi Christer,
 
On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

NUTSHELL:
 
What’s the problem?

What’s the solution?

 

DETAILS:

Regards,
 
Christer

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

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

 
…the agent sends 487. 

 

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

NEW:

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

NEW:

Problem solved? :)

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

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

...

Probably...

 

-Ekr

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Feb 2018 14:10:05 -0700

> tie-breaker value” to “MUST pick a new tie-breaker value”.

I was fine with the restart proposal, but what you've written up seems
good to me.

Peter

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 26 Feb 2018 16:11:02 -0800

> On Feb 26, 2018, at 11:59, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ted,
> 

Firefox has actually encountered endpoints in the wild which kept using 0 or 1 (I’m not sure any more) as it’s tie breaker value.

I’m not a fan of the ICE restart solution, because it would need another round of negotiation, which is slow. Thus I like you proposed solution better, although it means more code.

Best
  Nils Ohlmeier

>   <>
> On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>   <>
> From: Eric Rescorla [mailto:[email-masked] <mailto:[email-masked]>]
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> Cc: Taylor Brandstetter <[email-masked] <mailto:[email-masked]>>; Ben Campbell <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; The IESG <[email-masked] <mailto:[email-masked]>>
> On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> First, the draft already covers the case when the tie-breaker values are identical. It is described in section 7.3.1.1 <http://7.3.1.1/>:
> 
> Section 7.2.5.1 <http://7.2.5.1/>:
> =============
> 
> OLD:
> 
>   <>
> From: Eric Rescorla [mailto:[email-masked] <mailto:[email-masked]>]
> To: Taylor Brandstetter <[email-masked] <mailto:[email-masked]>>
> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Ben Campbell <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; The IESG <[email-masked] <mailto:[email-masked]>>
> On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter <[email-masked] <mailto:[email-masked]>> wrote:
> 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,
> 
> ...
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ice <https://www.ietf.org/mailman/listinfo/ice>
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ice <https://www.ietf.org/mailman/listinfo/ice>
>