Re: frag6: better limitation

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Fri, Jan 26, 2018 at 07:37:21AM +0100, Maxime Villard wrote:
> Le 25/01/2018 à 22:37, Joerg Sonnenberger a écrit :
> > On Thu, Jan 25, 2018 at 10:32:42PM +0100, Maxime Villard wrote:
> > > 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.
> > 
> > I don't understand what you mean here. The typical scenario here is
> > someone sending fragments with a randomized host part. Given that IPv6
> > has enough space for that, it is not really possible to restrict that.
> 
> Perhaps an example will illustrate what I meant. If you have a firewall
> configuration that says:
> 
> 	allow incoming IP_A on wm0 (local network)
> 	allow incoming IP_B on wm1 (public network)
> 
> An attacker can send fragments (from the outside) with a source address of
> IP_B, the firewall won't kick these. The kernel maintains a per-IP limit, so
> if there is a flood, the fragments from IP_B will still go through the
> firewall but the kernel won't process them.

Firewall configurations with a hard-coded list of IPv6 addresses for
incoming connections are rare. Your patch fixes one form of DoS by
introducing a worse form -- I can just send a couple of fragment from
2001:db8::1, followed by a couple of fragments from 2001::db8::2 etc.
Before the total amount of memory used for fragments had a fixed limit,
now it doesn't.

Just as with IPv4, IPv6 fragmentation is best effort. Higher level
protocols should not depend on it to work reliably if they want to work
in a semi-hostile environment.

Joerg