On sending TCP RST's and ICMP Unreachables.

Darren Reed avalon@coombs.anu.edu.au
Mon, 8 May 2000 01:38:54 +1000 (Australia/NSW)


Lots of emails put into one.

...
> Actually dyanmic NAT is evil too (because it violates end2end), but in 
> practice it is not that bad a layering violation than arbitary sending RSTs, 
> because both ends still have an end2end illusion and only speak together. 

Well, I'd not go that far, but say that for a given connection, there is
the illusion of an end-to-end `connection'.

> With sending RSTs you're second guessing the TCP algorithms and that 
> is bad. 

> -Andi

You're not second guessing TCP algorithms at all.  TCP is well defined,
so there is no second guessing to do.

> No, an ICMP unreachable is normally a soft error (in ESTABLISHED it is 
> only reported after a timeout), a RST is a hard error. The difference 
> is with TCP's handling of routing changes. 
> 
> -Andi 

Yes.  For the most part, people want to cause a "hard error" when TCP
packets that aren't meant for anything arrive at their firewall.

> > Of course there is a danger in such a feature: for example, if a naive 
> > admin configures a firewall to reject forged packets with TCP RST, then 
> > he/she created a perfect RST generator. Yes, it *is* a problem. But I 
> > don't see other reasons. 
> 
> That is the problem I'm worrying about. You as administrator are free 
> to do bad things to your own machine, but making it easy to do bad things 
> to whole networks is not good. Shipping a RST generator as a standard 
> Linux kernel feature is just irresponsible. 

Dear me!

Imagine if they configure it to return ICMP packets for everything, then
you'll have shipped an ICMP generator - how irresponsible.

Now, if you look at it practically, if anyone does that then they won't
be able to use the net for a damn thing and will quickly change it.

They're also only going to get packets which are for their network, unless
they manage to hack a BGP table and get a default route for someone.

This is a totally bogus piece of rationale being put forward by Andi.

> If you really want it please write a small ipqueue hack that generates 
> them in user space, but do not pollute the kernel with such hacks. 
> 
> Thanks, 
> 
> -Andi 

Sounds more like it is time for Linux to stop shipping with iptables
built *into* the kernel, by default, so that Rusty can make the firewall
do what people need it to do without being tortured by the kernel gurus. 

> Because then quickly people will build Linux based "RST generators" 
> that run amok on networks by mistake. With unspecified hacks that is much 
> harder. 
> Of course you can always write a program that generates them, or somehow 
> trick something else to generate them, but that is relatively hard. 
> It definitely should not be a documented standard feature. 
> 
> -Andi (who is not going to post anything more to this thread) 

Bah, generating RST's is no more difficult than generating ICMP messages.
And that brings me to the reason why RST is much better than ICMP for
signalling to the sender to drop the connection: MANY people today drop
ICMP unreachables completely due to NUMEROUS hosts dealing with them
badly and dropping every network connection between the matching hosts.

Let me find an ICMP nuke program and hack on it a little and voila, a
TCP RST generator.  But there is a *significant* difference.  To get
the TCP RST to work, you have to get each IP# right, each port number
right AND (depending on target OS >:-) both sequence numbers right.
You're doing well if your ICMP handler for TCP matches up on port numbers
as well as IP#'s, never mind if they bother to get the seq# out of the
last 4 bytes (and there is never an ACK# included).

I remember working on a nuke program, before they were common place,
and as a test targetted the X-term of someone sitting across from me
(with their permission).  Instant logout.

> Why don't I like it? Some discussions with Alexey Kuznetsov on 
> netdev. TCP RSTs are the strongest form of error we have. eg. if an 
> established TCP connection gets an ICMP error, it stores it and 
> retries, since this may be a transient error. (NB. intelligent stacks 
> abort immediately when receiving an ICMP error in SYN_SENT state). A 
> RST, on the other hand, always causes immediate abort. 

Right.  If people are returning RST's from their firewall (or want to),
then they are saying "go away" and want to do so in the strongest form
possible.  If I block all access to port 25 locally from net 128.x.y.0/28,
I want to be saying "bugger off" not "no, sorry, try again and maybe you
will succeed".  I'd beg to disagree about any ICMP error causing an
immeadiate failure for TCP, even if in SYN_SENT.  If I've unplugged my
router from a LAN, just as a host tries to connect across, and gets an
"unreachable", plug it back 30 seconds later (untangling a mess :*),
if TCP has treated the ICMP as a soft error, it still has a chance to
make the connection without having to restart the whole damn thing.

> If we start generating RSTs in routers, sooner or later someone will 
> decide they are getting too many spurious RSTs, and decide to treat 
> them as ICMPs (ie. ignore them and retry). More wasted traffic. More 
> weakened standards.

Why would a router generate a spurious RST ?  Do they generate spurious
ICMP errors ?  And why are you calling a firewall a router all of a
sudden ?

> Don't think it'll happen? Well, let me tell you about a wonderful 
> protocol perversion from a certain (fairly common) operating system. 
> When the TCP SYN queue fills, instead of dropping the packet, this OS 
> would send a RST packet. 
> 
> This meant that an overloaded web server would abort new connections, 
> making the site seem down, not just slow (relying on SYN 
> retransmissions). 

> Their solution? Fix the other end: when their OS receives a RST on 
> SYN_SENT, they retransmit twice to make sure it's not a bogus RST 
> caused by overloading. Three SYN packets, three RSTs, for the price 
> of one. 

Does the company which does this have a big share price problem ?

> Hence I've not been overly eager to add RST functionality: it might 
> not make the situation much worse, but I'm not sure I want to find 
> out. 
> 
> Rusty. 

How could it make it worse ?  The 'net sucks enough as it is, with
live p0rn, censorship, email viruses, etc, features like returning
RST packets from a Linux firewall are not going to make it any worse,
if they make any difference at all, IMHO.  Nobody is going to ignore
those RST's because they gain nothing from it and everything from
acting upon them.

Cheers,
Darren