Subject: [quicwg/base-drafts] missing description of what happens when receiving an ACK for an unsent package (#2298)

From: Marten Seemann <[email-masked]>
Date: Sun, 06 Jan 2019 01:16:38 -0800

I can't find text about this case anywhere.

A peer that receives an acknowledgement for a packet that it didn't send should be required to close the connection. I'm not sure which error code to use for that though, none of those currently defined really matches this case, so you'd have to use INTERNAL_ERROR. We might want to consider introducing a more specific error code.

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 06 Jan 2019 10:01:39 -0800

> I'm not sure which error code to use for that though, none of those currently defined really matches this case, so you'd have to use INTERNAL_ERROR.

I think you are expected to use PROTOCOL_VIOLATION in such case. Quoting from editors' draft: _An endpoint detected an error with protocol compliance that was not covered by more specific error codes._

> A peer that receives an acknowledgement for a packet that it didn't send should be required to close the connection.

FWIW, I think that the requirement should be no stronger than "SHOULD if detected", to avoid endpoints memoizing the gaps for the previous 2<sup>31</sup> range. I assume that endpoints would typically just drop packets carrying a PN that is deemed too old.

-- 
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/2298#issuecomment-451761344

---

From: MikkelFJ <[email-masked]>
Date: Sun, 06 Jan 2019 11:28:07 -0800

This is always considered to be an Optimistic ACK attack. The only response is to treat the peer as hostile.

https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.21.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/2298#issuecomment-451767614

---

From: MikkelFJ <[email-masked]>
Date: Sun, 06 Jan 2019 11:32:37 -0800

@kazuho 
> I assume that endpoints would typically just drop packets carrying a PN that is deemed too old.

If an endpoint cannot prove it didn't send the packet, it should just ignore the ACK for that particular packet. The congestion controller should not be sensitive to packets that old, so the Optimistic ACK attack is harmless in this case. Dropping the entire packet containing an ACK with an old packet is likely too strong - ignoring the ACK for the packet is sufficient. If a peer continually sends ACK's for very old packets, that might go under weird behaviour similar to sending too many gaps, and an implementation could decide the peer is being too confused and close the connection with an error.

-- 
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/2298#issuecomment-451767976

---

From: MikkelFJ <[email-masked]>
Date: Sun, 06 Jan 2019 11:34:47 -0800

FYI: the reason this always needs to be treated as hostile (when provable) is because it is the only defence against the potentially very harmful optimistic ack attack. There are very few other other reasons to have gaps in the range, such as when having multiple concurrent transmit queues.

-- 
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/2298#issuecomment-451768120

---

From: Martin Thomson <[email-masked]>
Date: Tue, 08 Jan 2019 23:59:19 +0000 (UTC)

Closed #2298 via #2302.

-- 
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/2298#event-2061665943