OK so let's try this.. If you can show me a linux router can can route 100mbps or more of juno-z.101f.c attack without dropping packets I will be thoroughly impressed :) I am willing to test out any code/patches and settings that you can think of and post some results.. Paul xerox@foonet.net http://www.httpd.net -----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Monday, June 09, 2003 1:59 AM To: xerox@foonet.net Cc: hadi@shell.cyberus.ca; sim@netnation.com; fw@deneb.enyo.de; netdev@oss.sgi.com; linux-net@vger.kernel.org Subject: Re: Route cache performance under stress From: "CIT/Paul" <xerox@foonet.net> Date: Mon, 9 Jun 2003 01:27:48 -0400 Ahah Jamal!! Yes I have tried.. It does absoutely nothing for the constant randomness of packets. It increases the overall distribution of the hash in the cache but it does nothing for the addition of new packets.. Try fowarding packets generated by juno-z.101f.c and it adds EVERY packet to the route cache.. Every one. And at 30,000 pps It destroys the cache because every single packet coming in is NOT in the route cache because it's random ips. So you make packets that do things like this GC the oldest (LRU) routing cache entry. This isn't rocket science, and well behaved flows will still get all the benefits of the routing cache. The only person penalized will be the attacker since his routing cache entries will purge out quickly and as a response to HIS traffic. Nothing you can do No, there are many things we can do. Prove to me that routing caches are unable to behave acceptibly in random source address DoS situations. (I'm not Even sure why this is necessary anyway.. Who would want to add every single src/dst flow to a cache? Because %99 of traffic is well behaved flows, trains of packets. Even the most loaded core routers see flow lifetimes of at least 8 or 9 packets. Even if the flows lasted 3 packets, the input route lookup work saved (source address validation in particular, which requires access to a centralized global table and thus does not scale well on SMP) is entriely worth it. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
