On Mon, Nov 28, 2011 at 10:43 PM, <valdis.kletni...@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
