route cache overflow

Andre Uratsuka Manoel writes:
 > Hello,
 > 
 > It seems that no resolution was found for the route cache DoS issue
 > (am I wrong here?).

 Well we see different performance for different flow lengths. The numbers 
 we've see is 1 packet per flow is .22 (22%) of single flow for packet 
 forwarding. Decreasing hash chain during DoS we could increase the t-put 
 to .34 of single flow. Still Linux is very usable as it is very seldom
 in real scenarios that there is 100% DoS at all interface.

 > I was wondering, and I'd like to persue this line of thought if you
 > don't consider this stupid: wouldn't it be better, when we find that
 > the machine is under DoS to avoid creating route cache entries instead
 > of simply trying to drop entries that exist?

 I did some experiments to make the route hash per device but didn't see 
 any performance wins compared to the global hash but for policy control 
 and tuning it would probably improve things with per dev hash.
 
 ftp://robur.slu.se/pub/Linux/net-development/dhash

 But the problem is how to define/find DoS which is in reality mixed with 
 real traffic. I'm getting to think we can not have any special DoS 
 treatment at route level as this would open for new DoS attacks. We have
 to assume traffic is sane.

 > Couldn't we create entries only once for every 1<<n packets on
 > ip_route_input_slow so that flows with many packets will have route
 > cache entries created with higher probability than flows with very
 > little connections. The n variable could be adjusted according to
 > perceived DoS-ness.

 We have done a lot job already getting the skb into the CPU cache and 
 also we must look up the address to verify if it belongs to a flow or not. 

 It seems ipv6 does not create hash entries as ipv4 and should be more
 tolerant in this aspect but ipv6 has another major issue be design
 as the link nets have 2^64 addresses. Neighbor entries can overflow 
 any table.

 Also it might be interesting to see what other lookup algorithms can do.
 Working on some LPC-trie (level path compresses seach tree) code hoping 
 to able to test this for lookup someday.

 Cheers.
						--ro