Frames should have a length field

[ekr]

In S 5.2.2 QUIC frames are currently specified without any length field. This means that it's not possible to skip over unknown frame types.

There are at least two reasons why this is inconvenient:

• It makes it hard to write passive analysis tools because those tools will just choke if they encounter unrecognized frames (they cannot process the rest of the packet).
• It makes it hard to skip over frames you don't care about without parsing them. BLOCKED is a good example of such a frame currently

[marten-seemann]

After completing version negotiation, there should not be any unrecognized frame types. A peer receiving an unknown frame type should treat this as an error and close the connection.

There's no overhead in reading a BLOCKED frame, since it has a fixed length anyway (5 bytes: 1 flag byte and 4 bytes for the stream ID). But even if it hadn't, the overhead to parse it and skip it seems negligible to adding 2 bytes (per frame) to indicate the length of a frame.

[ekr]

"After completing version negotiation, there should not be any unrecognized frame types. A peer receiving an unknown frame type should treat this as an error and close the connection."

Yes, I am aware of this. which is why my point #1 was about passive analysis tools which do not participate in version negotiation and merely have to take whatever is negotiated on the wire. We see this regularly with TLS where Wireshark can properly handle TLS extension it doesn't recognize because they have an embedded length.

"There's no overhead in reading a BLOCKED frame, since it has a fixed length anyway (5 bytes: 1 flag byte and 4 bytes for the stream ID). But even if it hadn't, the overhead to parse it and skip it seems negligible to adding 2 bytes (per frame) to indicate the length of a frame."

This isn't a matter of processing overhead, it's a matter of having to have the complexity of the code to process types you don't care about.

[ianswett]

I think skipping frames you don't care about is a non-goal, since QUIC is an end-to-end transport.

And I don't expect there to be that many extension frames in QUIC, so I don't think it'll be an undue burden for wireshark to keep up.

[martinthomson]

Closing this as a duplicate of #233.