Subject: [rtcweb] Comments on draft-shieh-rtcweb-ip-handling

From: Adam Roach <[email-masked]>
Date: Wed, 10 Feb 2016 12:35:01 -0600

I've reviewed the RTCWEB IP handling document, and believe that the 
guidance it provides is correct. I have significant feedback on 
rationale, precision, and implications. I've also included a number of 
editorial suggestions.

In document order:

>          with both the VPN as well as the ISP public address over that
>          the VPN runs over.

"...address that the VPN runs over." (or "...address over which the VPN 
runs").

>     o  By default, WebRTC should follow the route for HTTP traffic, when
>        this is easy to determine (i.e. not considering proxies).

I don't think this is quite the right formulation. By default, WebRTC 
media should follow normal IP routing rules. In many cases, this will be 
the same as HTTP traffic, but that won't always be the case. The 
solution you describe -- binding to 0.0.0.0 or :: -- makes use of the 
kernel routing table, which may make a different decision than it did 
for the corresponding web site.

>     o  By default, support for host-host connections should be
>        maintained.

For people who have not been involved in the conversation so far, this 
is a pretty confusing description of what you're trying to say. I 
suggest something more like: "By default, WebRTC should enable direct 
connections between hosts in the same private network space [RFC1918] 
[RFC3927] [RFC4193] [RFC4862] [RFC5735]."

> connect()ing those sockets to a public
>        destination (e.g. "8.8.8.8"),

You're going to want to replace 'e.g. "8.8.8.8"' before publication is 
requested. Use of literal IP addresses in RFCs has become very strongly 
discouraged. I would suggest something like "e.g., the STUN or TURN 
server's address".

I would also suggest the document indicate that this technique does not 
require sending any traffic to the chosen address, and that it is simply 
a common trick for applications to retrieve information from the kernel 
about its routing table.

>     o  WebRTC incorporates an explicit permission grant for access to
>        local audio and video, which are typically much more sensitive
>        than the aforementioned IP address information.  If the user has
>        consented to media access, this should also allow WebRTC to gather
>        all possible candidates and determine the absolute best route for
>        media traffic.

[This is the most important comment I have on the document]

I don't think the rationale here follows. To be clear, I agree with the 
overall direction, but I think putting this in front of the security 
guys is asking for the draft to be shredded into ribbons. The notion 
that "camera access" is strictly more sensitive than "IP address" 
doesn't hold up to scrutiny.

I propose replacing this bullet with something more along the lines of: 
"When used with audio and video devices, WebRTC requires explicit user 
permission to access those devices. We propose that this permission 
grant be expanded to include consent to access all IP addresses 
associated with the user agent. This permission grant will allow WebRTC 
to gather all possible candidates and determine the the most optimal 
route for media traffic. Combining these permission grants -- rather 
than having the user grant permission individually -- is a considered 
balance that takes into account privacy, user notification fatigue, 
media performance, and informed consent. A key factor in this 
consideration is the implication of using cameras and microphones: when 
using physical devices with WebRTC, the user is typically engaging in a 
conversational session. Conversations are significantly more sensitive 
to network latency than most other real-time operations, and therefore 
benefit much more from the use of the most optimal network path available."

>     Mode 1  Enumerate all addresses: WebRTC will bind to all interfaces
>             individually and use them all to ping STUN servers or peers.

I think "ping" isn't really what you want. Perhaps "...use them all to 
attempt communication with STUN servers, TURN servers, and WebRTC peers."

>             access, as indicated in design idea #3 above.

If you're going to refer to the bullets by number, please make them a 
numbered list instead of unnumbered bullets. If you're using xml2rfc, 
use <list style="numbers">.

>     Mode 2  Default route + the single associated local address: By
>             binding solely to the "any" address, media packets will flow
>             through the same route as normal HTTP traffic.

"...media packets will follow the kernel routing table rules, which 
typically will be the same as the associated HTTP traffic."

>     Mode 3  Default route only: This is the the same as Mode 2, except
>             that the associated private address is not provided, which
>             may cause traffic to hairpin through NAT or fall back to the
>             application TURN server, with resulting quality implications.

"...hairpin through the NAT, call back to the application TURN server, 
or fail altogether..."

>     Mode 4  Force TCP and proxy: This is disables any use of UDP and
>             forces use of TCP to connect to the TURN server or peer.  If
>             a proxy server is configured, the TCP traffic will be sent
>             through the proxy, with resulting quality implications.

Can we strike "TCP" from this option? Yes, most of the time -- at least 
for now -- this will be TCP. But the important behavior here is that 
traffic go through a specific, configured proxy server. Basically, I 
want it to be clear that using a provisioned TURN server in the same way 
as one uses a provisioned HTTP proxy has the same privacy properties, 
and should be considered to be the same mode of operation.

Propose: "Force proxy: This forces all WebRTC media traffic through a 
proxy. If only an HTTP proxy server or TCP-only SOCKS server is 
configured, the use of UDP will be disabled, and media will be sent as 
TCP traffic through the proxy. The use of TCP for media degrades its 
performance significantly."

> For example, Chrome users can install the WebRTC
>     Network Limiter extension for this configuration.

I'm not sure this makes sense to go into an RFC. It's almost certainly 
going to be irrelevant and sound very quaint in 5 to 10 years.

>     The recommendations mentioned in this document may cause breakage to
>     certain WebRTC applications.

"...may cause certain WebRTC applications to malfunction or operate in a 
degraded fashion."

>     o  Applications should deploy a TURN server with support for both UDP
>        and TCP connections to the server.  This ensures that connectivity
>        can still be established, even when Mode 3 or Mode 4 are in use.

"This ensures that connectivity can typically be established, even when 
Mode 3 or Mode 4 are in use." Hairpinning -- even through a TURN server 
-- isn't always going to work. It will most of the time, but not always. 
Hence, "typically".

Thanks!

/a

---

From: Justin Uberti <[email-masked]>
Date: Tue, 16 Feb 2016 14:34:33 -0800

Thanks for the detailed review. Most of these are noncontroversial - the
one that probably needs more discussion is the question around a
provisioned TURN server.

On Wed, Feb 10, 2016 at 10:35 AM, Adam Roach <[email-masked]> wrote:

> guidance it provides is correct. I have significant feedback on rationale,
> precision, and implications. I've also included a number of editorial
> suggestions.
>
> In document order:
>

good catch.

> the same as HTTP traffic, but that won't always be the case. The solution
> you describe -- binding to 0.0.0.0 or :: -- makes use of the kernel routing
> table, which may make a different decision than it did for the
> corresponding web site.
>

I see where you are going, but "normal IP routing rules" seems overly
vague. I'll try another wording.

> For people who have not been involved in the conversation so far, this is
> a pretty confusing description of what you're trying to say. I suggest
> something more like: "By default, WebRTC should enable direct connections
> between hosts in the same private network space [RFC1918] [RFC3927]
> [RFC4193] [RFC4862] [RFC5735]."
>

Yes, this section could be clearer.

> discouraged. I would suggest something like "e.g., the STUN or TURN

The STUN/TURN server may not be the right choice (what if DNS is blocked?).
But agree it can be any public, stable IP address.

> require sending any traffic to the chosen address, and that it is simply a
> common trick for applications to retrieve information from the kernel about
> its routing table.
>

Good idea.

> overall direction, but I think putting this in front of the security guys
> is asking for the draft to be shredded into ribbons. The notion that
> "camera access" is strictly more sensitive than "IP address" doesn't hold
> up to scrutiny.
>
> permission to access those devices. We propose that this permission grant
> be expanded to include consent to access all IP addresses associated with
> the user agent. This permission grant will allow WebRTC to gather all
> possible candidates and determine the the most optimal route for media
> traffic. Combining these permission grants -- rather than having the user
> grant permission individually -- is a considered balance that takes into
> account privacy, user notification fatigue, media performance, and informed
> consent. A key factor in this consideration is the implication of using
> cameras and microphones: when using physical devices with WebRTC, the user
> is typically engaging in a conversational session. Conversations are
> significantly more sensitive to network latency than most other real-time
> operations, and therefore benefit much more from the use of the most
> optimal network path available."
>

Agree this could benefit from a more nuanced explanation, and thanks for
the suggested text.

> attempt communication with STUN servers, TURN servers, and WebRTC peers."

Will reword.

> numbered list instead of unnumbered bullets. If you're using xml2rfc, use
> <list style="numbers">.
>

OK.

> typically will be the same as the associated HTTP traffic."

OK.

> "...hairpin through the NAT, call back to the application TURN server, or
> fail altogether..."
>

OK.

> traffic go through a specific, configured proxy server. Basically, I want
> it to be clear that using a provisioned TURN server in the same way as one
> uses a provisioned HTTP proxy has the same privacy properties, and should
> be considered to be the same mode of operation.

> proxy. If only an HTTP proxy server or TCP-only SOCKS server is configured,
> the use of UDP will be disabled, and media will be sent as TCP traffic
> through the proxy. The use of TCP for media degrades its performance
> significantly."
>

I'm not sure about this. It really depends on how things should work when a
RETURN proxy is provisioned - does mode 3 mean that all traffic on the
default interface goes through the proxy, or do we try going through the
proxy and going direct simultaneously?

If the former, then mode 3 is sufficient. If the latter, then I agree with
your approach.

But I was thinking the former would be the least surprising behavior.

> going to be irrelevant and sound very quaint in 5 to 10 years.

Fair point.

> "...may cause certain WebRTC applications to malfunction or operate in a

Will reword.

> Mode 3 or Mode 4 are in use." Hairpinning -- even through a TURN server --
> isn't always going to work. It will most of the time, but not always.
> Hence, "typically".
>
> Agreed, although perhaps it would be better to simply say "assuming the
TURN server can be reached".

> Thanks!
>
> /a
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Feb 2016 17:54:29 -0600

On 2/16/16 16:34, Justin Uberti wrote:
>
>     Can we strike "TCP" from this option? Yes, most of the time -- at
>     least for now -- this will be TCP. But the important behavior here
>     is that traffic go through a specific, configured proxy server.
>     Basically, I want it to be clear that using a provisioned TURN
>     server in the same way as one uses a provisioned HTTP proxy has
>     the same privacy properties, and should be considered to be the
>     same mode of operation. 
>
>
>     Propose: "Force proxy: This forces all WebRTC media traffic
>     through a proxy. If only an HTTP proxy server or TCP-only SOCKS
>     server is configured, the use of UDP will be disabled, and media
>     will be sent as TCP traffic through the proxy. The use of TCP for
>     media degrades its performance significantly."
>
>
> I'm not sure about this. It really depends on how things should work 
> when a RETURN proxy is provisioned - does mode 3 mean that all traffic 
> on the default interface goes through the proxy, or do we try going 
> through the proxy and going direct simultaneously?
>
> If the former, then mode 3 is sufficient. If the latter, then I agree 
> with your approach.

Well, it's not just TURN servers -- it's anything that operates as a 
proxy and can deal with UDP traffic. Basically, it's a matter of 
future-proofing this option. If it makes you feel better, think of this 
as allowing the use of QUIC proxies in the future, if someone rolled out 
a QUIC-enabled TURN protocol. Or, if you'd like to look at a protocol 
that is actually specified (if not widely deployed), consider use with a 
UDP-enabled SOCKS5 proxy.

The point of my comment is that throwing "TCP" into mode 4 seems 
arbitrary. I'm not saying we have to outline the potential non-TCP cases 
that may arise; I just want us not to be so shortsighted as to preclude 
them.

/a