RE: Inappropriate TCP Resets Considered Harmful

[Ben Nagy <ben.nagy () marconi com au>]

> -----Original Message-----
> 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
> > non-RFC-compliant datagrams.[...]
>
> 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 
> non-ECN mode)?
[...]
> I think that's worse than what Micro$oft reportedly does - 
> retries a socket
> connection inside IE if it gets "connection refused", 
> supposedly because
> some web servers (IIS?) will respond with RSTs if their 
> listen queue is
> full.

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 
> with undefined
> 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.

[...] 
> Darren

--
Ben Nagy
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
http://www.nfr.com/mailman/listinfo/firewall-wizards