Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

David Schinazi <> Thu, 05 March 2020 06:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A14A93A0DB6 for <>; Wed, 4 Mar 2020 22:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lk6FpTk_GtRd for <>; Wed, 4 Mar 2020 22:14:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE2EC3A0DB5 for <>; Wed, 4 Mar 2020 22:14:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0E463E0F2A for <>; Wed, 4 Mar 2020 22:14:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1583388897; bh=OfRb31IWHZNKzc68V+SrHp2YpgUNFx2CUl4g4e0UVeE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QOvH2pHax3j0QubmKAu3hgl/1yHbxEPlBXkTKM+955lgZqng2AXGFMPZnL7h+4Dw0 AkVu8R4YhVphAwzRcOR4CH7n4zsYApMEIrp6ouZynhZCXfvRKm85bY42/EtRAAp2Ay 1NSGnEJ9wJ1h2St75siPBC8RUD7WkTIZwcUc7fg0=
Date: Wed, 04 Mar 2020 22:14:56 -0800
From: David Schinazi <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3439/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e6098e0f26bb_39953fa67aecd96024207d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2020 06:15:00 -0000

In the design of Google QUIC, the client picks a random connection ID, and the server uses that. (BTW that's why it's called a connection ID, it's a unique identifier that has a one-to-one mapping with one connection...) What that means in practice is that the client uses randomness to generate the connection ID, the load balancer maps that to a given server, and using the same connection ID for the duration of the connection makes sure that all packets reach the same server. So far we've kept this design for our implementation of IETF drafts. We understand that some server deployments may want to have the server pick its connection ID, but so far we don't see the value in that outweighing the added complexity. Today we do not yet have a good mechanism for a server to ask the load balancer for more connection IDs that will map to it. We have some hacks that we can perform, but I don't think those hacks will work for the first connection that a server receives. So if this becomes required, we'll have to build the load balancer protocol before we can deploy the new draft.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: