Re: Enforcement of minimum size of the Initial server packets

[Christian Huitema <[e-mail]>]

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

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

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