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

From: Justin Uberti <[email-masked]>
Date: Sun, 11 Feb 2018 11:23:32 -0800

OK, I updated the doc as discussed in this thread. PTAL at
https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-05 and see if the
changes look reasonable.

On Thu, Dec 14, 2017 at 1:32 PM, Martin Thomson <[email-masked]>
wrote:

> 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.
> >
> > 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: Mon, 12 Feb 2018 09:59:31 +1100

Lots more changes there than I expected, most good.

When talking about mode 1, you say: "significanly limites the network
information exposed to arbitrary web pages."   Aside from the typos
there, I think that this is incorrect.  You are talking about mode 1,
which creates maximum exposure.  I think that what limits information
is the requirement for explicit permission, but that isn't how the
sentence is constructed.

With the addition of "The recommended defaults are as follows:" that
same text is potentially more misleading.  It suggests that mode 1 is
the first choice, which isn't the intent at all.  I would revert that
addition.

The newly added Section 6 seems exclusively about implementation of
the route towards an origin.  I think that this goal could be more
explicit (changing the header might help).  I also think that it could
be constructed more rationally:

1. Goal: The intent is to determine the source address that would be
added to packets that are sent toward the origin.  Start by assuming
that UDP and TCP get the same routing.

2. Process: Bind a UDP socket to the null address (0.0.0.0 or ::) and
tell the socket to connect to the IP we have previously determined for
the origin.  Generally this results in the socket being assigned a
local address based on the host routing table without sending any
packets.  The socket can then be queried to determine the local
address.

3. Details: Hosts that use a proxy can use the IP address they would
use for connecting to that proxy.  For a file:// origin, pick a route
toward an arbitrary IP address.

"If the client is behind a proxy and cannot resolve the IPs via DNS,
the IPv4/v6 addresses of the proxy can be used instead."  (Nit: "IP
addresses") I think that this suggests a different default for clients
that use proxies...

Nits:

p2p needs acronym expansion, OS probably too

---

From: Justin Uberti <[email-masked]>
Date: Tue, 13 Feb 2018 12:59:27 -0800

> is the requirement for explicit permission, but that isn't how the

Yes, that was not my best work. I wanted to make clear that this provides
benefits for trusted WebRTC applications (the first half of the sentence),
but agree the second half is confusing. I plan to strike everything after
the comma, typos and all.

> the first choice, which isn't the intent at all.  I would revert that

This was intended to be a segue from enumerating the modes to providing
recommendations, but I agree it still feels somewhat awkward - will plan to
strike if you don't think a segue is needed.

> toward an arbitrary IP address.

The intent is actually twofold:
1) How to use OS routing - bind to 0.0.0.0/::.
2) How to figure out the proper source address when binding to 0.0.0.0/:: -
do the steps you mention.

One option could be to simply split the Implementation Guidance into these
two sections, where the body of the second section would be as you describe
(and then both would have a descriptive section header).

> addresses") I think that this suggests a different default for clients

Not quite sure what you meant by different default.

> p2p needs acronym expansion, OS probably too

Agree on p2p; a brief perusal of RFCs seems to indicate that OS as an
not-explicitly-defined-acronym is OK.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Feb 2018 10:05:34 +1100

Looks like you have it in hand.

> do the steps you mention.

Sounds like a reasonable plan.  I'll trust you to get the split right
however it works out (one section or two).

> Not quite sure what you meant by different default.

Mode 2 as default when a proxy is enabled has the unfortunate effect
of requiring that the browser probe the default path to the origin.
This text seems to say that if you won't do DNS, or if DNS returns an
error, then you probe toward the proxy.  Maybe these clients shouldn't
even bother using that IP address.  Of course, that pushes endpoints
behind the same proxy onto relays unnecessarily, so it's crappy either
way.

'twas an idle thought only.  Pay it no mind.  I'm sure that we can
each come to our own conclusions about this.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 13 Feb 2018 16:44:43 -0800

> however it works out (one section or two).

OK. Will send a PR for your stamp this week.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 26 Feb 2018 22:56:47 -0800

https://github.com/juberti/draughts/pull/96