Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 14:10:45 +0000

Hi,

Just to be clear, with “WebRTC endpoint” I guess you do not include gateways?

Maybe we should talk about “JSEP endpoints”, or something..

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 1. lokakuuta 2013 1:30
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Yes. In the offers and answers that WebRTC endpoints create, a=ice-lite is prohibited, since WebRTC endpoints must support "Full" ICE.

The remote endpoint may of course support only ICE Lite, and WebRTC implementations must work properly with such endpoints.

This isn't normatively indicated anywhere that I could find, so I plan to add specifics on this to the next version of JSEP.

On Mon, Sep 30, 2013 at 8:32 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) <[email-masked]<mailto:[email-masked]>>:
> JSEP-04 prohibits the use of a=ice-lite. It is stated that it is incompatible with I-D.ietf-rtcweb-rtp-usage.
> Can you point out which specific aspect of this draft ICE Lite is incompatible with?
>
> In deployments where one endpoint is a browser and another one is a gateway connected to the public Internet, it makes sense to allow ICE lite.
Without reading JSEP-04 I expect that it is not allowed for a web
browser to indicate "a=ice-lite", but a server can do that. Anyhow,
AFAIR the usage of ICE lite is fully transparent for the non ICE lite
endpoint.

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Oct 2013 16:18:33 +0200

On Thu, Oct 3, 2013 at 4:10 PM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> Just to be clear, with “WebRTC endpoint” I guess you do not include
> gateways?****
>
> ** **
>
> Maybe we should talk about “JSEP endpoints”, or something.
>

I assumed he meant "browser".

-Ekr

>  Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Justin Uberti
> *Sent:* 1. lokakuuta 2013 1:30
> *To:* Iñaki Baz Castillo
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] No a=ice-lite in JSEP-04****
>
> ** **
>
> Yes. In the offers and answers that WebRTC endpoints create, a=ice-lite is
> prohibited, since WebRTC endpoints must support "Full" ICE. ****
>
> ** **
>
> The remote endpoint may of course support only ICE Lite, and WebRTC
> implementations must work properly with such endpoints.****
>
> ** **
>
> This isn't normatively indicated anywhere that I could find, so I plan to
> add specifics on this to the next version of JSEP.****
>
> ** **
>
> ** **
>
> ** **
>
> On Mon, Sep 30, 2013 at 8:32 AM, Iñaki Baz Castillo <[email-masked]> wrote:
> ****
>
> 2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) <[email-masked]>:*
> ***
>
> > JSEP-04 prohibits the use of a=ice-lite. It is stated that it is
> incompatible with I-D.ietf-rtcweb-rtp-usage.
> > In deployments where one endpoint is a browser and another one is a
> gateway connected to the public Internet, it makes sense to allow ICE lite.
> ****
>
> <[email-masked]>****
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>
> [email-masked]

---

From: Tim Panton <[email-masked]>
Date: Thu, 3 Oct 2013 15:26:35 +0100

I'm starting to think that we need a less clumsy name for the webRTC media wire protocol 
ICE/STUN/TURN/SRTP/DTLS/RTCP/Opus/VP8/ etc...

It looks likely to take on a life of it's own outside the browser.

T.

On 3 Oct 2013, at 15:10, Christer Holmberg wrote:

