On Nov 28, 2011, at 9:15 PM, Jeff Wheeler wrote:
On Mon, Nov 28, 2011 at 4:51 PM, Owen DeLong <owen@delong.com> wrote:
Technically, absent buggy {firm,soft}ware, you can use a /127. There's no actual benefit to doing anything longer than a /64 unless you have buggy *ware (ping pong attacks only work against buggy *ware), and there can be some advantages to choosing addresses other than ::1 and ::2 in some cases. If you're letting outside packets target your point-to-point links, you have bigger problems than neighbor table attacks. If not, then the neighbor table attack is a bit of a red-herring.
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.
That's _NOT_ a fair characterization of what I said above, nor is it a fair characterization of my approach to dealing with neighbor table attacks. What I said above is that if you allow random traffic aimed at your point to point links, you're doing something dumb. If you don't allow random traffic, you don't have a neighbor table exhaustion attack reaching your point to point interfaces. It's that simple. That's what I said above. As to my actual plan for dealing with it, what I said was that if we ever see a neighbor table attack start causing problems with services, we'd address it at that time. Likely we would address it more globally and not through a whack-a-mole process. I did not give details of all of our mitigation strategies, nor can I. What I can say is that we do have several /64s that could be attacked such that we'd notice the attack. Most likely the attack wouldn't break anything that is a production service before we could mitigate it. In more than a decade of running production IPv6 networks, we have yet to see a neighbor table attack. Further, when you consider that most attacks have a purpose, neighbor table attacks are both more difficult and less effective than other attack vectors that are readily available. As such, I think they are less attractive to would-be attackers.
I hate to drag a frank, private discussion like that into the public list; but every time Owen says this is a non-issue, you should keep in mind that his own plan is totally unacceptable for any production service. Only one of the following things can be true: either 1) Owen thinks it is okay for services to break repeatedly and require operator intervention to fix them if subjected to a trivial attack; or 2) he is lieing. Take that as you will.
No, there is a third possibility. I don't mind you taking a frank private discussion public (though it's not very courteous), but, I do object to you misquoting me and misconstruing the nature and substance of what I said. I do not think it is OK for services to break repeatedly. I do think that the probability of an attacker finding ND attacks useful combined with the effort required to carry one out against a well-defended target make them far less likely than you characterize them to be. As such, I'm willing to limit the mitigation efforts to the steps we've already taken until they prove inadequate. IF they prove inadequate (whether that proof comes in the form of a service breakage or not), then we will address mitigation more broadly. However, investing infinite resources in preventing an unlikely and not particularly effective attack strikes me as a poor use of resources. Yes, ND attacks are possible if you leave your /64 wide open to external traffic. However, if you're using your /64 to provide services, chances are it's pretty easy to cluster your server in a much smaller range of addresses. A simple ACL that only permits packets to that range (or even twice or 4 times that range) will effectively block any meaningful ND attack. For example, let's say you use 2001:db8:fe37:57::1000:0 to 2001:db8:fe37:57:1000:01ff as the IPv6 range for a set of servers. Let's say there are 200 servers in that range. That's 200/512 good ND records for servers and 312 slots where you can put additional servers. That gives you a total attack surface of 312 incomplete ND records. This was part of my frank private discussion with Jeff, but, he seems to have forgotten it. In my mind, if your ACL only permits those 512 addresses to be reached from the outside (potentially attacking) world, then, your router isn't likely to fall over from those 312 incomplete ND entries. Maybe Jeff tries to run production services on something smaller than a LInksys WRT54G. I don't know. I certainly don't. Anything larger should be able to handle a few hundred incomplete NDs that don't belong without incident. If you have networks that you don't protect with ACLs, then, you're asking for other troubles regardless of the protocol anyway. Owen