RE: Structuring the BKK spin bit discussion

Praveen Balasubramanian <pravb@microsoft.com> Wed, 31 October 2018 16:32 UTC

Return-Path: <pravb@microsoft.com>
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 3E78B1293FB for <quic@ietfa.amsl.com>; Wed, 31 Oct 2018 09:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level:
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 6hXPb37QJA2V for <quic@ietfa.amsl.com>; Wed, 31 Oct 2018 09:32:38 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0106.outbound.protection.outlook.com [104.47.36.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419A4128CE4 for <quic@ietf.org>; Wed, 31 Oct 2018 09:32:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mDQoPAzTy5IA2P93jWxO63H91APrKgPpdu+iZClpqik=; b=dmWLAhr+qeWnMtz9ABkzez1ptq7mVSdZtw7TD/bk6jyeL+FlCNkY/U0di5qfsNgriuHi05WWVmDnHMe/UKQU796KYKRNBIXQW6sCQQzxKRR1XVMb3/XfhZ8EnVv/+r2Izc8IDupeoQXNfcGzGEabf8l0JskhY0RxCrubpDDjf+Y=
Received: from DM5PR2101MB1046.namprd21.prod.outlook.com (52.132.128.15) by DM5PR2101MB0919.namprd21.prod.outlook.com (52.132.132.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.2; Wed, 31 Oct 2018 16:32:36 +0000
Received: from DM5PR2101MB1046.namprd21.prod.outlook.com ([fe80::9c64:a017:8062:939f]) by DM5PR2101MB1046.namprd21.prod.outlook.com ([fe80::9c64:a017:8062:939f%4]) with mapi id 15.20.1294.014; Wed, 31 Oct 2018 16:32:36 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Marcus Ihlar <marcus.ihlar@ericsson.com>
CC: Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>, huitema <huitema@huitema.net>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Kazuho Oku <kazuhooku@gmail.com>
Subject: RE: Structuring the BKK spin bit discussion
Thread-Topic: Structuring the BKK spin bit discussion
Thread-Index: AQHUb5vavgJndpf/BEmVaq54GPMvY6U2Y+yAgAAMqQCAArb/gIAAJugAgAAbi4CAACNjQA==
Date: Wed, 31 Oct 2018 16:32:36 +0000
Message-ID: <DM5PR2101MB10464C5346F73F83CAC25BD1B6CD0@DM5PR2101MB1046.namprd21.prod.outlook.com>
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> <D8BB0373-FDEB-4312-94E6-BBA304D595BE@trammell.ch>
In-Reply-To: <D8BB0373-FDEB-4312-94E6-BBA304D595BE@trammell.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:b:2933:a062:eb3b:5529]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0919; 6:cIqbD8rxthHyBa+8Ew1ITKwtxIJLtcowlgIroznPr8nsnkdmJwqktFcrSutPkEu+7ppddW/JFz/tNR0VULdAarlzOjH776wCP2AGJoExkZEioUEa5MDsUgvwQBClnjiGP5ddrf1YGCGq6U0dAS3Cs48g8u8LrF2KDqzBWMAIhKFKkmaWEvZ9PDMNb3iojCB6FfTFPg0sU7VZN2hsFQklYyKCXWJE3mxTixzIDCOeRQ5D2wKmMHPZin21N1rs2IKChqNIpPlcpy/PYsIqZOnx9RD5b3yLZDm2F1UPM7CpgKG4ogcWkF1bNX9hMF3oVk+njEEkvY5pFZTjFRcdaSYYRnpSzKqLGuwbNn+9UXcGNZkfu28lAov9c3bfDnlrj+3gZFmRW4inKHf+aZJkRKeNK3eNpFAKmt4n5dvOCAq09SWFx8dM0lq2G4CgFjlfpftb+gjphs0vTB3vmCozX2nx2A==; 5:bYg83oZst4ReddzyjWNsU+5Z5h0/44vIDA3+5GzDbggO9Y5yC3y749rUhSkuQVu1rcgtK8gZhhp31zKfTmkR3Ph1BOkiptkmwEzO9gBBxwQ9SBu8jyilye+Dm1K2doGICnYzxBM0a5/zlSajgi35XPwPtGSkm5/mnMFgfZjzVSM=; 7:Bhb8SOMaCgr1pceTruWjgGf4dr5NMeweDWnPbJbPRb4p4iszs5yGI8DyStfjdKUZlNue294oxr6EEKMeE6hmBG+RH/DVp661lsReOQMTdYqbyi3Ge2DdY0TaHtmqP9fYuKXN4FbZ7ZEhewu0KamuVw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 59020e94-ae8d-4daa-46dd-08d63f4e77b0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:DM5PR2101MB0919;
x-ms-traffictypediagnostic: DM5PR2101MB0919:
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <DM5PR2101MB0919FEBE49D7985E5A342DEEB6CD0@DM5PR2101MB0919.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(158342451672863)(248295561703944)(37575265505322)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231382)(944501410)(52105095)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DM5PR2101MB0919; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0919;
x-forefront-prvs: 084285FC5C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(346002)(39860400002)(376002)(189003)(13464003)(199004)(97736004)(8990500004)(5660300001)(10290500003)(76176011)(229853002)(316002)(305945005)(2900100001)(86612001)(6306002)(105586002)(46003)(14444005)(256004)(99286004)(186003)(9686003)(86362001)(106356001)(66574009)(71190400001)(7736002)(6246003)(71200400001)(22452003)(74316002)(53936002)(7696005)(14454004)(53546011)(33656002)(476003)(93886005)(6506007)(10090500001)(478600001)(5250100002)(8936002)(11346002)(6436002)(68736007)(102836004)(55016002)(8676002)(39060400002)(4326008)(966005)(25786009)(446003)(81166006)(6116002)(81156014)(54906003)(2906002)(6346003)(110136005)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0919; H:DM5PR2101MB1046.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-message-info: zaSCWNEOgRdVQo3R4rw3VUo+su4ZFhbUN7PCEWFH6Yv8YHmJHknYUsdR/N9tGI2y5hHkeljFZs+Q+LjC8A94rvbrr8LLmrgebarVzj4g+x+DKBpz89iSUry4HvZaBx5vvrX0cSrAf+TYjXsIyj98cJEIQyuVjIyFvW23FiReRLVEAwF6aiRh4mjRPN/EdJ8EQSlEB15pqyFIqCG+kroI213Amh8zbCFBCNNH3DVokRf2TR/2gBToy/k4SEsWhOI3Ev5ohANLAdxTiCn3myCf51XT8U2XjN7cJseQXfCteijin8W0xbo8cU2/ugHdUBpM2sdpzC3cya3jxXvhSMP6qZ/nuNTUhaJJo3SjhSBJ9So=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 59020e94-ae8d-4daa-46dd-08d63f4e77b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2018 16:32:36.6042 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0919
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-HRgkCswUa6LoeGNvHbeP5dccTk>
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: Wed, 31 Oct 2018 16:32:41 -0000