> 2013/9/30 Rauschenbach, Uwe (NSN - DE/Munich) <[email-masked]>:
> <[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Oct 2013 16:31:52 +0200

If I implement my own WebRTC stack in a smartphone app, am I disallowed to
do ICE-lite in my side??

Let's focus. We can mandate constrains just into browsers so IMHO "WebRTC
browser" is the appropriate name here.

--
Iñaki Baz Castillo
<[email-masked]>
El 03/10/2013 16:26, "Tim Panton" <[email-masked]> escribió:

> Maybe we should talk about “JSEP endpoints”, or something..****
> ** **
> Regards,****
> ** **
> Christer****
> ** **

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 3 Oct 2013 14:53:45 +0000

> ICE/STUN/TURN/SRTP/DTLS/RTCP/Opus/VP8/ etc...

RAI 2.0 seems to be the term that is getting used ….

---

From: Adam Roach <[email-masked]>
Date: Thu, 3 Oct 2013 09:53:40 -0500

On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <[email-masked]> wrote:

> If I implement my own WebRTC stack in a smartphone app, am I disallowed to do ICE-lite in my side??

I would hope so, yes. The chance that your smartphone app would have any hope if working if it did ice lite are as close to zero as to make no difference.

The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope. 

/a

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Oct 2013 17:13:32 +0200

--
Iñaki Baz Castillo
<[email-masked]>
El 03/10/2013 16:53, "Adam Roach" <[email-masked]> escribió:
> I would hope so, yes. The chance that your smartphone app would have any
hope if working if it did ice lite are as close to zero as to make no
difference.
>
> The fact that implementors apparently don't see this as an obvious fact
tells me that we need pretty strong language around this prohibition, and
"browser" is clearly too narrow a scope.

Some vendor will implement ICE-lite in its PBX and then many users will put
in into a LAN with port 5060 redirection in the router. And things won't
work.
The problem you describe will be present anyhow.

Regards.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 03 Oct 2013 09:01:36 -0700

> The fact that implementors apparently don't see this as an obvious fact tells me that we need pretty strong language around this prohibition, and "browser" is clearly too narrow a scope.

The spec should say that:
1. The prohibition on sending media prior to completing a STUN 
connectivity test is a MUST
2. A full ICE implementation is a SHOULD

If I'm building a system with clients at one end and gateways with 
public addresses at the other, a full ICE implementation isn't required 
anywhere in order to make calls through those gateways. But keeping the 
browser from being able to spew media at something that hasn't consented 
*is* required.

Matthew Kaufman

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 16:30:58 +0000

Hi,

Do we really need to say more than the ICE RFC already says? I think it explains when ICE-lite is appropriate, and when it isn't.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Matthew Kaufman [[email-masked]]
Sent: Thursday, 03 October 2013 7:01 PM
To: [email-masked]
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Oct 2013 18:48:17 +0200

Agreed. This is not a HOWTO but a set of specs.

--
Iñaki Baz Castillo
<[email-masked]>
El 03/10/2013 18:46, "Christer Holmberg" <[email-masked]>
escribió:

>  Hi,
>
>
>
> Do we really need to say more than the ICE RFC already says? I think it
> explains when ICE-lite is appropriate, and when it isn't.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Matthew Kaufman [[email-masked]]
> *Sent:* Thursday, 03 October 2013 7:01 PM
> *To:* [email-masked]
> *Subject:* Re: [rtcweb] No a=ice-lite in JSEP-04
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 16:48:56 +0000

What I think we DO need to say (eventhough someone may think it's obvious) , in the continous consent spec, is that ICE-lite entities do not send cc STUN requests.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Christer Holmberg [[email-masked]]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; [email-masked]
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Hi,

Regards,

Christer

Matthew Kaufman

---

From: Adam Roach <[email-masked]>
Date: Thu, 03 Oct 2013 12:32:24 -0500

I would assert that what we have is demonstrably insufficient, inasmuch 
as you, Iñaki, demonstrated just a few messages ago that you don't 
understand the present guidance. No one who does would ever even imagine 
putting ICE lite into a smartphone application.

Perhaps a reiteration in the RTCWEB documents would be appropriate.

/a

On 10/3/13 11:48, Iñaki Baz Castillo wrote:
> <[email-masked] <mailto:[email-masked]>>
>
> El 03/10/2013 18:46, "Christer Holmberg" 
> <[email-masked] 
> <mailto:[email-masked]>> escribió:
>
>     Hi,
>
>     Do we really need to say more than the ICE RFC already says? I
>     think it explains when ICE-lite is appropriate, and when it isn't.
>
>     Regards,
>
>     Christer
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] on
>     behalf of Matthew Kaufman [[email-masked]
>     <mailto:[email-masked]>]
>     *To:* [email-masked] <mailto:[email-masked]>
>     > On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > I would hope so, yes. The chance that your smartphone app would
>     have any hope if working if it did ice lite are as close to zero
>     as to make no difference.
>     >
>     > The fact that implementors apparently don't see this as an
>     obvious fact tells me that we need pretty strong language around
>     this prohibition, and "browser" is clearly too narrow a scope.
>     >
>     >
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 03 Oct 2013 19:43:32 +0200

On 10/03/2013 06:48 PM, Christer Holmberg wrote:
>
> What I think we DO need to say (eventhough someone may think it's
> obvious) , in the continous consent spec, is that ICE-lite entities do
> not send cc STUN requests.
>

Hm. If correct: What are the consequences of that?

It seems to me that the entity sending cc STUN requests is the one
asking for permission (although I may have misremembered something). So
this means that if there are no cc STUN requests coming from the
ice-lite end, the ice-lite end is neither requesting permission to
contine to send, nor is it going to stop sending when the WebRTC end
tries to revoke permission.

With the security guarantees we've been trying to work in here, where
it's safe to execute Javascript because there's a limit to how much
damage you can do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascript to
access that API (for brevity's sake, let's call them "browsers", even
though W3C tends to call them "UAs") MUST NOT implement ice-lite. No
matter whether they have a public IP address or not; if they implement
ice-lite, they can't offer the security guarantees we want.

Entities that don't offer an API that allows third parties to start
connections from it (for brevity, "non-browsers") have to be taken over
in other ways in order to perform an attack anyway, in which case all
the WebRTC guarantees are shot - so there's no harm in allowing them to
implement ice-lite.

> Christer Holmberg [[email-masked]]
> *Sent:* Thursday, 03 October 2013 7:30 PM
> *To:* Matthew Kaufman; [email-masked]
> Do we really need to say more than the ICE RFC already says? I think
> it explains when ICE-lite is appropriate, and when it isn't.
>
>  
>
> Regards,
>
>  
>
> Christer
>
>  
>
>  
>
> > I would hope so, yes. The chance that your smartphone app would have
> any hope if working if it did ice lite are as close to zero as to make
> no difference.
> >
> > The fact that implementors apparently don't see this as an obvious
> fact tells me that we need pretty strong language around this
> prohibition, and "browser" is clearly too narrow a scope.
> >
> >
>

-- 
Surveillance is pervasive. Go Dark.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 3 Oct 2013 11:49:16 -0700

Agree with Harald, although I don't like the terms "browser"/"non-browser",
since many folks (us included) are making native versions of the WebRTC
APIs available, which should conform to the same rules as their web
brethren.

WebRTC implementations (basically, anything exposing a WebRTC API) MUST
support full ICE, and MUST not support ICE Lite.
WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite.

On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand <[email-masked]>wrote:

> obvious) , in the continous consent spec, is that ICE-lite entities do not
> send cc STUN requests.
>
>
> It seems to me that the entity sending cc STUN requests is the one asking
> for permission (although I may have misremembered something). So this means
> that if there are no cc STUN requests coming from the ice-lite end, the
> ice-lite end is neither requesting permission to contine to send, nor is it
> going to stop sending when the WebRTC end tries to revoke permission.
>
> With the security guarantees we've been trying to work in here, where it's
> safe to execute Javascript because there's a limit to how much damage you
> can do with it.... I reach this conclusion:
>
> though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matter
> whether they have a public IP address or not; if they implement ice-lite,
> they can't offer the security guarantees we want.
>
> connections from it (for brevity, "non-browsers") have to be taken over in
> other ways in order to perform an attack anyway, in which case all the
> WebRTC guarantees are shot - so there's no harm in allowing them to
> implement ice-lite.
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
> > On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <[email-masked]><[email-masked]>wrote:
> >
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> --

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Oct 2013 19:08:26 +0000

