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

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Jul 2017 23:45:03 -0700

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.