Re: Increasing QUIC connection ID size
Ian Swett <ianswett@google.com> Fri, 12 January 2018 13:58 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 32F2312D77D for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 05:58:50 -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 FDV7gIqxUgpO for <quic@ietfa.amsl.com>; Fri, 12 Jan 2018 05:58:46 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 B3BE112E869 for <quic@ietf.org>; Fri, 12 Jan 2018 05:58:46 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id t63so5950540iod.0 for <quic@ietf.org>; Fri, 12 Jan 2018 05:58:46 -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=d61a15hbM8tQPqvEbUviDoe3In+rQO0/WiAFrCrzqpg=; b=g0qI3lxKZEV0GxCwkvxb6Vt5yLAa8GYFaR+y+BTXtGrXnp7u27cTIuBurB2Ayv2AQW bwX375IYd10JKHX+vpboB42VnsGLwBWcjYxSfkO2ePxoRPQWm95U2XxRnQzrn6ktvAvb hqlFoRUaQ/BIA1Aq1foe1g35XflpM3pp52FdqYJX32TpNLYGswISGeF+43lfqT8WZ8/w oNJ3oqfTrlF0lUvdYU/zQau5Ih1++2C+p85bxlMJ0rf34y6Wl9tW9KK2GIBwbenKA0gM LHrDoe17vem1j3WORTpfV2ZpGjoQcoMpC1S6Al53QBsuQJ+GyWjAr14Vmp1wDoIAzVs3 EMLQ==
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=d61a15hbM8tQPqvEbUviDoe3In+rQO0/WiAFrCrzqpg=; b=HoH8qpBxa9Wuy61CCdNQfwJnTd1szC0IWt+bYtxXI3i8DzSPKplux1Vw9XXNQK85R4 aNPY4JiMnxW98lEkbu/gjjN4VYmC6AGs2rJGiv2Gm8VN9FVqjuyuLAZoEHw1l15Og8vi U0FJ4jQuK+pEPQcil1he9zkTTeCNbnu4Z/g3AuYObk/3+wJiGWNf8benOa3xUw3LB7Yc xV4QI6t2i1OhJz4vRQ+fiRTg4GSpvJfnR3b7Ddto4pZ1v03K+eqLtiCF29yxO89gmGaA 5jOZ7iHg+bzmlPQP4hNxT/TYL9q/arLBhYnN9i4+OnpnQ5FvNkxx8gFd1iT/aCNBCX2q Q9KA==
X-Gm-Message-State: AKwxytdI7AXyddyYFUPjz8mNzGS1+zz5rpEoZ844fdhS4NXQWuJt5uiZ LAuTR/4vNR4CWHoPxM85eQBa0CigQTB/ltu93/trJQ==
X-Google-Smtp-Source: ACJfBotDTUqAKOYhx2pHfDHgBVO7iLVPnDgPM31/LLynBNhRpH45+fNtuL54feKtAEtIqfyQDGplLfPrCfqoG9lEdlg=
X-Received: by 10.107.79.2 with SMTP id d2mr23801780iob.170.1515765525676; Fri, 12 Jan 2018 05:58:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.17 with HTTP; Fri, 12 Jan 2018 05:58:24 -0800 (PST)
In-Reply-To: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net>
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>
From: Ian Swett <ianswett@google.com>
Date: Fri, 12 Jan 2018 08:58:24 -0500
Message-ID: <CAKcm_gNyrW1rVMrO3oF06+YH6cCEf2KQgTKRtQ-JrvWa1cpYKA@mail.gmail.com>
Subject: Re: Increasing QUIC connection ID size
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="f4f5e803beb0b910af056294a93d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8NlH3tBATKCrVeQD-_HCFxcVOHA>
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 13:58:50 -0000
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. > > >
- 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