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

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 00:42:51 -0700

The PR clarifies the following:

* An endpoint that drops the keys when entering closing state MUST back-off the frequency of CONNECTION_CLOSE packets that it sends.
* An endpoint that does not drop the keys stops sending CONNECTION_CLOSE packet once it receives a packet containing CONNECTION_CLOSE.

The first point is what we have discussed in #3095. The second point is something we have not discussed, though I think it has been implied.

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

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

-- Commit Summary --

  * Clarify that:

-- File Changes --

    M draft-ietf-quic-transport.md (22)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3157.patch
https://github.com/quicwg/base-drafts/pull/3157.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/3157

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 00:51:20 -0700

@kazuho pushed 1 commit.

1e0db50707bd7ec1179b03269aef26fcc3cd3b0a  plural

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/3539edc1b1d03a469bd0ff5a32b0735daef8e79c..1e0db50707bd7ec1179b03269aef26fcc3cd3b0a

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2019 02:13:23 -0700

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

---

From: Marten Seemann <[email-masked]>
Date: Mon, 28 Oct 2019 02:39:25 -0700

marten-seemann commented on this pull request.

Why would it receive a packet with a CONNECTION_CLOSE frame? The peer won't send a CONNECTION_CLOSE in response to a CONNECTION_CLOSE, so this condition would only occur by pure coincidence.
I don't think we need any text describing this corner case.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 05:20:40 -0700

kazuho commented on this pull request.

I agree that this should not be a SHOULD. But we already have a MAY. The current text states that _an endpoint MAY transition from the closing period to the draining period if it receives a CONNECTION_CLOSE frame_.

I think that the text here should be something along the lines of:
* During the closing period, an endpoint that sends a CONNECTION_CLOSE frame SHOULD respond to a packet that *can be AEAD-decrypted* with another packet containing a CONNECTION_CLOSE frame. That action *MAY* cease when it receives a packet containing a CONNECTION_CLOSE frame.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 28 Oct 2019 06:13:17 -0700

mikkelfj commented on this pull request.

exponentially decrease?

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 14:58:08 -0700

@kazuho pushed 1 commit.

abfc00ca30ae3d44ba1f29db246b588178cc1127  SHOULD backoff in decrypting, MUST backoff if not

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/1e0db50707bd7ec1179b03269aef26fcc3cd3b0a..abfc00ca30ae3d44ba1f29db246b588178cc1127

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 15:01:30 -0700

@kazuho pushed 1 commit.

e36eb7614830dcff2fecb0c720fa29ede4643d03  separate paragraphs for each class of design

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/abfc00ca30ae3d44ba1f29db246b588178cc1127..e36eb7614830dcff2fecb0c720fa29ede4643d03

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 15:01:40 -0700

ianswett commented on this pull request.

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

```suggestion
keys when entering the closing period is unable to decrypt
```

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

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 15:02:06 -0700

+incoming packets MUST exponentially back off the frequency in which it sends

```suggestion
incoming packets so MUST exponentially back off the frequency in which it sends
```

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:02:39 -0700

Fixed in e36eb76.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:15:53 -0700

Fixed in abfc00c.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:17:02 -0700

@kazuho pushed 1 commit.

a45ded27fd9b4da8658657c0be11ff8cc0d2639c  rephrase based on @martinthomson's suggestion

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/e36eb7614830dcff2fecb0c720fa29ede4643d03..a45ded27fd9b4da8658657c0be11ff8cc0d2639c

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:18:56 -0700

Thank you.

Applied @martinthomson's suggestion in a45ded2. I do not think "exponentially" is required here, there could be other approaches, such as limiting the emission of CONNECTION_CLOSE to once every PTO.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:19:45 -0700

Thank you for the suggestions. I think they are covered by a45ded2.

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

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 17:24:39 -0700

> +closing state.
+
+During the closing period, an endpoint that sends a CONNECTION_CLOSE frame
+SHOULD respond to any incoming packet that can be decrypted with another packet
+containing a CONNECTION_CLOSE frame.  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 is allowed to drop the packet protection keys when entering the
+closing period ({{draining}}).  However, an endpoint without the packet
+protection keys cannot identify and discard invalid packets.  To avoid creating
+an unwitting amplification attack, such endpoints MUST reduce the frequency with
+which it sends packets containing a CONNECTION_CLOSE frame.
+
+To minimize the state that an endpoint maintains for a closing connection,

I think it makes sense to make this part of the preceding paragraph, since it pertains to cases when the keys are dropped?

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:36:58 -0700

@kazuho pushed 1 commit.

15898c5c6ee3538bfe6b45a9e652ee0767c59c21  merge the paragraphs (suggested by @ianswett)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/a45ded27fd9b4da8658657c0be11ff8cc0d2639c..15898c5c6ee3538bfe6b45a9e652ee0767c59c21

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 17:37:42 -0700

+

Nice catch! Adopted in 15898c5.

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

---

From: ianswett <[email-masked]>
Date: Mon, 28 Oct 2019 17:49:24 -0700

ianswett approved this pull request.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2019 21:12:13 -0700

martinthomson requested changes on this pull request.

> @@ -2379,15 +2379,23 @@ terminate the connection immediately.  A CONNECTION_CLOSE frame causes all

The "that can be decrypted" is new.  If you keep it, then it needs to be paired with something in the following paragraph that allows the endpoint to send the prebuilt packet in response to any received packet.

This probably blows the line length limit, but this is what I'm thinking.

```suggestion
closing period ({{draining}}) and send a packet containing a CONNECTION_CLOSE in
response to any UDP datagram that is received.  However, an endpoint without the packet
```

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 21:25:23 -0700

Could you please elaborate a bit more?

My understanding is that we need "that can be decrypted." The reason we are adding MUST for endpoints that drop the keys when entering the closing state is because they cannot validate the packet using the keys. In this paragraph, we are talking about the flip side. That means that the endpoints MUST validate the incoming packets by unprotecting them.

Or are you specifically suggesting that we need to talk about how duplicates are to be handled?

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 21:26:43 -0700

@kazuho pushed 1 commit.

175e7ddf52fd32aec9b24ad37214a35df99c8230  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/15898c5c6ee3538bfe6b45a9e652ee0767c59c21..175e7ddf52fd32aec9b24ad37214a35df99c8230

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 28 Oct 2019 21:28:10 -0700

@kazuho pushed 1 commit.

89a0171ca79c8846ea72749f819a4d52af64b824  wordwrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3157/files/175e7ddf52fd32aec9b24ad37214a35df99c8230..89a0171ca79c8846ea72749f819a4d52af64b824