Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Mar 2009 17:15:24 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        Julian Elischer <julian@elischer.org>
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:  <20090318161524.GA11771@onelab2.iet.unipi.it>
In-Reply-To: <49C118B2.5050002@elischer.org>
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> <49C026B1.8010108@elischer.org> <20090317231222.GD95451@onelab2.iet.unipi.it> <49C118B2.5050002@elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 18, 2009 at 08:52:18AM -0700, Julian Elischer wrote:
> Luigi Rizzo wrote:
> >On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer 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.
> >>So what is the behaviour when you reassemble a 5K packet,
> >>and then it has to be forwarded out another interface with 1500 MTU.
> >
> >Good point. One option would be that when REASS is called from the
> >output path, it always act as "count" and never calls ip_reass()
> >
> >Would that work ? The firewall in the output path is called before
> >fragment, locally generated packets are not fragmented, and if
> >don't want stray fragment you should have already called "reass"
> >in the inbound path through the firewall ?
> 
> yeah but what if you reassemble on input, and then the packet is routed?

it should work -- ip_output() gets the full packet,
the firewall is called on line 441 before
ip_fragment() which is on line 568.

cheers
luigi



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