RE: Increasing QUIC connection ID size

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 11 January 2018 23:57 UTC

Return-Path: <ilubashe@akamai.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 954F812EC6A for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 15:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 xTyFfWtmPUL8 for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 15:56:57 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CD512EC5C for <quic@ietf.org>; Thu, 11 Jan 2018 15:56:57 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0BNqvk7014575; Thu, 11 Jan 2018 23:56:54 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=bjsHKZfqxH0pmMpyBhOCec7ZDrcQuE0Xg6qd6pe8+eI=; b=B3oSztzZ4/LAtLI4pbf1PoBokZWeOkiwuQPU+o2jQWEbLFx5KBH5zBTWmWAlbBUZNu3H 0W7RSPLSionTTFAX6LSpzrUBkDfDzOMnmUEJL7Hk8PXpsISx+Y1tB4qEu9XSprWAJjN+ nn3XSCz969RtZ7NhFHKbyrGHnxXE5+mlr5XTa9ZtAQG7oNn2+wj6T/IvpYgDQqTSe/T7 RiyLSZAfbenTTW80V4L3F979oVQDzeboRau2379Q8fB1KNiwIC8mnQ6mDDE5QllelGE5 ptl2sJGkjBH6PKjMKCG7WTfyS34KRLQSxlnZsbg4ihn4FpETS6Mnnn+1EhIRIJP+4suU Fg==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2fda9rrmt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 23:56:54 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0BNtdxY012341; Thu, 11 Jan 2018 18:56:53 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fatpe8k3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 18:56:53 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 Jan 2018 18:56:52 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 Jan 2018 18:56:52 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Thu, 11 Jan 2018 18:56:52 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Victor Vasiliev <vasilvv@google.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Increasing QUIC connection ID size
Thread-Topic: Increasing QUIC connection ID size
Thread-Index: AQHTizIxs65b7ysujkqedmh6APARjaNvVjxA
Date: Thu, 11 Jan 2018 23:56:52 +0000
Message-ID: <d2a6136f93654eb1a5c7970cfb41f7ad@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CAAZdMad=YnTyXG-q0ACpT=tyCSX1GgRLvb=8HT3Au=e9_XT5Ag@mail.gmail.com>
In-Reply-To: <CAAZdMad=YnTyXG-q0ACpT=tyCSX1GgRLvb=8HT3Au=e9_XT5Ag@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.34.88]
Content-Type: multipart/alternative; boundary="_000_d2a6136f93654eb1a5c7970cfb41f7adusma1exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=809 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110321
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=760 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110320
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/PgX4Y8QiInlUDVmZTHlwG3zoyeo>
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: Thu, 11 Jan 2018 23:57:01 -0000

I am interested in exploring this proposal, since it allows for more flexible schemes of encoding routing metadata and a checksum.  I would also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implementation.


  *   Igor
From: Victor Vasiliev [mailto:vasilvv@google.com]
Sent: Thursday, January 11, 2018 6: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.