Subject: Re: Possible DoS with 6RD border relay

From: Brent Cook <[email-masked]>
Date: Wed, 4 Jan 2012 13:26:04 -0600

On Wednesday, January 04, 2012 11:53:20 AM Eric Dumazet wrote:
> Le mercredi 04 janvier 2012 à 11:35 -0600, Brent Cook a écrit :
> > On Wednesday, January 04, 2012 11:25:31 AM Eric Dumazet wrote:
> > > Le mercredi 04 janvier 2012 à 11:02 -0600, Brent Cook a écrit :
> > > > I forgot to mention, I'm testing 3.2 rc7:
> > > > 
> > > > Linux target1 3.2.0-7-generic #13-Ubuntu SMP Sat Dec 24 18:06:57 UTC
> > > > 2011 x86_64 x86_64 x86_64 GNU/Linux
> > > > 
> > > > but the same behavior occurs with 2.6.35
> > > 
> > > Please check :
> > > 
> > > grep . /proc/sys/net/ipv6/route/*
> > 
> > /proc/sys/net/ipv6/route/gc_elasticity:9
> > /proc/sys/net/ipv6/route/gc_interval:30
> > /proc/sys/net/ipv6/route/gc_min_interval:0
> > /proc/sys/net/ipv6/route/gc_min_interval_ms:500
> > /proc/sys/net/ipv6/route/gc_thresh:1024
> > /proc/sys/net/ipv6/route/gc_timeout:60
> > /proc/sys/net/ipv6/route/max_size:4096
> > /proc/sys/net/ipv6/route/min_adv_mss:1220
> > /proc/sys/net/ipv6/route/mtu_expires:600
> > 
> > This is a system with 8GB of ram.
> > 
> > If I modify gc_thresh to be >= the number of bits the client varies, the
> > system works OK:
> > 
> > /proc/sys/net/ipv6/neigh/default/gc_thresh1:128
> > /proc/sys/net/ipv6/neigh/default/gc_thresh2:512
> > /proc/sys/net/ipv6/neigh/default/gc_thresh3:1024
> > 
> > root@target1:~# echo 200000 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
> > root@target1:~# echo 200000 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
> > root@target1:~# echo 200000 > /proc/sys/net/ipv6/neigh/default/gc_thresh3
> > 
> > But it seems to be a losing battle since the client has a delegated
> > prefix of /64.
> 
> I am not sure of this.
> 
> Try to change /proc/sys/net/ipv6/route/max_size
> 
> and /proc/sys/net/ipv6/route/gc_thresh
> 
> [To something larger than number of in flight packets on your gateway ]

Thanks for the suggestion, I tried 200k:

root@target1:~# echo 200000 > /proc/sys/net/ipv6/route/max_size 
root@target1:~# echo 200000 > /proc/sys/net/ipv6/route/gc_thresh 

It did not seem to improve the behavior - once neighbor table overflow hits, 
things go downhill.  So far, only modifying the neighbor cache threshold seems 
to improve things.