Subject: [quicwg/base-drafts] Stateless Reset Eternal Ping Pong (#1443)

From: MikkelFJ <[email-masked]>
Date: Tue, 12 Jun 2018 22:53:35 -0700

Two p2p server systems with compatible CID formats might accidently have a stateless reset routed back and forth between two are more servers that do not understand the packet context and consequently respond with a new reset. This can leave zombie resets spinning forever.

An advanced attacker might be able to take advantage of the above.

What is the motivation for making the reset undetectable in the first place?

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 11:01:22 -0700

I think the "compatible CID formats" piece of this doesn't matter.  The recipient of a short header packet won't be able to identify the CID because the length is unknown.  It will guess the length it probably used (assuming the remainder is payload) and generate a Stateless Reset with a random CID/body.

But yes, in the absence of loss, this will continue forever.  An attacker could start the process with a spoofed source address.  Perhaps a suggestion that endpoints SHOULD limit the number of Stateless Resets they will send to a given address?  If each side sends back even one fewer SR than it received incoming packets, the attacker doesn't get much return from its spoofed traffic.

-- 
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/1443#issuecomment-398842429

---

From: MikkelFJ <[email-masked]>
Date: Wed, 20 Jun 2018 12:22:12 -0700

I think it would be easier to detect resets, but that is apparently not an option.

Rembering source address in a stateless context is not ideal. But exponential decay can be used:

Whenever an endpoint feels the urge to send a reset, it should ignore that urge it with a probability x, 0 < x <= 1 such that reflected resets will eventually die out.

-- 
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/1443#issuecomment-398866569

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 20 Jun 2018 22:15:58 +0000 (UTC)

One way of fixing this is to forbid sending a stateless reset unless the size of the stateless reset will be smaller than the packet that has triggered the stateless reset.

Note that endpoints are already required to send a large packet after quiescence, if they want to see stateless reset in case the server has lost state. See the following statement in [section 6.10.4](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.6.10.4):
> An endpoint SHOULD NOT send a stateless reset that is significantly larger than the packet it receives.

-- 
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/1443#issuecomment-398915066

---

From: MikkelFJ <[email-masked]>
Date: Wed, 20 Jun 2018 22:49:41 -0700

> One way of fixing this is to forbid sending a stateless reset unless the size of the stateless reset will be smaller than the packet that has triggered the stateless reset.

This would require a significant size reduction which could be observable (I still don't understand why the reset must be hidden). It would also not address transmissions of many very small messages in separate packets.

I think the statistically dropping every N'th packet, say 4'th, would work well because in most cases the reset happen as expected, and when not, it happens on retransmission just as if a packet were lost. 

-- 
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/1443#issuecomment-398983982

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Jun 2018 00:11:05 -0700

> I think that statistically dropping every N'th retry packet, say every 4'th, would work well because in most cases the reset happen as expected, and when not, it happens on retransmission just as if a packet were lost.

I might argue that statistically ignoring a packet goes against the goal of stateless reset; i.e. provide a signal that the connection has been reset *as early as possible, before timeout happens*.

IMO, the method to fix the issue should be either remember the peer address (as has been suggested by @MikeBishop in https://github.com/quicwg/base-drafts/issues/1443#issuecomment-398842429) or to limit the size (as I have suggested in https://github.com/quicwg/base-drafts/issues/1443#issuecomment-398915066).

-- 
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/1443#issuecomment-398999726

---

From: Mike Bishop <[email-masked]>
Date: Thu, 21 Jun 2018 14:25:40 -0700

Honestly, I'm inclined toward both/and.  @mikkelfj, nothing says it needs to be dramatically smaller.  SR currently has to be at least 37 octets long; with a requirement that it also be smaller than the triggering packet, it's guaranteed to die eventually.

An implementation can choose the size of SR it sends back based on how concerned it is; if it usually selects a size that's 60-80% the size of the packet that triggered it, the ping-pong will die out after ~6 round trips.  Select smaller, and it dies even more quickly.  Couple that with permission (not a requirement) for an implementation to keep a little state to short-circuit these and I think it's sufficient.

-- 
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/1443#issuecomment-399248516

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Jun 2018 00:36:20 -0700

I think that I'm with @MikeBishop here.  37 octets is quite a bit bigger than the smallest packet that might be sent, and if there is at least a chance of getting a reset back, then connections will die more quickly, though it might only be in the aggregate.  Advising reduced probability when the reset is not smaller than the packet it responds to seems right.

If you consider that we want to have resets of varying size, that's probably good, because you don't end up clamping resets to the size of the incoming packet.  I'm sure that you can devise a simple scheme that randomizes probability as a function of the increase in packet length over the incoming packet.

-- 
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/1443#issuecomment-401273965

---

From: MikkelFJ <[email-masked]>
Date: Fri, 29 Jun 2018 01:52:53 -0700

I'm all for reducing reset size, but it can't stand alone as @martinthomson also summarized. Probability is needed for small packets.

-- 
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/1443#issuecomment-401292527