Re: [PATCH + RFC] neighbour/ARP cache scalability

[Tim Gardner <timg@tpi.com>]

On Tue, 2004-09-21 at 10:04, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <Pine.LNX.4.44.0409211856260.9906-100000@netcore.fi> (at Tue, 21 Sep 2004 18:58:05 +0300 (EEST)), Pekka Savola <pekkas@netcore.fi> says:
> 
> > This still doesn't take a stance on rate-limiting the ND/ARP packets,
> > in case that there still is enough memory, but some kind of attack is
> > clearly underway.  Should it still be done?  Consider 100Kpps of
> > router-generated ARP/ND probes -- not good!
> 

Detecting an attack would require some kind of heuristic in the core
router code. I believe that logic is better suited for an iptables
filter. Why burden well guarded machines that are unikely to experience
this kind of attack? I think the only thing NUD should do is limit the
absolute number of NUD entries that it can create. Give it a sysctl knob
for large networks, but make the default something reasonable (like
2K).  

I've developed a variant of the Port Scan Detector (PSD) iptables filter
that combats this very problem. It only allows so many destination
IP/Port pairs from a given address to be opened over time. This limits
the rate at which connections can be opened as well as the absolute
number. For example, on my edge routers I set the policy that no single
IP source address can create more then 64 connections within a 30 second
sliding window. This has made a huge impact on the ARP storms that our
network used to experience.

rtg

-- 
timg@tpi.com http://www.tpi.com
406-443-5357(MT) 503-601-0234(OR)