Crypto callback (was: New Denial of Service Attack on Panix)
Avi Freedman
freedman at netaxs.com
Tue Sep 24 02:08:16 UTC 1996
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
More information about the NANOG
mailing list