TCP sequence number randomization

I have nothing against Overmind's answer, which is definitely a good summary of why sequence number randomisation was invented. But I'm not sure it answers the question as asked, so I will try to do so.

You are right. Nothing stops a privileged MITM from faking a TCP reset, with a valid SN, right now - randomised SNs or no. But a privileged MITM need not go to such lengths to disturb your connections through his network - he need only unplug a cable, or change a router ACL.

SN randomisation was designed to stop everyone else from doing the same thing. If your SNs can be guessed, anyone can forge that TCP reset, and desynchronise your connections. If they can't be guessed, access to the data stream is required.

Classically, each device chose the ISN by making use of a timed counter, like a clock, that was incremented every 4 microseconds. This counter was initialized when TCP started up and then its value increased by 1 every 4 microseconds until it reached the largest 32-bit value possible (4Gigs) at which point it “wrapped around” to 0 and resumed incrementing. Any time a new connection is set up, the ISN was taken from the current value of this timer. Since it takes over 4 hours to count from 0 to 4,294,967,295 at 4us per increment, this virtually assured that each connection will not conflict with any previous ones. The main issue with this method is that it makes ISNs predictable. A malicious person could write code to analyze ISNs and then predict the ISN of a subsequent TCP connection based on the ISNs used in earlier ones. Because this represents a security risk, which has been exploited in the past, firewall implementations now use a random number in their ISN selection process. That way, predictability is no longer an issue.