Clever Geek Handbook

Disable FIN packet and overwrite?

While browsing the open source codebase, I thought of an interesting scenario. Suppose that after a successful TCP connection, the TCP client should send a packet with sequence number = 101. Instead, it sends a FIN with sequence number 201. Now, when the TCP server invalidates the FIN, it queues the data packet to arrive. My question is what the RFC TCP endpoint should do if the server receives a data packet with sequence number = 101 and length = 150. Does it overwrite the previously sent FIN? Or does the server truncate the data packet to a FIN sequence number? Or does it depend on the TCP implementation?

+3


source to share


1 answer


According to some sections of RFC 793

"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 (from a window sequence number or an unacceptable number acknowledgment) shall only trigger an empty acknowledgment segment containing the current send sequence number and an acknowledgment indicating the next expected sequence number and the connection remains in the same state.

....

"The natural way to think about the handling of incoming segments is to imagine that they are first checked for the correct sequence number (i.e. that their contents are within the expected 'receive window' range, in the sequence number space), and then that they are like usually queued and processed in sequential order.

When a segment overlaps other segments already received, we reconstruct the segment to contain only new data and set the header fields to be consistent. "

...



My Resposne: Remember if this happens it is because of bad TCP behavior on the client. Not for no-order, but for the wrong sequence in the segment with the FIN flag. Or maybe an attack.

When TCP, on the server side, receives a segment with SEQ = 201, it will keep that segment for a limited time and will send an ACK of 101 because it is waiting for that SEQ number. Then, when the segment with SEQ = 101 arrives, the TCP on the receiving side after receiving the segment with SEQ = 101 will have a new receive window. From the first arriving segment with SEQ = 201, it should only receive data outside of byte 251 (in my test, it removed overlapping bytes from the segment with SEQ = 101 instead - this may be implementation dependent), if any, and accept a FIN. The receiving TCP will send back an ACK. When the socket is closed on the server side, the receiving TCP will send back the [FIN, ACK] segment.

To test it, I have a client that does exactly what you described (this is done using raw sockets in user space, it is not possible to simulate it using TCP sockets. The server is a simple nodejs server), a FIN segment and after 15 seconds is sent previous segment. The server reads the received data and after 10 seconds it closes the socket.

Here is tcpdump, you can see the responses on the TCP server side:

    [rodolk@localhost ~]$ sudo tcpdump -i p2p1 -vv tcp
tcpdump: listening on p2p1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:33:03.648216 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [S], cksum 0x5f49 (correct), seq 523645, win 500, length 0
19:33:03.649826 IP (tos 0x0, ttl 128, id 26590, offset 0, flags [DF], proto TCP (6), length 44)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [S.], cksum 0x1ac8 (correct), seq 1576251572, ack 523646, win 8192, options [mss 1460], length 0
19:33:03.651208 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [.], cksum 0x5091 (correct), seq 1, ack 1, win 500, length 0
19:33:03.651567 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 74)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [F.], cksum 0x8121 (correct), seq 122:156, ack 1, win 500, length 34
19:33:03.651891 IP (tos 0x0, ttl 128, id 26591, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [.], cksum 0x5314 (correct), seq 1, ack 1, win 65392, length 0
19:33:18.652083 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 171)
    192.168.56.101.16345 > 192.168.56.1.webcache: Flags [P.], cksum 0xf973 (correct), seq 1:132, ack 1, win 500, length 131
19:33:18.652834 IP (tos 0x0, ttl 128, id 26593, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [.], cksum 0x5313 (correct), seq 1, ack 157, win 65237, length 0
19:33:28.661041 IP (tos 0x0, ttl 128, id 26594, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [F.], cksum 0x5312 (correct), seq 1, ack 157, win 65237, length 0
19:33:28.961756 IP (tos 0x0, ttl 128, id 26595, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.56.1.webcache > 192.168.56.101.16345: Flags [F.], cksum 0x5312 (correct), seq 1, ack 157, win 65237, length 0
+2


source






More articles:


All Articles