20

In current time, when a TCP connection is initiated, the initial sequence number is required to be random.

But I am wondering, when TCP was first invented, was the initial sequence number required to be random, or was this requirement added later?

Improve this question
3
  • 11
    When TCP was invented, security considerations were unlikely an issue, as at the time there was no concern about adversarial agents.
    – Leo B.
    Dec 30, 2018 at 4:28
  • 4
    @LeoB., there was concern about adversarial agents, but the typical "adversarial agent" was an MIT or CalTech student looking to perpetrate a prank, and if things got out of hand, you could just talk to the person's sysadmin.
    – Mark
    Dec 30, 2018 at 20:30
  • @Mark Has the DARPA spec included a provision for pranking?
    – Leo B.
    Dec 30, 2018 at 21:01

2 Answers 2

Reset to default
32

The first standard specifying modern TCP is RFC793 from 1981 (with predecessors dating back to 1974), which says about initial sequence number selection:

To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. We want to assure this, even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds.

So they recognized that the sequence number has to be relatively unique, to avoid accidental collision between separate sessions. It didn't, however, consider deliberate attack.

Possible attacks against TCP sequence numbers were first described in 1985, and there were various vendor-specific fixes for it. Finally in 1996, RFC1948 standardized one fix, which uses a cryptographic hash of ports, addresses and secret key to decide the initial sequence number.

This is still the method that is used in e.g. Linux kernel secure_tcp_seq. So it is not really random (which would risk random collisions), but just difficult to predict without knowing the secret key (net_secret in Linux kernel).

Improve this answer
13

It is not actually required that the TCP initial sequence number be random. It would be more correct to say that it is chosen arbitrarily, or to put it another way, that there is no rule specifying how the starting value must be chosen. This means that it can start at 0 for every connection, or at any other number. That same starting value can be used for every new connection, or a new value may be chosen for each one.

For security reasons it's a good idea to choose an actual random value for every individual connection, but there is no actual requirement that it must be done this way.

Improve this answer
3
  • 6
    Actually, there are requirements on the initial sequence number: it must not be a prior in-use sequence number. An ISN of "always 0" has a high risk of confusing an in-transit initial packet from a prior failed connection with the initial packet from a new connection. The requirement to avoid re-use (and a mechanism to do so) are spelled out in the original TCP standard.
    – Mark
    Dec 30, 2018 at 20:37
  • If originator of a connection assigns source port numbers in a manner that ensures they won't get reused for awhile, it won't matter how it assigns sequence numbers. If the socket that accepts a connection always sends back exactly as much data as it receives, it can safely use a received sequence number as its own without having to worry about what numbers it might have used recently.
    – supercat
    Jan 2, 2019 at 22:15
  • Sure, but you lose your mind across a reboot, so you need to take some steps to help prevent accidental aliasing. Seeding the allocator from a clock is one way; making sure it takes your OS a long time to reboot is another.
    – another-dave
    Nov 14, 2021 at 1:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .