> This is another option that's probably better left to sysadmins. Basically, > "wormhole" reassembles enough fragments to make filtration decisions reliably. > After than, it effectively falls back on EITHER crop or drop, which should be > up to the firewall's admin to choose (since it's equally simple to implement > either). So you'd have something like "wormhole reassemble-drop-ovl" or > "wormhole reassemble-crop-ovl". [... chopped alot ...]
You're imagining a problem that isn't there and then solving it the wrong way. IP fragments should be *very* rare on the network. PMTU discovery exists for a reason. In the normal case, the "wormhole" will be no different than crop/drop-ovl. Most of the time the frags will arrive in order with a full header first. It just isn't worth optimizing for the uncommon case. > As for arguments that these kinds of tiny frags, such as ones too small to > contain proper headers or overlapping frags, cannot be generated by legitimate > applications, I strongly urge you all not to underestimate human capacity for > utter stupidity. rofl. Thank you for reminding us. sorry. couldn't resist ;-) The last time I looked at Cisco's PIX, they required the first logical fragment to arrive first or they'd drop all of the fragments. And it was required to contain a full header. The PIX has a large enough marketshare that I'm not too worried about host/router fragmentation algorithm's being released that don't send the first frag first with a full header. > Don't forget that it violates standards to generate fragments > with don't fragment sent, yet there is a significant entity (whose name need > not be mentioned) which has nevertheless accomplished this amazing feat of > utter brainlessness. I do recall watching a certain amount of debate ensuing > as people's dependence on this service caused inconveniences to pf users and > developers alike. Sigh. You missed the point of scrub dropping DF|MF. It is perfectly legal and actually makes sense. But it leads to an ambiguity in IPv4. Scrubbing/normalization resolves or drops ambiguities. > So, now we add timeout modulation to pf. Nothing fancy. Just that each time a > state is created, a random value percentage value is generated, between 0 and a .... > Now, instead of knowing, within a couple hundreds or tens of milliseconds when > a timeout will expire, your attacker is faced with a probabilistic function. OpenBSD has a random TCP timestamp header so an attacker is going to have a difficult time predicting when the 10s timeout was first inserted into the wheel. Remember PF prunes the whole tree of expired states every timeout interval, we don't insert a timeout into the wheel for every state or reassembly queue. Perusing the PF source would probably do you some good. Some implementation experience to back up the theory. .mike
