Re: [rtcweb] tweaks for ip-handling language

[Martin Thomson <[e-mail]>]

Taking ekr's suggestion...


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.
            As such, this should only be performed when the user has
            explicitly given consent for local media access, as
            indicated in design idea #3 above.

   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.  User agents SHOULD
   use Mode 2 by default, though they might choose a stricter default policy
   in certain circumstances.

Gathering all possible candidates MUST only be performed when some
form of user consent has been provided; 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.

  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.


On 17 November 2016 at 08:26, Martin Thomson <[e-mail]> wrote:
> This looks like a good change on its own.  However, reading the
> document, I find that the "all possible candidates" issue is hard to
> fix.  This text is part of the rationale for the different modes.
> Placing a requirement here - before we've established the baseline -
> is probably the wrong thing to do.
>
> I think that restructuring the corresponding section might be the best
> plan.  The text in question isn't rationale; it doesn't really belong
> where it is.
>
> Thus, I would recommend this structure:
> 1. define the 4 modes
> 2. recommend that mode 2 is the default.
> 3. include this text - tweaked slightly - to explain how user consent
> is necessary to use mode 1
> 4. explain that modes 3 and 4 might be made the default in certain contexts
> 5. include the other rationale to justify the design
>
>
> On 16 November 2016 at 16:25, Alissa Cooper <[e-mail]> wrote:
>> This still needs the fix for “all possible candidates.”
>>
>> OLD
>> Gathering all possible candidates SHOULD only be performed when some form of user consent has been provided; this thwarts the typical drive-by enumeration attacks.  The details of this consent are left to the implementation; one potential mechanism is to key this off getUserMedia consent.  The getUserMedia suggestion takes into account that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome.
>>
>> NEW
>> Gathering all possible candidates MUST only be performed when some form of user consent has been provided; 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. Such a mechanism might be chosen based on the fact that the user has provided some consent to the application already; that when doing so the user typically wants to engage in a conversational session, which benefits most from an optimal network path, and lastly, the fact that the underlying issue is complex and difficult to explain, making explicit consent for enumeration troublesome.
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb