Subject: [rtcweb] Question about ICE-Lite server

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 Jul 2014 15:15:11 +0200

Hi,

In case of aggressive ICE the controlling agent (let's say: the
client), and assuming the client has IPv4 and IPv6 and the ICE-Lite
server as well, the server will receive multiple STUN Requests with
USE-CANDIDATE and will decide which one to select based on computed
candidate-pair priorities (so both the client and server select the
same as they follow the same algorithm).

Now my question is: let's assume that the server is just provided with
local ICE username and password, but knows nothing about the fields in
ICE candidates (let's assume that the SDP is negotiated by other
entity which does not notify the media server about ICE candidate
parameters others than local username and password).

So the media server just knows its local ICE username and password,
but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface
and another on the IPv6 interface.

Can the ICE server determine which pair to select (the IPv4 or the
IPv6) by just inspecting the PRIORITY attribute in both STUN Requests
and select the one with highest value?

Or does the server need to assign priority, component and all the ICE
stuff to its interfaces and also be provided with the client's and its
own ICE candidates?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 6 Jul 2014 00:18:14 -0400

According to RFC 5245: "If its peer has a lite implementation, an agent
MUST use a regular nomination algorithm." So, this whole problem cannot
occur.

_____________
Roman Shpount

On Fri, Jul 4, 2014 at 9:15 AM, Iñaki Baz Castillo <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Jul 2014 21:53:42 -0700

> MUST use a regular nomination algorithm." So, this whole problem cannot

Nice catch. That actually changes things, since Firefox always uses
aggressive nomination and for performance reasons, I'm not excited
about moving to regular nomination. This seems like an argument
for perhaps forbidding ICE-Lite.

I note that this section (8.1.1) actually requires regular nomination in
another situation:

   The controlling agent nominates pairs to be selected by ICE by using
   one of two techniques: regular nomination or aggressive nomination.
   If its peer has a lite implementation, an agent MUST use a regular
   nomination algorithm.  If its peer is using ICE options (present in
   an ice-options attribute from the peer) that the agent does not
   understand, the agent MUST use a regular nomination algorithm.

I note that this has the impact that in the role conflict scenarios
(see appendix B.11) offering half-trickle may throw the other side
into regular nomination (though only if the other side doesn't
support trickle). This is probably an edge case, but I thought I
would point it out.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Jul 2014 10:16:31 +0200

>> MUST use a regular nomination algorithm." So, this whole problem cannot

Good point, thanks. Anyhow I don't think I should trust clients :)

> for perhaps forbidding ICE-Lite.

I don't understand, shouldn't that be fixed in Firefox? This is not
about performance but about real issues in scenarios with IPv4 and
IPv6 in which Firefox talks to an ICE Lite peer.

Should I address an issue? or is it already known?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Jul 2014 11:13:11 +0200

> parameters others than local username and password).

To me this sounds like "can an endpoint participate in ICE without 
participating in the exchange of candidates" - and my immediate reaction 
is "if it could, it would be a security risk".

I don't think it's possible. And I think that's a Good Thing.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Jul 2014 05:08:37 -0700

On Sun, Jul 6, 2014 at 1:16 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> I don't understand, shouldn't that be fixed in Firefox?

That's one way to fix it. The other is to require that WebRTC peers do
full ICE. I'd be interested in hearing what Chrome does.

This is not
> Should I address an issue? or is it already known?

Feel free to file an issue.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Jul 2014 14:35:56 +0200

> full ICE. I'd be interested in hearing what Chrome does.

I'm hope not. Implementing ICE-Lite in a server is trivial.
Implementing full ICE is an overhead in a server. Please not. It is
Firefox which must adhere to the standard and use regular nomination
when the peer is ICE-Lite.

> Feel free to file an issue.

I will. Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Jul 2014 14:47:25 +0200

>> Feel free to file an issue.

Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1034964

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Jul 2014 14:51:41 +0200

2014-07-06 11:13 GMT+02:00 Harald Alvestrand <[email-masked]>:
> participating in the exchange of candidates" - and my immediate reaction is
> "if it could, it would be a security risk".
>

Hi Harlad, it is not exactly like that. It is just that the signaling
logic (the entity parsing and generating the SDP) and the media server
are not co-located. The required information/parameters is transmitted
via API between both servers. Regarding ICE the only information the
media server needs (given that it is a ICE-Lite server) is the local
username and password (so it can verify authentication for incoming
Binding requests and can authenticate success responses).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Jul 2014 15:05:59 +0200

2014-07-06 14:08 GMT+02:00 Eric Rescorla <[email-masked]>:
> I'd be interested in hearing what Chrome does.

Chrome does not perform aggressive nomination when talking to a ICE-Lite peer.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 6 Jul 2014 06:09:14 -0700

> when the peer is ICE-Lite.

