Re: performance issues (nat / conntrack)

[don-nf@isis.cs3-inc.com (Don Cohen)]

Patrick Schaaf writes:
 > Don,
 > 
 > (hope you don't mind me replying on-list)
No, I just hope the rest of the list doesn't mind.

 > The relative slowness of conntrack vs. nonconntrack doesn't matter in the
 > real world. I can reproduce it in artificial tests, but in reality, the
 > arrival rates for new connections are lower. The reason, at least for me,
 > is that I parallelize on multiple boxes long before conntrack reaches its
 > breaking point, and I do that for different reasons (resilience and the
 > other workload the boxes tend to have, like user level proxying.)
It seems to me like a real problem when you're under attack.
It means that a syn flood at a relatively low rate is effective.
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 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.  The attacker can still attack some particular
bucket(s) (which doesn't do a lot of good - he's denying service to
some small number of customers but has no control over which ones),
but not the whole machine. 

 > >  > As for theories, the last time, we almost agreed that the hash function
 > >  > is very bad. Nobody did confirm that feeling, though.
 > > What's wrong with the hash function?
 > 
 > It's suspected to be bad. Chains are suspected to become long. Bucket
 > occupation is suspected to have high variance. Nobody checked, or at
 > least nobody reported the results of such checking.
To me something like the sum of IP's and ports all mod something
that is not a multiple of 2 seems ideal.  I suppose it's something
like that.