Re: Structuring the BKK spin bit discussion
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 31 October 2018 00:05 UTC
Return-Path: <mikkelfj@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 0A6FB1277CC for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 17:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 l8mFsS9JrZDn for <quic@ietfa.amsl.com>; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 AA0F1130DC7 for <quic@ietf.org>; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
Received: by mail-it1-x130.google.com with SMTP id e74-v6so16014321ita.2 for <quic@ietf.org>; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uHbUHM1vMvfBVz6+p6Y5TbQn4ane+bSQxv6gFDb+im0=; b=LBC0B5CvPkj7pUKnUXFzieOntkDMuUzjW2QHAP6EBsNSNo/m05zKpQ7K67ZpjuD/m0 oe5w77sI/jZCoOTlFM/vEH2uXtcD+4Gw9WmzZ4NOw4rWnyvtIjzaZCH4W1842dlKLURz ulJBNu0RnXzY7AqvWMpowRPnA/SNL2ZiN8ZXaPBqb6fKXUL5O7Eqn4PkKqxDgMwbheT8 tfpzeGitLMfJxPFS2LLK0HT2SguzMUWpGGpdP57JUfYbOV8lLJA6vO68aZKTj6PC7trE JClugw7T7jLHBnsxZh0eKrw6CgJNKgxHhuY8yHGhoMQo47/qXw+4JD1mdGQxwlu9Ph/y 8JMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uHbUHM1vMvfBVz6+p6Y5TbQn4ane+bSQxv6gFDb+im0=; b=cZmMF6wG0Iak/8uENEZbbK7aTi+7WaWrbdia3JbbSbdIQYUf4usSNPYJdd1gSV0txa +DRVLAny69LfxdcUX5sc04nHiiZgUHJ+FnJpcERM7TPYpJq9ta9YNO1tSPhcLOvgsYuB ZVz/YJ45XC3HRjoWgnRlh6lKXLSnF5Lh0SOmu3C1OgrYPXWlqWCNrQXz0dBxc78e2VP6 jU0v60ZvaYzxdP4MqxwJS+LaZXxoJMrIQ7bSRIr82v4jk+ExkEV+NuIQ39RJeZS5eyyw zKhWfjMQKdSZWprlncExmhPRF0KoZ84XN0DWumwXWpDKGETq8oJSQ8LuhaAQjYiB/CJw dZ0A==
X-Gm-Message-State: AGRZ1gJ703PpjtpM7OPQicoj2GTz33K5EcIggG7BTo08gRPLMB5pCUaT hKevjWERDVEa/ZfoPCGuhxVqdb/BZH8tU8cOiT4=
X-Google-Smtp-Source: AJdET5eI5o6CsTVfSCgnXI1KZ/Dm94z8XxQeNYYAR1Mei1Aer01vqwGQtrnYiXCN4Oc9fGFFnx/05L4Yx9MlOFdIXyo=
X-Received: by 2002:a24:3088:: with SMTP id q130-v6mr589627itq.148.1540944329022; Tue, 30 Oct 2018 17:05:29 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Oct 2018 17:05:28 -0700
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CACpbDccP7zw6yUyMs0iyAzByBDjprsoBbwey3c0t7wXEddvrvA@mail.gmail.com>
References: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org> <20181029160802.GD7258@ubuntu-dmitri> <8268B90E-F109-424C-91A8-DB7BFE208F53@huitema.net> <CABkgnnU7W-_o_EGZWpJvTGRSm0KiL-hS7q_oQ6kT3LBoNKHGhw@mail.gmail.com> <5E1AB9AC-D24F-4E0D-9925-57816C5314A4@trammell.ch> <a088c411-1acc-8b0f-fc1b-8c79ce6f1cd7@huitema.net> <DB6PR10MB1766E6B29792BB4401FF38F0ACCC0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <HE1PR0701MB23939472CAA7CC7C1CD42BB1E2CC0@HE1PR0701MB2393.eurprd07.prod.outlook.com> <65907d96-a525-dcd0-39cd-678c52d26ab6@huitema.net> <CABkgnnVCveXr2GUsx2ZyKNf08VaCh+Ts-T=5wD3_-8Pqk2xRTQ@mail.gmail.com> <CACpbDccP7zw6yUyMs0iyAzByBDjprsoBbwey3c0t7wXEddvrvA@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 30 Oct 2018 17:05:27 -0700
Message-ID: <CAN1APdcZAK6Kw0b+hB6Z1fZ4xWATmqYXzg--_qFLdKUq7E5zPg@mail.gmail.com>
Subject: Re: Structuring the BKK spin bit discussion
To: Jana Iyengar <jri.ietf@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
Cc: Marcus Ihlar <marcus.ihlar@ericsson.com>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059a34a05797b0f3e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2uxft7S1NBnJWXZ5DOWyFMYnOYQ>
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 00:05:31 -0000
This might overcomplicate things but a client could perhaps downsample the spin bit by only changing phase every second time the server does, or other harmonics. If this is done randomly it could hide some latency. On 31 October 2018 at 00.52.29, Jana Iyengar (jri.ietf@gmail.com) wrote: On Tue, Oct 30, 2018 at 3:55 PM Martin Thomson <martin.thomson@gmail.com> wrote: > On Wed, Oct 31, 2018 at 5:42 AM Christian Huitema <huitema@huitema.net> > wrote: > > Mikkel is correct, we may not want a purely random per connection > behavior, but rather something "random per destination". This would better > mimic the opt-out behavior of a privacy-sensitive endpoint, which would > always opt out when contacting a specific destination. If I had to > implement it, I would not use a PRNG, but rather something compute the hash > of a local secret and either the peer address or the peer name. That way, > the client would opt out for all 16 Netflix connections, or for none of > them. > > Or are we looking for random per-path? > > That notion would seem to tilt the balance more in favour of the > "discretionary" option over the "negotiated" one on the basis that > spinning/not doesn't become a linkability consideration. > Yes, per path makes sense to me. I think the linkability concern here is weak, but it doesn't hurt any to do this per path.
- 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