From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 15:43:54 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81AA6D35; Fri, 12 Jun 2015 15:43:54 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48BCDF40; Fri, 12 Jun 2015 15:43:53 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id D2FFE19E08; Fri, 12 Jun 2015 17:43:50 +0200 (CEST) Received: by vega.codepro.be (Postfix, from userid 1001) id C2D5821DA; Fri, 12 Jun 2015 17:43:50 +0200 (CEST) Date: Fri, 12 Jun 2015 17:43:50 +0200 From: Kristof Provost To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: RFC: Dropping support for scrub fragment crop/drop-ovl Message-ID: <20150612154350.GA3135@vega.codepro.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:43:54 -0000 Hi all, I've recently been looking at bug 200330. I broke things while adding the reassembly support for ipv6 to pf. Those issues should be fixed now, but having looked at the fragment crop/drop-ovl code, I'm starting to think support for those options should just be removed. For context: in FreeBSD's pf scrub rules can specify different ways to handle fragments. These are 'reassemble', 'crop' and 'drop-ovl'. 'reassemble' is the default, and does full reassembly before filtering the packet. 'crop' and 'drop-ovl' do not reassemble. The man page explains it better than I can: > fragment crop > The default fragment reassembly method is expensive, hence the option > to crop is provided. In this case, pf(4) will track the fragments > and cache a small range descriptor. Duplicate fragments are dropped > and overlaps are cropped. Thus data will only occur once on the wire > with ambiguities resolving to the first occurrence. Unlike the > fragment reassemble modifier, fragments are not buffered, they are > passed as soon as they are received. The fragment crop reassembly > mechanism does not yet work with NAT. > > fragment drop-ovl > This option is similar to the fragment crop modifier except that all > overlapping or duplicate fragments will be dropped, and all further > corresponding fragments will be dropped as well. Basically, these options don't reassemble. That also implies that you get the choice between having your firewall drop fragmented packets, or allowing potentially unwanted packets through because they're fragmented. That's not explicitly mentioned in the man page and I suspect many users don't realise this and are thus led to make choices with unintended consequences. All of this applies only to IPv4. I never implemented support for crop/drop-ovl in the IPv6 reassembly code. On IPv4 any scrub is 'fragment reassembly'. The OpenBSD people removed crop/drop-ovl back in 2009. Removing crop/drop-ovl would also remove around 450 lines of fairly hairy pf code. We'd just default to fragment reassemble, even if crop or drop-ovl is specified. That'd mean a behaviour change, but it'll likely actually make many firewall configurations behave better rather than break things. In summary, unless someone comes forward to say they're using crop or drop-ovl support from them is going to go away. Regards, Kristof