Re: [rtcweb] WGLC for draft-ietf-rtcweb-ip-handling

[Justin Uberti <[e-mail]>]

On Thu, Apr 19, 2018 at 6:10 PM Lennart Grahl <[e-mail]>
wrote:

> On 20.04.2018 02:02, Justin Uberti wrote:
> > On Thu, Apr 19, 2018 at 4:41 PM Lennart Grahl <[e-mail]>
> > wrote:
> >
> >> On 20.04.2018 01:29, Justin Uberti wrote:
> >>> On Thu, Apr 19, 2018 at 9:22 AM Nils Ohlmeier <[e-mail]>
> >> wrote:
> >>>
> >>>> While I understand the arguments against adding more mode I still
> think
> >>>> the paragraph describing Mode 4 is missing details and causes
> confusion
> >>>> among implementers:
> >>>>
> >>>> - It is not clear if the word “proxy” refers to a HTTP proxy or a TURN
> >>>> server.
> >>>>
> >>>> This can easily be improved by replacing the word “proxy” with “HTTP
> >>>> proxy” everywhere in the Mode 4 paragraph.
> >>>>
> >>>
> >>> The proxy doesn't need to be a HTTP proxy; it could be a SOCKS or
> RETURN
> >>> proxy (SOCKS is specifically noted in the para).
> >>>
> >>>>
> >>>> - It is unclear how an implementation should behave in the absence of
> >> such
> >>>> a proxy.
> >>>>
> >>>> I would suggest to add a sentence the implementation should not hand
> out
> >>>> any candidates in the absence of a HTTP proxy.
> >>>>
> >>>
> >>> This is a fair point. However, my take is that the behavior should be
> the
> >>> same as Mode 3 in this case, as the web server already sees the client
> >> IP.
> >>> I could add a sentence to make this super clear.
> >>
> >> The web server, yes. But not the other peer. I don't think we can assume
> >> trust towards the web server equals trust towards the other peer. I
> >> would agree with Nils that it shouldn't hand out any candidates in this
> >> case.
> >>
> >
> > This is not unique to Mode 4.
> >
> > This scenario is discussed in detail in
> >
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14#section-5.4
> ;
> > I don't think it needs special mention in this doc.
>
> Still, I see no possibility for the user to voice it's opinion in this
> matter. However, that may simply be an issue for the browser vendors to
> resolve (by providing additional browser settings - I think at least
> Firefox does that already).
>
> Then it probably should be clarified because if I'm not mistaken Chrome
> gets it wrong, too (no proxy = no candidates). Unless that fourth mode
> does not actually map to mode 4 (see
>
> https://cs.chromium.org/chromium/src/content/public/common/webrtc_ip_handling_policy.cc?q=rtcIPHandling&sq=package:chromium&dr=CSs&l=15
> ).
>
>
In Chrome Mode 4 is currently over-conservative, it forces the use of TCP,
and those TCP connections are sent through a proxy if one exists. This is
because "is a proxy present?" is a per-destination question (at least when
PAC files are used
<https://en.wikipedia.org/wiki/Proxy_auto-config#The_PAC_File>), and as
such was difficult to determine a priori.

FWIW, you can try it out at
https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia?hl=en
.