IETF Logo Mail Archive

[rtcweb] New proposal for IP address handling in WebRTC

Justin Uberti <juberti@google.com> Mon, 20 April 2015 05:49 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557721ACDC8 for <rtcweb@ietfa.amsl.com>; Sun, 19 Apr 2015 22:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIsKSM2M_J5H for <rtcweb@ietfa.amsl.com>; Sun, 19 Apr 2015 22:49:57 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDCF1ACDC7 for <rtcweb@ietf.org>; Sun, 19 Apr 2015 22:49:57 -0700 (PDT)
Received: by iebrs15 with SMTP id rs15so108898330ieb.3 for <rtcweb@ietf.org>; Sun, 19 Apr 2015 22:49:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=wyJIoU1vRuWrpOQcEobrFngu+X2kyOrDtFlW+DkzxLE=; b=O2gesD9CrVUF0HPVVnIcSxX5Qd4kyXTyYpF4lEuyIXEZI4ZtrlredzhTU/qTt4oJcw aW20wSAGv4DgLQLLuqbw6P2ToLPqm4LCUtMP5E+r55SMDBuWkSGLiyOx7QaQgS3thUWR ktmuRXv7wn640PtC3IOXS0R3cziGWkzARXgyM/Qrs5h5hRwe5AmUVar354I5C1GC/+92 uPcVdWmqaaKb6Ed/+R3+BrpCn8n50MMFz75eY9x+CeXtPe9YckGTnZanNtMvTH3P6tQv DOzAcgKV7jGgkbArlISfRpD1kzsm/jnHovSlVSZDm9rdfpNcjVAc1dThJfHF8sJLz9LK 1V0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=wyJIoU1vRuWrpOQcEobrFngu+X2kyOrDtFlW+DkzxLE=; b=f867j6wKkqYzia4kXfiRc9gnN8NzAoW9Eoh+qeYUPuEpvqY4zpQ52DThA2hhLlg8Te LkfOmHGu1yebBmo68GlchBmQGyI5sJxiKcfhuQUwi/Up6TQLiL/HWSomP8IDJOw3OqH4 XhGL2nTDT8S4XigrYodT4WgfrXwqI361Fm2NIlIShIIZX2Po7JiTTM6pSnGVfzEgssEQ nzmcpgFKnnvWbgcekxMl/QAR40BdSqHOSSxP3h3dO4BCIOAVPQ6iunrILyZmqsVtA40D hf8shSCzZF+fqkoiChm53wjfVNbDRbKWiM4/YlGbLzGJkpbYYDI13vRehCPQH8cbR6wz 1dOA==
X-Gm-Message-State: ALoCoQmoobHyZ5uDbanEvtaAyUInD5C9Z52ZcXYH9JttGxr12YpfouKilf0B6sYCYHcAA8DMUyPG
X-Received: by 10.43.71.201 with SMTP id yl9mr599002icb.66.1429508996920; Sun, 19 Apr 2015 22:49:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.63.3 with HTTP; Sun, 19 Apr 2015 22:49:36 -0700 (PDT)
From: Justin Uberti <juberti@google.com>
Date: Sun, 19 Apr 2015 22:49:36 -0700
Message-ID: <CAOJ7v-1BQ3cVBQy=DA0eKPkcQ0BP2Ga1t2nxi9uB_Yzs51GAvg@mail.gmail.com>
To: Guo-wei Shieh <guoweis@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c1dcbcf7473a0514217fd7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/Org7gB80gH1_OilmvdeGg7zqiqI>
Subject: [rtcweb] New proposal for IP address handling in WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2015 05:49:59 -0000

*Background*
At IETF 92 we proposed a browser mechanism that users could enable to avoid
disclosing their VPN IP to websites as a side effect of ICE candidate
generation. When this mechanism was enabled, the browser would bind only to
0.0.0.0 and ::, and only generate candidates via STUN and TURN; because
these sockets would follow the OS default routing, the only candidate
addresses discovered would be the ones that the website already had access
to (i.e. from the HTTP request).

The primary downsides with this mechanism were:
a) users had to manually enable it (through some potentially non-obvious
preference)
b) when enabled, it caused trombone routing in intranet cases
c) when enabled, it broke pretty much every simple demo page (which
typically don't use STUN servers)

*Proposal*
We now propose a new mechanism that attempts to address these issues. The
new mechanism works like the previous mechanism, but during the candidate
generation process, we call getsockname to obtain the local IP address of
the interface used to talk to the STUN/TURN server. This obtains a *single*
interface IP, which allows the browser to avoid trombone routing, but also
minimizes the amount of IP information revealed to JS. Furthermore, the
STUN traffic continues to go out the default route, meaning that if a VPN
is used, the 'real' public address is still not disclosed. (Naturally, this
has some performance implications, as a user may not always want their
media to go out the VPN.)

For pages that don't use STUN/TURN servers (typically demo pages), there
are a few options to consider:
a) always surface localhost as a candidate when no STUN/TURN servers are
provided (works with existing demos, but may have false positives with
certain apps)
b) always include some default STUN server when no STUN/TURN servers are
provided (similar to above, plus complexity of choosing default)
c) add some RTCConfiguration parameter indicating that the localhost
address is desired (requires updating many demo pages)

None of these choices is ideal, but this seems like a solvable problem.

*Implications for Browsers*
As this mechanism should alleviate the primary security concerns with
interface enumeration, with relatively small impact on user experience, we
propose that this be the default for browsers. For users that don't want to
disclose any local IP information, browsers could expose a preference that
prevents surfacing even the single local IP (i.e. the originally proposed
behavior). For users that want to ensure maximum performance (e.g. to
address the VPN issue above), a similar preference (or permissions grant)
could be exposed that allows enumeration of all IPs.

*FAQ*
Q: WebRTC already requires permission to access getUserMedia. Why not use
that permission to control interface enumeration?
A: Receive-only applications (e.g. streaming media) or datachannel
applications don't require a call to gUM, so there are cases where that
approach would not work.
Q: Is this only for browsers, or also for native apps?
A: This proposal is currently targeted at browsers. Native applications,
especially on mobile, need to be able to access individual interfaces in
order to be able to do seamless wifi-cellular call handover.

We welcome feedback on this proposal.

Guo-wei Shieh and Justin Uberti

v2.23.0 | Report a Bug | By Email