Subject: [quicwg/base-drafts] Retransmit server initial upon second Initial (#3080)

From: ianswett <[email-masked]>
Date: Sun, 06 Oct 2019 18:15:36 -0700

When the second duplicate client Initial is received, the server SHOULD retransmit the contents of it&#39;s Initial to speed up the handshake.

Fixes #3078
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Retransmit server initial upon second Initial

-- File Changes --

    M draft-ietf-quic-recovery.md (5)

-- Patch Links --

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

---

From: Nick Banks <[email-masked]>
Date: Sun, 06 Oct 2019 18:19:24 -0700

nibanks approved this pull request.

This is definitely an improvement. Thanks for writing it up! In addition to this, should we have text that says the client should/may immediately retransmit its initial packet if it gets a handshake packet it can't 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/3080#pullrequestreview-297874799

---

From: ianswett <[email-masked]>
Date: Sun, 06 Oct 2019 20:49:45 -0700

@ianswett pushed 1 commit.

2e7bff7670dfde7068be546704bd33b5f74e0f7a  Update draft-ietf-quic-recovery.md

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

---

From: ianswett <[email-masked]>
Date: Sun, 06 Oct 2019 21:01:48 -0700

18c9bba3487c51d85f4797eb8dc4215ebbb728f3  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/2e7bff7670dfde7068be546704bd33b5f74e0f7a..18c9bba3487c51d85f4797eb8dc4215ebbb728f3

---

From: MikkelFJ <[email-masked]>
Date: Mon, 07 Oct 2019 01:31:18 -0700

> that says the client should/may immediately retransmit its initial packet if it gets a handshake packet it can't decrypt?

That could be an attack vector since you could send small invalid handshake packets. Not sure how efficient such an attack would be and we don't try too hard to avoid problems at this stage, as long as isn't an efficient amp attack.

-- 
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/3080#issuecomment-538894292

---

From: MikkelFJ <[email-masked]>
Date: Mon, 07 Oct 2019 01:32:12 -0700

mikkelfj commented on this pull request.

> @@ -508,6 +508,12 @@ until it is certain that the server has finished its address validation
 probe timer if the client has not received an acknowledgement for one of its
 Handshake or 1-RTT packets.
 
+When a server receives duplicate CRYPTO data in an Initial packet after sending
+its Initial flight, it can assume the client did not receive all Initial CRYPTO
+data. To speed handshake completion, it SHOULD retransmit all unacknowledged
+Initial CRYPTO data subject to the path validation limits.  After doing so,
+the PTO is re-armed.
+

Can we formulate duplicate crypto a bit more precise? Does it mean a valid crypto packet with the same packet number as seen before?

-- 
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/3080#pullrequestreview-297970866

---

From: ianswett <[email-masked]>
Date: Mon, 07 Oct 2019 08:03:05 -0700

ianswett commented on this pull request.

By CRYPTO data, I meant data sent in CRYPTO frames, which is why I used uppercase for CRYPTO.

-- 
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/3080#discussion_r332071290

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Oct 2019 16:45:49 -0700

martinthomson commented on this pull request.

The server can't arm the PTO prior to confirming that the path is valid.

-- 
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/3080#pullrequestreview-300408487

---

From: ianswett <[email-masked]>
Date: Thu, 10 Oct 2019 19:10:25 -0700

The server can't send if it's limited by the amplification factor, but the PTO can be armed otherwise.

-- 
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/3080#discussion_r333802526

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Oct 2019 20:13:09 -0700

The way I read this, it says that you retransmit then you re-arm the PTO timer.

I think that you mean to say that when the path is validated, you can re-arm the PTO timer after retransmitting the CRYPTO data, but that's not what it says.

-- 
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/3080#discussion_r333811560

---

From: ianswett <[email-masked]>
Date: Fri, 11 Oct 2019 13:51:07 -0700

ebb854354ccdc67a64e7e124f8af9c9ac52ba238  Reword the paragraph

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/18c9bba3487c51d85f4797eb8dc4215ebbb728f3..ebb854354ccdc67a64e7e124f8af9c9ac52ba238

---

From: ianswett <[email-masked]>
Date: Fri, 11 Oct 2019 13:53:07 -0700

The PTO can be armed prior to path validation, but the text said it always was, which is wrong, so I reworded the paragraph.

-- 
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/3080#discussion_r334170140

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Oct 2019 15:46:44 -0700

I'm ambivalent on this one, but this doesn't seem like it would be hurtful.

+When a server receives duplicate Initial CRYPTO data when there
+is unacknoweledged Initial CRYPTO data, it can assume the client did not

```suggestion
is unacknowledged Initial CRYPTO data, it can assume the client did 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/3080#pullrequestreview-301575783

---

From: ianswett <[email-masked]>
Date: Tue, 22 Oct 2019 15:42:53 -0700

20435cf19a7461bf050033a0b04aa452afcde980  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/ebb854354ccdc67a64e7e124f8af9c9ac52ba238..20435cf19a7461bf050033a0b04aa452afcde980

---

From: ianswett <[email-masked]>
Date: Tue, 22 Oct 2019 15:59:41 -0700

02080b75875107b2d0b6a17b9a7b304c714f0502  Update based on interim feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/20435cf19a7461bf050033a0b04aa452afcde980..02080b75875107b2d0b6a17b9a7b304c714f0502

---

From: ianswett <[email-masked]>
Date: Tue, 22 Oct 2019 16:01:57 -0700

f1c94bf510b5e06ec4c739241bce996bc03037dd  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/02080b75875107b2d0b6a17b9a7b304c714f0502..f1c94bf510b5e06ec4c739241bce996bc03037dd

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 19:22:47 -0700

40cc163f42b57fb5ec514174e6173e38475359fc  line lengths

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/f1c94bf510b5e06ec4c739241bce996bc03037dd..40cc163f42b57fb5ec514174e6173e38475359fc

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 19:26:11 -0700

b9c84234ab1e9c6c1fbc61e181885491612d87d1  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/40cc163f42b57fb5ec514174e6173e38475359fc..b9c84234ab1e9c6c1fbc61e181885491612d87d1

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 19:26:47 -0700

6851dbb3bfed9d4695abfd798a790addaaaa5775  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/b9c84234ab1e9c6c1fbc61e181885491612d87d1..6851dbb3bfed9d4695abfd798a790addaaaa5775

---

From: Nick Banks <[email-masked]>
Date: Wed, 23 Oct 2019 20:32:40 -0700

I think the latest text looks great. Thanks @ianswett for putting it together.

-- 
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/3080#issuecomment-545727565

---

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

bdcd8c75f213ddacd24f3450d69b623c3d814bc1  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3080/files/6851dbb3bfed9d4695abfd798a790addaaaa5775..bdcd8c75f213ddacd24f3450d69b623c3d814bc1

---

From: martinduke <[email-masked]>
Date: Mon, 28 Oct 2019 15:11:44 -0700

After thinking it through, this is a good choice.

The downside is the client might have a bad initial PTO. But without this optimization, upon receipt of another client hello I'll just send more ceritificate data that was blocked by the amplification limit, data that is probably useless if the server hello has been lost. Far better for me to send the server hello again 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/3080#issuecomment-547167765

---

From: martinduke <[email-masked]>
Date: Mon, 28 Oct 2019 15:11:53 -0700

martinduke 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/3080#pullrequestreview-308179298

---

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

1ae98696a9afd8bd6adbe62661ec2adc74b02c14  Update draft-ietf-quic-recovery.md

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

---

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

kazuho commented on this pull request.

> @@ -519,6 +519,26 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.

As there's a chance where a client receives an 1-RTT packet before it receives Initial and Handshake packets, I think it'd be more natural to cover that case too.

Maybe s/When a client receives Handshake packets/When a client receives Handshake or 1-RTT packets/.

> @@ -519,6 +519,26 @@ bytes.
 Initial packets and Handshake packets may never be acknowledged, but they are
 removed from bytes in flight when the Initial and Handshake keys are discarded.
 
+### Speeding Handshake Completion
+
+When a server receives duplicate Initial CRYPTO data, it can assume the client
+did not receive all Initial CRYPTO data or the client's estimated RTT is too
+small. When a client receives Handshake packets prior to obtaining Handshake
+keys it may assume some or all of the server's Initial packets were lost.
+
+To speed handshake completion, either peer MAY send a packet containing
+unacknowledged Initial CRYPTO data subject to the path validation limits, as
+though the PTO expired. A client MAY send an ack-eliciting packet with no
+CRYPTO data if all Initial data has been acknowledged.  The PTO can only be
+shortened once in this way. Subsequently, the PTO uses the normal calculation
+with exponential backoff.

Am I correct in assuming that this way of setting the PTO is to be used *only until* an endpoint learns the RTT?

Consider the case where the server sends three datagrams (Initial1(CRYPTO+ACK), Initial2(CRYPTO), Handshake1(CRYPTO)) as its first flight. When Initial2 gets dropped but other packets are received by the client, the client would have an RTT estimate (as it processes the ACK in Initial1), but also have an undecryptable Handshake packet too, which this section discusses about.

My intuition is that the provision of this paragraph should not be invoked in such a case, as RTT has already been learnt.

If that is the case, it might be a good idea to clarify that the section is about estimating PTO until an RTT estimation is obtained.

-- 
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/3080#pullrequestreview-308223551