Re: [quicwg/base-drafts] Backoff on CONNECTION_CLOSE (#3157)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I had a little trouble following the logic here; I have a few suggestions.

> @@ -2379,15 +2379,19 @@ terminate the connection immediately.  A CONNECTION_CLOSE frame causes all
 streams to immediately become closed; open streams can be assumed to be
 implicitly reset.
 
-After sending a CONNECTION_CLOSE frame, endpoints immediately enter the closing
-state.  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.  To minimize the state that an endpoint
-maintains for a closing connection, endpoints MAY send the exact same packet.
-However, endpoints SHOULD limit the number of packets they generate containing a
-CONNECTION_CLOSE frame.  For instance, an endpoint could progressively increase
-the number of packets that it receives before sending additional packets or
-increase the time between packets.
+After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
+closing state.  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, until it receives a packet
+that contains a CONNECTION_CLOSE frame.  However, such an endpoint SHOULD limit

Time for a new paragraph.  And the "However, " doesn't really need to be here as this no longer relates to the former sentence in any contradictory way.

```suggestion
that contains a CONNECTION_CLOSE frame.

An endpoint SHOULD limit
```

But I *think* that your "However" here refers to the bit where the endpoint drops keys, which comes much later in the paragraph.  Is that right?

> -containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint
-maintains for a closing connection, endpoints MAY send the exact same packet.
-However, endpoints SHOULD limit the number of packets they generate containing a
-CONNECTION_CLOSE frame.  For instance, an endpoint could progressively increase
-the number of packets that it receives before sending additional packets or
-increase the time between packets.
+After sending a CONNECTION_CLOSE frame, an endpoint immediately enters the
+closing state.  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, until it receives a packet
+that contains a CONNECTION_CLOSE frame.  However, such an endpoint SHOULD limit
+the number of packets it generates containing a CONNECTION_CLOSE frame.  For
+instance, an endpoint could progressively increase the number of packets that it
+receives before sending additional packets or increase the time between packets.
+An endpoint that drops the packet protection keys when entering the closing
+period and therefore being unable to decrypt the incoming packets MUST

My suggestion, which should be a new paragraph:

> An endpoint MAY drop packet protection keys when entering the closing period and send the same packet multiple times.  However, an endpoint that cannot process incoming packets will be unable to identify and discard invalid packets.  To avoid creating an unwitting amplification attack, an endpoint that drops packet protection keys MUST reduce the frequency with which it sends packets containing CONNECTION_CLOSE.

-- 
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/3157#pullrequestreview-307710089