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

Nick Banks <nibanks@microsoft.com> Wed, 15 July 2020 14:19 UTC

Return-Path: <nibanks@microsoft.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 31D183A0C13 for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 07:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 3nRhw31ujfrU for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 07:19:48 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650125.outbound.protection.outlook.com [40.107.65.125]) (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 853E73A0C3A for <quic@ietf.org>; Wed, 15 Jul 2020 07:19:43 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PLl3giwA3u192hp9EkwKFMU9M0/47X9qdnbTtfapYIm+kP8Njr+SiHU3MAzTsUYPpxxMTHhH2JmK3sh4/nZ5JGvLmTFh/MoSKx1vMLER2fok/Q3mpPiRHHS4czI5B+cBv7d3CYtnVG5GP0dVlTlyRFeQVAH0Z3FLMS7aHnSfRVTHnuIZrsnnTdL94y8aw8F8RK3YqYzbigI+r3mKOMg658llAHJHREZC8DwjBG7a/puRbmgITlZsDUxBmE6EpxuLWsGYhop252c/bU4xdJ/Z9zIYybSaip26zNMYFetO4EmXFFtJvqw4c+NzXBDwSbrER0QIvw+iQbaMkqEwAzwWig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=on2diSG9/0qFMigWg3c1+RTMUhwTucpsytVOt3apZaI=; b=ayI5Jce019aUihlRId9YONH2hpFgtsQwe9b1qxT0ikN05pFlrwZGUwYQTXqlIc01UTugG8kn6CObPDRUnDEVFwMXAhJGtsq8cO+7o48p/bEm3Wm9D7Hi48lg6YH2dII0CdxxuzplIqiRApeWHG1Opzudnlf5P25MK88VLJ72LycoKDhSc59HZvXpcjWw8qXiEEULPeFlUT1xeYa/K3Bgjnu52yfVBWn51f3zVDwjRrq9ZLSOL7BHLzPsi6G7FWMXPRc/AEoBUzbDb7GCdu5KLgJjRfQ11a8+LYX0/hG8GzZ5iuCtWnc5icTKCf2iWVX/IsH1tjEFGljySERKH3N6hA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=on2diSG9/0qFMigWg3c1+RTMUhwTucpsytVOt3apZaI=; b=OhQxPt/PWznMziojhwGuKCgApYu9fEB2vjE0vl9zaSOaUh7+2DcSvofNvJXraoRK/OWzh4UjTNTMHVFkpgLkp5aWklesXtkB5JMw+4TDTRmSyJCGppUT6Oe0ptDXtQexdk2ILoett+4atnrwZMSJwy7luyzrGARPbjpS1PQv5S0=
Received: from DM6PR00MB0767.namprd00.prod.outlook.com (2603:10b6:5:1bc::8) by DM6PR00MB0798.namprd00.prod.outlook.com (2603:10b6:5:20c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3235.0; Wed, 15 Jul 2020 14:19:38 +0000
Received: from DM6PR00MB0767.namprd00.prod.outlook.com ([fe80::8cde:b3eb:6722:d9f9]) by DM6PR00MB0767.namprd00.prod.outlook.com ([fe80::8cde:b3eb:6722:d9f9%9]) with mapi id 15.20.3236.000; Wed, 15 Jul 2020 14:19:38 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Marten Seemann <martenseemann@gmail.com>, Martin Thomson <mt@lowentropy.net>
CC: QUIC WG <quic@ietf.org>
Subject: RE: Need your help: different connection IDs in the same datagram
Thread-Topic: Need your help: different connection IDs in the same datagram
Thread-Index: AQHWWnj9jl+t0ZAZWEqMGonzhdFIe6kIiFEAgAAlyxA=
Date: Wed, 15 Jul 2020 14:19:38 +0000
Message-ID: <DM6PR00MB07671C4366474017F18BC3D8B37E0@DM6PR00MB0767.namprd00.prod.outlook.com>
References: <ae21cc02-3357-40c8-a1e9-3966fdf575a5@www.fastmail.com> <CAOYVs2o4PJmApJ=4BCNTW5agOJOgfvigyQSVhjvnWFCc_arHcQ@mail.gmail.com>
In-Reply-To: <CAOYVs2o4PJmApJ=4BCNTW5agOJOgfvigyQSVhjvnWFCc_arHcQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-15T14:19:31Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=8d37d2af-4592-42b9-aa11-8b90a8dd298c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [66.235.1.136]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0f0989ba-d62c-4650-2dd4-08d828ca1b73
x-ms-traffictypediagnostic: DM6PR00MB0798:
x-microsoft-antispam-prvs: <DM6PR00MB079895BB6BA3B3FD252D6CC9B37E0@DM6PR00MB0798.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2jP5Ve99873MtaJzX5fp1d9gMLaB8fOiRI3OZmXMlJOkAARhszrn+90e7OdMD7yB06PCS73pwXbHM2DP1+QfFanpsX1KPzl+fGig/tF+mwVerS5iVUUCTsjUon95bQqSB78/yNr0MsT0puBgYPlKF2OtXfpskjaSc+iyr7yPb58qCi22K92IMC0+SmuQTNWk8kqWiOh38lFqeiXNkPFtbndnxqwRS0UjDV3Y0S1YjIragLosCVE31y3ICNa16DUOT1cBwH7PMj2PDgip/ZbKRUW6QokbV2FCy3SvNN9qEhluA/Qx+vdUJr0SIYogXqRiifxm0iI82vObXTH8lj9S4YsUv2AI//sPC7jiE0w+DstCT/ZlupUucpEfjsXjRlDJEPZkoW1gTmlLiIXRuDNlLQvkoQcrV9YMLjji+YzvoO7cwTuMRMUcr0YWwauyoGR1wEH9OOKihiCMDfJoBhhgzQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0767.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(366004)(346002)(396003)(5660300002)(71200400001)(26005)(10290500003)(186003)(110136005)(316002)(86362001)(166002)(966005)(478600001)(55016002)(2906002)(66946007)(83380400001)(66446008)(64756008)(66476007)(66556008)(6506007)(53546011)(7696005)(52536014)(76116006)(9686003)(8936002)(33656002)(8676002)(4326008)(8990500004)(82950400001)(82960400001)(151803002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: US7aKv+IKH/4alEb7575db++J+tuIEcehirvu96FcKQ2d1QDtl/zWQ1fNJsPdbFoVtjYHi3kRQQjibdW870n8vlumQhMOZurng3YGwFJWRO+k5WaAgm3tFNGaSG/AoOQ2k/7DudLsYEKcsZLrdpdYxzynKTAUcq3wpl+vagT5HbTJXgdsvqr2j0KpNVEZL/0eTBcAtHA2HnMP5unHr9odAHzcOVEMhbJHKfSy9tlqvG4YcH1Y+mdY9wQVPkLhtvHr3mdrRJu0H+nIEbgqc67lWpBd9HtTjA2onC6ZxAIU8yNYkA+M3Y7MozCyiWoZD9IGzMlQPaDWwDSDamCfrS2nrDqoWCzdQJahYs4U7xq175j4XHTAVgngiUX0Ue33nkJt5MCJufPImgmGE0rv31jPnk46L9gg2pUO4CTHtj0uzZhjQuRUXYUIjKTpBukOFdolebssiotZyZXe7qWfCxeaVnmalAts6UiAtFNUxYUTTjLhLy7B5xgZkinkj+zA1w/m/8PGZXF5Y54+oHLto7mHyaLyYZgSalXrhXniKNd8ny2kAn07YY4M42ljPalu5g1nOQjIFGphrxibVDMxg1B7cFq6DRdFguvXU5oKx6Etbnur8sqBRXo6FPw+oNAMxgEgPrYXvyoJOkv0absq641Zw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DM6PR00MB07671C4366474017F18BC3D8B37E0DM6PR00MB0767namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0767.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f0989ba-d62c-4650-2dd4-08d828ca1b73
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 14:19:38.1515 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: YhaSQ1vBspyj2lOp0vYB/xq0DoZKTROkiHV4ys8JDPtT+xJWjxvO6z00hEldzImjPvAgv33UgsHNDXqAZdy9JA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0798
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NhB-rBzsN0t9ArvyrHc0_TgXB8I>
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 14:19:50 -0000

Generally, I agree with Marten’s comments that that there is little reason to use multiple connections IDs in the same datagram. Specifically, for our implementation, MsQuic, validating the connection ID in each packet is much simpler if they’re all the same.; our UDP datagram context structure holds a pointer to the first connection ID in the datagram, so all that needs to be done (for each QUIC packet) is compare the current QUIC packet’s connection ID to that pointer. The logic requires no additional connection state. If we allowed any connection ID that’s valid for the connection, then we’d have to go to the connection object and do a lookup each time instead. It’s definitely possible to do, but requires a bit more work (CPU) and synchronization of state. For those reasons, I’d prefer to keep the connection IDs consistent.

Thanks,
- Nick

From: QUIC <quic-bounces@ietf.org> On Behalf Of Marten Seemann
Sent: Wednesday, July 15, 2020 4:54 AM
To: Martin Thomson <mt@lowentropy.net>
Cc: QUIC WG <quic@ietf.org>
Subject: Re: Need your help: different connection IDs in the same datagram

Let's have a look where this situation can occur:

During the early stages of the handshake it is not possible: The client changes its connection ID used for Initial and 0-RTT packets as soon as it receives a new connection ID provided by the server in a Retry or Initial packet. The earliest time where a client could possibly coalesce packets with different connection IDs is after receiving the Server Preferred Address, and decides (for whatever reason) to not migrate to that address, but to use that connection ID on the original path (and before the handshake is confirmed).

The server needs to receive a NEW_CONNECTION_ID frame before it can change connection IDs. The earliest this can happen is in a 0-RTT packet, so in principle a server could start using that connection ID in its first flight.
I can see little reason to 1. start using a new connection ID during the handshake and at the same time 2. to not completely switch to that connection ID, but instead to continue using both at the same time.
To be clear, it isn't prohibited to use multiple connection IDs at the same time (and on the same path), it's just that there's no good reason to do so. I don't think it's too much of a burden to ask implementations that still decide to do so to make sure that the connection IDs used in a coalesced packet match, considering that for the receiver it's more cumbersome to check that all connection IDs are actually valid for this connection than to just validate that all packets use the same connection ID.

On Wed, Jul 15, 2020 at 2:24 PM Martin Thomson <mt@lowentropy.net<mailto:mt@lowentropy.net>> wrote:
https://github.com/quicwg/base-drafts/issues/3800<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3800&data=02%7C01%7Cnibanks%40microsoft.com%7C75dfe6046cbe489852d908d828b5d4be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304108718116239&sdata=ixeFxeDjp0kzD87SZz3APaSAnHoAbP5K%2Bl53TSEDfe8%3D&reserved=0> discovered a minor "discrepancy" in our requirements for coalescing packets.  We required that:

* senders not coalesce packets for different connections in the same datagram.

* receivers reject packets with different connection **IDs** in the same datagram.

https://github.com/quicwg/base-drafts/pull/3870/files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3870%2Ffiles&data=02%7C01%7Cnibanks%40microsoft.com%7C75dfe6046cbe489852d908d828b5d4be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637304108718126227&sdata=zb1PUsYnpLqkEIyD%2B3cmxSKtjvivb05or70XnqMFUyc%3D&reserved=0> was the result of a discussion where I was convinced that looser constraints here weren't harmful.  The requirements would identify connections, not connection IDs.

Originally, my inclination was to fix the requirement on the sender to use connection IDs, which would remove some linkability.  But then I was reminded that linkability is already defeated for several reasons.  You can't coalesce outside of the handshake and we require a stable path for the handshake AND long headers include a source connection ID that can be used for linkability.  So the linkability concern is basically lost.

We also learned that some implementations were generating packets while processing incoming packets.  Later they would coalesce these into a datagram that might then have different connection IDs on the packets it contains.

There has been some opposition to the proposed resolution in PR 3870.

Apparently, for some, having multiple connection IDs in the same datagram complicates processing.  I don't understand this objection.  It seems to me more difficult to retain state across packets than it is to process each atomically.  I was hoping that Christian or Nick can explain more about how this affects them.

Marten also indicated that there was a reason not to allow this, but if I understand that, this is based on some potential for future optimization, which could be conditional on having consistent connection IDs.  If we moved to a scheme that required consistent connection IDs, anyone using that scheme could be required to avoid coalescing different connection IDs.  So this seems more of a theoretical concern.

And - in anticipation of maybe choosing to make senders use a consistent connection ID - if you might be generating coalesced datagrams with different connection IDs in packets, how hard would it be to ensure that these are consistent?  Lars and Ian, I think both of you indicated that you might do this.