Re: Increasing QUIC connection ID size

Jana Iyengar <jri@google.com> Fri, 12 January 2018 01:00 UTC

Return-Path: <jri@google.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 5D67E126C26 for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 17:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 obFN30UuzjFY for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 17:00:26 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 EAC67126579 for <quic@ietf.org>; Thu, 11 Jan 2018 17:00:25 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id v139so1860072ywg.4 for <quic@ietf.org>; Thu, 11 Jan 2018 17:00:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gGz1SyHa8fAR3rH+9EMa6CyYRjfxIsfe5tXqOvnvA3Y=; b=lptzNUZDk50ThBjDtNdG2Y1kp1Egrqz4vivApx4CS1zr5CBSNhV8aXhz0yFsU0Z2IQ +ArqdnuTgjLXIasZ0Elxaau20nk04UzscZ0SWihNojzDicK9zTx2zfVPdMN/pG/ROf4M eEcGCIBHRfK1CWDd1rFupkx1cZzNXar3zlTSQOfgrLSAn8zSs+WsieONp+vOpGZgdRhp nhGBdvmQLBBmLAalvYffHfEmK2RNZrbA+YQdq6r0S0lhqiT2S/A7LYztzX07MdCuJyNI DrW4j1PCP/2IetUmnEclOSVM1QJZIXbKmlxDal8ki0QypCYFTSFynfEV8EWyxYZWOOoj Gc3g==
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=gGz1SyHa8fAR3rH+9EMa6CyYRjfxIsfe5tXqOvnvA3Y=; b=d2jU45LDQ7lLkcYvw6tlyv/HLeZ7oB8lbAMR3A5eXeuc7lsIlQOSo+74uqjlFaKUtG tXJsRtKTM99xAVpIkdIcDm6d5EqHUNveelHZu5ZHmi3Un8fl4F+aZf97xKc7bABSWWj8 xXe/4OCC/pnUDkc1Y8l1YzPY1US5PBiEBOtOhTl/hRoLb7oJlZPz72mPZuFHPerDo+hk 0VmsOWEITRL2gixVl8ivqBw1KEvh/4v6C1FC+onxe/jcYbBfJzQVpi9/9Ulaf8pngNJs kZXe7WszD2ONbpFHC4Gqsz6Mf8iAehfK/abUO9nPu9XdPRJuXK2e8yIVbkVuiupP1bdI IhaA==
X-Gm-Message-State: AKwxytem887WcD3gMm4PitepC8t+bVgGJpVNxmB2G3YhHRXi3vVSAGRc oWIgleWg1EfbLXbcVuuB8AtX5kjHfUwaZdJFhpwGag==
X-Google-Smtp-Source: ACJfBotll6jAAN5aajY1hlnFQBma6YK7FCYUKtZd5ywl8hISPTEiZJtniG+SsqD6Ayb1kGdiY1dzLAbYPZgn1DYchE4=
X-Received: by 10.129.146.130 with SMTP id j124mr3076841ywg.256.1515718824368; Thu, 11 Jan 2018 17:00:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.42.147 with HTTP; Thu, 11 Jan 2018 17:00:23 -0800 (PST)
In-Reply-To: <E2392130-4F00-42D9-81E3-F66CA4D6FBF2@fb.com>
References: <CAAZdMad=YnTyXG-q0ACpT=tyCSX1GgRLvb=8HT3Au=e9_XT5Ag@mail.gmail.com> <E2392130-4F00-42D9-81E3-F66CA4D6FBF2@fb.com>
From: Jana Iyengar <jri@google.com>
Date: Thu, 11 Jan 2018 17:00:23 -0800
Message-ID: <CAGD1bZb7tgoBNemgCFeUNYUd805V3F1KJUkUEB0daGnZ7gQ6vw@mail.gmail.com>
Subject: Re: Increasing QUIC connection ID size
To: Roberto Peon <fenix@fb.com>
Cc: Victor Vasiliev <vasilvv@google.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114c4c101cd2a5056289cad0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SupklDXLEJBdPoAnOeBf7YYPIgs>
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 01:00:28 -0000

