Re: NEW_CONNECTION_ID sequence numbers

Kazuho Oku <kazuhooku@gmail.com> Wed, 05 January 2022 06:20 UTC

Return-Path: <kazuhooku@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 464BB3A2689 for <quic@ietfa.amsl.com>; Tue, 4 Jan 2022 22:20:30 -0800 (PST)
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 zNuTcksOJppK for <quic@ietfa.amsl.com>; Tue, 4 Jan 2022 22:20:25 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 109E33A2687 for <quic@ietf.org>; Tue, 4 Jan 2022 22:20:25 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id f5so157727143edq.6 for <quic@ietf.org>; Tue, 04 Jan 2022 22:20:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yblCs0aerkbOx+so4atyWuB8WexI3iPFaA9lzs+sfLE=; b=Kr/i4Kk7MEdvCU66YNAHrtXo6DCHjxY+fTxzQ1rsGiZEJIVdGvbJ7noR2n0Xp6+Bg+ oGSsMrtaEhrQKI88tOYsUYhPipHMlu5jTW1RwbXaXO2xtpcl430TAIphiwojMpmSIREc Grmr+XvtUrdkClL2QqMV6mJsT35dtlVK2DJxGaHHFKrWFdXm5Hioz7cTQREwbCrOWBgA CRb+oFuPM6uk8H6GbFar2v25+LUpfc272hz71Dmw102FsIzpwamjwgdcbc7PBkxD2ncc 36BsrLs2KTIxdOlATUvXV5U4pGJAXJbtWp/YOkyBAFurKQr/STGANUc7x+xokMrM2KL2 O9yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yblCs0aerkbOx+so4atyWuB8WexI3iPFaA9lzs+sfLE=; b=NRmQk5l58wjyH6KU2OvsJ/XNMyuFXnWnMKx64FDLYlFgiO37piN5990ZjOYf5ty9Qf JoKXIGEbN1WydBJwa+uPQOccgW0Vqxid4/x+58Zeo0fQpwnF58rfxvzUtNGuy6QTh76b ofrIikt+qP6YKlcbmdtcm+TE9BkCh+gNVsfZtYk+LHSF+b2lPe5M2G9NCErBEiq03vjd /zzAKqExHEPC6bgd/vSx3Lt31nEccV9vW5x3cyAFoFNgLqNRJCH+8qLaQCxio8Dr0ufv zn1RnU7MD8co79vUB5Wv/xQbNwAoOW/3ZAM+HaQAw2/7umjdXx6d6aiFYB79YlM/3ARX 9AUQ==
X-Gm-Message-State: AOAM532FXmvvM0LdHQy8UdpdGZvD9AEqhbOy0maYTupvXTMmdR8plstE ZMuN74CRO6CD/5fgzghb18kO2XBtmAjt3PPhJiX93hk5
X-Google-Smtp-Source: ABdhPJz7yehH4tKKDD8Un7JL8DWcBSeTMnEHfXkfXa7yAKRI8JpYVGruUwdwVI/YuoL6Fv2D7szhKsEkGJ17+XFIvZs=
X-Received: by 2002:a17:906:93e8:: with SMTP id yl8mr41246966ejb.207.1641363622406; Tue, 04 Jan 2022 22:20:22 -0800 (PST)
MIME-Version: 1.0
References: <27e024ed-a78f-416e-869d-82930c7388a3@beta.fastmail.com>
In-Reply-To: <27e024ed-a78f-416e-869d-82930c7388a3@beta.fastmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 05 Jan 2022 15:20:10 +0900
Message-ID: <CANatvzyq_sftiTeEEWi3JpYm1+bQS3TsC+wiUxksTpAP0h9gmQ@mail.gmail.com>
Subject: Re: NEW_CONNECTION_ID sequence numbers
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a9327205d4cfbf7c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tZKds3J4irxWdlgdAW2OFhHLqOc>
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, 05 Jan 2022 06:20:31 -0000

Martin, thank you for bringing the issue to the list.

2022年1月5日(水) 14:57 Martin Thomson <mt@lowentropy.net>:

> Hey,
>
> I discovered a problem in my implementation of NEW_CONNECTION_ID that
> quicly didn't like.  I was always skipping sequence number 1, even when
> there was no preferred address, which caused quicly to think that I was
> exceeding the limits it set.
>
> Kazuho, Jana, and I all agree that my code was wrong, but I found it
> pretty hard to clearly identify how this was specified in the spec.  Here's
> what it says:
>
> >  The sequence number of the initial connection ID is 0. If the
> preferred_address transport parameter is sent, the sequence number of the
> supplied connection ID is 1.
> >
> > Additional connection IDs are communicated to the peer using
> NEW_CONNECTION_ID frames (Section 19.15). The sequence number on each newly
> issued connection ID MUST increase by 1.
>
> -- https://quicwg.org/base-drafts/rfc9000.html#name-issuing-connection-ids
>
> Is it abundantly clear that I'm wrong based on this?  Did I miss a clearer
> piece of text elsewhere?  Or, should we be looking to open an erratum?
>

I think that the cited text is the only place that discusses this, and
regarding the text we have now, it seems to me that it clearly *implies*
that if preferred_address TP is omitted, then the CID(seqnum=1) should be
carried by a NEW_CONNECTION_ID frame.

If we were to skip CID(seqnum=1) when preferred_address TP is omitted, then
we would have not used a clause like "if the preferred_address transport
parameter is sent." Instead, we would have omitted the if clause or said
like "regardless of preferred_address transport parameter being sent."

Therefore, my personal view is that an erratum is *not* required. However,
I agree generally that implications are a source of confusion. If we are to
revise the spec, this is one place that we can do better.

Anyways. Even if we are to conclude that an erratum is unnecessary, it is
always good to keep a record of how potentially confusing text should be
read (or be improved in the next revision). To that respect, I appreciate
your bringing this issue to the list regardless of how we would conclude.


> Cheers,
> Martin
>
>

-- 
Kazuho Oku