Subject: [quicwg/base-drafts] How many datagrams can a client send prior to validating the path? (#2135)

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Dec 2018 17:19:15 -0800

To avoid it being used as a DDoS attack vector, we forbid the server from sending more than three datagrams before the path is validated during the handshake.

Do we need similar safeguard for the number of datagrams that a client may emit before it sees a packet from the server? IMO, it might be worth considering, due to the following reasons:

* The attack vector exists. For example, an attacker can inject a DNS response for a huge website to a DNS server. Then, clients would start sending 0-RTT packets to the victim.
* The number of packets that the client can send prior to path being validated was one for TCP. The QUIC transport draft is silent about the limit (though INITCWND would practically become in play here).

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 01:13:45 -0800

We limit amount of bytes now, not number of packets, no?

If we limit the client, it would need to be a rate limit, otherwise it would never be able to connect again later when network conditions improve.

I'm not sure it makes sense to have a MUST limit on client, as there can be many deployments types with different attack vectors. DNS might not be in the equation. However, obviously a client should not saturate a link on connection retries.

-- 
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/2135#issuecomment-446895657

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 01:23:25 -0800

> We limit amount of bytes now, not number of packets, no?

That's a good point. This is not a reflection attack (unlike the server's packets) and therefore it makes more sense to define a limit using number of bytes.

> If we limit the client, it would need to be a rate limit, otherwise it would never be able to connect again later when network conditions improve.

IMO it can be a fixed number of bytes that can be transmitted in one RTO. For example, "a client SHOULD NOT send more than 3 * MTU bytes per every retransmission timeout, until it receives a packet from a server."

-- 
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/2135#issuecomment-446898698

---

From: ianswett <[email-masked]>
Date: Thu, 13 Dec 2018 06:03:49 -0800

My thinking was that the initial CWND was a sufficient limit.

-- 
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/2135#issuecomment-446979032

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Dec 2018 21:16:09 -0800

@ianswett If that's the consensus, I am happy to accept it (I do not have a strong opinion here).

-- 
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/2135#issuecomment-447725212

---

From: ianswett <[email-masked]>
Date: Mon, 17 Dec 2018 08:33:39 -0800

That's what I remember us arriving at before.  But I'm happy to have it explicitly stated if it's 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/issues/2135#issuecomment-447908976