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 proposals). W/ a SYN, you might have: a) window-size (1 byte) b) mss (2 bytes) c) data 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. Avi
2). Then host receive SYN, it calculate cryptographic initial TCP sequence depended from IP address [+ probably port] of another TCP side, answer by SYN-ACK with it and forget it.
Cryprographic calculation and verification.
4) Take the negative current time in the 4ms units (see RFC793) and add to it some cryptographic constant which is calculated from other part IP [+port] on the base of secret site key.
5) During checking subtract this cryptographic constant and verify time - it must be in range of 2 max segment live time from current time.
( More accurate strategy would be to increment "time" with any established TCP session, record the real time of each such increment and remove old values which is older than 2MSL.)
6) What it is need to do with MSS option ? - take the default (I said that it is non-elegant decision !)
- Leonid Yegoshin, LY22