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


I can propose yet another decision of SYNs flood attack
on the site under attack.
  Unfortunatly I had no time to verify it in real live,
but it is seemed as correct. Also it is not elegant
decision, but ...

   1). It is need to measure the available TCP control blocks
       resource and switch on to this strategy then host is
       under attack (for exam then number of free TCP blocks
       is less 1/3 of all TCP blocks). And switch back after
       it is seens that attack ended.

The strategy consist of

   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.

   3). Then host receive ACK which havn't IPs and ports of any
       already established or closing TCP session, then host verify answer-sequence
       in it and if it is correct - create TCP block and set it to
       established state and run as normal.

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 !)


       - Callback allow the only non-falsified host connection.

       - Cryptographic sum on the base of IP [+port] deny SYNs flood
    also as another spoofing - the other part must answer with
    this callback key. (It is already used in many UNIX systems).
    The probability of success SYN flood attack is 1 for 80000
    SYN packets. The same is for ordinary ACKs flood attack.


       - What would be after unexpected (!) reboot of server ?
   It is looks like one of 80000 nonclosed connection which haven't
   keepalive option and stay passive during reboot and long
   time before reboot can be accepted as new without
   notification of client. But if we take in account
   more accurate strategy of "time" calculation
   the probability of it can be significantly lower.

       - Some perfomance degradation due to MSS loss from initial SYN.
   But some system send MSS during first ACK also and eliminate
   this problem for it.

       - It is need to have source code of server system and some programming
   efforts to implement it :slight_smile:

               - Leonid Yegoshin, LY22