Re: performance issues (nat / conntrack)

[Patrick Schaaf <bof@bof.de>]

> But I don't think that the hash function is the problem in that case.
> In fact, there is no hash function that solves that problem, since the
> attacker can always feed you data that ruins the hash function, unless
> of course you want the function to differ from one machine to the next
> and in effect be another secret.

I agree that such secret localization is the only chance you have
against attacks on the hashes. It may even be doable.

> I suggest instead that the hash lookup be limited to a small number of
> probes.  If not found in, say, 10 probes, act like it's not there and
> the table is full.

For each packet, there is exactly one hash chain to look up. So you end
up limiting the _length_ of the single chain when creating new entries.

To the user, that would mean random breakage long before saturation,
for the sake of handling a hypothetical attack.

Thus, you also need an "am I under attack" algorithm first, and enable
that limiting behaviour only when that algorithm triggers.

In practise, the denial of service attacks I've seen fill your slowest
link, and there's nothing you can do about that except rate limit on
the _other_ side.

best regards
  Patrick