Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling]

From: Justin Uberti <[email-masked]>
Date: Tue, 01 May 2018 21:33:08 +0000

Do you want to take a shot at the text? (either in email or as a PR)

On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier <[email-masked]> wrote:

>
> On Apr 30, 2018, at 15:03, Justin Uberti <[email-masked]> wrote:
>
> Any TURN server provided by the browser is in effect a proxy, and forcing
> use of said proxy can be done either through firewall config or explicit
> selection of Mode 4. (IOW, no new mode is needed.)
>
>
> I do agree that these two configurations result in a similar behavior.
> But I doubt that these use the same code path in implementations.
> And (thus) I doubt readers of the draft/RFC will automatically come to the
> same conclusion.
>
> It think it might be helpful to add another sentence explaining this
> scenario.
>
> The document originally pointed at RETURN as an example of how such TURN
> proxying could work, but was removed in order to avoid a dependency.
>
>
> Fair enough.
>
>   Nils
>
> On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings <[email-masked]> wrote:
>
>>
>>
>> On Apr 17, 2018, at 3:15 AM, Justin Uberti <
>> juberti=[email-masked]> wrote:
>>
>> IMO "trusting the TURN relay but not the application" is not a
>> significant enough benefit to merit adding specific functionality for.
>>
>>
>> In the case were the TURN server is provided by the JS, I agree. But in
>> the case where the configuration of the browser provided the TURN server,
>> then I think it is as trusted as say a VPN server.
>>
>>
>>
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 4 May 2018 11:26:39 -0400

Repo is here :)

https://github.com/juberti/draughts

spt

> On May 1, 2018, at 17:33, Justin Uberti <juberti=[email-masked]> wrote:
> 
>> Any TURN server provided by the browser is in effect a proxy, and forcing use of said proxy can be done either through firewall config or explicit selection of Mode 4. (IOW, no new mode is needed.)
> 
> And (thus) I doubt readers of the draft/RFC will automatically come to the same conclusion.
> 
> It think it might be helpful to add another sentence explaining this scenario.
> 
>> The document originally pointed at RETURN as an example of how such TURN proxying could work, but was removed in order to avoid a dependency.
> 
> Fair enough.
> 
>   Nils
> 
>>> On Apr 17, 2018, at 3:15 AM, Justin Uberti <juberti=[email-masked]> wrote:
>>> 
>>> IMO "trusting the TURN relay but not the application" is not a significant enough benefit to merit adding specific functionality for.
>>> 
>> 
>> In the case were the TURN server is provided by the JS, I agree. But in the case where the configuration of the browser provided the TURN server, then I think it is as trusted as say a VPN server. 
>> 
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 4 May 2018 09:50:09 -0700

Created https://github.com/juberti/draughts/pull/101 <https://github.com/juberti/draughts/pull/101>

  Nils

> On May 4, 2018, at 08:26, Sean Turner <[email-masked]> wrote:
> 
> Repo is here :)
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 May 2018 10:08:03 -0700

Thanks for the PR. I spent some time thinking about this and ultimately
concluded that more significant changes to the document will be necessary
if it is to prescribe how a browser-provided TURN server should be handled,
essentially incorporating much of the guidance from
https://tools.ietf.org/html/draft-ietf-rtcweb-return-02

For example, candidates produced from the TURN server should not have
raddr/rport set; interactions between the browser-provided and any
application-provided TURN server need to be described; the question of
whether local candidates should be provided needs to be considered.

As such, I see 3 paths forward here:
a) Leave the document as-is. While leaving some ambiguity on this topic,
the eventual (hopefully) publication of RETURN should clarify things, at
which point we can publish a -bis.
b) Discuss the general concept of browser-provided TURN servers, but
mention that this is an area of further study, and give some guidance based
on our current understanding. That is, explain how the existing modes would
work in the presence of a browser-provided TURN server.
c) Restore the reference to RETURN and progress the RETURN doc.

Overall, I don't expect the mode recommendations to change in the presence
of a browser- or network- provided TURN server, so I think any changes here
will be almost entirely additive.

Thoughts?

On Fri, May 4, 2018 at 9:50 AM Nils Ohlmeier <[email-masked]> wrote:

> Created https://github.com/juberti/draughts/pull/101
>
>   Nils
>
> IMO "trusting the TURN relay but not the application" is not a significant
> enough benefit to merit adding specific functionality for.
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 May 2018 07:20:48 -0600

> On May 11, 2018, at 11:08 AM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> Thanks for the PR. I spent some time thinking about this and ultimately concluded that more significant changes to the document will be necessary if it is to prescribe how a browser-provided TURN server should be handled, essentially incorporating much of the guidance from https://tools.ietf.org/html/draft-ietf-rtcweb-return-02 <https://tools.ietf.org/html/draft-ietf-rtcweb-return-02>
> 
> For example, candidates produced from the TURN server should not have raddr/rport set; interactions between the browser-provided and any application-provided TURN server need to be described; the question of whether local candidates should be provided needs to be considered.
> 
> a) Leave the document as-is. While leaving some ambiguity on this topic, the eventual (hopefully) publication of RETURN should clarify things, at which point we can publish a -bis.
> b) Discuss the general concept of browser-provided TURN servers, but mention that this is an area of further study, and give some guidance based on our current understanding. That is, explain how the existing modes would work in the presence of a browser-provided TURN server.
> Overall, I don't expect the mode recommendations to change in the presence of a browser- or network- provided TURN server, so I think any changes here will be almost entirely additive.
> 
> Thoughts?

I lean towards option B as it sounds like it meets our current needs and allows us to separate out the harder stuff to do later.