Should there be size limits for messages and strings?

[huitema]

The messages defined in MoQ Transport include variable length components:

• name space,
• track name,
• setup path,
• go away URI,
• authorization info,
• number of supported versions,
• number of setup or subscribe parameters.

These components have no specified maximum size, which opens an avenue for DOS attacks: start sending a message with components of arbitrary length, up to 2^62, and watch as the other endpoint allocates memory to hold the message. Application developers are very likely to mitigate the DOS attack by setting some limits, either to the global size of messages or to the size of individual components. We may expect different implementations to pick different limits, with a fairly good potential of causing interoperability issues.

Maybe we should specify some limits.

[TimEvens]

+1 to having some limits. I think we should have some defaults in the standard and then negotiate those during client/server setup.

[LPardue]

Guidance on limits is good.

However, limit negotiation doesn't tend to work well when intermediaries enter the mix. We've seen this in HTTP/2 and HTTP/3 with the max field section size parameter. If a proxy is given something from the origin that exceeds the client's limit, its not really advisable to silently drop it.

[fluffy]

All implementations end up with limits and having them all be different in different implementations with no way to say they were exceeded is a nightmare.

I would argue on limits for everything and sending protocol error and closing the connection if limits are exceeded.

[huitema]

If limit negotiation is known to not work, then we should have the limits expressed in the base spec.

[TimEvens]

Currently, I've mapped the termination reason (https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-04#section-3.5) as the application reason code (https://github.com/private-octopus/picoquic/blob/master/picoquic/picoquic.h#L780) when closing a connection.

It's starting to look like this is not right. If we terminate by protocol volition (e.g., 0x3) then the remote side is left unaware of the specific protocol violation. Was it malformed, was it caused by invalid state machine, was it a timeout, was it a size that exceed, ??? If it was a size limit, then what size was the problem and is there suggested value to use? How would the remote side know what to do, other than repeatedly reconnect that results in only the same violation over and over again?

[huitema]

The error code in the application-specific variant of CONNECTION_CLOSE" is defined as "codes defined by the application protocol". So it is completely legit to put the specific MoQ code there. You may also want to use a reason phrase if you want to facilitate debugging.

[afrind]

You may also want to use a reason phrase

An endorsement for reason phrases!

See also #273