RFC: Dropping support for scrub fragment crop/drop-ovl

[Ermal Luçi]

On Fri, Jun 12, 2015 at 11:43 AM, Kristof Provost <kp at freebsd.org> wrote:

> 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.
>


Just go ahead an do that.

>
> 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
> _______________________________________________
> freebsd-pf at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>



-- 
Ermal