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

[Justin Uberti <[e-mail]>]

On Mon, Apr 16, 2018 at 3:24 PM Nils Ohlmeier <[e-mail]> wrote:

>
> On Mar 7, 2018, at 11:49, Sean Turner <[e-mail]> wrote:
> This is the WGLC for the "WebRTC IP Address Handling Requirements” draft
> available @
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/.  Please
> review the draft and send your comments to this list by 2359UTC on 30 March
> 30 2017.
>
>
> I apologize for bringing this up so late, but it looks to me like we
> should consider phrasing the words for Mode 4 in this draft more precisely.
>
> As shown here https://bugs.chromium.org/p/chromium/issues/detail?id=767304 and
> here https://bugzilla.mozilla.org/show_bug.cgi?id=1452713 implementers
> are somewhat confused what to do if Mode 4 is chosen, but no HTTP proxy is
> configured.
>
> At a minimum I would suggest to insert “HTTP” before each of the
> occurrences of the word proxy in the description:
>
> Mode 4:  Force proxy: This forces all WebRTC media traffic through a
>             proxy, if one is configured.  If the proxy does not support
>             UDP (as is the case for all HTTP and most SOCKS [RFC1928 <https://tools.ietf.org/html/rfc1928>]
>             proxies), or the WebRTC implementation does not support UDP
>             proxying, the use of UDP will be disabled, and TCP will be
>             used to send and receive media through the proxy.  Use of
>             TCP will result in reduced quality, in addition to any
>             performance considerations associated with sending all
>             WebRTC media through the proxy server.
>
> Because apparently some people think of proxies and TURN relays being the
> same thing. Which I don’t think is/was the intention here.
>
> Second of all I think the draft would benefit from explaining what to do
> expect in Mode 4 in the absence of a HTTP proxy.
>
> And lastly I think the discussions in the above bug reports have brought
> up the point that TURN relays might not be trustworthy either.
> I’m assuming it’s only a matter of time until when some evil actors will
> provide fake TURN implementations to gather the browsers routable IP from
> the TURN layer.
> Therefore I think it would make a lot more sense to specify two different
> modes:
> - Mode 4: Relay only: only TURN relay candidates are gathered.
> - Mode 5: HTTP proxy only: all WebRTC media traffic is forced through a
> HTTP proxy.
>                 If no HTTP proxy is configured no candidates are gathered.
> I realize that the process might have gotten already to far to follow this
> suggestion.
>
>
How would relay-only help here? The web application can still learn the IP
directly from the TURN servers.