Subject: Re: [rtcweb] Open issues for draft-ietf-rtcweb-ip-handling

From: Sean Turner <[email-masked]>
Date: Tue, 12 Dec 2017 08:31:52 -0500

These have been lingering for a bit, and I’d like to see if can’t resolve them.  Please let us know if you’ve got any opinions on the following 3 issues, which happen to be the only open issues stopping us from WGLCing this draft.

spt

> On Jul 20, 2017, at 02:45, Justin Uberti <[email-masked]> wrote:
> 
> Since there will be no WG meeting this week, here are the open issues for the document. Feedback on these issues is the only thing standing between this document and WGLC.
> 
> 1. https://github.com/juberti/draughts/issues/59
> 
> In the problem statement, should the paragraph on VPNs mention IP address discovery? 
> 
> Currently, the problem statement says the following:
>    1.  If the client is behind a Network Address Translator (NAT), the
>        client's private IP addresses, typically [RFC1918] addresses, can
>        be learned.
> 
>    2.  If the client tries to hide its physical location through a
>        Virtual Private Network (VPN), and the VPN and local OS support
>        routing over multiple interfaces (i.e., a "split-tunnel" VPN),
>        WebRTC will discover the public address for the VPN as well as
>        the ISP public address that the VPN runs over.
> 
> However, Bernard mentioned that even without split-tunnel support, the ICE implementation allows discovery of the VPN private address. I think this is covered by the first paragraph, but perhaps this should be spelled out further. Thoughts?
> 
> 
> 2. https://github.com/juberti/draughts/issues/60.
> 
> Should supporting WebRTC over Tor be an explicit goal of this document (and mentioned in the goals section)? 
> 
> This scenario is possible via Mode 4, e.g. force-proxy mode, but it may be out of scope for this document. Bernard mentioned that it may be out of scope as Tor distros can disable Javascript, making WebRTC useless, but upon investigation I found that the default Tor bundle does enable Javascript, and so this is worth considering. Thoughts?
> 
> 
> 3. https://github.com/juberti/draughts/issues/61
> 
> Should the document discuss implementation details as it relates to suggested default behavior? 
> 
> The document currently says the following:
> 
>     1.  By default, WebRTC should follow normal IP routing rules, to the
>        extent that this is easy to determine (i.e., not considering
>        proxies).  This can be accomplished by binding local sockets to
>        the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which
>        allows the OS to route WebRTC traffic the same way as it would
>        HTTP traffic, and allows only the 'typical' public addresses to
>        be discovered.
> 
> However, Bernard thinks that this text may be making some assumptions, specifically about whether a strong or weak host model is used. My thinking was that spelling out the general implementation approach helps readers grok exactly what this section is getting at, but open to other opinions here.
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Dec 2017 15:32:23 -0600

Since I was asked...

1. I think that this might benefit from a mention of the case.  You
are taking the effort to address the VPN case, but if someone has a
public address, this might be a surprise.

2. No specific text necessary here I think.  Forcing a proxy should do
for this case.  It's true that Tor browser doesn't necessarily disable
JS and WebRTC, but the forced proxy mode is a reasonable strategy for
that case.

3. I agree with you.

On Thu, Jul 20, 2017 at 1:45 AM, Justin Uberti <[email-masked]> wrote:
> Since there will be no WG meeting this week, here are the open issues for
> the document. Feedback on these issues is the only thing standing between
> this document and WGLC.
>
> However, Bernard mentioned that even without split-tunnel support, the ICE
> implementation allows discovery of the VPN private address. I think this is
> covered by the first paragraph, but perhaps this should be spelled out
> further. Thoughts?
>
> This scenario is possible via Mode 4, e.g. force-proxy mode, but it may be
> out of scope for this document. Bernard mentioned that it may be out of
> scope as Tor distros can disable Javascript, making WebRTC useless, but upon
> investigation I found that the default Tor bundle does enable Javascript,
> and so this is worth considering. Thoughts?
>
> However, Bernard thinks that this text may be making some assumptions,
> specifically about whether a strong or weak host model is used. My thinking
> was that spelling out the general implementation approach helps readers grok
> exactly what this section is getting at, but open to other opinions here.
>
>
>
>