Re: Packet number spaces in multipath (was Re: What to do about multipath in QUIC)

Kazuho Oku <> Mon, 07 December 2020 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E17E3A0DA1 for <>; Sun, 6 Dec 2020 16:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oegD69NKZg1r for <>; Sun, 6 Dec 2020 16:04:28 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4621C3A0CE8 for <>; Sun, 6 Dec 2020 16:04:28 -0800 (PST)
Received: by with SMTP id d17so16942366ejy.9 for <>; Sun, 06 Dec 2020 16:04:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p2KayjxcvPD914r70bgSStIe0l/hzkieGdYwmK4RgVQ=; b=kWfDo/42pR+T2lE88nm/07A5zJRPtQIlwH95a4PLCF/94CglW891oh1ei7PasxRYeM CdwG9IrU/MVE73+Exjy12pRB69WwQWgv6ihWUQpaC37vIHebI9qPSqCe10dFeXbbbsy1 B5jaW/2S0VcjmCIVPcQqs4nDAcsYfKiLvHcf00LmCKfS8pnymJI9xWyek/9k48LUccBw 1cp+aMFwiiERkptxFB33uVpJiJhxUuyN+MH8eTg90kj3wrhKFpkKef0nJkn12VAfL+X8 gV4ekE6mxxcz20h3k1DOkwcFJUxVgh5kVW+FhEtqwmjhPNv1rv5za3z5Zed7IE7P2Bhb c0mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p2KayjxcvPD914r70bgSStIe0l/hzkieGdYwmK4RgVQ=; b=dQzvqZ/S6hovjIaj2BRNpUBBt0mgoq9G2PxsgvAuMM6YIAFsUeLt+lbBKt65fvgODo 5CNSvep92GYfb5iREkEM+JNR/1LX+31LbOdqrogpE0lmwFrzBm2aP+6l2wgXTwIJwKjN eengcomlyu5h4kKdJtQl1htZYCSAwgJkgOK7unD98rtlf9ULGYWUUTmjz8YXlRt0pLpz 6DPDMOkdAr8d2uv0Ff9o8aoGu0SG3FtiLagVroYunYz2XiBlLcDPyPHH8OafBXVpvjw6 qANqRM1+JEJGXALK2sVOPdlVEDE02rhwidyO/xaqtpQ3mx4Pj7iRPuyLme26Db0Nt1qh iE3w==
X-Gm-Message-State: AOAM530xG6n0yOdpIkqMchXepNM/cnd+CDs3hQl4AxWD6fGhbWUtjenr wVu9zmoOX4c/VVNun2T2elV516cPCfiSL2AMHPk=
X-Google-Smtp-Source: ABdhPJzBgJaBwC622x1jBGKvR5WnfPdpEb6reXL8G1xlmIxBSiWiDpFTlI35ad1iiQbeW8zla1r4bgSVZ+CIYh6gnxE=
X-Received: by 2002:a17:906:5609:: with SMTP id f9mr16069468ejq.535.1607299466460; Sun, 06 Dec 2020 16:04:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Mon, 07 Dec 2020 09:04:15 +0900
Message-ID: <>
Subject: Re: Packet number spaces in multipath (was Re: What to do about multipath in QUIC)
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="000000000000bf037405b5d49128"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Dec 2020 00:04:33 -0000

2020年12月7日(月) 8:24 Martin Thomson <>:

> As this wasn't mentioned in the discussion:
> On Wed, Nov 25, 2020, at 14:34, Jana Iyengar wrote:
> > First though, a point on terminology: the receiver maintains a separate
> > "ReceivedPackets" for each CID, probably for each CID sequence number
> > (CSN). Let's please not call this a SACK Dashboard, to avoid confusion.
> >
> > On the question of sending more than 2^32 packets, I think that
> > resetting the packet number (PN) is ok on new CIDs.
> A design like this would require changes to the way that keys are
> generated.  Unfortunately, I think that this also increases the cost of key
> generation a little for reasons specific to the internal workings of the
> key derivation function.
I think Jana is discussing a different problem. Let me go through.

For multipath, I think that it is a good idea to have packet number spaces
for each path.

Then, the question is if we want to use different encryption keys for each
path, or if we want to use the same keys. As AEAD prevents nonce reuse, the
sensible option here is to use the 32-bit unused space of 96-bit nonce to
contain the identifier of the path (note: RFC 5116 recommends AEAD should
support nonce of at least 96 bits). Therefore, we do not need to restrict
the number of packets being sent on one path to 2^32 or whatever.

However, there is a separate issue. That is that the packet format of QUIC
v1 does not allow an endpoint to start from a CID that is greater than 2^31.

Therefore, if an endpoint intends to use a new path ID (which is being the
CID sequence number), but wants to continue using packet number space of a
different CID, then it needs to ensure that the next packet number to be
used is below 2^31.

IIUC this is the problem that Jana is referring to, and arguing that it is
okay because an endpoint can always reset the packet number to zero on a
new path.

Kazuho Oku