Re: Increasing QUIC connection ID size

Ian Swett <ianswett@google.com> Fri, 12 January 2018 14:35 UTC

Return-Path: <ianswett@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 6F4E512E884 for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 06:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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, 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 hSlYV3yNQrTD for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 06:35:10 -0800 (PST)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 633EB124319 for <quic@ietf.org>; Fri, 12 Jan 2018 06:35:10 -0800 (PST)
Received: by mail-io0-x22b.google.com with SMTP id d11so6055683iog.5 for <quic@ietf.org>; Fri, 12 Jan 2018 06:35:10 -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=bhvbAvgDtc4r7E9z/es0TvJ88wyVxeTdNcPcZrH9fz4=; b=nEMssOwk2sbxDKxGqe94rBPc1rbIZvzZxzkWhLeWFlkoTXGU3NEiIqYYnNuqh2gHTT w8zJdk6gD+CjsnW28+Aim8RgvhzSDQAuH2RH1st3mxJiT373KsC0Cio2os8oJzBEDwJD WV4AwlPP2zKr9DAVlpilKTXpYdzO89opGJBoXgUu4tRnhvLTkdDCJ73uDnslYtPA+p+U 2nqCG2F29xZDkNDk2eKURRZO5SPTKZVDWTNF2hLq5NqG0bvda0WdN1A1u/xbEp0A/wFS R2dvZbhO+bATb4jIrNlggNV5jW5IlNAa5pmhD1B5eEnzwT02rQGWsufsQIN3YDi+sZu4 xuaQ==
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=bhvbAvgDtc4r7E9z/es0TvJ88wyVxeTdNcPcZrH9fz4=; b=o2DXynZLCSiHs0cIQNI8jUomEuZ7ZOyRrK1UG+o7iixhTGVGYVk6RVVBwembO5QezA twWqvrD3h8t2xAv7BSnIoeS79Hq8DQp9cgoa3aMNBifuC0F+f7Esv8eCvnBCRUuA+gRV SKReW5EL6pHUtbgtcrYCbzcHciD11U5SPh4XjhwCnPCkx5GotoOaFLbChE5Qrw9ZuQzu 7Hn+oftQLmiaMcR8YyUXvLbikpv6koxRFGXOY9LnTXe4v1telEuesIGrXkdg51r4+M3M b30jKhe3RYp+v4uT6ShY5XbiGBbAlRvjDKvWauh+djujP0EXOQ/IVBFPz6bOoMtKdULM WjMw==
X-Gm-Message-State: AKGB3mIV5nSo0GEEv/+ucKwVNl39DmRKPTaNPyAOkYv37SZisbQ8qBN7 OooVXbdFr/8c10DB1tL8tir4Q8NXiAjcfHMwfrZd8Q==
X-Google-Smtp-Source: ACJfBovjR9SkNfMTBKEPaFZp7/VPpPVS1+Bv2D0WMS+7SEYfnYCNFPe6ItLEDwwbFbQe2WFEYZ7u9ukPgwD1BJUDLHc=
X-Received: by 10.107.201.4 with SMTP id z4mr25403837iof.154.1515767709375; Fri, 12 Jan 2018 06:35:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.17 with HTTP; Fri, 12 Jan 2018 06:34:48 -0800 (PST)
In-Reply-To: <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.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>
From: Ian Swett <ianswett@google.com>
Date: Fri, 12 Jan 2018 09:34:48 -0500
Message-ID: <CAKcm_gNg6Q5Y7ebKZUFDGAFa8WmiC03wOzizLGcxGOTQNhSTMw@mail.gmail.com>
Subject: Re: Increasing QUIC connection ID size
To: "Lubashev, Igor" <ilubashe@akamai.com>
Cc: "huitema@huitema.net" <huitema@huitema.net>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b7042e1ead60562952b44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kKdPzxpwmwCZGNaqVWU7zIfAsjc>
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 14:35:13 -0000

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> 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]
> *Received:* Friday, 12 Jan 2018, 8:59AM
> *To:* Christian Huitema [huitema@huitema.net]
> *CC:* IETF QUIC WG [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>
> 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)
>> 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]
>> *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.
>>
>>
>>
>