Well, we're currently discussing what the standards should say.
If we decide that counterparties to WebRTC do full ICE (just like
we've required them to do a bunch of other stuff) then it will be
the other side which needs to adjust.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 6 Jul 2014 15:20:25 +0200

> the other side which needs to adjust.

Of course. I just hope such a decision is not taken given the amount
of server side implementations relying on ICE-Lite (and the fact that
it is not so hard for full ICE clients to behave correctly when
talking to a lite peer).

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jul 2014 09:03:20 +0000

Hi,

> it is not so hard for full ICE clients to behave correctly when

+1.

I also we more or less had agreed on this in the past, that ICE-Lite is ok e.g. for gateways.

Regards,

Christer

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 7 Jul 2014 10:22:18 +0000

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of ext Christer
> Holmberg
> Sent: Monday, July 07, 2014 11:03 AM
> To: Iñaki Baz Castillo; Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [rtcweb] Question about ICE-Lite server
> 
> Hi,
> 

Same here. Gateways connected to the public Internet need to (and often do) implement ICE Lite only.
So far, implementers have trusted that this is OK based on the ICE RFC. 
We need good reasons when profiling other RFCs.

Kind regards,
Uwe

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Jul 2014 12:25:01 +0200

> I also we more or less had agreed on this in the past, that ICE-Lite is ok e.g. for gateways.

Oh, and also for much more interesting servers than gateways! :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 7 Jul 2014 12:34:22 +0200

On Mon, 7 Jul 2014 12:25:01 +0200

> Oh, and also for much more interesting servers than gateways! :)

I agree that ICE-Lite should be supported. We've used the
backwards-compatibility card for so many things in RTCWEB so far that it
seems silly to throw away what on the other end would be really useful.

L.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Jul 2014 12:41:09 +0200

> seems silly to throw away what on the other end would be really useful.

BTW I do not consider ICE Lite something for "backwards-compatibility", but
an easier way to implement real ICE in servers running in the public
Internet in which all the complexity of full ICE is not required at all.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Jul 2014 15:39:53 -0400

> Oh, and also for much more interesting servers than gateways! :)
I also agree that ICE-Lite must be supported and regular nomination should
be used with it to avoid timing issues.

Also, I wanted to make sure it would be possible to use ICE-TCP with an
ICE-Lite with WebRTC end-points. Using ICE-TCP with ICE-Lite would probably
create a simplest possible way to implement services that only need to
setup client to server communications since they would be able to operate
without the need for separate STUN and TURN servers.

I have a question regarding ICE-Lite support with IPv6: Does anybody
currently actively uses ICE-Lite with hosts that include both IPv4 and IPv6
candidates? I always felt that exact operation of such servers was
under-defined, so any real world experience would be extremely interesting.

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Jul 2014 15:46:28 -0400

> I don't think it's possible. And I think that's a Good Thing.
Since ICE-Lite server does not send any connectivity checks, it can operate
with virtually no information about the remote side. It certainly does not
need any information about the candidates. All it cares about that the
other side supports ICE, if there was an ICE mismatch and if remote side is
full or lite implementation. All checks from remote side are validated
using the local password. If remote side is lite or does not support ICE
media can be sent immediately, otherwise it will need to wait for a
connectivity check with the use attribute. Very, very simple.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 7 Jul 2014 23:27:28 +0200

> under-defined, so any real world experience would be extremely interesting.

I'm doing that exactly now. I don't see major problems, this is, the
server just listens into varios sockets (IPv4 and IPv6) for the same
"component" and selects the first 5-tuple from which it receives a
STUN request with USE-CANDIDATE.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 09:13:00 -0700

> full ICE. I'd be interested in hearing what Chrome does.

Chrome supports ICE lite, with regular nomination. There were a lot of
requests for it.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 09:16:39 -0700

On Mon, Jul 7, 2014 at 12:46 PM, Roman Shpount <[email-masked]> wrote:

> Since ICE-Lite server does not send any connectivity checks, it can
> operate with virtually no information about the remote side. It certainly
> does not need any information about the candidates. All it cares about that
> the other side supports ICE, if there was an ICE mismatch and if remote
> side is full or lite implementation. All checks from remote side are
> validated using the local password. If remote side is lite or does not
> support ICE media can be sent immediately, otherwise it will need to wait
> for a connectivity check with the use attribute. Very, very simple.
>
>
This seems fine to me. For ICE server implementations, there really is no
need to receive candidates from the client. All client candidates can be
generated based on incoming connectivity checks (i.e. prflx candidatates).
And yes, you would use the contents of the PRIORITY attribute to determine
the candidate priority.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Jul 2014 18:17:06 +0200

On Jul 11, 2014 6:13 PM, "Justin Uberti" <[email-masked]> wrote:

requests for it.

That is great. BTW does Chrome use aggressive nomination when the peer is
full ICE? I did not check that.

Thanks.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 09:33:54 -0700

Yes, Chrome always uses aggressive nomination unless ICE Lite is used.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Jul 2014 18:47:19 +0200

> And yes, you would use the contents of the PRIORITY attribute to determine

Thanks for confirming that!

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Jul 2014 10:02:15 -0700

> Chrome supports ICE lite, with regular nomination. There were a lot of

OK. I withdraw my objection. We'll get on fixing the relevant piece of
Firefox.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Jul 2014 19:04:46 +0200

> OK. I withdraw my objection. We'll get on fixing the relevant piece of

So many thanks Eric.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Jul 2014 13:26:48 -0400

> Yes, Chrome always uses aggressive nomination unless ICE Lite is used.
What about the cases when it sees unknown "ice-options" attribute? This
should make Chrome use regular nomination as well.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 Jul 2014 11:43:35 -0700

Chrome doesn't do that. I think that behavior is harmful and is going to be
changed in ice-bis.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 12 Jul 2014 00:06:16 +0200

Agreed. Imagine a future RFC defining
a=ice-option:no-regular-nomitation-support so Chrome does not understand it
and thus... uses regular nomination...

--
Iñaki Baz Castillo
<[email-masked]>
On Jul 11, 2014 8:43 PM, "Justin Uberti" <[email-masked]> wrote:

> Chrome doesn't do that. I think that behavior is harmful and is going to
> be changed in ice-bis.