Subject: Re: [quicwg/base-drafts] Authenticate Retry (#1710)

From: Juha-Matti Tilli <[email-masked]>
Date: Wed, 05 Sep 2018 20:53:43 -0700

I'm somewhat surprised by the anti-middlebox attitudes here. Don't you realize that practically every single device in the Internet is behind a middlebox?

For QUIC to work, a middlebox needs to allocate state for the UDP connection. Thus, every single UDP packet potentially creates state, requiring memory. If there are lots of UDP packets (think about the equivalent of TCP SYN flood in QUIC), the memory of the middlebox will be quickly exhausted.

The only form of saving the middlebox from an out-of-memory condition is if the middlebox can authenticate the client's willingness to fully open the connection before allocating any memory. Thus, the middlebox needs to send a RETRY packet to the client. This middlebox sending a RETRY packet is exactly what you're planning to prevent here by authenticating retry.

It's not only the endpoint that needs to be protected from flooding attacks. The middlebox needs to be protected also.

-- 
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/1710#issuecomment-418956237

---

From: Lars Eggert <[email-masked]>
Date: Thu, 06 Sep 2018 03:35:11 -0700

If a middlebox sends a RETRY for every new connection, that will kill 0-RTT, no? Because it means that we're back to adding an extra roundtrip all the time.

-- 
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/1710#issuecomment-419046826

---

From: mirjak <[email-masked]>
Date: Thu, 06 Sep 2018 03:38:37 -0700

Not really, this is probably a rare scenarios, e.g. when middlebox is already in some DDoS protection state or if the box would usually only expect out-going connections. 

-- 
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/1710#issuecomment-419047705

---

From: Juha-Matti Tilli <[email-masked]>
Date: Thu, 06 Sep 2018 04:03:08 -0700

Yes, a RETRY sent by a middlebox will add extra roundtrip. However, as @mirjak noticed, the DDoS protection need not be always on. It is possible to enable the RETRY authentication when some percentage (such as 50%) of the memory available for UDP state machines has already been taken by a DDoS attack. I consider it far better to have an extra roundtrip when under an attack than it is to stop accepting new connections due to the out-of-memory condition.

The same thing is true for SYN cookies: they are the fallback, the usual rule is that the server will have the connection parameters stored in memory. SYN cookie will take over the memory only when running out of memory.

-- 
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/1710#issuecomment-419054195

---

From: Lars Eggert <[email-masked]>
Date: Thu, 06 Sep 2018 05:26:34 -0700

I worry that such a feature would effectively always become turned on, either by misconfiguration ("it sounds more secure"), or because the capacity of the path is increased without the box being upgraded, or other such reasons. Sure, in a perfect world, such boxes would be carefully monitored and carefully operated, but that's not really the works we live in. So a highly visible failure (as not accepting new connections) is IMO much preferable to a silent degrading of user experience.

-- 
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/1710#issuecomment-419074546

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Sep 2018 05:57:17 -0700

I agree with @larseggert that middlebox owned by third parties should not be allowed to generate reties. Allowing such behavior will ossify the QUIC protocol, because that would mean that the protocol cannot be upgraded just by modifying the endpoints.

We should forbid such behavior of middleboxes. I would argue for mandating the authentication of retries, if there is a chance of seeing such middleboxes appearing (if we ship QUIC with unauthenticated 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/1710#issuecomment-419083052

---

From: MikkelFJ <[email-masked]>
Date: Thu, 06 Sep 2018 05:59:58 -0700

But it could be done such that some trusted middleboxes could be authorized to do it via key sharing, possibly tied to protocol version.

-- 
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/1710#issuecomment-419083908

---

From: Juha-Matti Tilli <[email-masked]>
Date: Thu, 06 Sep 2018 06:10:16 -0700

@mikkelfj trusted by what? Trusted by the client? Trusted by the server? There are middleboxes in the client side as well, and if such a client side middlebox happens to have even one open port, a DDoS attack could fill the state tables, thus preventing outgoing connections from succeeding if incoming and outgoing connections share the same memory (like they usually do).

I don't agree with @larseggert that a DDoS should cause a visible failure. Usually, the goal is to NOT have a DDoS attack perform a visible failure but rather try as hard as possible to cause silent degrading of user experience. Of course, the ultimate goal would be to have no degradation of the user experience at all, but DDoS attacks are hard to mitigate.

-- 
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/1710#issuecomment-419087088

---

From: MikkelFJ <[email-masked]>
Date: Thu, 06 Sep 2018 06:36:02 -0700

@jmtilli I understand your concern, but an authorized middleware could only be in collaboration with the endpoint that transmits the retry, i.e. the server role. It's hardly practical to have that happen in domestic routers, and such routers would have a hard time doing anything more than dropping new connections - to where should it redirect traffic?

If you have unauthorized retries, a set of hacked domestic routers could force legitimate connections to gravitate towards a single target server - but that can to an extend be guarded by building in protection in tokens.

The connection ID is visible in outbound packets. The initial CID is random, the next is server chosen (but can be absent and replaced by 5-tuple). A client side router need not track the initial CID and can track connection setup over a short timespan. If the CID survives that, it is likely a valid connection, and if not, the situation would not be improved with a retry.

A client side router would never need to hold more than a limited number of connections unless it is proxying for a large org and the state space is much smaller than that of an endpoint proper. Hence, a large router could afford the RAM to hold that many connections.

So the primary problem is server side that receive many connections from many sources.
For peer to peer server networks, client middleware is also a concern, but still I don't see why a client side router would issue a redirect.

-- 
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/1710#issuecomment-419095588

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 15:45:41 -0700

Closed #1710 via #1793.

-- 
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/1710#event-1867046377