[rtcweb] IP handling text

[Martin Thomson <[e-mail]>]

4.  Detailed Design

   We define four modes of WebRTC behavior,
   reflecting different privacy/media tradeoffs:

   Mode 1:  Enumerate all addresses: WebRTC will bind to all interfaces
            individually and use them all to attempt communication with
            STUN servers, TURN servers, or peers.  This will converge on
            the best media path, and is ideal when media performance is
            the highest priority, but it discloses the most information.

   Mode 2:  Default route + the single associated local address: By
            binding solely to the wildcard address, media packets will
            follow the kernel routing table rules, which will typically
            result in the same route as the application's HTTP traffic.
            In addition, the associated private address will be
            discovered through getsockname, as mentioned above.  This
            ensures that direct connections can still be established
            even when local media access is not granted, e.g., for data
            channel applications.

   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 a NAT, fall back to the
            application TURN server, or fail altogether, with resulting
            quality implications.

   Mode 4:  Force proxy: This forces all WebRTC media traffic through a
            proxy, if one is configured.  If the proxy does not support
            UDP (as is the case for all HTTP and most SOCKS [RFC1928]
            proxies), or the WebRTC implementation does not support UDP
            proxying, the use of UDP will be disabled, and TCP will be
            used to send and receive media through the proxy.  Use of
            TCP will result in reduced quality, in addition to any
            performance considerations associated with sending all
            WebRTC media through the proxy server.

   Mode 1 MUST NOT be used without user consent.  This thwarts the typical
drive-by enumeration attacks.  The details of this consent are left to
the implementation. One potential mechanism is to tie this consent to
getUserMedia consent.  User agents SHOULD
   use Mode 2 by default, though they might choose a stricter default policy
   in certain circumstances.

  The main ideas for the design are 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.

   2.  By default, support for direct connections between hosts (i.e.,
       without traversing a NAT or relay server) should be maintained.
       To accomplish this, the local IPv4 and IPv6 addresses of the
       interface used for outgoing STUN traffic should still be surfaced
       as candidates, even when binding to the wildcard addresses as
       mentioned above.  The appropriate addresses here can be
       discovered by the common trick of binding sockets to the wildcard
       addresses, connect()ing those sockets to some well-known public
       IP address (one particular example being "8.8.8.8"), and then
       reading the bound local addresses via getsockname().  This
       approach requires no data exchange; it simply provides a
       mechanism for applications to retrieve the desired information
       from the kernel routing table.

   4.  Determining whether a web proxy is in use is a complex process,
       as the answer can depend on the exact site or address being
       contacted.  Furthermore, web proxies that support UDP are not
       widely deployed today.  As a result, when WebRTC is made to go
       through a proxy, it typically must use TCP, either ICE-TCP
       [RFC6544] or TURN-over-TCP [RFC5766].  Naturally, this has
       attendant costs on media quality and also proxy performance.

   5.  RETURN [I-D.ietf-rtcweb-return] is a new proposal for explicit
       proxying of WebRTC media traffic.  When RETURN proxies are
       deployed, media and STUN checks will go through the proxy, but
       without the performance issues associated with sending through a
       typical web proxy.

   Note that when a RETURN proxy is configured for the interface
   associated with the default route, Mode 2 and 3 will cause any
   external media traffic to go through the RETURN proxy.  This provides
   a way to ensure the proxy is used for external traffic, but without
   the performance issues of forcing all media through said proxy.