Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Mar 2009 23:35:11 +0100
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:  <20090317223511.GB95451@onelab2.iet.unipi.it>
In-Reply-To: <49C01E08.9050709@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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote:
> Luigi Rizzo wrote:
> >
> >Thinking more about it, i believe that calling reass as an explicit
> >firewall action is useless, because if ip_reass fails due to lack of
> >all fragments you are back to square one:
> >	what do I do with this fragment ?
> >  
> 
> AFAIK ip_reass() never fails: if it's the last fragment it reassembles 
> the packet and return it, else it queues the fragment for later
> reassembly.

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.

Good progress!

	cheers
	luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090317223511.GB95451>