Re: Increasing QUIC connection ID size

Martin Thomson <martin.thomson@gmail.com> Fri, 12 January 2018 06:18 UTC

Return-Path: <martin.thomson@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 7EBC2126CE8 for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 22:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 zfiXdhDlKAtD for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 22:18:53 -0800 (PST)
Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 980911205F1 for <quic@ietf.org>; Thu, 11 Jan 2018 22:18:53 -0800 (PST)
Received: by mail-ot0-x236.google.com with SMTP id 44so3354992otk.8 for <quic@ietf.org>; Thu, 11 Jan 2018 22:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0iY+CE4ToIHflEdKvsR/xg1duJBnKJjHFxC115/WoYw=; b=Aza9aeGTQmwKS4TTmwF5GP8tjyqXlBw6lClxHwcj1cd4U0IcYc6GNL2L50rDoYEP5U vA/E6zr8XDnJv01vxT/R56eraUgN296fTpPYnXYprZFU6xBvRxBjFHk02qX1oGukpc2t 894P8dThE7N5Hkcw06BWiycDlPhX9/hB2Kt4jXcW23R9zkLSwmjJZcUDpvUUCjA9BCXj MR/glzuTOlLkv8h5GqjhcF1NKsverRYdC5FDoX2QEZitrVttoRxi9OgZ6G5d32HTBxJi ud7IlS+FAjNgAD2K/MM+KG3wZaE2sRHv6+jLZ+cZ50kVhK/YaClZ7uWav3vBwCsNuJDC DhSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0iY+CE4ToIHflEdKvsR/xg1duJBnKJjHFxC115/WoYw=; b=Jf0gqnZrk/W5DSCTrAhXx6Sep46XMo3AWWdUXdHt7Ydqlz7wiKUeZ3MYvTcr1d7IJI bg12Nz7V0abc3auwgdfjZPSeHkV7cWY2ITQYU1hiUpdVE2J0CEKOObi8FklopCw6TZ3I hzn9qsT9u1ixw+9CgPGiEPPYohlBIF+MDt7q31hJi+K/dv7YjKMUjuyXCxiw5gcy9CJy 9hwg8xJ9q8bPvdfY6kMdYLbfIp2BbpGqYdp2hfvt7SYNnNBnvPSazhi6T3aNc/y8srb3 X9Q8wM3XQw1CMxs7l+aOlaT9C9BG8qY1Nwn9oaD0xsK5qUjoOIPlhVGC1Wht/uZ3sx5f 727Q==
X-Gm-Message-State: AKwxytfX9ly9O9y3EZbLRsJyWHzehPP5X0fs3Lbxo4uys47J2fUN2OI+ qYSXBHqC+3xeWcqi8c0U/Xjm+QCJUrzYK1mjgnU=
X-Google-Smtp-Source: ACJfBotND6bEqbglrnk2x3QWbL+bLpBlXrtfV0DwGpO3hIbDbfBmgtOFVPh20y9+eUYBJHs9G+/oe86uFxZBlI5RswI=
X-Received: by 10.157.40.134 with SMTP id s6mr15104780ota.133.1515737932936; Thu, 11 Jan 2018 22:18:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.39.16 with HTTP; Thu, 11 Jan 2018 22:18:52 -0800 (PST)
In-Reply-To: <20180112055554.GA15873@1wt.eu>
References: <CAAZdMad=YnTyXG-q0ACpT=tyCSX1GgRLvb=8HT3Au=e9_XT5Ag@mail.gmail.com> <d2a6136f93654eb1a5c7970cfb41f7ad@usma1ex-dag1mb5.msg.corp.akamai.com> <CAN1APdf7MqhdQ-+VMOwsNgz_F+OZK-8CzndwWTQq4FPM52ro9Q@mail.gmail.com> <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> <20180112055554.GA15873@1wt.eu>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 12 Jan 2018 17:18:52 +1100
Message-ID: <CABkgnnU+QMGD4XW3mgpE1fYRVrceEXV6tu9Psy5m=LV_zPqogg@mail.gmail.com>
Subject: Re: Increasing QUIC connection ID size
To: Willy Tarreau <w@1wt.eu>
Cc: Roberto Peon <fenix@fb.com>, Victor Vasiliev <vasilvv@google.com>, =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rYUtrVk2F2R-JS4_DAjlsFXAenE>
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, 12 Jan 2018 06:18:55 -0000

https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00 is
currently DTLS specific.  Is this something that you feel should be
more general?

I think that people reading this thread should be aware of the
alternative design options here, the above draft identifies one.  Note
that there are several key ways in which this might be unsuitable for
QUIC in its current form; it makes a different set of trade-offs.

On Fri, Jan 12, 2018 at 4:55 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Fri, Jan 12, 2018 at 01:05:02AM +0000, Roberto Peon wrote:
>> Correct/agreed. The L4 'router' must be able to decrypt/interpret the data in
>> order to act upon it. This requires sharing of some key material.
>
> At least we need to keep in mind that it's critical to ensure consistency
> between all front nodes (think DNS+anycast BGP+ECMP LB before reaching the
> L7 LB). It's critical that all equipments in the path are able to coherently
> find the correct path to the origin node without having to actually learn
> anything from the packets. And synchronizing keys between multiple nodes
> is often a pain (though never impossible).
>
> At the HTTP workshop 2 years ago, I proposed to place some upfront routing
> information on TLS to save LBs from having to decrypting the stream to
> find what server the stream had to be sent to. The proposal was to have
> a small ID, typically 16 bits, for this. In my opinion this is another
> option we can consider here : with only 16 bits, you can easily store a
> server ID in a reasonable farm size (even dynamic), but you don't have
> enough information to track users. So it could remain accessible in
> clear, saving front nodes from having to decrypt anything or share keys.
>
> Willy
>