Subject: [quicwg/base-drafts] Optimistic ACK in early handshake (#2192)

From: MikkelFJ <[email-masked]>
Date: Sat, 15 Dec 2018 02:49:53 -0800

An endpoint might want to increase bandwidth by performing optimistic ACK's. The protection is to create gaps in the PN space. If such gaps are created in early handshake, a man on the side can inject ACKs where there are gaps causing the connection to fail.

A recommendation could be to only create gaps when this attack is no longer possible, but this would give the optimistic ACK attacker an advantage.

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

---

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

This sounds like a piecemeal solution to Initial injection attacks, therefore I would prefer not to do that. IMO, just having a blanket allowance (#2141) would be fine.

-- 
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/2192#issuecomment-447723431

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Dec 2018 09:02:10 +0000 (UTC)

Nothing I mention is a solution. #2141 just opens the optimistic ACK attack which is not an injection attack. Maybe it is not problematic - I don't know how much you can manipulate cnwd while doing handshake.

-- 
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/2192#issuecomment-447769706

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Dec 2018 01:04:43 -0800

Note that the current text: " An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION (see Section 10.3)." would need expansion to deal with blanket allowance of rejection in handshake.

-- 
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/2192#issuecomment-447770441

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Dec 2018 09:23:35 +0000 (UTC)

Does optimistic ACKs really work in QUIC? I thought renege on ACKs where not allowed, but I can't find any text on that currently. Thus, if you actually have a packet loss, the whole connection will be screwed as you can't get retransmission of the lost 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/2192#issuecomment-448526466

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Dec 2018 02:44:04 -0800

Optimistic ACKs are an attack, not something permitted. But it also isn't renege as I understand the word since it ACK's something that was never send as opposed to regretting ACK'ing something earlier ACK'ed. The attack can cause a client to get all the bandwidth that a server intended to be shared across many clients.

To defend against optimistic ACK's, QUIC explicitly states that a connection should be closed if it sees an ACK on a packet that wasn't sent (at least for as long as packets are still tracked and can affect the congestion window). The problem is that this defence can be exploited by another attack which is an injection attack. And the defence against this injection attack would be to not defend against optimistic ACKs, at least while the injection attack is possible.

-- 
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/2192#issuecomment-448550411

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Dec 2018 03:07:18 -0800

@gloinul 
> Thus, if you actually have a packet loss, the whole connection will be screwed as you can't get retransmission of the lost data.

I don't think (hope not) that there is text preventing acknowledging a packet multiple times, but it SHOULD not be acknowledge again once an endpoint knows that the peer received the acknowledgment.

As to renege in the current text:

section 19.3.: 
> QUIC acknowledgements are irrevocable. Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK frame. This is unlike TCP SACKs ([RFC2018]).

section 21.3.:
> An endpoint that acknowledges packets it has not received might cause a congestion controller to permit sending at rates beyond what the network supports. An endpoint MAY skip packet numbers when sending packets to detect this behavior. An endpoint can then immediately close the connection with a connection error of type PROTOCOL_VIOLATION (see Section 10.3).

-- 
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/2192#issuecomment-448556712

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Dec 2018 14:54:07 +0000 (UTC)

Yes, having multiple ACKs talking about the same PN is fine to my understanding. With renege I meant changing the ACK for a PN from received, to missing. Once you have set a PN to have been received, the sender should consider it received. That is why I don't think the optimistic ACK works if the receiver cares about the data it retrieves from the server. If the receiver lies just to consume as much sender resources as possible, then that is a different issue that I agree is not impacted by my comment.

-- 
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/2192#issuecomment-448623058

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Dec 2018 07:15:02 -0800

Your point is that if the attacker optimistically ACKs a packet that it has all reasons to believe it will receive, but then packet gets dropped by some router, then the attacker cannot get its data later. Like crying wolf once too many. But if it doesn't care about the occasional loss, it can get better bandwidth, for example to starve out other users.

But if the loss is unlikely, and when it happens, is likely to just be a lost video frame, then you might watch better netflix on the dorm than all of your friends. If the connection has a vital loss, you just reconnect.

The real question here is the bandwidth can be manipulated enough to matter, while doing handshake. For example, one might want to drop RTT history once new data is available post handshake.

-- 
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/2192#issuecomment-448630342