From 5b2d342317ebf6d57ae094139f1f9dc93c2a4fec Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 14:57:10 +1000 Subject: [PATCH 01/19] Split error code space This creates two orthogonal spaces for error codes. Application error codes can be used for both connection and stream errors and are under the control of the application protocol. Transport error codes are QUIC-controlled, but can only terminate the connection. To fix this, I had to add IANA considerations for error codes, plus a few extra tweaks. I think that the error code space could be narrowed to 16 bits after this, if only to keep things sane. Closes #132. --- draft-ietf-quic-tls.md | 41 ++++-- draft-ietf-quic-transport.md | 251 ++++++++++++++++++++++------------- 2 files changed, 183 insertions(+), 109 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index eff99dfe85..d564200b47 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1505,11 +1505,13 @@ SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack. -# Error codes {#errors} +# Error Codes {#errors} -The portion of the QUIC error code space allocated for the crypto handshake is -0xC0000000-0xFFFFFFFF. The following error codes are defined when TLS is used -for the crypto handshake: +This document defines error codes from the error code space used in +{{QUIC-TRANSPORT}}. To avoid collisions, these codes are defined in the range +0xC0000000-0xFFFFFFFF. + +The following error codes are defined when TLS is used for the crypto handshake: TLS_HANDSHAKE_FAILED (0xC000001C): : The TLS handshake failed. @@ -1523,24 +1525,35 @@ TLS_FATAL_ALERT_RECEIVED (0xC000001E): # IANA Considerations -This document does not create any new IANA registries, but it does utilize the -following registries: +This document does not create any new IANA registries, but it registers the +values in the following registries: -* QUIC Transport Parameter Registry - IANA is to register the three values found - in {{errors}}. +* QUIC Transport Error Codes Registry {{QUIC-TRANSPORT}} - IANA is to register + the three error codes found in {{errors}}, these are summarized in + {{iana-errors}}. -* TLS ExtensionsType Registry - IANA is to register the - quic_transport_parameters extension found in {{quic_parameters}}. Assigning - 26 to the extension would be greatly appreciated. The Recommended column is - to be marked Yes. +* TLS ExtensionsType Registry + {{!TLS-REGISTRIES=I-D.ietf-tls-iana-registry-updates}} - IANA is to register + the quic_transport_parameters extension found in {{quic_parameters}}. + Assigning 26 to the extension would be greatly appreciated. The Recommended + column is to be marked Yes. -* TLS Exporter Label Registry - IANA is requested to register - "EXPORTER-QUIC 0-RTT Secret" from {{zero-rtt-secrets}}; +* TLS Exporter Label Registry {{!TLS-REGISTRIES}} - IANA is requested to + register "EXPORTER-QUIC 0-RTT Secret" from {{zero-rtt-secrets}}; "EXPORTER-QUIC client 1-RTT Secret" and "EXPORTER-QUIC server 1-RTT Secret" from {{one-rtt-secrets}}; "EXPORTER-QUIC Packet Number Secret" {{packet-number-gaps}}. The DTLS column is to be marked No. The Recommended column is to be marked Yes. +| Value | Error | Description | Specification | +|:-----------|:--------------------------|:--------------| +| 0xC000001C | TLS_HANDSHAKE_FAILED | {{errors}} | +| 0xC000001D | TLS_FATAL_ALERT_GENERATED | {{errors}} | +| 0xC000001E | TLS_FATAL_ALERT_RECEIVED | {{errors}} | +{: #iana-errors title="QUIC Transport Error Codes for TLS"} + + + --- back # Contributors diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 1e0482ca07..483bf91593 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -845,7 +845,8 @@ explained in more detail as they are referenced later in the document. |:------------|:------------------|:----------------------------| | 0x00 | PADDING | {{frame-padding}} | | 0x01 | RST_STREAM | {{frame-rst-stream}} | -| 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | +| 0x02 | TRANSPORT_CLOSE | {{frame-transport-close}} | +| 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | | 0x04 | MAX_DATA | {{frame-max-data}} | | 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | | 0x06 | MAX_STREAM_ID | {{frame-max-stream-id}} | @@ -1497,19 +1498,19 @@ signal the timeout using an immediate close. ### Immediate Close -An endpoint sends a CONNECTION_CLOSE frame to terminate the connection -immediately. A CONNECTION_CLOSE causes all open streams to immediately become -closed; open streams can be assumed to be implicitly reset. After sending or -receiving a CONNECTION_CLOSE frame, endpoints immediately enter a draining -period. +An endpoint sends a CONNECTION_CLOSE or APPLICATION_CLOSE frame to terminate the +connection immediately. Either frame causes all open streams to immediately +become closed; open streams can be assumed to be implicitly reset. After +sending or receiving a CONNECTION_CLOSE frame, endpoints immediately enter a +draining period. -During the draining period, an endpoint that sends a CONNECTION_CLOSE frame -SHOULD respond to any subsequent packet that it receives with another packet -containing a CONNECTION_CLOSE frame. To reduce the state that an endpoint -maintains in this case, it MAY send the exact same packet. However, endpoints -SHOULD limit the number of CONNECTION_CLOSE messages they generate. For -instance, an endpoint could progressively increase the number of packets that it -receives before sending additional CONNECTION_CLOSE frames. +During the draining period, an endpoint that sends a CONNECTION_CLOSE or +APPLICATION_CLOSE frame SHOULD respond to any subsequent packet that it receives +with another packet containing either close frame. To reduce the state that an +endpoint maintains in this case, it MAY send the exact same packet. However, +endpoints SHOULD limit the number of packets they generate containing either +close frame. For instance, an endpoint could progressively increase the number +of packets that it receives before sending additional packets. Note: @@ -1519,9 +1520,9 @@ Note: control, which are not expected to be relevant for a closed connection. Retransmitting the final packet requires less state. -An endpoint can cease sending CONNECTION_CLOSE frames if it receives either a -CONNECTION_CLOSE or an acknowledgement for a packet that contained a -CONNECTION_CLOSE. +An endpoint can cease sending CONNECTION_CLOSE or APPLICATION_CLOSE frames if it +receives either a CONNECTION_CLOSE, APPLICATION_CLOSE or an acknowledgement for +a packet that contained a either close frame. ### Stateless Reset {#stateless-reset} @@ -1530,7 +1531,8 @@ A stateless reset is provided as an option of last resort for a server that does not have access to the state of a connection. A server crash or outage might result in clients continuing to send data to a server that is unable to properly continue the connection. A server that wishes to communicate a fatal connection -error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so. +error MUST use a TRANSPORT_CLOSE or APPLICATION_CLOSE frame if it has sufficient +state to do so. To support this process, the server sends a stateless_reset_token value during the handshake in the transport parameters. This value is protected by @@ -1584,7 +1586,7 @@ indistinguishable from a regular packet. A stateless reset is not appropriate for signaling error conditions. An endpoint that wishes to communicate a fatal connection error MUST use a -CONNECTION_CLOSE frame if it has sufficient state to do so. +TRANSPORT_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so. #### Detecting a Stateless Reset @@ -1670,7 +1672,7 @@ The RST_STREAM frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| Application Protocol Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Final Offset (64) + @@ -1684,43 +1686,51 @@ Stream ID: : The 32-bit Stream ID of the stream being terminated. -Error code: +Application Protocol Error Code: -: A 32-bit error code which indicates why the stream is being closed. +: A 32-bit application protocol error code (see {{app-error-codes}}) which + indicates why the stream is being closed. -Final offset: +Final Offset: : A 64-bit unsigned integer indicating the absolute byte offset of the end of data written on this stream by the RST_STREAM sender. -## CONNECTION_CLOSE frame {#frame-connection-close} +## TRANSPORT_CLOSE frame {#frame-transport-close} -An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its peer that -the connection is being closed. If there are open streams that haven't been -explicitly closed, they are implicitly closed when the connection is closed. -The frame is as follows: +An endpoint sends a TRANSPORT_CLOSE frame (type=0x02) to notify its peer that +the connection is being closed. TRANSPORT_CLOSE is used to signal errors at the +QUIC layer, or the absence of errors (with the NO_ERROR code). + +If there are open streams that haven't been explicitly closed, they are +implicitly closed when the connection is closed. + +The TRANSPORT_CLOSE frame is as follows: ~~~ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason Phrase Length (16) | [Reason Phrase (*)] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ -The fields of a CONNECTION_CLOSE frame are as follows: +The fields of a TRANSPORT_CLOSE frame are as follows: Error Code: : A 32-bit error code which indicates the reason for closing this connection. + TRANSPORT_CLOSE uses codes from the space defined in {{error-codes}}; + APPLICATION_CLOSE uses codes from the application protocol error code space + ({{app-error-codes}}). Reason Phrase Length: : A 16-bit unsigned number specifying the length of the reason phrase in bytes. - Note that a CONNECTION_CLOSE frame cannot be split between packets, so in + Note that a TRANSPORT_CLOSE frame cannot be split between packets, so in practice any limits on packet size will also limit the space available for a reason phrase. @@ -1731,6 +1741,17 @@ Reason Phrase: This SHOULD be a UTF-8 encoded string {{!RFC3629}}. +## APPLICATION_CLOSE frame {#frame-application-close} + +An APPLICATION_CLOSE frame (type=0x03) uses the same format as the +TRANSPORT_CLOSE frame ({{frame-transport-close}}), except that it uses error +codes from the application protocol error code space ({{app-error-codes}}) +instead of the transport error code space. + +Other than the error code space, the format and semantics of the +APPLICATION_CLOSE frame are identical to the TRANSPORT_CLOSE frame. + + ## MAX_DATA Frame {#frame-max-data} The MAX_DATA frame (type=0x04) is used in flow control to inform the peer of @@ -2702,11 +2723,10 @@ discarded upon receipt. This avoids potential ambiguity about which STREAM frames count toward flow control. Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed -(remote)" states, an endpoint MUST send a RST_STREAM with an error code of -QUIC_RECEIVED_RST. If the STOP_SENDING frame is received on a stream that is -already in the "half-closed (local)" or "closed" states, a RST_STREAM frame MAY -still be sent in order to cancel retransmission of previously-sent STREAM -frames. +(remote)" states, an endpoint MUST send a RST_STREAM frame. If the STOP_SENDING +frame is received on a stream that is already in the "half-closed (local)" or +"closed" states, a RST_STREAM frame MAY still be sent in order to cancel +retransmission of previously-sent STREAM frames. While STOP_SENDING frames are retransmittable, an implementation MAY choose not to retransmit a lost STOP_SENDING frame if the stream has already been closed @@ -2980,32 +3000,39 @@ frame that signals the error. Where this specification identifies error conditions, it also identifies the error code that is used. A stateless reset ({{stateless-reset}}) is not suitable for any error that can -be signaled with a CONNECTION_CLOSE or RST_STREAM frame. A stateless reset MUST -NOT be used by an endpoint that has the state necessary to send a frame on the -connection. +be signaled with a TRANSPORT_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame. A +stateless reset MUST NOT be used by an endpoint that has the state necessary to +send a frame on the connection. ## Connection Errors Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire -connection, MUST be signaled using a CONNECTION_CLOSE frame -({{frame-connection-close}}). An endpoint MAY close the connection in this -manner, even if the error only affects a single stream. +connection, MUST be signaled using a TRANSPORT_CLOSE or APPLICATION_CLOSE frame +({{frame-transport-close}}, {{frame-application-close}}). An endpoint MAY close +the connection in this manner, even if the error only affects a single stream. -A CONNECTION_CLOSE frame could be sent in a packet that is lost. An endpoint -SHOULD be prepared to retransmit a packet containing a CONNECTION_CLOSE frame if -it receives more packets on a terminated connection. Limiting the number of -retransmissions and the time over which this final packet is sent limits the -effort expended on terminated connections. +Application protocols can signal application-specific protocol errors using the +APPLICATION_CLOSE frame. Errors that are specific to the transport, including +all those described in this document, are carried in a TRANSPORT_CLOSE frame. +Other than the type of error code they carry, these frames are identical in +format and semantics. -An endpoint that chooses not to retransmit packets containing CONNECTION_CLOSE -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 use -the stateless reset process ({{stateless-reset}}). +A TRANSPORT_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is +lost. An endpoint SHOULD be prepared to retransmit a packet containing either +frame type if it receives more packets on a terminated connection. Limiting the +number of retransmissions and the time over which this final packet is sent +limits the effort expended on terminated connections. -An endpoint that receives an invalid CONNECTION_CLOSE frame MUST NOT signal the -existence of the error to its peer. +An endpoint that chooses not to retransmit packets containing TRANSPORT_CLOSE or +APPLICATION_CLOSE 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 use the stateless reset process +({{stateless-reset}}). + +An endpoint that receives an invalid TRANSPORT_CLOSE or APPLICATION_CLOSE frame +MUST NOT signal the existence of the error to its peer. ## Stream Errors @@ -3019,58 +3046,34 @@ 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 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 -critical; it can instead generate appropriate errors in response to being -notified that the critical stream is closed. - -An endpoint MAY send a RST_STREAM frame in the same packet as a CONNECTION_CLOSE -frame. - +A stream error is always an application-layer construct. A RST_STREAM MUST NOT +be generated by the QUIC transport layer. Resetting a stream at the transport +layer could cause unrecoverable loss of application protocol state. Application +protocols might require certain streams to be reliably delivered in order to +guarantee consistent state between endpoints. For this reason, all errors that +can be detected at the transport layer result in connection errors. -## Error Codes +An endpoint that detects a stream error MAY choose to treat the error as a +connection error and send an APPLICATION_CLOSE frame in place of RST_STREAM. -Error codes are 32 bits long, with the first two bits indicating the source of -the error code: -0x00000000-0x3FFFFFFF: -: Application-specific error codes. Defined by each application-layer protocol. +## Transport Error Codes {#error-codes} -0x40000000-0x7FFFFFFF: -: Reserved for host-local error codes. These codes MUST NOT be sent to a peer, - but MAY be used in API return codes and logs. - -0x80000000-0xBFFFFFFF: -: QUIC transport error codes, including packet protection errors. Applicable to - all uses of QUIC. - -0xC0000000-0xFFFFFFFF: -: Cryptographic error codes. Defined by the cryptographic handshake protocol - in use. +Transport error codes are 32 bits long. This section lists the defined QUIC transport error codes that may be used in a -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. +TRANSPORT_CLOSE frame. These errors apply to the entire connection. NO_ERROR (0x80000000): -: 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. +: An endpoint uses this with TRANSPORT_CLOSE to signal that the connection is + being closed abruptly in the absence of any error. INTERNAL_ERROR (0x80000001): : The endpoint encountered an internal error and cannot continue with the connection. -CANCELLED (0x80000002): - -: 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 (0x80000003): : An endpoint received more data than it permitted in its advertised data limits @@ -3119,10 +3122,6 @@ PROTOCOL_VIOLATION (0x8000000A): : An endpoint detected an error with protocol compliance that was not covered by more specific error codes. -QUIC_RECEIVED_RST (0x80000035): - -: Terminating stream because peer sent a RST_STREAM or STOP_SENDING. - FRAME_ERROR (0x800001XX): : An endpoint detected an error in a specific frame type. The frame type is @@ -3130,6 +3129,18 @@ FRAME_ERROR (0x800001XX): MAX_STREAM_ID frame would be indicated with the code (0x80000106). +## Application Protocol Error Codes {#app-error-codes} + +Application protocol error codes are 32-bits long, but the management of +application error codes are left to application protocols. Application protocol +error codes are used for the RST_STREAM ({{frame-rst-stream}}) and +APPLICATION_CLOSE ({{frame-application-close}}) frames. + +Application protocols SHOULD define an error codes for use when sending a +RST_STREAM in response to a STOP_SENDING frame. Otherwise, there is no +restriction on the use of the 32-bit error code space for application protocols. + + # Security and Privacy Considerations ## Spoofed ACK Attack @@ -3248,8 +3259,7 @@ accessible. The expert(s) are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing, or architecturally dubious). -The initial contents of this registry are shown in -{{iana-tp-table}}. +The initial contents of this registry are shown in {{iana-tp-table}}. | Value | Parameter Name | Specification | |:-------|:------------------------|:------------------------------------| @@ -3263,6 +3273,57 @@ The initial contents of this registry are shown in {: #iana-tp-table title="Initial QUIC Transport Parameters Entries"} +## QUIC Transport Error Codes Registry {#iana-error-codes} + +IANA \[SHALL add/has added] a registry for "QUIC Transport Error Codes" under a +"QUIC Protocol" heading. + +The "QUIC Transport Error Codes" registry governs a 32-bit space. This space is +split into two spaces that are governed by different policies. Values with the +first byte in the range 0x00 to 0xfe (in hexadecimal) are assigned via the +Specification Required policy {{!RFC5226}}. Values with the first byte 0xff are +reserved for Private Use {{!RFC5226}}. + +Registrations MUST include the following fields: + +Value: + +: The numeric value of the assignment (registrations will be between 0x00000000 + and 0xfeffffff). + +Code: + +: A short mnemonic for the parameter. + +Description: + +: A brief description of the error code semantics, which MAY be a summary if a + specification reference is provided. + +Specification: + +: A reference to a publicly available specification for the value. + +The initial contents of this registry are shown in {{iana-error-table}}. Note +that FRAME_ERROR takes the range from 0x80000100 to 0x800001ff and private use +occupies the range from 0xfe000000 to 0xffffffff. + +| Value | Error | Description | Specification | +|:------------|:--------------------------|:------------------------------|:----------------| +| 0x0 | NO_ERROR | No error | {{error-codes}} | +| 0x1 | INTERNAL_ERROR | Implementation error | {{error-codes}} | +| 0x3 | FLOW_CONTROL_ERROR | Flow control error | {{error-codes}} | +| 0x4 | STREAM_ID_ERROR | Invalid stream ID | {{error-codes}} | +| 0x5 | STREAM_STATE_ERROR | Frame received in invalid stream state | {{error-codes}} | +| 0x6 | FINAL_OFFSET_ERROR | Change to final stream offset | {{error-codes}} | +| 0x7 | FRAME_FORMAT_ERROR | Generic frame format error | {{error-codes}} | +| 0x8 | TRANSPORT_PARAMETER_ERROR | Error in transport parameters | {{error-codes}} | +| 0x9 | VERSION_NEGOTIATION_ERROR | Version negotiation failure | {{error-codes}} | +| 0xA | PROTOCOL_VIOLATION | Generic protocol violation | {{error-codes}} | +| 0x100-0x1FF | FRAME_ERROR | Specific frame format error | {{error-codes}} | +{: #iana-error-table title="Initial QUIC Transport Error Codes Entries"} + + --- back # Contributors From 9bfaa6c0c352b47f101ce4f8822bdf1dbda1f8d9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:00:56 +1000 Subject: [PATCH 02/19] s/Public Reset/Stateless Reset/ --- draft-ietf-quic-transport.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 483bf91593..423d67bebf 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1490,10 +1490,19 @@ A connection that remains idle for longer than the idle timeout (see connection state if they have neither sent nor received a packet for this time. The time at which an idle timeout takes effect won't be perfectly synchronized +<<<<<<< HEAD on peers. A connection enters the draining period when the idle timeout expires. During this time, an endpoint that receives new packets MAY choose to restore the connection. Alternatively, an endpoint that receives packets MAY signal the timeout using an immediate close. +======= +on peers. Endpoints might allow for the possibility that the remote side might +attempt to send packets before the timeout. In this case, an endpoint might +choose to retain enough information to generate a packet containing +TRANSPORT_CLOSE (see {{immediate-close}}). Endpoints MAY instead rely on +sending Stateless Reset in response to packets that arrive after an idle +timeout. +>>>>>>> s/Public Reset/Stateless Reset/ ### Immediate Close From ba3e0742b4901e593f30a7dcc45ae25042294d8f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:07:10 +1000 Subject: [PATCH 03/19] Get codes consistent --- draft-ietf-quic-transport.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 423d67bebf..97d6d8fbc8 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3073,32 +3073,32 @@ Transport error codes are 32 bits long. This section lists the defined QUIC transport error codes that may be used in a TRANSPORT_CLOSE frame. These errors apply to the entire connection. -NO_ERROR (0x80000000): +NO_ERROR (0x0): : An endpoint uses this with TRANSPORT_CLOSE to signal that the connection is being closed abruptly in the absence of any error. -INTERNAL_ERROR (0x80000001): +INTERNAL_ERROR (0x1): : The endpoint encountered an internal error and cannot continue with the connection. -FLOW_CONTROL_ERROR (0x80000003): +FLOW_CONTROL_ERROR (0x3): : An endpoint received more data than it permitted in its advertised data limits (see {{flow-control}}). -STREAM_ID_ERROR (0x80000004): +STREAM_ID_ERROR (0x4): : An endpoint received a frame for a stream identifier that exceeded its advertised maximum stream ID. -STREAM_STATE_ERROR (0x80000005): +STREAM_STATE_ERROR (0x5): : An endpoint received a frame for a stream that was not in a state that permitted that frame (see {{stream-states}}). -FINAL_OFFSET_ERROR (0x80000006): +FINAL_OFFSET_ERROR (0x6): : An endpoint received a STREAM frame containing data that exceeded the previously established final offset. Or an endpoint received a RST_STREAM @@ -3106,36 +3106,36 @@ FINAL_OFFSET_ERROR (0x80000006): 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 (0x80000007): +FRAME_FORMAT_ERROR (0x7): : 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. This is a generic error code; an endpoint SHOULD use the more specific frame format - error codes (0x800001XX) if possible. + error codes (0x1XX) if possible. -TRANSPORT_PARAMETER_ERROR (0x80000008): +TRANSPORT_PARAMETER_ERROR (0x8): : 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 (0x80000009): +VERSION_NEGOTIATION_ERROR (0x9): : 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 (0x8000000A): +PROTOCOL_VIOLATION (0xA): : An endpoint detected an error with protocol compliance that was not covered by more specific error codes. -FRAME_ERROR (0x800001XX): +FRAME_ERROR (0x1XX): : An endpoint detected an error in a specific frame type. The frame type is included as the last octet of the error code. For example, an error in a - MAX_STREAM_ID frame would be indicated with the code (0x80000106). + MAX_STREAM_ID frame would be indicated with the code (0x106). ## Application Protocol Error Codes {#app-error-codes} @@ -3314,8 +3314,8 @@ Specification: : A reference to a publicly available specification for the value. The initial contents of this registry are shown in {{iana-error-table}}. Note -that FRAME_ERROR takes the range from 0x80000100 to 0x800001ff and private use -occupies the range from 0xfe000000 to 0xffffffff. +that FRAME_ERROR takes the range from 0x100 to 0x1FF and private use occupies +the range from 0XFE000000 to 0XFFFFFFFF. | Value | Error | Description | Specification | |:------------|:--------------------------|:------------------------------|:----------------| From 3663e684e5b117684891cbb8d0aad17120c5fb65 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:15:17 +1000 Subject: [PATCH 04/19] Make STOP_SENDING application-specific as well --- draft-ietf-quic-transport.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 97d6d8fbc8..d38c3b9a32 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1681,7 +1681,7 @@ The RST_STREAM frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Application Protocol Error Code (32) | +| App Protocol Error Code (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Final Offset (64) + @@ -2002,7 +2002,7 @@ follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Error Code (32) | +| App Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ @@ -2011,8 +2011,9 @@ The fields are: Stream ID: : The 32-bit Stream ID of the stream being ignored. -Error Code: -: The application-specified reason the sender is ignoring the stream. +App Error Code: +: A 32-bit, application-specified reason the sender is ignoring the stream (see + {{app-error-codes}}). ## ACK Frame {#frame-ack} @@ -3137,6 +3138,8 @@ FRAME_ERROR (0x1XX): included as the last octet of the error code. For example, an error in a MAX_STREAM_ID frame would be indicated with the code (0x106). +See {{iana-error-codes}} for details of registering new error codes. + ## Application Protocol Error Codes {#app-error-codes} @@ -3145,9 +3148,10 @@ application error codes are left to application protocols. Application protocol error codes are used for the RST_STREAM ({{frame-rst-stream}}) and APPLICATION_CLOSE ({{frame-application-close}}) frames. -Application protocols SHOULD define an error codes for use when sending a -RST_STREAM in response to a STOP_SENDING frame. Otherwise, there is no -restriction on the use of the 32-bit error code space for application protocols. +Application protocols SHOULD define an error codes for indicating no error and +for use when sending a RST_STREAM in response to a STOP_SENDING frame. +Otherwise, there is no restriction on the use of the 16-bit error code space for +application protocols. # Security and Privacy Considerations From 1abd960838a9d0c995cd5af7ec3dcf5a4fc9e084 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:16:25 +1000 Subject: [PATCH 05/19] Split errors in HTTP too --- draft-ietf-quic-http.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 180452b952..7c7c69d70d 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -872,16 +872,15 @@ establishment to servers. QUIC allows the application to abruptly terminate (reset) individual streams or the entire connection when an error is encountered. These are referred to as "stream errors" or "connection errors" and are described in more detail in -[QUIC-TRANSPORT]. +{{QUIC-TRANSPORT}}. This section describes HTTP-specific error codes which can be used to express the cause of a connection or stream error. ## HTTP-Defined QUIC Error Codes {#http-error-codes} -QUIC allocates error codes 0x0000-0x3FFF to application protocol definition. The -following error codes are defined by HTTP for use in QUIC RST_STREAM and -CONNECTION_CLOSE frames. +The following error codes are defined by HTTP for use in QUIC RST_STREAM and +APPLICATION_CLOSE frames. HTTP_PUSH_REFUSED (0x01): : The server has attempted to push content which the client will not accept @@ -1270,7 +1269,7 @@ The entries in the following table are registered by this document. ## Error Codes {#iana-error-codes} This document establishes a registry for HTTP/QUIC error codes. The -"HTTP/QUIC Error Code" registry manages a 30-bit space. The "HTTP/QUIC +"HTTP/QUIC Error Code" registry manages a 32-bit space. The "HTTP/QUIC Error Code" registry operates under the "Expert Review" policy {{?RFC5226}}. @@ -1285,7 +1284,7 @@ Name: : A name for the error code. Specifying an error code name is optional. Code: -: The 30-bit error code value. +: The 32-bit error code value. Description: : A brief description of the error code semantics, longer if no detailed From 30661ba8543ad95f3897a08484f1fc3955ed2362 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:18:39 +1000 Subject: [PATCH 06/19] Refine description of HTTP codes --- draft-ietf-quic-http.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 7c7c69d70d..4a4e2d4905 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -877,10 +877,10 @@ the entire connection when an error is encountered. These are referred to as This section describes HTTP-specific error codes which can be used to express the cause of a connection or stream error. -## HTTP-Defined QUIC Error Codes {#http-error-codes} +## HTTP/QUIC Error Codes {#http-error-codes} -The following error codes are defined by HTTP for use in QUIC RST_STREAM and -APPLICATION_CLOSE frames. +The following error codes are defined for use in QUIC RST_STREAM and +APPLICATION_CLOSE frames when using HTTP/QUIC. HTTP_PUSH_REFUSED (0x01): : The server has attempted to push content which the client will not accept From 7514803a195b0f75e59e4984c101dccbb98c4221 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:21:00 +1000 Subject: [PATCH 07/19] Move TLS errors closer --- draft-ietf-quic-tls.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index d564200b47..fd4cfea7e7 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1508,18 +1508,17 @@ packets as indicative of an attack. # Error Codes {#errors} This document defines error codes from the error code space used in -{{QUIC-TRANSPORT}}. To avoid collisions, these codes are defined in the range -0xC0000000-0xFFFFFFFF. +{{QUIC-TRANSPORT}}. The following error codes are defined when TLS is used for the crypto handshake: -TLS_HANDSHAKE_FAILED (0xC000001C): +TLS_HANDSHAKE_FAILED (0x201): : The TLS handshake failed. -TLS_FATAL_ALERT_GENERATED (0xC000001D): +TLS_FATAL_ALERT_GENERATED (0x202): : A TLS fatal alert was sent, causing the TLS connection to end prematurely. -TLS_FATAL_ALERT_RECEIVED (0xC000001E): +TLS_FATAL_ALERT_RECEIVED (0x203): : A TLS fatal alert was received, causing the TLS connection to end prematurely. @@ -1545,11 +1544,11 @@ values in the following registries: {{packet-number-gaps}}. The DTLS column is to be marked No. The Recommended column is to be marked Yes. -| Value | Error | Description | Specification | -|:-----------|:--------------------------|:--------------| -| 0xC000001C | TLS_HANDSHAKE_FAILED | {{errors}} | -| 0xC000001D | TLS_FATAL_ALERT_GENERATED | {{errors}} | -| 0xC000001E | TLS_FATAL_ALERT_RECEIVED | {{errors}} | +| Value | Error | Description | Specification | +|:------|:--------------------------|:----------------------|:--------------| +| 0x201 | TLS_HANDSHAKE_FAILED | TLS handshake failure | {{errors}} | +| 0x202 | TLS_FATAL_ALERT_GENERATED | Sent TLS alert | {{errors}} | +| 0x203 | TLS_FATAL_ALERT_RECEIVED | Receives TLS alert | {{errors}} | {: #iana-errors title="QUIC Transport Error Codes for TLS"} From ec4c9ad273369bc8674c347ce98e154e3e84542c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:25:44 +1000 Subject: [PATCH 08/19] Match the names --- 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 d38c3b9a32..447011b204 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1695,7 +1695,7 @@ Stream ID: : The 32-bit Stream ID of the stream being terminated. -Application Protocol Error Code: +App Protocol Error Code: : A 32-bit application protocol error code (see {{app-error-codes}}) which indicates why the stream is being closed. From aacc9bbff886feea8d0a167756421619669d91d1 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 11 Aug 2017 15:29:44 +1000 Subject: [PATCH 09/19] Add HTTP_NO_ERROR --- draft-ietf-quic-http.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 4a4e2d4905..89c5a48370 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -882,6 +882,10 @@ the cause of a connection or stream error. The following error codes are defined for use in QUIC RST_STREAM and APPLICATION_CLOSE frames when using HTTP/QUIC. +HTTP_NO_ERROR (0x00): +: No error. This is used when the connection or stream needs to be closed, but + there is no error to signal. + HTTP_PUSH_REFUSED (0x01): : The server has attempted to push content which the client will not accept on this connection. @@ -1092,7 +1096,7 @@ The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error codes as follows: NO_ERROR (0x0): -: QUIC_NO_ERROR +: HTTP_NO_ERROR PROTOCOL_ERROR (0x1): : No single mapping. See new HTTP_MALFORMED_* error codes defined in @@ -1298,6 +1302,7 @@ The entries in the following table are registered by this document. |-----------------------------------|--------|----------------------------------------|----------------------| | Name | Code | Description | Specification | |-----------------------------------|--------|----------------------------------------|----------------------| +| HTTP_NO_ERROR | 0x00 | No error | {{http-error-codes}} | | HTTP_PUSH_REFUSED | 0x01 | Client refused pushed content | {{http-error-codes}} | | HTTP_INTERNAL_ERROR | 0x02 | Internal error | {{http-error-codes}} | | HTTP_PUSH_ALREADY_IN_CACHE | 0x03 | Pushed content already cached | {{http-error-codes}} | From 390704b1e15e7b0adfd3784d8b3b1c61c880a822 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 15 Aug 2017 11:21:05 +1000 Subject: [PATCH 10/19] Review comments --- draft-ietf-quic-tls.md | 2 +- draft-ietf-quic-transport.md | 36 +++++++++++++++--------------------- 2 files changed, 16 insertions(+), 22 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index fd4cfea7e7..ef96c23ae5 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1507,7 +1507,7 @@ packets as indicative of an attack. # Error Codes {#errors} -This document defines error codes from the error code space used in +This section defines error codes from the error code space used in {{QUIC-TRANSPORT}}. The following error codes are defined when TLS is used for the crypto handshake: diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 447011b204..5fcd313910 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1681,7 +1681,7 @@ The RST_STREAM frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| App Protocol Error Code (16) | +| App Protocol Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Final Offset (64) + @@ -1993,8 +1993,9 @@ Stateless Reset Token: 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. The frame is as -follows: +signals a peer to abruptly terminate transmission on a stream. + +The STOP_SENDING frame is as follows: ~~~ 0 1 2 3 @@ -2015,6 +2016,7 @@ App Error Code: : A 32-bit, application-specified reason the sender is ignoring the stream (see {{app-error-codes}}). + ## ACK Frame {#frame-ack} Receivers send ACK frames to inform senders which packets they have received and @@ -3033,12 +3035,8 @@ A TRANSPORT_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is lost. An endpoint SHOULD be prepared to retransmit a packet containing either frame type if it receives more packets on a terminated connection. Limiting the number of retransmissions and the time over which this final packet is sent -limits the effort expended on terminated connections. - -An endpoint that chooses not to retransmit packets containing TRANSPORT_CLOSE or -APPLICATION_CLOSE 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 use the stateless reset process +limits the effort expended on terminated connections. An endpoint that does not +retransmit this packet could be forced to use the stateless reset process ({{stateless-reset}}). An endpoint that receives an invalid TRANSPORT_CLOSE or APPLICATION_CLOSE frame @@ -3056,15 +3054,11 @@ 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 PROTOCOL_VIOLATION. -A stream error is always an application-layer construct. A RST_STREAM MUST NOT -be generated by the QUIC transport layer. Resetting a stream at the transport -layer could cause unrecoverable loss of application protocol state. Application -protocols might require certain streams to be reliably delivered in order to -guarantee consistent state between endpoints. For this reason, all errors that -can be detected at the transport layer result in connection errors. - -An endpoint that detects a stream error MAY choose to treat the error as a -connection error and send an APPLICATION_CLOSE frame in place of RST_STREAM. +RST_STREAM MUST be instigated by the application and MUST carry an application +error code. Resetting a stream without knowledge of the application protocol +could cause the protocol to enter an unrecoverable state. Application protocols +might require certain streams to be reliably delivered in order to guarantee +consistent state between endpoints. ## Transport Error Codes {#error-codes} @@ -3148,9 +3142,9 @@ application error codes are left to application protocols. Application protocol error codes are used for the RST_STREAM ({{frame-rst-stream}}) and APPLICATION_CLOSE ({{frame-application-close}}) frames. -Application protocols SHOULD define an error codes for indicating no error and -for use when sending a RST_STREAM in response to a STOP_SENDING frame. -Otherwise, there is no restriction on the use of the 16-bit error code space for +Application protocols SHOULD define error codes for indicating no error and for +use when sending a RST_STREAM in response to a STOP_SENDING frame. Otherwise, +there is no restriction on the use of the 16-bit error code space for application protocols. From 3e670a13c4f4ce342beb2f268c9c32273115c003 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 6 Sep 2017 11:21:33 +1000 Subject: [PATCH 11/19] Jana's comments --- draft-ietf-quic-transport.md | 73 ++++++++++++++++-------------------- 1 file changed, 33 insertions(+), 40 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5fcd313910..a1d96355a6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -845,7 +845,7 @@ explained in more detail as they are referenced later in the document. |:------------|:------------------|:----------------------------| | 0x00 | PADDING | {{frame-padding}} | | 0x01 | RST_STREAM | {{frame-rst-stream}} | -| 0x02 | TRANSPORT_CLOSE | {{frame-transport-close}} | +| 0x02 | CONNECTION_CLOSE | {{frame-connection-close}} | | 0x03 | APPLICATION_CLOSE | {{frame-application-close}} | | 0x04 | MAX_DATA | {{frame-max-data}} | | 0x05 | MAX_STREAM_DATA | {{frame-max-stream-data}} | @@ -1490,19 +1490,10 @@ A connection that remains idle for longer than the idle timeout (see connection state if they have neither sent nor received a packet for this time. The time at which an idle timeout takes effect won't be perfectly synchronized -<<<<<<< HEAD on peers. A connection enters the draining period when the idle timeout expires. During this time, an endpoint that receives new packets MAY choose to restore the connection. Alternatively, an endpoint that receives packets MAY signal the timeout using an immediate close. -======= -on peers. Endpoints might allow for the possibility that the remote side might -attempt to send packets before the timeout. In this case, an endpoint might -choose to retain enough information to generate a packet containing -TRANSPORT_CLOSE (see {{immediate-close}}). Endpoints MAY instead rely on -sending Stateless Reset in response to packets that arrive after an idle -timeout. ->>>>>>> s/Public Reset/Stateless Reset/ ### Immediate Close @@ -1540,8 +1531,8 @@ A stateless reset is provided as an option of last resort for a server that does not have access to the state of a connection. A server crash or outage might result in clients continuing to send data to a server that is unable to properly continue the connection. A server that wishes to communicate a fatal connection -error MUST use a TRANSPORT_CLOSE or APPLICATION_CLOSE frame if it has sufficient -state to do so. +error MUST use a CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has +sufficient state to do so. To support this process, the server sends a stateless_reset_token value during the handshake in the transport parameters. This value is protected by @@ -1595,7 +1586,7 @@ indistinguishable from a regular packet. A stateless reset is not appropriate for signaling error conditions. An endpoint that wishes to communicate a fatal connection error MUST use a -TRANSPORT_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so. +CONNECTION_CLOSE or APPLICATION_CLOSE frame if it has sufficient state to do so. #### Detecting a Stateless Reset @@ -1706,16 +1697,16 @@ Final Offset: data written on this stream by the RST_STREAM sender. -## TRANSPORT_CLOSE frame {#frame-transport-close} +## CONNECTION_CLOSE frame {#frame-connection-close} -An endpoint sends a TRANSPORT_CLOSE frame (type=0x02) to notify its peer that -the connection is being closed. TRANSPORT_CLOSE is used to signal errors at the -QUIC layer, or the absence of errors (with the NO_ERROR code). +An endpoint sends a CONNECTION_CLOSE frame (type=0x02) to notify its peer that +the connection is being closed. CONNECTION_CLOSE is used to signal errors at +the QUIC layer, or the absence of errors (with the NO_ERROR code). If there are open streams that haven't been explicitly closed, they are implicitly closed when the connection is closed. -The TRANSPORT_CLOSE frame is as follows: +The CONNECTION_CLOSE frame is as follows: ~~~ 0 1 2 3 @@ -1727,19 +1718,19 @@ The TRANSPORT_CLOSE frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ -The fields of a TRANSPORT_CLOSE frame are as follows: +The fields of a CONNECTION_CLOSE frame are as follows: Error Code: : A 32-bit error code which indicates the reason for closing this connection. - TRANSPORT_CLOSE uses codes from the space defined in {{error-codes}}; - APPLICATION_CLOSE uses codes from the application protocol error code space - ({{app-error-codes}}). + CONNECTION_CLOSE uses codes from the space defined in {{error-codes}} + (APPLICATION_CLOSE uses codes from the application protocol error code space, + see {{app-error-codes}}). Reason Phrase Length: : A 16-bit unsigned number specifying the length of the reason phrase in bytes. - Note that a TRANSPORT_CLOSE frame cannot be split between packets, so in + Note that a CONNECTION_CLOSE frame cannot be split between packets, so in practice any limits on packet size will also limit the space available for a reason phrase. @@ -1753,12 +1744,12 @@ Reason Phrase: ## APPLICATION_CLOSE frame {#frame-application-close} An APPLICATION_CLOSE frame (type=0x03) uses the same format as the -TRANSPORT_CLOSE frame ({{frame-transport-close}}), except that it uses error +CONNECTION_CLOSE frame ({{frame-connection-close}}), except that it uses error codes from the application protocol error code space ({{app-error-codes}}) instead of the transport error code space. Other than the error code space, the format and semantics of the -APPLICATION_CLOSE frame are identical to the TRANSPORT_CLOSE frame. +APPLICATION_CLOSE frame are identical to the CONNECTION_CLOSE frame. ## MAX_DATA Frame {#frame-max-data} @@ -2003,16 +1994,18 @@ The STOP_SENDING frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| App Error Code (32) | +| Application Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields are: Stream ID: + : The 32-bit Stream ID of the stream being ignored. -App Error Code: +Application Error Code: + : A 32-bit, application-specified reason the sender is ignoring the stream (see {{app-error-codes}}). @@ -2734,11 +2727,11 @@ connection and stream flow-control windows, even though these frames will be discarded upon receipt. This avoids potential ambiguity about which STREAM frames count toward flow control. -Upon receipt of a STOP_SENDING frame on a stream in the "open" or "half-closed -(remote)" states, an endpoint MUST send a RST_STREAM frame. If the STOP_SENDING -frame is received on a stream that is already in the "half-closed (local)" or -"closed" states, a RST_STREAM frame MAY still be sent in order to cancel -retransmission of previously-sent STREAM frames. +A STOP_SENDING frame on a stream in the "open" or "half-closed (remote)" states, +requests that the the receiving application send a RST_STREAM frame. If the +STOP_SENDING frame is received on a stream that is already in the "half-closed +(local)" or "closed" states, a RST_STREAM frame MAY still be sent in order to +cancel retransmission of previously-sent STREAM frames. While STOP_SENDING frames are retransmittable, an implementation MAY choose not to retransmit a lost STOP_SENDING frame if the stream has already been closed @@ -3012,7 +3005,7 @@ frame that signals the error. Where this specification identifies error conditions, it also identifies the error code that is used. A stateless reset ({{stateless-reset}}) is not suitable for any error that can -be signaled with a TRANSPORT_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame. A +be signaled with a CONNECTION_CLOSE, APPLICATION_CLOSE, or RST_STREAM frame. A stateless reset MUST NOT be used by an endpoint that has the state necessary to send a frame on the connection. @@ -3021,17 +3014,17 @@ send a frame on the connection. Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire -connection, MUST be signaled using a TRANSPORT_CLOSE or APPLICATION_CLOSE frame -({{frame-transport-close}}, {{frame-application-close}}). An endpoint MAY close +connection, MUST be signaled using a CONNECTION_CLOSE or APPLICATION_CLOSE frame +({{frame-connection-close}}, {{frame-application-close}}). An endpoint MAY close the connection in this manner, even if the error only affects a single stream. Application protocols can signal application-specific protocol errors using the APPLICATION_CLOSE frame. Errors that are specific to the transport, including -all those described in this document, are carried in a TRANSPORT_CLOSE frame. +all those described in this document, are carried in a CONNECTION_CLOSE frame. Other than the type of error code they carry, these frames are identical in format and semantics. -A TRANSPORT_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is +A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is lost. An endpoint SHOULD be prepared to retransmit a packet containing either frame type if it receives more packets on a terminated connection. Limiting the number of retransmissions and the time over which this final packet is sent @@ -3039,7 +3032,7 @@ limits the effort expended on terminated connections. An endpoint that does not retransmit this packet could be forced to use the stateless reset process ({{stateless-reset}}). -An endpoint that receives an invalid TRANSPORT_CLOSE or APPLICATION_CLOSE frame +An endpoint that receives an invalid CONNECTION_CLOSE or APPLICATION_CLOSE frame MUST NOT signal the existence of the error to its peer. @@ -3066,11 +3059,11 @@ consistent state between endpoints. Transport error codes are 32 bits long. This section lists the defined QUIC transport error codes that may be used in a -TRANSPORT_CLOSE frame. These errors apply to the entire connection. +CONNECTION_CLOSE frame. These errors apply to the entire connection. NO_ERROR (0x0): -: An endpoint uses this with TRANSPORT_CLOSE to signal that the connection is +: An endpoint uses this with CONNECTION_CLOSE to signal that the connection is being closed abruptly in the absence of any error. INTERNAL_ERROR (0x1): From b38f611f8b522d9046d2a0a0506c27375fa0f0fa Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 8 Sep 2017 08:25:56 +1000 Subject: [PATCH 12/19] Small tweak at Mike's suggestion --- draft-ietf-quic-http.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 89c5a48370..217990cd4c 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -1092,11 +1092,11 @@ QUIC has the same concepts of "stream" and "connection" errors that HTTP/2 provides. However, because the error code space is shared between multiple components, there is no direct portability of HTTP/2 error codes. -The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to QUIC error -codes as follows: +The HTTP/2 error codes defined in Section 7 of {{!RFC7540}} map to the HTTP over +QUIC error codes as follows: NO_ERROR (0x0): -: HTTP_NO_ERROR +: HTTP_NO_ERROR in {{http-error-codes}}. PROTOCOL_ERROR (0x1): : No single mapping. See new HTTP_MALFORMED_* error codes defined in From 31fa531806d31a61ff6dbf7207cbf0962873f60b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 28 Sep 2017 11:19:50 +1000 Subject: [PATCH 13/19] Reword STOP_SENDING text to avoid implication of mandatory RST_STREAM --- draft-ietf-quic-transport.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index a1d96355a6..608a6d6ed9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2716,22 +2716,23 @@ Reordering might cause frames to be received after closing, see ## Solicited State Transitions -If an endpoint is no longer interested in the data being received, it MAY send a -STOP_SENDING frame on a stream in the "open" or "half-closed (local)" state to -prompt closure of the stream in the opposite direction. This typically -indicates that the receiving application is no longer reading from the stream, -but is not a guarantee that incoming data will be ignored. +If an endpoint is no longer interested in the data it is receiving on a stream, +it MAY send a STOP_SENDING frame identifying that stream to prompt closure of +the stream in the opposite direction. This typically indicates that the +receiving application is no longer reading data it receives from the stream, but +is not a guarantee that incoming data will be ignored. STREAM frames received after sending STOP_SENDING are still counted toward the connection and stream flow-control windows, even though these frames will be discarded upon receipt. This avoids potential ambiguity about which STREAM frames count toward flow control. -A STOP_SENDING frame on a stream in the "open" or "half-closed (remote)" states, -requests that the the receiving application send a RST_STREAM frame. If the -STOP_SENDING frame is received on a stream that is already in the "half-closed -(local)" or "closed" states, a RST_STREAM frame MAY still be sent in order to -cancel retransmission of previously-sent STREAM frames. +STOP_SENDING can only be sent for any stream that is not "idle", however it is +mostly useful for streams in the "open" or "half-closed (local)" states. A +STOP_SENDING frame requests that the receiving application send a RST_STREAM +frame. If the STOP_SENDING frame is received on a stream that is already in the +"half-closed (local)" or "closed" states, a RST_STREAM frame MAY still be sent +in order to cancel retransmission of previously-sent STREAM frames. While STOP_SENDING frames are retransmittable, an implementation MAY choose not to retransmit a lost STOP_SENDING frame if the stream has already been closed From 37f62797b71c2d07591efc5df58e87cde42f2ec5 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 28 Sep 2017 11:45:49 +1000 Subject: [PATCH 14/19] Better track changes on master --- draft-ietf-quic-transport.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 608a6d6ed9..46b5696f24 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3017,7 +3017,7 @@ Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire connection, MUST be signaled using a CONNECTION_CLOSE or APPLICATION_CLOSE frame ({{frame-connection-close}}, {{frame-application-close}}). An endpoint MAY close -the connection in this manner, even if the error only affects a single stream. +the connection in this manner even if the error only affects a single stream. Application protocols can signal application-specific protocol errors using the APPLICATION_CLOSE frame. Errors that are specific to the transport, including @@ -3029,8 +3029,12 @@ A CONNECTION_CLOSE or APPLICATION_CLOSE frame could be sent in a packet that is lost. An endpoint SHOULD be prepared to retransmit a packet containing either frame type if it receives more packets on a terminated connection. Limiting the number of retransmissions and the time over which this final packet is sent -limits the effort expended on terminated connections. An endpoint that does not -retransmit this packet could be forced to use the stateless reset process +limits the effort expended on terminated connections. + +An endpoint that chooses not to retransmit packets containing CONNECTION_CLOSE +or APPLICATION_CLOSE 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 use the stateless reset process ({{stateless-reset}}). An endpoint that receives an invalid CONNECTION_CLOSE or APPLICATION_CLOSE frame From 78db6b219940801e94785d359466214fbcea9b92 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 28 Sep 2017 11:45:59 +1000 Subject: [PATCH 15/19] Reword advice on application error codes --- draft-ietf-quic-transport.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 46b5696f24..17c845dba6 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3140,10 +3140,10 @@ application error codes are left to application protocols. Application protocol error codes are used for the RST_STREAM ({{frame-rst-stream}}) and APPLICATION_CLOSE ({{frame-application-close}}) frames. -Application protocols SHOULD define error codes for indicating no error and for -use when sending a RST_STREAM in response to a STOP_SENDING frame. Otherwise, -there is no restriction on the use of the 16-bit error code space for -application protocols. +There is no restriction on the use of the 16-bit error code space for +application protocols. However, application protocols SHOULD define error codes +for terminating streams with an error and for use when sending a RST_STREAM in +response to a STOP_SENDING frame. # Security and Privacy Considerations From 0d0b7ab605663319d9234cb4917e5c6dc3c10bf7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 4 Oct 2017 12:42:20 -0700 Subject: [PATCH 16/19] Steal a code from the application --- draft-ietf-quic-http.md | 81 +++++++++++++++++++----------------- draft-ietf-quic-transport.md | 14 ++++--- 2 files changed, 51 insertions(+), 44 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 217990cd4c..5de0f6197c 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -882,67 +882,71 @@ the cause of a connection or stream error. The following error codes are defined for use in QUIC RST_STREAM and APPLICATION_CLOSE frames when using HTTP/QUIC. -HTTP_NO_ERROR (0x00): +HTTP_STOPPING (0x00): +: This value is reserved by the transport to be used in response to QUIC + STOP_SENDING frames. + +HTTP_NO_ERROR (0x01): : No error. This is used when the connection or stream needs to be closed, but there is no error to signal. -HTTP_PUSH_REFUSED (0x01): +HTTP_PUSH_REFUSED (0x02): : The server has attempted to push content which the client will not accept on this connection. -HTTP_INTERNAL_ERROR (0x02): +HTTP_INTERNAL_ERROR (0x03): : An internal error has occurred in the HTTP stack. -HTTP_PUSH_ALREADY_IN_CACHE (0x03): +HTTP_PUSH_ALREADY_IN_CACHE (0x04): : The server has attempted to push content which the client has cached. -HTTP_REQUEST_CANCELLED (0x04): +HTTP_REQUEST_CANCELLED (0x05): : The client no longer needs the requested data. -HTTP_HPACK_DECOMPRESSION_FAILED (0x05): +HTTP_HPACK_DECOMPRESSION_FAILED (0x06): : HPACK failed to decompress a frame and cannot continue. -HTTP_CONNECT_ERROR (0x06): +HTTP_CONNECT_ERROR (0x07): : The connection established in response to a CONNECT request was reset or abnormally closed. -HTTP_EXCESSIVE_LOAD (0x07): +HTTP_EXCESSIVE_LOAD (0x08): : The endpoint detected that its peer is exhibiting a behavior that might be generating excessive load. -HTTP_VERSION_FALLBACK (0x08): +HTTP_VERSION_FALLBACK (0x09): : The requested operation cannot be served over HTTP/QUIC. The peer should retry over HTTP/2. -HTTP_MALFORMED_HEADERS (0x09): +HTTP_MALFORMED_HEADERS (0x0A): : A HEADERS frame has been received with an invalid format. -HTTP_MALFORMED_PRIORITY (0x0A): +HTTP_MALFORMED_PRIORITY (0x0B): : A PRIORITY frame has been received with an invalid format. -HTTP_MALFORMED_SETTINGS (0x0B): +HTTP_MALFORMED_SETTINGS (0x0C): : A SETTINGS frame has been received with an invalid format. -HTTP_MALFORMED_PUSH_PROMISE (0x0C): +HTTP_MALFORMED_PUSH_PROMISE (0x0D): : A PUSH_PROMISE frame has been received with an invalid format. -HTTP_MALFORMED_DATA (0x0D): +HTTP_MALFORMED_DATA (0x0E): : A DATA frame has been received with an invalid format. -HTTP_INTERRUPTED_HEADERS (0x0E): +HTTP_INTERRUPTED_HEADERS (0x0F): : A HEADERS frame without the End Header Block flag was followed by a frame other than HEADERS. -HTTP_WRONG_STREAM (0x0F): +HTTP_WRONG_STREAM (0x10): : A frame was received on stream where it is not permitted. -HTTP_MULTIPLE_SETTINGS (0x10): +HTTP_MULTIPLE_SETTINGS (0x11): : More than one SETTINGS frame was received. -HTTP_MALFORMED_PUSH (0x11): +HTTP_MALFORMED_PUSH (0x12): : A push stream header was malformed or included an invalid Push ID. -HTTP_MALFORMED_MAX_PUSH_ID (0x12): +HTTP_MALFORMED_MAX_PUSH_ID (0x13): : A MAX_PUSH_ID frame has been received with an invalid format. @@ -1302,25 +1306,26 @@ The entries in the following table are registered by this document. |-----------------------------------|--------|----------------------------------------|----------------------| | Name | Code | Description | Specification | |-----------------------------------|--------|----------------------------------------|----------------------| -| HTTP_NO_ERROR | 0x00 | No error | {{http-error-codes}} | -| HTTP_PUSH_REFUSED | 0x01 | Client refused pushed content | {{http-error-codes}} | -| HTTP_INTERNAL_ERROR | 0x02 | Internal error | {{http-error-codes}} | -| HTTP_PUSH_ALREADY_IN_CACHE | 0x03 | Pushed content already cached | {{http-error-codes}} | -| HTTP_REQUEST_CANCELLED | 0x04 | Data no longer needed | {{http-error-codes}} | -| HTTP_HPACK_DECOMPRESSION_FAILED | 0x05 | HPACK cannot continue | {{http-error-codes}} | -| HTTP_CONNECT_ERROR | 0x06 | TCP reset or error on CONNECT request | {{http-error-codes}} | -| HTTP_EXCESSIVE_LOAD | 0x07 | Peer generating excessive load | {{http-error-codes}} | -| HTTP_VERSION_FALLBACK | 0x08 | Retry over HTTP/2 | {{http-error-codes}} | -| HTTP_MALFORMED_HEADERS | 0x09 | Invalid HEADERS frame | {{http-error-codes}} | -| HTTP_MALFORMED_PRIORITY | 0x0A | Invalid PRIORITY frame | {{http-error-codes}} | -| HTTP_MALFORMED_SETTINGS | 0x0B | Invalid SETTINGS frame | {{http-error-codes}} | -| HTTP_MALFORMED_PUSH_PROMISE | 0x0C | Invalid PUSH_PROMISE frame | {{http-error-codes}} | -| HTTP_MALFORMED_DATA | 0x0D | Invalid DATA frame | {{http-error-codes}} | -| HTTP_INTERRUPTED_HEADERS | 0x0E | Incomplete HEADERS block | {{http-error-codes}} | -| HTTP_WRONG_STREAM | 0x0F | A frame was sent on the wrong stream | {{http-error-codes}} | -| HTTP_MULTIPLE_SETTINGS | 0x10 | Multiple SETTINGS frames | {{http-error-codes}} | -| HTTP_MALFORMED_PUSH | 0x11 | Invalid push stream header | {{http-error-codes}} | -| HTTP_MALFORMED_MAX_PUSH_ID | 0x12 | Invalid MAX_PUSH_ID frame | {{http-error-codes}} | +| HTTP_STOPPING | 0x00 | STOPPING (reserved by transport) | {{http-error-codes}} | +| HTTP_NO_ERROR | 0x01 | No error | {{http-error-codes}} | +| HTTP_PUSH_REFUSED | 0x02 | Client refused pushed content | {{http-error-codes}} | +| HTTP_INTERNAL_ERROR | 0x03 | Internal error | {{http-error-codes}} | +| HTTP_PUSH_ALREADY_IN_CACHE | 0x04 | Pushed content already cached | {{http-error-codes}} | +| HTTP_REQUEST_CANCELLED | 0x05 | Data no longer needed | {{http-error-codes}} | +| HTTP_HPACK_DECOMPRESSION_FAILED | 0x06 | HPACK cannot continue | {{http-error-codes}} | +| HTTP_CONNECT_ERROR | 0x07 | TCP reset or error on CONNECT request | {{http-error-codes}} | +| HTTP_EXCESSIVE_LOAD | 0x08 | Peer generating excessive load | {{http-error-codes}} | +| HTTP_VERSION_FALLBACK | 0x09 | Retry over HTTP/2 | {{http-error-codes}} | +| HTTP_MALFORMED_HEADERS | 0x0A | Invalid HEADERS frame | {{http-error-codes}} | +| HTTP_MALFORMED_PRIORITY | 0x0B | Invalid PRIORITY frame | {{http-error-codes}} | +| HTTP_MALFORMED_SETTINGS | 0x0C | Invalid SETTINGS frame | {{http-error-codes}} | +| HTTP_MALFORMED_PUSH_PROMISE | 0x0D | Invalid PUSH_PROMISE frame | {{http-error-codes}} | +| HTTP_MALFORMED_DATA | 0x0E | Invalid DATA frame | {{http-error-codes}} | +| HTTP_INTERRUPTED_HEADERS | 0x0F | Incomplete HEADERS block | {{http-error-codes}} | +| HTTP_WRONG_STREAM | 0x10 | A frame was sent on the wrong stream | {{http-error-codes}} | +| HTTP_MULTIPLE_SETTINGS | 0x11 | Multiple SETTINGS frames | {{http-error-codes}} | +| HTTP_MALFORMED_PUSH | 0x12 | Invalid push stream header | {{http-error-codes}} | +| HTTP_MALFORMED_MAX_PUSH_ID | 0x13 | Invalid MAX_PUSH_ID frame | {{http-error-codes}} | |-----------------------------------|--------|----------------------------------------|----------------------| diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 17c845dba6..fc2cae4f64 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2730,9 +2730,11 @@ frames count toward flow control. STOP_SENDING can only be sent for any stream that is not "idle", however it is mostly useful for streams in the "open" or "half-closed (local)" states. A STOP_SENDING frame requests that the receiving application send a RST_STREAM -frame. If the STOP_SENDING frame is received on a stream that is already in the -"half-closed (local)" or "closed" states, a RST_STREAM frame MAY still be sent -in order to cancel retransmission of previously-sent STREAM frames. +frame. An endpoint that receives a STOP_SENDING frame MUST send a RST_STREAM +frame for that stream with an error code of STOPPING. If the STOP_SENDING frame +is received on a stream that is already in the "half-closed (local)" or "closed" +states, a RST_STREAM frame MAY still be sent in order to cancel retransmission +of previously-sent STREAM frames. While STOP_SENDING frames are retransmittable, an implementation MAY choose not to retransmit a lost STOP_SENDING frame if the stream has already been closed @@ -3141,9 +3143,9 @@ error codes are used for the RST_STREAM ({{frame-rst-stream}}) and APPLICATION_CLOSE ({{frame-application-close}}) frames. There is no restriction on the use of the 16-bit error code space for -application protocols. However, application protocols SHOULD define error codes -for terminating streams with an error and for use when sending a RST_STREAM in -response to a STOP_SENDING frame. +application protocols. However, QUIC reserves the error code with a value of 0 +to mean STOPPING. The application error code of STOPPING (0) is used by the +transport to cancel a stream in response to receipt of a STOP_SENDING frame. # Security and Privacy Considerations From 72784255fa030c25ca3e1ad43d07a5237465dfcd Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 5 Oct 2017 11:26:43 -0700 Subject: [PATCH 17/19] Simply reserve the RST_STREAM code of 0. --- draft-ietf-quic-http.md | 4 ++-- draft-ietf-quic-transport.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 5de0f6197c..14c85a6e9b 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -882,7 +882,7 @@ the cause of a connection or stream error. The following error codes are defined for use in QUIC RST_STREAM and APPLICATION_CLOSE frames when using HTTP/QUIC. -HTTP_STOPPING (0x00): +Reserved (0x00): : This value is reserved by the transport to be used in response to QUIC STOP_SENDING frames. @@ -1306,7 +1306,7 @@ The entries in the following table are registered by this document. |-----------------------------------|--------|----------------------------------------|----------------------| | Name | Code | Description | Specification | |-----------------------------------|--------|----------------------------------------|----------------------| -| HTTP_STOPPING | 0x00 | STOPPING (reserved by transport) | {{http-error-codes}} | +| (reserved) | 0x00 | Reserved by transport | {{http-error-codes}} | | HTTP_NO_ERROR | 0x01 | No error | {{http-error-codes}} | | HTTP_PUSH_REFUSED | 0x02 | Client refused pushed content | {{http-error-codes}} | | HTTP_INTERNAL_ERROR | 0x03 | Internal error | {{http-error-codes}} | diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index fc2cae4f64..b843e736b3 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3144,8 +3144,8 @@ APPLICATION_CLOSE ({{frame-application-close}}) frames. There is no restriction on the use of the 16-bit error code space for application protocols. However, QUIC reserves the error code with a value of 0 -to mean STOPPING. The application error code of STOPPING (0) is used by the -transport to cancel a stream in response to receipt of a STOP_SENDING frame. +for use in RST_STREAM. An application error code of 0 is used by QUIC to cancel +a stream in response to receipt of a STOP_SENDING frame. # Security and Privacy Considerations From 0ed11a25190a12cbb1d8601f5e9c6ee6620624b7 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 5 Oct 2017 11:29:06 -0700 Subject: [PATCH 18/19] Application error code missed --- draft-ietf-quic-transport.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index b843e736b3..e875de79e9 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -1672,7 +1672,7 @@ The RST_STREAM frame is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| App Protocol Error Code (32) | +| Application Protocol Error Code (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Final Offset (64) + @@ -1686,7 +1686,7 @@ Stream ID: : The 32-bit Stream ID of the stream being terminated. -App Protocol Error Code: +Application Protocol Error Code: : A 32-bit application protocol error code (see {{app-error-codes}}) which indicates why the stream is being closed. From c302a454bf807e9e8428b2ebd7a33a67adcd118f Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 5 Oct 2017 11:45:18 -0700 Subject: [PATCH 19/19] We really should just call this STOPPING --- draft-ietf-quic-http.md | 4 ++-- draft-ietf-quic-transport.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 14c85a6e9b..90ddbce398 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -882,7 +882,7 @@ the cause of a connection or stream error. The following error codes are defined for use in QUIC RST_STREAM and APPLICATION_CLOSE frames when using HTTP/QUIC. -Reserved (0x00): +STOPPING (0x00): : This value is reserved by the transport to be used in response to QUIC STOP_SENDING frames. @@ -1306,7 +1306,7 @@ The entries in the following table are registered by this document. |-----------------------------------|--------|----------------------------------------|----------------------| | Name | Code | Description | Specification | |-----------------------------------|--------|----------------------------------------|----------------------| -| (reserved) | 0x00 | Reserved by transport | {{http-error-codes}} | +| STOPPING | 0x00 | Reserved by QUIC | {{QUIC-TRANSPORT}} | | HTTP_NO_ERROR | 0x01 | No error | {{http-error-codes}} | | HTTP_PUSH_REFUSED | 0x02 | Client refused pushed content | {{http-error-codes}} | | HTTP_INTERNAL_ERROR | 0x03 | Internal error | {{http-error-codes}} | diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e875de79e9..9d276ca799 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -3144,8 +3144,8 @@ APPLICATION_CLOSE ({{frame-application-close}}) frames. There is no restriction on the use of the 16-bit error code space for application protocols. However, QUIC reserves the error code with a value of 0 -for use in RST_STREAM. An application error code of 0 is used by QUIC to cancel -a stream in response to receipt of a STOP_SENDING frame. +to mean STOPPING. The application error code of STOPPING (0) is used by the +transport to cancel a stream in response to receipt of a STOP_SENDING frame. # Security and Privacy Considerations