Subject: [rtcweb] tweaks for ip-handling language

From: Alissa Cooper <[email-masked]>
Date: Wed, 16 Nov 2016 16:25:56 +0900

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.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Nov 2016 08:26:14 +0900

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 <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2016 08:57:01 +0900

I generally agree with Martin's comments, with the following exception.

I would remove everything after "off getUserMedia consent." It has no
normative effect
and is simply rationale.

-Ekr

On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson <[email-masked]>
wrote:

> > 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.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Nov 2016 04:54:52 +0100

> I would remove everything after "off getUserMedia consent." It has no

If we have rough consensus that the rationale is not unreasonable, I
like leaving rationale in.

>
> -Ekr
>
>
> On Thu, Nov 17, 2016 at 8:26 AM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 16 November 2016 at 16:25, Alissa Cooper <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > 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
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Nov 2016 11:57:38 +0900

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.