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

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Oct 2018 21:15:09 -0700

This turned out to be not awesome for the HTTP draft, so I'm looking for input on how I might resolve the user-interface issues.

There is a technical change here.  APPLICATION_CLOSE wasn't permitted in Initial packets.  Here it would be allowed.  I don't think that's a problem though.

Closes #1881.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1900

-- Commit Summary --

  * Merge APPLICATION_CLOSE description with CONNECTION_CLOSE
  * TLS-related changes
  * HTTP-related changes
  * Allow APPLICATION_CLOSE in Initial packets because why not

-- File Changes --

    M draft-ietf-quic-http.md (11)
    M draft-ietf-quic-tls.md (3)
    M draft-ietf-quic-transport.md (208)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1900.patch
https://github.com/quicwg/base-drafts/pull/1900.diff

-- 
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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 24 Oct 2018 00:00:58 -0700

> This turned out to be not awesome for the HTTP draft, so I'm looking for input on how I might resolve the user-interface issues.

This might be a dumb question but do we need to refer to "QUIC frames" in the HTTP draft? To me it seems a bit like crossing the layers.

I believe we can generally refer to features provided by the transport. For example, we could say "close the connection at the QUIC transport level" or "send a ping at the transport layer" rather than talking about QUIC frames that are used to implement the features.

-- 
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#issuecomment-432536894

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Oct 2018 00:47:44 -0700

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

---

From: ianswett <[email-masked]>
Date: Wed, 24 Oct 2018 12:57:33 +0000 (UTC)

ianswett commented on this pull request.

 

I tend to agree, I'd remove the type reference.

-- 
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#discussion_r227775547

---

From: ianswett <[email-masked]>
Date: Wed, 24 Oct 2018 13:01:36 +0000 (UTC)

I think the Immediate close text below addresses your concern?

-- 
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#discussion_r227777001

---

From: MikkelFJ <[email-masked]>
Date: Wed, 24 Oct 2018 06:06:14 -0700

Not really, though I could easily miss something:

 "During the closing period, an endpoint that sends a CONNECTION_CLOSE
 frame SHOULD respond to any packet that it receives with another packet
 containing a CONNECTION_CLOSE frame. "

If this is done without verying the input packet that triggers the next close frame because it is a stateless shrink-wrapped close packet triggered by CID, there is a potential for abuse, I believe.

-- 
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#discussion_r227778718

---

From: ianswett <[email-masked]>
Date: Wed, 24 Oct 2018 13:06:21 +0000 (UTC)

I'd suggest application instead of protocol in this sentence.

-- 
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-167895568

---

From: ianswett <[email-masked]>
Date: Wed, 24 Oct 2018 13:06:53 +0000 (UTC)

I think this looks good, but I'm curious to see others feedback.

-- 
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-167895816

---

From: Marten Seemann <[email-masked]>
Date: Wed, 24 Oct 2018 06:17:14 -0700

I agree with @kazuho. An application protocol built on top of QUIC shouldn't need to reference any QUIC frame types (and their code points).

-- 
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#issuecomment-432651794

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 24 Oct 2018 08:03:29 -0700

To be awkward, I'll point out the problem we have - there are many places where HTTP/QUIC refers to specific aspects of QUIC e.g. QUIC STREAM frame, QUIC transport parameters initial_max_stream_data_bidi_remote etc. Fixing one problem on this change here only scratches the surface of problems in the only formal application mapping we have.

It might be possible to use the forms of language suggested by @kazuho but the text could up being clunky.

I guess my point is either leave it or commit to fixing it consistently (and consider writing some guidance for new application mapping authors on how to discuss transport features). Broader changes should obviously be done on some other ticket.

-- 
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#issuecomment-432695536

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 16:56:34 -0700

@martinthomson pushed 1 commit.

6e13020  Make the split clearer

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/725b155bd3c5d3de7c9bb49fadc963d53dfa3747..6e130204e5d9685e0570f55eb5a2b31ed24a2c35

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 16:59:32 -0700

I think that Lucas is right here.  We don't have a clean interface, so we rely on talking about frames rather than that interface.  That's OK as long as we are clear on what we're doing in the process.  That way, we avoid relying on aspects of the transport that are for internal use only.

Sitting down and defining the interface (which consists primarily of the creation, use, and cancellation of streams, plus the creation and cancellation of connections) is difficult and time-consuming, and previous attempts to do that have failed.  So I don't want to start down that path at this stage; it would delay things.

-- 
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#issuecomment-432867466

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 25 Oct 2018 05:56:29 -0700

> Sitting down and defining the interface (which consists primarily of the creation, use, and cancellation of streams, plus the creation and cancellation of connections) is difficult and time-consumi…

