Skip to main content

TCP sequence number randomization [Resolved]

In a recent interview, my friend was asked about firewalls’ TCP sequence number randomization feature. The interviewer mentioned that we know that a firewall randomizes the TCP sequence number, but an attacker in the middle can still sniff that packet on the wire and send it on behalf of the sender. So what does randomization bring to the table?

I have studied this attack against sequence numbers in RFC 6528 but haven’t been able to grasp the concept fully.

I would appreciate help in understanding this.


Question Credit: Ravneet Singh
Question Reference
Asked September 14, 2019
Tags: , tcpip
Posted Under: Network
31 views
2 Answers

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.


credit: MadHatter
Answered September 14, 2019

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.


credit: Overmind
Answered September 14, 2019
Your Answer