Re: Enforcement of minimum size of the Initial server packets

[Martin Thomson <[e-mail]>]

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.

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