Hi,

Why does the exposure of a WebRTC API determine whether the application must support full ICE or not? Shouldn't it depend on whether the application code is considered "trusted" or not.

For example, assume I would implement a gateway using node.js and WebRTP API. The gateway platform isn't downloading the JavaScript code from a webserver - it is "manually" installed, which means it can be reviewed before it is executed.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] on behalf of Justin Uberti [[email-masked]]
Sent: Thursday, 03 October 2013 9:49 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Agree with Harald, although I don't like the terms "browser"/"non-browser", since many folks (us included) are making native versions of the WebRTC APIs available, which should conform to the same rules as their web brethren.

WebRTC implementations (basically, anything exposing a WebRTC API) MUST support full ICE, and MUST not support ICE Lite.
WebRTC-compatible endpoints (e.g. gateways) MAY support ICE Lite.

On Thu, Oct 3, 2013 at 10:43 AM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
On 10/03/2013 06:48 PM, Christer Holmberg wrote:

It seems to me that the entity sending cc STUN requests is the one asking for permission (although I may have misremembered something). So this means that if there are no cc STUN requests coming from the ice-lite end, the ice-lite end is neither requesting permission to contine to send, nor is it going to stop sending when the WebRTC end tries to revoke permission.

With the security guarantees we've been trying to work in here, where it's safe to execute Javascript because there's a limit to how much damage you can do with it.... I reach this conclusion:

