
The many ways of handling TCP RST packets - luu
https://www.snellman.net/blog/archive/2016-02-01-tcp-rst/
======
peterwwillis
"What could be a simpler networking concept than TCP's RST packet?"

There are _twelve_ RFCs that cover the TCP protocol. They had to write a guide
to traversing them all (RFC7414), and that guide references _128 other RFCs_.
I doubt we can expect any aspect of a particular implementation to be simple.

As more products emerge, their functionality diverges and inconsistencies
appear. Unless you test your product against someone else's, assume there will
probably be unexpected behavior, no matter what spec you're following. (It
just gets worse with the intermediary devices, as they're not even a plain-old
TCP stack anymore; now they can include a NAT implementation, routing, a
firewall, an application proxy... the complexity becomes dizzying)

~~~
feld
These intermediary devices vastly outnumber our routers and are a huge part of
the "internet sucks" problem.

------
AstroJetson
"What could be a simpler networking concept than TCP's RST packet?"

I just checked my collection of Steven's TCP/IP Illustrated and there are a
couple of pages on RST. So it's not that simple.

Kudo's to digging into RST as deeply as you did, I found the article to be a
good read. I do think it's very cool that the people that did the RFC's really
thought about the corner cases and how the protocol could take care of them.

------
derFunk
I just had a short romance with RST/ACK. It happened during a keepalive http
session to AWS ELB, where the nginx backend had keepalive disabled completely
due to a misconfiguration. The ELB's idle_time was set to 10seconds (instead
of default 60). Just because the idle_time was set to a low value the effect
of seeing the RST/ACK could be seen. It needed Wireshark to track this down.
On the http level it appeared that a request had been sent, but the received
response was empty and didn't even reach nginx at all (because ELB closed the
stream).

------
userbinator
I don't have a huge knowledge of TCP, but IMHO the sequence number should just
be ignored for RST --- that half of the connection is unusable for sending
data after a RST, so the sequence number is irrelevant. I think the connection
should close, unconditionally. The argument about RST spoofing seems somewhat
contrived - if you have the means to inject arbitrary packets, chances are you
also have the means to read them, so what sequence numbers are being used is
known. Any flaw in this reasoning? Despite the diagram showing very different
behaviour for all the OSs, the fact that they should be able to successfully
communicate with each other, and the Internet is the biggest example of that,
says to me that it might not really matter all that much...

 _What would really suck is if an operating system were to totally ignore the
rule to reply with an RST when receiving a packet on a closed socket._

Isn't this behaviour explicitly encouraged to prevent port scanning and
related attacks?

~~~
hwh
"if you have the means to inject arbitrary packets, chances are you also have
the means to read them" \- this is not true in some (most?) settings. Current
mode of operation of the Internet as we know it will allow incoming traffic
allow to claim to stem from any public IP address. It's up to the
interconnecting parties to ensure that no forged source IP adresses are used
on packets leaving their network towards others, but that's all there is at
the moment. See [http://www.internetsociety.org/doc/addressing-challenge-
ip-s...](http://www.internetsociety.org/doc/addressing-challenge-ip-spoofing)

