From owner-freebsd-ipfw@FreeBSD.ORG  Tue Mar 17 23:07:01 2009
Return-Path: <owner-freebsd-ipfw@FreeBSD.ORG>
Delivered-To: freebsd-ipfw@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 2BDD9106566B;
	Tue, 17 Mar 2009 23:07:01 +0000 (UTC)
	(envelope-from luigi@onelab2.iet.unipi.it)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129])
	by mx1.freebsd.org (Postfix) with ESMTP id D8D238FC13;
	Tue, 17 Mar 2009 23:07:00 +0000 (UTC)
	(envelope-from luigi@onelab2.iet.unipi.it)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
	id 86095730A1; Wed, 18 Mar 2009 00:12:22 +0100 (CET)
Date: Wed, 18 Mar 2009 00:12:22 +0100
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: Julian Elischer <julian@elischer.org>
Message-ID: <20090317231222.GD95451@onelab2.iet.unipi.it>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49C026B1.8010108@elischer.org>
User-Agent: Mutt/1.4.2.3i
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?
X-BeenThere: freebsd-ipfw@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFW Technical Discussions <freebsd-ipfw.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ipfw>
List-Post: <mailto:freebsd-ipfw@freebsd.org>
List-Help: <mailto:freebsd-ipfw-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2009 23:07:01 -0000

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 ?

cheers
luigi