From 1ed2ef5ebca4ca82139743ea2a9eb9c778fdfe68 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 24 Apr 2017 15:32:18 +1000 Subject: [PATCH 1/9] Add proposed error codes This is just the error codes, not references to those codes. --- draft-ietf-quic-transport.md | 195 +++++++++-------------------------- 1 file changed, 50 insertions(+), 145 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 595387edce..c35c5dd6b4 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2339,7 +2339,7 @@ Stream IDs are usually encoded as a 32-bit integer, though the STREAM frame stream ID are zero. -## Life of a Stream +## Life of a Stream {#stream-states} The semantics of QUIC streams is based on HTTP/2 streams, and the lifecycle of a QUIC stream therefore closely follows that of an HTTP/2 stream {{?RFC7540}}, @@ -2812,6 +2812,10 @@ risks a peer missing the first such packet. The only mechanism available to an endpoint that continues to receive data for a terminated connection is to send a Public Reset packet. +An endpoint that receives an invalid error code in a CONNECTION_CLOSE frame MUST +NOT signal the existence of the error to its peer. It MAY treat the error as an +INTERNAL_ERROR on the basis that there is some fault with the peer. + ## Stream Errors @@ -2858,173 +2862,74 @@ CONNECTION_CLOSE or RST_STREAM frame. Error codes share a common code space. Some error codes apply only to either streams or the entire connection and have no defined semantics in the other context. -QUIC_INTERNAL_ERROR (0x80000001): -: Connection has reached an invalid state. - -QUIC_STREAM_DATA_AFTER_TERMINATION (0x80000002): -: There were data frames after the a fin or reset. - -QUIC_INVALID_PACKET_HEADER (0x80000003): -: Control frame is malformed. - -QUIC_INVALID_FRAME_DATA (0x80000004): -: Frame data is malformed. - -QUIC_MULTIPLE_TERMINATION_OFFSETS (0x80000005): -: Multiple final offset values were received on the same stream - -QUIC_STREAM_CANCELLED (0x80000006): -: The stream was cancelled - -QUIC_CLOSED_CRITICAL_STREAM (0x80000007): -: A stream that is critical to the protocol was closed. - -QUIC_MISSING_PAYLOAD (0x80000030): -: The packet contained no payload. - -QUIC_INVALID_STREAM_DATA (0x8000002E): -: STREAM frame data is malformed. - -QUIC_UNENCRYPTED_STREAM_DATA (0x8000003D): -: Received STREAM frame data is not encrypted. - -QUIC_MAYBE_CORRUPTED_MEMORY (0x80000059): -: Received a frame which is likely the result of memory corruption. - -QUIC_INVALID_RST_STREAM_DATA (0x80000006): -: RST_STREAM frame data is malformed. - -QUIC_INVALID_CONNECTION_CLOSE_DATA (0x80000007): -: CONNECTION_CLOSE frame data is malformed. - -QUIC_INVALID_GOAWAY_DATA (0x80000008): -: GOAWAY frame data is malformed. - -QUIC_INVALID_WINDOW_UPDATE_DATA (0x80000039): -: WINDOW_UPDATE frame data is malformed. - -QUIC_INVALID_BLOCKED_DATA (0x8000003A): -: BLOCKED frame data is malformed. - -QUIC_INVALID_PATH_CLOSE_DATA (0x8000004E): -: PATH_CLOSE frame data is malformed. - -QUIC_INVALID_ACK_DATA (0x80000009): -: ACK frame data is malformed. - -QUIC_INVALID_VERSION_NEGOTIATION_PACKET (0x8000000A): -: Version negotiation packet is malformed. - -QUIC_INVALID_PUBLIC_RST_PACKET (0x8000000b): -: Public RST packet is malformed. - -QUIC_DECRYPTION_FAILURE (0x8000000c): -: There was an error decrypting. - -QUIC_ENCRYPTION_FAILURE (0x8000000d): -: There was an error encrypting. - -QUIC_PACKET_TOO_LARGE (0x8000000e): -: The packet exceeded kMaxPacketSize. - -QUIC_PEER_GOING_AWAY (0x80000010): -: The peer is going away. May be a client or server. - -QUIC_INVALID_STREAM_ID (0x80000011): -: A stream ID was invalid. - -QUIC_INVALID_PRIORITY (0x80000031): -: A priority was invalid. - -QUIC_TOO_MANY_OPEN_STREAMS (0x80000012): -: Too many streams already open. - -QUIC_TOO_MANY_AVAILABLE_STREAMS (0x8000004c): -: The peer created too many available streams. - -QUIC_PUBLIC_RESET (0x80000013): -: Received public reset for this connection. - -QUIC_INVALID_VERSION (0x80000014): -: Invalid protocol version. - -QUIC_INVALID_HEADER_ID (0x80000016): -: The Header ID for a stream was too far from the previous. - -QUIC_INVALID_NEGOTIATED_VALUE (0x80000017): -: Negotiable parameter received during handshake had invalid value. +INTERNAL_ERROR (0x80000001): -QUIC_DECOMPRESSION_FAILURE (0x80000018): -: There was an error decompressing data. +: The endpoint encountered an internal error and cannot continue with the + connection. -QUIC_NETWORK_IDLE_TIMEOUT (0x80000019): -: The connection timed out due to no network activity. +ENHANCE_YOUR_CALM (0x80000002): -QUIC_HANDSHAKE_TIMEOUT (0x80000043): -: The connection timed out waiting for the handshake to complete. +: The endpoint detected that its peer is exhibiting a behavior that might be + generating excessive load. -QUIC_ERROR_MIGRATING_ADDRESS (0x8000001a): -: There was an error encountered migrating addresses. +NO_ERROR (0x80000003): -QUIC_ERROR_MIGRATING_PORT (0x80000056): -: There was an error encountered migrating port only. +: An endpoint uses this with CONNECTION_CLOSE to signal that the connection is + being closed abruptly in the absence of any error. An endpoint uses this with + RST_STREAM to signal that the stream is no longer wanted or in response to the + receipt of a RST_STREAM for that stream. -QUIC_EMPTY_STREAM_FRAME_NO_FIN (0x80000032): -: We received a STREAM_FRAME with no data and no fin flag set. +CANCELLED (0x80000004): -QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA (0x8000003b): -: The peer received too much data, violating flow control. +: An endpoint sends this with RST_STREAM to indicate that the stream is not + wanted and that no application action was taken for the stream. This error + code is not valid for use with CONNECTION_CLOSE. -QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA (0x8000003f): -: The peer sent too much data, violating flow control. +FLOW_CONTROL_ERROR (0x80000005): -QUIC_FLOW_CONTROL_INVALID_WINDOW (0x80000040): -: The peer received an invalid flow control window. +: An endpoint received more data than it permitted in its advertised data limits + (see {{flow-control}}. -QUIC_CONNECTION_IP_POOLED (0x8000003e): -: The connection has been IP pooled into an existing connection. +STREAM_ID_ERROR (0x80000006): -QUIC_TOO_MANY_OUTSTANDING_SENT_PACKETS (0x80000044): -: The connection has too many outstanding sent packets. +: An endpoint received a frame for a stream identifier that exceeded its + advertised maximum stream ID. -QUIC_TOO_MANY_OUTSTANDING_RECEIVED_PACKETS (0x80000045): -: The connection has too many outstanding received packets. +STREAM_STATE_ERROR (0x80000007): -QUIC_CONNECTION_CANCELLED (0x80000046): -: The QUIC connection has been cancelled. +: An endpoint received a frame for a stream that was not in a state that + permitted that frame (see {{stream-states}}). -QUIC_BAD_PACKET_LOSS_RATE (0x80000047): -: Disabled QUIC because of high packet loss rate. +FINAL_OFFSET_ERROR (0x80000008): -QUIC_PUBLIC_RESETS_POST_HANDSHAKE (0x80000049): -: Disabled QUIC because of too many PUBLIC_RESETs post handshake. +: An endpoint received a STREAM frame containing data that exceeded the + previously established final offset. Or an endpoint received a RST_STREAM + frame containing a final offset that was lower than the maximum offset of data + that was already received. Or an endpoint received a RST_STREAM frame + containing a different final offset to the one already established. -QUIC_TIMEOUTS_WITH_OPEN_STREAMS (0x8000004a): -: Disabled QUIC because of too many timeouts with streams open. +FRAME_FORMAT_ERROR (0x80000009): -QUIC_TOO_MANY_RTOS (0x80000055): -: QUIC timed out after too many RTOs. +: An endpoint received a frame that was badly formatted. For instance, an empty + STREAM frame that omitted the FIN flag, or an ACK frame that has more + acknowledgment ranges than the remainder of the packet could carry. -QUIC_ENCRYPTION_LEVEL_INCORRECT (0x8000002c): -: A packet was received with the wrong encryption level (i.e. it should - have been encrypted but was not.) +TRANSPORT_PARAMETER_ERROR (0x8000000A): -QUIC_VERSION_NEGOTIATION_MISMATCH (0x80000037): -: This connection involved a version negotiation which appears to have been - tampered with. +: An endpoint received transport parameters that were badly formatted, included + an invalid value, was absent even though it is mandatory, was present though + it is forbidden, or is otherwise in error. -QUIC_IP_ADDRESS_CHANGED (0x80000050): -: IP address changed causing connection close. +VERSION_NEGOTIATION_ERROR (0x8000000B): -QUIC_ADDRESS_VALIDATION_FAILURE (0x80000051): -: Client address validation failed. +: An endpoint received transport parameters that contained version negotiation + parameters that disagreed with the version negotiation that it performed. + This error code indicates a potential version downgrade attack. -QUIC_TOO_MANY_FRAME_GAPS (0x8000005d): -: Stream frames arrived too discontiguously so that stream sequencer buffer - maintains too many gaps. +PROTOCOL_VIOLATION (0x8000000C): -QUIC_TOO_MANY_SESSIONS_ON_SERVER (0x80000060): -: Connection closed because server hit max number of sessions allowed. +: An endpoint detected an error with protocol compliance that was not covered by + more specific error codes. # Security and Privacy Considerations From 27d517e94d875d78ef91f27a683d4d00f20782f8 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 24 Apr 2017 15:34:29 +1000 Subject: [PATCH 2/9] Reference error codes One interesting change here is that we don't have an error code for running out of packet numbers. If you think about this for even a few seconds, you will realize that you can't send that error code because it can't go in a packet. And that's even assuming that you manage to keep a connection alive long enough to send that many packets. At 1 million packets a second, that's almost 600 thousand years. Even if we assume that you jump 2^31 packets every time you switch between networks, and change once a minute, that's 16 thousand years. I didn't remove the parenthetical mention of QUIC_NO_ERROR because that is being removed in other pull requests. --- draft-ietf-quic-transport.md | 63 +++++++++++++++++------------------- 1 file changed, 30 insertions(+), 33 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c35c5dd6b4..e2d2af604d 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -754,9 +754,9 @@ increase by at least one after sending any packet, unless otherwise specified A QUIC endpoint MUST NOT reuse a packet number within the same connection (that is, under the same cryptographic keys). If the packet number for sending -reaches 2^64 - 1, the sender MUST close the connection by sending a -CONNECTION_CLOSE frame with the error code QUIC_SEQUENCE_NUMBER_LIMIT_REACHED -(connection termination is described in {{termination}}.) +reaches 2^64 - 1, the sender MUST close the connection without sending a +CONNECTION_CLOSE frame or any further packets; the sender MAY send a Public +Reset packet in response to further packets that it receives. To reduce the number of bits required to represent the packet number over the wire, only the least significant bits of the packet number are transmitted over @@ -1157,10 +1157,10 @@ particularly with respect to transport parameters that establish limits: A server MAY close a connection if remembered or assumed 0-RTT transport parameters cannot be supported, using an error code that is appropriate to the -specific condition. For example, a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA -might be used to indicate that exceeding flow control limits caused the error. -A client that has a connection closed due to an error condition SHOULD NOT -attempt 0-RTT when attempting to create a new connection. +specific condition. For example, a FLOW_CONTROL_ERROR might be used to indicate +that exceeding flow control limits caused the error. A client that has a +connection closed due to an error condition SHOULD NOT attempt 0-RTT when +attempting to create a new connection. ### New Transport Parameters @@ -1195,7 +1195,7 @@ The client includes two fields in the transport parameters: MUST be identical to the value that is on the packet that carries the ClientHello. A server that receives a negotiated_version that does not match the version of QUIC that is in use MUST terminate the connection with a - QUIC_VERSION_NEGOTIATION_MISMATCH error code. + VERSION_NEGOTIATION_ERROR error code. * The initial_version is the version that the client initially attempted to use. If the server did not send a version negotiation packet {{packet-version}}, @@ -1213,7 +1213,7 @@ server MUST check that it would have sent a version negotiation packet if it had received a packet with the indicated initial_version. If a server would have accepted the version included in the initial_version and the value differs from the value of negotiated_version, the server MUST terminate the connection with a -QUIC_VERSION_NEGOTIATION_MISMATCH error. +VERSION_NEGOTIATION_ERROR error. The server includes a list of versions that it would send in any version negotiation packet ({{packet-version}}) in supported_versions. This value is @@ -1222,9 +1222,9 @@ set even if it did not send a version negotiation packet. The client can validate that the negotiated_version is included in the supported_versions list and - if version negotiation was performed - that it would have selected the negotiated version. A client MUST terminate the -connection with a QUIC_VERSION_NEGOTIATION_MISMATCH error code if the +connection with a VERSION_NEGOTIATION_ERROR error code if the negotiated_version value is not included in the supported_versions list. A -client MUST terminate with a QUIC_VERSION_NEGOTIATION_MISMATCH error code if +client MUST terminate with a VERSION_NEGOTIATION_ERROR error code if version negotiation occurred but it would have selected a different version based on the value of the supported_versions list. @@ -1358,8 +1358,7 @@ protection can be delegated to the cryptographic handshake protocol, avoiding redundant protection. If integrity protection is delegated to the cryptographic handshake, an integrity failure will result in immediate cryptographic handshake failure. If integrity protection is performed by QUIC, QUIC MUST abort the -connection if the integrity check fails with a QUIC_ADDRESS_VALIDATION_FAILURE -error code. +connection if the integrity check fails with a PROTOCOL_VIOLATION error code. ## Connection Migration {#migration} @@ -1902,9 +1901,9 @@ might not increase the largest received offset. The data sent on a stream MUST NOT exceed the largest maximum stream data value advertised by the receiver. An endpoint MUST terminate a connection with a -QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it receives more data than the -largest maximum stream data that it has sent for the affected stream, unless -this is a result of a change in the initial limits (see {{zerortt-parameters}}). +FLOW_CONTROL_ERROR error if it receives more data than the largest maximum +stream data that it has sent for the affected stream, unless this is a result of +a change in the initial limits (see {{zerortt-parameters}}). ## MAX_STREAM_ID Frame {#frame-max-stream-id} @@ -1934,9 +1933,9 @@ ignored. A peer MUST NOT initiate a stream with a higher stream ID than the greatest maximum stream ID it has received. An endpoint MUST terminate a connection with -a QUIC_TOO_MANY_OPEN_STREAMS error if a peer initiates a stream with a higher -stream ID than it has sent, unless this is a result of a change in the initial -limits (see {{zerortt-parameters}}). +a STREAM_ID_ERROR error if a peer initiates a stream with a higher stream ID +than it has sent, unless this is a result of a change in the initial limits (see +{{zerortt-parameters}}). ## BLOCKED Frame {#frame-blocked} @@ -2539,9 +2538,8 @@ regardless of whether it is permitted to initiated new streams. Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a STREAM frame with an ID greater than the limit it has sent MUST treat -this as a stream error of type QUIC_TOO_MANY_OPEN_STREAMS ({{error-handling}}), -unless this is a result of a change in the initial offsets (see -{{zerortt-parameters}}). +this as a stream error of type STREAM_ID_ERROR ({{error-handling}}), unless this +is a result of a change in the initial offsets (see {{zerortt-parameters}}). A receiver MUST NOT renege on an advertisement; that is, once a receiver advertises a stream ID via a MAX_STREAM_ID frame, it MUST NOT subsequently @@ -2642,9 +2640,9 @@ smaller offset. A sender could receive MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST therefore ignore any flow control offset that does not move the window forward. -A receiver MUST close the connection with a -QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error ({{error-handling}}) if the -peer violates the advertised connection or stream data limits. +A receiver MUST close the connection with a FLOW_CONTROL_ERROR error +({{error-handling}}) if the peer violates the advertised connection or stream +data limits. A sender MUST send BLOCKED frames to indicate it has data to write but is blocked by lack of connection or stream flow control credit. BLOCKED frames are @@ -2769,13 +2767,12 @@ An endpoint MUST NOT send data on a stream at or beyond the final offset. Once a final offset for a stream is known, it cannot change. If a RST_STREAM or STREAM frame causes the final offset to change for a stream, an endpoint SHOULD -respond with a QUIC_STREAM_DATA_AFTER_TERMINATION error (see -{{error-handling}}). A receiver SHOULD treat receipt of data at or beyond the -final offset as a QUIC_STREAM_DATA_AFTER_TERMINATION error, even after a stream -is closed. Generating these errors is not mandatory, but only because -requiring that an endpoint generate these errors also means that the endpoint -needs to maintain the final offset state for closed streams, which could mean a -significant state commitment. +respond with a FINAL_OFFSET_ERROR error (see {{error-handling}}). A receiver +SHOULD treat receipt of data at or beyond the final offset as a +FINAL_OFFSET_ERROR error, even after a stream is closed. Generating these +errors is not mandatory, but only because requiring that an endpoint generate +these errors also means that the endpoint needs to maintain the final offset +state for closed streams, which could mean a significant state commitment. # Error Handling @@ -2826,7 +2823,7 @@ affected stream. Stream 0 is critical to the functioning of the entire connection. If stream 0 is closed with either a RST_STREAM or STREAM frame bearing the FIN flag, an -endpoint MUST generate a connection error of type QUIC_CLOSED_CRITICAL_STREAM. +endpoint MUST generate a connection error of type PROTOCOL_VIOLATION. Some application protocols make other streams critical to that protocol. An application protocol does not need to inform the transport that a stream is From d3dec577b0124bbd90a50a5bb5d0a6ac4f709c74 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 12 May 2017 14:49:00 +1000 Subject: [PATCH 3/9] Simplify CONNECTION_CLOSE error handling --- draft-ietf-quic-transport.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e2d2af604d..3cab65559f 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2809,9 +2809,8 @@ risks a peer missing the first such packet. The only mechanism available to an endpoint that continues to receive data for a terminated connection is to send a Public Reset packet. -An endpoint that receives an invalid error code in a CONNECTION_CLOSE frame MUST -NOT signal the existence of the error to its peer. It MAY treat the error as an -INTERNAL_ERROR on the basis that there is some fault with the peer. +An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the +existence of the error to its peer. ## Stream Errors From 870b07b28978d9876132608dbef2ab15b565b16c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 24 Apr 2017 15:32:18 +1000 Subject: [PATCH 4/9] Add proposed error codes This is just the error codes, not references to those codes. --- draft-ietf-quic-transport.md | 24 +++--------------------- 1 file changed, 3 insertions(+), 21 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3cab65559f..c66c785970 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2319,25 +2319,6 @@ similar to the way ephemeral streams are used in SST for some applications. -## Stream Identifiers {#stream-id} - -Streams are identified by an unsigned 32-bit integer, referred to as the Stream -ID. To avoid Stream ID collision, clients initiate streams using odd-numbered -Stream IDs; streams initiated by the server use even-numbered Stream IDs. - -Stream ID 0 (0x0) is reserved for the cryptographic handshake. Stream 0 MUST -NOT be used for application data, and is the first client-initiated stream. - -A QUIC endpoint cannot reuse a Stream ID. Streams MUST be created in sequential -order. Open streams can be used in any order. Streams that are used out of -order result in lower-numbered streams in the same direction being counted as -open. - -Stream IDs are usually encoded as a 32-bit integer, though the STREAM frame -({{frame-stream}}) permits a shorter encoding when the leading bits of the -stream ID are zero. - - ## Life of a Stream {#stream-states} The semantics of QUIC streams is based on HTTP/2 streams, and the lifecycle of a @@ -2809,8 +2790,9 @@ risks a peer missing the first such packet. The only mechanism available to an endpoint that continues to receive data for a terminated connection is to send a Public Reset packet. -An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the -existence of the error to its peer. +An endpoint that receives an invalid error code in a CONNECTION_CLOSE frame MUST +NOT signal the existence of the error to its peer. It MAY treat the error as an +INTERNAL_ERROR on the basis that there is some fault with the peer. ## Stream Errors From 4a513432998d45e37e67332d3134377e6cf66881 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 24 Apr 2017 15:34:29 +1000 Subject: [PATCH 5/9] Reference error codes One interesting change here is that we don't have an error code for running out of packet numbers. If you think about this for even a few seconds, you will realize that you can't send that error code because it can't go in a packet. And that's even assuming that you manage to keep a connection alive long enough to send that many packets. At 1 million packets a second, that's almost 600 thousand years. Even if we assume that you jump 2^31 packets every time you switch between networks, and change once a minute, that's 16 thousand years. I didn't remove the parenthetical mention of QUIC_NO_ERROR because that is being removed in other pull requests. --- draft-ietf-quic-transport.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index c66c785970..490ed83c38 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1114,7 +1114,9 @@ initial_max_stream_id (0x0002): : The initial maximum stream ID parameter contains the initial maximum stream number the peer may initiate, encoded as an unsigned 32-bit integer. This is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}}) immediately - after completing the handshake. + after completing the handshake. This value MUST NOT be set to 0, an endpoint + MUST generate a TRANSPORT_PARAMETER_ERROR error if it receives a value of + 0 for this parameter. idle_timeout (0x0003): From 4183871492ece12b2e62710ad82c41018622ccdc Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Thu, 11 May 2017 18:31:34 -0700 Subject: [PATCH 6/9] Restored a few error codes and redefined FRAME_ERROR. --- draft-ietf-quic-transport.md | 69 ++++++++++++++++++++++++++---------- 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 490ed83c38..257053033b 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2842,45 +2842,83 @@ CONNECTION_CLOSE or RST_STREAM frame. Error codes share a common code space. Some error codes apply only to either streams or the entire connection and have no defined semantics in the other context. -INTERNAL_ERROR (0x80000001): +FRAME_ERROR (0x800000TT): + +: An endpoint received a frame that was badly formatted. For instance, an empty + STREAM frame that omitted the FIN flag, or an ACK frame that has more + acknowledgment ranges than the remainder of the packet could carry. The final + octet of the error code carries the Type field in the offending frame. + +INTERNAL_ERROR (0x80000100): : The endpoint encountered an internal error and cannot continue with the connection. -ENHANCE_YOUR_CALM (0x80000002): +CRYPTO_STREAM_CLOSED (0x80000101): + +: A fin or a RST_STREAM was received for stream 0. + +PAYLOAD_MISSING (0x80000102): + +: Received packet contained no payload. + +HANDSHAKE_TIMEOUT (0x80000103): + +: Connection timed out waiting for the handshake to complete. + +NETWORK_IDLE_TIMEOUT (0x80000104): + +: Connection timed out due to no network activity. + +UNENCRYPTED_STREAM_DATA (0x80000105): -: The endpoint detected that its peer is exhibiting a behavior that might be - generating excessive load. +: Stream data for a stream other than 0 was received in an unprotected packet. -NO_ERROR (0x80000003): +INVALID_VERSION_NEGOTIATION_PACKET (0x80000106): + +: Version negotiation packet is malformed. + +PUBLIC_RESET_RECEIVED (0x80000107): + +: A public reset packet was received for this connection post-handshake. + +TOO_MANY_RTOS (0x80000108): + +: Connection timed out after too many retransmissions. + +ADDRESS_VALIDATION_FAILURE (0x80000109): + +: Peer's IP address validation failed. + +NO_ERROR (0x8000010A): : An endpoint uses this with CONNECTION_CLOSE to signal that the connection is being closed abruptly in the absence of any error. An endpoint uses this with RST_STREAM to signal that the stream is no longer wanted or in response to the receipt of a RST_STREAM for that stream. -CANCELLED (0x80000004): +CANCELLED (0x8000010B): : An endpoint sends this with RST_STREAM to indicate that the stream is not wanted and that no application action was taken for the stream. This error code is not valid for use with CONNECTION_CLOSE. -FLOW_CONTROL_ERROR (0x80000005): +FLOW_CONTROL_ERROR (0x8000010C): : An endpoint received more data than it permitted in its advertised data limits (see {{flow-control}}. -STREAM_ID_ERROR (0x80000006): +STREAM_ID_ERROR (0x8000010D): : An endpoint received a frame for a stream identifier that exceeded its advertised maximum stream ID. -STREAM_STATE_ERROR (0x80000007): +STREAM_STATE_ERROR (0x8000010E): : An endpoint received a frame for a stream that was not in a state that permitted that frame (see {{stream-states}}). -FINAL_OFFSET_ERROR (0x80000008): +FINAL_OFFSET_ERROR (0x8000010F): : An endpoint received a STREAM frame containing data that exceeded the previously established final offset. Or an endpoint received a RST_STREAM @@ -2888,25 +2926,20 @@ FINAL_OFFSET_ERROR (0x80000008): that was already received. Or an endpoint received a RST_STREAM frame containing a different final offset to the one already established. -FRAME_FORMAT_ERROR (0x80000009): - -: An endpoint received a frame that was badly formatted. For instance, an empty - STREAM frame that omitted the FIN flag, or an ACK frame that has more - acknowledgment ranges than the remainder of the packet could carry. -TRANSPORT_PARAMETER_ERROR (0x8000000A): +TRANSPORT_PARAMETER_ERROR (0x80000110): : An endpoint received transport parameters that were badly formatted, included an invalid value, was absent even though it is mandatory, was present though it is forbidden, or is otherwise in error. -VERSION_NEGOTIATION_ERROR (0x8000000B): +VERSION_NEGOTIATION_ERROR (0x80000111): : An endpoint received transport parameters that contained version negotiation parameters that disagreed with the version negotiation that it performed. This error code indicates a potential version downgrade attack. -PROTOCOL_VIOLATION (0x8000000C): +PROTOCOL_VIOLATION (0x800001FF): : An endpoint detected an error with protocol compliance that was not covered by more specific error codes. From 9a501beab3d27160501641a6ba7c471453d7065a Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 12 May 2017 15:28:02 -0700 Subject: [PATCH 7/9] fix broken things during rebase --- draft-ietf-quic-transport.md | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 257053033b..4a2af9a3e8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1114,9 +1114,7 @@ initial_max_stream_id (0x0002): : The initial maximum stream ID parameter contains the initial maximum stream number the peer may initiate, encoded as an unsigned 32-bit integer. This is equivalent to sending a MAX_STREAM_ID ({{frame-max-stream-id}}) immediately - after completing the handshake. This value MUST NOT be set to 0, an endpoint - MUST generate a TRANSPORT_PARAMETER_ERROR error if it receives a value of - 0 for this parameter. + after completing the handshake. idle_timeout (0x0003): @@ -2321,6 +2319,24 @@ similar to the way ephemeral streams are used in SST for some applications. +Stream Identifiers {#stream-id} + +Streams are identified by an unsigned 32-bit integer, referred to as the Stream +ID. To avoid Stream ID collision, clients initiate streams using odd-numbered +Stream IDs; streams initiated by the server use even-numbered Stream IDs. + +Stream ID 0 (0x0) is reserved for the cryptographic handshake. Stream 0 MUST NOT +be used for application data, and is the first client-initiated stream. + +A QUIC endpoint cannot reuse a Stream ID. Streams MUST be created in sequential +order. Open streams can be used in any order. Streams that are used out of order +result in lower-numbered streams in the same direction being counted as open. + +Stream IDs are usually encoded as a 32-bit integer, though the STREAM frame +({{frame-stream}}) permits a shorter encoding when the leading bits of the +stream ID are zero. + + ## Life of a Stream {#stream-states} The semantics of QUIC streams is based on HTTP/2 streams, and the lifecycle of a @@ -2792,10 +2808,8 @@ risks a peer missing the first such packet. The only mechanism available to an endpoint that continues to receive data for a terminated connection is to send a Public Reset packet. -An endpoint that receives an invalid error code in a CONNECTION_CLOSE frame MUST -NOT signal the existence of the error to its peer. It MAY treat the error as an -INTERNAL_ERROR on the basis that there is some fault with the peer. - +An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the +existence of the error to its peer. ## Stream Errors From e407ba73b275961442f47dd4a6bfc393339aa2d4 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 12 May 2017 15:30:08 -0700 Subject: [PATCH 8/9] fix broken things during rebase --- draft-ietf-quic-transport.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4a2af9a3e8..ad49f68531 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2319,18 +2319,19 @@ similar to the way ephemeral streams are used in SST for some applications. -Stream Identifiers {#stream-id} +## Stream Identifiers {#stream-id} Streams are identified by an unsigned 32-bit integer, referred to as the Stream -ID. To avoid Stream ID collision, clients initiate streams using odd-numbered +ID. To avoid Stream ID collision, clients initiate streams using odd-numbered Stream IDs; streams initiated by the server use even-numbered Stream IDs. -Stream ID 0 (0x0) is reserved for the cryptographic handshake. Stream 0 MUST NOT -be used for application data, and is the first client-initiated stream. +Stream ID 0 (0x0) is reserved for the cryptographic handshake. Stream 0 MUST +NOT be used for application data, and is the first client-initiated stream. A QUIC endpoint cannot reuse a Stream ID. Streams MUST be created in sequential -order. Open streams can be used in any order. Streams that are used out of order -result in lower-numbered streams in the same direction being counted as open. +order. Open streams can be used in any order. Streams that are used out of +order result in lower-numbered streams in the same direction being counted as +open. Stream IDs are usually encoded as a 32-bit integer, though the STREAM frame ({{frame-stream}}) permits a shorter encoding when the leading bits of the @@ -2811,6 +2812,7 @@ Public Reset packet. An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the existence of the error to its peer. + ## Stream Errors If the error affects a single stream, but otherwise leaves the connection in a From 875675b9da255aedbe67f8edf43da087927f1a5b Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Fri, 12 May 2017 15:30:57 -0700 Subject: [PATCH 9/9] fix broken things during rebase --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index ad49f68531..3902a2d6ff 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2328,7 +2328,7 @@ Stream IDs; streams initiated by the server use even-numbered Stream IDs. Stream ID 0 (0x0) is reserved for the cryptographic handshake. Stream 0 MUST NOT be used for application data, and is the first client-initiated stream. -A QUIC endpoint cannot reuse a Stream ID. Streams MUST be created in sequential +A QUIC endpoint cannot reuse a Stream ID. Streams MUST be created in sequential order. Open streams can be used in any order. Streams that are used out of order result in lower-numbered streams in the same direction being counted as open.