Defend against endless Stateless Reset ping-pong #1627
Conversation
This implements the agreed defenses, giving implementations a suite of choices. None of these a non-deterministic, as agreed. Closes #1443.
draft-ietf-quic-transport.md
Outdated
| exhausted limits. | ||
|
|
||
| * An endpoint can set the TTL in the IP header to one fewer than the TTL in the | ||
| packet that it received. Once the TTL reaches zero, any looping ends. |
There was a problem hiding this comment.
This only works if both endpoints do this, right?
There was a problem hiding this comment.
Yeah, it would also work if the Stateless Reset were the same size as the triggering packet (on the assumption that the peer is applying one of the other techniques), but that's pretty marginal, so I'm going to cut this option.
draft-ietf-quic-transport.md
Outdated
| sent and stop generating new Stateless Reset packets once a limit is reached. | ||
| Using separate limits for different remote addresses will ensure that | ||
| Stateless Reset packets can be used for some peers even when other peers have | ||
| exhausted limits. |
There was a problem hiding this comment.
I'm not sure if we discussed this anywhere, but if you're willing to keep some state around for a short period of time, wouldn't the easiest thing be to save the last 16 bytes of the packet (for each remote address), and if they match on two (non-identical) packets, you can be pretty sure that those are Stateless Resets.
There was a problem hiding this comment.
If they use the technique we describe, the input to the calculation for a stateless reset is the connection ID from the inbound packet - and that is randomized in a stateless reset. So no winner there.
draft-ietf-quic-transport.md
Outdated
|
|
||
| * An endpoint can remember the number of Stateless Reset packets that it has | ||
| sent and stop generating new Stateless Reset packets once a limit is reached. | ||
| Using separate limits for different remote addresses will ensure that |
There was a problem hiding this comment.
Would it make sense to suggest "using separate limits" for different DCIDs of the incoming packets in addition to "remote addresses"?
There was a problem hiding this comment.
Further segregating by destination connection ID might work, yes.
draft-ietf-quic-transport.md
Outdated
| to be quickly detected and recovered. In this case, endpoints will need to | ||
| rely on other methods - such as timers - to detect that the connection has | ||
| failed. | ||
| routed. This might also triggering another Stateless Reset in response, see |
draft-ietf-quic-transport.md
Outdated
| will ensure that Stateless Reset packets can be used to close connections when | ||
| other peers or connections have exhausted limits. | ||
|
|
||
| * An endpoint can ensure that every Stateless Reset that it sends is smaller |
There was a problem hiding this comment.
I think it's worth advising that a stateless reset should never be larger than the received packet. This makes this defense unilaterally useful, because at least one side is reducing the size every time.
There was a problem hiding this comment.
That's a good point, and a reason that the TTL defense was removed. I will restructure.
There was a problem hiding this comment.
On second thought: if one peer is remembering, then the problem does eventually go away without size reductions. But it requires that the state is not bound to a connection ID (as @kazuho suggested), it has to be bound to a remote address.
I have restructed the text to emphasize size reduction as the first defense. State is then an alternative.
This implements the agreed defenses, giving implementations a suite of
choices. None of these a non-deterministic, as agreed.
Closes #1443.