Re: Inappropriate TCP Resets Considered Harmful

[Darren Reed <darrenr () reed wattle id au>]

In some email I received from Ben Nagy, sie wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> OK, I'll bite.
>
> I'm mainly of the opinion that ECN is experimental, and sends
> non-RFC-compliant datagrams. I think that any firewalls that pass ECN
> enabled TCP without being explicitly configured to do so aren't doing their
> job properly.

Well, Linux 2.4 shipped with ECN turned on by default.  There were people
afraid of letting their firewalling send RST's in response to TCP packets
because Linux has too much exposure - it's a pity those sentiments weren't
held by the person who decided ECN should be turned on by default.  I'm not
sure if it makes sense for ECN to be considered "experimental" given the
exposure it has had curtesy of Linux.

[...]
> 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)?
> Once ECN becomes an RFC and those reserved bits get "officially" assigned,
> people are much more likely to be sympathetic. If an experimental protocol
> needs to break the RFCs for it to work, then don't whine when it doesn't.
> What part of MUST BE ZERO isn't clear? ;)

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.

ECN is documented in RFC 2481 and you can find the definition of the use
of those bits therein.

Reading that Internet draft, it quickly becomes clear that part of it is
political in nature - i.e. it has been written with the goal of conveying
the author's opinion(s) which is "how dare people respond to our precious
little protocol, ECN, in an unfriendly way" (or that's what it conveys to
me, anyway).  If section 2.2 is indeed meant to be the "Security
Considerations" for that document then it is an abysmal failure.

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".

IMHO, I think the people behind that draft are sticking their head in the
sand when it comes to Internet and pretending firewalls don't exist.  For
better or worse, they do, people want them and use them on a regular basis.
As they make up the Internet as much as do web servers, these days, I fail
to see why firewalls cannot evolve.  It is entirely inappropriate for them
to let through packets that they do not understand as such packets are
clearly not going to be part of any "policy" that's being put in place.

Using the argument that the author of that draft used, it would be possible
to argue that source routing options should not be blocked because they
they are used in traceroute and that's an application.

Whilst some aspects of the 'net may change quickly, others aren't going to.
Building a new protocol or extension and expecting it to work universally
"overnight" given a very small (one operation system) support base is what
I'd call naive.

Darren
_______________________________________________
firewall-wizards mailing list
firewall-wizards () nfr com
http://www.nfr.com/mailman/listinfo/firewall-wizards