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, 01 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 >
- Structuring the BKK spin bit discussion Lars Eggert
- Re: Structuring the BKK spin bit discussion Dmitri Tikhonov
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Martin Thomson
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Ted Hardie
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen
- RE: Structuring the BKK spin bit discussion Marcus Ihlar
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Jana Iyengar
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Martin Thomson
- Re: Structuring the BKK spin bit discussion Jana Iyengar
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- Re: Structuring the BKK spin bit discussion Ian Swett
- SV: Structuring the BKK spin bit discussion Marcus Ihlar
- Re: SV: Structuring the BKK spin bit discussion alexandre.ferrieux
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- RE: Structuring the BKK spin bit discussion Praveen Balasubramanian
- Re: Structuring the BKK spin bit discussion Brian Trammell (IETF)
- Re: Structuring the BKK spin bit discussion Roland Zink
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen
- Re: Structuring the BKK spin bit discussion Christian Huitema
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- RE: Structuring the BKK spin bit discussion Mike Bishop
- Re: Structuring the BKK spin bit discussion Roland Zink
- Re: Structuring the BKK spin bit discussion Roland Zink
- RE: Structuring the BKK spin bit discussion Roni Even (A)
- Re: Structuring the BKK spin bit discussion Kazuho Oku
- Re: Structuring the BKK spin bit discussion Mikkel Fahnøe Jørgensen