Re: Crypto callback (was: New Denial of Service Attack on Panix)

[Avi Freedman <freedman () netaxs com>]

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

- - - - - - - - - - - - - - - - -