In TCP, packets with the "Reset" (RST or R) flag are sent to abort a connection. Probably the most common reason you are seeing this is that an SYN packet is sent to a closed port. But RST packets may be sent in other cases to indicate that a connection should be closed. Lets first look at the reset in response to an SYN to a closed port:
Interesting here: The sequence number of the RST packet is 0. If you are looking at "unusually frequent" sequence numbers, "0" may show up at the top if you had a lot of failed connections that resulted in resets. For an RST in response to an SYN, the sequence number is not really used. This is the first packet arriving from that source, and no further packets will be sent. Also, there is nothing to acknowledge. So the sequence number, if there is one, would be ignored and as a result, the few operating systems I tested (BSD, macOS, Linux, Windows 10) all use a sequence number of 0. Could this be used to help with spoofing TCP Resets? Not really. As there is no initial sequence number yet, the RST sequence number wouldn't add anything. A second issue that sometimes causes confusion: RST packets with payload
The RST packet above has a payload length of 11 bytes. tcpdump is nice enough to display the payload with a "RST" prefix. The actual payload here was " --- |
Johannes 4068 Posts ISC Handler Nov 24th 2020 |
Thread locked Subscribe |
Nov 24th 2020 3 months ago |
There is a fairly vague reference in RFC1122 (Host Requirements):
4.2.2.12 RST Segment: RFC-793 Section 3.4 A TCP SHOULD allow a received RST segment to include data. DISCUSSION It has been suggested that a RST segment could contain ASCII text that encoded and explained the cause of the RST. No standard has yet been established for such data. No further details on who suggested this or why. |
Quadword 4 Posts |
Quote |
Nov 24th 2020 3 months ago |
RFC1122 page 87 section 4.2.2.12 mentions RST payload but does not provide details: https://tools.ietf.org/html/rfc1122#page-87
4.2.2.12 RST Segment: RFC-793 Section 3.4 A TCP SHOULD allow a received RST segment to include data. DISCUSSION It has been suggested that a RST segment could contain ASCII text that encoded and explained the cause of the RST. No standard has yet been established for such data. - Darrell Root |
DarrellRoot 5 Posts |
Quote |
Nov 25th 2020 3 months ago |
Another good reason to use RST:
128 TCP connections ought to be enough for everybody. This seems to be the philosophy of Azure App instances. You can have 128 source ports, so can make 128 connections towards your backend webserver's IP no matter how many names. A nicely FIN closed connection blocks its port for 240 seconds (I expect they se limits to handle IP over Avian Carriers, RFC 1149 - So they can allow a late arriving packet in). Sending a RST when closing the port is way better, then there is only a 15s block. Stupid timeouts leads to stupid countermeasures. One open connection per 2 seconds to the same destination is SLOW. Of course you can do request pooling / connection reuse, but that is not guaranteed to be enough. Other solutions are a VPN (no SNAT), multiple IP addresses on the server and either run fast-flux or DNS round robin |
Povl H. 75 Posts |
Quote |
Dec 1st 2020 2 months ago |
Sign Up for Free or Log In to start participating in the conversation!