Aaron Suen wrote:
Currently, there are two major ways to handle fragmented IP datagrams in pf:
"fragment reassembly," and "those other ones." I say "those other ones"
because fragment reassembly is [seems to be] the recommended method of handling
fragments, since only a fully reassembled fragment is guaranteed to contain
enough header information to filter properly. For instance, nmap has a command
line option that will chop packets up into ridiculously small fragments, not
one of which contains enough header information to sufficiently filter. So if
you demand high security, you have to use fragment reassemble, right?
No - you just drop these tiny fragments. Fragments too short to contain a L3 header are invalid and should never be generated by legitimate applications.
You might mean the _first_ fragment must contain an entire L4 header to be legitimate, but that doesn't extend to all fragments.
Fragment reassebly is a normalisation technique, not a filtering requirement.
It's a prerequisite for L4 filtering. You can't filter on data you don't have, and you can't know you have that data unless you're tracking fragments.
Aaron is basically describing "fragment crop" with the addition of guaranteed L4 header reassembly, which is something that the man page suggests is intended for the future.
