Subject: Enforcement of minimum size of the Initial server packets

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Dec 2020 21:18:53 -0800

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

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 15 Dec 2020 16:23:54 +1100

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.

-- https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14-7

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.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Dec 2020 21:51:33 -0800

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

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 15 Dec 2020 01:12:36 -0800

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.
> --
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14-7

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?

Mikkel

On 15 December 2020 at 06.51.57, Christian Huitema ([email-masked])
wrote:

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

>> 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.
> --
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14-7
>
> 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.

-- Christian Huitema