Question

In 17.3   TCP Connection Establishment we noted that RST packets had to have a valid SYN value, but that “RFC 793 does not require the RST packet’s ACK value to match”. There is an exception for RST packets arriving at state SYN-SENT: “the RST is acceptable if the ACK field acknowledges the SYN”. Explain the reasoning behind this exception. (This is the one RST transition shown in the state diagram at 17.7   TCP state diagram.)

Answer 1

TCP is quite different in several dimensions .

TCP is stream-oriented, meaning that the application can write data in very small or very large amounts and the TCP layer will take care of appropriate packetization (and also that TCP transmits a stream of bytes, not messages or records;

TCP is connection-oriented, meaning that a connection must be established before the beginning of any data transfer

TCP is reliable, in that TCP uses sequence numbers to ensure the correct order of delivery and a timeout/retransmission mechanism to make sure no data is lost short of massive network failure.

In Above

RFC 793 does not require the RST packet’s ACK value to match”

The original TCP standard RFC 793 does allow data to be sent with the first SYN packet, as part of the handshake, but such data cannot be released to the remote-endpoint application until the handshake completes.

TCP Connection Establishment  RST packets had to have a valid SYN value If B had not been LISTENing at the port to which A sent

its SYN  its response would have been RST (“reset”), meaning in this context “connection refused”. Similarly,if A sent data to B before the SYN packet, the response would have been RST.

RST can be sent by either side at any time to abort the connection. Sometimes routers along the path send “spoofed” RSTs to tear down TCP connections.

sometimes external attackers are able to tear down a TCP connection with a spoofed RST;

spoofed So this Requires the

1.brute-force guessing the endpoint port numbers

2.the current SYN value

Thats why RFC 793 does not require the RST packet’s ACK value to match

In the days of 4 kB window sizes, guessing a valid SYN was a one-in-a-million chance.

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.