Subject: [quicwg/base-drafts] Server's first flight should be capped by INITCWND (#3639)

From: Kazuho Oku <[email-masked]>
Date: Fri, 08 May 2020 18:45:14 -0700

When the client has a large first flight (post-quantum, or 0-RTT), it can send 10 packets at once.

But that does not mean that the server can immediately send as much as 3x it receives in response, because that is above the INITCWND - the initial assumption about the network capacity.

Things to be considered here are:
* Server cannot rely on CC until the client's address is validated, because an attacker might spoof Initial ACKs
* At the very least, server needs to send one Initial in response to every client Initial packet _not_ containing ACKs, otherwise the handshake might fail when there is hevy loss.

Based on this observation, to me it seems that the easiest way of going forward would be to state that the amplification limit changes from 3x to 1x once the amount of data being sent by the server reaches INITCWND.

Disclaimer: this issue popped up while trying to find out a response to @rmarx's claim that quicly sends 3x that is above INITCWND, when the client sends a large amount of 0-RTT data.

-- 
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/issues/3639

---

From: ekr <[email-masked]>
Date: Fri, 08 May 2020 19:28:35 -0700

> Server cannot rely on CC until the client's address is validated, because an attacker might spoof Initial ACKs.

Just to clarify, only an on-path attacker can do this, right?

-- 
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/issues/3639#issuecomment-626091105

---

From: ianswett <[email-masked]>
Date: Fri, 08 May 2020 19:32:27 -0700

I agree it should be limited to INITCWND.

Here's how I read(and intended to write) the text:
 1) Congestion control always applies, because I don't know of anywhere we say otherwise.
 2) In addition, prior to address validation, the amplification limit of 3x also applies on the server side.

Init CWND section: https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-recovery.md#initial-and-minimum-congestion-window-initial-cwnd

-- 
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/issues/3639#issuecomment-626091587

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 08 May 2020 21:07:07 -0700

@ekr 
> Just to clarify, only an on-path attacker can do this, right?
 
An off-path attacker can do that. An attacker can easily guess the packet number that the server uses, and spoof an ACK without actually receiving a packet from the server. Note also that there is no guarantee that there would be enough entropy in server-generated CID, even though a server can generate CIDs in such a manner. That's why we postpone the validation of the path until the server receives a Handshake packet.

@ianswett I think I agree with you that the limit can be defined as `min(3x, CC)`.

-- 
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/issues/3639#issuecomment-626101974

---

From: ianswett <[email-masked]>
Date: Sun, 10 May 2020 13:08:41 -0700

Thanks @kazuho PTAL at PR #3640 and see if that clarifies this issue or if something else is necessary.

-- 
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/issues/3639#issuecomment-626382259

---

From: ianswett <[email-masked]>
Date: Wed, 13 May 2020 06:09:01 -0700

Closed #3639 via 010574ee63c0cc9af3ed84758e91e13beffe55bf.

-- 
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/issues/3639#event-3331984476

---

From: ianswett <[email-masked]>
Date: Wed, 13 May 2020 06:10:49 -0700

Reopened #3639.

-- 
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/issues/3639#event-3331992838

---

From: ianswett <[email-masked]>
Date: Wed, 13 May 2020 06:10:52 -0700

At the editor's meeting, we concluded that the pseudocode did not represent the current text about re-arming the PTO alarm.  I merged the first PR because I think it's a nice clarification and I'll send out a PR for the pseudocode.

-- 
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/issues/3639#issuecomment-627973461

---

From: ianswett <[email-masked]>
Date: Tue, 19 May 2020 15:33:27 -0700

Closed #3639 via #3653.

-- 
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/issues/3639#event-3353963601