Re: Asymmetric CIDs

Ian Swett <ianswett@google.com> Fri, 16 February 2018 17:26 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 29E3D1270FC for <quic@ietfa.amsl.com>; Fri, 16 Feb 2018 09:26:24 -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 lKhqhf9whOS8 for <quic@ietfa.amsl.com>; Fri, 16 Feb 2018 09:26:20 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 6FADF124C27 for <quic@ietf.org>; Fri, 16 Feb 2018 09:26:20 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id p204so2591795itc.4 for <quic@ietf.org>; Fri, 16 Feb 2018 09:26:20 -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=rXDu5dbxBDMMqCpHdFmpLlulITIxJmg3BBtDVS0JvOk=; b=XQkAGaHxKbKo/fju6Ge1hlq4QlM+CpRDHKOJSZtnlWOkTdPGZKzp8E8+m52Xhn5xD7 IhaRd3pkyMEKpUwyV305mYnE7VsZCbfcONibMcVo4uM9HSl9fXE5Y3Lu4zbi0qhIkUom 43EkMRSSqzGzR6Nw5xePKdLpylXYwNdGKeWEVV0r2ZK2T1MlYoQ8AImU/dJY2APflGLO Yw1LmVaCOW4EPEp4M9jMo3wVapbrf8IOrrHIHmffafzmEm5PiZw1FAKy3fPG4jLWFyRu Lw73t0SvRQfqlkBJO8cOWijF+VQEnl6pQi04YfCpufXotGP+/28oOCsjy/FRtqad04Ye /KdQ==
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=rXDu5dbxBDMMqCpHdFmpLlulITIxJmg3BBtDVS0JvOk=; b=o18NU54UI5Srs1UFwRbYHyZGAx2BYW5MfMdPgKtG86cW48/gPqXKXH0Kubek+itmUo NPy8Q0BrZzTFvrSnI4IKTXUlGrir65IFrhjN8iD55ItaNxGcnnmU1uvB3u5q6OhLY+E/ Yds5rR41lPwakZDpDVbW9wKXUzXPi7VRa6zWK7KTflwea7vFT+TpPE/c34zj4F1X71b8 XUG+7APXD081DKyLK4UtqpuawUYwdIcBA5NKcTxLUPT+AkDA2xDJSrx7yUwNSedJyMCC v5X1Y1d5DMDLPbtNkel5iQMiF4xqsljmUapndzaPXuicbApO2WVBZn5teblsIaZRLUrg kxVQ==
X-Gm-Message-State: APf1xPBlRcG/B2wTHbve7dsqAtKs1sEx7WhW6AoaF9A+yT2V/vKhLxo5 k56buPtkbTKVF1MoPa6krWl5n7e2OGHE8B7IKG9Ilg==
X-Google-Smtp-Source: AH8x227xbvDgQclbU5ERU38iWVUttkiMgJu7Uuf/PmfvPyhDnWt9Loyb6AXVgIm8FukoAEBJ1rv1/zG4mDFBpqhSZtM=
X-Received: by 10.36.121.5 with SMTP id z5mr8973485itc.146.1518801979392; Fri, 16 Feb 2018 09:26:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.222.4 with HTTP; Fri, 16 Feb 2018 09:25:58 -0800 (PST)
In-Reply-To: <CABcZeBMVabN9LQ42BxpSwK71hzu_TbzwqhHTJV1uJBKr5g-N3A@mail.gmail.com>
References: <CABcZeBMVabN9LQ42BxpSwK71hzu_TbzwqhHTJV1uJBKr5g-N3A@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Fri, 16 Feb 2018 12:25:58 -0500
Message-ID: <CAKcm_gOvf0N7sq2so38sQaD+2jHGnDpsSQHEwU8HPgSpMJRfzA@mail.gmail.com>
Subject: Re: Asymmetric CIDs
To: Eric Rescorla <ekr@rtfm.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114abbba7839b2056557a458"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/-a6uAyC3kqM1FEvnrPBXNsUBcLg>
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, 16 Feb 2018 17:26:24 -0000

Thanks for the excellent summary EKR.  I like this design and think the
breakage of stateless reset in certain cases is acceptable, since it only
applies if both sides must have their preferred connection ID present in
order to route correctly, which is a use case that's impossible in the
status quo.  I have not come up with any other downsides.

