lkml.org 
[lkml]   [2006]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Question about tcp hash function tcp_hashfn()
On Wed, May 31, 2006 at 02:12:43AM -0700, David Miller (davem@davemloft.net) wrote:
> I think it will need to be changed nevertheless. Even though this
> hash works on established sockets, it is attackable just like the
> routing hash used to be. If an attacker has sufficient resources, he
> can make hash chains in the TCP established hash table very long. As
> the years pass, it becomes easier and easier for one to have enough
> computing power at their disposal to carry out this kind of attack.

Jenkins hash is very complex compared to tcp XOR one, and even simple
test showed it's bottlenecks in some setups, so it's tuning will be
quite challenging both from mathematical and engineering points of view.

And socket code actually differs from routing cache, since the former is
limited to 64k connections in a time, while routing cache can grow to
unpredictibe sizes.

> So something like Jenkins with a random hash input become more and
> more critical. And this requires some kind of way to rehash, RCU
> table locking opens the door for that. Current locking scheme is
> too tightly bound for that kind of flexibility.
>
> I wish Ben L. would resubmit the TCP hash locking stuff he said he'd
> work on. :)

It was good approach indeed.

--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-05-31 11:47    [W:0.152 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site