NIST IPv6 document

Thu Jan 6 10:54:47 UTC 2011

On Thu, Jan 6, 2011 at 4:32 AM, Joel Jaeggli <joelja at 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 at 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 at 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 at 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 at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts