Re: [rtcweb] Importance of local addresses in ICE

Justin Uberti <juberti@google.com> Wed, 29 April 2015 23:54 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 DA2541A8AEC for <rtcweb@ietfa.amsl.com>; Wed, 29 Apr 2015 16:54:57 -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 vMmPYI6D5XYP for <rtcweb@ietfa.amsl.com>; Wed, 29 Apr 2015 16:54:56 -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 2EC051A8AEA for <rtcweb@ietf.org>; Wed, 29 Apr 2015 16:54:56 -0700 (PDT)
Received: by iejt8 with SMTP id t8so55389596iej.2 for <rtcweb@ietf.org>; Wed, 29 Apr 2015 16:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DiLbqjC4QrzGPcDJ7/Ziy77vdPOnBBOF7plV8IpSl0U=; b=lx2S8p/FIU/G6+pel3pjohuzE5xAf+jZFORjGczvtEb7CLrRCI3gNhdrCBpzOBeG2c qyvErLfgRY5ktqREZ9xMcUY2Qe1uGQrllTvCOK2khbZOnE0CeBhp0OaY+nf4eEfLPVMI 14iZDqwM3bqfbjmTTYuqVHBCMleANO2Rxo3NV0qMPRHMYPw1ZWIOzsISBRlAy3+OQygq FSDadIUzfAco6eKWj22qYJPv8TQjfmhBHrEGMonGJUUCw7OsYztrw25pU2b56ItBz4U6 +rykbACjC1cchyrplQuRBVzGKT2rFBemfzhPqNe+qOLkK7yShmKzsLTp8kAUuUPjnGAV DufA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DiLbqjC4QrzGPcDJ7/Ziy77vdPOnBBOF7plV8IpSl0U=; b=SJllRjv1gpZiK11YRjyeH5fn16L5WN9u49I28hw3ZL6qCvZ01vaOf507y++4mWrBE+ WsrY6sHActZhe1rNQqtRcRJSfmSzOLDDUnGY37vhpy0A0wkgqR6Dq6pwXpppMwhK/RXY a8CHyzYuNlPWJukVG6M6S0NGOPVc8uzELzlbBQJGgbJ7CUXazBdIJQpfHqSMQUHrCOHE NIR2KlFn/yGRJ+fp/u21mFgs+HSmWg1ScBxUyr0Ss2s/3KPCbWkMTIswYi55kiXoTfDp Yt5l1VUSGkLnDLlet+6eg4sqWtUCHFA4Og0gDEbzzhooqZOqE4CIlAo1K4b/vSM4G2ti GUTQ==
X-Gm-Message-State: ALoCoQkiht92jg8bWxk2DrwMBFHJwiE8WaFpRSPhD1U7fJAtU2myeu3A/pEv+P3646rJavjOtD3x
X-Received: by 10.107.128.149 with SMTP id k21mr2072366ioi.7.1430351695527; Wed, 29 Apr 2015 16:54:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.32.233 with HTTP; Wed, 29 Apr 2015 16:54:35 -0700 (PDT)
In-Reply-To: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca>
References: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca>
From: Justin Uberti <juberti@google.com>
Date: Wed, 29 Apr 2015 16:54:35 -0700
Message-ID: <CAOJ7v-3rxX-PgbrmZ1qVOyDs6jOxCgdt8LZDwGdHNYf_ckkxxg@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary="001a113f9224b75cf60514e5b4db"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/o57Ac4PF7nZdG50UYSm3r88E43g>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Importance of local addresses in ICE
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: Wed, 29 Apr 2015 23:54:58 -0000

Are you referring to our proposal where we surface the single host IP used
for contacting the STUN/TURN servers, or surfacing all host IPs? I
generally agree that surfacing a single host IP is important, especially
given CGN as you mention, but surfacing all may have fingerprinting
implications.

It would be good to get empirical data on how often host-host occurs in the
wild - if anyone is running a WebRTC service with p2p calls and can get
data on the %age of host-host candidate calls, that would be greatly
appreciated. (Hangouts is client-server.)

On Sun, Apr 26, 2015 at 8:24 PM, Cullen Jennings <fluffy@iii.ca> wrote:

> There has been some suggestion that the ICE should not advertise
> candidates that were addresses from a NATed address space. I think it is
> critical that we do and here is why.
>
> Carrier Grade NATs (CGN) are becoming far more common in many countries.
> Most measures of them show they are not friendly towards over the top VoIP
> traffic (totally shocker given they are often deployed by people offering a
> commercial voice service as well). So when you have two user both behind
> the same GCN, if ICE does not expose the local address, all of the traffic
> is forced thought the GCN (which may have more jitter than you might hope)
> and to a TURN server. If the ICE contained the local candidates then media
> would go directly through between the devices.
>
> CGN while not that common in the US is prevalent in many countries -
> particularly ones that had less IPv4 addressed allocated to them.
>
> Now you can say that this might reveal some information about their IP
> address. But think about what we really wish the wold looked like. There
> was no NAT and they had a IPv6 address. I have a hard time seeing how to
> DHCP generated address behind the NAT is hugely different than a random
> allocated v6 address so I don't see much downside on doing this and I see
> huge upside - particularly for people that are working of a cellular data
> link behind a CGN.
>
> I am also think that in general, end to end is better for privacy than
> forcing all your data through a MITM that the user does not control (the
> TURN server and CGN in this case).
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>