Re: Increasing QUIC connection ID size

Roberto Peon <fenix@fb.com> Fri, 12 January 2018 19:56 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 5255B127077 for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 11:56:56 -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=HLhtC3Le; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=cKFFKoeA
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 l2uX0H6fii8v for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 11:56:52 -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 4236D1242F5 for <quic@ietf.org>; Fri, 12 Jan 2018 11:56:52 -0800 (PST)
Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w0CJracu027883; Fri, 12 Jan 2018 11:56:42 -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=YmiUahvd0oh0gctEdqz/FvrCsM5Phwyg9B7dCrHmjx0=; b=HLhtC3LeR5ErJByZKKpSgFNr1YJgyNYu6sR0dA1BRoNzHFzuYjuqel6wH26ZvcAZ66cR WNGvGR+xyBQOmC5tVztX3hwvu6tizokPMPJUxOOEfVnsDAgbTltBuUPaVuvyd7LZjhZs 5lpOxQ9yYur30uew76Q33afpsmTZXaZyuX4=
Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2ff1y3ra62-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jan 2018 11:56:42 -0800
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 12 Jan 2018 11:56:40 -0800
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=YmiUahvd0oh0gctEdqz/FvrCsM5Phwyg9B7dCrHmjx0=; b=cKFFKoeAJZxtdyK5kAAE29Ntukp6opgar9EGfTk2FPi9Jh/iys9oza7ZBXLH7P5XXlYVgznHE+Bzc5UQhm9qNhPYFBrLsJFqokKr7ayxZPl82TefCbCJmh1ERY5AWhZPQGo03Z2zcunoRjDla7FILqf5nzKHMMkBbjeJwIzbPmo=
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 19:56:38 +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 19:56:39 +0000
From: Roberto Peon <fenix@fb.com>
To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= <mikkelfj@gmail.com>, "Lubashev, Igor" <ilubashe@akamai.com>, Ian Swett <ianswett@google.com>
CC: "quic@ietf.org" <quic@ietf.org>, "huitema@huitema.net" <huitema@huitema.net>
Subject: Re: Increasing QUIC connection ID size
Thread-Topic: Increasing QUIC connection ID size
Thread-Index: AQHTizJFGh6gA6yAxkSP/nHmnMJHJaNvWU8AgAAH/ICAACejgIAAu4AAgAAEU4CAAAXZAIAAFUUAgAASmoD//6vqgA==
Date: Fri, 12 Jan 2018 19:56:39 +0000
Message-ID: <C24046D4-C6E2-4217-9CF5-29970086E39C@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> <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <CAKcm_gNyrW1rVMrO3oF06+YH6cCEf2KQgTKRtQ-JrvWa1cpYKA@mail.gmail.com> <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> <CAKcm_gNg6Q5Y7ebKZUFDGAFa8WmiC03wOzizLGcxGOTQNhSTMw@mail.gmail.com> <808c94738a52489d913279b1e6db100f@usma1ex-dag1mb5.msg.corp.akamai.com> <CAN1APdfNit=2MJA2JryN=tsppaLjEVAYoyfFfSCUEtZ-0rwDqQ@mail.gmail.com>
In-Reply-To: <CAN1APdfNit=2MJA2JryN=tsppaLjEVAYoyfFfSCUEtZ-0rwDqQ@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::7:7098]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:m2BVT9x/F26CYMlIETsZNaatcGFMAhFoTnMZNJILbDw3R10MBB1MYt514PyehjNE6RnXVCy0PqwnR8RuutwHUn5O+39r7LX8YN+L9gYmy39NqHV3AcGDoJFCUhhOQnnVjPiKbMb0VME++cISfzOy0GYILHMkGOuZbq8+jvuOnAoLthyJVZc9IsJESZhL1lZPWA+lLmQ7Bs+98hRqaC7bULYWomBmyuENUkiNyqEnkQbpGp78S0fgT9xznWAZQj6b; 20:QbzZ/mZKWpVA9RB08zCjBbTwitnKTYHFlWmR28XFkmC+yXrxyKjxRMQoTXPJ1OcWY2lzmo9yg22MHieBf+RFHXcCfG6+/jbLA+AnRsc4Y/7o37AXhtLvlI0cXHhHvU0ltTDVpVKT5B7OjSf4/yT+TvcKFOIzXr7x75S+bxNfcBo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3e7141d1-4322-4648-b07f-08d559f69831
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020086)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189;
x-ms-traffictypediagnostic: SN6PR1501MB2189:
x-microsoft-antispam-prvs: <SN6PR1501MB21891B303F132BBFD8FD9799CD170@SN6PR1501MB2189.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(85827821059158)(211936372134217)(153496737603132)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(11241501184)(944501147)(10201501046)(3002001)(6041268)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(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)(366004)(39860400002)(346002)(396003)(39380400002)(376002)(189003)(53754006)(24454002)(199004)(13464003)(97736004)(229853002)(6306002)(81166006)(54896002)(236005)(3660700001)(83716003)(5660300001)(68736007)(2950100002)(2906002)(6486002)(8676002)(82746002)(6246003)(6436002)(7736002)(6512007)(81156014)(3280700002)(4326008)(53946003)(86362001)(110136005)(59450400001)(5250100002)(316002)(99286004)(54906003)(53546011)(36756003)(478600001)(6116002)(2900100001)(106356001)(39060400002)(33656002)(6506007)(561944003)(76176011)(102836004)(25786009)(8936002)(53936002)(14454004)(105586002)(93886005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: T8gtyb3EeK2f3VUsvbDWufbhdJuYA+5qxvjIEgXWHRefnMMnhywnBYXMp3xRZ65LEVkJpy3lNEQksq4+jBpgiw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C24046D4C6E242179CF529970086E39Cfbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e7141d1-4322-4648-b07f-08d559f69831
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 19:56:39.2075 (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-12_10:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vtTe4UeHNDnCCg8NwmLnX4Z-XVc>
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 19:56:56 -0000

So long as:

  *   The server determines CIDs
  *   All parties agree on CID length
then various L4<->L7 strategies can be safely attempted, whether the strategy is:

  1.  Encrypting L7 address+salt as CID
  2.  Encoding of L7 IP address + HMAC into CID
  3.  Encoding of L7 MAC
Or something else.

If we agree on that, then we need a strategy to determine CID length.

I’d suggest, for simplicity in V1, just making it 128 bits. We can get fancy later and have multiple sizes, negotiated per connection, or frame, as desired.
Yes, it will be more overhead in the protocol, but it will unlock folks ability to experiment with L7<->L4 balancing in reasonable ways.
-=R



From: QUIC <quic-bounces@ietf.org> on behalf of Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Date: Friday, January 12, 2018 at 8:58 AM
To: "Lubashev, Igor" <ilubashe@akamai.com>om>, Ian Swett <ianswett@google.com>
Cc: "quic@ietf.org" <quic@ietf.org>rg>, "huitema@huitema.net" <huitema@huitema.net>
Subject: RE: Increasing QUIC connection ID size

It could also be fixed 62 bit connection identifier and 2 msg of the first CID byte stores the additional length. The requirement is then that the first 62 bits must have “enough entropy” and the remaining bits are application or deployment specific. This will force routers to support 128-bits, but it will allow them to require it if so desired.

A router need not be concerned with the variable length aspect if the QUIC invariant ensures that a packet length is at least long enough to read 128 bits from CID start. It can just assume the length it expects and then validate as needed with auth tag or length, or just assume it is safe under the conditions.

In all cases the QUIC endpoint MUST include the CID in the additional data authentication to ensure routing data has not been tampered.

One could also take this a step further and shorten the first 64 bits, but that is probably a rats nest: 16, 32, 64, 128 bits.



Kind Regards,
Mikkel Fahnøe Jørgensen


On 12 January 2018 at 16.51.19, Lubashev, Igor (ilubashe@akamai.com<mailto:ilubashe@akamai.com>) wrote:
The point here is that if 128-bit is an option from V1, then all clients will support it, and the server can choose to always use 128-bit connection IDs.  The load balancer then can be sure that valid connection IDs (in packets featuring server connection ID) can only be 128-bit.  If V1 does not have 128-bit support, then the server must develop a less secure version of the connection ID to fit into 64 bits, and the load balancer must treat 64-bit connection IDs as acceptable.  Then, there is nothing to prevent an attacker from using 64-bit connection IDs, if that’s more convenient for them.

From: Ian Swett [mailto:ianswett@google.com<mailto:ianswett@google.com>]
Sent: Friday, January 12, 2018 9:35 AM
To: Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>>
Cc: quic@ietf.org<mailto:quic@ietf.org>; huitema@huitema.net<mailto:huitema@huitema.net>
Subject: Re: Increasing QUIC connection ID size

I think we'll want support for both no matter how we do this.

On Fri, Jan 12, 2018 at 9:13 AM, Lubashev, Igor <ilubashe@akamai.com<mailto:ilubashe@akamai.com>> wrote:
If the 128-bit option is not in V1, then it will be required for the 128-bit option to be signaled in the packet's invariant section (like a bit in the 1st byte). Otherwise, the very load balancers this is designed for will not know whether the connection ID has 64- or 128-bit format. (It would need to support both, since there would be clients stuck at V1.)

In fact, the security promises of having a 128-bit connection ID option (allows for making routing info harder to forge) are greatly diminished, when a load balancer has to support 64-bit connection IDs "forever".


-----Original Message-----
From: Ian Swett [ianswett@google.com<mailto:ianswett@google.com>]
Received: Friday, 12 Jan 2018, 8:59AM
To: Christian Huitema [huitema@huitema.net<mailto:huitema@huitema.net>]
CC: IETF QUIC WG [quic@ietf.org<mailto:quic@ietf.org>]
Subject: Re: Increasing QUIC connection ID size
I would like to leave QUIC open for longer connection IDs in future versions, so I'd like to specify the invariants in such a way that longer connection Ids wouldn't violate them(ie: Victor's suggestion of “middleboxes always get first 64 bits and they have useful entropy to distinguish connections”.) but I'm reluctant to include 128 bit connection IDs in v1 at this point.

I would also echo Christian's sentiment that the incremental overhead starts becoming fairly large.

On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>> wrote:
We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value.

On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state.

If the router does not want to keep the state, it can indeed create a connection ID by encrypting a <nonce, server-ID> tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish.

So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large.

On 1/11/2018 2:25 PM, Mikkel Fahnøe Jørgensen wrote:
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.