Better SYN flood protection? (Was: Client puzzle protocol)

[Mikael Olsson <mikael.olsson () enternet se>]

Seeing that most people take a look at the "client puzzle protocol"
and say "but this doesn't solve anything?!" I thought I'd take
the opportunity to (re)introduce an idea of mine.

I mentioned this three months ago, but noone seemed interested.
This time around, I took the time of explaining WHY this is 
a good idea, so read on...


Why do we need a better SYN flood protection 
than the current SYN cookies?
--------------------------------------------

  Current SYN cookies are carried in the sequence number
  field, which makes for great compitability with all
  implementations of TCP. 
  
  However, this small field is unable to carry all 
  desired information, which either makes for loss of 
  functionality, or RAM usage on the server side, the 
  latter being exactly what we wanted to avoid by using 
  SYN cookies. 

  Also, using the sequence number field to carry extra
  information makes for a smaller random space of the 
  TCP ISNs, which in turn makes TCP blind spoofing easier.


  In this document, I propose a new standard for implementing
  SYN cookies using a TCP option. This enhancement does not
  break any existing TCP functionality, but acts as a helper
  during SYN flooding attacks. It enables the connection 
  terminator (server / firewall) to remember ANY data from 
  half-open connections while still consuming NO RAM whatsoever.



Why am I mailing this here rather than to the IETF?
---------------------------------------------------

  1) Because I think this may be hard to introduce 
  without some backup.

  2) Because this is more of a firewall issue than a 
  host issue. SYN flood prevention in a firewall
  protecting a large network is VERY expensive in
  terms of RAM usage if one is to do it right.




The Issue
---------

  Upon receipt of a SYN packet, we don't want to use local
  resources to remember it; there is no way of knowing whether
  it is legit or part of a SYN flood

  The ideal situation would be to be able to respond with a SYN+ACK
  packet, and completely forget about original SYN packet.

  This is not possible today, since there are a number of things
  that we'll need later on in the connection, such as the proposed
  MSS, SACKPERMIT, WSOPT information, etc ...

  The SYN cookie schemes of today utilize the sequence number field
  to send information to the connection originator; this works since
  we know that that information is passed back to us unchanged later
  on. The problem is that the MSS/SACK/WSOPT info must be remembered 
  locally, still consuming local resources, albeit not as much as
  before.


New proposed solution
---------------------

  Enter, stage right, two new TCP options:
  TCPOPT_NECHO and TCPOPT_NECHOREPLY.  *clap* *clap* *clap*

  I'd propose that TCPOPT_NECHO could be used in the SYN+ACK packet
  to transmit all the data that the connection terminator would want 
  echoed from the connection originator; this is the same data that
  we otherwise would have to store in RAM for the half-opened connection.
  The connection originator would then respond with a TCPOPT_NECHOREPLY 
  containing all the data received in the NECHO, unaltered, in its ACK packet.

  The data in these options, or its length, is NOT defined by any 
  specification, and their use is NOT regulated by any means. All 
  that is required is that a TCP receiving NECHO will take all its 
  data and send out an NECHOREPLY with the same data in its next packet.

  In the option data, we would be able to place all the information
  that our hearts could desire, along with a hash for authentication.
  This data could include MSS information, window scaling, a boolean
  saying whether SACK is in use, etc ...

  As I said earlier, the format of the option data is not specified.
  It does not have to be. Its contents are only meaningful to the
  host sending the NECHO option, and need not be understood by
  anyone else.

  This also leaves an open opportunity to use this option type somewhere
  else in the future. RST cookies, anyone?


The effects
-----------

  In situations where we're short of memory, we can actually
  drop all information related to SYN_RECVD connections, and
  still have everything work when the ACK packet arrives later
  on, with all the information needed to setup the connection 
  contained in the NECHOREPLY option.


How much does one need to implement
-----------------------------------

  Connection originators (ie all TCP stack implementors) only
  need to be able to REPLY to NECHO options. They do not need
  to be able to send out NECHOs with SYN cookie information of
  their own.

  Connection terminators (firewalls, servers) need to implement
  the generation of NECHO options and consequent parsing of the
  incoming NECHOREPLY options.


Pros
----

  We achieve everything that SYN cookies were initially intended
  to do, including zero RAM usage for half-open connections.

Cons
----

  This won't help connection originators whose stacks don't reply to
  NECHOs. It also means a bit of work on the TCP stacks around the
  world.

  NOTE: My proposed solution does ***NOT*** break today's TCP
  functionality! It is designed as an optional "helper" during
  SYN flooding situations!


So what's the big idea then?
----------------------------

  My (futile?) hope would be that client side developers start 
  implementing the mechanism to REPLY to NECHO requests; it's 
  low cost, simple, and they don't have to have the first clue 
  as to what it does.
  
  Connection originators having the REPLY mechanism would benifit 
  by always succeeding in connecting to a server that sends out 
  its SYN cookies inside an NECHO option, even if it is under 
  heavy SYN flooding.

  Connection originators NOT supporting this option would 
  have a hard time getting to such hosts. I would hope that this
  is incentive enough to get TCP stack implementors to incorporate
  the reply functionality in their code.


Living alongside today's SYN cookies
------------------------------------

  It is completely possible to utilize BOTH types of SYN cookies
  on the same server. Hence, when the server runs out of resources
  to handle sequence-number-carried SYN cookies (which work
  regardless of the originator TCP implementation), the
  new option-based SYN cookies would let people with "new" TCPs 
  connect anyway.


Why "NECHO"?
------------

  There is already an option called "ECHO", see RFC 1072, but its 
  length is assumed to be 6 bytes (4 bytes data). We need more
  than that to be able to relay all information - for future needs.
  The "N" in "NECHO" is simply "New".  
  We could also call it "VECHO", for "Variable (length)"

  One COULD quite conceivably utilize the ECHO option; maybe a lot of
  stacks support it today? I don't know. 
  However, I don't know if it is legal to use in the SYN+ACK packet.

  4 bytes could carry 2 bytes of MSS, 1 byte of window scale, 
  1 bit of SACKPERMIT, and have 7 bits to spare.
  (What about timestamps? I have to go read RFC 1323 again...)
  The whole concept seems kind of .... cramped.

  Maybe one could use ECHO and violate the specification by sending
  more than 4 bytes of data?


Welpz. Enough rambling and unfounded speculation for one day.

Ideas?
Flames?
Comments?
Some backup that I can hand over to Bellovin et Co? :-)
Spontaneous applause? :-)

/Mike

-- 
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46 (0)660 105 50           Fax: +46 (0)660 122 50
Mobile: +46 (0)70 248 00 33
WWW: http://www.enternet.se        E-mail: mikael.olsson () enternet se