IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

Wed Nov 30 04:12:51 UTC 2011

On Tue, Nov 29, 2011 at 12:42 AM, Owen DeLong <owen at delong.com> wrote:
> 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.

Here are some direct quotes from our discussion:
> Since we have relatively few customers per aggregation router, I don't
> think you'd be nearly as successful as you think you would.

> On the platforms we use, it won't spill over into IPv4 breakage. Additionally,
> it will break fewer than 50 other dedicated servers and no other customers.
> This will be tolerated for about 5 minutes while our support department
> receives the alarm and looks into the cause, then, your dedicated server
> won't have power any more and the problem will go away along with your
> account.

At no time did you ever suggest you had any idea how to systemically
solve this problem.  Now you are claiming that you have a "more
global" approach, but this is another of your lies.

> All of our support guys have enough clue to get to this quickly enough
> and our monitoring systems would detect the abnormally large
> neighbor table fairly early in the process.

Your monitoring systems keep an eye on the size of your ND tables?
How can this be true if you believe that ND attacks are not an issue?
Did you just throw resources at monitoring this for no reason?  Do you
really even poll or alert on this data, or were you simply telling
another lie?

> Additionally, we have a network engineer on duty 24x7, so, even
> if the support guys don't figure it out correctly, there's backup with
> clue right behind them in the same room.

That is exactly "NOC whack-a-mole."

> What I said above is that if you allow random traffic aimed at your
> point to point links, you're doing something dumb.

If your network has nothing but point-to-point links, it is easy to
defend.  Sadly that is not how you or I interface with many of our
customers.

In addition, you don't actually practice what you preach.  Hurricane
Electric uses /126 networks in its backbone.  Why are you not rushing
to change these to /64?  After all, you regularly tell us about the
supposed disadvantages of /126 on point-to-point links.  What are
these disadvantages?

> 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.

No, this is not what you said.  Again, you are simply telling lies.

> I did not give details of all of our mitigation strategies, nor can I.

Yes you did.  Your "strategy" is whack-a-mole.

> 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.

Breaking about 50 customers for as long as it takes your support staff
or NOC to troubleshoot, in your mind, muts not be "breaking anything
that is a production service," or else "before we could mitigate it"
means you have figured out how to travel through time.

> 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.

Again, the "bad guys" don't have much motive (yet) since few services
of interest share common IPv4 and IPv6 infrastructure today.  That
will change.

> 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.

It's disingenuous of you to continue to lie every time this topic
comes up on the mailing list.

> 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.

Since I've re-read our earlier discussion (unlike you) I can state
with certainty that it was not part of our earlier discussion.  If it
was, I would be happy to tell everyone that your plan for deploying
IPv6 to your customers includes blocking the use of the majority of
the /64, such that it would function better if it were simply a longer
subnet anyway.

Again, your solution makes no sense.

> 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.

If you have a small layer-3 switch with 50 users, as you do, ~512
possible ND entries per user gets you to ~25k total, if the attacker
decides they want to take advantage of it.  25k is larger than the
IPv6 ND table on all(?) layer-3 ToR switches.  Without throttling of
ND punts per destination address (which is not possible if the table
is exhausted, even if the data plane has this feature otherwise) then
either the ND function for legitimate traffic will be broken, or the
control-plane will fail in a worse way.

I think my characterization of our earlier discussion is quite fair.
My characterization of our current one is very simple: you are telling
some pretty big lies.  Feel free to demonstrate how I am mistaken.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts