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

[Iñaki Baz Castillo <[e-mail]>]

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
<[e-mail]>
El 03/10/2013 21:22, "Christer Holmberg" <[e-mail]>
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.
>
>
>
> 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:* [e-mail] [[e-mail]] on behalf of
> Justin Uberti [[e-mail]]
> *Sent:* Thursday, 03 October 2013 9:49 PM
> *To:* Harald Alvestrand
> *Cc:* [e-mail]
> *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 <[e-mail]>wrote:
>
>>  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.
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>> ------------------------------
>> *From:* [e-mail] [[e-mail]] on behalf of
>> Christer Holmberg [[e-mail]]
>> *Sent:* Thursday, 03 October 2013 7:30 PM
>> *To:* Matthew Kaufman; [e-mail]
>> *Subject:* Re: [rtcweb] No a=ice-lite in JSEP-04
>>
>>   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:* [e-mail] [[e-mail]] on behalf of
>> Matthew Kaufman [[e-mail]]
>> *Sent:* Thursday, 03 October 2013 7:01 PM
>> *To:* [e-mail]
>> *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 <[e-mail]><[e-mail]>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.
>> >
>> >
>>
>> 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
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing [e-mail]://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>   --
>> Surveillance is pervasive. Go Dark.
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>