netdev - Re: Possible DoS with 6RD border relay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 05 Jan 2012 14:20:54 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	bcook@...akingpoint.com
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: Possible DoS with 6RD border relay

From: Brent Cook <bcook@...akingpoint.com>
Date: Wed, 4 Jan 2012 22:22:52 -0600

> Is this expected behavior? All of the peers in this case are really the same 
> 6RD client - it's really simulating a customer edge router with a few thousand 
> hosts behind it. I suspect that adding a static route entry for the CE's 
> prefix via 'sit' will also make the problem go away.

Any route which refers to more than one exact host as the destination must
be cloned or COW'd.

This is so that we can provide unique metrics for the destination, as
well as a unique neighbour for the nexthop.

In your case, the keys used to lookup the nexthop for all of these
routes must be different, otherwise you wouldn't hit the neighbour
table limits.  Since if they were all the same we'd find an existing
neighbour entry and just bump it's reference count.

Longer term I intend to make the ipv4 and ipv6 routes not take a
reference to the neighbour entries.  The neighbour entries will be
"refcount-less", and only we'll just use the neighbour entry at packet
output time using a low latency fast lookup inside of a tight RCU
protected code sequence.

So all of this "neighbour table overflow" crap will just disappear.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html