Subject: [Ice] trickle: ufrag signaling

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 7 Sep 2016 20:45:13 -0600

At IETF 96 [1], the WG discussed the topic of signaling the ufrag to 
differentiate candidates between ICE restarts. To address this issue, I 
propose that we add the following text after the ufrag examples in 
Section 8:

    Note: It is the responsiblity of the signaling protocol to properly
    indicate which ICE negotiation session is in force (i.e., by
    communicating the relevant ufrag) so that both parties have a
    consistent view of which candidates are paired.  This is especially
    important in the case of ICE restarts (see Section 13).

Peter

[1] https://www.ietf.org/proceedings/96/minutes/minutes-96-ice

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 8 Sep 2016 15:40:42 +0000

On Sep 7, 2016, at 10:45 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

At IETF 96 [1], the WG discussed the topic of signaling the ufrag to differentiate candidates between ICE restarts. To address this issue, I propose that we add the following text after the ufrag examples in Section 8:

Peter

I think this is good, except that the i.e. clause is insufficient.

It is also the responsibility of the signaling protocol to make sure that it’s clear which set of local candidates pair with which set of remote candidates.

(Jingle currently is broken here, even with XEP-0371.)

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Sep 2016 09:46:52 -0600

On 9/8/16 9:40 AM, Jonathan Lennox wrote:
>> differentiate candidates between ICE restarts. To address this issue,
>> I propose that we add the following text after the ufrag examples in
>> Section 8:
>>
> It is also the responsibility of the signaling protocol to make sure
> that it’s clear which set of local candidates pair with which set of
> remote candidates.

Does communicating and agreeing on the ufrag-in-force not accomplish that?

> (Jingle currently is broken here, even with XEP-0371.)

I plan to look at that next, but feedback is welcome on the appropriate 
lists or directly to the authors.

Peter

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 8 Sep 2016 15:54:48 +0000

> On Sep 8, 2016, at 11:46 AM, Peter Saint-Andre <[email-masked]> wrote:
> 

Communicating no, agreeing yes. But you need to establish both the local and the remote ufrag (or generation or whatever).

The problem is this:

Romeo’s IP address changes, so he sends an ICE restart (ufrag B)

His IP address then changes again, so he sends another ICE restart (ufrag C).

Juliet then replies with a new set of her own candidates (ufrag X).

In Jingle, Romeo doesn’t know whether Juliet intended to pair her ufrag-X candidates with his ufrag-B candidates or his ufrag-C candidates.

In SIP and SDP offer/answer, this problem doesn’t arise, because Juliet’s reply would have explicitly been carried an answer to the ufrag B or ufrag C offer.  (And indeed, Romeo probably wouldn’t have been allowed to send the ufrag-C offer at all until an answer came in to the ufrag-B offer.)  But Jingle’s transport-info messages are unilateral, and don’t carry this semantic.

> I plan to look at that next, but feedback is welcome on the appropriate lists or directly to the authors.
> 
> Peter
> 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Sep 2016 14:24:23 -0600

> In SIP and SDP offer/answer, this problem doesn’t arise, because Juliet’s reply would have explicitly been carried an answer to the ufrag B or ufrag C offer.  (And indeed, Romeo probably wouldn’t h…

Yes, I see the problem (and, outside of this WG, we'll fix it in Jingle).

Would this text be better in the Trickle ICE spec?

   Note: The signaling protocol needs to provide a mechanism for both
   parties to indicate and agree on the ICE negotiation session (ufrag)
   in force so that they have a consistent view of which candidates are
   to be paired.  This is especially important in the case of ICE
   restarts (see Section 13).

Thanks!

Peter

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 8 Sep 2016 20:26:54 +0000

> On Sep 8, 2016, at 4:24 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

Yes, that text seems good to me.  Thanks!

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Sep 2016 14:42:12 -0600

> Yes, that text seems good to me.  Thanks!

OK, I'll submit an updated version later today.

Peter

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Sep 2016 14:41:52 +1000

>   restarts (see Section 13).

Are we separately clear that ufrag needs to be different for each ICE
negotiation session that an endpoint instantiates?

BTW, I find the parenthetical useless.  "(as identified by ufrag)"
might be better.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Sep 2016 20:51:43 -0600

> negotiation session that an endpoint instantiates?

That appears to be the general understanding, but I'm not sure if it is 
exactly specified anywhere. Do think it belongs in the trickle spec or 
the core ICE spec? (IMHO the latter is more appropriate.)

> BTW, I find the parenthetical useless.  "(as identified by ufrag)"

Seems like an improvement, yes.

Peter

---

From: Ari Keränen <[email-masked]>
Date: Wed, 21 Sep 2016 16:15:30 +0000

> On 15 Sep 2016, at 03:51, Peter Saint-Andre <[email-masked]> wrote:
> 
> That appears to be the general understanding, but I'm not sure if it is exactly specified anywhere. Do think it belongs in the trickle spec or the core ICE spec? (IMHO the latter is more appropriate.)

(hats off)
Seems like core ICE thing to me.

ICE-bis says (https://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-05#section-9):
>    To restart ICE, an agent MUST change both the password and the user
>    name fragment for the media stream in an offer.

Do you think we need something more there?

> Seems like an improvement, yes.

+1

Cheers,
Ari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Sep 2016 11:12:40 +1000

> Do you think we need something more there?

Probably.  We need to say that the ufrag needs to be unique across all
ICE restarts (do we have a better name for this?  Peter uses
"generation", I think) within a session.  It probably also needs to be
unique across all sessions that are terminated by the same hosts.