STOP_SENDING for lower streams on receiving out-of-order higher streams

[NErinola]

Observation

The QUIC server sends STOP_SENDING frames for all streams of the same type with lower IDs when it receives a STREAM frame with an unexpected higher ID. After the handshake, STREAM frames may legitimately arrive out-of-order. For example, if a STREAM frame with ID 4 arrives before a STREAM frame with ID 0, the server sends a STOP_SENDING frame for the stream with ID 0. This behavior is not compliant with the QUIC specification and can lead to unnecessary stream terminations under normal network conditions.

PoC

1. Complete the handshake with the server.
2. Send a 1-RTT packet containing a STREAM frame for ID 4.
3. Observe that the server sends a STOP_SENDING frame for the stream with ID 0.

Impact

• No direct security vulnerability.
• Natural packet reordering could lead to early stream termination and degraded performance.

Tested Implementation

• v1.64.0
• Example Server (Resumption)

[maddeleine]

Thanks for reporting this issue, we'll take a look.