0

While learning about Sequence and Acknowledgment numbers one thing bugged me. I wasn't able to rule out for myself if the following scenario in which Host A sends data to Host B by using some established TCP-connection is possible: Host A sends data with sequence number X and acknowledgement number Y to Host B. Host B, in return, sends back data with sequence number Y and acknowledgement number X+1. Now suppose that the data sent by Host B is slow. In the meantime, data from an earlier connection between the same sockets of A and B which is still present in the network and accidentally also has sequence number X arrives at Host A. Would A accept the wrong data packet in this case? How would it be able to detect that its not the right data packet? Or does my scenario not make sense at all?

EDIT: Added the italicised part.

Improve this question
1
  • 1
    Source port numbers should not be reused too fast and initial sequence numbers should be random. If this is not the case (as can be observed in some broken embedded TCP stacks) then this kind of problems can actually happen.
    – Steffen Ullrich
    Aug 26, 2021 at 9:15

2 Answers 2

Reset to default
2

Identical sequence numbers in different connections (=sockets) are not a problem. Each socket tracks its own sequence numbers. At any point in time, a socket is unambiguously defined by the sourceIP:sourcePort:destinationIP:destinationPort tuple.

To ensure that a previously used source port isn't reused while data may still be 'in flight', the port is blocked (with a FIN-WAIT state) until the closing has been confirmed by the remote host (or it is eventually timed out).

For each connection, each segment's position in the potentially infinite data stream is defined by its segment number. That would only pose a problem if the pipe grows so large that it wraps the 32-bit field - you'd need to have 4 GB in flight for that, which only becomes an issue for an interplanetary network. Currently, TCP's window scale option only allows a size of up to ~1 GB.

Improve this answer
7
  • Thanks for answering. I'm a little confused as I was referring to different connections over the same sockets at different points in time. Was my question poorly phrased or didn't I understand your answer? I edited my question (cf. the italicised part).
    – Moritz Loritz
    Aug 26, 2021 at 9:44
  • Different connection = different socket. You shouldn't confuse the BSD-style socket API with TCP sockets.
    – Zac67 ♦
    Aug 26, 2021 at 10:31
  • 1
    This is what motivated my question - Kurose & Ross ("Computer Networking") write: "we assumed that the initial sequence number was zero. In truth, both sides of a TCP connection randomly choose an initial sequence number. This is done to minimize the possibility that a segment that is still present in the network from an earlier, already-terminated connection between two hosts is mistaken for a valid segment in a later connection between these same two hosts (which also happen to be using the same port numbers as the old connection)" (p. 248)
    – Moritz Loritz
    Aug 26, 2021 at 14:03
  • In this case both connections would use the same ports and hence the same socket. Is this in contrast to what you said or did I miss something?
    – Moritz Loritz
    Aug 26, 2021 at 14:03
  • 1
    as said in the Kurose& Ross. It is (at least theoretically) possible that an outdated segments from previous connections arrives. To minimize the probability of this causing a problem, initial sequence numbers should be random. Thus with very high probability the outdated segment will be outside of receiver window and will be rejected.
    – Effie
    Sep 29, 2021 at 21:38
2

Yes, this is theoretically possible. But in practice, a network stack should be designed to minimize the possibility of this happening with a robust random initial sequence number algorithm.

Yes, the host would accept this traffic as it has no way to tell it's from a previous connection. (hackers use the same trick to break connections, but guessing sequence numbers is very difficult.)

(With today's proliferation of NAT, it's entirely possible for port numbers to recycle fast enough for port reuse alone to create this problem.)

Improve this answer
1
  • Some buggy CGNAT implementations exhibit the problem you mentioned @Ricky where they will create a connection with a duplicate 4-tuple. I've observed it on a CDN with the same CDN-side IP in use for both very long-duration sessions (downloads, HTTP Live Streaming, etc) and shorter-duration sessions (regular web traffic) which seems to make collisions on the buggy eyeball-side equipment more likely.
    – Jeff Wheeler
    Aug 26, 2021 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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