On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli <joelja@bogus.com> wrote:
Which at a minimum is why you want to police the number of nd messages that the device sends and unreachable entries do not simply fill up the nd cache, such that new mappings in fact can be learned because there
Your solution is to break the router (or subnet) with a policer, instead of breaking it with a full table. That is not better; both result in a broken subnet or router. If NDP requires an NDCache with "incomplete" entries to learn new adjacencies, then preventing it from filling up will ... prevent it from learning new adjacencies. Do you see how this is not a solution?
are free entries. you need to do this on a per subnet basis rather than globally. as in ipv4 policing, global limits will kill the boxes ability to learn new entries everywhere.
Yes, per-subnet/interface limits are absolutely needed, to prevent the entire box from being killed when one subnet/interface becomes impaired. That won't stop attackers from breaking your network, both because one subnet that presumably has production services on it is broken, and because, presumably, the attacker can identify other subnets on the router. Even if not, the problem remains that ... some subnets/interfaces are broken. On Thu, Jan 6, 2011 at 5:20 AM, Owen DeLong <owen@delong.com> wrote:
You must also realize that the stateful firewall has the same problems Uh, not exactly...
Of course it does. The stateful firewall must either 1) be vulnerable to the same form of NDP attack; or 2) have a list of allocated v6 addresses on the LAN. The reason is simple; a "stateful firewall" is no more able to store a 2**64 table than is a "router." Calling it something different doesn't change the math. If you choose to solve the problem by disabling NDP or allowing NS only for a list of "valid" addresses on the subnet, this can be done by a stateless router just like on a stateful firewall.
Uh, no it doesn't. It just needs a list of the hosts which are permitted to receive inbound connections from the outside. That's the whole
This solution falls apart as soon as there is a compromised host on the LAN, in which case the firewall (or router) NDP table can again be filled completely by that compromised/malicious host. In addition, the "stateful firewall," by virtue of having connection state, does not solve the inbound NDP attack issue. The list of hosts which can result in an NDP NS is whats causes this, and such a list may be present in a stateless router; but in both cases, it needs to be configured. "Stateful firewall" is unfortunately not magic dust that you can sprinkle on any network problem.
Except that routers don't (usually) have the ability to do dynamic outbound filtration which means that you have the scaling problem you've described of having to list every host on the net. If the router does have this ability, then, the router is, by definition, a stateful firewall.
As I state above, this capability does not "fix" the problem because the "stateful firewall" can just as easily be subject to DoS. You must have a list of valid v6 hosts on the subnet for your solution to work.
There are risks with sparse subnets that have been inadequately addressed for some of their failure modes at this time. I wouldn't go so far as saying they are a plan to fail. In most cases, most networks shouldn't be susceptible to an externally initiated ND attack in the first place because those should mostly be blocked at your border except for hosts that provide services to the larger internet.
As you have pointed out, without state information, you can't block this external attack. Even if you have a "stateful firewall," that firewall must itself have a solution for the internally-originated NDP attack. While the problems are slightly different and the internally-originated attack is less likely, both must be solved to ensure a reliable v6 network. The "stateful firewall" only solves half the problem and remains entirely vulnerable to the other half. On Thu, Jan 6, 2011 at 5:29 AM, Owen DeLong <owen@delong.com> wrote:
But, Jeff, if the router has a bunch of /24s attached to it and you scan them all, the problem is much larger than 250 arp entries.
That depends on how many is "a bunch" and how large is the ARP table on the device. A pizza box layer-3 switch, as I have mentioned, easily holds several thousand entries, modern units upwards of 10,000. That's enough room for several v4 /24 networks. No device has enough for one v6 /64 network. In addition, most of the IPs on your typical /24 networks will be in use routinely (in a hosting environment, anyway) which means that a scan really doesn't generate many new WHO-HAS and incomplete entries, because most layer-2 mappings are already known. Those that aren't fit within the cheap router's resource limitations somewhat easily. On Thu, Jan 6, 2011 at 5:41 AM, Phil Regnauld <regnauld@nsrc.org> wrote:
Additionnally I believe the size of typical recommended IPv6 space will probably discourage idle scanning, though this may change as the resources available increase, as Joe G. pointed out. If it does not, we'll have to address it if the existing mitigation techniques aren't sufficient.
It may indeed reduce "idle" or random scanning by agents such as worms. However, it will make intentional, DoS-oriented scanning quite popular. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts