Re: Increasing QUIC connection ID size

Willy Tarreau <w@1wt.eu> Fri, 12 January 2018 05:56 UTC

Return-Path: <w@1wt.eu>
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 4BD071201FA for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 21:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 5mCEa-QiVSXC for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 21:56:06 -0800 (PST)
Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 210C4120727 for <quic@ietf.org>; Thu, 11 Jan 2018 21:56:05 -0800 (PST)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w0C5tsRE015883; Fri, 12 Jan 2018 06:55:54 +0100
Date: Fri, 12 Jan 2018 06:55:54 +0100
From: Willy Tarreau <w@1wt.eu>
To: Roberto Peon <fenix@fb.com>
Cc: "Lubashev, Igor" <ilubashe@akamai.com>, Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= <mikkelfj@gmail.com>, Victor Vasiliev <vasilvv@google.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Increasing QUIC connection ID size
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Pw8MqAPuckcvapmqm0UEr05fK_g>
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 05:56:08 -0000

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