Since the handshake exposes the RTT information, what is the geolocation privacy issue resulting from the spin bit? Brian, what are the edge cases you refer to where handshake latency will be different than what is measured by spin bit? 

-----Original Message-----
From: QUIC <quic-bounces@ietf.org>; On Behalf Of Brian Trammell (IETF)
Sent: Wednesday, October 31, 2018 7:19 AM
To: Marcus Ihlar <marcus.ihlar@ericsson.com>;
Cc: Lars Eggert <lars@eggert.org>;; IETF QUIC WG <quic@ietf.org>;; huitema <huitema@huitema.net>;; Dmitri Tikhonov <dtikhonov@litespeedtech.com>;; Kazuho Oku <kazuhooku@gmail.com>;
Subject: Re: Structuring the BKK spin bit discussion

hi Kazuho, Marcus,

+1 to this; the intra-network latency variation on the mobile segment of the mobile networks we looked at via the MONROE in the testbed in our PAM paper the followed from the RTT DT work (see https://github.com/mami-project/rtt-privacy-paper/blob/master/rtt-privacy.pdf, especially section 3.1 and figure 2(b)) makes RTT measurement on a mobile network useless for geolocation.

We did notice (not shown in the paper) that different carriers (n = 4, if I recall correctly) had distinct latency distributions, so with traffic from all Japanese mobile users you could probably use RTT data in the aggregate to build a "carrier classifier". This is of course a useless exercise because you can already tell which carrier a subscriber is coming from by looking at the IP address of the CGNAT exit.

IMO there are only a few edge cases where there are actual potential geoprivacy issues raised by the spin bit with respect to tunneled VPN traffic. All of these involve trans- or intercontinental tunnels (>30ms of additional RTT, for 3000km of location uncertainty -- how far is it from Okinawa to Hokkaido?). In every case the handshake latency gives you away as well, but in every case long RTTs might also have non-distance related causes. So while I see disabling the spin bit as a necessary feature, especially for clients to have, IMO its utility is more useful for peace of mind and information reduction than for actual information elimination.

Cheers,

Brian

> On 31 Oct 2018, at 13:40, Marcus Ihlar <marcus.ihlar@ericsson.com>; wrote:
> 
> 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>; för Kazuho Oku 
> <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>;:
> >
> >
> >
> > > On Oct 29, 2018, at 9:08 AM, Dmitri Tikhonov <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