From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 18 15:52:42 2009 Return-Path: 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 6F125106568E for ; Wed, 18 Mar 2009 15:52:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4AB5C8FC27 for ; Wed, 18 Mar 2009 15:52:42 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id CA33D101C01; Wed, 18 Mar 2009 08:52:27 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id AE11C2D600D; Wed, 18 Mar 2009 08:52:09 -0700 (PDT) Message-ID: <49C118B2.5050002@elischer.org> Date: Wed, 18 Mar 2009 08:52:18 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Luigi Rizzo 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> In-Reply-To: <20090317231222.GD95451@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@FreeBSD.org, Dmitriy Demidov , Alex Dupre 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 15:52:42 -0000 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? > > cheers > luigi