Design Issue: Must Ignore rule for Unknown Frame Types

[jasnell]

In the current draft (-02) we say, "Implementations MUST ignore unsupported and unrecognized frame types." but we give no guidance that I can find about handling unknown frames that potentially modify session state. For example, suppose some extension comes up with a new frame type that includes a compressed header block. The receiving endpoint will have no way of interpreting the content, but if it ignores the frame entirely, it's stored session state can unknowingly fall out of sync with the sender.

Recommendation: rather than a "MUST IGNORE" rule here, unknown and unrecognized frame types ought to be a Session Error because the receiver cannot determine whether and how those frames may have changed the session state on the sending side. It would not be safe for the receiver to continue attempting to communicate with the sender on that session.

This obviously has an impact on the extensibility of the framing layer. In short, a sender would not be able to use a new frame type unless it knows the receiver can interpret it. The only solution for that would be to have some kind of negotiation occur where the sender effectively ask the recipient if particular extensions are supported (as part of the session header perhaps?)

[jasnell]

Related issue: MUST IGNORE and Possible Denial of Service Attack:

In the current draft (-02), we say that Unknown and unrecognized Frame types MUST be ignored by an endpoint. While this is ok in theory, this can be very dangerous in practice. Specifically, an attacking sender could choose to flood a recipient with a high number of junk frames that use a previously unused type code. Because of the MUST IGNORE rule, these would simply be discarded by the recipient but the damage will already have been done. Flow control actions could help mitigate the problem, but those are only partially effective.

Also, the order of processing here for error handling is not clear.

Let's say an attacker sends a HEADERS frame to the server initiating a stream. The server sends an RST_STREAM REFUSED_STREAM fully closing the stream. The attacker continues to send JUNK frames for the same stream ID. There are two conditions happening here:

1. The sender is sending frames for a closed stream, which ought to result in an RST_STREAM, but..
2. The frame type is unknown and unrecognized by the server so MUST be ignored.

Which condition takes precedence and how do we mitigate the possible attack vector on this one.

[jasnell]

Issue resolved with commit 1527cea