>>>>> "jmm" == Joanne M Mikkelson <jmmikkel%MIT.EDU@localhost> writes: >>>>> "is" == Ignatios Souvatzis <is%netbsd.org@localhost> writes: is> If the RST wasn't abused, the firewall's behaviour would be is> reasonable. It seems like you're not listening. She says Linux sends an RST the same way when you call close() on a socket with unread data, and it seems reasonable to me---why bother acknowledging data that can never be read? The firewall and NetBSD are both playing around with the interpretation of TCP. The problem is, NetBSD's allowed to, and it's the firewall's job to accomodate NetBSD, not the other way round. We've allowed this to become inverted, and now TCP design has been taken over by crazy irresponsible people bouncing off the walls blocking passing and rewriting whatever they like with a blank check that says ``securitah,'' a bunch of incomplete hypothetical stories, no consensus, no testing, no interop pressure. Many TCP improvements including this one are about security, but TCP designers don't get the blank check. Anyway there's no reason the firewall can't send an RST itself. no good reason---I'm sure they will make one up, involving ``spoofing'' again. jmm> an extremely common OS using a firewall with rather common jmm> behavior uh oh. here we go... Is there some way to build a NetBSD firewall to notice the accumulation of stale connections not eliciting RST's trying to DoS the server, and start blocking the Windows host entirely? Then it can be your broken firewall vs. my broken firewall. If you can't beat 'em...
Description: PGP signature