Re: [quicwg/base-drafts] One close frames (#1900)

[MikkelFJ <[e-mail]>]

mikkelfj commented on this pull request.



> @@ -1268,8 +1268,9 @@ express the cause of a connection or stream error.
 
 ## HTTP/QUIC Error Codes {#http-error-codes}
 
-The following error codes are defined for use in QUIC RST_STREAM, STOP_SENDING,
-and APPLICATION_CLOSE frames when using HTTP/QUIC.
+The following error codes are defined for use in QUIC RST_STREAM frames,
+STOP_SENDING frames, and CONNECTION_CLOSE frames with a type of 0x03 when using
+HTTP/QUIC.

I like the idea of a single close frame, but if it is necessary to refer to frame sub-type by numerical value, I think the idea has gone too far.

> @@ -2133,25 +2133,25 @@ These states SHOULD persist for three times the current Retransmission Timeout
 
 An endpoint enters a closing period after initiating an immediate close
 ({{immediate-close}}).  While closing, an endpoint MUST NOT send packets unless
-they contain a CONNECTION_CLOSE or APPLICATION_CLOSE frame (see
-{{immediate-close}} for details).  An endpoint retains only enough information
-to generate a packet containing a closing frame and to identify packets as
-belonging to the connection.  The connection ID and QUIC version is sufficient
-information to identify packets for a closing connection; an endpoint can
-discard all other connection state.  An endpoint MAY retain packet protection
-keys for incoming packets to allow it to read and process a closing frame.
+they contain a CONNECTION_CLOSE frame (see {{immediate-close}} for details).  An
+endpoint retains only enough information to generate a packet containing a
+CONNECTION_CLOSE frame and to identify packets as belonging to the connection.
+The connection ID and QUIC version is sufficient information to identify packets
+for a closing connection; an endpoint can discard all other connection state.
+An endpoint MAY retain packet protection keys for incoming packets to allow it
+to read and process a CONNECTION_CLOSE frame.

This is outside the semantic changes of the PR, but I wonder if connection close retransmission could suffer from lack of address validation. Amplification attacks would only be an issue if the close packet is large. One could imagine a valid connection triggering a large close packet that is not acknowledged followed by a spoofed packets that redirects retransmission. I don't think this is practical, but perhaps some clarification on the subject would be helpful. For example recommending sending small close packets if not verified.

> @@ -2228,28 +2230,28 @@ Note:
   control, which are not expected to be relevant for a closed connection.
   Retransmitting the final packet requires less state.
 
-After receiving a closing frame, endpoints enter the draining state.  An
-endpoint that receives a closing frame MAY send a single packet containing a
-closing frame before entering the draining state, using a CONNECTION_CLOSE frame
-and a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets,
-which could result in a constant exchange of closing frames until the closing
-period on either peer ended.
+After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state.
+An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet
+containing a CONNECTION_CLOSE frame before entering the draining state, using a
+CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT
+send further packets, which could result in a constant exchange of
+CONNECTION_CLOSE frames until the closing period on either peer ended.
 

"An endpoint MUST NOT send further packets ...". Does that mean only the endpoint receiving the initial CLOSE frame, or both endpoints. In the latter case close retransmission is not possible, but that is inconsistent with other text.

> @@ -4055,9 +4053,11 @@ Final Offset:
 
 ## CONNECTION_CLOSE frame {#frame-connection-close}
 
-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).
+An endpoint sends a CONNECTION_CLOSE frame (type=0x02 or 0x03) to notify its
+peer that the connection is being closed.  The CONNECTION_CLOSE with a frame
+type of 0x02 is used to signal errors at the QUIC layer, or the absence of
+errors (with the NO_ERROR code).  The CONNECTION_CLOSE frame with a type of 0x03
+is used to signal an error with the protocol that uses QUIC.

I suggest defing a subtype name such as "a CONNECTION_CLOSE of subtype TRANSPORT_CLOSE (0x02) or APPLICATION_CLOSE (0x03)". See my comment on http draft on using explicit frame code 0x03. This makes it difficult for external documents to discuss QUIC, especially across versions where the code might change but the semantics remain.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900#pullrequestreview-167760223