1

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.

Improve this question

4 Answers 4

Reset to default
3

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.

Improve this answer
4
  • Adding context: The server end is secure and I only need to modify the sequence numbers originating from the server network. So the attacks are minimal since there isn't much surface area. The roll-over is a problem though. Commented Jul 24, 2013 at 16:05
  • 1
    Then yeah, from a technical standpoint, the big problem is really just dealing with handling the point where your sequence number has the last 24 bits all 1s, since the next number will roll over into the session information. Might just want to make it always start pretty low, or 0. From a more "is this a good idea" standpoint, well, that depends a bit. As production-level code? No. Dear gods, no. Never let this happen. As part of a research network under controlled circumstances, to make an experiment work? Probably not that big a deal, as long as you undo this on the server when you're done. Commented Jul 24, 2013 at 16:11
  • Also, of course, note that the session information will have to stay constant throughout the connection. If you attempt to change it, your sequence numbers won't line up, and the TCP connection will fail. Commented Jul 24, 2013 at 16:14
  • the numbers will line up. I guess this means I'll have to use linux and recompile the unix sockets part to use only the last 24 bits. Commented Jul 24, 2013 at 16:43
1

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.

Improve this answer
3
  • Will the client send back the options data in each datagram? Commented Jul 25, 2013 at 5:29
  • The client will not automatically send a TCP option - you have to add it yourself. But the complexity of writing a client program that sets a TCP option is orders of magnitude less than that of writing a TCP layer that abuses the SEQ and ACK numbers. Commented Jul 25, 2013 at 10:38
  • We have no control over the client, so options won't work. Commented Jul 25, 2013 at 16:24
0

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.

Improve this answer
1
  • Even writing a network driver won't work because the sequence numbers are stored in winsock's universe. Commented Jul 24, 2013 at 16:08
0

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.

Improve this answer