Having thought about this a bit, I like the idea of encrypting CIDs. The
strongest argument for me is that we really want unlinkable CIDs, and
crypto is a quite simple way of generating such CIDs.  Encrypted CIDs also
allows for a simple solution to the problem of generating server-chosen
CIDs that route back to the same server, since any structure in the
plaintext is not visible in the CID that is sent on the wire.

Crypto in 128 bits is readily available, making it less expensive for
hardware (load balancers) to do it per packet, so using 128 bits seems like
a good idea.

On Thu, Jan 11, 2018 at 4:45 PM, Roberto Peon <fenix@fb.com>; wrote:

> Having the server specify the connID-size as part of the connection
> setup+version negotiation would certainly be grease-y.
>
> A larger connID helps to solve a lot of L4<->L7 routing issues, agreed,
> pre-supposing that the server always picks the new/alternate conn-ID for
> the client.
>
> -=R
>
>
>
> *From: *QUIC <quic-bounces@ietf.org>; on behalf of Victor Vasiliev <
> vasilvv@google.com>;
> *Date: *Thursday, January 11, 2018 at 3:16 PM
> *To: *IETF QUIC WG <quic@ietf.org>;
> *Subject: *Increasing QUIC connection ID size
>
>
>
> Hi everyone,
>
>
>
> In the current version of QUIC, the connection ID size is fixed to be a
> 64-bit opaque blob, and that is set as an invariant in the protocol.
>
>
>
> I’ve looked into possibility of using a connection ID to encode the
> specific server details into it (to provide stability of the connection in
> case of load balancing changes, especially BGP flaps for anycast IPs), and
> have chatted about this with other people I knew were interested in this.
> It seems like 64 bits might be too small for this purpose, and we might
> want to leave an opportunity to extend the connection ID size.
>
>
>
> The basic idea is that you want to be able to:
>
>    1. Store some routing metadata in the connection ID.
>    2. Have some entropy that allows distinguish users with identical
>    routing metadata.
>    3. Have a checksum to ensure the validity of routing information
>    4. Encrypt the information above to prevent disclosing the route
>    information and allow generating uncorrelatable connection IDs.
>
> There are two underlying issues here.  The first problem is that all of
> this does not fit well into 64 bits, and you have to seriously compromise
> on the strength of the checksum (which is bad especially if you want it to
> be a MAC rather than a checksum).  The second problem is that encrypting
> 64-bit values fast is actually fairly hard since the block ciphers easily
> available in hardware have 128-bit block size, and the performance
> requirements on load balancers are tighter than on servers.
>
>
>
> In other words, having a 128-bit connection ID provides for an easy secure
> way to generate unlinkable connection IDs on migration.
>
>
>
> So, the problem we’re trying to solve is that the connection ID is too
> small.  There are two questions I believe the working group should answer
> at this point:
>
>    1. Do we want to address this problem at this point in standardization
>    process?
>    2. If we don’t address this problem right now, how do we structure the
>    standard in a way that we can extend the connection ID in the future?
>
> There are multiple ways to solve the problem of making connection ID
> larger.  One is to just add extra bit to the “omit connection ID” field to
> allow 128-bit connection IDs.  Another approach is to allow connection ID
> size to be explicitly specified by the server, and then assume that the
> load balancer knows that size and no one else on the path needs to read it.
>
>
>
> There’s also a question of how much of connection IDs do middleboxes
> (excluding load balancers and other boxes owned by the same entity as
> either client or server) need to know.  We could go for both “middleboxes
> should be always able to read the entire ID” and “middleboxes should not
> read connection IDs at all options”, but I think there’s also a room for
> more flexible formulations like “middleboxes always get first 64 bits and
> they have useful entropy to distinguish connections”.
>
>
>
>   -- Victor.
>