Re: Enforcement of minimum size of the Initial server packets

Martin Thomson <> Tue, 15 December 2020 05:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 533993A09A5 for <>; Mon, 14 Dec 2020 21:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.201
X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Vg6ZPYht; dkim=pass (2048-bit key) header.b=Q/UzGgVA
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9lzBlWTDeC3j for <>; Mon, 14 Dec 2020 21:24:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E9A13A0990 for <>; Mon, 14 Dec 2020 21:24:16 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 3AA7AC9A for <>; Tue, 15 Dec 2020 00:24:15 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Tue, 15 Dec 2020 00:24:15 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=xzr4ERRjkCN14v0MipSyTMfcZnDskFv BdBmZ4ye9TxQ=; b=Vg6ZPYht3c3IeIqjCNfdvrqllNiWsEzTW+gomsGO66UJ4DR CYwsYd0Ia92HNEBl7OKYSSx3psvyGQBvGWtN0DznEoLoKkQOKAcFJhQMOeC9hyRd Jy/22aHvaqEzIYx4X5tLC7xrxXB1cuJ2tQCrChF1aHhTiyOfMGilqCXCusWiX60c 75CHTFUTGDkgPOtUtzxsJ36SDhVRHKhhz5U9cSozX+/nDZFTJ2t6TlrrhPaDQJd2 LfTUpeqBCry4SoZkZiGhy0hEE3nejEY3RW2gvc1LadanAhtYoGg/XHsFTQA9DKiD XxQDh1Drvfx6VF/UdWEGRCfRaagwTjgIuG3MhuQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=xzr4ER RjkCN14v0MipSyTMfcZnDskFvBdBmZ4ye9TxQ=; b=Q/UzGgVAbS9M6zapiR64E4 JLZSOXk7t9ZHqsEK3lSOJZRiOzo+9H2F146F5PF4XVOWlXhn7pL93497ViaZRL2c 3mNnW384lZdX5oBYxKlhfp2mlUmNEFkAjDI0lQg0UM6/VuEXy4aPA54jA5st+qcC XB1JnX4JD2HdVgBBH4GB/CEwV6JX/Fjlw01hddoB6ex5GPw1ZLambA56eLz6jcSm +PKbkM+2lWDd79RcsnmVfxxk67X25GaCZo0pcPN2oELH0KQussPvQm/LqSEI9mUr nVroEo04jWyY9YyoUNG3TVTRdSBYaMSVCQzCc1R47dcPhpfdl8iUYbyIvr1UvKQA ==
X-ME-Sender: <xms:fkjYX_R3qqKQbV2kWavUCtmBTAktckxdK6jNoOeNiNOS4X7Rxp_l4A> <xme:fkjYXwxnQN8YIeoXexWrUcFX66CxB4CnVq_nBNdhNUm4DYsR9_UQr1cmllXirynk1 zE0cQFaNvngopN3kyo>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekledgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeitefgfedukeevffethe ekudetjeeitdffveeutefgveejueffgfehuefhgfeigfenucffohhmrghinhepqhhuihgt fihgrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:fkjYX00AcUlAuxBauwBsO-Ot2gu93jAgq1D1n8Ak2PfJ6_s9rVm0Dw> <xmx:fkjYX_C6QR2uPXshawxa6KfIm_6_XHo0IGHoGIWxKPVywT7y0D1F9Q> <xmx:fkjYX4j8czT-9hD6aQsDgCmov2Teabh_XDhGxRddlHsiWOCN_hDtNA> <xmx:fkjYXzttDkdnh5r0WVDvVrnfldH6KsNpBLlCdWMSs4OFC_ZMWGg66w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7A2AE200C5; Tue, 15 Dec 2020 00:24:14 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Tue, 15 Dec 2020 16:23:54 +1100
From: Martin Thomson <>
Subject: Re: Enforcement of minimum size of the Initial server packets
Content-Type: text/plain
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: Tue, 15 Dec 2020 05:24:17 -0000

Enforcement of that sort isn't permitted:

> QUIC sometimes requires datagrams to be no smaller than a certain size; see Section 8.1 as an example. However, the size of a datagram is not authenticated. That is, if an endpoint receives a datagram of a certain size, it cannot know that the sender sent the datagram at the same size. Therefore, an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints; the endpoint MAY however discard such datagrams.


When you combine that with not being able to tell (a priori) whether a packet requires padding, that means that clients can't really be expected to enforce this rule.

On Tue, Dec 15, 2020, at 16:18, Christian Huitema wrote:
> The transport spec says in section 14.1 that "a server MUST expand the 
> payload of all UDP datagrams carrying ack-eliciting Initial packets to 
> at least the smallest allowed maximum datagram size of 1200 bytes." My 
> question is, how do we expect clients to enforce that? If clients 
> blindly reject server initial packets that are less than 1200 bytes 
> long, they will miss those server initial packets that are not 
> ack-eliciting, such as packets that contains only acknowledgements or 
> connection_close frames. But if clients wait until the packet is parsed 
> to discover that it was ack-eliciting, the only remedy if they find that 
> the packet is too short is to close the connection with protocol 
> violation error. Is that the expected behavior?
> -- Christian Huitema