>>>>> "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...
Attachment:
pgp1qulb20g0S.pgp
Description: PGP signature