Subject: Re: [MMUSIC] ICE aggressive nomination problem

From: Ari Keränen <[email-masked]>
Date: Sun, 3 Nov 2013 15:09:36 -0800

Folks,

This aggressive nomination bug is still an open issue for ICE. If time 
permits, I'm hoping to discuss this tomorrow. As a solution, I'm leaning 
towards the updated offer, but would like to hear your opinions on this.

Cheers,
Ari

On 12/19/12 9:50 AM, Ari Keranen wrote:
> Hi all,
>
> Going through the ICE spec reminded me of one old problem with
> aggressive nomination that I discussed with Philip Matthews back when
> ICE was published:
>
> Two endpoints L and R. L is the offerer and controlling end. There are
> two possible paths, and just one component.
>
> Since L is using aggressive nomination, it sets the USE-CANDIDATE flag
> in each Binding request. However, the Binding response for the first
> path does not make it back to L. When the second check succeeds, L
> immediately stops ICE processing and uses the second path. However, R
> thinks the first path is being used.
>
> Initially, L will use path 2 for data, while R will use path 1.
> Eventually, both paths will fail, because L is only sending keep-alives
> on path 2, while R is only sending them on path 1.
>
> L                                         R
>   <--------- Bind req ---------------------  ]
>   ---------- Bind resp ------------------->  ]  Path 1
>   ---------- Bind req, USE-CAND ---------->  ]
>        X <-- Bind resp --------------------  ]
>
>   <--------- Bind req ---------------------  ]
>   ---------- Bind resp ------------------->  ]  Path 2
>   ---------- Bind req, USE-CAND ---------->  ]
>   <--------- Bind resp --------------------  ]
>
> ---
>
>
> Any good ideas how to fix this? Should the controlling agent just keep
> retransmitting even after successful nomination (for how long)?
>
> The updated offer (if we make that MUST in all cases) will help to
> detect the problem though and this could also be added to the list of
> "reasons for not using aggressive nomination unless you really have to".
>
>
> Cheers,
> Ari
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Nov 2013 15:18:31 -0800

> retransmitting even after successful nomination (for how long)?

This specific problem came up when we were writing the CU-RTC-Web
demo.  It turns out that you can tell if a nomination is genuine by
the fact that application data arrives.  In this case, R notices that
path 2 is both nominated AND live, then it switches to that path.

---

From: Ari Keränen <[email-masked]>
Date: Sun, 3 Nov 2013 15:23:38 -0800

> path 2 is both nominated AND live, then it switches to that path.

Good point. How about if there's no application data to send before the 
NAT bindings time out?

Cheers,
Ari

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Nov 2013 15:25:54 -0800

On 3 November 2013 15:23, Ari Keränen <[email-masked]> wrote:
> Good point. How about if there's no application data to send before the NAT
> bindings time out?

Why did you want to use ICE then? :)

---

From: Ari Keränen <[email-masked]>
Date: Sun, 3 Nov 2013 15:28:00 -0800

> Why did you want to use ICE then? :)

Preemptive ICE in order to minimize setup delay? A corner-case of a 
corner-case? :)

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Mon, 4 Nov 2013 00:33:50 +0100

Unless you maintain them, your candidates will timeout even with regular ICE.

If you do maintain them then you have data.

Or am I missing something?

Emil

On Mon, Nov 4, 2013 at 12:28 AM, Ari Keränen <[email-masked]> wrote:
>>> NAT

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Nov 2013 15:38:32 -0800

> If you do maintain them then you have data.

Well, DTLS heartbeats aren't really data.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 4 Nov 2013 00:40:21 +0100

> Well, DTLS heartbeats aren't really data.

Not sure what you mean.

---

From: Ari Keränen <[email-masked]>
Date: Sun, 3 Nov 2013 19:38:17 -0800

Hi Emil,

> If you do maintain them then you have data.

If you don't have "real" data to send, by RFC5245 you would send 
keepalive traffic (STUN Binding Indications, RTP No-Ops, etc.). So in 
this case you should consider receiving any of them on a not-selected 
candidate pair as a sign to change using that candidate pair, right?

I see at least some security issues here, but actually those apply also 
to non-secure application layer data.

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 4 Nov 2013 14:52:46 +0000

> candidate pair as a sign to change using that candidate pair, right?

The simple use case here is presentation sharing. If you just plan to receive a presentation you will never send any data. (Other than keepalives)

Other protocols such as BFCP also sends very little data, but there are some initial HELOs there.

.-.
Pål-Erik

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 4 Nov 2013 14:52:46 +0000

.-.
Pål-Erik