During SYN floods, fallback exclusively to SYN cookies for a small period

[jtl]

Summary

This contains 3 proposed commits:

1. Remove the unused sch parameter to syncache_respond().

2. Access the syncache secret directly from the V_tcp_syncache variable, rather than indirectly through the backpointer to the tcp_syncache structure stored in the hashtable bucket.

This also allows us to remove the requirement in syncookie_generate()
and syncookie_lookup() that the syncache hashtable bucket must be
locked.

3. Add new functionality to switch to using cookies exclusively when we are under attack. This code uses an overflow of a SYN cache hash bucket as a heuristic to detect an attack. When an attack is detected, the code falls back to using SYN cookies only for 15 seconds. If the attack continues, the fall back time is increased exponentially until it reaches a maximum (16 minutes). When an attack is detected, the code logs a message so the user can decide whether any action is necessary.

Test Plan

Tested with a 6Mpps SYN flood. Before the change, CPU was at ~33%, packet loss was quite high, and user-space transfers stopped. After the change, CPU was at ~30%, packet loss was roughly 50% less, and user-space transfers continued.

[gallatin]

sys/netinet/tcp_syncache.c

2403 ↗

(On Diff #62057)

This is kind of tricky. It seems like we'll only detect an extension of the attack and advance the backoff if we refill the syn cache (and hence try to pause) in the same second as the callout was scheduled to run. It seems like under an attack, a callout might run "late" and unpause after the deadline, leading to us never advancing the backoff. Have you considered adding some slop? Or am I missing something?

[jtl]

sys/netinet/tcp_syncache.c

2403 ↗

(On Diff #62057)

Let me describe how the code is supposed to work. You can then let me know if I've somehow managed to write the code incorrectly.

When we detect an overflow, V_tcp_syncache.pause_until is set to time_uptime + a pause time. Once we reach V_tcp_syncache.pause_until, the callout will run and clear the paused flag. If we detect another overflow before V_tcp_syncache.pause_until + the last pause time we used, we will consider it an extension of the same attack.

To give a practical example, assume we detect an overflow at time_uptime = 60. V_tcp_syncache.pause_until will be set to 75. At time_uptime = 75, the callout will run and clear the paused flag. If we detect a new overflow at time_uptime = 80, we will consider it part of the same attack (because 80 is less than 75 + 15) and set V_tcp_syncache.pause_until to 110 (80 + 30). OTOH, if we detect a new overflow at time_uptime = 95, we will consider it a new attack (because 95 is more than 75 + 15) and set V_tcp_syncache.pause_until to 110 (95 + 15).

For another example, assume we detect an overflow at time_uptime = 60. We pause until time_uptime = 75. At time_uptime = 80, we detect another overflow. We will pause until time_uptime = 110 (80 + 30). At time_uptime = 115, we detect another overflow. We will pause until time_uptime = 175 (115 + 60). If we detect another overflow at time_uptime = 225, we will consider it part of the same attack (because 225 is less than 175 + 60).

Does this clear things up? Or, do you think the code works differently than this?

[gallatin]

sys/netinet/tcp_syncache.c

2403 ↗

(On Diff #62057)

Yes, that makes sense.

[rrs]

sys/netinet/tcp_syncache.c

307 ↗

(On Diff #62057)

Any particular reason you did not use callout_init_mtx and just hook the mutex to the callout?

[jtl]

sys/netinet/tcp_syncache.c

307 ↗

(On Diff #62057)

The syncache_pause() function holds this mutex longer than (and uses it to synchronize more than) scheduling the callout. I assumed that associating this with the callout using callout_init_mtx would cause an unnecessary recursive acquisition of the callout when scheduling it; however, I now see that is not the case. I can change this to using callout_init_mtx.

[jtl]

Switch to using callout_init_mtx to let the callout system acquire the pause lock.