Draft: draft-ietf-rtcweb-ip-handling

Commentary: This reverts commit .
In order to establish a peer-to-peer connection, WebRTC
implementations use Interactive Connectivity Establishment (ICE)
RFC8445, which attempts to discover multiple IP addresses using
techniques such as Session Traversal Utilities for NAT (STUN) RFC5389
and Traversal Using Relays around NAT (TURN) RFC5766, and then checks
the connectivity of each local-address-remote-address pair in order
to select the best one.  The addresses that are collected usually
consist of an endpoint's private physical/virtual addresses and its
public Internet addresses.
These addresses are exposed upwards to the web application, so that
they can be communicated to the remote endpoint for its checks.  This
allows the application to learn more about the local network
configuration than it would from a typical HTTP scenario, in which
the web server would only see a single public Internet address, i.e.,
the address from which the HTTP request was sent.
In order to establish a peer-to-peer connection, WebRTC
implementations use Interactive Connectivity Establishment (ICE)
RFC8445, which attempts to discover multiple IP addresses using
techniques such as Session Traversal Utilities for NAT (STUN) RFC5389
and Traversal Using Relays around NAT (TURN) RFC5766, and then checks
the connectivity of each local-address-remote-address pair in order
to select the best one.  The addresses that are collected usually
consist of an endpoint's private physical or virtual addresses and
its public Internet addresses.
These addresses are provided to the web application so that they can
be communicated to the remote endpoint for its checks.  This allows
the application to learn more about the local network configuration
than it would from a typical HTTP scenario, in which the web server
would only see a single public Internet address, i.e., the address
from which the HTTP request was sent.
Of these three concerns, #1 is the most significant, because for some
users, the purpose of using a VPN is for anonymity.  However,
different VPN users will have different needs, and some VPN users
(e.g., corporate VPN users) may in fact prefer WebRTC to send media
traffic directly, i.e., not through the VPN.
Of these three concerns, the first is the most significant, because
for some users, the purpose of using a VPN is for anonymity.
However, different VPN users will have different needs, and some VPN
users (e.g., corporate VPN users) may in fact prefer WebRTC to send
media traffic directly, i.e., not through the VPN.
The second concern is less significant but valid nonetheless.  The
core issue is that web applications can learn about addresses that
are not exposed to the internet; typically these address are IPv4,
but they can also be IPv6, as in the case of NAT64 RFC6146.  While
disclosure of the RFC4941 IPv6 addresses recommended by I-D.ietf-
rtcweb-transports is fairly benign due to their intentionally short
lifetimes, IPv4 addresses present some challenges.  Although private
IPv4 addresses often contain minimal entropy (e.g., 192.168.0.2, a
fairly common address), in the worst case, they can contain 24 bits
of entropy with an indefinite lifetime.  As such, they can be a
fairly significant fingerprinting surface.  In addition, intranet web
sites can be attacked more easily when their IPv4 address range is
externally known.
The third concern is the least common, as proxy administrators can
already control this behavior through organizational firewall policy,
and generally, forcing WebRTC traffic through a proxy server will
have negative effects on both the proxy and on media quality.
When binding to a wildcard address, some extra work is needed to
determine the associated local address required by Mode 2, which we
define as the source address that would be used for any packets sent
to the web application host (assuming that UDP and TCP get the same
routing).  Use of the web application host as a destination ensures
the right source address is selected, regardless of where the
application resides (e.g., on an intranet).
When binding to a wildcard address, some extra work is needed to
determine the associated local address required by Mode 2, which we
define as the source address that would be used for any packets sent
to the web application host (assuming that UDP and TCP get the same
routing treatment).  Use of the web application host as a destination
ensures the right source address is selected, regardless of where the
application resides (e.g., on an intranet).
This document is entirely devoted to security considerations.
This document describes several potential privacy and security
concerns associated with WebRTC peer-to-peer connections, and
provides mechanisms and recommendations for WebRTC implementations to
address these concerns.