Subject: [rtcweb] Review of draft-ietf-rtcweb-ip-handling (part 1)

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 May 2017 18:43:13 -0400

General points:

a. Please expand acronyms on first use (e.g. HTTP, VPN, ICE, etc.).

Details

1 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-1>.
Introduction

   As a technology that supports peer-to-peer connections, WebRTC may
   send data over different network paths than the path used for HTTP
   traffic.  This may allow a web application to learn additional
   information about the user, which may be problematic in certain
   cases.  This document summarizes the concerns, and makes
   recommendations on how best to handle the tradeoff between privacy
   and media performance.

[BA] There are a number of distinct privacy issues that WebRTC

needs to address. I believe this document is focussed on IP

address info that can be gleaned by Web applications (the

second sentence).  That is somewhat distinct from what information

a web server might glean, or what a passive observer might be

able to obtain looking at traffic generated by a WebRTC client.

The first sentence therefore is a bit confusing to me.

A suggestion:

"As a technology that attempts to optimize peer-to-peer

connections by testing connectivity between available

addresses, WebRTC may allow a web application to learn

additional information about the user compared to an

application which only utilizes HTTP.  This may be

problematic in certain cases."

2 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-2>.
Problem Statement

   WebRTC enables real-time peer-to-peer communications by enumerating
   network interfaces and discovering the best route through the ICE
   [RFC5245 <https://tools.ietf.org/html/rfc5245>]protocol.  During
the ICE process, the peers involved in a
   session gather and exchange all the IP addresses they can discover,
   so that the connectivity of each IP pair can be checked, and the best
   path chosen.  The addresses that are gathered usually consist of an
   endpoint's private physical/virtual addresses, and its public
   Internet addresses.

[BA] The terms "route" and "path" used here do not refer to IP

routing and so is a bit confusing.  How about this?

   "In order to enable peer-to-peer communications, WebRTC

   peers utilize ICE [RFC5245] which gathers and exchanges

   all the IP addresses it can discover, so that the

   connectivity of each IP pair can be checked, and the best
   pair can be chosen.  The addresses that are gathered

   usually consist of an endpoint's private physical/virtual

   addresses, and its public Internet addresses."

   2.  If the client tries to hide its physical location through a 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.

[BA] Even if the local OS doesn't support split-tunnel,

isn't it still possible for an ICE implementation to

discover other addresses?

3 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-3>.
Goals

   Being peer-to-peer, WebRTC represents a privacy-enabling technology,
   and therefore we want to avoid solutions that disable WebRTC or make
   it harder to use.  This means that WebRTC should be configured by
   default to only reveal the minimum amount of information needed to
   establish a performant WebRTC session, while providing options to
   reveal additional information upon user consent, or further limit
   this information if the user has specifically requested this.
   Specifically, WebRTC should:

   o  Provide a privacy-friendly default behavior which strikes the
      right balance between privacy and media performance for most users
      and use cases.

   o  For users who care more about one versus the other, provide a
      means to customize the experience.

[BA] This section might state whether it is a

goal to enable WebRTC to be used with

The Onion Routing network (Tor). There

are a number of reasons why enabling Javascript

for  use with Tor may represent a problem so that

use of WebRTC might not be advisable:

https://security.stackexchange.com/questions/95046/why-disable-javascript-in-tor

 4 <https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-03#section-4>.
Detailed Design

   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.

[BA] This paragraph discusses routing behavior and
address binding together and leads me to wonder whether
some assumptions aren't being made (e.g. weak versus
strong host model). My suggestion is to simplify the
the paragraph and leave details to later on. For example:

"1. By default WebRTC should only allow applications
to discover the same address information made available
by an HTTP application: the 'typical' public address."