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

[Justin Uberti <[e-mail]>]

On Fri, Apr 20, 2018 at 10:18 AM Nils Ohlmeier <[e-mail]>
wrote:

>
> On Apr 20, 2018, at 07:48, Justin Uberti <
> juberti=[e-mail]> wrote:
>
> Small PR for improved text:
> https://github.com/juberti/draughts/pull/100/files
>
>
> I think this helps.
>
> I guess that the implementation is suppose to fall back to mode 3 (vs not
> work at all) derives from the “This is the same as Mode 3,…” part?
>

Correct.


> The only option which comes to my mind to make this more explicit would be
> to add another sentence like “If the applications HTTP traffic is not
> proxied it should fall back to Mode 3”.
>

I thought about this but decided just to clarify the sentence where it
refers to Mode 3, since adding an explicit sentence felt like belaboring
the point. If you still feel this is unclear I could be convinced.

>
>   Nils
>
> On Fri, Apr 20, 2018 at 5:50 AM Sean Turner <[e-mail]> wrote:
>
>> I’m going to go ahead and push this draft towards Adam (our AD) and we’ll
>> treat this as an IETF LC comment to get fixed up before the IESG telechat
>> (i.e., Justin just throw a PR in for whatever change, but there’s no need
>> to spin a new version).
>>
>> spt
>>
>> > On Apr 19, 2018, at 21:10, Lennart Grahl <[e-mail]
>> <[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
>> ).
>> >
>> > Cheers
>> > Lennart
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>