Re: Enforcement of minimum size of the Initial server packets

Mikkel Fahnøe Jørgensen <> Tue, 15 December 2020 09:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD0F03A0EAE for <>; Tue, 15 Dec 2020 01:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.196
X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[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, UNPARSEABLE_RELAY=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 93jxot7QSiLY for <>; Tue, 15 Dec 2020 01:12:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 418723A0E72 for <>; Tue, 15 Dec 2020 01:12:38 -0800 (PST)
Received: by with SMTP id k78so18252223ybf.12 for <>; Tue, 15 Dec 2020 01:12:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=+SF/wEdwHLvkXkPjFqIHKMM3a1syUK6TSl4HjRuwyIc=; b=BJf/EMsnp04Ixw5yCWae9t9Ns9QCSMkvq9E3Yp30LSsVIj1qPFLIeqV3sM96nYBgep 91sfJ3eI72Q+1CJhVDdJ7ITwIseQ0gSKm7B9t/y1RBKfVcnBQ1428aA0oP7LIIYHy3yL 3nVrG4vJ1eY095XllVbJGLoxcmpCAS0GeszRwjiToqiyPUoiTFqcZ2LNWHE1RuNfKxRj EkuFbK8G01csxl6QzN4uUGiY4k+QwX0tS3KnuSOEBmhVDRjWRLV7KE9Eh46cQJ2Fk9Lu /Zi9VQqw87qCqyW4jMMyeklNvH20Hcg3GLK6quZTJPfEMISpa+kyRLiMzz2q4IvkYfHz bKYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=+SF/wEdwHLvkXkPjFqIHKMM3a1syUK6TSl4HjRuwyIc=; b=ltOiHGkCj0KsFjT4D8R36bF+Dfj7j7uqege+KeZ488Rz7Yy6oCP6OCOmMOn85STIBp ptQyn3psAR0pN8+rys3CA6/0AY1f53toCjN/ms8xBkjGG1N0EE6S0Qh5MC9W1kwk6l/m 9W0zaqzWcx3shyfIMTiC61N0FTGBlYLaGjMzyJn0Ng2DuKTQujUPI5knhuaecE34l2ws oL1nBoRVyAinuHSjOSTSZA9h2EvbQSa7xUe3qN4AmSPa1vnJw+/No7m3xFTabH2R4VKK AOSIx2G9H1e27s4bisqtyMIP968MYOHS/2l+RstMR9RdJLWhT4hL3RrzgheHNO/rHR7J f+oA==
X-Gm-Message-State: AOAM530Ca0My+CynLHa8z8SsgQGACeI6sONZl6iJm6w/Ulwrpq2hVMdc OvBPrQFuSAD3bI1/4T7olSzCRkJodSYe3jxtlHjc4bCyDC4iWw==
X-Google-Smtp-Source: ABdhPJz5PGrgpfzou3CjxOXXiRvPCMJ8bZiqq9tMeLOiDRroWsoQbox2YtdxHBoT7Z73alkxG5rBpUvaq6Ur5y0OMuM=
X-Received: by 2002:a25:a3a1:: with SMTP id e30mr41495200ybi.264.1608023557362; Tue, 15 Dec 2020 01:12:37 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 15 Dec 2020 01:12:36 -0800
From: Mikkel Fahnøe Jørgensen <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Tue, 15 Dec 2020 01:12:36 -0800
Message-ID: <>
Subject: Re: Enforcement of minimum size of the Initial server packets
To: Martin Thomson <>, Christian Huitema <>,
Content-Type: multipart/alternative; boundary="000000000000ed56c705b67d2870"
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 09:12:40 -0000

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

But it MAY be enforced during connection establishment, 14.1:

"A server MUST discard an Initial packet that is carried in a UDP datagram
with a payload that is smaller than the smallest allowed maximum datagram
size of 1200 bytes. A server MAY also immediately close the connection by
sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION”

BTW: What does 14-7 mean in Martin’s link above?
I only there are only sections up to 14.4.1?


On 15 December 2020 at 06.51.57, Christian Huitema (

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