Re: Structuring the BKK spin bit discussion

Roland Zink <roland@zinks.de> Thu, 01 November 2018 10:28 UTC

Return-Path: <roland@zinks.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222B91294D0 for <quic@ietfa.amsl.com>; Thu, 1 Nov 2018 03:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zinks.de
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 A8Yiimn1_Pgl for <quic@ietfa.amsl.com>; Thu, 1 Nov 2018 03:27:59 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE23128C65 for <quic@ietf.org>; Thu, 1 Nov 2018 03:27:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1541068075; s=strato-dkim-0002; d=zinks.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=1cujfRvShX8RPBv3mbgYaMHJbs0xQePvcb2v67Qch30=; b=lOIKtyvbUGBDvnx7uB711U9Nbu3uf+cmAWcuOaVao4XazZzekpHtQ3IpR2DwY81Fbs qo0o5PtEvSnQYhUDd3XxiFwIvfPkiYEjnw0Cs4dLz/FSDQ99JdSuwkvCCEVTCGCQvdXO LLTBHgmU7REfzKwrmXTskH1hIVMidX6Q2+8XRqPdHnv1mxlPjspp8PFoJha4XvdAPHfY 64BAIvpITkWG8PX7FE+qV4b8am5OonzVnRQVFdSPHFE4pL5D5I2aJFYJZ/JDzptHhSAu jEv8eyk6IBkiX+4/Wz+qviqkjmDFDdKvE9GGkGST1WyetWQ9CiwDiFvVEAqsbrNDay67 0DPg==
X-RZG-AUTH: ":PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1YaZ2OgvlDQJHaSxcis="
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.105] by smtp.strato.de (RZmta 44.3 DYNA|AUTH) with ESMTPSA id R07dc3uA1ARt62n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <quic@ietf.org>; Thu, 1 Nov 2018 11:27:55 +0100 (CET)
Subject: Re: Structuring the BKK spin bit discussion
To: quic@ietf.org
References: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org> <20181029160802.GD7258@ubuntu-dmitri> <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net> <CANatvzxt-QBmeJUwp+MjtbpYXstPiEigDzQe0KfWJN+q0XR4Kg@mail.gmail.com> <HE1PR0701MB23938B01BC31888DAC3629B8E2CD0@HE1PR0701MB2393.eurprd07.prod.outlook.com> <CY4PR22MB0983A1FF62451F45923220B4DACE0@CY4PR22MB0983.namprd22.prod.outlook.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <658b7583-2687-cbd6-3bd3-508f211daa5d@zinks.de>
Date: Thu, 1 Nov 2018 11:27:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CY4PR22MB0983A1FF62451F45923220B4DACE0@CY4PR22MB0983.namprd22.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------2DD85E73D7A0919F01C64899"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AYPP8FZmTWb4kGKObp4vp_MNEc4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2018 10:28:03 -0000

Often the data of roaming users is tunneled back to the home operator. 
Coming back to the question about NAT and VPN use case I would consider 
this as the mobile network acts as a VPN and this isn't related to NAT. 
The same would happen when the mobile network operator wouldn't do NAT.

Regards,

Roland


Am 01.11.2018 um 04:47 schrieb Mike Bishop:
>
> But data connections when roaming run back to the home operator, IIUC, 
> so the size of Japan doesn’t mitigate this concern.  That means a 
> roaming user’s distance from Tokyo still gets disclosed, and it’s more 
> than measurement error if that user is roaming on a different continent.
>
> *From:* QUIC <quic-bounces@ietf.org>; *On Behalf Of * Marcus Ihlar
> *Sent:* Wednesday, October 31, 2018 7:40 AM
> *To:* Kazuho Oku <kazuhooku@gmail.com>;; Christian Huitema 
> <huitema@huitema.net>;
> *Cc:* Lars Eggert <lars@eggert.org>;; IETF QUIC WG <quic@ietf.org>;; 
> Dmitri Tikhonov <dtikhonov@litespeedtech.com>;
> *Subject:* SV: Structuring the BKK spin bit discussion
>
> Hi Kazuho,
>
> I believe the biggest difference is the size of the hidden network 
> segment.
>
> In the NAT case the client and NAT are still in the same country or 
> continent.
>
> A quick glacne at distancecalculator.net shows that the city farthest 
> from Tokyo in Japan is Naha-Shi, at 1554 km.
>
> That translates to roughly 5ms at the speed of light, so the kinds of 
> measurements to determine distance from Tokyo based on RTT will be 
> extremely sensitive and error prone.
>
> Please note that the distance analyis can be performed on handshake 
> RTT as well, for connections where the initial handshake is visible at 
> the measurement point.
>
> ------------------------------------------------------------------------
>
> *Från:*QUIC <quic-bounces@ietf.org <mailto:quic-bounces@ietf.org>> för 
> Kazuho Oku <kazuhooku@gmail.com <mailto:kazuhooku@gmail.com>>
> *Skickat:* den 31 oktober 2018 11:20
> *Till:* Christian Huitema
> *Kopia:* Lars Eggert; IETF QUIC WG; Dmitri Tikhonov
> *Ämne:* Re: Structuring the BKK spin bit discussion
>
> 2018年10月30日(火) 1:54 Christian Huitema <huitema@huitema.net 
> <mailto:huitema@huitema.net>>:
> >
> >
> >
> > > On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov 
> <dtikhonov@litespeedtech.com <mailto:dtikhonov@litespeedtech.com>> wrote:
> > >
> > >> On Mon, Oct 29, 2018 at 05:26:34PM +0200, Lars Eggert wrote:
> > >> We'd specifically like to ask client and server implementors with
> > >> projected sizable deployments to indicate whether they intent to
> > >> implement and deploy, if the WG decided to include the spin-bit in
> > >> the spec.
> > >
> > > LiteSpeed Technologies will support the spin bit -- both in our
> > > server and client QUIC implementations -- if it make it into the
> > > draft.
> >
> > My implementation is not used in any large scale deployment, but it 
> does support the spin bit. In fact, it has configuration options to 
> support spin bit variants: node, just spin, spin + vec, spin + QR.
> >
> > I think the strongest objection to the spin bit was put up by Marten 
> during the last interim: measuring the RTT with the spin bit discloses 
> the use of hidden path segments like VPN. This issue was not discussed 
> during the privacy analysis.
>
> May I ask if the VPN users are the only ones that lose some privacy
> with spin bits?
>
> I ask this because I live in a country where IIUC the mobile carriers
> place their nation-wide carrier-grade NAT near the capital city (i.e.,
> Tokyo). That means that for people living in the country, having spin
> bits turned on could reveal their distance from Tokyo.
>
> So the question is: if VPN users need special care, do some NAT users
> as well? Or if the answer is no, what is the difference from between
> the two groups?
>
> Generally speaking, I am not against giving users the freedom to
> expose spin bits, however I am wondering how the endpoints should
> provide the freedom of choice (UI question) as well as what the
> default should be.
>
> >
> > The privacy issue could be mitigated by turning off the spin bit at 
> privacy sensitive clients, but this would make these clients "stick out".
> >
> > One solution would be to remove the spin bit from the spec, trading 
> off better privacy for worse management. I am considering another 
> solution in which privacy sensitive clients hide the RTT by 
> controlling the spin, for example spinning at fixed intervals. I plan 
> testing that option in Picoquic.
> >
> > -- Christian Huitema
> >
> >
>
>
> -- 
> Kazuho Oku
>