On Mon, Nov 28, 2011 at 10:43 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 29 Nov 2011 00:15:02 EST, Jeff Wheeler said:
Owen and I have discussed this in great detail off-list. Nearly every time this topic comes up, he posts in public that neighbor table exhaustion is a non-issue. I thought I'd mention that his plan for handling neighbor table attacks against his networks is whack-a-mole. That's right, wait for customer services to break, then have NOC guys attempt to clear tables, filter traffic, or disable services; and repeat that if the attacker is determined or going after his network rather than one of his downstream customers.
It's worked for us since 1997. We've had bigger problems with IPv4 worms that decided to probe in multicast address space for their next target, causing CPU exhaustion on routers as they try to set up zillions of multicast groups.
Sure, it's a consideration. But how many sites are *actually* getting hit with this, compared to all the *other* DDOS stuff that's going on? I'm willing to bet a large pizza with everything but anchovies that out in the *real* world, 50-75 times as many (if not more) sites are getting hit with IPv4 DDoS attacks that they weren't prepared for than are seeing this one particular neighbor table exhaustion attack.
Any of the guys with actual DDoS numbers want to weigh in?
Agreed. While I don't have any good numbers that I can publicly offer up, it also intuitively makes sense that there's a greater proportion of IPv4 DDOS and resource exhaustion attacks vs IPv6 ones. Especially on the "distributed" part; there's a heck of lot more v4-only hosts to be 0wned and botnet'ed than dual-stacked ones. That said, I think the risk of putting a /64 on a point-to-point link is much greater than compared to a (incredibly wasteful) v4 /24 on a point-to-point. Instead of ~254 IPs one can destinate traffic towards (to cause a ARP neighbor discovery process), there's now ~18446744073709551614 addresses one can cause a router to start sending ICMPv6 messages for. For links that will only ever be point-to-point, there's no good reason (that I know of) to not use a /127. For peering LANs or places that have a handful of routers, /112's are cute, but I would think the risk is then comparable to a /64 (which has the added benefit of SLAAC). I imagine the mitigation strategies are similar for both cases though: just rate-limit how often your router will attempt neighbor discovery. Are there other methods? Cheers, jof