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.