On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Hi folks,
>
> After a bunch of discussion, the CID task force came down to rough
> consensus that asymmetric conn IDs were probably the right
> direction (CID task force members, please feel free to voice dissent
> here). Here's a complete writeup of what I think would be needed
> for asymmetric connection IDs. It's not a PR, because I think
> something self-contained is cleaner.
>
> Note that if we adopt this direction, we would be sacrificing
> public reset under some conditions (see previous emails to the
> list) and we would need to decide if it was worth keeping at all.
>
>
> OVERVIEW
> The basic idea is that each side gets to dictate the connection IDs
> that are used to send to it. During the handshake, you establish those
> CIDs and then each side can issue new CIDs during the connection.  The
> main advantage of this is that it allows for symmetric topologies in which
> the client is also behind some kind of stateless LB/router rather than
> just the server. See Issue #1091 for more info on this.
>
>
> The overall handshake looks something like this:
>
> Client                                      Server
>
> Initial [CID=XXX] {recv-CID=YYY} ---------------->
> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ}
> Cleartext [CID=ZZZ], {recv-CID=YYY} ------------->
> <-------------------------- Short header [CID=YYY]
> Short header [CID=ZZZ] -------------------------->
>
>
> The client's initial CID (XXX) is special, and either consists of
>
>     (a) a randomly chosen dummy CID. Proposal: require this to be
>         8 bytes or at least a minimum. This should be the same
>         for all Initial packets in a connection (unless a stateless
>         reject is received, as below).
>     (b) a CID which it received from the server in a stateless reject
>
> All the server's packets are sent with the client's receive CID (YYY)
> and all subsequent client packets are sent with the server's receive
> CID (ZZZ). The general rule is that you should send with the
> connection ID that you most recently received (where recently
> is defined as highest PN).
>
> Note: I believe it's safe to just use the sending CID as the mixin
> for the KDF, but I haven't thought this entirely through yet.
>
> Finally, you can send NEW_CONNECTION_ID in either direction to provide
> a new connection ID for the other side to use. The general assumption
> is that you can do this at any time, just as with current QUIC, and
> that any time you send to a new remote 3-tuple you should change CIDs
> if you can. Note that this means that endpoints should try to make
> sure that the other side has spare CIDs in case they need to migrate.
>
>
> WIRE ENCODING
> As we discussed in the meeting the short header should just have
> an implicit length CID. This gives us the following short header:
>
>    +-+-+-+-+-+-+-+-+
>    |0|C|K| Type (5)|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                     [Connection ID (*)]                       +  <-
> change from 64
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                      Packet Number (8/16/32)                ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     Protected Payload (*)                   ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Note that we may also be able to dispense with the C bit, if each
> side just gets to say "send me this CID exactly", why do we want
> to say "here is my CID but you can omit it".
>
>
> We have several options about the long header. The first question
> is where recv-CIDs go. In previous versions I suggested putting
> them in transport parameters, or elsewhere in the TLS handshake,
> and that might still be viable, though it has some drawbacks [0],
> so the other alternative is to put both CIDs in in the long header.
> This would look something like:
>
>    +-+-+-+-+-+-+-+-+
>    |1|   Type (7)  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  DCID-Length  |                                               |
>    +-+-+-+-+-+-+-+-+   Dst Connection ID (*)                       +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  SCID-Length  |                                               |
>    +-+-+-+-+-+-+-+-+   Src Connection ID (*)                       +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Version (32)                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                       Packet Number (32)                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Payload (*)                        ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> The semantics here are that the first value is the CID you want to
> send to and the second one is the value you want used to send to you
> (I've inverted these to keep the order the same as short header).
>
> Two notes about this encoding:
>
> 1. I think we agreed that we didn't want arbitrary length CIDs up to
> 255 bytes, and yet we have room in this length byte. I propose we
> limit it to 31 bytes and then grease the remaining 3 bits [1].
>
> 2. Because the client sends its CID first, there's no way to get the
> current QUIC semantics of the server just dictates the CID.  I propose
> we fix that by defining a special sentinel CID (all 1s, all 0s,
> whatever) of whatever our maximum length is that means "just use your
> own CID".
>
> We can endlessly bikeshed on this structure.
>
>
> Finally, we will need to update NEW_CONNECTION_ID to allow a variable
> length CID. This would look like this:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Sequence (i)                       ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  CID-Length   |                                               |
>    +-+-+-+-+-+-+-+-+       Connection ID (*)                       +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +                   Stateless Reset Token (128)                 +
>    |                                                               |
>    +                                                               +
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> [0] However, in the transport parameters design, if the server's
> handshake gets reordered, the client might need to send some ACKs with
> the initial CID. However, we've agreed that the client's IP address
> has to be stable, so this isn't a problem. Alternately, you could
> change C->S CIDs in the short header if that was easier.
>
> [1] An alternative would be to have a sparse range (e.g., you can
> express 0-7 and then 8-22 by 2s, assuming I have counted correctly)
> and then we could pack both lengths into a single byte. As I said,
> lots of opportunities for bikeshedding here.
>
>