Normally TCP/IP Sequence and Acknowledge numbers are 32 bit. However, I need a way to shorten them to be 24 bit (it’s an experiment in deep inspection firewalls).
Question: Is it possible to shorten the bit resolution of the Seq/Ack numbers in windows without the knowledge of the application? (which in this case is IIS)
I want to use those top 8 bits to store some session information.
Theoretically, this could be done, but in practice, you’ll probably need to find somewhere else to store that information. Each end of the connection is allowed to choose any arbitrary number it wants, but using anything other than a completely random number leaves a gaping vulnerability to certain types of attacks. This might be acceptable to you, if the machine in question is on a tightly controlled network, but because of how bad an idea this is, you will essentially need to build your own TCP layer; operating systems generally won’t expose an API to shoot yourself in the foot like this.
And even then, you’ll need to do this at both ends, since each end of the connection chooses its Sequence Number independently. And you’d need to make sure rollover is handled properly. If you really and truly insist on this, then that’s fine, but the machines that you do it on will have issues properly talking TCP with anything else due to the issue of rollover, and you’re going to need to rewrite a lot. You’ll almost certainly be better served trying to find somewhere else to store that session information.
4
Use TCP Options instead. They’re fully supported by most if not all TCP implementations, they’ll transit firewalls intact, etc. Adding one to carry your session id would be pretty straightforward, and it won’t mess with the SEQ/ACK rules.
3
I would think so, those numbers usually aren’t exposed to the application layer, they’re only used by the TCP/IP stack. I’m not sure how you’d actually go about doing it, short of writing your own network driver, but I assume you’ve got a plan.
1
Can we reduce the sequence number ?
As Billy Mailman pointed out theoretically yes you can do it.
Should you do it ?
No,
Why ?
Because every other system in the world will expect the syn/ack sequence number to be of certain length and their TCP stack will be written to parse the standard lengths of each field.So even if your system creates a syn with 24 bits the end system will reply with syn/ack with a sequence number of 32 bit you cannot control that and your system must be smart enough to understand that.You will also face integration issues with other third party devices for the same reason.
And in the second scenario where the end device initiates the connection you will nevertheless have to send 32 bit sequence number
So to do all this you have to create your own TCP stack at the least you have to modify existing ones to suit you and if you manage to do that you ll have minimal or no support for the stack you modified.
How else can we do it ?
It is always best to stick to standards if you want to scale your applications at least with regards to networking standards like TCP. As Ross Patterson pointed out use tcp options. client program can be easily written to set options but messing with sequence numbers will be a nightmare.
If all you want is some session information do it in your application layer and let your application figure out what information it needs and how best to do it, that way it is much more elegant and simpler than what you are trying to do.