frag6: better limitation

[Maxime Villard <max%m00nbsd.net@localhost>]

Hi,
There is something I find a bit inappropriate in our frag6 entry point. When
a fragment is received, the kernel performs the following check:

	if (frag6_nfrags >= (u_int)ip6_maxfrags)
		goto dropfrag;

Here, frag6_nfrags is the total number of fragments that are pending in
the kernel's memory. But this value is system-wide, and not fine-grained.

On a system that has several addresses/interfaces, it implies that if only
one interface is flooded with fragments, the fragments received on each of
the remaining interfaces will get kicked.

The timeout - after which the pending fragments are dropped - is one minute.

It is easy for a remote attacker to send fragments in a loop, and cause the
check above to be always true. After one minute he just has to send another
round of fragments, the limit will again be reached, and so on.

I ended up writing this [1], without a lot of conviction, to say the truth.
A per-src-IP policy is implemented: each sender is allowed to have a given
number of fragments pending; beyond that limit, they get kicked.

Now, if someone floods the machine with fragments, the kernel will at some
point kick all the fragments that come from this someone's address. Obviously,
an attacker could be able to use a different src address; but then we rely
on the firewall to reject the packets earlier.

With this change I am able to send fragments to a local NetBSD machine that is
being flooded from the outside.

Not sure if that's worth it, or if it's the right thing to do, but our way
of handling fragments does not seem very correct. The other BSDs have this
issue too.

Maxime

[1] http://m00nbsd.net/garbage/ip6/frag6.diff