Re: Increasing QUIC connection ID size
Roberto Peon <fenix@fb.com> Fri, 12 January 2018 01:13 UTC
Return-Path: <prvs=45509646aa=fenix@fb.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 D2FF4128959 for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 17:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=j8E/gVWR; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iOoJqLGZ
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 2V5frqhLKMoo for <quic@ietfa.amsl.com>; Thu, 11 Jan 2018 17:13:07 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 698A4120726 for <quic@ietf.org>; Thu, 11 Jan 2018 17:13:07 -0800 (PST)
Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w0C1BtIq032704; Thu, 11 Jan 2018 17:13:02 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=wrn6UFBrvRbIB46V0jdjhv+q/rWoujzKJ5obQufqy0Y=; b=j8E/gVWReJ+VWceBQFfuebR8/eUNcOVBKnhE68AWra/7VUKy6WCLddTPlyKPeE+fOfcM 2OyEytR4FPsjbt2QswDfRDssQt5Pm0yl7yMoGBCSHAGqaTuFf/ANx2Y9xv90dWCmwaMG R1jWaVQVp4SnICUwqJ1xkips9khVy3lDY3U=
Received: from maileast.thefacebook.com ([199.201.65.23]) by m0001303.ppops.net with ESMTP id 2fed8g9e6h-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 17:13:02 -0800
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.28) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 11 Jan 2018 20:13:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wrn6UFBrvRbIB46V0jdjhv+q/rWoujzKJ5obQufqy0Y=; b=iOoJqLGZXFH+ebTgLGND/v/2nT+oLP9BMjDkM/RN1mV7uwpYF9eh3SEytHPmDt+IuppH3IEfmf8tF8n4KfWfPyFKQcGqHXUCpSm0oqbvhNq8f0YH2YEIz3DlP803YtDZCi+2wl81gY7FvszQalL24Y4B3TejNiJ6T4vxtGVXhXw=
Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2189.namprd15.prod.outlook.com (52.132.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 01:12:59 +0000
Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 01:12:59 +0000
From: Roberto Peon <fenix@fb.com>
To: Jana Iyengar <jri@google.com>
CC: "Lubashev, Igor" <ilubashe@akamai.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, 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: AQHTizJFGh6gA6yAxkSP/nHmnMJHJaNvWU8AgAAH/ICAAAhFgP//fKwAgACHSQD//3rxAA==
Date: Fri, 12 Jan 2018 01:12:59 +0000
Message-ID: <346D256C-5D64-4EB4-8AA1-C16ACEB7B704@fb.com>
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> <CAGD1bZbdNJwV6fbjC9jqQjec7q=OFndb=i1cwCzYSXfdrTTCzA@mail.gmail.com>
In-Reply-To: <CAGD1bZbdNJwV6fbjC9jqQjec7q=OFndb=i1cwCzYSXfdrTTCzA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c090:200::5:47a8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:CcATfzGwMD8Bl2ri8KNo3bruceLij4DaKMC76xp7IuoEv2ZYu6DxZ+dgk9l9MiwTxMee3/YjuIe+AhAIVC3ypBKeoErE/wlhOgEg+wG8cXC++5rRJFapQQbNsSJ68eg4slrqI/MRDEAEqj5mZtz1lOiidw2gBv1B6F1FRWVOV2BxsSULKWyanGkFht70b20ox7wz3ZPAhxxlw2RwJbtANWnLH9L9W4UxrvXPfwIjLq9IjuUtKPSGxziANk/ijIMt; 20:UQ/5d+YckszpuqVZaaMXb2HHMp9P+t7MLVfyb0saM5K/Lm4BoaDxTP4m54whMqwpER8V13X8iA3bBHBxVZ8/mRuJ1kXQ6NQJUCzlPNLAVVIbNedfhRjdge2Z5Zx6YaiP2GgJ2lddosIvDQCstPtSEG3SWrsxbEHz3Aa1/Fffnhk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: e692f07c-0fc8-42f4-9263-08d559599f20
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020074)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189;
x-ms-traffictypediagnostic: SN6PR1501MB2189:
x-microsoft-antispam-prvs: <SN6PR1501MB2189B44E43222C244C8BD429CD170@SN6PR1501MB2189.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR1501MB2189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2189;
x-forefront-prvs: 0550778858
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(24454002)(199004)(189003)(53754006)(99286004)(105586002)(54906003)(5250100002)(316002)(6116002)(2900100001)(106356001)(53546011)(478600001)(36756003)(59450400001)(86362001)(25786009)(76176011)(8936002)(102836004)(53936002)(93886005)(6506007)(39060400002)(561944003)(33656002)(14454004)(68736007)(5660300001)(2950100002)(6916009)(97736004)(3660700001)(83716003)(54896002)(236005)(6306002)(81166006)(81156014)(6512007)(3280700002)(7736002)(4326008)(229853002)(2906002)(6486002)(6436002)(8676002)(82746002)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: DZQ+9ZyJ++oitZYTWozLcUSl21j+se2RBL3mECo+WMHN62ILtdz/7QzgieP3Qal+nIo0XufeEpjd2zoOh8M02A==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_346D256C5D644EB48AA1C16ACEB7B704fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e692f07c-0fc8-42f4-9263-08d559599f20
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 01:12:59.8997 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2189
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DJS47cdVQubwyVu6f8cPxJjBpVc>
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:13:10 -0000
Yup! If you’re paranoid, you can encrypt twice: One less-secure key which allows decryption of the key ID bits (and the rest of the bits, which are along for the ride), and then another key (indicated by the first) which allows decryption and subsequent interpretation of encoding of the the L7 address (plus salt somewhere in there) into the remaining bits. Ultimately, knowing a scheme is possible is sufficient here so long as we delegate connID assignment to the server. -=R From: Jana Iyengar <jri@google.com> Date: Thursday, January 11, 2018 at 5:09 PM To: Roberto Peon <fenix@fb.com> Cc: "Lubashev, Igor" <ilubashe@akamai.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Victor Vasiliev <vasilvv@google.com>, IETF QUIC WG <quic@ietf.org> Subject: Re: Increasing QUIC connection ID size Just thinking aloud about key rotation -- you could always use the high-order bit as an expicit key selection bit... the server and load balancer can then use this bit during rotation to change keys without breakages. On Thu, Jan 11, 2018 at 5:05 PM, Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>> 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. -=R From: QUIC <quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>> on behalf of "Lubashev, Igor" <ilubashe@akamai.com<mailto:ilubashe@akamai.com>> Date: Thursday, January 11, 2018 at 4:55 PM To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>>, Victor Vasiliev <vasilvv@google.com<mailto:vasilvv@google.com>>, IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>> Subject: RE: Increasing QUIC connection ID size I think the idea is that the key used to encrypt connection ID is known to both the server and the router. That key would need to be rotated periodically, and the router would need to understand which key was used for this particular connection, but that can be solved. From: Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com<mailto:mikkelfj@gmail.com>] Sent: Thursday, January 11, 2018 7:25 PM To: Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>; Victor Vasiliev <vasilvv@google.com<mailto:vasilvv@google.com>>; IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>> Subject: RE: Increasing QUIC connection ID size Actually, on encryption of connection ID, this is not so simple. We must assume there is only a single key for many connections because the router is not part of a key exchange. This unique value or counter used for encrypting a single block cannot be the same for two different connections ID’s, but it can be public. This means that it must be stored in the packet header. And, as it turns out, random connection ID chosen by a trusted source, can be used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the actual routing information. So now you start to really need some extra payload. Alternatively the routing information is entirely random such as content hashed routing. Then you only need to authenticate the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can probably get away with 64-bits for all routing information possibly including the auth tag. Say 48 bits of routing data and 16 bits of auth tag. Kind Regards, Mikkel Fahnøe Jørgensen On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com<mailto:ilubashe@akamai.com>) wrote: 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<mailto:vasilvv@google.com>] Sent: Thursday, January 11, 2018 6:16 PM To: IETF QUIC WG <quic@ietf.org<mailto: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.
- Increasing QUIC connection ID size Victor Vasiliev
- Re: Increasing QUIC connection ID size Mikkel Fahnøe Jørgensen
- Re: Increasing QUIC connection ID size Mikkel Fahnøe Jørgensen
- RE: Increasing QUIC connection ID size Lubashev, Igor
- RE: Increasing QUIC connection ID size Mikkel Fahnøe Jørgensen
- Re: Increasing QUIC connection ID size Roberto Peon
- RE: Increasing QUIC connection ID size Lubashev, Igor
- Re: Increasing QUIC connection ID size Jana Iyengar
- Re: Increasing QUIC connection ID size Roberto Peon
- Re: Increasing QUIC connection ID size Mikkel Fahnøe Jørgensen
- Re: Increasing QUIC connection ID size Jana Iyengar
- Re: Increasing QUIC connection ID size Roberto Peon
- Re: Increasing QUIC connection ID size Christian Huitema
- Re: Increasing QUIC connection ID size Willy Tarreau
- Re: Increasing QUIC connection ID size Martin Thomson
- Re: Increasing QUIC connection ID size Göran Eriksson AP
- Re: Increasing QUIC connection ID size Willy Tarreau
- Re: Increasing QUIC connection ID size Ian Swett
- RE: Increasing QUIC connection ID size Lubashev, Igor
- Re: Increasing QUIC connection ID size Ian Swett
- RE: Increasing QUIC connection ID size Lubashev, Igor
- RE: Increasing QUIC connection ID size Mikkel Fahnøe Jørgensen
- RE: Increasing QUIC connection ID size Praveen Balasubramanian
- Re: Increasing QUIC connection ID size Roberto Peon
- Re: Increasing QUIC connection ID size Victor Vasiliev
- Re: Increasing QUIC connection ID size Jana Iyengar
- Re: Increasing QUIC connection ID size Christian Huitema
- Re: Increasing QUIC connection ID size Marten Seemann
- Re: Increasing QUIC connection ID size Martin Thomson
- Re: Increasing QUIC connection ID size Mikkel Fahnøe Jørgensen
- Re: Increasing QUIC connection ID size Victor Vasiliev