Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Frame types that are Protocol Violations #1107

Merged
merged 3 commits into from Feb 12, 2018
Merged

Frame types that are Protocol Violations #1107

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
60faa96
Frame types that are Protocol Violations
martinduke Feb 12, 2018
2fbc433
Update draft-ietf-quic-transport.md
martinduke Feb 12, 2018
5bb5d4b
Added handling for unopened streams
martinduke Feb 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
21 changes: 21 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1974,6 +1974,9 @@ After sending a RST_STREAM, an endpoint ceases transmission and retransmission
of STREAM frames on the identified stream. A receiver of RST_STREAM can discard
any data that it already received on that stream.

An endpoint that receives a RST_STREAM frame for a send-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.

The RST_STREAM frame is as follows:

~~~
Expand Down Expand Up @@ -2097,6 +2100,15 @@ change in the initial limits (see {{zerortt-parameters}}).
The MAX_STREAM_DATA frame (type=0x05) is used in flow control to inform a peer
of the maximum amount of data that can be sent on a stream.

An endpoint that receives a MAX_STREAM_DATA frame for a receive-only stream
MUST terminate the connection with error PROTOCOL_VIOLATION.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about when receiving MAX_STREAM_DATA on a send or bidi stream but that has not yet been opened?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MAX_STREAM_DATA is defined in the state machine as one way to open a stream.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks. But that only makes sense for bidi, or? If MAX_STREAM_DATA is received on a send stream way before the sender is ready to process it, what should it do? (I think there was some dicussion on related issues at some point).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In section 10.2.3 it says "The receiver only sends MAX_STREAM_DATA in the “Recv” state. " So I assume it would be a protocol error to send it in other states.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see now that this is for the receive end of bidirectional streams only. So for send-only streams, you're right.

However, for bidirectional streams, a node may open the stream and have that initial message be lost. Its receive direction will be in RECV (so it can send the frame) and can send MAX_STREAM_DATA, while nothing has happened at all at the peer.

An endpoint that receives a MAX_STREAM_DATA frame for a send-only stream
it has not opened MUST terminate the connection with error PROTOCOL_VIOLATION.

Note that an endpoint may legally receive a MAX_STREAM_DATA frame on a
bidirectional stream it has not opened.

The frame is as follows:

~~~
Expand Down Expand Up @@ -2225,6 +2237,9 @@ A sender SHOULD send a STREAM_BLOCKED frame (type=0x09) when it wishes to send
data, but is unable to due to stream-level flow control. This frame is
analogous to BLOCKED ({{frame-blocked}}).

An endpoint that receives a STREAM_BLOCKED frame for a send-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.

The STREAM_BLOCKED frame is as follows:

~~~
Expand Down Expand Up @@ -2328,6 +2343,9 @@ An endpoint may use a STOP_SENDING frame (type=0x0c) to communicate that
incoming data is being discarded on receipt at application request. This
signals a peer to abruptly terminate transmission on a stream.

An endpoint that receives a STOP_SENDING frame for a receive-only stream MUST
terminate the connection with error PROTOCOL_VIOLATION.

The STOP_SENDING frame is as follows:

~~~
Expand Down Expand Up @@ -2644,6 +2662,9 @@ are present in the frame.
final offset of the stream. Setting this bit indicates that the frame
marks the end of the stream.

An endpoint that receives a STREAM frame for a send-only stream MUST terminate
the connection with error PROTOCOL_VIOLATION.

A STREAM frame is shown below.

~~~
Expand Down