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