mailing list archives
Re: Inappropriate TCP Resets Considered Harmful
From: Darren Reed <darrenr () reed wattle id au>
Date: Mon, 14 May 2001 11:22:54 +1000 (EST)
In some email I received from Ben Nagy, sie wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
From: Darren Reed [mailto:darrenr () reed wattle id au]
Sent: Saturday, May 12, 2001 11:26 PM
To: ben.nagy () marconi com au
Cc: floyd () aciri org; firewall-wizards () nfr com
Subject: Re: [fw-wiz] Inappropriate TCP Resets Considered Harmful
For the time being, though, wouldn't it be better to make ECN
implementations deal with TCP RSTs (as in try and resend in
I think that's worse than what Micro$oft reportedly does -
retries a socket
connection inside IE if it gets "connection refused",
some web servers (IIS?) will respond with RSTs if their
listen queue is
Why is a retry bad? If I were writing firewall (heaven forbid!) I'd treat
ECN packets either by silently discarding them or by sending an ICMP error.
I can see the argument for not using a RST, but don't consider it a "broken"
choice, just "uninformative".
If I chose the "stealth" option, the packets would get dropped and there
would be several SYN retries anyway. Even if I chose an ICMP Parameter
problem, that's not exactly a common error, and would get filtered in many
cases (plus it would make fingerprinting my firewall trivial), so there
would also be resends there.
If the ECN stack knows that there's a fair chance that the RST just means
"ECN not spoken here" then why is it bad to have a go in non-ECN mode?
Retrying in response to an RST is bad because an RST is not an indicator
of a communications problem. It is saying that the service is not available.
If a service is not availabe why would you want to do an automatic retry to
see if it is ? If that sort of behaviour starts to become "the norm", then
what do we do to say "No, there *really* is no service X here, go away" ?
firewall-wizards mailing list
firewall-wizards () nfr com
- FW Sequence Number based statefulness, (continued)