It might be worth adding that the traffic exploiting that problem is not invalid in any sense. TCP segments can arrive out-of-order in legitimate usage, too. For instance, individual TCP packets of one connection can take different paths to your peer, so a higher fragment may very well arrive before a lower one. If that was not expected, there would be no need for TCP reassembly at all.
So, reassembling TCP segments is needed, unless you're willing to break perfectly legitimate connections. But an attacker should not be able to grow the reassembly queue up to the point where you crash because you run out of memory. Finding a good strategy to decide what queue entries to drop at what point is not trivial. I think we'll wait and see what strategies work best in the TCP/IP stack, and use that experience if/when implementing TCP reassembly in pf scrub. Daniel
