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

Jana Iyengar <jri.ietf@gmail.com> Thu, 16 July 2020 05:08 UTC

Return-Path: <jri.ietf@gmail.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 5CDA33A0D50 for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 22:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 2iQG_aM1NXCD for <quic@ietfa.amsl.com>; Wed, 15 Jul 2020 22:08:57 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 B5F553A0D4B for <quic@ietf.org>; Wed, 15 Jul 2020 22:08:56 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id b30so293535lfj.12 for <quic@ietf.org>; Wed, 15 Jul 2020 22:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vlORikIBMMXr8O3JZhwcG4hBq5u1GDft2TIae+gDyEc=; b=htJBbFWlAeaFssrPwPQezj3A0P2Ehb8cC8FxstfRk8UaAeDVQJdWCU6wl1AIZCC1zS 14NUhXBRpUFNwjaM27h8DujLpX2aPKMKZcrYfd8k7bo6deVywonH4h2Qq1oePzANAuPG U3OQp1A5MJoDFa+ebzfF6DXWXSy3/08baBKn6fVvh3F4hyRPd683mHtJOIyVzdP9uGfG RTkGski79gKv/8U5lhIie9qre3sgI7BYHqc7uEeZR9Xdk5Iv22ExWex4XSUlYjdXhD2K BhnB5fEx5SecAwSYhOwLAQDtx5+xvBlH31zwzXv5ur+aR2SsQGjL1DmCbvztcce2eqN2 tjWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vlORikIBMMXr8O3JZhwcG4hBq5u1GDft2TIae+gDyEc=; b=Z/Gl+aUh5QCNlKWejfiGzpM9Hqx2GQ25J0xQrJA1HAyrmD3BlpEJFjWzejWGsAst5v 9SjN6Ut5WHFZyoXJUiT+934JfoDPNdU+YjLvNNCR7TRqccYMjyJGjJ9IwncjfhjeFnLW UM2sGc5rhPzHuiXvbs+mrjbvXhFaGw0mTSMNnNHejd4GeJmAXSGRT5eaP7AEbp3ScTXV HjjeWCNLqJjtZNnUMy/+5HBznUgUefkxtXjixSbG02FjMAiGUhyAdUqOB5xEJupPKRmZ kIEAlKJI2bqA/R8ELntyFXmxBerl4KdHatrEv58+wnxSOr9bFY7neNkVndZQb/F1fbIZ V2jA==
X-Gm-Message-State: AOAM530MygJcg34c2a2bz31NgpXasxtplDjiWaniT7h3EAmoG6be4c6v ecD/1acr7LboIbr7kZWtsI+rl8vZHF13RwjwEvNsfQno
X-Google-Smtp-Source: ABdhPJzDN7q0Ma8Z9JYASo9F+rQ1f1NwjwO8y63CJusb/XRLz9/dq2nThLJpEqktKTo8XEIwy5UNWzzIe9FbTMYDOlw=
X-Received: by 2002:ac2:4550:: with SMTP id j16mr1191039lfm.37.1594876134484; Wed, 15 Jul 2020 22:08:54 -0700 (PDT)
MIME-Version: 1.0
References: <ae21cc02-3357-40c8-a1e9-3966fdf575a5@www.fastmail.com> <20200715180231.GB9808@lubuntu> <7ee5a352-fef6-44ed-9e82-09194aae366e@www.fastmail.com> <20200715235957.GE9808@lubuntu> <4f59efcf-0fc6-4e64-ad20-8eb4e1978095@www.fastmail.com> <20200716003244.GG9808@lubuntu>
In-Reply-To: <20200716003244.GG9808@lubuntu>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Wed, 15 Jul 2020 22:08:43 -0700
Message-ID: <CACpbDceED0kb0Dd3-iCfzFU0At_vb85U2taSZW_3R-WtbRjazQ@mail.gmail.com>
Subject: Re: Need your help: different connection IDs in the same datagram
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000074eea605aa8809d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/32RAuEPmachLjzgDtO7WXqsx9UE>
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: Thu, 16 Jul 2020 05:08:58 -0000

The spirit of the text, as far as I remember, _was_ meant to prevent
multiple connections from being coalesced.

The text for a sender prohibits packets from multiple connections being
coalesced.

A receiver can be one of three things:
1. It can compare state across packets within a datagram. In this case, it
can enforce the policy of not coalescing packets from multiple connections.
2. It cannot compare CIDs across packets within a connection, and it
delivers all packets to the connection with the first CID. In this case, if
multiple coalesced packets belong to multiple connections, then subsequent
packets are undecryptable by the chosen connection, and dropped.
3. It cannot compare CIDs across packets within a connection, but it does a
lookup and delivers each coalesced packet to the correct connection. This
violates the SHOULD that PR 3870 proposes, but that is not a MUST, and one
could use this wiggle room if it's difficult to change the implementation.

In all three cases, I don't see that the new behavior in PR 3870 (SHOULD
drop subsequent coalesced packets belonging to a different connection)
makes it harder for any implementation in question. What am I missing?

All that said, I am fine with prohibiting mixing CIDs if that's where we're
leaning.

On Wed, Jul 15, 2020 at 5:33 PM Dmitri Tikhonov <dtikhonov@litespeedtech.com>
wrote:

> On Thu, Jul 16, 2020 at 10:29:07AM +1000, Martin Thomson wrote:
> > On Thu, Jul 16, 2020, at 09:59, Dmitri Tikhonov wrote:
> > > You've lost me a bit, Martin.  Is this the code you aimed for?
> > ....
> > >         if (conn)
> > >         {
> > >   #if VARIANT_A
> > >             if (!conn_owns_scid(conn, dcid))
> > >   #elif VARIANT_B
> > >             if (conn != lookup_by_dcid(dcid))
> > >   #else
> > >         if (false)
> > >   #endif
> > >                 continue;
> > >         }
> > >         conn = process_packet(quic_packet);
> > >     }
> >
> > Yeah, the point being that the check here is added at your discretion.
> > It is possible to rely on the crypto to ensure that the connection
> > rejects anything that isn't intended for it.
>
> I see.  That's true, this is another way to do it.  On the other hand,
> this is even less efficient than a hash lookup.
>
>   - Dmitri.
>
>