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
