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

[Kristof Provost]

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