Re: [rtcweb] [Suspected Junk Mail] Importance of local addresses in ICE

Cullen Jennings <fluffy@iii.ca> Sun, 17 May 2015 21:14 UTC

Return-Path: <fluffy@iii.ca>
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 1B57B1ACEC4 for <rtcweb@ietfa.amsl.com>; Sun, 17 May 2015 14:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.764
X-Spam-Level:
X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 P5ZV-CusboWJ for <rtcweb@ietfa.amsl.com>; Sun, 17 May 2015 14:14:51 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E0C1AD0C7 for <rtcweb@ietf.org>; Sun, 17 May 2015 14:13:48 -0700 (PDT)
Received: from [10.0.232.47] (unknown [205.158.164.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 965FD509BB; Sun, 17 May 2015 17:13:46 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAOJ7v-3rxX-PgbrmZ1qVOyDs6jOxCgdt8LZDwGdHNYf_ckkxxg@mail.gmail.com>
Date: Sun, 17 May 2015 14:13:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D805F959-3893-4AB4-9CD1-B01748663253@iii.ca>
References: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca> <CAOJ7v-3rxX-PgbrmZ1qVOyDs6jOxCgdt8LZDwGdHNYf_ckkxxg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/-P-VDNN0h7Vr4iLO2BV6XbyOTNk>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [Suspected Junk Mail] 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: Sun, 17 May 2015 21:14:53 -0000

The problem with surfacing a single host IP is it is very hard to choose which one. As I pointed the idea of a default route is not as simple as one might think. For example, on some things the default route depends on the domain name you are trying to reach. 


> On Apr 29, 2015, at 4:54 PM, Justin Uberti <juberti@google.com> wrote:
> 
> 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
>