Stateless reset oracle defense

[martinthomson]

After a bunch of discussion on this point, I think that the conclusion is that the only effective defense against being used as a stateless reset oracle is to ensure that an attacker can't influence choice of server instance that a packet arrives at.

If you have a cluster, there's a huge advantage in being able to reset a connection if a packet arrives for a connection you don't know about. It is often the case that this is because the instance that handled the connection is gone, or the routing in the cluster has shifted so that the connection ID now points at a different instance. In both cases, not sending a reset means that the connection will hang around being useless until it times out.

The problem is that if you have a cluster arrangement where instances can be directly targetted by an attacker, they can use one instance as a stateless reset oracle. Send that instance packets with the desired connection ID and they get back a token that they can use to kill the legitimate connection.

The best (and perhaps only) defense we have here is to recommend that clusters be arranged so that any group of instances that share a key cannot be individually targetted by an attacker without changing the connection ID.

This also means that the instance ID notion isn't that useful, except perhaps as a means of providing key separation between different clusters. Removing that from the draft will simplify things.

[mikkelfj]

There is another possible defense which also ties into allowing middleboxes to help prevent DDos attacks:

Including a small checksum in the header which might be successfully compromised every 64 attempt or so, but infrequent enough to support signficant traffic filtering. This checksum could be few bits in the header or the packet number.

The connecting client and the cluster will understand the checksum but without on-path access to an existing packet an attack will fail with signficant probability as it will be filtered similar to other DDoS attacks.

DDoS attacks are extremely common and frequently take down major infrastructure so there is a lot of value in being able to filter out those attack packets before they reach the endpoint.

[martinthomson]

I think that we should consider two fixes here. As @mikkelfj says, we don't have any proof of receipt in a stateless reset, and that makes this problem much worse. The challenge there is that endpoints don't typically remember the last packet they sent.

[martinthomson]

We discussed the secondary defense in Kista and concluded that any defense we might provide would be defeated easily by an attacker because the stateless reset oracle attack already depends on the attacker seeing packets for the connection. The attacker would consequently have the same information (if not more) than an endpoint that just lost state. We'll concentrate on the description of in-cluster routing defenses.