Subject: [quicwg/base-drafts] Frames should have a length field (#194)

From: ekr <[email-masked]>
Date: Sun, 22 Jan 2017 20:45:37 -0800

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/194

---

From: Marten Seemann <[email-masked]>
Date: Sun, 22 Jan 2017 21:20:45 -0800

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/194#issuecomment-274402803

---

From: ekr <[email-masked]>
Date: Sun, 22 Jan 2017 21:41:03 -0800

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/194#issuecomment-274404796

---

From: ianswett <[email-masked]>
Date: Mon, 23 Jan 2017 02:27:07 -0800

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. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/194#issuecomment-274450815