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

From: Sean Turner <[email-masked]>
Date: Wed, 2 Aug 2017 12:15:34 -0400

Here’s another one that might have gotten buried since IETF week.

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