4

Is a TCP segment with RST but no ACK ever legitimately encountered today?

While some kernels emit such an RST when a SYN segment is sent "illegitimately" from themselves (e.g., nmap half-syn, scapy, etc), I would consider this occurrence illegitimate. Of course, if the port is closed, the scanned server responds with an ACK-RST, if it responds.

Given that a FIN only segment is never legal, is a RST only segment ever legitimately encountered in a network today?

I assume the answer is NO, given the references in the aforementioned link, but just checking given the RST "caveat" mentioned above. Are there any legitimate caveats?

4

Is a TCP packet with RST but no ACK ever legitimately encountered today?

Yes, the ACK is only required for a valid RST when in the SYN-SENT state. See RFC 793, Transmission Control Protocol. In particular, look at the Reset Processing section:

Reset Generation

As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case.

There are three groups of states:

  1. If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.

    If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the CLOSED state.

  2. If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent.

    If our SYN has not been acknowledged and the precedence level of the incoming segment is higher than the precedence level requested then either raise the local precedence level (if allowed by the user and the system) or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly (if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then). If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.

    If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. The connection remains in the same state.

  3. If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received, and the connection remains in the same state.

    If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection,a reset is sent and connection goes to the CLOSED state. The reset takes its sequence number from the ACK field of the incoming segment.

Reset Processing

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.

The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state.


Given that a FIN only packet is never legal...

There is actually nothing in the RFC that forbids a FIN-only segment (not packet). For example, one end of a TCP connection could have already sent ACKs for all received segments, but then it decides that it is done sending, so it will send a FIN segment, but since there is nothing to ACK, it should not send an ACK (doing so could cause a problem that gets a RST in response).

Most modern security devices will probably drop a packet containing a FIN-only segment, but that does not mean it is actually an invalid segment, nor does it mean every such device will drop such a packet.

| improve this answer | |
  • Thank you, and I appreciate the extra update on the FIN. – fundagain Mar 25 '19 at 21:36
  • "For example, one end of a TCP connection could have already sent ACKs for all received segments, but then it decides that it is done sending, so it will send a FIN segment, but since there is nothing to ACK, it should not send an ACK (doing so could cause a problem that gets a RST in response)." I think it does send an ACK with the FIN: From TCP/IP Illustrated "Shortly thereafter the server sends its own FIN with sequence number 1479690172. This segment also (redundantly) ACKs the client’s FIN once again. " Which is why, as you point out, we should not see non ACKed FINs in the wild. – fundagain Apr 3 '19 at 19:15
  • ACKs are to acknowledge something, but if the side sending the first FIN has already sent ACKs for everything, there is nothing to acknowledge. The side sending the first FIN can still receive, and it must still send ACKs for anything it receives after it send the FIN. The first FIN does not necessarily need to acknowledge something, but the other side must acknowledge the FIN, and it usually does with its own ACK/FIN, then the side that sent the first FIN is supposed to send a final ACK to acknowledge the final FIN. – Ron Maupin Apr 3 '19 at 20:37
  • If what you are saying is correct, then surely non-acked fins must be common? What happens to them when cisco switches drop them? – fundagain Apr 3 '19 at 20:40
  • 1
    Probably not. ACKs are literally acknowledgements of something, and most things in networking are bi-directional. Sending duplicate ACKs can mean something was missed or received twice (three can mean it was completely missed, please resend). – Ron Maupin Apr 3 '19 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.