[secdir] Re: draft-ietf-quic-reliable-stream-reset-09 ietf last call Secdir review

[Marten Seemann <[e-mail]>]

Thank you for the review!

> At the end of sec. 1: "application protocols continue to treat this stream
function as an abrupt termination". Clarifying question: is this in the
sense
that application protocol can expect no new data to be sent over this stream
?
Because "abrupt termination" doesn't seem representative of the new
behaviour
overall.

It is abrupt termination in the sense that it tells the application that
the transfer was not successful. For example, when downloading a file, you
might treat a FIN as "all the bytes I received constitute the entirety of
this file" vs. a RESET_STREAM (or RESET_STREAM_AT) as "parts of the file
were transferred, but what I received is not the complete file".

https://github.com/quicwg/reliable-stream-reset/pull/94 should make this
clearer.

> In sec. 5: "A RESET_STREAM_AT frame with this value is logically
equivalent to
a RESET_STREAM frame". I'm not sure this is consistent with the state
machine
transitions described in sec. 5.3. For example, with RESET_STREAM the state
machine is not expected to go from Recv through Size Known.

I think it is, given the following sentence in the draft:
> Once all data up to the smallest Reliable Size have been received, it
enters the "Data Recvd" state.

...which in the case of a Reliable Size of 0 is immediate. That said, I
think we can improve the wording a bit:
https://github.com/quicwg/reliable-stream-reset/pull/92

> In sec 5.3: "Conversely, if bytes below that offset still need to be sent
or
acknowledged, the transition might take multiple network roundtrips and
*might
require additional flow control credit issued by the receiver*." (emphasis
mine) It seems impossible to reach the state described at the end, requiring
additional flow control credit. In sec. 4 you note that "An endpoint MUST
NOT
send a RESET_STREAM_AT frame that exceeds the largest maximum stream data
value
advertised by the receiver for the stream, or that violates the receiver's
maximum data limit." Coupled with "If the Reliable Size is larger than the
Final Size, the receiver MUST close the connection", Reliable Size must
always
be fully accounted for in the current flow control credit.

> In sec. 5.3: "This might require the receiver to issue additional flow
control
credit." - identical reasoning to above.

The intention of this section was to say that if your application's
requirement is to send a stream header of N bytes, you're not able to send
RESET_STREAM_AT with Reliable Size N before you've received flow control
credit for at least N. I opened a PR:
https://github.com/quicwg/reliable-stream-reset/pull/93



On Wed, 29 Jul 2026 at 23:47, Ionuț Mihalcea via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-quic-reliable-stream-reset
> Title: QUIC Stream Resets with Partial Delivery
> Reviewer: Ionuț Mihalcea
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The summary of the review is Almost Ready.
>
> The draft defines a new frame for QUIC, allowing senders to reset a stream
> with
> the promise of reliable delivery for a given amount of data on said stream.
>
> The document is well written and seems comprehensive in integrating the new
> mechanism in the QUIC stream management machinery. I noticed a few
> inconsistencies (which might be due to my lack of expertise with QUIC),
> described below.
>
> At the end of sec. 1: "application protocols continue to treat this stream
> function as an abrupt termination". Clarifying question: is this in the
> sense
> that application protocol can expect no new data to be sent over this
> stream?
> Because "abrupt termination" doesn't seem representative of the new
> behaviour
> overall.
>
> In sec. 5: "A RESET_STREAM_AT frame with this value is logically
> equivalent to
> a RESET_STREAM frame". I'm not sure this is consistent with the state
> machine
> transitions described in sec. 5.3. For example, with RESET_STREAM the state
> machine is not expected to go from Recv through Size Known.
>
> In sec 5.3: "Conversely, if bytes below that offset still need to be sent
> or
> acknowledged, the transition might take multiple network roundtrips and
> *might
> require additional flow control credit issued by the receiver*." (emphasis
> mine) It seems impossible to reach the state described at the end,
> requiring
> additional flow control credit. In sec. 4 you note that "An endpoint MUST
> NOT
> send a RESET_STREAM_AT frame that exceeds the largest maximum stream data
> value
> advertised by the receiver for the stream, or that violates the receiver's
> maximum data limit." Coupled with "If the Reliable Size is larger than the
> Final Size, the receiver MUST close the connection", Reliable Size must
> always
> be fully accounted for in the current flow control credit.
>
> In sec. 5.3: "This might require the receiver to issue additional flow
> control
> credit." - identical reasoning to above.
>
> Thanks!
>
>
>