Re: introducing a limit for the number of prefixes/routes from RA (IPv6)

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 11 May 2011, at 16:19 , S.P.Zeidler wrote:
> at present, there is no limit to the number of prefixes (and thus, routes)
> that a IPv6 autohost will accept via router advertisements.
> 
> If an attacker floods the net with random RA announcements, at several
> thousand (for my laptop: 5000 and a bit) the machine slows down to not
> even updating time any longer. As soon as the flood stops, at least in the
> case I tested, the machine fully recovered (apart from very unseemly
> ifconfig output, and ifconfig taking noteable time to complete).
> Daemons may not be coping with the number of addresses gracefully, too.
> 
> Limiting just the number of routes processed already fixes the slowdown,
> but not the issues network programs may run into.
> 
> In order to deal with this, I propose to set a limit on the number of
> prefixes and routes an autohost will accept. I name routes separately
> since RFC4191 provides a mechanism for sending routes additionally to
> prefixes; we do not yet support this but may do so in the future.
> 
> A proposed patch is at http://www.netbsd.org/~spz/rtadv-limit.diff
> 
> Comments? Improvements?

While I only know enough to be dangerous, the problem is really unlikely
to be routes (i.e. things installed in the routing table) per se.  5000
was a relatively reasonable number of routes 20 years ago when machines
running this code were way, way slower than they are now.  I commonly test
the kernel routing table with a 1 million prefix dump obtained from someone's
core router.

I think instead that the problem is with IPv6-specific code like this:

struct nd_prefix *                    
nd6_prefix_lookup(struct nd_prefixctl *key)
{                                     
        struct nd_prefix *search;     
                                      
        LIST_FOREACH(search, &nd_prefix, ndpr_entry) {
                if (key->ndpr_ifp == search->ndpr_ifp &&
                    key->ndpr_plen == search->ndpr_plen &&
                    in6_are_prefix_equal(&key->ndpr_prefix.sin6_addr,
                    &search->ndpr_prefix.sin6_addr, key->ndpr_plen)) {
                        break;        
                }                     
        }                             
                                      
        return (search);              
}  

A linear list like that is appropriate when there is normally just
one or two of something but where, only in some extreme corner case,
there might be a dozen or two manually configured, like IPv4 interface
addresses on a single interface.  What this is doing, however, is a
full-blown automatic routing protocol, and the only reason to expect
there should only be a few of those is if you don't expect anyone
to actually use IPv6 for anything serious.  This should be using a data
structure with better scaling properties.

That's not to say that having a configurable limit isn't reasonable (in
fact this protocol is complicated enough that it should probably be done
user space so it can have full-blown policy configuration should that be
needed; it usually is for other routing protocols), it is just that
doing it to fix this problem is just covering up the problem.

Dennis Ferguson