mailing list archives
RE: Inappropriate TCP Resets Considered Harmful
From: Ben Nagy <ben.nagy () marconi com au>
Date: Mon, 14 May 2001 09:42:35 +1000
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
In some email I received from Ben Nagy, sie wrote:
I'm mainly of the opinion that ECN is experimental, and sends
Well, Linux 2.4 shipped with ECN turned on by default [so] I'm not
sure if it makes sense for ECN to be considered
"experimental" given the
exposure it has had[...]
I thought the whole idea of the IETF was to try and make sure that "wide
deployment" didn't equal "de facto standard" - otherwise MS would be writing
all our standards for us.
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?
Reading that Internet draft, it quickly becomes clear that
part of it is
political in nature[...]
I do have some problems with the tone - it certainly got my hackles up (I
had to re-write my reply before sending >;)
Personally, I see little difference between dropping packets
bits set and sending an error back. I wouldn't call
responding to those
packets in an unfriendly way "broken".
That's pretty much how I feel. Which error, though? Parameter Problem (12),
Unreachable for type of service (3/11 or 12) or administraively prohibited
(3/13)? Almost all of those will make pretty obvious fingerprints, too.
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
firewall-wizards mailing list
firewall-wizards () nfr com