Should server enforce post-Retry packet numbering?
Dmitri Tikhonov <dtikhonov@litespeedtech.com> Fri, 07 August 2020 13:54 UTC
Return-Path: <dtikhonov@litespeedtech.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 B7F683A0B58 for <quic@ietfa.amsl.com>; Fri, 7 Aug 2020 06:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.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 1tJ6wsQ5G06N for <quic@ietfa.amsl.com>; Fri, 7 Aug 2020 06:54:25 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 044783A0B33 for <quic@ietf.org>; Fri, 7 Aug 2020 06:54:24 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id o2so751681qvk.6 for <quic@ietf.org>; Fri, 07 Aug 2020 06:54:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=Fd0QI652mmcXb/ZaFFrWA8urDr2gCNMqwKqb6JNLHLU=; b=le4AaRqlt1TDr61fX6FrFGZ7oBWqLU4T2U6JIqEip/AUllV06e9YAv8/ZYYhA3Q9VH 6b9rIuspO/UM8WqnRuArkNsrockKJ41Cj6Ysi4Z1c4VNUPLyF5FkKOQrupZLzchsrJKn 3g8YkZV1KD+q33TsBWaq/4S3fYlLaaMCb9Lnawe4RVI7kKpoi8Gnvy9e8Bi015/2LTuz oJIsDZeZl4U6dYhHZnhciS1eO5AyuUmTOVZcJztTcvoMHiZkCqubj4Iaj3cTT6Gi9WJi TACaKRtp3srbTtbUCmvecfgubfT2+wxZQAceS6d2GvY3EjkJfrM7TJLvAqwE/BL9OHpe fAiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=Fd0QI652mmcXb/ZaFFrWA8urDr2gCNMqwKqb6JNLHLU=; b=YatQSKzGqNZ5p+ngyhOneyJ1qGuT3kcmW4Cc4+1MnERxd9HMPW1adrTlNBMSQxD2+y okAbjnSGjlSicFMIwHiEFBjIXYfagLG1hwZ/bYsozk68eE4RJ+CO8NKVHj1wYSftzdE+ GEYLSqmy/eq3G2hR1DBHDGSZhmagUp2ZEMlqgWoPRpCn8zFdTvN65tEwex18561YnsLP T0r2YgS8+lXfWa9Yhzz55HRB8LdL+X3Brbq9QgW8EQZUBo4lK8xGxfCxoAdEONr4cK/R PRa4PKTk7xTuTwUf4dse3L6WXmJMLF0fZk7vpVYcVSv5ym15H2oBZTpBJr/J3dARnry2 Z/yA==
X-Gm-Message-State: AOAM530+FU9MLDiXwS9gy+dLFPjUa9oSt/jUW4pIoEXUSBi4xovjbhNj Gbq6vAzTp2+9rCvrow4r8IiW0L83cVk=
X-Google-Smtp-Source: ABdhPJwTtpaMfNXUezKVx+M3MqIndOb8O3S9v8/5/yksLxeTD4MxHaNGYiSFoK9sF2sK9TxKPEXxmg==
X-Received: by 2002:ad4:4a29:: with SMTP id n9mr14883699qvz.50.1596808463490; Fri, 07 Aug 2020 06:54:23 -0700 (PDT)
Received: from lubuntu (ool-44c1d219.dyn.optonline.net. [68.193.210.25]) by smtp.gmail.com with ESMTPSA id b23sm7624102qtp.41.2020.08.07.06.54.22 for <quic@ietf.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2020 06:54:22 -0700 (PDT)
Date: Fri, 07 Aug 2020 09:54:11 -0400
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
To: IETF QUIC WG <quic@ietf.org>
Subject: Should server enforce post-Retry packet numbering?
Message-ID: <20200807135410.GA20644@lubuntu>
Mail-Followup-To: IETF QUIC WG <quic@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/D59v8K4Zem5Kb2zjQWyKsA_v1eI>
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: Fri, 07 Aug 2020 13:54:27 -0000
Hello, In a couple of threads on Slack, Lars reminded me of an interesting MUST NOT in the transport draft: " A client MUST NOT reset the packet number for any packet number space " after processing a Retry packet; Section 17.2.3 contains more " information on this. This made me wonder whether the server should check that the client indeed did not reset the packet number. This is possible to do by including the packet number into the Retry token and then comparing this value with the number of the packet that carries the token back. I could not find such SHOULD in the draft. Should it be included? E.g. "The server SHOULD abort the connection if it detects that packet numbers were reset upon Retry." - Dmitri.
- Should server enforce post-Retry packet numbering? Dmitri Tikhonov
- Re: Should server enforce post-Retry packet numbe… Marten Seemann
- Re: Should server enforce post-Retry packet numbe… Jana Iyengar
- Re: Should server enforce post-Retry packet numbe… Dmitri Tikhonov