+1. The more I think about it, the more it sounds like [TAPS](https://datatracker.ietf.org/wg/taps/about/). Let's not voyage to that path right now.

-- 
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#issuecomment-433039680

---

From: Nick Banks <[email-masked]>
Date: Thu, 25 Oct 2018 07:26:48 -0700

nibanks approved this pull request.

LGTM 👍

-- 
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-168411455

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Oct 2018 19:44:26 -0700

7b054d8  Merge branch 'master' into one-close-frames

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/6a9a135dd04d8e917317c1bbdc99ce544995b1eb..7b054d8de6311b9cfb89b9cc2070540a0bfaa90b

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 11:26:12 -0700

I'll also point out that HTTP/2 had some pretty extensive discussion of how it chose to profile TLS, the layer below it.  I don't think it's inappropriate for an application mapping to constrain how an implementation of that mapping *uses* the lower-level protocol; I do think it's inappropriate to constrain or discuss implementation of that protocol.

That said, there are probably places where we could be more formal about requiring the function (close connection), and letting the QUIC internals be informative (...which will trigger a QUIC CONNECTION_CLOSE frame in QUIC v1.)

-- 
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#issuecomment-434023846

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 11:38:56 -0700

MikeBishop approved this pull request.

Other than waving the flag for embedded flags, this looks fine.  One missed reference to two closing frame types.

Each endpoint MUST NOT send further packets once they've received a CONNECTION_CLOSE, except to send a single CONNECTION_CLOSE of their own if desired.  Yes, that means that if the responding CONNECTION_CLOSE is dropped, it won't be retransmitted, but that's okay -- the other side is already closing, and won't be transmitting further packets to provoke a retransmission anyway.

-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.
+A CONNECTION_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

"...containing a CONNECTION_CLOSE frame if it...."

> @@ -4067,9 +4065,13 @@ Final Offset:

-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.  Protocols that use
+QUIC only use the CONNECTION_CLOSE frame of type 0x03; the frame with type 0x02
+is only used internally by QUIC.

More inclined to indicate this as an embedded flag, indicating whether the error is at the transport or application layer.  Also makes the optional field easier.

> @@ -5021,9 +4983,9 @@ See {{iana-error-codes}} for details of registering new error codes.
 
 Application protocol error codes are 16-bit unsigned integers, 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 protocol error codes are used for the RST_STREAM frame
+({{frame-rst-stream}}) and the CONNECTION_CLOSE frame with a type of 0x03
+({{frame-connection-close}}) frames.

"the NAME frame with a type of 0xXX" is a very clunky reference convention.  Flags.

-- 
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-169453025

---

From: MikkelFJ <[email-masked]>
Date: Mon, 29 Oct 2018 13:17:34 -0700

OK, I'll buy not sending more than one close after seeing one, although it could prolong the draining period in case of loss.

-- 
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#discussion_r229082296

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Oct 2018 14:41:29 -0700

MikeBishop commented on this pull request.

I think actually it causes one of the endpoints to remain in closing instead of draining, but the spec says "The draining period SHOULD end when the closing period would have ended," so I think the time is the same whether you transition or not.

-- 
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#discussion_r229109004

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 18:00:04 -0700

martinthomson commented on this pull request.

 

As I said elsewhere, that's a wash when you try it out.

-- 
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#discussion_r229147216

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 18:05:04 -0700

ee50d48  No either for closing any more

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/7b054d8de6311b9cfb89b9cc2070540a0bfaa90b..ee50d4888e14a341f56c5252e2c0e125c572759d

---

From: janaiyengar <[email-masked]>
Date: Mon, 29 Oct 2018 19:48:20 -0700

janaiyengar commented on this pull request.

A few nits, but looks good overall.

 

```suggestion
type of 0x02 is used to signal errors at only the QUIC layer, or the absence of
```

 

```suggestion
is used to signal an error with the protocol that uses QUIC.
```

 

```suggestion
```

 

```suggestion
```

> @@ -4094,14 +4096,17 @@ The fields of a CONNECTION_CLOSE frame are as follows:
 
 Error Code:
 
-: A 16-bit error code which indicates the reason for closing this connection.
-  CONNECTION_CLOSE uses codes from the space defined in {{error-codes}}.
+: A 16-bit error code which indicates the reason for closing this connection.  A
+  CONNECTION_CLOSE frame of type 0x02 uses codes from the space defined in
+  {{error-codes}}; a CONNECTION_CLOSE frame of type 0x03 uses codes from the

```suggestion
  {{error-codes}}.  A CONNECTION_CLOSE frame of type 0x03 uses codes from the
```

 Frame Type:
 
 : A variable-length integer encoding the type of frame that triggered the error.
   A value of 0 (equivalent to the mention of the PADDING frame) is used when the
-  frame type is unknown.
+  frame type is unknown.  The application-specific variant of CONNECTION_CLOSE
+  does not include this field.

```suggestion
  (type 0x03) does not include this field.
```

I don't think you can avoid this clunkiness with flags here. You'd end up saying something like "CONNECTION_CLOSE frame with the X flag" instead.

-- 
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-169593400

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:06:25 -0700

144a06c  only QUIC

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/ee50d4888e14a341f56c5252e2c0e125c572759d..144a06c2ead6a6fba4c9a33e31c76bcb9a589855

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:06:38 -0700

d4161f2  drop tail

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/144a06c2ead6a6fba4c9a33e31c76bcb9a589855..d4161f2ad4ef0e488d06d0e082380a14ebc4f8e7

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:06:40 -0700

2fa1962  drop tail

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/d4161f2ad4ef0e488d06d0e082380a14ebc4f8e7..2fa1962e5cbe757069ae8a4b39ca34ae454d4733

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:06:43 -0700

3b511a8  drop tail

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/2fa1962e5cbe757069ae8a4b39ca34ae454d4733..3b511a8db215b017fc0f2149bf901cad95ba2686

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:06:51 -0700

9dadb18  period

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/3b511a8db215b017fc0f2149bf901cad95ba2686..9dadb18e2080ab8057dc42b740c6e3dd5581a3fd

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Oct 2018 20:07:06 -0700

00ab8c9  parenthesize type

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/9dadb18e2080ab8057dc42b740c6e3dd5581a3fd..00ab8c90c18517686023c7875307dd81ba30dff7

---

From: ianswett <[email-masked]>
Date: Tue, 30 Oct 2018 08:14:37 -0700

Bump

-- 
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#discussion_r229348750

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 17:20:38 -0700

4485da7  application not protocol in this case

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1900/files/00ab8c90c18517686023c7875307dd81ba30dff7..4485da74fde8dd7bfd425743bc75675f2f161eff

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 17:20:47 -0700

Merged #1900 into master.

-- 
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#event-1936627473