I've been thinking about something like that (which at least a few
others have proposed, apparently, though I've not seen texts of their
W/ a SYN, you might have:
a) window-size (1 byte)
b) mss (2 bytes)
I think tossing data is no problem (will get retransmitted) and most
boxes I know of don't send data w/ SYNs. W/o worrying about window-size,
Alex Yuriev & I had figured we could use the upper 12 bits of the 32 bit
seq number to actually throw the mss/2 into and use 20 bits to get
1,000,000 possible crypto keys.
We'd use a current secret key and change it every so often, keeping the
old one around for 30-60 seconds when we change it.
When an ACK of the SYN-ACK comes back, pull the MSS out and check the
crypto checksum. Problem: You have window size, at least.
In practice, I doubt you'd see more than 2^10=1024 or 2^12=4096
combinations of window-size and mss (so you could just store the combos
and use the upper 10-12 bits to store that index).
So the two challenges are:
a) Hacking tcp_input.c, which is a RFM (real frigging mess) - or, to put
it another way, it's written for speed, not to segregate into separate
non-interrelated code paths what happens for SYNs, ACKs of SYNs, ACKS
of SYN ACKs, and then for established connections...
b) Fing a good algoritm to feed:
32 bits (dest ip, could be less if you keep an index of your own local
IPs) + 32 bits (source IP) + 16 bits (source port) + 16 bits (dest port)
+ 32 bits (secret key) in and get out 20-32 bits.
I doubt I'll have any time to mess with this this week, though I may.
Every time I pass through tcp_input.c I grok more - or at least, feel
that I don't *completely* grok less.
Also, I think that someone from BSDi is working on something like this.
And, bottom line is: One way or another, there needs to be a better
way (like a hash into an array) of storing PCBs for the kernel. And
if you solve THAT problem, avoiding PCB-and-socket creation until the
ACK of the SYN-ACK isn't even needed, I suspect.