Re: Need your help: different connection IDs in the same datagram

Martin Thomson <mt@lowentropy.net> Wed, 15 July 2020 22:49 UTC

Return-Path: <mt@lowentropy.net>
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 6D5A83A0AE3 for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 15:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=nbaR8Thi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RKXKgr0N
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 60p3F_TC0kdB for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 15:49:41 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BCD3A0AB8 for <quic@ietf.org>; Wed, 15 Jul 2020 15:49:41 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E3518D55 for <quic@ietf.org>; Wed, 15 Jul 2020 18:49:40 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 18:49:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Aw+1U17+CloHQ5nYikj0HUFcgatIqxs QBN9EPsCX1AU=; b=nbaR8ThiBeXNd6E0HAZi1rf+q0GZE+jHDHhiIFmkUd3hxa1 rFJzUV4tAC8QQk4/lkNPgTOZmgQFtKZAtusSd+2yjocWMcbK7pBb1RJOaG6gaq5k qu9/PY8Er0HtCXIF/B4vXnlTaez6jEB6+pT1AggJ5bXZ6WrwyEhrFKHFH8AtLl/f lb+aJlyxVv8FKLXxr723Ws1koZJF1km4fvmaF05OdHCPtk5LM5D4IOIFvxJadOFq HAr1xPcrSm8IBV7jVoLXYrP/gAA7tQgHmqF08s7zER1IX+HcGd6HUEPchxp8kGQp cS+gNptKwx+4/cSYab1t54MPN9I67lHnQiuMaRw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Aw+1U1 7+CloHQ5nYikj0HUFcgatIqxsQBN9EPsCX1AU=; b=RKXKgr0NgPZqjcXFZMBMGZ 8jDSX05gNU3c/9rkIR1ONQikfEVbFqGCXil/LJQ0CqO1l+v35JNAEG6oyiUJ9BeP BP7zXzq+KR3zzfXMa5AYIVedWr2QKNdJi9iOKMpLFDCmEU9Nc8Krdc0kuZHKwyqy e7MwZ3VDghOJnFqTKUO6Pn9pTDnpMT3aazAlhCbjwo8ABaurB2d07CdVx4lTLSTl bguBr9WGQp15afPE3Z1UVkh/4DQSk2br5JVtLLmx+VxuspNE+mflRiwwwmNArn/9 OSQIQdfYnZafnt7NwEMngeFEXS77TSi9n0teMhdZVaTtUP+9HP47AbogVHXqhWrw ==
X-ME-Sender: <xms:BIgPX-FcGdZsUDUoOTnyVcyrP-mcMFHMY_WV1h_c6xLntmdS4qNpNA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeefgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:BIgPX_XNoPdXtvt38EEwQ3Swi34WgqNmZ09OQdElaaRJuge32HKkug> <xmx:BIgPX4InvjO6TnlbvrjmuxlahFT1MT6oEEhdsDa9QqPB6JyNhjucDQ> <xmx:BIgPX4EKMUx2NYVJ72u9xo3CobgArDa9ah1NQ7DIbA6EYqTXmogNdg> <xmx:BIgPX1U8gBJpXklUxnOgIfPZoTBd9RcyCcnfH1EAALCFXg8iRR-PdA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21321E00DF; Wed, 15 Jul 2020 18:49:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <9b265aef-d1bd-47cc-9a1c-677eef223c73@www.fastmail.com>
In-Reply-To: <CAKcm_gP24=x64QwcCdki-jxFXsLKiTPH8UYFdGOG3H1YJgEbOQ@mail.gmail.com>
References: <ae21cc02-3357-40c8-a1e9-3966fdf575a5@www.fastmail.com> <20200715180231.GB9808@lubuntu> <CAKcm_gPfc3sFy0kuyTzUFk2XFMZ8NdXTd7CuNf0o0v+RXDG=xg@mail.gmail.com> <CH2PR22MB20861D3BEA06EE61AA882245DA7E0@CH2PR22MB2086.namprd22.prod.outlook.com> <CAKcm_gP24=x64QwcCdki-jxFXsLKiTPH8UYFdGOG3H1YJgEbOQ@mail.gmail.com>
Date: Thu, 16 Jul 2020 08:49:20 +1000
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Need your help: different connection IDs in the same datagram
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5q9GuuN6QeccUF6ktiM5eJ84B_g>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 15 Jul 2020 22:49:45 -0000

On Thu, Jul 16, 2020, at 07:17, Ian Swett wrote:
> I forgot there's a contradiction, because I thought we disallowed 
> sending mixed-CID packets.  So I'd prefer changing to MUST NOT coalesce 
> packets with different CIDs.  Even if you generate them and then 
> coalesce them(which we do), that's not that hard to enforce in the 
> coalescing code.

OK, this is good information.  I had understood that you were concerned that you might violate a requirement to have consistent connection IDs.

Here's one example of how you might:

Client receives server's first flight, which comprises Initial, Handshake, 1-RTT (which includes NEW_CONNECTION_ID, because this is a good time to send that in a lot of cases).  Assume this all comes at once, in a single datagram.

1. Client processes Initial and Handshake.
2. Client generates a Handshake packet (that includes TLS Finished) and sets that aside.  This uses the connection ID from the servers Initial.
3. Client processes 1-RTT.  Sees NEW_CONNECTION_ID, decides to use it.
4. Client generates first application data, and makes a 1-RTT packet using the new connection ID.
5. Client gathers all generated packets and sends them.

Does anyone care about doing this, or something like it? Because if not, I make a new proposal that changes the requirements to:

* Senders MUST ensure that all coalesced packets include the same value for the Destination Connection ID field.
* Receivers SHOULD discard coalesced packets if they are for a different connection than the first; senders MAY discard coalesced packets that contain a different value in the Destination Connection ID field than the first.