Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))

"Brian Trammell (IETF)" <ietf@trammell.ch> Fri, 06 April 2018 09:39 UTC

Return-Path: <ietf@trammell.ch>
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 04D90120725 for <quic@ietfa.amsl.com>; Fri, 6 Apr 2018 02:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 D-dmnI737qXs for <quic@ietfa.amsl.com>; Fri, 6 Apr 2018 02:38:59 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38CA1200F1 for <quic@ietf.org>; Fri, 6 Apr 2018 02:38:58 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 40AE334054E; Fri, 6 Apr 2018 11:38:57 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.27613); Fri, 6 Apr 2018 11:38:56 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Apr 2018 11:38:56 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50841368; Fri, 06 Apr 2018 11:38:56 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <FFEC6258-4B0F-473F-BAF6-28C655EE6DAF@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_995ECBAE-A056-450C-828B-4C8A82642BC4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))
Date: Fri, 06 Apr 2018 11:38:55 +0200
In-Reply-To: <CANatvzzoAK0SRrLOfz6HecbsE3oevWWkzJcfhceuqECF0VL=MA@mail.gmail.com>
Cc: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Christian Huitema <huitema@huitema.net>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>, Frederick Kautz <fkautz@alumni.cmu.edu>
To: Kazuho Oku <kazuhooku@gmail.com>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <759C5BE4-DE4C-4A82-929C-B03234B88A37@huitema.net> <CAJGwveB=qs+J2iBQRs3d5jdGuP9yBWoAgv0t3mwD=Wrf6Q5g8g@mail.gmail.com> <F395D018-FFCA-405F-BBD5-1313C6F6DAF9@huitema.net> <CABkgnnWAgGJaKs8teKTURiNDRA61fRhN6pxYQuD1MbkPDqasKQ@mail.gmail.com> <2F06334E-C3DF-4034-A6A4-AF383505D930@trammell.ch> <CABkgnnX1=h4qx+3YjXj=ZME5ihZbJ2rqE8zeT4j84dJj0ZfZGg@mail.gmail.com> <29F2FB1B-3A82-4E60-A4A5-70AC36CEEC54@trammell.ch> <CANatvzzoAK0SRrLOfz6HecbsE3oevWWkzJcfhceuqECF0VL=MA@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i7s5IDGyG_797MgQcY-7P0Yb6E8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 06 Apr 2018 09:39:01 -0000

Hi, Kazuho,

> On 6 Apr 2018, at 11:14, Kazuho Oku <kazuhooku@gmail.com> wrote:
> 
>> It's multiplicative by a factor of three, which means that the max flow concurrency will reduce by a factor of three. I agree it's probably tolerable, but we do need to understand what we're actually getting for that cost. I remain dubious about the actual privacy benefits WRT third party passive surveillance here -- they don't accrue at all unless there's a CGNAT in the way that doesn't bind an address/port range to a customer at a given point in time. In the common case, ISTM that just burn more in-network state than they additionally require at the surveillance point to track the change. Defenses with such scaling curves are not a good idea.
>> 
> I think I share the same concern.
> 
> One way to minimize the impact could be to suggest certain amount of connections (e.g., 5%) to gratuitously migrate to a new tuple just once, right after the connection is being established.
> 
> If we specify that way, we can assume that the impact on the NAT will be having 5% more flows. Middlebox vendor that mistakenly tries to use the cleartext bits in the packet header as the signal of connection initiation will also see failures at the same rate.

If the goal is only ossification agility, ensuring that migration can actually work, then this seems like a much better approach.

However, I would submit that if we think we are in a position where:

- there is a strong incentive for firewalls/NATs to want to see start- (and end-) of flow (which seems to me to be the threat model we're trying to mitigate with this); and

- we do not want arbitrary information in the QUIC wire image to be used to detect these conditions, since that might cause bits of the wire image we don't want to end up in the accidental invariants;

then we really should consider adding explicit advisory flow state signals, both for establishment and teardown. The theory here is that if you give in-network functions a "grip" in the wire image of the protocol they can use for state management, they won't try to grab on to the slippery bits. Together with probabilistic migration, these signals would divorce "on-path state" from "transport session state", reducing the privacy impact with respect to SYN/FIN in TCP.

(The alternative is to make the wire image so inscrutable that on-path state tracking becomes completely futile and goes away. I'm not sure we're that good at inscrutable wire images.)

Cheers,

Brian