Messages in this thread | | | Date | Wed, 19 Aug 1998 20:28:48 +0200 | From | Andi Kleen <> | Subject | Re: Dest Unreach Rate limits, was: Re: Linux 2.1.x showstopper list |
| |
On Wed, Aug 19, 1998 at 04:00:15PM +0200, kuznet@ms2.inr.ac.ru wrote: > Hello! > > > > It is not fixed on vger. The problem is that 2.1 uses the destination cache > > > now to load limit ICMP messages, but dest unreach is send when no suitable > > > destination entry could be computed. > > Andy, could you show me how it is possible to make it? > As I undertsnad now, this problem never existed.
Now when I read the code I must agree with you, I can't see how it could happening. Seems my original analysis was wrong.
But - we had actual reports of floods together with tcpdumps as proof (if you remember it was in the netdev or linux-net thread some months ago that lead to the invention of RTCF_BADROUTE).
Maybe the token bucket filters used are not aggressive enough and should be more limiting.
ICMP always allocating a dest entry for dest unreachs means that an attacker can easily make a linux router thrash its routing cache, which is bad. I see you introduced rt_fast_clean() in your newest patch set, maybe it should be extended to cover dst_entries created by ICMP outputs too.
Cisco seems to take the easy way out BTW for this problem - I hear they just use a configurable global load limit per route that does not care about source addresses. You already implemented such a mechanism. With that an routing cache entry is not strictly necessary (except for a little bit longer lookup time for the ICMP route). icmp_send could just create a "temporary dst_entry" that is not inserted into the routing cache and is freed as soon as the ICMP skb leaves the system.
What do you think about this? ICMP does not sleep until the packet is send off to lower layers, so there is no chance of the dst entry becoming obsolete.
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |