Re: Enforcement of minimum size of the Initial server packets

Christian Huitema <> Tue, 15 December 2020 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B22C3A0A29 for <>; Mon, 14 Dec 2020 21:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4UgTdjBhK8_L for <>; Mon, 14 Dec 2020 21:51:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 071533A0A21 for <>; Mon, 14 Dec 2020 21:51:39 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kp3FH-000KFl-6j for; Tue, 15 Dec 2020 06:51:36 +0100
Received: from (unknown []) by (Postfix) with ESMTPS id 4Cw6ny59LnzTQm for <>; Mon, 14 Dec 2020 21:51:34 -0800 (PST)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kp3FG-0002N5-Ja for; Mon, 14 Dec 2020 21:51:34 -0800
Received: (qmail 28573 invoked from network); 15 Dec 2020 05:58:47 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 15 Dec 2020 05:58:47 -0000
Subject: Re: Enforcement of minimum size of the Initial server packets
To: Martin Thomson <>,
References: <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Mon, 14 Dec 2020 21:51:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCMQk 66Vu1kq88Lj5xK2PZsnmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjUYFoLz2NZcguRHblw+ZN9KE5LN1n8YXzQY0mQUNzTGAwCyMkrqOaHyAipaXQfAHlJH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha9PVglyn2M1Ne3VuFRksqHzx FICOvNaKixd/6tiHJgrA2JUne37EdXOqrRyXv4wznjA08FLvVADy8LB0Htmu5lw11lqdy1V/0aEk MCdb3YpWUo4/+EUytKrR9Md9I2Rs12dbay1uBmcjbmCY3bWMBYRPCC/cRgvQKtcrMMueERx3USUv /kqk+HSX8N9n9PvNfFsVYsKIuuJFtFJVVKeiSTeIaIzNoZzswxuMaWjBAlpwQKAF9rx7E/FOOo0H C4C4+PUf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb
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:51:41 -0000

On 12/14/2020 9:23 PM, Martin Thomson wrote:

> 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.

Agreed. I guess I can write extra code to inspect Initial packets that 
are shorter than the expected size, and then ignore them rather than 
processing them if they contain a frame that requires acknowledgements. 
But that's probably the kind of checks that should only be used when 

-- Christian Huitema

> 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