Re: Structuring the BKK spin bit discussion

Kazuho Oku <kazuhooku@gmail.com> Wed, 31 October 2018 10:21 UTC

Return-Path: <kazuhooku@gmail.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 B9C14129619 for <quic@ietfa.amsl.com>; Wed, 31 Oct 2018 03:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 GVW9j030ArEo for <quic@ietfa.amsl.com>; Wed, 31 Oct 2018 03:21:05 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 BA1E212958B for <quic@ietf.org>; Wed, 31 Oct 2018 03:21:04 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id z80-v6so8224843ljb.8 for <quic@ietf.org>; Wed, 31 Oct 2018 03:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lDtpRyKsjJ+r1TFVKzXIToDv8OAtJ0zr9MqtIlvktRc=; b=Ix+qB10sKAe3YAStW4eS4SjWEsRaKTGRmt0vlUcntv2Ri5xW3A6BE99UolgImQ60rV zLFeGcjqPoFLGCkWO4AUVGWkThtyDFNghmdU4unP1bihaDoNBJi9AFnJLF6QB195T3G/ LtHvgbfVmVD+BoOj5kIHAg0dK8mrPeOBcKKB5nEd7tSdqB4El9HP8V/XeHynYOKmxloK WvZaArn7mYrCxsa7MnOSpd++3W6S4TRw9DREOGsTtpYtuzioH5HfU3Ayhx5H61SeE1GB kFeUcdESXhKBL//PUaaJ9EEQ7qGbIBB8wSaMWfDmrFOgPEbYy/VNBkbrIkUQszcLVLkK 0GCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lDtpRyKsjJ+r1TFVKzXIToDv8OAtJ0zr9MqtIlvktRc=; b=nymUjEzS88oZUN85hTDqVFMvcMQbtB+kVjh4gZ//BERO71XEd+e8OJaXoUhvUoXFVM +O9LNXITN0Fnx75RWPutF2kk7KzzhMW5k0v7d2/36KMetQ6Zxkl1QPkv7XuR2MxGsyS4 r7Ugw78c9JbflbnujQS7BejEYrRBokqeEHiG40SO4S/18VqU9E8NacvOFiJho95YAMMX uVUyevpb7WkryZlAUMipHJxRpS9RAEfvttXKfWC3wiCbHhg0mpL1GdQFN8LPuypwSN+0 vOrjB14rgjZuUoqhqn/zRZvylUbOKgUGuKbycxuSZraOM04flUzZONy7LcNjvJPBFl0y WA+A==
X-Gm-Message-State: AGRZ1gLni9UmF6bKXj+U5j/43EFsXSIm5i2Ug9QiHrnogv7qKlOXWXk2 L4/s2cZnzgTaBC9K/QhsPrENf5SRb7B9A/J6Lug=
X-Google-Smtp-Source: AJdET5ed1/yLj8EtO9WIWlW8AWKTeJhOwPOEe6fgls2tr2jI1y09idTAsPtcJD2ji8n16Bpq29Mcxxjsz5TF0tRrHFQ=
X-Received: by 2002:a2e:3918:: with SMTP id g24-v6mr1545227lja.113.1540981262816; Wed, 31 Oct 2018 03:21:02 -0700 (PDT)
MIME-Version: 1.0
References: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org> <20181029160802.GD7258@ubuntu-dmitri> <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net>
In-Reply-To: <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 31 Oct 2018 19:20:51 +0900
Message-ID: <CANatvzxt-QBmeJUwp+MjtbpYXstPiEigDzQe0KfWJN+q0XR4Kg@mail.gmail.com>
Subject: Re: Structuring the BKK spin bit discussion
To: Christian Huitema <huitema@huitema.net>
Cc: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g-3ADJIkFXGbh-3fQ0xzu7lGqXA>
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 10:21:07 -0000

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