You will always be exposed to attacks if you're connected to the Internet. (Not really sure what you were trying to say there.) My primary concerns are attacks originated from external networks. Internal network attacks are a different issue altogether (similar to ARP attacks or MAC spoofing), which require different solutions. As previously discussed in a recent thread, the attack vector you describe (in a service provider environment) can be mitigated though architecture simply by effective CPE design (isolated link network to CPE, L3 hand-off at CPE, with stateful packet inspection; and small or link-local prefixes for link networks). Thankfully, this isn't a model that is anything new; many networks are already built in this way. The only point contested is the validity of longer-than 64-bit prefixes; which I think I've spoken enough on. Enterprise and Data Center environments have a different set of [similar] concerns. Which is where the most concern on exploitation of ND and large prefixes comes into play. I think most of us have been at this for long enough to have given up on the one-configuration-fits-all school of network design. A stateful firewall internally can be a strong tool to mitigate this attack vector in such environments, depending on their size. For networks where a stateful firewall isn't practical, though, that is where stronger router implementation comes into play. The suggestion of disabling ND outright is a bit extreme. We don't need to disable ARP outright to have functional networks with a reasonable level of stability and security. The important thing is that we work with vendors to get a set of tools (not just one) to address these concerns. As you pointed out Cisco has already been doing quite a bit of work in this area, and once we start seeing the implementations become more common, other vendors will more than likely follow (at least if they want our business). Maybe I'm just a glass-half-full kind of guy. ;-) I think being able to use longer prefixes than 64-bit helps considerably. I think that seeing routers that can implement ND in hardware (or at least limit its CPU usage), and not bump known associations for unknown ones will help considerably. Stateful firewalls (where appropriate) will help considerably. And L2 security features (ND inspection with rate-limiting, RA guard, DHCPv6 snooping) will all help -- considerably. Combined, they make for an acceptable solution by current standards. As was also pointed out, though, many networks don't even implement this level of security for IP internally; the difference is that many of them haven't needed to for external attacks because of the widespread use of NAT, stateful firewalls, and much smaller address space. That is a little different in the IPv6 world, and why there is concern being expressed on this list. The most important thing is that network operators are aware of these issues, have a basic understanding of the implications, and are provided with the knowledge and tools to address them. This really isn't much different than IPv4. On Wed, Dec 28, 2011 at 4:08 PM, Jeff Wheeler <jsw@inconcepts.biz> wrote:
On Wed, Dec 28, 2011 at 10:19 AM, Ray Soucy <rps@maine.edu> wrote:
There are a few solutions that vendors will hopefully look into. One being to implement neighbor discovery in hardware (at which point table exhaustion also becomes a legitimate concern, so the logic should be such that known associations are not discarded in favor of unknown associations).
Even if that is done you are still exposed to attacks -- imagine if a downstream machine that is under customer control (not yours) has a whole /64 nailed up on its Ethernet interface, and happily responds to ND solicits for every address. Your hardware table will fill up and then your network has failed -- which way it fails depends on the table eviction behavior.
Perhaps this is not covered very well in my slides. There are design limits here that cannot be overcome by any current or foreseen technology. This is not only about what is broken about current routers but what will always be broken about them, in the absence of clever work-arounds like limits on the number of ND entries allowed per physical customer port, etc.
We really need DHCPv6 snooping and ND disabled for campus access networks, for example. Otherwise you could give out addresses from a limited range in each subnet and use an ACL (like Owen DeLong suggests for hosting environments -- effectively turning the /64 into a /120 anyway) but this is IMO much worse than just not configuring a /64.
On Wed, Dec 28, 2011 at 10:45 AM, <sthaug@nethelp.no> wrote:
I'm afraid I don't believe this is going to happen unless neighbor discovery based attacks become a serious problem. And even then it would take a long time.
The vendors seem to range from "huh?" to "what is everyone else doing?" to Cisco (the only vendor to make any forward progress at all on this issue.) I think that will change as this topic is discussed more and more on public mailing lists, and as things like DHCPv6 snooping, and good behavior when ND is disabled on a subnet/interface, begin to make their way into RFPs.
As it stands right now, if you want to disable the IPv6 functionality (and maybe IPv4 too if dual-stacked) of almost any datacenter / hosting company offering v6, it is trivial to do that. The same is true of every IXP with a v6 subnet. I think once some bad guys figure this out, they will do us a favor and DoS some important things like IXPs, or a highly-visible ISP, and give the vendors a kick in the pants -- along with operators who still have the "/64 or bust" mentality, since they will then see things busting due to trivial attacks.
-- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/