Date: Thu, 2 Apr 2009 13:32:31 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Paolo Pisati <p.pisati@oltrelinux.com> Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov <dima_bsd@inbox.lv>, Alex Dupre <ale@FreeBSD.org> Subject: Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets? Message-ID: <20090402113231.GB6577@onelab2.iet.unipi.it> In-Reply-To: <49D49AEB.20701@oltrelinux.com> References: <200903132246.49159.dima_bsd@inbox.lv> <20090313214327.GA1675@onelab2.iet.unipi.it> <49BF61E7.7020305@FreeBSD.org> <49BFB9B2.9090909@oltrelinux.com> <20090317190123.GB89417@onelab2.iet.unipi.it> <49C01E08.9050709@oltrelinux.com> <20090317223511.GB95451@onelab2.iet.unipi.it> <49D49AEB.20701@oltrelinux.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 02, 2009 at 01:00:59PM +0200, Paolo Pisati wrote: > Luigi Rizzo wrote: > > > >Ok then we may have a plan: > > > >you could do is implement REASS as an action (not as a microinstruction), > >with the following behaviour: > > > >- if the packet is a complete one, the rule behaves as a "count" > > (i.e. the firewall continues with the next rule); > > > >- if the packet is a fragment and can be reassembled, the rule > > behaves as a "count" and the mbuf is replaced with the full packet; > > > >- if the packet is a fragment and cannot be reassembled, the > > rule behaves as a "drop" (i.e. processing stops) > > and the packet is swallowed by ipfw. > > > >This seems a useful behaviour, but it must be documented very > >clearly because it is not completely intuitive. Perhaps we should > >find a more descriptive name. > > > committed yesterday in HEAD as "reass" action, and here is the 7.x > patch: http://people.freebsd.org/~piso/ipfw-reass-7x.diff Good job. Can you put a description in the manpage especially on the assumptions and side effects of the reass option ? E.g. as i read it, + you need to make sure that the fragments are not dropped before the 'reass' (so you cannot rely on port numbers to decide accept or deny). This is obvious but a very common mistake; + reass silently queues the fragment if it does not reass, so it opens up a bit of vulnerability. Again obvious, but people won't realise if they don't see the code. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090402113231.GB6577>