North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Crypto callback (was: New Denial of Service Attack on Panix)
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 - - - - - - - - - - - - - - - - -
|