Entities that implement the WebRTC API, and allow others' Javascript to access that API (for brevity's sake, let's call them "browsers", even though W3C tends to call them "UAs") MUST NOT implement ice-lite. No matter whether they have a public IP address or not; if they implement ice-lite, they can't offer the security guarantees we want.

Entities that don't offer an API that allows third parties to start connections from it (for brevity, "non-browsers") have to be taken over in other ways in order to perform an attack anyway, in which case all the WebRTC guarantees are shot - so there's no harm in allowing them to implement ice-lite.

Regards,

Christer

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Christer Holmberg [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, 03 October 2013 7:30 PM
To: Matthew Kaufman; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

Hi,

Regards,

Christer

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Matthew Kaufman [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, 03 October 2013 7:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] No a=ice-lite in JSEP-04

On 10/3/2013 7:53 AM, Adam Roach wrote:
> On Oct 3, 2013, at 9:31, Iñaki Baz Castillo <[email-masked]><mailto:[email-masked]> wrote:
>

Matthew Kaufman

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Oct 2013 13:04:32 -0700

On 3 October 2013 12:08, Christer Holmberg
<[email-masked]> wrote:
> For example, assume I would implement a gateway using node.js and WebRTP
> API. The gateway platform isn't downloading the JavaScript code from a
> webserver - it is "manually" installed, which means it can be reviewed
> before it is executed.

In that case, given that node.js has a UDP API, there isn't a security
reason for preventing you from sending RTP.  You'd only need ICE-lite
to be compatible.  That said, if you want to use the WebRTC API,
wouldn't you want the same code (on both sides of the API)?

But that's not really the WebRTC API as specified, because the
specification has to assume the browser security model.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 3 Oct 2013 13:49:51 -0700

Agree with Martin.

Also, the implications of DTLS (for example) are substantially larger than
requiring full ICE. Given that full ICE is already strongly recommended by
5245, is there any non-academic reason to not mandate it for WebRTC
implementations?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Oct 2013 23:01:29 +0200

AFAIR JSEP is not about WebRTC API and belongs to RTCWEB IETF WG.
Anyhow the only reason for disallowing ICE-lite in some endpoints is the
fact that it would fail in NAT cases. OK, mandate no ICE-lite for browsers
and let implementors of other WebRTC devices to decide whether they want to
implement it or not (IMHO).

--
Iñaki Baz Castillo
<[email-masked]>
El 03/10/2013 21:22, "Christer Holmberg" <[email-masked]>
escribió:

>  Hi,
>
>
>
> Why does the exposure of a WebRTC API determine whether the application
> must support full ICE or not? Shouldn't it depend on whether the
> application code is considered "trusted" or not.
>
>
>
> Justin Uberti [[email-masked]]
> *Sent:* Thursday, 03 October 2013 9:49 PM
> *To:* Harald Alvestrand
> *Cc:* [email-masked]
>   Agree with Harald, although I don't like the terms
> "browser"/"non-browser", since many folks (us included) are making native
> versions of the WebRTC APIs available, which should conform to the same
> rules as their web brethren.
>
>> it's safe to execute Javascript because there's a limit to how much damage
>> you can do with it.... I reach this conclusion:
>>
>> any hope if working if it did ice lite are as close to zero as to make no
>> difference.
>> >